One change through review

PR #215, merged on 19 July 2026, is one real change through Flow-Next’s own development, followed here from requirement to the correction review produced. The recorded run was a planned autonomous run in July 2026: two tasks, the codex review backend, and it predates Flow (5.0.0, September 2026). Nothing on this page was routed by Flow; the last section shows where Flow’s decisions would appear on a change like it today.

The change and its evidence

flowctl list and flowctl status took about 30 seconds on a repository with 100 specs and 403 tasks, because task loading spawned two uncached git rev-parse subprocesses per task. Spec fn-109 called for memoizing those lookups and batching the export’s git grep fan-out while preserving every result. The PR reports flowctl list --json at 0.48 seconds against a 30.8-second baseline and flowctl status at 0.41 seconds against 32 seconds, with 809 git subprocess spawns per list collapsed to 2.

The central example on this page is the correction review forced on the batched search, where a forced-color Git configuration broke the parsing that recovered per-symbol attribution.

Give Flow the performance request

Illustrative only; this is what a reader would hand Flow today for a change like this one. The performance row routes on a measurement, so the request names the baseline and the behaviour-preservation constraint:

flowctl list --json takes 30.8 s and flowctl status 32 s on this repo (100 specs,
403 tasks). Get both under 1.5 s. Memoize the repo-root and state-dir lookups and
batch the export's git grep calls. Every existing result, including per-symbol
attribution and ordering, must stay byte-identical.

Flow would baseline on the real surface first, make the baseline and target the requirement, and treat the post-change measurement as the evidence. Without the numbers, the request is an unmeasured slowdown and routes to investigation first.

The requirement

R8 required the batched git grep to issue at most 2 invocations for 40 removed symbols (down from 40) while keeping the same per-symbol attribution, ordering, and reference limits as the sequential implementation. That gave review something more precise to check than whether the CLI felt faster.

What review caught

The review found that a user’s forced-color Git configuration (color.grep=always) wraps matches in SGR escape sequences even when the output is piped. The escape’s trailing m is a word character, so the word-boundary regex that attributed each line to a symbol failed on coloured text and silently dropped references the sequential implementation had kept. That violated R8.

The correction adds --color=never to the batched git grep invocation, so the attribution regex runs on the exact bytes Git matched. The review-round fix is a separate commit, so a reader can inspect the correction directly.

What the checks establish

Two kinds of evidence sit on this PR, and they answer different questions.

Correctness, tied to R8. The task record carries the NEEDS_WORK finding and the fix through SHIP. On ordinary output, a sequential-oracle parity test asserts the batched result matches the earlier per-symbol implementation byte for byte. Under forced colour that equality is impossible, because each per-symbol grep coloured only its own match on a shared line, so the correction commit’s regression test, test_forced_color_grep_refs_survive, sets color.grep=always on a fixture repository, strips the escape sequences from the oracle’s output, and asserts that every reference survives and that snippets are raw file bytes. The full suite (1858 tests) and the smoke tests (144) ran green at the fix.

Performance, separate from correctness. The timings above are measurements on one repository at one size. They establish that R1 and R2 were met on that surface; they say nothing about attribution, which is what the parity test and the regression test establish.

These are historical results from that change. Installation paths and test counts in the linked records are evidence of that run, not instructions for a current install.

What reached the human reviewer

The PR body maps all ten acceptance criteria to their tasks and evidence commits, lists the verification commands per task, and separates what the pipeline verified from what needs a person. Its review plan puts the correction commit in the must-review bucket with one question: does --color=never fully neutralize the forced-color configuration for the batched grep parse? The reviewer can follow the important change without rediscovering why it exists.

Question	Where the answer lives
What behaviour must stay true?	Spec R8
What did review find?	The task record and the correction commit 17f3c3c
How was the fix checked?	The parity test and test_forced_color_grep_refs_survive
What should a human inspect?	The PR’s requirement coverage and its must-review question

Where Flow shows up on a change like this today

Flow would record the route on the spec before anything ran, and the report would carry one stage: line each for work and make-pr, with the QA skip and its reason beside them; the 30.8-second baseline and the 0.48-second result would sit on the task’s evidence, measured by work before and after the change. Today it would be one spec built inline in the conversation, with no plan, and as a multi-file change to persisted state lookups it would get three reviewers from another model family. Work would run with that review inside it, and the run would stop with the change committed on a local branch; after you said “open the PR”, make-pr would open it ready for review. The finding, the fix commit, the receipt, and the R-ID mapping would be the same artifacts, with the route decision one more line in the trail. A later Flow run on the open PR would offer landing and ask once, unless you had already authorized the merge. To drive the same stages by name, start from the skills index.

Try the workflow yourself or read the receipt formats.