Repository navigation
v1.6.0
This release changes who runs which checks. Before 1.6.0 every task ran the project's whole check inventory before committing. Now a task runs the checks that cover what it changed, widening to the project's checks when it touches shared paths, and integration and a fresh verify own the full inventory. An autonomous run whose verify fails can now attempt a bounded repair instead of stopping.
Performance mechanisms validated; elapsed-time improvement not yet established.
What's improved
- Tasks no longer run the whole suite by default. Before 1.6.0, every implementer ran the project's full check inventory before each commit, and so did every task fixer and the final fixer. Now a task runs the checks that cover what it changed. It falls back to the full suite only when it touches shared paths, changes files outside its brief, or the agent forces it.
- The full suite runs where it counts. Integration runs it once on the merged result, and verify runs it again, fresh, at the delivered head. Acceptance still reads only verify, so the final guarantee is unchanged.
- Fixers stay focused. Task fixers and the autonomous final fixer run the tests that cover their change, not the whole suite.
- A failing verify no longer has to end an autonomous run. Up to 2 bounded repair attempts, each followed by a fresh verify and a re-review, can fix a real check failure at the delivered head. Previously the run ended unaccepted and handed the failure back to you.
- Relaunches skip setup for finished lanes. A lane whose tasks are all done and reviewed no longer reruns its setup commands.
- You can see what ran. Each task check leaves an evidence file saying which checks it picked and why. Autopsy now counts task-check calls by selection, whole-suite runs by role, repairs and setup skips. The dry run summarises the check policy before launch.
Measured on sb1, the first real run (details under Testing). The same plan had been drafted for 1.5 with no lane commands, so on 1.5.2 every task would have run the full inventory.
- Measured: 26 of the 30 task checks were targeted, median 80 s, 2,286 s in all. The full inventory took 586 s at the start of the run and 869 s at verify.
- Estimated, not measured: had those 26 calls each run the full inventory at 586–869 s, they would have taken about 15,200–22,600 s. That is roughly 3.6–5.6 hours of check time not spent, summed across lanes.
- Estimated, not measured: on the run's critical path, 10 targeted calls took 985 s against an estimated 5,900–8,700 s at full-inventory cost, roughly 80–130 minutes. A different critical path, or five Unity suites contending at once, would change this figure. It is not a measured elapsed-time saving.
Highlights
task_checksin the manifest: per-task check lists, keyed by task id.testis required and non-empty; an absentlintorbuildinherits the lane's commands; a batch uses its last task's entry. Task checks are never part of the final inventory.widen_paths: paths whose changes make a task run the project's checks instead of its targeted list (shared contracts, configuration).scripts/task-checks: the workflow builds the call; the implementer runs it once before committing. It selectslane(no entry, as before 1.6.0),targetedorwidened, records every reason in order (no_entry,no_files,outside_files,widen_path,forced,git_failed), and writes evidence to<ledger>/checks/task-<unit>.<n>.json. The evidence is a record and a count: nothing reads it to accept, skip or reuse checks.- Check ownership: task fixers run focused tests; reviewers read the task-check evidence; integration runs the delivery inventory once; the final fixer runs focused checks in autonomous runs (every project command in supervised runs, as before); verify runs the full inventory at the delivered head, fresh, every time. The table is in reference.md, "Check ownership".
- Bounded repair after a failing verify (autonomous runs only): at most 2 per run (
repairs_spentcarries earlier launches'), only for a real failing exit at the verified head on a clean checkout (not a timeout or a signal), and only while enough agents are free for the repair, its verify and the re-review that must follow. Each repair is one Opus agent,verify repair <n>, followed by a fresh verify and a re-review of the repair. Supervised runs reject as before. - Setup skip: lanes with no pending work skip their setup commands on a relaunch; the report lists them in
setup_skipped. - Dry run: a
checkssummary (final inventory size, units with and without an entry,widen_pathscount, repair limit) and a warning when changes to shared files will not widen task checks. - Autopsy 5: new counters for task-check calls (by selection, reasons, failures), project test runs (whole-suite executions by role), repairs and setup skips. The legacy
full_suite_runsis kept. run-checks --descends-from SHA, used by repair to confirm the head it repaired.
Behaviour to know
- A task whose changes fall outside its Files list, or under
widen_paths, runs project-wide checks; an agent can force that with--force-full '<why>'. A lane whose setup differs from the project's widens to its own checks, since its worktree never ran the project's setup; integration still runs every check. - A break that crosses lanes and that no targeted list covers now surfaces at integration rather than in the task.
- Manifests without
task_checksbehave as before 1.6.0: every task runs its lane's checks.
Testing
node tests/run-tests.mjs: 1268 pass, 16 skipped, 0 fail on Windows locally; CI passed on Ubuntu (Node 22 and 24), macOS and Windows (Ubuntu Node 22: 1284 tests, 1279 pass, 5 skipped, 0 fail).- The Python-backed tests also pass on Python 3.8.20 (216 tests).
- First real run, sb1 (the maintainer's Unity 6 game, engine installed from the release branch before release): 24 tasks (3 prelude, 5 lanes, 4 join), 65 agents, one launch, 273 min, accepted; verify passed first time, so repair was not exercised. Measured from the run's evidence files:
- 30 task-check calls: 26 targeted (median 80 s, 2,286 s in all) and 4 widened (all prelude tasks touching shared Core paths, median 586 s, 2,328 s in all). The project's whole suite took 731 s at integration and 867 s at verify.
- Integration ran the full inventory once, and it passed first time. Verify ran it again at the delivered head and it passed.
- Fixers ran focused filters, not the whole suite.
- Not exercised in this run: repair (verify passed) and setup skip (the project has no setup commands).
- No speed percentage: sb1 has no matched run on 1.5.2 to compare with. One run cannot establish an elapsed-time gain.
Compatibility
- Additive manifest fields (
task_checks,widen_paths,repairs_spent); manifests without them run as before. - New report fields:
check_policy,setup_skipped,final.repairs. - Autopsy version 5; repair and setup counters read
unavailableon archives from older engines.
Upgrade
In your clone:
git pull && bash install.sh