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 <tmp>` -> "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.
