# Ponytail complexity audit — Fusion PPC orchestration system

Lane 4, Part 2. Skill invoked: `ponytail:ponytail-audit` (repo-wide scan, ranked biggest cut first,
lists findings and applies nothing). Read-only. Run **after** the two-axis code review so it sees the
integrated system.

**Scope boundary, enforced.** This is a complexity-only audit. Correctness, security, performance,
data integrity and UX are explicitly out of scope and are owned by other lanes. Nothing below is a
bug report. Where a complexity finding happens to sit next to a defect, the defect is cited by
reference to `matt-pocock-code-review.md`, not re-litigated here.

**Preservation constraint, enforced.** The accepted T1 evidence corpus is unique evidence: 12 files,
716 lines at
`outputs/loop-runs/20260830-fusion-ppc-architecture-orchestration/children/t1-evidence-corpus/artifacts/`.
It is never a deletion target. The ceremony around it is.

---

## Raw ranked output (verbatim)

```
delete: 32 of the 40 per-child control files - 8 children x {acceptance-ledger, access-ledger, run-state, launch-prompt}, 1,493 lines of bookkeeping around 8 goal files. One generated status table (~30 lines) + the existing parent access-ledger. [outputs/loop-runs/20260830-fusion-ppc-architecture-orchestration/children/*/]
delete: launch_child.py, 291 lines re-implementing the platform launcher minus the Slack post. Add --no-slack to ~/ops/run-in-cloud.sh (536 lines) - its :260-272 is BYTE-IDENTICAL Python to launch_child.py:41-53, and :226/:453 state_5.sqlite, :394 prompts/$SLUG.run.sh, :439 tmux new-session, :500 codex-app-sync.py decorate --pin true are the same calls. 16 slack references are the only real difference. [outputs/loop-runs/20260830-fusion-ppc-architecture-orchestration/launch_child.py]
delete: 153 of 186 rows in the T1 acceptance ledger - every T1-F-* row collapses to one template, identical but for a counter, evidence cell pointing at the same file. One row: "153 inventory items VERIFIED, see created-file-inventory.md". [children/t1-evidence-corpus/acceptance-ledger.md:34-186]
shrink: 502 duplicated lines across the 8 goal-v1.md files (1,445 total, 943 unique). One shared preamble file + per-child unique sections. [children/*/goal-v1.md]
delete: 5 competing sources of truth for one boolean "is T2 running" - run-state.md:25, child-registry.md:9, dependency-handoff-ledger.md:8, children/t2-measurement-audit/run-state.md:3, ~/ops/sessions/fusion-ppc-t2.json. tmux/git are the truth; derive the rest. [outputs/loop-runs/20260830-fusion-ppc-architecture-orchestration/]
native: child-registry.md + dependency-handoff-ledger.md, 40 lines hand-maintained. git branch --contains + tmux ls answer both questions in one command each, and cannot go stale. [child-registry.md, dependency-handoff-ledger.md]
delete: 7 idle git worktrees holding 10.5 GB for zero commits of work (t2-t7 all at 9f92003, t2 at a286b77, none carrying child artifacts). git worktree remove. [/home/matt/mirror/Fusion-ppc-children/]
delete: 16 stale run artifacts outliving the run - 8 ~/ops/sessions/fusion-ppc-*.json still claiming waiting_for, 8 ~/ops/prompts/fusion-ppc-*.run.sh. Launcher should clean up on terminal state. [~/ops/sessions/, ~/ops/prompts/]
shrink: 4 hand-rolled PPC dashboards/decks, 1,655 lines of repeated report logic for one client's data. One templated renderer + data. [deliverables/fusion-ppc-2026-07-30/public/deck.html:414, deliverables/fusion-ppc-council-2026-07-31/public/deck.html:489, ads-control/template/stage-3-ai-advice-review.html:168, deliverables/fusion-meta-ads-review-2026-08-24/index.html:584]
yagni: EFFORTS defines 6 reasoning levels, 2 ever used (medium x6, xhigh x2) and --model has exactly one value across all 8 launches. Inline the two, drop the flag. [launch_child.py:22,141,152]
yagni: status_meta() hardcodes a 4-step ladder every child gets identically, then never updates it. Drop it, or read the steps from the goal file. [launch_child.py:102-119]
delete: run_id built and stored, never read or printed anywhere. [launch_child.py:187,198]
delete: --codename flag whose only use is being substring-matched back out of the prompt it was written into. Match on session slug. [launch_child.py:137,171-173]
yagni: 9 CLI flags on a program hardcoded to one run - parent_task_id is a literal UUID, the title must start "[Fus] ↺" and end with one exact parent name. Either parameterise it or hardcode it, not both. [launch_child.py:154-156,201]
delete: the architecture goal frozen twice on two branches (638e7524 on the orchestrator branch, ce93cef on round-13-takeover, plus 975e6c3 on the child branches), byte-identical blob 2421c9e, no cross-reference. One freeze, one line. [see matt-pocock-code-review.md fixed-point receipts]
delete: __pycache__/launch_child.cpython-312.pyc on disk in the run directory. Gitignored already, so just noise. [outputs/loop-runs/20260830-fusion-ppc-architecture-orchestration/__pycache__/]
stdlib: hand-rolled TOML section editing by regex, 13 lines. tomllib to read + a small writer, or configparser-style round-trip. [launch_child.py:41-53]

net: -2,457 lines, -34 repo files, -16 ops files, -10.5 GB, -0 deps possible.
```

---

## Scoped interpretation

### What this system actually is

Stripped of vocabulary, the orchestration apparatus is a **to-do list with eight rows and a
launcher**. It is currently expressed as 61 files and 3,500 lines of control documents, plus a
291-line bespoke process launcher, plus 14 GB of worktrees, to produce and track 716 lines of
evidence.

The ratio is the finding:

| | Files | Lines |
| --- | --- | --- |
| Control and ceremony | 49 | 3,500 |
| Actual delivered evidence | 12 | 716 |
| **Ceremony share** | **80%** | **83%** |

Measured on the corrected range `ce93cef..round-13-takeover` (59 files, 4,010 insertions).

### Weighed against Matt's instruction

> "give me a more consice prompt. i need the 80/20. dont overengineer."
> — `01a04df6-2370-7071-a178-42aa9e3cad05`, T0006, line 107

The system inverted the ratio he asked for. He asked for the 80/20 and received a build that spent
83% of its output on the tracking of work rather than the work. Seven of the eight children carry a
complete five-file control package — roughly 2,800 lines of frozen contract, ledger, access register
and launch prompt each — and produced nothing at all.

The deeper point is not that the ceremony is verbose. It is that **the ceremony did not do its job**.
Five documents tracked T2's state and all five disagreed with the filesystem
(`matt-pocock-code-review.md`, SPEC-8). A single `tmux ls` was more truthful than the entire ledger
system. Bookkeeping that must itself be audited is not bookkeeping, it is a second system to
maintain.

### The 80/20 version of this system

Same guarantees, roughly 200 lines:

1. **One task table.** Eight rows: task, branch, status, dependency, artifacts path. Generated from
   `git branch --contains` and `tmux ls`, never hand-edited, therefore never stale.
2. **One goal file per child.** The unique 943 lines, not the 1,445 with a duplicated preamble.
3. **`~/ops/run-in-cloud.sh --no-slack`.** The platform already launches pinned Codex children with
   model and effort readback. Verified: `run-in-cloud.sh:260-272` is **byte-identical Python** to
   `launch_child.py:41-53` — same regex, same `trust_level` branches, same
   `tmp.write_text(text.lstrip())` and `chmod(0o600)`. This is a copy, not an independent
   implementation.
4. **The T1 corpus, untouched.** 716 lines, 12 files.

That is a 4-file-per-run apparatus instead of 49, and it deletes the class of defect the other lane
found, because a derived status table cannot claim `ACTIVE` while `tmux` is empty.

### Where the serial chain itself is the complexity

Not a file-count finding, but the largest structural one. `goal-v1.md:44-51` puts all three of
Matt's named deliverables at chain positions 3 through 8, behind two enabler tasks he never asked
for. Eight tasks, seven dependency edges, five ledger documents each, to deliver three artifacts.
One stall at stage 1 produced zero of three.

The 80/20 architecture is three parallel children reading the already-committed report package —
dashboard, strategy A, strategy B — with the evidence corpus as an optional enrichment rather than a
gate. Same three deliverables, no dependency graph, no handoff ledger, and no single point of
failure. That change alone deletes `dependency-handoff-ledger.md`, the `WAITING_DEPENDENCY` machinery
in all eight launch prompts, and the release-message protocol.

### What must NOT be deleted

Stated explicitly so this audit cannot be misread as license:

- **The 12 T1 artifact files, 716 lines.** Unique evidence, verified intact on the reviewed branch
  (`git diff 4459dfe b1013882 -- .../artifacts/` is empty). Includes the honest `UNAVAILABLE`
  markings that other lanes depend on.
- **The 8 child `goal-v1.md` files' unique content.** They are the only record of what T2 through T7
  were contracted to do. Collapse the duplicated preamble, keep the unique 943 lines.
- **`deliverables/fusion-ppc-2026-07-30/` and `deliverables/fusion-ppc-council-2026-07-31/`.**
  Pre-existing client deliverables. `AGENTS.md:47` is explicit: *"Do not remove unique evidence or
  client deliverables during cleanup."* The templated-renderer finding above is a
  build-the-next-one-differently note, not a delete-these note.
- **The three OUTSTANDING sentinels.** Stale, but the stop-gate reads them; `AGENTS.md:58-61`
  specifically warns against editing them to satisfy a validator.

### Realistic deletion estimate, concrete

| Target | Files | Lines | Other |
| --- | --- | --- | --- |
| Per-child acceptance/access/run-state/launch-prompt (8x4) | −32 | −1,493 | replaced by ~30-line generated table |
| T1 acceptance-ledger template rows | 0 | −152 | 186 → 34 lines |
| `launch_child.py` | −1 | −270 | replaced by a flag on the existing launcher |
| `child-registry.md` + `dependency-handoff-ledger.md` | −2 | −40 | derived from git/tmux |
| Duplicated goal preamble | +1 / −0 | −502 | shared preamble file |
| **Repo total** | **−34** | **−2,457** | |
| Idle worktrees (7 of 8) | | | **−10.5 GB** |
| `~/ops` session JSONs + runner scripts | −16 | | stale after the run ended |

**Manual steps removed:** the per-child freeze-and-hash ritual (8x), the dependency-release message
protocol (7 transitions), the per-child access preflight (8x), and the hand-maintained registry
update after every state change. Roughly **30 manual bookkeeping steps** collapse to one generated
table.

**Control documents removed: 34 of 49.** Evidence files removed: **0 of 12**.

### One honest credit

`launch_child.py` ships a runnable self-check (`:122-130`, `--self-check` returns `PASS`, exit 0) and
carries a correctly-formed `# ponytail:` comment at `:245` naming its ceiling and upgrade path. That
is the discipline working. The problem is not that the file was written carelessly. It is that it
should not exist — `~/ops/run-in-cloud.sh` already does this, its trust-config block is byte-identical
to the one here, and the only real difference is 16 Slack references that a flag could suppress.

*Verification note: worktree sizes measured with `du -sc` (t2 through t7 = 10,615,292 KB). Launcher
equivalence measured by reading both files, not inferred from naming.*

---

*Complexity only. No fixes applied, no files changed, nothing deleted. Correctness, security,
performance, data-integrity and UX findings belong to other lanes.*