Status
Open, not done: it waits for real use. Read again on 2026-10-05. The defaults named here still stand: max_autonomous_passes is 3, and since #40 the same ceiling bounds the reworks in planning; surface-status gate runs the project's full gates; every slice, review and fix gets a fresh agent.
The evaluations (#58) already read part of the list below from the journals and the streams, on a synthetic host with a model in the developer's place (evals/surface_evals/measure.py): the outcome and the reason of a hand back, the passes in planning, the reviews and the count of their findings, the fixes, the failed gate runs, the cost of a run. They do not split the findings by class, do not time the gate runs, do not split the cost by command, and say nothing of real use. Their reader of journals is a place to start from for the aggregate proposed below.
What to measure
The chain's defaults were set before any real use: three autonomous passes, full gates run by the script at every pass, a fresh agent for every slice, review and fix. Once projects use it, measure per plan:
- the passes used, and the stops by cause (conformant, ceiling, break, alarm, refusal);
- the review findings by class (defect, deviation, break), and the breaks the developer accepted or refused;
- the gate runs, their duration and their share of the loop's time;
- the cost and the duration of each command.
Most of it can be read from the journals and reports the plans leave on the main branch; a surface-status subcommand could aggregate them.
Then revisit the defaults with the numbers: the passes, the gate runs at every pass (their commands are found at planning since #18), the fresh agent per step.
Status
Open, not done: it waits for real use. Read again on 2026-10-05. The defaults named here still stand:
max_autonomous_passesis 3, and since #40 the same ceiling bounds the reworks in planning;surface-status gateruns the project's full gates; every slice, review and fix gets a fresh agent.The evaluations (#58) already read part of the list below from the journals and the streams, on a synthetic host with a model in the developer's place (
evals/surface_evals/measure.py): the outcome and the reason of a hand back, the passes in planning, the reviews and the count of their findings, the fixes, the failed gate runs, the cost of a run. They do not split the findings by class, do not time the gate runs, do not split the cost by command, and say nothing of real use. Their reader of journals is a place to start from for the aggregate proposed below.What to measure
The chain's defaults were set before any real use: three autonomous passes, full gates run by the script at every pass, a fresh agent for every slice, review and fix. Once projects use it, measure per plan:
Most of it can be read from the journals and reports the plans leave on the main branch; a
surface-statussubcommand could aggregate them.Then revisit the defaults with the numbers: the passes, the gate runs at every pass (their commands are found at planning since #18), the fresh agent per step.