Development record
The delivery pipeline abcd runs on itself is hand-orchestrated and should be deterministic. This session hand-ran the full sequence: SOTA research -> itd-84 decomposition -> draft intent -> TWO independent adversarial reviews (design/feasibility + record-discipline) -> planning interview -> plan+spec -> test-first implementation -> TWO more adversarial reviews of the diff (ruthless + security) -> apply/refute findings -> gates (preflight, record-lint) -> atomic commits + PR -> resolve the ledger issue with provenance -> seed the deferred items back into the ledger. Every hand-off, gate, and review-pair was driven by judgement, not a deterministic harness. The individual stages already have records — itd-83 (the review bar fires itself), itd-84 (decompose before filing), itd-82 (ledger drain), itd-78 (intent-dependency graph) — but ALL are drafts/staged and NONE composes the others into one orchestrated pipeline. Honest constraint (loud-staging): the pipeline cannot be MORE automated than its stages, so full automation waits on those disciplines shipping; but the deterministic SCAFFOLD — the fixed stage order, the mandatory review-pair gate before plan and before merge, the hand-offs to the host for the human-in-the-loop steps, the ledger-seed-the-deferrals close-out — can be built now as a workflow/routine (itd-107 versioned-routine-template is the nearest delivery vehicle). Routing note: this is a big, cross-record idea, not a decomposed intent — it likely needs /abcd:ideate then itd-84 decomposition before it becomes filable, and it may reshape rather than duplicate itd-83/82/78.
The delivery pipeline abcd runs on itself is hand-orchestrated and should be deterministic. This session hand-ran the full sequence: SOTA research -> itd-84 decomposition -> draft intent -> TWO independent adversarial reviews (design/feasibility + record-discipline) -> planning interview -> plan+spec -> test-first implementation -> TWO more adversarial reviews of the diff (ruthless + security) -> apply/refute findings -> gates (preflight, record-lint) -> atomic commits + PR -> resolve the ledger issue with provenance -> seed the deferred items back into the ledger. Every hand-off, gate, and review-pair was driven by judgement, not a deterministic harness. The individual stages already have records — itd-83 (the review bar fires itself), itd-84 (decompose before filing), itd-82 (ledger drain), itd-78 (intent-dependency graph) — but ALL are drafts/staged and NONE composes the others into one orchestrated pipeline. Honest constraint (loud-staging): the pipeline cannot be MORE automated than its stages, so full automation waits on those disciplines shipping; but the deterministic SCAFFOLD — the fixed stage order, the mandatory review-pair gate before plan and before merge, the hand-offs to the host for the human-in-the-loop steps, the ledger-seed-the-deferrals close-out — can be built now as a workflow/routine (itd-107 versioned-routine-template is the nearest delivery vehicle). Routing note: this is a big, cross-record idea, not a decomposed intent — it likely needs /abcd:ideate then itd-84 decomposition before it becomes filable, and it may reshape rather than duplicate itd-83/82/78.
Grounds
- declined: itd-2609201916151817 carries what this seed asked for; this would be wrong if that intent were superseded without a successor that orchestrates delivery
Frontmatter
| id | iss-381 |
|---|---|
| type | issue |
| lifecycle | wontfix |
| severity | major |
.abcd/work/issues/wontfix/iss-381-deterministic-delivery-pipeline.md
open on GitHub ↗ · commit history ↗
mentions7
- iss-2608210932052003abcd launches autonomous bug hunts (and other routines) for the user, opt-in — beyond handing the user a prompt to paste into a cloud routine. Today the bughunt is a Desktop prompt the user wires into an external cloud routine by hand; the direction is abcd owning the launch: the user opts in, and abcd assembles and starts the routine, applying the run contract it already governs (the human git identity per itd-131, the gates, the merge decision, the state issue). This is the realisation of the run seam — adr-27 (run is a pluggable seam, not a bespoke engine), itd-29 (the run operator surface: start/status/pause/resume/ship), itd-107 (routines assemble from one versioned template; the bughunt and a delivery-pipeline archetype), and the reframed iss-381 (the deterministic delivery pipeline survives as an itd-107 archetype, not an engine). When abcd launches the routine it sets the human git identity at launch, which is the clean mechanism the itd-131 identity gate points at for routine commits (vs today's prompt/env workaround). Big, cross-record capability — needs decomposition and likely ideate before it is filable; recorded so the direction is durable.
- itd-78abcd Knows What to Build First — Even When It's Something Small
- itd-82`abcd drain` fixes the issues that need no decision, and hands the rest back by kind
- itd-83The Review Bar Fires By Itself, In Every Repo abcd Manages
- itd-84An Intent Is Decomposed Before It Is Filed, And A Reversal Is Only Ever Flagged
- itd-107Autonomous Routines Assemble From One Versioned Template
- itd-2609201916151817One verb takes a READY intent to delivered, and refuses while a decision is open