flow-4-review

This is one round of an ongoing review, not a one-shot. We run it again and again until a round turns up nothing real, so this might be the first round (feature just built, I've done my manual testing) or the Nth (we've already found and fixed bugs in earlier rounds). Doesn't matter, the job is identical every time: find everything wrong with the current uncommitted code and fix it cleanly. Don't burn time re-establishing "where are we, is this fresh"; just read the current full diff (it already includes whatever got fixed in prior rounds), review all of it, fix what's real. The point is to keep the round count low, so cast a wide net each time. A round counts as the clean bill, and the loop ends, when it surfaces nothing real OR only non-functional findings (comments, doc lines, formatting, renames with no behavior change): comments cannot hide bugs, so a round that only polished prose is done, and dispatching another agent over it is pure waste.

Start by reading the full uncommitted git diff yourself, once. Most of this code is NOT in your context, so do not review from memory: you'll naturally over-focus on whatever you touched most recently, and the mandate is the entire uncommitted change, every file. Use the diff to carve the work into well-scoped slices that together cover everything with no gaps. You can bias one or two slices toward the riskiest or most recent work (earlier-round fixes are exactly where new bugs hide), but prior-round fixes get reviewed like everything else, no "already handled" status.

Then build every dispatch so the agent never has to find anything: give the exact file references, the files and line ranges of the slice, plus the context files to open around them. Do NOT paste diff hunks into the dispatch; repeating the diff through the prompt costs more context than the agent reading the named files itself. The agent reads the named files directly and never re-derives anything with git commands; the launcher scopes, the agents review.

Then launch all the review agents in parallel, in a SINGLE message with multiple agent spawns, all of them the code-reviewer agent. Never one at a time, never sequential; that wastes enormous time and is unacceptable. Do all your exploration first, decide the scoping for every agent, then fire them all at once. More well-scoped agents beats too few. Pass each agent ONLY the shape rules its slice touches (they don't share the project rules or MEMORY.md): the [decision framework]'s shape rules, DRY, SYNC markers, no fallbacks, naming. Do NOT pass the reply or punctuation rules: agent reports are internal working text, and style sweeps run by every agent are pure waste.

The agents are detectors: they return verified findings, precisely stated, and they don't run the full test suite (you already ran it). The findings are input to you; you hold the whole architecture and the full rules, they each saw a slice. So the design of every fix is YOURS. For each validated finding, before you write the fix, ask: does the architecture already expose the right mechanism for this (a registry, a trait, ConfigBag-style validation, the ctx capabilities)? If yes, connecting to it IS the fix; don't build parallel machinery. Past example: a node's input needed type-checking and ConfigBag already did all of it; the fix was routing through ConfigBag, not a new macro. And in this project the people who author nodes are the same surface that gets reused as the language: a fix that makes node authors hand-roll plumbing the language should provide via the ctx is a bad fix even when it works. Only build something new when nothing suitable exists, and even then reshape it clean per the [decision framework], never a patch.

Validate each finding before acting on it: is the issue real, or a deliberate choice the agent lacked context for? Discard the false positives, with the reason noted.

Shapes drift back. Before walking back any shape-changing finding, check whether that shape was a deliberate decision from an earlier round; existing comments tell you. Don't ping-pong the architecture between designs. And when you settle a shape, leave a comment saying why, so future rounds can tell deliberate from drift.

Once you've validated the findings, summarize for me below the --- line BEFORE fixing: non-trivial bugs get a bit of context (how it works now, where it would break) plus the fix you'll make, technical but clear, and don't assume I know every in-and-out of the architecture; trivial bugs get one line each so I can skim for anything that smells. The summary is informational, not a permission gate: do NOT ask "want me to proceed" when each bug has one obvious fix. Default to fixing everything in the same turn right after the summary. The only time to stop and ask is a genuine fork under [the fork rule]. "Non-trivial to explain" does not mean "needs my input"; a bug can take a paragraph to describe and still have one obvious fix.

Then fix everything, and two things matter equally: the fixes are clean reshapes, and they introduce no new bugs. Switch to [code mode] for the fixes. Reshape the base shape so the issue is impossible; sometimes the right fix really is wiring a connection or adding a guard, but minimize added hops. Stay DRY: if something will repeat, lift the parent; if there are twenty near-identical parents, unify them. No spaghetti. A 1000-line reshape that gives the right shape beats a 10-line dirty patch we'll regret. After any non-trivial fix, have a code-reviewer agent verify it does what you intend and introduces nothing new, and iterate until each fix is genuinely clean (they verify by reading, not by re-running suites). No shortcuts regardless of size.

This round ends when you've fixed everything real you found: run ONE em dash sweep yourself, over everything this round added (code comments, doc lines, commit messages, the summary below the line), then report this round's findings and fixes below the line, and we keep going. The sweep is yours, once, at the end; the agents never do it.