bug(unic-archon-dlc): the re-entry idiom reads before it offers the choice, and Step 8 hardcodes names the Consumer overrides

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.

Start with docs/research/2026-08-31-dlc-run-2-findings.md, then inspect the /specs and /tickets command text, especially Step 2 and Step 8, along with config.yaml's project.branching setting. Clarify the re-entry decision and how Consumer naming conventions are declared; done means both commands no longer require manual overrides and their criteria match the artefacts produced.