Weekly pacing reads the subscription's real meter: it never slowed the crew while the week fell 8 points in 3 hours #8881

Weekly pacing now runs on percent of the week's limit, says so on home when it can't tell, and holds every run start. I did not prove your null-w.cap theory by reading the real week limit, and I never called keep_plan. The pacing, unknown-pace and run-start tests pass. A wider pass of 69 crew and autonomy tests passes. bun scripts/gate.ts, tsc --noEmit and the design lint are clean. scripts/fast.ts called the diff too broad (1359 of 1960 files, 117 minutes), so I picked those crew and autonomy suites myself. I did not run the full suite; the forge's check does.

What changed

• Percent, not dollars (src/crew/week.ts, src/crew/week_read.ts): the decision takes the share of the week still free, the share kept for people, the spend per hour over the last 3 hours, and the reset time. The elapsed share and the percent are compared to decide.
• Unknown pace (src/crew/week.ts): while no account's weekly limit is known, home says "The week's pace is unknown…" and the crew holds at 2 slots, or the ceiling if that is lower. Before, it returned nothing and fell silent.
• Burn decides too (src/crew/week.ts): a burn that would use up the crew's share before the reset slows the crew even when the week's total looks on pace. The sentence names the run-out time, for example "running out about 2026-11-03 …".
• Every start path (src/crew/dispatch.ts): the hold sits in pump, so assigned, review, feedback and check runs in an autonomous repository wait when the week allows fewer slots than are already going. A held run logs "queued, not started: <sentence>" once.
• Home's sentence: it carries the percent left and the run-out time, and the terminal dashboard prints the same words.
• /talk reserve: 10% of the week's crew capacity stays unspent, and the crew stops at it.

Tests

• test/week.test.ts replays today's numbers (46% free, 2.7 points an hour, reset 11-08 02:00Z). It checks that the crew slows and that the sentence names the run-out.
• test/week-wiring.test.ts covers a fast afternoon on an on-pace week, and the unknown case.
• test/week-pump.test.ts checks that an assigned run past the reserve stays queued with the reason in its log, then starts once the spend is gone.

Not done

• I did not prove why weekFor returned null by reading the real week limit. The new test covers the case where w.cap is null: the old code would have fallen silent, and the new code says the pace is unknown and holds at 2 slots.
• Percent still comes from standing.ts's inferred dollar cap, so an account with no inferred cap counts as unknown rather than being read straight from headroom. I did not change how that cap is inferred.
• The weekly usage meter's own headroom is not read directly either.
• crew.concurrency: I did not touch it. Once this is merged and home shows a pace sentence rather than "unknown", set it back to its ceiling.

Try it: after the preview deploys, open / as the owner and read the pace sentence, or run bun test test/week.test.ts test/week-wiring.test.ts test/week-pump.test.ts.

Closes #8873

Weekly pacing now runs on percent of the week's limit, says so on home when it can't tell, and holds every run start. I did not prove your null-w.cap theory by reading the real week limit, and I never called keep_plan. The pacing, unknown-pace and run-start tests pass. A wider pass of 69 crew and autonomy tests passes. bun scripts/gate.ts, tsc --noEmit and the design lint are clean. scripts/fast.ts called the diff too broad (1359 of 1960 files, 117 minutes), so I picked those crew and autonomy suites myself. I did not run the full suite; the forge's check does.

What changed

• Percent, not dollars (src/crew/week.ts, src/crew/week_read.ts): the decision takes the share of the week still free, the share kept for people, the spend per hour over the last 3 hours, and the reset time. The elapsed share and the percent are compared to decide.
• Unknown pace (src/crew/week.ts): while no account's weekly limit is known, home says "The week's pace is unknown…" and the crew holds at 2 slots, or the ceiling if that is lower. Before, it returned nothing and fell silent.
• Burn decides too (src/crew/week.ts): a burn that would use up the crew's share before the reset slows the crew even when the week's total looks on pace. The sentence names the run-out time, for example "running out about 2026-11-03 …".
• Every start path (src/crew/dispatch.ts): the hold sits in pump, so assigned, review, feedback and check runs in an autonomous repository wait when the week allows fewer slots than are already going. A held run logs "queued, not started: <sentence>" once.
• Home's sentence: it carries the percent left and the run-out time, and the terminal dashboard prints the same words.
• /talk reserve: 10% of the week's crew capacity stays unspent, and the crew stops at it.

Tests

• test/week.test.ts replays today's numbers (46% free, 2.7 points an hour, reset 11-08 02:00Z). It checks that the crew slows and that the sentence names the run-out.
• test/week-wiring.test.ts covers a fast afternoon on an on-pace week, and the unknown case.
• test/week-pump.test.ts checks that an assigned run past the reserve stays queued with the reason in its log, then starts once the spend is gone.

Not done

• I did not prove why weekFor returned null by reading the real week limit. The new test covers the case where w.cap is null: the old code would have fallen silent, and the new code says the pace is unknown and holds at 2 slots.
• Percent still comes from standing.ts's inferred dollar cap, so an account with no inferred cap counts as unknown rather than being read straight from headroom. I did not change how that cap is inferred.
• The weekly usage meter's own headroom is not read directly either.
• crew.concurrency: I did not touch it. Once this is merged and home shows a pace sentence rather than "unknown", set it back to its ceiling.

Try it: after the preview deploys, open / as the owner and read the pace sentence, or run bun test test/week.test.ts test/week-wiring.test.ts test/week-pump.test.ts.

Pacing now meters the forge's own token, which is the most likely reason weekFor returned null in your case. I could not confirm that against production numbers from here, and crew.concurrency is still unreset. The focused tests, the gate and tsc pass. I ran no wider than the week, autonomy and crew suites, so the full check is the forge's.

Cause of the null. The usage tool lists a crew with no grant under platform. readWeek used grantedAccounts, which excludes platform, so a crew on the forge's own token got no account and weekFor returned null. readWeek now meters platform when a repository has no grant. A test replays your numbers through the real ledger: 46% free, about 2.7 points an hour, reset about 5.3 days off. It fails without the fix and passes with it.

Where I disagree with item 1.

• This repo ingests no provider-reported percent. The usage tool's headroom figure is freePct(cap, used) from standing.ts, so the 54% to 46% you quoted is derived from the same inferred cap. There is no percent sample to take the change of, so I read that same figure and compute burn from the last 3 hours of usage.cost_usd over it. Real provider percents would need new capture, which I did not add.
• An account with no inferred cap is still "unknown". Unknown now holds the crew at 2 slots and home says the pace is unknown, instead of falling silent.
• A repository with no grant whose platform account has no known cap is not metered at all. Treating it as unknown held other tests' repos at 2 slots. Say if you want it held instead.

Other items.

• 2: the hold is now src/crew/week_hold.ts (weekHold), with test/week-hold.test.ts, and pump calls it.
• 3: test/week-pump.test.ts no longer uses a fixed sleep or a 100×100ms poll. It waits on the run log and run state with a deadline.
• 4 and 6: I could not verify the pacer on the preview, because this sandbox cannot reach this pull's preview. I cannot quote the owner-view sentence, and I did not touch crew.concurrency. Once home shows a percent-left sentence instead of "unknown", set it back to the repository's slot ceiling (autonomySlots, 5 in your tick), since the pacer now caps below that.
• 5: done through repoPace and weekWords in test/week-wiring.test.ts, as above.
• Direction: I cannot confirm the owner prioritised this pull over the pipeline-first rule. It touches crew throttling and about 11 files. A person should decide whether it waits.

Try it: bun test test/week.test.ts test/week-wiring.test.ts test/week-hold.test.ts test/week-pump.test.ts.

Left #8873 open: 3 unticked items remain (Pacing runs on the measured percent the provider reports (headroom), not an inferred dollar cap, so it can't silently switch off. The elapsed share and the percent drive the decision.; Home's sentence is on the page for the owner, with the percent left and the projected run-out time.; When the pacer is working, crew.concurrency goes back to its ceiling; say so on the pull.).