Session Retro — S264 (main-track O-of-O)

The first session retro, written at S264 close as a working proof-of-concept for the retro habit Liam ratified (dossier §4.G). Format = the six categories. ID-48 {48.1} will decide the canonical surface (JSON ledger + mirrors vs Mempalace diary) and may migrate this.

Session: S264 · 2026-05-25 · main-track orchestrator-of-orchestrators · origin 63644534 → 1b85dcae

1. Bugs discovered

Stale-base cherry-pick on task-list.json — cherry-picking the id32 worker’s ledger commit conflicted because the worker forked at S262 and main advanced through S263. git diff main..worker showed 17,086 deletions (S263’s mirrors the worker never had) — a blind merge would have reverted S263.
task-view sibling clone broken — /Users/liamj/Documents/development/task-view was 1 commit ahead of the v0.1.0-task-view tag and missing react/jsx-dev-runtime; it could not run --check. (Pre-existing, not introduced here.)
Stale worker ledger records fail the current schema — ID-47 (worker-authored) was missing commit_refs/session_refs/priority_note/updatedAt/status_note and used cross_doc_links.text instead of .raw (DocLinkSchema = {path,anchor,raw}). The new ID-48 record hit the same status_note-missing trap.
Carried (systemic, central to ID-48): ID-32 B4 (defineRoute double-wraps the 178/193 handlers that return NextResponse) + ID-28 fictional bind_target.

2. Failed assumptions

“The id32 delta is just the research doc.” The S263 continuation said so, but the worker had advanced 2 further commits (closed 32.14/15/20/21/22, added 32.23 + ID-47). Lesson: a live worker’s branch moves after the handoff was written — re-read its tip.
“The cmux daemon is down.” The probe returned empty — but only because it ran inside the sandbox. The daemon was UP; cmux + git worktree ops just need dangerouslyDisableSandbox.
“Worker ledger records are schema-current.” They were authored against an older schema.

3. Architecture / design decisions

Worker-branch-only merge model reaffirmed (S262 pivot): workers commit to their own branch; the parent O-of-O integrates at teardown. The workflow-orchestration skill may still describe cherry-pick-to-main — the brief’s merge-cadence block is authoritative.
HEAD-based python transaction for ledger merges, over fragile cherry-pick conflict resolution — base on git show HEAD:, splice the wanted records, guarantee zero regression.
Preserve-via-tags before teardown — s262-32.16-acceptance-gate (the gate test 32.27 needs) + s262-id32-worker-final (the saga journal + reusable codemod mechanics).
ID-48 paired with ID-23, not merged — ID-48 = process/eval axis; ID-23 = tooling axis.

4. Rejected approaches

Blind branch-merge of the id32 worker → rejected (would revert S263’s 17k deletions); used surgical file-checkout + python ledger merge instead.
Bulk orphan-worktree deletion → rejected (5 of 15 hold unique ID-20.12 + ID-44 commits); deferred with a per-worktree verdict.
Deploying the 4 parallel feature terminals this session → rejected by Liam (pivot to prepare-for-next-session); torn down immediately after launch.

5. Workflow improvements

The whole ID-48 initiative — root the SDLC workflow in validate-reality-before-spec’ing (two independent blind-spec-execution failures = systemic), continuous real-corpus probing, non-vacuous ACs, and this retro habit.
All 5 cmux briefs now carry a workflow-discipline block + the worker-branch-only model.
Recoverable misstep, fast: I launched the 4 terminals before Liam’s “don’t deploy this session” message had landed, then tore them down cleanly within one turn (0-commit branches → clean delete). The lesson for the O-of-O: heavy/expensive fan-out deserves an explicit go even when the topology is pre-authorised — the cost of a beat is lower than the cost of a launch-then-revert.

6. Unresolved questions

workflow-evaluator form — agent / skill / combo? ({48.1})
Checker-mandate matrix — which task-types require a Checker vs OQ-surfacing-only (e.g. {N.1} RESEARCH)?
/code-review (ex-/simplify) — replace /code-simplification, or run both?
Retro surface — extend the Mempalace diary, build the JSON 4th-ledger surface, or both? (This doc is the precursor.)
ID-48 ↔ theme-10 roadmap linkage — linked_tasks[] not yet reconciled (curator).
Efficiency metrics — what does the evaluator measure (token usage, duplicated reads, redundant dispatches, megaturn detection)?