The re-entry idiom reads before it offers the choice
/specs Step 2 and /tickets Step 2 carry the same shape: detect → read → summarise → ask.
"Check whether <ARTIFACTS_DIR>/<SLUG>/PRD.md already exists. If it does, this is a re-entry. Read it, summarise it back, and ask whether to revise it or start over — never silently clobber an existing PRD."
The read happens before the choice it is offered for. So both branches are chosen by an agent that has already read the previous artefact, and a second run over an existing PRD cannot be unanchored by picking "start over".
Measured against plugin 0.26.0, gitCommitSha 348f2319. It is a property of the command text, so it holds in every repository.
Run 2 worked around it by deleting PRD.md and issues.json on the branch before invoking, in two commits. That works, and it is not something a command should require an operator to know.
Step 8 hardcodes names that do not fit the Consumer
The branch name. Step 8 prescribes feature/specs/<slug>. The Consumer's documented convention is feature/<WI#>_<slug>. It was overridden in both runs — run 1 used feature/42981_specs-profile-card-take3, run 2 feature/43004_profile-card — and in run 2 the override was necessary rather than stylistic, because a branch cut from develop would have restored the artefacts the setup commits had just removed.
Two overrides across two runs is evidence that the default is wrong, not that the operators were difficult.
The pull-request title. The gate hardcodes plan(<SLUG>): PRD and ADRs, naming an artefact run 2 did not produce — no ADR crystallised. An accurate title had to be written by hand.
The open question, to be grilled before criteria
For re-entry: should the command detect and ask before reading, or should re-entry be an explicit argument rather than something inferred from the filesystem?
For the names: where does a Consumer declare its branch convention, given config.yaml already carries project.branching?
Full evidence: docs/research/2026-08-31-dlc-run-2-findings.md.
The re-entry idiom reads before it offers the choice
/specsStep 2 and/ticketsStep 2 carry the same shape: detect → read → summarise → ask.The read happens before the choice it is offered for. So both branches are chosen by an agent that has already read the previous artefact, and a second run over an existing PRD cannot be unanchored by picking "start over".
Measured against plugin 0.26.0,
gitCommitSha 348f2319. It is a property of the command text, so it holds in every repository.Run 2 worked around it by deleting
PRD.mdandissues.jsonon the branch before invoking, in two commits. That works, and it is not something a command should require an operator to know.Step 8 hardcodes names that do not fit the Consumer
The branch name. Step 8 prescribes
feature/specs/<slug>. The Consumer's documented convention isfeature/<WI#>_<slug>. It was overridden in both runs — run 1 usedfeature/42981_specs-profile-card-take3, run 2feature/43004_profile-card— and in run 2 the override was necessary rather than stylistic, because a branch cut fromdevelopwould have restored the artefacts the setup commits had just removed.Two overrides across two runs is evidence that the default is wrong, not that the operators were difficult.
The pull-request title. The gate hardcodes
plan(<SLUG>): PRD and ADRs, naming an artefact run 2 did not produce — no ADR crystallised. An accurate title had to be written by hand.The open question, to be grilled before criteria
For re-entry: should the command detect and ask before reading, or should re-entry be an explicit argument rather than something inferred from the filesystem?
For the names: where does a Consumer declare its branch convention, given
config.yamlalready carriesproject.branching?Full evidence:
docs/research/2026-08-31-dlc-run-2-findings.md.