@elnora-ai/linear 1.0.1 → 2.0.0

package/references/cli-reference.md

@@ -0,0 +1,227 @@
+# elnora-linear CLI Reference
+
+All Linear operations use the `elnora-linear` CLI. Commands output JSON to stdout. Auth via `LINEAR_API_KEY` env var (already set).
+
+**CLI path:** `elnora-linear`
+
+## Commands
+
+```bash
+# Issues
+issues search "terms" [--limit N]
+issues list [--team "Team"] [--project "Project"] [--state "State"]
+issues get ENG-123
+issues create "Title" --team "Team" [--description "md"] [--project "P"] \
+  [--labels "L1,L2"] [--priority 0-4] [--assignee "name"|"me"|"none"] \
+  [--state "Todo"|"Backlog"] [--due-date "YYYY-MM-DD"] [--parent "ENG-123"]
+issues update ENG-123 [--title "T"] [--description "md"] [--state "S"] \
+  [--assignee "name"] [--priority 0-4] [--labels "L1,L2"] [--project "P"] \
+  [--due-date "YYYY-MM-DD"] [--team "Team"]
+
+# Comments
+comments create ENG-123 --body "text"
+comments list ENG-123
+comments update <commentId> --body "text"
+comments delete <commentId>
+
+# Projects
+projects list [--team "Team"] [--state "planned|started|paused|completed|canceled"]
+projects get "Project Name"
+projects create "Name" --team "Team" [--description "md"] [--priority 0-4] \
+  [--lead "name"|"me"] [--start-date "YYYY-MM-DD"] [--target-date "YYYY-MM-DD"] \
+  [--color "#hex"] [--icon "emoji"]
+projects update <nameOrId> [--name "N"] [--description "md"] [--priority 0-4] \
+  [--lead "name"|"me"|"none"] [--start-date "YYYY-MM-DD"] [--target-date "YYYY-MM-DD"] \
+  [--color "#hex"] [--icon "emoji"] [--state "planned|started|paused|completed|canceled|backlog"]
+projects delete <nameOrId> [--permanent]
+projects restore <nameOrId>
+
+# Teams & States
+teams list
+teams get "Team"
+teams create "Name" --key "KEY" [--description "desc"] [--color "#hex"] \
+  [--icon "emoji"] [--timezone "tz"]
+teams update <nameOrId> [--name "N"] [--key "KEY"] [--description "desc"] \
+  [--color "#hex"] [--icon "emoji"] [--timezone "tz"]
+teams delete <nameOrId>
+teams restore <nameOrId>
+states list --team "Team"
+
+# Labels
+labels list [--team "Team"]
+labels create "Name" [--color "#hex"] [--team "Team"]
+labels update <id> [--name "N"] [--color "#hex"] [--description "desc"]
+labels delete <id>
+
+# Users
+users list
+users me
+users get "Name or email"
+
+# Documents
+documents list [--project "Project"] [--limit N]
+documents get <id>
+documents create --title "Title" [--content "md"] [--project "Project"]
+documents update <id> [--title "T"] [--content "md"]
+documents delete <id>
+documents restore <id>
+
+# Cycles
+cycles list --team "Team" [--type current|previous|next]
+cycles get <id>
+
+# Initiatives
+initiatives list
+initiatives get "Name or ID"
+initiatives create "Name" [--description "desc"] [--status Planned|Active|Completed] [--owner "name"]
+initiatives update "Name or ID" [--name "N"] [--status "S"] [--description "D"]
+initiatives delete "Name or ID" [--permanent]
+initiatives restore "Name or ID"
+
+# Milestones
+milestones list --project "Project"
+milestones get "Name or ID" --project "Project"
+milestones create "Name" --project "Project" [--description "D"] [--target-date "YYYY-MM-DD"]
+milestones update <id> [--name "N"] [--description "D"] [--target-date "YYYY-MM-DD"]
+milestones delete <id>
+
+# Status Updates
+status-updates list --type project --project "Project" [--limit N]
+status-updates create --type project --project "Project" [--body "md"] [--health onTrack|atRisk|offTrack]
+status-updates update <id> [--body "md"] [--health onTrack|atRisk|offTrack]
+status-updates delete <id> [--permanent]
+status-updates restore <id>
+
+# Attachments
+attachments list ENG-123
+attachments get <id>
+attachments create ENG-123 --url "URL" --title "Title" [--subtitle "S"] [--icon "emoji"]
+attachments upload ENG-123 --file "path" --filename "name" --content-type "mime" [--title "T"]
+attachments delete <id>
+
+# Relations
+relations create ENG-123 ENG-456 [--type related|blocks|duplicate|similar]  # default: related
+relations list ENG-123
+relations delete <relationId>
+
+# Project Labels
+project-labels list
+project-labels create "Name" [--color "#hex"] [--description "D"]
+project-labels update <id> [--name "N"] [--color "#hex"] [--description "D"]
+project-labels delete <id>
+
+# Issues — atomic label edits and batch ops (v2.2)
+issues subscribe ENG-123
+issues unsubscribe ENG-123
+issues add-label ENG-123 "Type: feature"
+issues remove-label ENG-123 "Layer: frontend"
+issues batch-create <jsonFile|->  # Array of IssueCreateInput; cap 50; --yes when N>=10. NOTE: requires raw UUIDs (teamId, labelIds, stateId) — does NOT resolve names like single-issue create. Look up IDs first via teams/labels/states list.
+issues batch-update <ids> <jsonPatchFile|->  # ids = comma-separated ENG-X or UUIDs
+
+# Comments resolve / unresolve (v2.2)
+comments resolve <commentId>
+comments unresolve <commentId>
+
+# Reactions (v2.2)
+react <ENG-X|commentUUID> "<emoji>" [--issue]   # --issue forces UUID -> issueId
+unreact <reactionId>
+
+# Reactions notes:
+# - Linear normalizes shortcodes server-side (e.g. "thumbsup" → "+1"). The
+#   returned reaction.emoji reflects the normalized form. Pass either the
+#   literal Unicode glyph (👍) or a known shortcode (:eyes:); both work.
+# - --issue is implied when the target matches ENG-N. Passing it on an
+#   ENG-N target is a no-op and now emits a stderr warning.
+
+# Quota (v2.2)
+quota   # Remaining rate-limit budget — allowed/remaining/requested/period/resetAt
+
+# Audit (v2.2 — read-only)
+audit entries [--limit N] [--since "ISO"] [--type "AuditEntryType"]
+audit types
+
+# Notifications (v2.2)
+notifications list [--limit N] [--unread]
+notifications get <id>
+notifications archive <id> --yes
+notifications mark-read   --issue|--initiative|--initiative-update <id> [--at "ISO"]
+notifications mark-unread --issue|--initiative|--initiative-update <id>
+notifications snooze      --issue|--initiative|--initiative-update <id> --until "ISO"
+
+# Customers (v2.2 — Linear's customer-feedback feature)
+customers list [--query "text"] [--limit N]
+customers get <idOrName>
+customers create "Name" [--domains "csv"] [--external-ids "csv"] [--owner "userOrMe"] [--revenue N] [--size N] [--logo-url URL]
+customers update <idOrName> [--name "N"] [--domains "csv"] [--external-ids "csv"] [--owner "userOrMe|none"] [--revenue N] [--size N] [--logo-url URL]
+customers upsert --external-id <id>|--id <uuid> [--name "N"] [--domains "csv"] [--owner "u"] [--revenue N] [--size N]
+
+customer-needs list [--customer "idOrName"] [--project "Name"] [--limit N]
+customer-needs get <id>
+customer-needs create --body "md" (--customer <idOrName>|--customer-external-id <id>) (--issue ENG-X|--project "Name") [--priority 0|1] [--attachment <id>|--attachment-url <url>]   # Linear API: priority is 0 or 1 only (not 0-4 like issues)
+customer-needs from-attachment <attachmentId>
+customer-needs update <id> [--body "md"] [--customer "X"] [--issue ENG-X|--project "Name"] [--priority 0-4]
+customer-needs archive <id> --yes
+
+# Templates (v2.2)
+templates list [--type issue|project|document] [--team "Name"]
+templates sync --team "<your-team>" [--dry-run] [--templates-dir <path>] [--yes]
+
+# Webhooks (v2.2 — agent framework)
+webhooks list [--limit N]
+webhooks get <id>
+webhooks create --url <https-url> --resource-types "Issue,AgentSessionEvent" (--team "Name"|--all-public-teams) [--label "L"] [--secret <s>] [--disabled]
+webhooks update <id> [--url <https-url>] [--resource-types "csv"] [--label "L"] [--enabled|--disabled]
+webhooks delete <id> --yes
+webhooks rotate-secret <id> --yes   # Secret shown ONCE
+webhooks verify <signatureFile> --body <bodyFile> [--secret <s>]
+
+# Agent sessions (v2.2)
+agent-sessions list [--limit N]
+agent-sessions get <id>
+agent-sessions create-on-issue <ENG-X|UUID> [--external-link <url>]
+agent-sessions create-on-comment <commentUUID> [--external-link <url>]
+agent-sessions update <id> [--external-link <url>] [--plan '<jsonString>']
+agent-sessions update-external-url <id> [--external-link <url>] [--add <url>] [--remove <url>]
+
+# Agent activities (v2.2)
+agent-activities list <sessionId> [--limit N]
+agent-activities get <id>
+agent-activities create <sessionId> --type thought|action|elicitation|response|error \
+  [--body "text"] [--action "name"] [--parameter "p"] [--result '<json>'] \
+  [--signal select|auth|continue|stop] [--signal-metadata <jsonFile>] [--ephemeral]
+```
+
+**Priority values:** 0=None, 1=Urgent, 2=High, 3=Normal, 4=Low
+
+**Note:** `--labels` replaces existing labels. To preserve, first read from `issues get`, then include all in `--labels`.
+
+## Argument Style — Positional vs Flag
+
+Some commands take a value as a flag (`--body "text"`) and others as a positional. The conventions:
+
+| Command | Style | Example |
+|---------|-------|---------|
+| `comments create <issueId> --body "text"` | Flag — body is multi-line and optional in syntax | `comments create ENG-1 --body "Looks good"` |
+| `comments update <id> --body "text"` | Flag — same reason | `comments update <uuid> --body "Updated"` |
+| `issues add-label <id> <label>` | Positional — single label, atomic | `issues add-label ENG-1 "Type: bug"` |
+| `issues remove-label <id> <label>` | Positional — single label, atomic | `issues remove-label ENG-1 "Type: bug"` |
+| `issues update <id> --labels "L1,L2"` | Flag — REPLACES the full set, plural | `issues update ENG-1 --labels "Type: bug,Layer: frontend"` |
+| `react <target> <emoji>` | Two positionals | `react ENG-1 "🚀"` |
+| `unreact <reactionId>` | One positional (UUID only) | `unreact <uuid>` |
+
+The label commands are intentionally asymmetric: `add-label`/`remove-label` are atomic single-label edits, while `--labels` on `issues update` is a full-set replacement (use it when you mean "set the labels to exactly this list").
+
+## Common Mistakes
+
+| Wrong | Correct | Why |
+|-------|---------|-----|
+| `--assign` | `--assignee` | Full flag name required |
+| `--labels "X"` on `issues list` | `--label "X"` (singular) | `list` filters by ONE label; `create`/`update` set MANY |
+| `--desc` | `--description` | Full flag name required |
+| `--body` (on issues) | `--description` | `--body` is for `comments create` only |
+| `add-label ENG-1 "a,b"` | Two calls, or `update --labels "current,a,b"` | `add-label` rejects comma-containing values |
+| `--project "X" --team "Y"` where X belongs to Z | Match project to its owning team | Projects are team-scoped — check `workspace-routing.md` |
+| `batch-create` with `teamName`/`labelNames` | Pass raw UUIDs (`teamId`, `labelIds`) | Batch ops skip name resolution by design |
+
+**Label flag convention:** `--label` (singular) for `issues list` filtering. `--labels "L1,L2"` (plural, comma-separated) for `create`/`update` to SET the full label set.
+

package/references/curator-tiering-rules.md

@@ -0,0 +1,78 @@
+# Linear State Curator — Tiering Rules
+
+Edit this file to tune the curator's behavior. Loaded at runtime by the curator and embedded into the LLM snapshot. The JSON copy of these rules lives in `workflows.json` (loaded by the rule engine); this file is the human-readable contract.
+
+The curator scores every open issue (Todo / In Progress / Backlog) on the teams listed in `teams.json` against the rules below and picks the highest-confidence tier that fires.
+
+> **Implementation status (2026-05):** the HIGH tier (auto-apply) and LOW tier (report only) are fully wired. The MEDIUM tier currently stages questions in `~/.config/elnora-linear/state/curator-state.json` only — the Slack-posting and DM-back paths described below (top-level channel posts, threaded LLM-classified replies, label-allowlist DMs) are part of the design contract but **not yet shipped**. The orchestrator that posts to Slack, classifies replies, and applies the result is a follow-up release. Treat the Slack language as planned behavior; today, a human reads the state file (or the `linear-state-curator` agent does).
+
+## HIGH — auto-apply state changes (cap: 20 per run)
+
+Any one of these fires the HIGH tier. The curator updates state via `elnora-linear issues update`, posts a rationale comment on the issue with cited signals, and lists the action in the daily summary.
+
+- **H1 — Todo + merged PR.** Issue state is `Todo` AND a linked GitHub PR is merged within the last 7 days AND the merge commit message contains the issue ID (e.g. `ENG-123`). → set state `Done`.
+- **H2 — In Progress + merged PR by assignee.** Issue state is `In Progress` AND a linked PR is merged AND the PR author's email matches the assignee's email. → set state `Done`.
+- **H3 — Duplicate of recently closed issue.** Issue title fingerprint (lowercased, stopwords removed, top 5 keywords) matches a `Done` issue from the last 30 days in the same project. → set state `Canceled` with comment `Duplicate of <ID>`.
+- **H4 — External compliance signal passed.** Issue description references an external compliance check (e.g. a vendor test ID) that has been `PASSED` for >7 days. → set state `Done`. (Connect your compliance tooling via the `external_command` signal source.)
+- **H5 — Customer milestone signal.** Issue is in `customer-onboarding`-style project AND a corresponding customer milestone signal (from `slack_messages` or `external_command`) confirms completion. → set state `Done`.
+- **H6 — Backlog rot.** Issue state is `Backlog` AND no activity (comments, edits, label changes) in 60+ days AND no labels AND no assignee. → set state `Canceled` with comment `Canceled by curator: 60d+ inactive, no signal of intent.`
+
+## MEDIUM — ask in Slack (cap: 10 per run)
+
+Any one fires MEDIUM. The curator posts a top-level message in a configured channel (see `slack.json` `allowed_channels`) with `@mention` of the assignee — anyone allowed can reply in the thread.
+
+**Reply formats:**
+- Keywords: `done` / `close` / `yes` → apply. `skip` / `keep` / `hold` → leave. `cancel` / `wontfix` → cancel.
+- Free-form: *"yeah ship it"*, *"hold off, customer asked us to wait"*, *"first one done, second still open"*, *"actually ISSUE-235 is the one that's done, not this"* — the curator runs all replies through a single batched Claude call per run that sees ALL pending threads + ALL replies together. So:
+  - Multi-issue replies are routed correctly.
+  - References to issues NOT in the pending list are captured as out-of-band mentions and surfaced next run.
+  - Ambiguous replies trigger a follow-up question in the same thread instead of dropping silently.
+
+For label-blocked issues (rule M6 below), the curator instead **DMs an allow-listed user privately** so compliance/customer info stays out of public threads. See `slack.json` `allowed_dm_users`.
+
+**Reply processing cadence:** configurable per deployment. Typical setups:
+- Hourly during working hours — `resolve-only` mode processes pending replies (no full sweep).
+- Daily — full sweep including new HIGH/MEDIUM/LOW evaluation.
+- Manual: `elnora-linear curator-run --apply` triggers immediate processing.
+
+The curator posts a confirmation reply in the same thread once it acts (or asks a follow-up if it needs clarification).
+
+- **M1 — Commits without merged PR.** Commits in configured repos reference an issue ID in their message but no linked PR is merged yet. Question: "should I move this to In Progress?"
+- **M2 — Stalled In Progress.** Issue state is `In Progress` AND zero commits referencing it AND zero comments in 14+ days. Question: "still active, or should I move it back to Todo?"
+- **M3 — External email/thread match.** Issue title overlaps with a recent external thread (>=3 keyword match) AND no Linear comment in 7+ days. Question: "have you handled this off-ticket?"
+- **M4 — PR closed unmerged.** Linked PR was closed without merging AND issue is still open. Question: "abandoned, or new PR coming?"
+- **M5 — Title near-duplicate, both open.** Two issues in the same project with >=85% title similarity, both Todo. Question: "merge into one — which is the canonical?"
+- **M6 — Label allowlist override.** Any HIGH-tier rule that fires on an issue carrying a label in the workspace's "never-touch" set (`customer:*`, `compliance:*`, `security:critical`, `sla:*`) is automatically downgraded to MEDIUM and routed to a specific user via DM. The label allowlist exists to prevent silent state changes on customer- or compliance-sensitive work.
+
+## LOW — channel report only
+
+No action, no DM. Listed in the daily summary post under "Needs human triage".
+
+- **L1 — Pure stale Todo.** No HIGH or MEDIUM signal AND last activity >30 days AND state is Todo.
+- **L2 — Inactive assignee.** Assignee has zero Linear activity >60 days. Curator can't reach them on Slack. Surface in the channel.
+- **L3 — Unverifiable external reference.** Issue description references an external URL the curator cannot validate. Surface so a human can check.
+
+## Hard caps
+
+- `MAX_MUTATIONS=20` per run (HIGH actions).
+- `MAX_QUESTIONS_PER_DAY=10` (new MEDIUM DMs).
+- Excess HIGH and MEDIUM candidates roll over to the next run, prioritized by oldest `updatedAt`.
+
+## Never-touch labels
+
+Issues carrying any of these labels are never auto-mutated. Any HIGH match is downgraded to MEDIUM and DM'd to an allow-listed user, not the assignee.
+
+- `customer:*` — anything customer-facing
+- `compliance:*` — SOC 2, ISO 27001, GDPR, audit work
+- `security:critical` — critical-severity security
+- `sla:*` — items with explicit SLA commitments
+
+You can customize this allowlist in `workflows.json` under `never_touch_labels`.
+
+## Outbound surface
+
+Configured in `slack.json`:
+- `allowed_channels`: the only channels the curator may post in.
+- `allowed_dm_users`: the only users the curator may DM.
+
+Anything outside this surface is rejected as a bug — the curator is forbidden from messaging customers or external parties under any circumstance.

package/references/label-policy.example.json

@@ -0,0 +1,37 @@
+{
+	"$schema": "../schemas/label-policy.json",
+	"_example": true,
+	"policies": {
+		"ENG": {
+			"name": "Engineering",
+			"required": [
+				{
+					"prefixes": ["Type:"],
+					"min": 1,
+					"max": 1,
+					"description": "exactly one Type: label (feature | bug | improvement | research)"
+				},
+				{
+					"prefixes": ["Layer:"],
+					"min": 1,
+					"max": null,
+					"description": "one or more Layer: labels (frontend | backend | ops)"
+				}
+			],
+			"allowedPrefixes": ["Type:", "Layer:", "Flag:", "Template:"],
+			"requiresProject": true
+		},
+		"OPS": {
+			"name": "Operations",
+			"required": [
+				{
+					"prefixes": ["Type:", "Template:"],
+					"min": 1,
+					"description": "at least one Type: label OR a Template: label for compliance work"
+				}
+			],
+			"allowedPrefixes": ["Type:", "Template:", "Cadence:", "Flag:"],
+			"requiresProject": true
+		}
+	}
+}

package/references/label-policy.placeholder.json

@@ -0,0 +1,6 @@
+{
+	"$schema": "../schemas/label-policy.json",
+	"_placeholder": true,
+	"_populated_by": "manual edit; populate per-team label policies as you formalise them",
+	"policies": {}
+}

package/references/settings-template.md

@@ -0,0 +1,30 @@
+# elnora-linear — Settings Template
+
+Copy this file to `.claude/elnora-linear.local.md` in your project root to customize the plugin.
+
+```markdown
+---
+enabled: true
+default_team: "<your-default-team>"
+strict_validation: true
+ask_before_creating: true
+---
+
+# elnora-linear Configuration
+
+## Default Team
+Issues are created in the default_team unless specified otherwise.
+Options: see your `teams.json` reference for valid team keys/names.
+
+## Strict Validation
+When true, blocks issues missing required labels per your `label-policy.json` (e.g. Type + Layer on engineering teams).
+When false, creates with warnings.
+
+## Ask Before Creating
+When true, asks user to confirm project/labels when detection is uncertain.
+When false, uses best-effort detection.
+```
+
+## After Creating
+
+Restart Claude Code for changes to take effect.

package/references/signal-sources.example.json

@@ -29,14 +29,6 @@
 			"command": "ci-cli list-failing-builds --json",
 			"parse_as": "json",
 			"issue_match_field": "linear_issue_id"
-		},
-		{
-			"type": "mcp_tool",
-			"name": "stripe-payment-failures",
-			"enabled": false,
-			"server": "stripe-cli",
-			"tool": "list_failed_payments",
-			"args": { "lookback_hours": 24 }
 		}
 	]
 }

package/references/sla-reference.md

@@ -0,0 +1,70 @@
+# SLA Reference
+
+Due date = today + SLA days (ISO format YYYY-MM-DD).
+
+## Template SLA Mapping
+
+### Immediate Response (Same Day / 24 Hours)
+
+| Template Label | SLA | Due Date Calculation |
+|----------------|-----|---------------------|
+| `Template: Access-Provision` | Same day | Today |
+| `Template: Privileged-Access` | Same day | Today |
+| `Template: Access-Revoke` | 24 hours | Today + 1 day |
+| `Template: Security-Incident` (Sev 0) | 15 minutes | Immediate |
+| `Template: Security-Incident` (Sev 1) | 1 hour | Today |
+| `Template: Availability-Incident` (Critical) | 1 hour | Today |
+
+### Short-Term (1-5 Days)
+
+| Template Label | SLA | Due Date Calculation |
+|----------------|-----|---------------------|
+| `Template: Change-Standard` | 1-2 days | Today + 2 days |
+| `Template: Data-Modification` | 1-2 days | Today + 2 days |
+| `Template: RCA` (Sev 0) | 3 days | Today + 3 days |
+| `Template: Availability-Incident` (Medium) | 3 days | Today + 3 days |
+
+### Medium-Term (5-30 Days)
+
+| Template Label | SLA | Due Date Calculation |
+|----------------|-----|---------------------|
+| `Template: Change-Significant` | 5-10 days | Today + 10 days |
+| `Template: AI-Use-Case` | 5-10 days | Today + 10 days |
+| `Template: Corrective-Action` (Minor) | 5-30 days | Today + 30 days |
+| `Template: RCA` (Sev 1) | 5 days | Today + 5 days |
+| `Template: RCA` (Sev 2) | 10 days | Today + 10 days |
+| `Template: Lessons-Learned` | 10-20 days | Today + 20 days |
+| `Template: Availability-Incident` (Low) | 14 days | Today + 14 days |
+| `Template: Change-Major` | 15-30 days | Today + 30 days |
+| `Template: Operational-Request` | 3-14 days | Today + 14 days |
+| `Template: RCA` (Sev 3) | 20 days | Today + 20 days |
+
+### Long-Term (30+ Days)
+
+| Template Label | SLA | Due Date Calculation |
+|----------------|-----|---------------------|
+| `Template: Access-Review` | 30 days | Today + 30 days |
+| `Template: Management-Review` | 30 days | Today + 30 days |
+| `Template: Risk-Assessment` | 30 days | Today + 30 days |
+| `Template: Vendor-Assessment` | 30 days | Today + 30 days |
+| `Template: Vulnerability` | 30-90 days | Based on severity |
+| `Template: Pentest-Finding` | 30-90 days | Based on severity |
+| `Template: Internal-Audit` | 60 days | Today + 60 days |
+| `Template: Backup-Test` | RTO: 2 hours | Scheduled quarterly |
+
+---
+
+## Severity-Based SLAs
+
+For security issues, SLA depends on severity:
+
+| Severity | Vulnerability SLA | Pentest SLA | Security Incident SLA |
+|----------|------------------|-------------|----------------------|
+| Critical | 7 days | 7 days | 15 minutes |
+| High | 14 days | 14 days | 1 hour |
+| Medium | 60 days | 60 days | 4 hours |
+| Low | 90 days | 90 days | 24 hours |
+
+---
+
+Calendar days unless specified. SLA breach → create linked AUD-CAP issue.

package/references/template-index.md

@@ -0,0 +1,34 @@
+# Template Index
+
+Compliance templates for an ISO 27001 / SOC 2 audit trail. Templates route to a compliance team for documentation; actual fixes go to your engineering or security teams.
+
+**Usage:** Match keywords below → load ONE template → check `sla-reference.md` for due date.
+
+## Routing Table
+
+| Keywords | Template | File | Project |
+|----------|----------|------|---------|
+| incident, breach, attack, compromise | SEC-INC | `templates/SEC-INC-incident.md` | Security Incidents |
+| vulnerability, CVE, dependabot, codeql, security scan | SEC-VLN | `templates/SEC-VLN-vulnerability.md` | Vulnerability Management |
+| pentest, penetration test finding | SEC-PEN | `templates/SEC-PEN-pentest.md` | Pentest Remediation |
+| minor update, documentation fix, clarification | CHG-STD | `templates/CHG-STD-standard.md` | Standard Changes |
+| control change, procedure change, risk treatment | CHG-SIG | `templates/CHG-SIG-significant.md` | Significant Changes |
+| scope change, policy change, organizational change | CHG-MAJ | `templates/CHG-MAJ-major.md` | Major Changes |
+| new hire, onboarding, new access, grant access | ACC-PRO | `templates/ACC-PRO-provision.md` | Access Provisioning |
+| termination, offboarding, remove access, revoke | ACC-REV | `templates/ACC-REV-revoke.md` | Access Revocation |
+| access review, quarterly review, permission audit | ACC-QTR | `templates/ACC-QTR-review.md` | Quarterly Access Reviews |
+| admin access, root, elevated permissions, privileged | ACC-PRV | `templates/ACC-PRV-privileged.md` | Privileged Access |
+| internal audit, audit planning, control audit | AUD-INT | `templates/AUD-INT-internal.md` | Internal Audits |
+| management review, ISMS review, governance meeting | AUD-MGT | `templates/AUD-MGT-management.md` | Management Reviews |
+| nonconformity, NC, corrective action, audit finding | AUD-CAP | `templates/AUD-CAP-corrective.md` | Corrective Actions |
+| risk assessment, threat assessment, risk analysis | RSK-ASS | `templates/RSK-ASS-assessment.md` | Risk Assessments |
+| vendor assessment, supplier review, third-party risk | RSK-VND | `templates/RSK-VND-vendor.md` | Vendor Assessments |
+| AI use case, new AI capability, AI capability scope, model family change, foundation model swap | AI-USE | `templates/AI-USE-capability.md` | AI Governance |
+| backup test, restore test, DR test | OPS-BCK | `templates/OPS-BCK-backup.md` | Backup & DR Testing |
+| production data, data fix, database correction | OPS-DAT | `templates/OPS-DAT-data-mod.md` | Data Modifications |
+| outage, downtime, service unavailable | SLA-AVL | `templates/SLA-AVL-availability.md` | Availability Incidents |
+| infrastructure request, operational request | SLA-OPS | `templates/SLA-OPS-operational.md` | Operational Requests |
+| RCA, root cause, post-mortem | RCA-DOC | `templates/RCA-DOC-root-cause.md` | Root Cause Analysis |
+| lessons learned, retrospective, incident review | LRN-DOC | `templates/LRN-DOC-lessons.md` | Lessons Learned |
+
+No match? Route per `workspace-routing.md` with standard Type + Layer labels.

package/references/workspace-labels.md

@@ -0,0 +1,124 @@
+# Workspace Labels Reference
+
+> **Source of truth note:** the *required-label policy* per team is enforced
+> by the CLI (see `references/label-policy.json` + `elnora-linear issues
+> create` validation). The full *label catalog* is fetched live via
+> `elnora-linear context --team "<Team>"`. This file is human-only
+> documentation kept around for browsing the taxonomy at a glance — agents
+> no longer read it.
+
+The labels below are the suggested taxonomy this plugin assumes when you wire up label policies and templates. Replace with your own conventions; the structure (Type / Layer / Severity / Flag / Source / Cadence / Repo / Template) is the load-bearing piece.
+
+## Required Labels (example for an engineering team)
+
+### Type Labels (pick one)
+
+| Label | Keywords | When to Use |
+|-------|----------|-------------|
+| `Type: feature` | add, implement, build, create, new | New functionality |
+| `Type: improvement` | improve, optimize, refactor, enhance | Enhance existing |
+| `Type: bug` | fix, broken, error, crash, not working | Defects |
+| `Type: research` | research, explore, investigate, spike | Investigation |
+| `Type: compliance-task` | compliance, audit, evidence, documentation | Compliance work |
+
+### Layer Labels (pick one or more)
+
+| Label | When to Use |
+|-------|-------------|
+| `Layer: frontend` | UI code (React, Vue, Svelte, etc.) |
+| `Layer: backend` | API, database, server-side |
+| `Layer: ai-server` | Python, LLM, agents, ML pipelines |
+| `Layer: devops` | Cloud, CI/CD, Docker, infrastructure |
+| `Layer: operations` | Internal processes, audits, compliance |
+
+## Severity Labels
+
+| Label | When to Use |
+|-------|-------------|
+| `Severity: Critical` | System down, data breach, security emergency |
+| `Severity: High` | Major functionality broken, significant security |
+| `Severity: Medium` | Moderate impact, workaround exists |
+| `Severity: Low` | Minor issue, cosmetic, nice-to-have |
+
+**SLAs:** See `sla-reference.md` for due date calculation.
+
+## Flag Labels (optional)
+
+| Label | When to Use |
+|-------|-------------|
+| `Flag: security` | Security-related — vulnerabilities, auth, encryption |
+| `Flag: compliance` | SOC2, ISO27001, audit requirements |
+| `Flag: Risk Accepted` | Security issues where the risk has been accepted |
+| `Flag: AI-Incident` | AI-specific incident — hallucination causing harm, refusal failure, prompt-injection breach, model regression, AI-pathway data handling failure, or bias-related complaint. Used in conjunction with `Template: Security-Incident` on the Security Incidents project. Replaces a separate AI Incident Register and a separate bias-complaint log. |
+
+## Source Labels (track origin)
+
+| Label | When to Use |
+|-------|-------------|
+| `Source: Vulnerability Scan` | Automated scanning (Dependabot, Inspector) |
+| `Source: CodeQL` | GitHub CodeQL alerts |
+| `Source: Penetration Test` | External pentest findings |
+| `Source: Internal Discovery` | Found by team internally |
+| `Source: Customer Report` | Security issue from customer |
+| `Source: Support Request` | General support request |
+| `Source: Feature Request` | Customer feature request |
+| `Source: Bug Report` | Customer bug report |
+
+## Cadence Labels (recurring tasks)
+
+| Label | When to Use |
+|-------|-------------|
+| `Cadence: Annual` | Recurring tasks every 12 months |
+| `Cadence: Quarterly` | Recurring tasks every 3 months |
+
+## Repo Labels (link issue to source repo)
+
+Apply when an issue is scoped to one of your configured repos (see `repos.json`). Used by the curator and PR-linking automations.
+
+| Label | Repo |
+|-------|------|
+| `Repo: <repo-name>` | `github.com/<your-org>/<repo>` |
+
+## Access Labels
+
+| Label | When to Use |
+|-------|-------------|
+| `Account Setup` | New user account provisioning |
+| `Access Request` | New access requests |
+| `Access Revocation` | User termination/offboarding |
+| `Infrastructure` | DevOps work |
+
+**SLAs:** See `sla-reference.md` for due date calculation.
+
+## Template Labels (compliance workflows)
+
+| Label | Template File |
+|-------|---------------|
+| `Template: Security-Incident` | SEC-INC-incident.md |
+| `Template: Vulnerability` | SEC-VLN-vulnerability.md |
+| `Template: Pentest-Finding` | SEC-PEN-pentest.md |
+| `Template: Change-Standard` | CHG-STD-standard.md |
+| `Template: Change-Significant` | CHG-SIG-significant.md |
+| `Template: Change-Major` | CHG-MAJ-major.md |
+| `Template: Access-Provision` | ACC-PRO-provision.md |
+| `Template: Access-Revoke` | ACC-REV-revoke.md |
+| `Template: Access-Review` | ACC-QTR-review.md |
+| `Template: Privileged-Access` | ACC-PRV-privileged.md |
+| `Template: Internal-Audit` | AUD-INT-internal.md |
+| `Template: Management-Review` | AUD-MGT-management.md |
+| `Template: Corrective-Action` | AUD-CAP-corrective.md |
+| `Template: Risk-Assessment` | RSK-ASS-assessment.md |
+| `Template: Vendor-Assessment` | RSK-VND-vendor.md |
+| `Template: AI-Use-Case` | AI-USE-capability.md |
+| `Template: Backup-Test` | OPS-BCK-backup.md |
+| `Template: Data-Modification` | OPS-DAT-data-mod.md |
+| `Template: Availability-Incident` | SLA-AVL-availability.md |
+| `Template: Operational-Request` | SLA-OPS-operational.md |
+| `Template: RCA` | RCA-DOC-root-cause.md |
+| `Template: Lessons-Learned` | LRN-DOC-lessons.md |
+
+**SLAs:** See `sla-reference.md` for due date calculation by template.
+
+---
+
+*Routing: `workspace-routing.md` | SLAs: `sla-reference.md`*