capture: a Cadence-directed capture from inside a host project, so field friction reaches Cadence's own queue #96

New issue

Closed

opened 2026-08-08 23:14:12 +00:00 by john · 0 comments

john commented

2026-08-08 23:14:12 +00:00

Owner

Cadence runs on ten projects. Almost none of that use reaches Cadence.

The gap

/cad-capture writes to the CURRENT project's .planning/CAPTURE.md, which is correct for domain work and wrong for the one case it cannot express: friction with Cadence itself, noticed while using Cadence on something else. That note either lands in the host project's queue - where it is noise the host's triage will archive as out of scope - or it is not written at all.

Measured 2026-08-08 across the live projects: 135 open capture items in hindsight (82), assistant (28) and burnrate (25), of which 5 lines total mention Cadence at all. Ten projects of real field use, five of them tagged and shipped, producing essentially no Cadence feedback.

Why it matters more than it looks

The consequence is visible in Cadence's own roadmap. v2.2.0 the residue, v2.3.0 where the bytes live, v2.4.0 the parallel path, v2.5.0 what Cadence says about itself, v2.6.0 the reconciliation cycle - five consecutive cycles scoped from Cadence auditing Cadence, because that is the only feedback loop that reliably closes. FRI-01/FRI-02/FRI-03 exist because the maintainer hit them by hand and remembered, not because any mechanism captured them.

A tool used on ten projects should have its roadmap set by what is annoying on those ten projects. Right now it is set by what a self-audit finds.

Sketch, not a design

Something like /cad-capture --cadence <text>, appending to Cadence's own queue rather than the host's, carrying the host project and the command that provoked it. The interesting questions are the ones a plan has to answer: where the target queue lives when Cadence is installed as a plugin rather than checked out (${CLAUDE_PLUGIN_ROOT} is a read-only cache), what happens when the maintainer is not the user, and whether a capture that crosses a project boundary should be redacted the way EVD-01 redacts a run record.

Not v2.6.0. That cycle is full and the last two phases are already scoped.

Cadence runs on ten projects. Almost none of that use reaches Cadence. ## The gap `/cad-capture` writes to the CURRENT project's `.planning/CAPTURE.md`, which is correct for domain work and wrong for the one case it cannot express: friction with Cadence *itself*, noticed while using Cadence on something else. That note either lands in the host project's queue - where it is noise the host's triage will archive as out of scope - or it is not written at all. Measured 2026-08-08 across the live projects: 135 open capture items in `hindsight` (82), `assistant` (28) and `burnrate` (25), of which **5 lines total** mention Cadence at all. Ten projects of real field use, five of them tagged and shipped, producing essentially no Cadence feedback. ## Why it matters more than it looks The consequence is visible in Cadence's own roadmap. `v2.2.0` the residue, `v2.3.0` where the bytes live, `v2.4.0` the parallel path, `v2.5.0` what Cadence says about itself, `v2.6.0` the reconciliation cycle - five consecutive cycles scoped from Cadence auditing Cadence, because that is the only feedback loop that reliably closes. `FRI-01`/`FRI-02`/`FRI-03` exist because the maintainer hit them by hand and remembered, not because any mechanism captured them. A tool used on ten projects should have its roadmap set by what is annoying on those ten projects. Right now it is set by what a self-audit finds. ## Sketch, not a design Something like `/cad-capture --cadence <text>`, appending to Cadence's own queue rather than the host's, carrying the host project and the command that provoked it. The interesting questions are the ones a plan has to answer: where the target queue lives when Cadence is installed as a plugin rather than checked out (`${CLAUDE_PLUGIN_ROOT}` is a read-only cache), what happens when the maintainer is not the user, and whether a capture that crosses a project boundary should be redacted the way `EVD-01` redacts a run record. Not v2.6.0. That cycle is full and the last two phases are already scoped.