issue-tracking-protocollisted

<overview> # Context-Server Issue Tracker ONE unified tracker thread named `issues` holds every issue of every project -- one workspace-wide system of record, the Linear model. The project dimension lives in metadata (`project`), never in the thread name: any agent files an issue for any project into the same thread and filters by project when querying. One issue = one context entry; the entry's context ID IS the issue number, globally unique across all projects by construction. Why this shape: `project` metadata already encodes the project dimension, so cross-project queries are one `thread_id` plus metadata filters and agents need zero thread-name derivation; context IDs are global, so linking works identically within and across projects; the server's first-class `tags` are the single label mechanism; and one typed `links` object holds every connection an issue has, so no fact is ever stored twice. </overview> <schema_directive> ## Mandatory First Step: Load the Schema Before composing or updating ANY tracker entry, invoke `Skill(skill="context-metadata-schema")`. That skill is the single normative source for the field contract this tracker relies on: the universal core (`schema_version`, `kind`, `project`, `links`), the issue and comment field tables, the status and priority vocabularies, the links registry with its three design rules, the filter recipes (including the compound kind+status MUST and the `case_sensitive` rule for string-ID filters), and the operationa