step.6.diff.txt -- narrative retro for step.6 (U3.9a: first execution-kind DAG instance) Executed: 2026-07-18, same day as the skeleton. Companion artifact: step.6.gdiff.txt (automated, scripts/step_gdiff). Unlike step.5 (pure verification of inherited content), this step authored something that never existed before -- b3ubot's own first use of a workflow kind the substrate had never actually carried. ## Plan vs actual Followed the skeleton exactly, with zero deviations worth a table -- worth noting on its own, given every other execution step this session (2 through 5) found at least one live surprise. The difference here: step.6's entire risk surface was pre-verified at DRAFTING time (the grammar read in full, a real instance read in full, the SQL schema's "no CHECK constraint" confirmed directly, the OO API's exact field names confirmed directly, the canonical-form workflow read from `instances/README.md` before writing a single line) -- there was no code to "run and see what breaks" the way step.5's inherited fork had; there was only content to author against an already-proven, already-understood substrate. The one genuine uncertainty (would the hand-drafted file already be canonical, or need real cctdag-driven reformatting) resolved cleanly: the draft matched the unload output byte-for-byte on the first attempt. ## Gate evidence ``` +------+---------------------------------------------------------------------+ | G1 | `cctdag load execution_example.dag --db ` -> "loaded 1 dag(s) | | | ..."; `cctdag list` shows `execution_example`. | | G2 | `diff` between the hand-drafted file and the `cctdag unload` output | | | -> empty (byte-identical, zero reformatting needed). A SECOND | | | load/unload pass on the canonical file reproduced it again, | | | unchanged (the 2-pass property, checked independently of the | | | regression suite's own npass leg). | | G3 | Matrix leg: `exec_example | OK | OK | OK | OK | 4-way`. | | G4 | Npass leg: `exec_example | 1/4/3 | 1/4/3 | PASS` -- the counts | | | (1 dag, 4 nodes, 3 edges) match exactly what was authored, not an | | | approximation. | | G5 | Quirks leg: `exec_example | PRESENT | ABSENT | PRESENT | baseline` | | | -- identical landscape to every other corpus; the new, smaller, | | | differently-shaped instance introduced no new SCB walker quirk. | | G6 | Full cascade: "10 subproject PASS, 0 subproject FAIL, 0 SKIP" -- | | | unchanged subproject count (confirming this step added a CORPUS, | | | not new subproject machinery), regression leg now shows 7 corpora | | | everywhere (matrix/npass/quirks headers all list exec_example). | | G7 | `git status --short` after staging: every changed path under | | | `dag/` -- zero touches to `app/`, `adapters/`, `tests/`. | | G8 | `make test`: 38 passed / 8 skipped, byte-identical to step.5's own | | | closing baseline. | +------+---------------------------------------------------------------------+ ``` ## Findings for later steps 1. **A well-researched skeleton for an AUTHORING step can be complete in a way a well-researched skeleton for a VERIFICATION step of inherited code often can't be.** Step.5's research (reading the inherited scripts) could not discover bugs that only manifest at runtime, because the bugs lived in code nobody wrote this session. Step.6's research (reading the grammar, the schema, a real instance, the OO API) COULD be complete, because there was no pre-existing hidden state to be surprised by -- every fact needed to author correct NEW content was available by inspection, in advance. The general lesson: "verify something old" budgets for surprises; "author something new against fully-documented rules" can legitimately budget for zero, if the research was thorough enough first. 2. **Grounding illustrative content in something REAL (step.4's actual `ask` flow) rather than an invented scenario paid off immediately and will keep paying off.** Every node's `path` field points at an actual file:function that actually exists and actually does what the node's `description` says -- meaning this instance isn't just grammatically valid, it's SEMANTICALLY accurate to the one real execution-shaped thing in this codebase. When P3's real orchestrator eventually needs to know what a compiled execution DAG should look like, this file is a real reference, not a plausible-looking fiction. 3. **Deliberately omitting `oracle_gate` (rather than inventing a placeholder) is the same "honest interim" discipline this whole project runs on, applied to DATA instead of code.** A 5-node version WITH a fake oracle_gate node would have looked more "complete" but would have silently implied an oracle tier exists when it doesn't. The 4-node version is less impressive and more honest -- and the README's own scope section says exactly why, so nobody has to guess later. 4. **Registering in `corpora_list()` instead of writing a bespoke smoke script is the same "promote to regression forever, don't duplicate" discipline this project applies elsewhere** (see `feedback_promote_inner_circle_to_regression` -- this is the inverse direction: recognizing an EXISTING general mechanism already covers what a new bespoke one would, and choosing not to add the bespoke one, rather than promoting an ad hoc check into a permanent suite). ## Numbers ``` +--------------------------------------+----------------+ | new DAG kinds proven | 1 (execution) | | nodes / edges authored | 4 / 3 | | regression corpora (was 6, now) | 7 | | hand-draft vs canonical-form diff | 0 bytes | | new subprojects / new app/ code | 0 / 0 | | BUILD commit 289fd50 | 3 files, +94 | | | -4 | +--------------------------------------+----------------+ ``` U3.9a done -> the workflow DAG substrate (design.md §2.13) has now proven BOTH halves of its job: the inherited bootstrap kinds (step.5) and b3ubot's own planned extension (this step). P3's future orchestrator (U3.1 onward) has a real, working reference for what an execution DAG looks like, whenever it's built. Ledger updated in this RETRO commit per the §0 execution contract. End of retro.