the repair job closed 138 correctness findings and then, in writing, deferred the visual work, the performance work, and the scale work for "later." this is later. one hardening + scalability + accessibility + performance pass, run by ~20 agents working in parallel git worktrees, every lane integrated behind the same five-check gate, all of it shipped straight to prod.
the repair job left a 30-test pure-core suite and a 3.9→~6.5 self-scored app. this pass was about the dimensions a re-score doesn't flatter unless you actually do them: the unhappy paths now have tests, the dependency tree is clean, and the things you can see and feel — dark mode, mobile, render cost — got done.
next advisory only next@16 patches — out of scope under the no-Next-major rule, and documented, not ignored.each unit of work got its own git worktree and its own agent. disjoint file sets ran concurrently; anything that touched the same hot file (the client store, the api middleware, ColumnTasks, package.json) was serialized behind a single owner. nothing reached main without passing the same five checks — and every push auto-deployed.
one agent per lane in its own worktree; disjoint files run in parallel, contended files get a single serial owner.
rebase each finished lane onto main in dependency order. i own the join points.
between every merge, no exceptions:
push to main → vercel auto-deploys. 89 commits, live as they landed.
phase 0 stood up the safety net so everything after it could move fast without fear. phase 2 was the one part that had to be strictly serial: it rewrote the client state core, and the critical path ran through it.
running twenty agents in parallel is mostly throughput and occasionally a crime scene. the recoveries are the interesting part.
two background agents stalled mid-task — once on the selector rewrite, once on the lazy-load plumbing — leaving dozens of edited files uncommitted and no report.
recovery: commit their worktree state by hand, finish the missing edges (one dangling ref, a few un-threaded args, the tests they never wrote), and re-gate. after that, every agent was told to commit incrementally — so the next stall would cost nothing. it did stall again. it cost nothing.
the plan said clerk v5 → v7. then the peer ranges spoke up: v7 is Core 3, which drops Next 13/14 and requires next ≥ 15.2.3.
the hardening rule was explicit — no Next major. so v7 was off the table. v6.39.5 still supported Next 14, still pulled a patched js-cookie, and still cleared the @clerk criticals. it also made the next@14.2.35 patch a hard prerequisite, which lined up perfectly. auth() became async; the middleware learned to await.
the repair job left a fully-built dark mode unmounted. mounting it was one line — and revealed that the board surfaces were hardcoded bg-neutral-100, bg-white. a bright white column on a dark page.
the fix wasn't the toggle, it was the surfaces: convert hardcoded light colors to the shadcn semantic tokens that already had dark values, preserving the light theme byte-for-byte. then collapse the three-way switch to a plain light/dark toggle, because nobody asked for "system."
the audit's old roadmap listed bugs that the repair job had quietly already killed. re-fixing fixed code is how you add new bugs, so those got a guarding test instead of a patch — the verification without the risk.