| 1 | 1. **Important — A transient startup failure can leave plans enabled indefinitely.** [internal/console/plansmarker.go:21](internal/console/plansmarker.go:21) |
| 2 | |
| 3 | Remove the catalog and restart the console while the marker GET or PUT fails. The worker logs the error and exits permanently; no later pass retries it. Boxes continue reading the old enabled marker and enforcing limits after the bucket recovers. Initial enablement can likewise remain ineffective indefinitely. |
| 4 | |
| 5 | **Fix:** retry startup reconciliation with backoff until the desired marker state is established, rereading after CAS conflicts. Keep the successful no-catalog/no-marker path inert. Add transient read/write failure tests covering disablement. |
| 6 | |
| 7 | 2. **Important — Concurrent passes can restore disabled limits or overwrite newer values.** [internal/host/plans_pass.go:107](internal/host/plans_pass.go:107) |
| 8 | |
| 9 | `fastConvergeLoop` and `instancesLoop` independently call `plansPass`. Pass A can read an enabled marker and stall fetching limits. After the marker is disabled, pass B clears the cache; A then finishes and unconditionally installs its enabled snapshot. Limits return until another successful pass. Similarly, A’s captured `prev` can overwrite limits that B refreshed while A encountered a per-account error. |
| 10 | |
| 11 | Atomic pointers prevent data races, but do not order these operations. |
| 12 | |
| 13 | **Fix:** serialize the complete pass, including disable paths, or introduce publication ordering that rejects stale work. Add a blocking-store test that forces these interleavings. |
| 14 | |
| 15 | 3. **Minor — The refreshed census justification misdescribes the sweep change.** [internal/provision/testdata/plan14-root-reads-plans-2-box-limits.tsv:9](internal/provision/testdata/plan14-root-reads-plans-2-box-limits.tsv:9) |
| 16 | |
| 17 | Both the sweep row and its `@legacy` declaration retain “diagnostic throttling only” while freezing a body that now uses account limits to change hibernation and held-for-tick decisions. A reviewer relying on that justification receives an inaccurate account of the behavioral change. |
| 18 | |
| 19 | **Fix:** update both justifications to describe the idle hook, executing identity and retained lifecycle guards; regenerate the affected seal. |
| 20 | |
| 21 | **Declined to judge** |
| 22 | |
| 23 | - Spec §3’s settled commercial and hibernation policies — explicitly excluded from reconsideration. |
| 24 | - Small memory tiers — explicitly deferred to Plan 2b. |
| 25 | - Throttling and continuous-awake ceilings — explicitly deferred to Plan 4. |
| 26 | - Preserving always-on workers — required by this plan; admission restrictions belong to separate work. |
| 27 | - The atomic `SetIdleFor` ruling — accepted; it safely publishes the callback. |
| 28 | - The prescribed full/five-minute refresh cadence — accepted as scope. |
| 29 | - Final census-owner approval and remote CI status — not verified in this environment. |
| 30 | |
| 31 | The five required cases look correct in sequential execution; finding 2 breaks disablement and last-good preservation under overlap. The live-account SQL passed an in-memory SQLite probe covering live inserts/updates and missing/deleted accounts. Changed Go files are formatted, and `git diff --check` passed. |
| 32 | |
| 33 | Go tests could not start because the sandbox refused creation of Go’s build directory. Darwin/Windows builds remain unverified. HEAD remains `5e5a13e745a16bd0d44aedaa5d8555685dd06726`; the working tree is unchanged. |
| 34 | |
| 35 | **Verdict: ready with fixes. Resolve both Important findings and run the blocked checks before merging.** |