The pacer's burn matches the meter: it says 1.4% an hour while the real meter hasn't moved in over an hour #8912

The pacer now measures its burn from stored readings of the meter, not from dollars. Reviews and person-assigned runs now have their own lane. The week tests, the migration check and the type check pass, and so do the neighbouring pace and dashboard tests. I did not run the whole suite; the forge runs it on push. I could not call keep_plan, so the plan is not on the issue.

What changed

• Burn. src/crew/week_burn.ts is new. The week's free share is stored in a new week_reading table (migration 20261103140000-week-readings, pinned) at most once a minute. Burn is how far that share fell over the last hour, measured from the newest reading at or before the hour's start, else the oldest inside it. It is null when the span between readings is under 15 minutes, and a rise (a reset) counts as no burn. week_read.ts no longer turns dollars into percent.
• Too few readings. The sentence says "Burn not known yet: too few readings of the meter…". Until the readings exist the crew holds at 2 slots, as before. The ahead-of-pace sentence says "unread" instead of a made-up rate.
• Replay test. test/week-burn.test.ts replays 54% at 16:33Z, 46% at 19:25Z and 45% from 20:05Z to 21:15Z. At 21:15Z the burn is under 0.2% an hour, not 1.4%. At 19:30Z it is about 2.8 points an hour.
• Same number as usage. Home now rounds "N% of the week left" to a whole percent. It is still the same free share, aggregated over the repository's accounts, which is also not measured by the provider. It is derived from the inferred dollar cap, as usage does, and I did not change that.
• Wrong repository. weekWords was taking whichever autonomous repository sorted first by name. It now takes the one with the most agent runs this week, so "Nothing has landed this week" no longer appears over an idle repository.

Does the pace limit only picks or all runs? All runs in an autonomous repository, builds, reviews, assigned, feedback and check runs alike. That is why a review and a build filled the single slot and assigned work (#8901) waited. Now reviews and assigned runs have a lane of WEEK.floorSlots (2) of their own and are not counted against the pace slots, so a build never blocks them. The reserve wall still holds everything, because that is the point of the wall. Say so if you want finished work to run past it.

Tests

• I changed the wiring tests to seed meter readings instead of dollars, because they were testing the old behaviour. The sentence assertion in week.test.ts changed with it.
• I added a test for the review and assigned lane in test/week-hold.test.ts.
• I did not add a test for the repository choice in weekWords.

Not done

• No pruning beyond a week of readings, and no per-account readings; one reading is stored per set of accounts.

Try it: bun test test/week*.test.ts.

🤖 Generated with Claude Code

Closes #8910

The pacer now measures its burn from stored readings of the meter, not from dollars. Reviews and person-assigned runs now have their own lane. The week tests, the migration check and the type check pass, and so do the neighbouring pace and dashboard tests. I did not run the whole suite; the forge runs it on push. I could not call keep_plan, so the plan is not on the issue.

What changed

• Burn. src/crew/week_burn.ts is new. The week's free share is stored in a new week_reading table (migration 20261103140000-week-readings, pinned) at most once a minute. Burn is how far that share fell over the last hour, measured from the newest reading at or before the hour's start, else the oldest inside it. It is null when the span between readings is under 15 minutes, and a rise (a reset) counts as no burn. week_read.ts no longer turns dollars into percent.
• Too few readings. The sentence says "Burn not known yet: too few readings of the meter…". Until the readings exist the crew holds at 2 slots, as before. The ahead-of-pace sentence says "unread" instead of a made-up rate.
• Replay test. test/week-burn.test.ts replays 54% at 16:33Z, 46% at 19:25Z and 45% from 20:05Z to 21:15Z. At 21:15Z the burn is under 0.2% an hour, not 1.4%. At 19:30Z it is about 2.8 points an hour.
• Same number as usage. Home now rounds "N% of the week left" to a whole percent. It is still the same free share, aggregated over the repository's accounts, which is also not measured by the provider. It is derived from the inferred dollar cap, as usage does, and I did not change that.
• Wrong repository. weekWords was taking whichever autonomous repository sorted first by name. It now takes the one with the most agent runs this week, so "Nothing has landed this week" no longer appears over an idle repository.

Does the pace limit only picks or all runs? All runs in an autonomous repository, builds, reviews, assigned, feedback and check runs alike. That is why a review and a build filled the single slot and assigned work (#8901) waited. Now reviews and assigned runs have a lane of WEEK.floorSlots (2) of their own and are not counted against the pace slots, so a build never blocks them. The reserve wall still holds everything, because that is the point of the wall. Say so if you want finished work to run past it.

Tests

• I changed the wiring tests to seed meter readings instead of dollars, because they were testing the old behaviour. The sentence assertion in week.test.ts changed with it.
• I added a test for the review and assigned lane in test/week-hold.test.ts.
• I did not add a test for the repository choice in weekWords.

Not done

• No pruning beyond a week of readings, and no per-account readings; one reading is stored per set of accounts.

Try it: bun test test/week*.test.ts.

🤖 Generated with Claude Code

I've added all four rounds of tests and reworded the hold text. The week tests (burn, hold, pump, wiring) and the type check pass, and bun scripts/gate.ts printed nothing. I did not run the whole suite; the forge runs it on push. I did not confirm that the repository-choice test fails on the old first-by-name code; I only reasoned that it would.

1. Repository choice. I added a test in test/week-wiring.test.ts that makes a quiet autonomous repo, aaa-quiet, which sorts first by name. It asserts home's words carry the busy repo's run count, not (0 runs. The old code would have picked aaa-quiet.
2. Readings store. test/week-burn.test.ts now covers noteReading and readingsSince:

- Dedupe: a second reading within 59 seconds is dropped, and one a minute on is kept. - Scopes and prune: scopes are kept apart, since leaves out older readings, and readings older than a week are pruned. - Burn from stored readings: the burn is computed from stored readings.

A wiring test also checks that readWeek stores a reading by itself, and that an hour later the sentence says "burning 4% an hour".

1. Priority lane in the pump. test/week-pump.test.ts has a new test. Two builds fill the pace slots while one review and one assigned run are going. A queued build is held with the pace sentence, and a third review is held because the lane is full. When one lane run ends, the review starts and the build still waits.
2. Home against usage. A wiring test checks that home's "N% of the week left" equals readForgeUsage's week headroom for the same state. It runs at 20, 45.4, 54.6 and 70% used, which covers both rounding directions. They agree because both come from the same free share, rounded to whole percent. I changed no code for this.

Hold text. It now reads "2 of 2 places for reviews and assigned work are taken, the most the pace lets run at once." It is worded by the count instead of naming both reasons.

🤖 Generated with Claude Code

Left #8910 open: 1 unticked item remain (Say on the pull whether the pace limits only picks or all runs, and make reviews and work assigned by a person always able to run within a stated floor, so finished work lands first.).