Recording the starting point in Sprowt Harness

I added an Evidence Workbench in the terminal so I can inspect that starting point alongside the current changes, checks and review.

The reviewer already existed in the previous post. It now has to account for every unresolved finding from earlier rounds. Review was optional before; publishing now requires passing combined checks and a clean review of the current source, including updates to an existing PR.

Record the starting point before editing#

An accepted plan can include an environment recipe, with .sprowt/environment.json providing a project default. The controller runs setup, checks that the required tools work and then runs baseline commands. Failed setup stops editing. A failing baseline is saved and can become part of the repair work.

A test can fail because a tool is missing, because the project already fails it, or because the worker broke something. I now keep the preparation, baseline and final results separately so I can compare them.

Setup can be reused when its recipe, declared inputs, common manifests and lockfiles, and sandbox version still match. The required tools are checked again in the current VM and worker HOME. If that fails, setup gets one retry.

Baselines are deliberately outside that reuse rule. The implementation runs them for each attempt:

1            // Baselines run once per attempt; saved results are evidence, never a final-check cache.
2            receipt.baseline =
3                self.environment_commands(&recipe.baseline, cancelled, "baseline", &mut progress)?;
4            Ok(receipt.summary())

Each receipt keeps the commands, output, source fingerprint and errors. If preparation changes source or lockfiles, the harness preserves those edits and pauses. Setup should prepare dependencies without quietly changing the code being checked.

A finding stays open until it is dealt with#

Each finding now keeps an ID, such as R1, together with its evidence, repair attempts and the decisions made about it. A fresh reviewer receives the earlier findings and has to account for every open one.

The ledger rejects an incomplete report:

1    if issues.iter().any(|i| i.open() && !seen.contains(&i.id)) {
2        return Err("Review omitted an unresolved finding. Reassess every open ID; omission is not resolution.".into());
3    }
4    if report.status == "clean" && issues.iter().any(Issue::open) {
5        return Err("Review cannot pass with unresolved findings.".into());
6    }

Leaving R1 out of the next response cannot close it. Neither can quietly changing an open defect into an informational note. Dismissing it needs a reason and evidence against it. Closing it as fixed requires an attempted repair and passing results for its named regression checks on that version.

An uncertain finding needs investigation before repair. Another authorized repair pass requires progress: findings must close while confirmed work remains. No progress, uncertainty or using both passes sends me back to “Revise repair plan”. Repairs run one owner at a time.

Inspecting the current attempt#

The new Evidence Workbench makes these distinctions visible in the terminal. I can select Environment to read the preparation receipt, Checks to see command output, or Review to inspect a finding and its proposed fix.

“Latest update” belongs to the current attempt. A worker's earlier completion message stays in history when that task is reopened. Its original task checks remain distinguishable from later verification of the combined source.

Saved findings remain inspectable without implying that the current reviewer reported them again. Failed checks appear first, while passing command output can be expanded. “Work saved locally” has its own meaning, separate from passing checks or publishing to GitHub.

I can inspect a finding without starting a repair, or open the PR stage without publishing. Those actions have explicit controls. My composer draft survives navigation and resizing.

Combined-check failures now have a “Fix failed check” action that returns the command and output to the original owner with the latest combined source. Completed peers are preserved, but the repaired task and all combined checks must run again.

Keeping instructions and publication tied to evidence#

The harness now ships pinned role instructions with the build and supplies them to new and resumed agents. They live in read-only copies outside the worktrees. Startup does not fetch upstream instructions.

A dedicated writer now turns the reviewed diff and request into a short commit title and PR summary. This excerpt from the prompt reserves verification claims for the controller, shown as prompt text:

1Use concrete language. No hype, boilerplate, self-praise, agent attribution, exhaustive file lists, or invented benefits.
2Do not claim tests, review, deployment or performance results: verification is appended by the controller.
3Large diffs have marked excerpts. Describe only evidenced changes; do not infer omitted behavior.

The controller appends recorded check counts and review state. Changes to the source, base, request or publication state invalidate the cached draft. I still preview and confirm publication.

The model can still give a convincing but wrong explanation. Keeping its instructions and evidence does not settle that. What I can now inspect is what ran before editing, what ran afterward and what happened to each finding between attempts.