spike: per-repo routine capability detection — promote to its own topic

[kyle-sexton]

Phase 8 of the boris-routines-adoption plan. Independent of every other phase — it can run on any track.

Tier 0 item 3, and the clause the originating goal names verbatim: "configurable per repo/product/app based on the repo itself, any external context provided from CLAUDE.md, AGENTS.md, repo files, MCP servers, CLI tools."

Why this is promoted rather than planned inline

Three promotion triggers fire: its own exploration need (what each ecosystem's detection signal actually is), an independent commit boundary, and a >300 LOC estimate. Planning it inside the parent PLAN would make that document unscannable and deny this work its own clean-context boundary.

Work items

• Create docs/topics/routine-capability-detection/ and run /planning:interview then /planning:plan against it.
• Inputs it inherits rather than re-derives: the catalog's axes and mapping rules (plugins/autonomy/reference/routines.md:88-146); the three-layer config cascade (docs/conventions/config-cascade/); the deterministic-gate preference (docs/PLUGIN-PHILOSOPHY.md:664-666).
• This creates a second contract slice, red-lined by the same gate as the parent. It matches no line in scripts/contract-slice-baseline.txt and cannot be exempted — the baseline is read from the base revision. The promoted topic owes its own graduation-and-prune before its own merge. That is the convention's ordinary per-slice lifecycle, not a special case.

Sanity checks

• ls docs/topics/routine-capability-detection/PLAN.md exits 0, and awk '/^## Brief/{f=1;next} f&&NF{found=1;exit} END{exit !found}' docs/topics/routine-capability-detection/PLAN.md exits 0.
• That PLAN carries a terminal graduate-and-prune phase — grep -qi "check-contract-slice-prune" docs/topics/routine-capability-detection/PLAN.md.

Related

• Blocks a layering-enforcement detector, whose class membership is not decidable until per-repo rules exist