Add labels to issues table; canonical taxonomy aligned with GitHub

[ZaxShen]

Problem

Today the issues table has no label support — only status (open / in_progress / closed). That means:

• No way to mark an issue as bug vs enhancement locally.
• No way to filter by category across projects.
• When dual-backend issue tracking lands (separate concern, future PR), local + GitHub issues will need a common label vocabulary to sync. Without alignment, every sync becomes a translation problem.

Proposal

Schema — free-form string labels in a normalized table

CREATE TABLE IF NOT EXISTS issue_labels (
  issue_id INTEGER NOT NULL REFERENCES issues(id),
  label    TEXT    NOT NULL,
  PRIMARY KEY (issue_id, label)
);

CREATE INDEX IF NOT EXISTS idx_issue_labels_label ON issue_labels(label);

Labels are arbitrary strings. The plugin does NOT prescribe a taxonomy — it stores whatever labels the project uses.

Why no prescribed taxonomy

There is no single industry standard for issue labels beyond GitHub's defaults. Any taxonomy the plugin invents would be one team's convention forced onto every downstream user. The plugin's job is to STORE labels and ENABLE them — picking the vocabulary is a per-project decision.

What IS standard — the only cross-project baseline

GitHub creates these 9 default labels on every new repo. They're the closest thing to an industry standard for issue labeling:

• bug — Something isn't working
• documentation — Improvements or additions to documentation
• duplicate — This issue or pull request already exists
• enhancement — New feature or request
• good first issue — Good for newcomers
• help wanted — Extra attention is needed
• invalid — This doesn't seem right
• question — Further information is requested
• wontfix — This will not be worked on

Recommended starting point for any project using TMB: use these names locally for any issue category they cover. Beyond that, users adopt whatever labels their GitHub repo already uses.

Examples of well-known project conventions (NOT prescribed)

For projects that need priority / area / type beyond the GitHub defaults, common conventions in the wild — pick one or invent your own:

Convention	Source	Pattern
Kubernetes labels	kubernetes/kubernetes	kind/bug, priority/critical-urgent, area/kubelet, sig/network
Google priorities	various Google projects	P0 / P1 / P2 / P3 / P4
Linear-style	Linear and similar trackers	flat: urgent, high, medium, low
Conventional Commits-as-labels	some projects map their commits to labels	feat, fix, chore, refactor (originally commit types, not labels)

The plugin doesn't endorse one. Users align with their existing GitHub repo: gh label list shows what's currently in use; the plugin stores the same names.

MCP tools

Add to tools/issues.ts:

• issue_set_labels(issue_id, labels: string[]) — replace label set for an issue.
• issue_add_label(issue_id, label: string) — append one label.
• issue_remove_label(issue_id, label: string) — drop one label.
• issue_list_by_label(label: string, status?: string) — query issues by label.
• Update issue_get and issue_list to include the labels array in the response.

GitHub alignment (future, not in this issue)

When dual-backend issue tracking lands:

• Local label changes → GitHub via gh issue edit --add-label/--remove-label.
• GitHub label changes → local via gh issue list --json labels.
• No translation table needed — same names on both sides because the plugin doesn't impose a different vocabulary.

Documentation

• Update docs/architecture/ERD.md: add issue_labels table to the diagram, FK list, and "How agents use this" section.
• Update mcp/trajectory-server/docs/CONFIG_KEYS.md (or new file) with the GitHub-default-labels list as the recommended baseline + pointers to common conventions.
• Architect / gatekeeper prompts: when creating an issue, check gh label list (or issue_list_by_label to see what's in use locally) and apply matching labels — don't invent new ones unless the user asks.

Acceptance criteria

• issue_labels table added to schema.sql (no migration needed — pre-release, schema_version stays 1)
• 4 new MCP tools: issue_set_labels, issue_add_label, issue_remove_label, issue_list_by_label
• issue_get and issue_list include labels: string[] in their response
• Test: create issue, add labels, query by label, remove label, list with labels included
• Documentation cites GitHub's 9 default labels as the baseline, NOT a plugin-prescribed taxonomy
• ERD.md updated with the new table
• Architect / gatekeeper prompts mention "use existing repo labels (gh label list); don't invent" in their issue-creation flow

Out of scope

• Dual-backend GitHub sync (separate future issue — labels are the precondition for that).
• Repo bootstrap script that creates labels on GitHub (future, post-dual-backend).
• Label colors / descriptions (GitHub-only metadata; not stored locally).

[ZaxShen]

Parked — not blocking v1.0. Reopen when prioritized; the design / acceptance criteria captured in this issue stay valid.

[ZaxShen]

Reopening — was closed as 'parked' but standard is closed = shipped in code. Not implemented yet. Reopen until actually built.