issue-triage-routing

name	issue-triage-routing
description	Issue-triage upflow depth: the four repo classes, Route-A issue vs Step-7c upflow, the origination taxonomy, and the durable-proposal lifecycle. Use when triaging a GitHub issue.

Issue Triage → Upflow Routing — Depth Reference

The always-on routing MUST lives in rules/issue-triage-routing.md (read .claude/VERSION::type → route by class). This skill carries the on-demand depth: how each repo class routes, the two upflow paths (Route-A issue vs the Step-7c PR), the origination taxonomy, and why the durable surface is always the proposal — never a local artifact edit. The authoritative mechanics live in rules/artifact-flow.md § "Issue Routing By Change Type"; this skill is the triage-time companion that resolves the class → lane decision.

The Discriminator: Route By Change TYPE, Not Repo Convenience

Every artifact-or-code issue routes by the TYPE of change it requests:

• COC-artifact improvement (method, rules, skills, agents, COC-tooling) → the USE-template lane → a proposal via /codify Step 7b.
• Bug / code / feature / code-improvement (SDK code) → the BUILD lane → cross-SDK FIRST, then a proposal via /codify Step 7a.

Routing by repo convenience (a COC-method fix filed on BUILD; an SDK bug filed on a USE template) puts the change on the wrong lane — it never becomes the right kind of proposal, and the Gate-1 global-vs-variant split is bypassed.

The Four Repo Classes (read .claude/VERSION::type)

type	Role	A triaged issue routes to…
coc-use-template	origination node	/codify Step 7b proposal → loom /sync-from-use Gate-1 → /sync-to-use redistributes
coc-project	downstream consumer	UP to the template pulled from: /codify Step 7c PR to the template inbox (primary), or Route-A issue (fallback)
coc-build	SDK code	cross-SDK FIRST → /codify Step 7a proposal
coc-source	loom (splitter)	INGEST via /sync-from-build + /sync-from-use, Gate-1 classify — never originate a local artifact

coc-use-template — the origination node

A USE template (kailash-coc-claude-py, kailash-coc-claude-rs, kailash-coc-py, kailash-coc-rs) is the ONLY repo class that originates proposals to loom. A COC-artifact issue filed here — or an owner-filed Route-A downstream filing on its behalf — is consolidated by /codify Step 7b into a proposal in .claude/.proposals/, which loom /sync-from-use ingests (Gate-1 classify: global vs variant) and /sync-to-use redistributes on the next cycle. Downstream consumers pull on their own cadence.

coc-project — the downstream consumer (Route A vs Step 7c)

A downstream consumer is any repo that pulled COC artifacts FROM a USE template (end-user project repos, kaizen-cli-py, kz-engage, and every consumer of the canonical USE-template set). It routes COC-method improvements UP to the template it pulled from — NOT to its own repo, NOT to loom — via two paths:

• Primary — Step 7c upflow (push-only, human-gated): the consumer's own /codify Step 7c originates a proposal and offers it as a HUMAN-GATED PR to the template's .claude/.proposals/inbox/<date>-<slug>.yaml. The template's /sync-from-downstream scrubs + reviews-as-data + dedups + relays accepted entries into its OWN Step-7b manifest with hop-level provenance (origin: downstream, via: <template-slug> — never consumer-identifying).
• Fallback — Route A (issue on the template): for no-fork-permission or stale (pre-7c) consumers, file a COC-method issue against the USE template; the template's /codify originates the proposal per Step 7b. Retained, but the fallback — not the default.

Never file on your own repo: the consumer's Step-7c manifest is push-only (never pulled by loom or the template), so an own-repo issue documents a problem nobody upstream ever sees — an orphan proposal. Never file on loom directly: that skips the USE-template-side review that catches variant-vs-global misclassification before it reaches every OTHER consumer.

coc-build — SDK code, cross-SDK-first

A bug / feature / code-improvement on SDK code is filed against the BUILD repo, which considers cross-SDK FIRST (does the sibling SDK share the shape / fix?), then originates a proposal via /codify Step 7a.

coc-source — loom Splits, Never Originates

loom acts only as the central splitter/distributor. It ingests externally originated proposals via /sync-from-build + /sync-from-use (Gate 1), splits global vs variant (human classify), and distributes via /sync-to-use + /sync-to-build. A triaged issue at loom is classified, never authored into a local artifact. A distributor that also originates has no upstream audit trail — the BUILD-repo or USE-template /codify proposal provenance is the only record of why an artifact changed.

Narrow exceptions (receipt-gated): loom MAY originate directly under the Co-Owner-Directed Origination carve-out (verbatim directive + receipt-first journal DECISION + COC-tooling scope) OR the O1 compliance-origination class (external standard cited down to version + clause, GOVERNING the artifact). Both substitute a durable provenance receipt for the missing proposal; details in rules/artifact-flow.md § "Co-Owner-Directed Origination" + "§ The Origination Taxonomy".

The Origination Taxonomy (O1 / O2 / O3)

Three legitimate origination paths, each carrying its own audit trail; "loom Splits, Never Originates" protects the AUDIT TRAIL, not the authorship location:

• O1 — compliance/standard → artifact, authored directly at loom (platform-engineer; receipt-first journal DECISION naming the external authority + version/clause as provenance).
• O2 — consultant artifact improvement → upflow (business-consultant; Step-7c proposal provenance, QUADRUPLE disclosure-fenced).
• O3 — SDK capability / bug → BUILD (capability-engineer; BUILD /codify proposal, cross-SDK-first).

Why The Durable Surface Is The Proposal, Not A Local Edit

NEVER hand-edit loom directly to "resolve" a triaged issue, and NEVER "fix" one by editing a synced artifact locally. A synced .claude/** artifact at a consumer is Class-A non-durable — it is REBUILT by the next /sync-to-use, so a local edit is silently overwritten. The proposal (/codify Step 7a/7b/7c) is the only durable surface: it carries the Gate-1 audit trail, survives the sync rebuild, and cascades to every consumer. A local artifact edit does none of these.

Cross-References

• rules/issue-triage-routing.md — the always-on routing MUST (the pointer).
• rules/artifact-flow.md § "Issue Routing By Change Type" / "Downstream-Consumer Routing" / "loom Splits, Never Originates" / "The Origination Taxonomy" — the authoritative mechanics.
• rules/knowledge-cascade-routing.md — the memory-vs-COC-artifact capture routing decision (a sibling routing rule, one layer in).
• guides/co-setup/09-proposal-protocol.md Step 7b — the proposal-origination target flow.