carlos / platform Public

Record review round five and its dispositions

The Astra and Opus round 5 reviews are committed unedited, with the
disposition of each finding and the test that fails without its fix.
The attestation plan says what is now built and the four steps left
before any box may attest. The partial-month plan states its boundary
correctly. The handoffs are refreshed.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

claude 3 weeks ago 13f30b67fe52a7e937c11ba5506d5b993710eda0 parent 0d02dd3

7 files changed, +473 −22

.claude/HANDOFF.md +2 −2
docs/superpowers/plans/2026-10-01-durability-attestation-path.md +10 −8
docs/superpowers/plans/2026-10-01-partial-month-billing.md +5 −4
docs/superpowers/specs/CODEX-DISPOSITIONS-carloku-paid-launch-overnight.md +35 −0
docs/superpowers/specs/CODEX-FINDINGS-carloku-paid-launch-overnight-round5.md +222 −0
docs/superpowers/specs/OPUS-REVIEW-carloku-paid-launch-overnight-round5.md +189 −0
implementation/carloku-paid-launch/AGENT_HANDOFF.md +10 −8

diff --git a/.claude/HANDOFF.md b/.claude/HANDOFF.md

index 5c672548f..185794577 100644

--- a/.claude/HANDOFF.md

+++ b/.claude/HANDOFF.md

@@ -7,7 +7,7 @@

Get Carloku's paid plans live with Stripe Tax and the complete metered model; have the pricing page and signup flow reviewable in the morning.

**STATUS:**

-The exact tip, its gate result and its CI result are in the Amadan branch handoff, which is rewritten at each checkpoint; this file names what the work is. Independent review: GPT-6 Astra rejected rounds 1 to 4 (ten, eight, five, five findings); the AGENTS-required Opus production review accepted with fixes in rounds 2 to 4 (eight findings each, all P3 in round 4). Every finding was accepted and fixed with a reproduction (`docs/superpowers/specs/CODEX-DISPOSITIONS-carloku-paid-launch-overnight.md`). Round five runs against the tip; nothing lands until it passes. Landed in this run: console GET billing page, signup and billing demo harness, durability epoch race fix, unmetered-fallback escapes, AWS Cost and Usage Report transfer collector with bucket ownership ledger, statement folds for both new meters, partial-month billing on whole paid days, operator doors for review holds and the house marker, team quantity worker behind an unset policy switch, a teardown guard for shared buckets, the console half and scope computation of a scoped replication attestation (unwired), Stripe provisioning plan and print-only script. Review servers on docs-t1, each answering 200 on its IP form at 01:50 Dublin time on 2026-10-01: pricing http://docs-t1.tail5fd3ba.ts.net:38009 (fallback http://100.119.180.57:38009), console billing page http://docs-t1.tail5fd3ba.ts.net:45033 (fallback http://100.119.180.57:45033), signup and billing demo http://100.119.180.57:41881. The tailnet hostname was not verified from this box. Billing is OFF. No AWS, Stripe or production change was made; AWS was read once (one Cost Explorer query and two list calls on the flagship account).

+The exact tip, its gate result and its CI result are in the Amadan branch handoff, which is rewritten at each checkpoint; this file names what the work is. Independent review: GPT-6 Astra rejected rounds 1 to 5 (ten, eight, five, five, eleven findings); the AGENTS-required Opus production review accepted with fixes in rounds 2 to 5 (eight, eight, eight, nine). Every finding was accepted and fixed with a reproduction (`docs/superpowers/specs/CODEX-DISPOSITIONS-carloku-paid-launch-overnight.md`). Round six runs against the tip; nothing lands until it passes. Landed in this run: console GET billing page, signup and billing demo harness, durability epoch race fix, unmetered-fallback escapes, AWS Cost and Usage Report transfer collector with bucket ownership ledger, statement folds for both new meters, partial-month billing on whole paid days, operator doors for review holds and the house marker, team quantity worker behind an unset policy switch, a teardown that never destroys a bucket another app holds and refuses grants of a name while it is being destroyed, a scoped replication attestation built end to end behind an agent switch that is off, Stripe provisioning plan and print-only script. Review servers on docs-t1, each answering 200 on its IP form at 01:50 Dublin time on 2026-10-01: pricing http://docs-t1.tail5fd3ba.ts.net:38009 (fallback http://100.119.180.57:38009), console billing page http://docs-t1.tail5fd3ba.ts.net:45033 (fallback http://100.119.180.57:45033), signup and billing demo http://100.119.180.57:41881. The tailnet hostname was not verified from this box. Billing is OFF. No AWS, Stripe or production change was made; AWS was read once (one Cost Explorer query and two list calls on the flagship account).

**NEEDED:**

- Paul: approve or edit both copy reviews; confirm the HALF code word; decide the proration policy (`CONSOLE_BILLING_PRORATION` stays unset until then); approve or change the whole-paid-day rule for partial months (`docs/superpowers/plans/2026-10-01-partial-month-billing.md`, "What the approved spec says").

@@ -16,7 +16,7 @@ The exact tip, its gate result and its CI result are in the Amadan branch handof

**RECOMMENDED:**

- Read the round-five reviews, fix what they find, re-review the exact tip.

-- Then: the reader and agent call for the scoped attestation, the AWS principal inventory and the bucket ownership attestation door, quantity reduction at renewal, a `carlos` verb and docs for the operator doors, Free-tier enforcement, dormancy and pool accounting (none started).

+- Then: the AWS principal inventory and the bucket ownership attestation door, quantity reduction at renewal, a `carlos` verb and docs for the operator doors, Free-tier enforcement, dormancy and pool accounting (none started).

- Find what moved 1,395 GB out of Ireland to three other regions in September (collector plan); it is the largest S3 transfer line on the account and grew forty-fold in a month.

**SESSION:**

diff --git a/docs/superpowers/plans/2026-10-01-durability-attestation-path.md b/docs/superpowers/plans/2026-10-01-durability-attestation-path.md

index 577bb6dfd..63ba421f9 100644

--- a/docs/superpowers/plans/2026-10-01-durability-attestation-path.md

+++ b/docs/superpowers/plans/2026-10-01-durability-attestation-path.md

@@ -1,6 +1,6 @@

# Replication writes: how a box could honestly attest

-Date: 2026-10-01. Status: the meter folds and holds; no production box attests; nothing here flips that. Path A is chosen and its console half and scope computation are built and tested locally (see "Decision and progress"). The agent does not call any of it.

+Date: 2026-10-01. Status: the meter folds and holds; no production box attests; nothing here flips that. Path A is chosen and built end to end locally: the per-account fold, the scope, the reader and the agent's call (see "Decision and progress"). The call is behind a switch that is off everywhere.

## Where the meter stands

@@ -38,19 +38,21 @@ The flag may be set only by code that checks its own premise at startup: no `car

Built and tested on the branch, with no effect in production:

- **The fold counts durability days per account.** A box-day attested with an exclusion set is complete for every account the box did not exclude. `usageSweep.DurabilityExcluded` carries the excluded days and each statement's `SourceDays` is reduced for its own account only (`durabilityfold.go`, `accountSourceDays`). `TestDurabilityFoldScopedAttestationHoldsOnlyTheExcludedAccount` pins it, including two boxes of which one excludes and an unattested box.

-- **The scope computation** (`internal/host/durabilityscope.go`, `durabilityScope`). It excludes the owner of every unit-backed route, of every exec route that records a database and does not hibernate, and of every route whose database the live config names. It attests nothing when the replicator's state cannot be read, when the config names a database no route owns, or when the unit has been running since before its config was last written. `TestDurabilityScope` pins each rule.

+- **The scope computation** (`internal/host/durabilityscope.go`, `durabilityScope`). It excludes the owner of every unit-backed route, of every exec route that records a database and does not hibernate, and of every route whose path equals or encloses a database the live config names, as written or as resolved through symlinks. It attests nothing when the replicator's state cannot be read, when the unit is running with no config file, when the config names a database no route owns, or when the unit has been running since before its config was last written. `TestDurabilityScope` pins each rule.

- **The test this plan required first.** `TestScopedAttestationPublishesADayIncompleteForTheUnitOwner`: a box with a unit-backed route and the external replicator present publishes a day that is not complete for that route's owner, and is complete for the owner of a hibernating exec route.

+- **The reader of the replicator's state** (`internal/host/durabilityreplicator.go`, `replicatorProbe`, with `ops.GeneratedLitestreamDBs`). It reads the config, its modification time, and from systemd whether the unit is running, since when, and what it runs. It refuses a config that is not, line for line, what the generator writes; a unit whose command is not the replicator on that one config; a running unit with no config; a unit in any state between running and stopped; a path it cannot resolve; and a config or unit that changed while it was being read. The registry is read inside the same bracket (`readDurabilityScope`), so the routes and the replicator's state are one observation.

+- **The agent's call, behind a switch that is off.** With `CARLOS_DURABILITY_ATTEST=scoped` in the agent's environment, every publish tick observes the box and applies the scope before it seals anything (`enableScopedAttestation`, `applyScope`). A first claim starts at that tick. A new exclusion is dated no later than the config's writing and the last tick that verified the old claim, so a day cannot close complete for an account the replicator began touching just before midnight. When the premise fails the claim ends at the last tick that verified it. Without the switch nothing is attested, exactly as before.

-- **The reader of the replicator's state** (`internal/host/durabilityreplicator.go`, `replicatorProbe`, with `ops.GeneratedLitestreamDBs`). It reads the config, its modification time, and from systemd whether the unit is running and since when. It refuses a config that is not, line for line, what the generator writes; a running unit with no config; a unit in any state between running and stopped; and a config or unit that changed while it was being read. `TestGeneratedLitestreamDBsRefusesAnythingElse`, `TestParseSystemdUnitState` and `TestReplicatorProbe` pin it. Built after round five of the review began, so it is unreviewed.

+A prerequisite the reader uncovered: **the flagship's `/etc/litestream.yml` is kept by hand** (`internal/ops/litestream.go` says so). The reader will not speak for a hand-kept config, so the flagship attests nothing until its config is cut over to the generated one. That cutover is its own piece of work with its own risk (`ops.CoverageShortfall` exists for it) and is not part of this plan.

-A prerequisite this uncovered: **the flagship's `/etc/litestream.yml` is kept by hand** (`internal/ops/litestream.go` says so). The reader will not speak for a hand-kept config, so the flagship attests nothing until its config is cut over to the generated one. That cutover is its own piece of work with its own risk (`ops.CoverageShortfall` exists for it) and is not part of this plan.

+A consequence of how the fold now proves a day: a box whose ledger opened after the box began serving (by its metrics or edge registration) cannot prove those minutes, and that day holds for every account. On a box's first boot that depends on the agent opening its ledger before anything else is first seen. Whether such minutes may ever be waved through is a policy nobody has approved.

Not built, in the order it should be:

-1. The reader must still resolve the console database path the way the generator does (`ops.consoleDBPath`); today the scope assumes `<data>/console/console.db`.

-2. The agent's call, on open and before every seal: compute the scope, and exclude any account that has newly appeared from the earliest instant the external replicator could have known its database (the config's modification time), through `DurabilityLedger.Escaped`. The call must be behind an explicit switch that is off by default.

-3. An independent review of 1 and 2. This is the code that makes attestation read true.

-4. A scoped approval to set the switch on the flagship, after a dev box has run with it for a week and its published days have been read by hand.

+1. An independent review of the reader, the scope, the agent's call and the per-account fold together. Rounds four and five reviewed the scope and found it wrong three ways; the call and the reader have had none.

+2. A dev box running with the switch for a week, its published days read by hand, including a route flipped to always-on and a config regenerated across midnight.

+3. The flagship's config cut over to the generated one.

+4. A scoped approval to set the switch on the flagship.

What an excluded account sees: its replication-write meter never completes, so the monthly freeze refuses its month and it is billed nothing. Whether such an account should instead be billed its other four meters with writes left out is a product decision this plan does not make.

diff --git a/docs/superpowers/plans/2026-10-01-partial-month-billing.md b/docs/superpowers/plans/2026-10-01-partial-month-billing.md

index d516629a5..45baa8c9b 100644

--- a/docs/superpowers/plans/2026-10-01-partial-month-billing.md

+++ b/docs/superpowers/plans/2026-10-01-partial-month-billing.md

@@ -14,8 +14,9 @@ The pricing spec (`2026-09-07-carloku-pricing-plans-design.md`, "Entitlement ass

The spec says nothing about which usage is billed when the plan covered only part of the month. The whole-paid-day rule below is this branch's answer, chosen because it can never bill usage from an unpaid hour. It is a proposal until Paul approves it. What it costs and what it gives away:

-- Usage on the day a plan starts and on the day it ends is never billed, while the allowance still includes the paid hours of those days. Both round toward the customer, by at most two days' usage a month.

-- A plan paid for less than one whole UTC day in a month bills no usage for that month.

+- Usage on a **partial boundary day** is never billed: a UTC day the plan covered only part of, because it started, ended or lapsed inside that day. The allowance still includes the paid hours of that day. A plan that starts exactly at midnight covers that whole day, and the day is billed; one that ends exactly at midnight leaves the following day out and bills the day before.

+- The rounding is toward the customer, by at most two partial days for each continuous paid span. It is not bounded per month: a month with three short lapses on three different days leaves out three days' usage, and more with more.

+- A plan paid for less than one whole UTC day in a month bills no usage for that month. A plan that starts at midnight on the last day bills that one day.

- A lapse of any length inside a day (a failed payment recovered an hour later) takes that whole day's usage out.

The boundary is pinned case by case in `TestBillingCalculationPaidDayBoundaries` (a start exactly at midnight, one nanosecond after, the last minute of a day, an end exactly at midnight, one nanosecond before, a paid-through at noon, a quantity change at noon, the last day of the month, a span inside one day) and `TestBillingCalculationALapseInsideADayTakesTheDayOut`. Each case also checks that the counted days never cover more time than was paid for.

@@ -28,10 +29,10 @@ Bill only usage that provably fell inside the paid interval, against the allowan

1. **Statements carry daily meters.** `usage.Statement` gains `Days map[date]map[meter]float64`, additive on the wire. Every source already arrives per day or finer (metrics and edge by hour, storage and census by day, the durability ledger by hour, the AWS report by hour), so the sweep accumulates per day as well as per month. The monthly totals stay, and must equal the sum of the days, which a test pins. Evidence is unchanged: the same inputs are read.

2. **Allowance history yields intervals, not a refusal.** `AllowanceForMonth` returns the paid intervals inside the month with the assignment in force for each, and the allowance summed over them, each weighted by its share of the month as it already is for mid-month quantity changes. It still refuses what it must: an unordered history, a mixed terms version, a house and non-house mix, a status it cannot read.

-3. **Usage is counted by whole days inside a paid interval.** A UTC day counts only when all 24 hours lie inside one paid interval. The day a plan starts and the day it ends are not counted. That rounds toward the customer by at most two days a month and needs no finer attribution than the statement holds.

+3. **Usage is counted by whole days inside a paid interval.** A UTC day counts only when all 24 hours lie inside one paid interval. A day the plan covered only part of is not counted. That rounds toward the customer by at most two partial days for each continuous paid span, and needs no finer attribution than the statement holds.

4. **Overage** is the counted usage minus the prorated allowance, per meter, floored at zero, then the existing line and €1 floor rules. Storage is already a per-day accrual (bytes over days in month), so counting days is exact for it.

5. **Completeness is still whole-month.** The month's sources must be complete as today. A partial month is not a reason to bill on partial evidence.

-6. **A month with no paid day** (the plan started on the last day, or ended on the first) is recorded as waived with no provider call, which ends the endless retry.

+6. **A month with no whole paid day** (the plan started during the last day, or ended during the first) is recorded as waived with no provider call, which ends the endless retry.

What this does not do: bill Free usage. Free is bounded by enforcement, which is separate work.

diff --git a/docs/superpowers/specs/CODEX-DISPOSITIONS-carloku-paid-launch-overnight.md b/docs/superpowers/specs/CODEX-DISPOSITIONS-carloku-paid-launch-overnight.md

index e709d6ac8..97e0f487e 100644

--- a/docs/superpowers/specs/CODEX-DISPOSITIONS-carloku-paid-launch-overnight.md

+++ b/docs/superpowers/specs/CODEX-DISPOSITIONS-carloku-paid-launch-overnight.md

@@ -129,3 +129,38 @@ Consequences worth knowing:

- A store's first clock hour never resolves an owner. A charged line in it holds the month, and nothing releases that hold. Dormant on AWS today (no ledger claims completeness there). It needs a decision before the AWS principal inventory lands: an operator release for a named bucket-hour, or a ruling that the first partial hour of a new store is the platform's cost.

- The whole-paid-day rule for partial months is not in the approved spec. It is built and pinned, and it must not bill anyone until Paul approves it.

+# Dispositions: round 5 (Astra and Opus)

+Reviewed commit `daa32cb6`. Astra round 5 (`CODEX-FINDINGS-carloku-paid-launch-overnight-round5.md`, unedited): reject, eight P1, two P2, one P3. Opus round 5 (`OPUS-REVIEW-carloku-paid-launch-overnight-round5.md`, unedited): accept with fixes, three P2 and six P3. Every finding was checked against the code. All were accepted. Four of Astra's P1s and four of Opus's findings are in the teardown guard, which round 5 was the first review of; three more are in the attestation scope, which was unwired.

+| --- | --- | --- | --- |

+| Astra F1, Opus N4: a grant can land between the teardown's ledger read and its delete | Accepted. The decision is one compare-and-swap on the ledger. If nobody else holds the bucket the ledger names the app as destroying it, and every grant of the name is refused (`ErrBucketBeingDestroyed`) until that app's interval is closed. A grant and a teardown write the same object, so one of them sees the other. The decision is re-read before emptying and before deleting. | `objstore/ownership.go` `beginBucketTeardown`, `openBucketOwner`, `stillDestroying`; `walk.go` `Teardown` | `TestGrantAndTeardownCannotBothWin`, `TestTeardownHoldsTheNameUntilItHasFinished` |

+| Astra F1 (second part), Opus N2: a holder provisioned before ledgers has no interval and loses its bucket | Accepted. Teardown reads every store record and treats an app whose record names the bucket, and which the ledger has no interval for, as a holder. | `walk.go` `otherStoreHolders` | `TestTeardownFindsALegacyHolderByItsRecord` |

+| Astra F3 A: two sharers torn down together each defer to the other | Accepted. The app that finds another holder marks its own interval as leaving in the same write. The second to write finds the first leaving and is the last holder. | `ownership.go` `beginBucketTeardown` | `TestConcurrentTeardownsOfASharedBucketLeaveExactlyOneDestroyer` |

+| Astra F3 B, Opus N3: the last holder's teardown leaks the scanner plan | Accepted. An app that leaves a bucket with scanning enabled records on the ledger that the scanner is owed. Whoever destroys the bucket disables it, and refuses with no scanner configured. | `ownership.go` `ScannerOwed`, `walk.go` | `TestTeardownOfOneSharerLeavesASharedBucket`, `TestRetriedLegacyTeardownLeavesABucketAnotherAppNowHolds` (both now assert the scanner is gone with the bucket) |

+| Opus N1: a skip leaves the torn-down app's data readable by another account and reports success | Accepted, three ways. A minting grant is refused while another app holds the name (`ErrBucketHeld`). A teardown that leaves a bucket to an app of another account revokes, closes, keeps its record and returns `ErrBucketRetained`. A teardown records on its own store record that its bucket was deleted, and a re-run never touches a bucket of that name again. | `walk.go`, `objstore.go` `TeardownBlock` | `TestMintingGrantIsRefusedWhileAnotherAppHoldsTheName`, `TestRetriedLegacyTeardownLeavesABucketAnotherAppNowHolds`, `TestTeardownHoldsTheNameUntilItHasFinished` |

+| Astra F4: the observation time is the caller's earlier clock reading | Accepted. Completeness is dated at the caller's clock plus the time the walk had run when both probes had answered. | `walk.go` `Grant`, `grantElapsed` | `TestCompletenessIsDatedAfterTheProbesAnswer` (a twelve-second probe across an hour boundary) |

+| Astra F2: retiring a future-dated operation lets its sender lower the quantity | Accepted. An operation dated ahead of the observing clock is left outstanding, not retired. A sender re-reads the operation immediately before sending and does not send one that is no longer the outstanding one. | `billingquantity.go` `resolveQuantityOperation`, `sendQuantityOperation` | `TestQuantityFutureDatedOperationIsNotRetiredUnderItsSender` (Astra's interleaving), `TestQuantitySenderDoesNotSendARetiredOperation` |

+| Astra F9, Opus N8: a coincidental quantity is backdated and labelled charged | Accepted. An operation is confirmed only by the provider's success answer to its own request (`confirmed_at`). Only a confirmed operation dates the assignment at its instant and is labelled charged. An unconfirmed match is recorded as `landed_unverified`, dated when observed, with a review. A young unconfirmed operation makes the reconcile wait. Nothing is sent to find out. | `billingquantity.go`, `billingservice.go`, `billingstore.go` | `TestQuantityCoincidentalChangeIsNotBackdated`, `TestQuantityWebhookOverAYoungUnconfirmedOperationWaits`, `TestQuantityLandingSeenByAWebhookIsDatedAtTheOperation` (now a real landing), `TestQuantityWorkerRecoversALostResponse` |

+| Opus N5: the period-start clamp can date a proration before the addition it charges for | Accepted. The operation's instant is never before the newest addition it covers, and the compare-and-set refuses one that is. | `billingquantity.go` | `TestQuantityOperationIsNotDatedBeforeTheAdditionItChargesFor`, a case in `TestBeginQuantityOperationIsACompareAndSet` |

+| Astra F10, Opus N9: the audit guard is dropped and recreated outside a transaction | Accepted, and already fixed in `b4e272ff` before the reviews returned: the guard is replaced only when its stored text differs, in one immediate transaction. The rollback consequence Opus names is in the handoff. | `billingquantityaudit.go` | `TestQuantityProcessingGuardIsReplacedWhenItsBodyChanges` |

+| Astra F8: a permanent memory of an absent month hides a statement another console writes later | Accepted. The memory expires after six hours. | `economicspass.go` `statementAbsentTTL` | `TestStatementCatchUpRevalidatesAnAbsentMonth` |

+| Opus N6: a persistent read error on one statement hides its month for good | Accepted. After three passes running, an account's unreadable statement is reported once and the month is classified without it. The platform's statement stays unknown. The unknown rule is now pinned. | `economicspass.go` | `TestStatementMonthStateEdges` |

+| Astra F5: the registration tolerance erases missing coverage or an exclusion | Accepted. The tolerance is gone. Each box must prove the union of its durability, metrics and edge windows, and the proof is what its ledger covered. A ledger open before the box did anything makes a registration race harmless; one that opened late leaves a gap and the day holds. | `durabilityfold.go` | `TestDurabilityFoldProvesTheUnionOfABoxsWindows` |

+| Astra F6, Opus N7: the scope attributes a configured database to the first matching route | Accepted. Every route whose path equals or encloses the configured path is excluded. Paths are matched as written and as resolved through symlinks. | `host/durabilityscope.go`, `durabilityreplicator.go` | `TestDurabilityScope` (nested, duplicate, linked, both route orders), `TestReadDurabilityScopeIsOneObservation` |

+| Astra F7, Opus N7: a running unit with no config attests | Accepted. It attests nothing, in the scope and in the reader. The reader also requires the unit's command to be the replicator on that config alone. | `host/durabilityscope.go`, `durabilityreplicator.go` | `TestDurabilityScope`, `TestReplicatorProbe`, `TestParseSystemdUnitState` |

+| Opus N7: torn reads, and an exclusion that must reach back to the day the replicator could first have touched the database | Accepted. The registry is read inside the reader's bracket; a restart or rewrite around it attests nothing. A new exclusion is dated no later than the config's writing and the last tick that verified the old claim. | `durabilityreplicator.go` `readDurabilityScope`, `durabilityscope.go` `applyScope` | `TestReadDurabilityScopeIsOneObservation`, `TestScopedAttestationExcludesFromWhenTheConfigWasWritten` |

+| Astra F11: the partial-month plan misstates its boundary | Accepted. The plan and the code comment now speak of partial boundary days, bound the rounding per continuous paid span, and say a midnight start counts. | plan, `billingcalculation.go` | none |

+Two reviewers, two answers, on one point. Opus (round 4 N6) asked for a tolerance so a registration race does not hold a new box's first day. Astra (round 5 F5) showed the tolerance passes minutes the ledger never covered. The supervision rule decides it: ambiguity holds unless a policy is approved. The tolerance is removed. What the ledger covered is the proof. If a box's ledger opens after the box began serving, that day holds for everyone, and whether a box's first minutes may be waved through is a decision for the owner.

+Wired in this round, on supervision's direction, and unreviewed: the agent calls the scoped attestation when `CARLOS_DURABILITY_ATTEST=scoped` is set in its environment, before every seal. It is unset everywhere. `TestScopedAttestationIsOffUnlessAskedForByName` pins that only the exact value turns it on and that a publisher nobody enabled attests nothing.

+Not changed, with reasons:

+- A teardown that leaves a bucket to another account keeps its record and returns an error until the other store is torn down or a person removes the bucket. There is no operator override yet.

+- The scanner debt is only carried for apps that leave through the current code. A plan enabled by an app torn down by an older build, on a bucket still shared, is not known to the ledger.

+- Stripe's behaviour on a proration date, and whether its refusal names the parameter, is still unconfirmed. If it does not name it, a refused operation is not retired at once and falls back to the replay limit.

diff --git a/docs/superpowers/specs/CODEX-FINDINGS-carloku-paid-launch-overnight-round5.md b/docs/superpowers/specs/CODEX-FINDINGS-carloku-paid-launch-overnight-round5.md

new file mode 100644

index 000000000..31f861289

--- /dev/null

+++ b/docs/superpowers/specs/CODEX-FINDINGS-carloku-paid-launch-overnight-round5.md

@@ -0,0 +1,222 @@

+## 1. Disposition table

+Reviewed **daa32cb6**, against **aed42815**, including the delta from **4bbe94b6**. All references below identify the reviewed commit, including files subsequently changed in the working tree.

+The counterfactual test assessments below come from inspecting fixtures, assertions and removed conditions. I did **not** execute Go tests or mutation tests. I independently reproduced the floating-point boundary and the trigger-creation race using memory-only calculations and SQLite.

+In this table, unqualified filenames are under `internal/console/`.

+|---|---|---|---|

+| Astra R1 — retry charge and allowance dates differ | **Partly closed.** Successful retries receive the operation’s date, but matching quantity does not establish that this operation caused the change. See F9. | `billingservice.go:497`, `billingstore.go:448`; `billingquantity_test.go:922`, `:960`, `:987`. | **No** when the corresponding dating or review logic is removed. The retry test calculates seat-seconds rather than calling `AllowanceForMonth`. |

+| Astra R2 — observation hour attributed to the new owner | **Partly closed.** `OwnerAt` rejects an hour beginning before `CompleteSince`, but the grant can supply a timestamp preceding the actual observations. See F4. | `internal/objstore/ownership.go:359`; `internal/objstore/ownership_test.go:813`. | **No** with the previous hour-overlap condition. The fixture supplies the observation timestamp directly; it does not delay the probes. |

+| Astra R3 — missing platform statement hides oldest tenant month | **Partly closed.** Existing tenant statements now establish presence. Permanent absence caching can recreate the omission across processes. See F8. | `economicspass.go:1430`, `:1443`; `meterfolds_test.go:794`. | **No** with the old platform-only absence rule. The test does not create a statement after another process caches absence. |

+| Astra R4 — invalid proration date replayed for 22 hours | **Partly closed.** Date bounds and immediate retirement are implemented; retirement still permits a stale sender. See F2. Provider boundary semantics remain unverified. | `billingquantity.go:391`, `:606`, `:665`; `billingquantity_test.go:644`, `:738`, `:1021`. | **No** for the corresponding bounds, clamping and retirement assertions. The fake accepts future dates within the period. |

+| Astra R5 — map-order-dependent day sums | **Closed.** Validation sums dates in a fixed order. | `billingcalculation.go:172`; `billingcalculation_test.go:358`. | **Not reliably.** Removing sorting restores differing outcomes for the supplied values. The repeated test is probabilistic; “fails within a few runs” is not a deterministic guarantee. |

+| Opus N1 — incomplete compare-and-set | **Closed** for the reported revision and subscription gaps. | `billingquantity.go:386`; `billingquantity_test.go:667`, `:681`. | **No.** The revision case isolates revision; the rebound pending addition isolates subscription. |

+| Opus N2 — contradictory daily totals hold silently | **Closed.** Missing days remain quiet; contradictory days produce a diagnostic error. | `billingcalculation.go:138`, `:193`; `billinginvoice.go:186`, `:196`; `billingcalculation_test.go:319`. | **No.** The test checks the distinct error, diagnostic name and non-quiet classification. |

+| Opus N3 — clock-skewed operation date | **Partly closed**, for the same reasons as Astra R4. | `billingquantity.go:606`, `:665`; `billingquantity_test.go:1021`, `:738`. | **No** for the repaired fixture, but that fixture has no competing resolver or stale sender. |

+| Opus N4 — corrupt statement causes endless catch-up sweeps | **Closed** for a month whose sole remaining defect is corrupt JSON. Corruption counts as present without making the month open. | `economicspass.go:1418`, `:1448`; `meterfolds_test.go:828`. | **No.** Restoring the corrupt-as-open classification fails the settled-state assertion. Direct changes to cached closed statements remain the documented limitation. |

+| Opus N5 — coincidental quantity labelled charged | **Partly closed.** The renewed-period branch now says `landed_unverified`; the reverse ended-subscription label remains unchanged. | `billingquantity.go:721`, `billingquantityaudit.go:24`; `billingquantity_test.go:833`, assertion `:868`. | **No** if `charged` is restored. However, this fixture actually lands the request; it does not reproduce an unrelated actor setting the same target. |

+| Opus N6 — registration race across an hour boundary | **Partly closed.** The two-second boundary race passes, but the tolerance also discards required proof intervals. See F5. | `durabilityfold.go:100`; `meterfolds_test.go:549`. | **No** with hour truncation restored. The fixture publishes coverage beyond the shortened registration window, so it does not test missing coverage within the tolerance. |

+| Opus N7 — two subscriptions in one month create a review | **Closed as documentation**, as requested. | `docs/superpowers/plans/2026-10-01-partial-month-billing.md:54`; `implementation/carloku-paid-launch/AGENT_HANDOFF.md:40`. | **N/A.** No new behavioral test or behavior change was required. |

+| Opus N8 — principal-inventory contract too narrow | **Closed as an interface contract.** AWS implementation remains absent. | `internal/objstore/provisioner.go:53`. | **N/A.** The fake cannot establish compliance with the expanded AWS contract. |

+| Both reviews — teardown must protect another holder | **Partly closed.** The sequential retry and sequential shared-bucket cases are protected. Concurrent grants, concurrent teardowns and scanner cleanup remain unsafe. See F1 and F3. | `internal/objstore/walk.go:571`, `:595`, `:607`; `internal/objstore/ownership_test.go:851`, `:919`. | **No** with the guard removed. Neither test exercises concurrent walks; the retry test omits the final scanner assertion. |

+Additional verification limits:

+- `TestQuantityWorkerMeasuresThePauseFromTheProviderRead` now delays before operation insertion (`billingquantity_test.go:572`), so it genuinely distinguishes the earlier provider-read timestamp from a later send timestamp.

+- `TestQuantityRetryDatesTheAllowanceAtTheProrationInstant` alters the persisted operation’s timestamp after the failed request (`billingquantity_test.go:907`). It checks dating logic, not a provider’s real replay of an unchanged request twenty hours later.

+- `TestBillingCalculationFullMonthBytesAreUnchanged` (`billingcalculation_test.go:406`) checks omitted fields, arithmetic name and selected values. It does not compare against bytes produced by the previous implementation.

+- The revision and isolated-subscription mutation claims are supported. The broader historical claim that **every** compare-and-set clause is independently pinned remains too strong: removing the `Target <= Quantity` clause still leaves the lower-target fixture rejected by target recomputation.

+## 2. New findings

+### F1. P1 — The teardown decision is not protected against another grant

+**Where:** `internal/objstore/walk.go:571`, `:580`, `:611`, `:614`.

+**Scenario:** A’s teardown reads a ledger containing only A. Before it empties the bucket, B’s grant appends an interval, delivers credentials and writes an object. A then empties and deletes B’s bucket using its earlier decision.

+There is also an unrecorded-holder path: A and B share a legacy bucket, neither has a ledger interval, and A tears down. The new code records only A and proceeds to destroy the shared bucket. It does not establish that no other legacy holder exists.

+After the concurrent-grant case, B’s interval can remain open although its bucket and data have been destroyed. After the legacy case, the incomplete ledger still cannot establish ownership. Neither ledger outcome repairs the data loss.

+**Smallest acceptable fix:** Serialize grants and destructive teardown steps using a durable, bucket-scoped exclusion mechanism. Under that protection, refuse destruction when the holder inventory is incomplete. A second unprotected read immediately before deletion is insufficient.

+Skipping bucket destruction is appropriate when detaching one known holder from a shared bucket, including the retried teardown. Unknown ownership requires refusal or retained cleanup state.

+### F2. P1 — Retiring a future-dated operation allows a stale request to lower quantity

+**Where:** `internal/console/billingquantity.go:606`, `:659`, `:692`, `:729`.

+**Scenario:**

+1. The stored period starts three seconds ahead of the local clock—the new clock-skew test’s supported state.

+2. Worker A records a 10→11 operation, dated at that period start, and pauses before sending.

+3. Worker B reads provider quantity 10. Because `read.Unix() < op.CreatedAt`, it acknowledges A’s operation.

+4. Another member arrives. Worker C, whose pass overlaps these workers, records and completes a fresh 10→12 operation.

+5. A resumes after the three seconds, still within its two-minute send window. Nothing checks whether its operation was retired or replaced. Its previously unused key sends quantity 11 and lowers the provider’s quantity from 12.

+The outstanding-operation row no longer excludes A once another process retires it. Idempotency does not help because A’s old request has never executed.

+**Smallest acceptable fix:** Do not retire an operation merely because its timestamp is ahead of the observing clock; leave it outstanding until that instant. More generally, retirement must prevent already-authorized senders from executing before a replacement becomes eligible. Add the interleaving above to the cross-process tests.

+### F3. P1 — Skipped teardown steps can lose their last cleanup record permanently

+**Where:** `internal/objstore/walk.go:580`, `:595`, `:607`, `:635`, `:689`.

+**Scenario A — concurrent teardown:** A and B share a bucket. Both teardowns read both intervals open. Each skips bucket and scanner deletion because the other holds the bucket. Both then revoke their own credentials, close their intervals and delete their records.

+The bucket and scanner remain, but neither store record remains to retry cleanup. Subsequent teardown calls return success immediately at `walk.go:504`. The ledger now has no open holder; it does not identify a future owner or supply a cleanup job.

+**Scenario B — sequential scanner leak:** Only A’s record names the enabled scanner. A’s teardown preserves the scanner for B, then deletes A’s record. B’s later teardown deletes the bucket but skips `EnsureDisabled`, because B’s record has no enabled scanning block.

+The second scenario already exists in `TestRetriedTeardownLeavesABucketAnotherAppNowHolds`: scanning is enabled on the departing holder at `ownership_test.go:874`; the final teardown at `:908` checks only bucket removal at `:911`. The scanner plan outlives the bucket.

+**Smallest acceptable fix:** Preserve bucket-level cleanup responsibility until the final holder and scanner are removed. Serialize the last-holder decision, and retain or transfer scanner cleanup metadata before deleting the departing holder’s record. Extend the existing test to assert final scanner removal and add concurrent teardown coverage.

+### F4. P1 — “Observation time” is still the grant’s earlier caller timestamp

+**Where:** `internal/objstore/walk.go:206`, `:207`, `:211`; `internal/objstore/ownership.go:270`, `:359`.

+**Scenario:** A grant receives `now=09:59:58` and pauses before its probes. A legacy holder transfers data at 10:00:01 and removes its bucket and credentials by 10:00:05. At 10:00:10, both probes correctly report absence.

+The ledger is nevertheless opened with `CompleteSince=09:59:58`, because `Grant` passes its original `now` as the observation timestamp. `OwnerAt(10:00)` accepts the whole hour and attributes the earlier holder’s transfer to the new owner.

+The corrected hour comparison cannot compensate for an incorrectly dated observation. This remains dormant on the current AWS provisioner, which lacks the principal inventory.

+**Smallest acceptable fix:** Sample the observation clock after both successful probes, conservatively dating completeness no earlier than their completion. Add a delayed-probe test crossing an hour boundary.

+The month projection at `internal/usage/evidence_month.go:107` correctly preserves the supplied completeness boundary and relevant intervals. It pins the erroneous timestamp faithfully; projection is not the defect.

+### F5. P1 — Registration tolerance can erase missing coverage or an account exclusion

+**Where:** `internal/console/durabilityfold.go:100`, `:107`, `:132`; `internal/usage/durability.go:652`.

+**Scenario:** Edge expects a box from 09:00. Durability registration begins at 09:04. The four-minute difference passes the new tolerance.

+The fold then asks `day.Scope` only about 09:04 onward. Either of these day records therefore passes:

+- Coverage starts at 09:04, proving nothing about the preceding four minutes.

+- Coverage exists from 09:00, but excludes account A until 09:04 and excludes nobody afterward.

+In the second case, `UnmeteredWithin(09:04, …)` omits A. The day increments A’s completeness count despite that box explicitly excluding A during part of its expected service window. Another healthy box does not recover the omitted exclusion.

+**Smallest acceptable fix:** Keep registration tolerance separate from coverage proof. Evaluate coverage and exclusions over the union of the box’s expected windows from durability, metrics and edge. The benign registration-race fixture already publishes sufficient coverage and can continue passing.

+### F6. P1 — Scoped attestation assigns a configured database to only the first matching route

+**Where:** `internal/host/durabilityscope.go:106`, `:120`, `:125`; `internal/ops/litestream.go:273`.

+**Scenario:** Routes appear in this order:

+- Account B owns a unit route with database tree `/srv/unit`.

+- Account A owns a hibernating exec route with database `/srv/unit/a.db`.

+The external replicator config names `/srv/unit/a.db`. The prefix match finds B first and breaks. B is excluded; A remains attested although the external replicator touches A’s database. Reversing route order changes the result.

+Symlinks create the same problem without textual nesting: the unit tree walker follows symlinks, while scope matching only cleans path strings. `/srv/unit/a.db` can point to A’s `/data/a.db` and be attributed solely to B.

+**Smallest acceptable fix:** Exclude every possible route owner of a configured database, or refuse ambiguous ownership. The reader must establish filesystem identity, including symlink targets and relative-path resolution using the replicator’s actual execution context. It must fail closed when that identity cannot be established. Parser completeness alone does not address this.

+This is a future-authority defect; the function is unwired.

+### F7. P1 — Missing config is treated as proof that a running replicator has no databases

+**Where:** `internal/host/durabilityscope.go:34`, `:90`, `:113`, `:134`.

+**Scenario:** The external replicator loads a config containing A’s hibernating database. The config file is subsequently removed while the process continues running.

+The reader reports `ConfigPresent=false`, `UnitActive=true`. The stale-config check is skipped, as is every configured-path check. A has no unit or always-on route, so the function returns `Attested=true` without excluding A.

+A coherent filesystem read alone cannot establish which config an already-running process loaded.

+**Smallest acceptable fix:** Refuse attestation when an active replicator’s loaded configuration cannot be established, including an absent config. Beyond the plan’s existing parser requirements, the reader needs a coherent unit-generation/config witness: a restart or config replacement between reads must invalidate the observation. The agent must validate that witness together with the registry witness before granting or sealing attested coverage.

+This is also unwired; no production call enabling it was found.

+### F8. P1 — Permanent negative caching can hide a newly written oldest month

+**Where:** `internal/console/economicspass.go:1394`, `:1458`, `:1312`, `:1328`.

+**Scenario:** September is the first metered month. Around November 1:

+1. Console B still has an October-started pass in progress, preparing September as its previous month.

+2. Console A’s November catch-up checks September before B writes anything and caches it as absent.

+3. B writes an open September statement, then exits.

+4. A remains running.

+A never reads September again. September lies outside the oldest month A recognizes, so A never reaches the sweep that would delete its absence-cache entry. The retained open statement remains undiscovered despite being within the 36-month window.

+The assertion that no other pass can write a month two or more back overlooks passes that began before the month boundary.

+**Smallest acceptable fix:** Revalidate cached absence, using bounded expiry or a shared statement-generation witness. Add a two-server test that writes the oldest statement after one server has cached absence.

+### F9. P2 — A coincidental quantity change receives an unproven historical charge date

+**Where:** `internal/console/billingservice.go:497`; `internal/console/billingstore.go:448`, `:466`; `internal/console/billingquantity.go:724`.

+**Scenario:** A 10→11 operation is recorded at 02:00 but never executes. At 22:00 an operator independently sets quantity 11, with proration from 22:00. A webhook reconciles the subscription.

+The matching subscription, period and target cause reconciliation to backdate the allowance assignment to 02:00. No provider evidence ties the observed quantity to this operation or its proration date. With otherwise compatible history, no review is filed; the worker subsequently treats the target as landed without sending.

+This extends the old coincidental-quantity problem into effective-dated financial history. Here it gives excess allowance, favoring the customer, but the asserted charge date is still false.

+`TestQuantityLandingSeenByAWebhookIsDatedAtTheOperation` (`billingquantity_test.go:960`) cannot distinguish these scenarios: its fixture fails the request before execution and then directly assigns the fake’s quantity.

+**Smallest acceptable fix:** Require evidence associating the quantity change with this operation and its date before backdating. If only quantity equality is known, retain an unverified outcome and hold the ambiguous dating for review.

+### F10. P2 — Trigger replacement races concurrent store opens

+**Where:** `internal/console/billingquantityaudit.go:21`, `:22`, `:30`.

+**Scenario:** Two store opens execute the migration concurrently:

+1. A drops the processing guard.

+2. B drops it.

+3. A creates it.

+4. B’s unconditional `CREATE TRIGGER` fails because it already exists.

+I reproduced this schedule using the exact pinned `DROP` and `CREATE` statements against a shared, in-memory SQLite database. The error is `trigger billing_quantity_events_processing_guard already exists`.

+The separately committed statements also leave a period without the processing guard; a crash after the drop preserves that absence.

+**Smallest acceptable fix:** Replace the trigger inside one serialized transaction. Do not merely add `IF NOT EXISTS`, which would retain the missing-guard window. Add concurrent-open and rollback coverage.

+### F11. P3 — The partial-month proposal misstates its own boundaries

+**Where:** `docs/superpowers/plans/2026-10-01-partial-month-billing.md:17`, `:31`, `:34`; `internal/console/billingcalculation.go:143`.

+**Scenario:** The plan says the start day is never billed and that the rule excludes at most two days’ usage per month.

+The implementation counts a subscription’s start day when it begins exactly at midnight (`billingcalculation.go:202`). The tests explicitly pin this, including a last-day midnight start counting one day (`billingcalculation_test.go:237`, `:251`).

+Furthermore, three short lapses on three separate days exclude three days’ usage. “At most two days a month” is false when the month has multiple paid spans.

+**Smallest acceptable fix:** Describe excluded **partial boundary days**, and bound rounding per continuous paid span rather than per month. Correct the last-day example and matching code comment. This changes the explanation submitted for approval, not the proposed policy.

+Other requested boundary checks:

+- Ordinary exclusions are unioned across boxes, and `accountSourceDays` subtracts them per account (`economicspass.go:1637`). A non-expected, silent box does not erase another box’s exclusion. Live accounts receive statements even without usage (`:1597`); an absent statement does not itself establish completeness.

+- The live economics view consumes modeled totals rather than this per-account billing-completeness verdict. Month statements carry the adjusted counts, and their evidence captures the durability inputs. F5 concerns the interpretation of those inputs.

+- I found no additional history-order or frozen-month bypass in the new dating checks: `billingstore.go:462` rejects frozen dating, `:465` checks history order, and `:521` clamps backward observations with a review.

+- Stripe’s actual date-refusal and replay semantics cannot be established from this repository. The fake is not independent evidence that every recognized refusal proves non-execution.

+- A route without a valid account follows the documented legacy `release.RouteAccount` fallback to ops (`internal/release/adopt.go:862`); that alone is not evidence of a new tenant-attribution defect.

+## 3. Handoff claims the code contradicts

+References are to `implementation/carloku-paid-launch/AGENT_HANDOFF.md` at **daa32cb6**.

+- **Line 33 — per-account durability completeness.** A box’s exclusion can disappear when it falls within the registration tolerance outside the queried durability window. F5 contradicts the claimed completeness for accounts the box did not exclude.

+- **Line 35 — completeness begins when observation starts vouching.** The grant supplies its earlier caller timestamp, not the completed probes’ time. F4 shows an accepted hour preceding the observations.

+- **Lines 35 and 61 — “a store’s first clock hour never resolves.”** An observation exactly on the hour resolves that hour. `ownership_test.go:838` explicitly expects this. The claim should distinguish a partial first hour.

+- **Line 36 — catch-up sweeps every retained open or owed month within the window.** F8 leaves a newly written oldest month permanently hidden by another process’s cached absence.

+- **Line 38 — the seat’s charge and allowance start together, or a review holds it.** F9 permits an unrelated quantity change to receive the operation’s earlier date without a review.

+- **Line 76 — all findings were fixed with reproductions.** The disposition table contains partial closures; the teardown tests omit concurrent destruction and final scanner cleanup, and the coincidental-quantity test does not reproduce an independently changed quantity.

+The claim that production attestation remains false is supported: `durabilityScope` is called only from tests, and no production path added by this branch grants attestation.

+## 4. Verdict

+**Reject.**

\ No newline at end of file

diff --git a/docs/superpowers/specs/OPUS-REVIEW-carloku-paid-launch-overnight-round5.md b/docs/superpowers/specs/OPUS-REVIEW-carloku-paid-launch-overnight-round5.md

new file mode 100644

index 000000000..0687ce86d

--- /dev/null

+++ b/docs/superpowers/specs/OPUS-REVIEW-carloku-paid-launch-overnight-round5.md

@@ -0,0 +1,189 @@

+# Opus production and authority review, round 5: Carloku paid launch, `aed42815..daa32cb6`

+I read `4bbe94b6..daa32cb6` as whole files. The named tests pass on an exported copy of `daa32cb6` in `$TMPDIR`. I checked every "fails without the fix" claim by mutating that copy. I also wrote scratch reproductions for the findings below. All of it ran in `$TMPDIR` and was deleted afterwards. Nothing in the repository was modified and no network command was run.

+**Production authority.**

+- **Attestation:** nothing reachable in production sets it true.

+ - The only production open is `usage.OpenDurabilityLedger(..., DurabilityLedgerOptions{})` at `internal/host/durability.go:49`.

+ - `SetAttestation` and `SetAllClientsInstrumented` have no callers outside tests and the ledger itself.

+ - `durabilityScope` has no callers outside its test.

+- **Leaks:** `safeErrorParam` passes on only `proration_date` and `quantity`. The new teardown log line names the account, app and bucket, the same as the existing console logs. I found no new identifier or secret leak.

+- **Billing:** I found no path that bills a customer wrongly by more than clock skew (see N5).

+- **Customer data:** the teardown guard still lets one path destroy a customer's data, and it leaves another customer's data where it should not be (N1, N2).

+## 1. Disposition table

+| --- | --- | --- | --- |

+| Astra R1: a retried charge and its allowance start at different instants | **Closed** | `billingservice.go:487-500`, `billingstore.go:445-472` | `TestQuantityRetryDatesTheAllowanceAtTheProrationInstant` (`billingquantity_test.go:922`), `…SeenByAWebhook…` (`:960`), `…CannotBeDatedFilesAReview` (`:987`). All three **fail** with the dating removed; `:987` also fails with the review removed. Two guards are **not pinned**: removing the `billingClockTolerance` bound (`billingstore.go:460`) or the frozen-month check (`:462-465`) fails no test. The claim "each fails with its part disabled" is overstated for those two parts. |

+| Astra R2: the observation hour bills the new owner | **Closed** | `ownership.go:359` | `TestObservationHourDoesNotResolveToTheNewOwner` (`ownership_test.go:813`) and four others **fail** with the old comparison restored. |

+| Astra R3: a missing platform statement hides the oldest month | **Closed** | `economicspass.go:1430-1466` | `TestStatementCatchUpFindsAMonthWhosePlatformStatementIsMissing` (`meterfolds_test.go:794`) **fails** with "platform missing means absent" restored. |

+| Astra R4 / Opus N3: a clock-skewed proration date is replayed for 22 hours | **Closed in code; the provider side is unconfirmed** | `billingquantity.go:606` (clamp), `:390` (compare-and-set date), `:665` (retire) | `…DatedInsideThePeriodUnderClockSkew` (`:1021`) **fails** without the clamp. `TestBeginQuantityOperationIsACompareAndSet` (`:644`) **fails** without the date check. `TestQuantityWorkerCannotChargeAcrossARenewal` (`:738`) **fails** without the retirement. Retirement relies on Stripe naming `param=proration_date`, which only the fake does today. |

+| Astra R5: the day sum depends on map order | **Closed** | `billingcalculation.go:168-187` | `TestBillingCalculationPartialMonthIsDeterministic` (`billingcalculation_test.go:358`) failed **20 of 20** runs with the sort removed. |

+| Opus N1: the compare-and-set omits plan, band, terms and item | **Closed** | `billingquantity.go:386` (revision) | `TestBeginQuantityOperationIsACompareAndSet` **fails** with the revision clause removed, and with the subscription clause removed on its own. |

+| Opus N2: a day-sum mismatch holds silently | **Closed** | `billingcalculation.go:133-140`, `billinginvoice.go:196` | `TestBillingCalculationHoldsAPartialMonthOnUnusableDays` (`:319`) **fails** when the mismatch is made quiet again. |

+| Opus N4: an unreadable statement is re-swept every pass | **Partly closed** | `economicspass.go:1394-1466` | `TestStatementMonthStateEdges` (`meterfolds_test.go:828`) **fails** when a corrupt statement counts as open. It still **passes** when a store error counts as Open instead of Unknown, so the rule "a store error concludes nothing" is not pinned. It also passes with the absent-month memory removed (an efficiency rule, so acceptable). See N6. |

+| Opus N5: a coincidental quantity is labelled charged | **Partly closed** | `billingquantity.go:721` | `TestQuantityWorkerRecordsALandedOperationAfterARenewal` (`:833`) **fails** with `charged` restored. The same-period case is still labelled `charged` (`:724`); see N8. |

+| Opus N6: the hour comparison still holds across an hour boundary | **Closed** | `durabilityfold.go:100` | `TestDurabilityFoldHoldsBeforeABoxRegisteredItsLedger` (`meterfolds_test.go:549`) **fails** with the hour truncation restored. |

+| Teardown guard (discussion 191) | **Partly closed** | `walk.go:569-584`, `:595`, `:607` | `TestRetriedTeardownLeavesABucketAnotherAppNowHolds` (`ownership_test.go:851`) and `TestTeardownOfOneSharerLeavesASharedBucket` (`:919`) both **fail** with the guard removed. The first also fails with only the scanner clause removed. Four other shapes still go wrong: a holder with no ledger interval (N2), another account holding the bucket (N1), the scanner plan (N3) and the read-to-delete window (N4). |

+## 2. New findings, most severe first

+### N1. P2: a teardown that skips a bucket another account holds leaves the torn-down app's data readable by that account, and reports success

+**Where:** `internal/objstore/walk.go:580-584` and `:607`. The cause is that `Grant` (`walk.go:258`) creates a minted name's bucket even when it already exists and holds another app's data.

+**Scenario (reproduced):**

+1. `bac/other` is granted the adopted name `ledgerBucket`, which is the name `bab/titogo` mints. It writes `secret.txt`.

+2. Its teardown fails at `EmptyBucket`, so the bucket and its data survive.

+3. `bab/titogo` is granted its minted name. `EnsureBucket` succeeds on the existing bucket, and `bab` receives credentials for a bucket that holds `bac`'s object.

+4. `bac/other`'s teardown is retried. The ledger shows `bab` open, so the bucket is skipped. `bac`'s user and record are deleted and the walk returns nil.

+**Outcome:** `bac` asked for its data to be destroyed and the walk reported success. The data stays permanently readable by another tenant. Skipping is right in two cases: the operator-shared same-account bucket, and a retry after this app's bucket was already deleted. It is wrong when another account holds a bucket that may still contain this app's objects.

+**Smallest fix:**

+- When `sharedWith` names a different account, still revoke this app's user and close its interval. Then return an error before `deleteRecordIfUnchanged`, so an operator decides what happens to the data.

+- To let the legitimate retry pass, record on the store record that `DeleteBucket` succeeded, and skip silently only when that mark is present.

+- Separately, `Grant` should refuse a minting grant when `BucketExists` is true and the ledger shows another open holder.

+### N2. P2 (pre-existing, acknowledged in a comment, not fixed): a legacy holder with no interval loses its bucket

+**Where:** `walk.go:575-579`, then `:607-616`.

+**Scenario (reproduced):** two apps share an adopted bucket that was provisioned before ledgers existed. Tearing down one finds no ledger and writes one naming only itself. It then empties and deletes the bucket, destroying the other app's data. The same happens to a legacy holder when a later grant has written a ledger that omits it.

+**Smallest fix:** when no ledger exists and the grant is not `Minted` (older blocks read false), refuse the destructive bucket steps. Revoke and close as usual, and leave the bucket for an operator. Deleting a bucket the platform never minted needs a person.

+### N3. P3: the last holder's teardown leaks a Malware Protection plan for good

+**Where:** `walk.go:595`. Whether the scanner is disabled is decided from this record's `Scanning` block only.

+**Scenario (reproduced):** apps one and two share a bucket, and only one's record has scanning enabled.

+1. Tearing down one skips the scanner, which is correct while two holds the bucket.

+2. Tearing down two deletes the bucket and never calls `EnsureDisabled`, because two's record has no `Scanning` block.

+The plan outlives the bucket and counts against the non-adjustable 25-per-region quota, and no record names it any more.

+**Smallest fix:** whenever this teardown deletes the bucket and `sc != nil`, call `EnsureDisabled(bucket)` unconditionally. It is idempotent.

+### N4. P3: the read-to-delete window includes all of `EmptyBucket`

+**Where:** `walk.go:572` (ledger read) to `:614` (delete).

+**Scenario:** the comment acknowledges a grant landing in this window, but `EmptyBucket` is paginated and can run for minutes on a large bucket. A minting grant for the name's owner can land in that window (the console lock is per app, not per bucket). It adopts the half-emptied bucket, and the bucket is then deleted under it.

+**Smallest fix:** re-read the ledger after `EmptyBucket` and immediately before `DeleteBucket`, and skip the delete if another holder has appeared.

+### N5. P3: the period-start clamp can date a proration before the addition it charges for

+**Where:** `billingquantity.go:606`. The compare-and-set at `:390` checks only the period bounds.

+**Scenario:** console A's clock is behind console B's.

+1. B reconciles a renewal and records a member addition at B's 10:00:05.

+2. A computes `created = max(now, PeriodStart)`, which can be before 10:00:05.

+3. The provider prorates from that instant, and the allowance is dated there too. The charge and the allowance agree, but the customer pays for a seat for the seconds before the member existed.

+The excess is bounded by clock skew between consoles, so it is seconds.

+**Smallest fix:** also clamp `created` to at least the newest pending addition's `occurred_at`. Have `beginQuantityOperation` refuse an operation dated before that addition.

+### N6. P3: a persistent read error on one statement hides its month from catch-up for good

+**Where:** `economicspass.go:1444-1445` (any account's `unread` returns Unknown) and `:1317` (Unknown is skipped and does not anchor `oldest`).

+**Scenario:** one account's statement key fails with a store error other than not-exist on every read, for example a persistent `AccessDenied` or KMS failure on that object.

+- Every pass classifies the month Unknown and logs it, and never sweeps it for any account.

+- Before this change the month was Open and every other account's statement could still close.

+- If it is the oldest metered month, gap months right after it also fall out of the range.

+No test pins the Unknown rule: mutating it to Open passes `TestStatementMonthStateEdges`.

+**Smallest fix:** treat an unreadable non-platform statement like a corrupt one after N consecutive passes (log once, count as present). Keep Unknown for the platform statement. Add a test case that pins Unknown.

+### N7. P2 (unwired; must be fixed before item 2 of the plan's "Not built" list): `durabilityScope` vouches for accounts the external replicator touches

+**Where:** `internal/host/durabilityscope.go:90`, `:113-130`. Each case below was reproduced against the function as written.

+- **First match wins** (`:124-125`): one config path is attributed to the first route whose path equals or encloses it, so other owners of that same path are never excluded.

+ - Nested: unit `bae`'s tree is `/var/lib/carlos-app/kass.example.com`, and hibernating exec route `bac` records `…/kass.example.com/instances/a.db`. The config names that file, the result is `unmetered=[bae]`, and `bac` is vouched for.

+ - Duplicate: two routes (`bac`, `bad`) record `/data/x.db`, and only `bac` is excluded.

+ - Fix: do not stop at the first match. Exclude every route whose path equals or encloses the config path.

+- **Unit running, config absent** (`:90` requires `ConfigPresent`): a running unit with no config file attests, with `Unmetered=[]` for a hibernating-only box. The unit may be replicating from a deleted config, or from `litestream replicate <db> <url>` arguments on its command line.

+ - Fix: `UnitActive && !ConfigPresent` attests nothing.

+ - The reader must also confirm that the unit's `ExecStart` uses that config file and passes no database arguments.

+- **Symlinks** (`ops.treeDBs` follows them through `os.Stat`, `litestream.go:300`): a unit tenant controls its own state directory. It can create `instances/y.db -> /data/<y-host>.db`. The generator then names the link, the scope attributes it to the unit's owner, and the owner of `y`, a hibernating route, is vouched for while the root replicator streams its database.

+ - Fix: the reader must resolve every config path with `EvalSymlinks`, match both the literal and the resolved path, and refuse when resolution fails.

+ - Out of this diff: the same link puts a second replicator on another tenant's WAL, which the `FleetDBs` comment says corrupts the replica. That generator behaviour deserves its own discussion.

+- **Torn reads:** routes, config paths, config mtime and unit start are four separate reads.

+ - The bad interleaving: a route flips from hibernating to always-on, the config is regenerated, and the unit restarts. If the routes and paths were read before, and the unit start after, every check passes on stale data, and the owner is vouched for while replicated.

+ - The plan's "Not built" item 2 does not cover this. The reader must take the config mtime and unit start before and after reading the paths and routes (under the registry witness) and refuse if either moved.

+ - A new exclusion must also cover the day in which the replicator could first have touched the database. A config written at 23:59 and observed at 00:01 must exclude the account on both days, not only the second.

+### N8. P3: a same-period coincidental quantity is still labelled `charged`, and its allowance is dated at an instant nobody charged from

+**Where:** `billingquantity.go:724` and `billingservice.go:497-500`.

+**Scenario:** an operation's POST never executes, and someone sets the subscription to the same target by hand in the same period.

+- The webhook dates the assignment at the operation's instant, which is earlier than the change that actually happened. The allowance is larger, so this is in the customer's favour.

+- The worker marks the additions with this operation's `charged` reference.

+This is the half of round 4 N5 that the fix did not cover. It is a record label, not a bill.

+**Smallest fix:** in the `item.Quantity == op.Target` branch, use `landed_unverified` unless this process's own POST returned success for the key.

+### N9. P3: the processing guard is dropped and recreated outside a transaction, and a rollback durably holds accounts

+**Where:** `billingquantityaudit.go:21-31`.

+- There is a window between `DROP` and `CREATE` in which an update meets no guard.

+- A rollback to the previous build makes things worse. Its open runs the old `history_gap` sweep, which treats `landed_unverified` as invalid. That marks every such account `history_unproven`, a durable hold, while its `IF NOT EXISTS` keeps the new trigger.

+This is safe in direction but costly.

+**Smallest fix:** run the drop, the create and the sweep in one transaction. Note the rollback consequence in the handoff.

+### Answers to the brief's other questions

+- **Is skipping, rather than refusing, the right behaviour?**

+ - Yes for the same-account shared adopted bucket.

+ - Yes for the retried teardown when this app's bucket is already gone.

+ - No when another account holds a bucket that may still hold this app's data (N1).

+- **`OwnerAt`:** I found no hour that resolves to someone who did not own all of it. Before `CompleteSince` is truncated to the hour, the vouching hour itself never resolves. The month projection (`evidence_month.go:107-113`) pins `CompleteSince` clamped to the month start, and that is equivalent for every hour in the month. It also pins the clipped intervals, which is everything `OwnerAt` reads.

+- **Quantity dating:**

+ - A renewal and a quantity change in one reconcile fail `provableRenewal` and file the period review.

+ - A retired or abandoned operation is acknowledged and never dates anything.

+ - A later operation with the same target has its own key and its own instant.

+ - Dating requires `latest <= quantityStart`, and ties are ordered by revision (`plans/month.go:76-81`), so `AllowanceForMonth` stays readable.

+ - Additions still pending hold the freeze, so a month cannot freeze under an outstanding operation.

+ - Two notes, neither a bill: an `always_invoice` payment failure that flips the subscription to `past_due` in the same reconcile files `billing_quantity_date_unproven`. And the 5-minute tolerance is only safe because the quantity pass has a 2-minute timeout (`billingpass.go:42`).

+- **Retirement:** a validation 400 is not saved under Stripe's idempotency key, and a concurrent replay gets a 409. So I found no case where a request treated as "did not execute" could actually have executed, and none that lets two operations run.

+- **Per-account durability days:**

+ - Exclusions are a union across boxes, and over every span inside each box's window (`UnmeteredWithin`).

+ - Any box that proves nothing, or is silent when expected, makes the day incomplete for everyone.

+ - An account with no statement of its own (deleted) is not in the universe.

+ - Exclusions are validated sqids, the same key space as statements.

+ - The live economics view does not read `SourceDays`.

+ - The day files the exclusions come from are pinned evidence.

+ - The 5-minute slack can leave up to 5 minutes of a box's first boot unmetered on a "complete" day. That undercounts, in the customer's favour.

+- **`billingUsageOnPaidDays` and the audit guard:** correct apart from N9.

+## 3. Handoff claims the code contradicts

+- **Item 5, "leaves the bucket and its scanner alone when the ledger shows another app holding it":** this is true only for holders with an interval (N2). A shared bucket's plan leaks when the last holder has no `Scanning` block (N3), and a cross-account skip keeps the torn-down app's data (N1).

+- **Item 8, "an operation refused over its date is retired at once":** retirement happens only if Stripe names `param=proration_date`, which is unconfirmed. Otherwise the operation falls back to the 22-hour limit, as the dispositions say but the handoff does not.

+- **Item 6, "A statement that will not parse is logged once":** it is logged once per process. A store read error on a statement stops the month being swept at all (N6).

+- **Dispositions, round 4 R1, "Each fails with its part disabled":** the tolerance and frozen-month guards of the dating are unpinned.

+- **Dispositions, round 4 N4, "A store error concludes nothing", pinned by `TestStatementMonthStateEdges`:** that test does not pin it.

+## 4. Verdict

+**Accept with fixes.** Fix N1 and N3, and give N2 a refusal for non-minted legacy buckets, before the teardown guard lands. Pin the two dating guards and the Unknown rule. Fix N7 in the reader and the agent call before any switch exists. Attestation stays false everywhere in production, and both flags stay unset.

diff --git a/implementation/carloku-paid-launch/AGENT_HANDOFF.md b/implementation/carloku-paid-launch/AGENT_HANDOFF.md

index 54f847a62..ddc8c57e2 100644

--- a/implementation/carloku-paid-launch/AGENT_HANDOFF.md

+++ b/implementation/carloku-paid-launch/AGENT_HANDOFF.md

@@ -30,12 +30,12 @@ When a review is approved, apply each string byte for byte: the site by replacin

1. Plans and calculations, Stripe boundary, entitlements and membership, quantity history, invoice engine: as described in the September handoff (kept in git history at `aed42815`). Unchanged in this run.

2. Console GET `/a/{sqid}/billing` (`billingpage.go`, `templates/billing.html`): current plan, owner-only chooser posting to the existing checkout door, `?country=` price preview computed from the plans terms, error and pending banners, portal button once a customer exists, read-only for members, byte-identical 404 for non-members, closed state when billing is off. `plans.Countries()` exposes the embedded country list.

-3. Durability ledger: the epoch read race is fixed (epoch and created-at are immutable after recover) with a `-race` regression. An unmetered replication fallback on a box whose ledger opened now files an escape (`DurabilityLedger.Escaped`): the box-day is incomplete and the owner is excluded for the run. A box whose ledger failed to open has no publisher and files nothing. The console fold holds a day when a box that metrics or edge expected has no ledger directory, has no day file, or is expected by the durability source for a span more than five minutes shorter. Durability days are counted per account: a box-day attested with an exclusion set is complete for every account the box did not exclude. The move worker's checkpoint is recorded against the route's owner. Attestation is still false everywhere in production, and nothing in the agent sets it.

+3. Durability ledger: the epoch read race is fixed (epoch and created-at are immutable after recover) with a `-race` regression. An unmetered replication fallback on a box whose ledger opened now files an escape (`DurabilityLedger.Escaped`): the box-day is incomplete and the owner is excluded for the run. A box whose ledger failed to open has no publisher and files nothing. The console fold asks each box's published day to prove the union of that box's durability, metrics and edge windows; a box with no ledger directory, no day file, or a ledger whose coverage starts after the box began serving holds the day for everyone. There is no tolerance. Durability days are counted per account: a box-day attested with an exclusion set is complete for every account the box did not exclude. The move worker's checkpoint is recorded against the route's owner. Scoped attestation is built end to end and is OFF: the agent attests only with `CARLOS_DURABILITY_ATTEST=scoped` in its environment, which is set nowhere. Attestation is still false everywhere in production.

4. `internal/awsbilling`: Cost and Usage Report reader (versioned deliveries only), newest-delivery selection, digests, charged S3 transfer classifier. It holds on a charged usage line it does not count and on any non-usage line (fee, refund, credit, discount) with a cost on a transfer usage type. Every transfer usage type the flagship account wrote from July to September 2026 is pinned in a test.

-5. `internal/objstore/ownership.go`: append-only bucket ownership ledger, opened at grant, closed at teardown. It resolves an owner only for a ledger that claims completeness, and only for hours that begin at or after the instant it began vouching (a store's first clock hour never resolves). Completeness needs a grant block recorded as minting, nothing delivered to the app yet, a probe showing the bucket does not exist, and an inventory showing no principal's policy names the bucket (`GranteeProber`). The AWS provisioner cannot list principals yet, so on AWS no ledger claims completeness, new stores included, and store transfer holds. Teardown records a legacy store, incomplete, before destroying anything; closes the interval only after the credentials are revoked; and leaves the bucket and its scanner alone when the ledger shows another app holding it (discussion 191).

-6. Statement folds: `console/durabilityfold.go` (`durability_writes_1k`, policy in `usage.BillableReplicationWrites`) and `console/storeegressfold.go` (`store_egress_gb`). `usage.MeterSource` names a source for both meters. Month evidence pins ownership ledgers by their month projection and knows the durability box directory. Statements carry the five billed meters by UTC day (`Statement.Days`), summing to the monthly totals; the other meters are not recorded by day. With a transfer report configured, the statements catch-up walks a 36-month window and sweeps every month that has an open statement, is missing a statement an account is owed (the platform's included), or is a gap between metered months. A statement that will not parse is logged once and not swept for.

+5. `internal/objstore/ownership.go`: append-only bucket ownership ledger, opened at grant, closed at teardown. It resolves an owner only for a ledger that claims completeness, and only for hours that begin at or after the instant it began vouching, so a store's partial first hour never resolves (a ledger that began vouching exactly on the hour answers for that hour). Completeness needs a grant block recorded as minting, nothing delivered to the app yet, a probe showing the bucket does not exist, and an inventory showing no principal's policy names the bucket (`GranteeProber`), and is dated when both probes had answered. The AWS provisioner cannot list principals yet, so on AWS no ledger claims completeness, new stores included, and store transfer holds. A minting grant is refused while another app holds the name. Teardown decides by compare-and-swap on the ledger: if nobody else holds the bucket (by ledger interval or by store record) it marks the bucket as being destroyed, which refuses every grant of the name until it has finished; otherwise it leaves the bucket and its scanner, revokes its own credentials, and records that the scanner is owed. A teardown that leaves a bucket to another account keeps its record and returns `ErrBucketRetained` (discussion 191).

+6. Statement folds: `console/durabilityfold.go` (`durability_writes_1k`, policy in `usage.BillableReplicationWrites`) and `console/storeegressfold.go` (`store_egress_gb`). `usage.MeterSource` names a source for both meters. Month evidence pins ownership ledgers by their month projection and knows the durability box directory. Statements carry the five billed meters by UTC day (`Statement.Days`), summing to the monthly totals; the other meters are not recorded by day. With a transfer report configured, the statements catch-up walks a 36-month window and sweeps every month that has an open statement, is missing a statement an account is owed (the platform's included), or is a gap between metered months. A statement that will not parse, or that cannot be read three passes running, is reported once per process and the month is classified without it. A month seen with no statement is remembered for six hours, a closed statement for the life of the process.

7. Operator API doors (`billingoperator.go`): list and resolve billing review holds, list and set the house marker. No CLI verb yet.

-8. Team quantity worker (`billingquantity.go`) behind `CONSOLE_BILLING_PRORATION` (`immediate` or `next_invoice`). Unset, which is how it must stay until Paul decides, it makes no provider call. An operation is recorded by a compare-and-set on the billing row's revision, subscription, period, quantity and status, on the target and newest pending addition recomputed from the database, and on its own instant lying inside the period. The request dates its proration at that instant (`proration_date`), which the provider is expected to refuse after a renewal; an operation refused over its date is retired at once. The assignment the landing creates takes effect at the same instant, so a seat's charge and its allowance start together, or a review holds the account. The provider's side of this is taken from Stripe's documentation and has not been confirmed in test mode. Only additions of the subscription's current period can raise it; older ones are closed uncharged with a review; additions and operations of an ended subscription are closed. It does not yet lower the quantity at renewal.

+8. Team quantity worker (`billingquantity.go`) behind `CONSOLE_BILLING_PRORATION` (`immediate` or `next_invoice`). Unset, which is how it must stay until Paul decides, it makes no provider call. An operation is recorded by a compare-and-set on the billing row's revision, subscription, period, quantity and status, on the target and newest pending addition recomputed from the database, and on its own instant lying inside the period and not before the addition it charges for. The request dates its proration at that instant (`proration_date`). A sender re-reads its operation before sending and does not send one that has been retired; an operation dated ahead of the observing clock is left alone. An operation is confirmed only by the provider's success answer to its own request. A confirmed landing takes effect at the operation's instant, so a seat's charge and its allowance start together; a quantity that merely matches an unconfirmed operation's target is recorded as `landed_unverified`, dated when observed, with a review. If the provider refuses a request and names `proration_date`, the operation is retired at once; if it does not name it, the operation waits out the 22-hour replay limit. None of the provider's side is confirmed: test mode is not authorized. Only additions of the subscription's current period can raise it; older ones are closed uncharged with a review; additions and operations of an ended subscription are closed. It does not yet lower the quantity at renewal.

9. Stripe provisioning plan `stripe-provisioning.md` and print-only `stripe-provision.sh` (verified never to invoke the CLI).

10. Partial-month billing: `plans.AllowanceForMonth` returns the paid spans of a month and the allowance weighted over them. A partly covered month (a first month, a month a subscription ends in, a lapse) bills only the UTC days wholly inside a paid span, against that allowance, and records the days it counted. Completeness is still whole-month. **The whole-paid-day rule is not in the approved spec, which speaks only of prorating the allowance. It is a proposal that needs Paul's approval; the plan document states what it rounds away and the tests that pin its boundary.** A month with a paid span and no whole paid day bills nothing. A month with no paid span is refused quietly. Two subscriptions in one month price and then hold on `billing_invoice_identity_mixed`.

11. Plans: `docs/superpowers/plans/2026-10-01-store-transfer-cur-collector.md`, `2026-10-01-durability-attestation-path.md`, `2026-10-01-bucket-ownership-attestation.md`, `2026-10-01-partial-month-billing.md` (built).

@@ -45,7 +45,7 @@ When a review is approved, apply each string byte for byte: the site by replacin

The monthly freeze requires all five billed meters complete. Two cannot be, in production, today:

- `store_egress_gb`: no Cost and Usage Report export exists, so the source is unconfigured. It needs the scoped infrastructure approval in the collector plan, a first real delivery, a principal inventory in the AWS provisioner, and attested ownership for the stores that already exist. A read-only look at the account's billing on 2026-10-01 (collector plan) found no export, no credit or discount line on S3 from July to September, no free transfer allowance reaching the account, and 1,395 GB of inter-region transfer out of Ireland in September that looks like the platform's own bucket.

-- `durability_writes_1k`: no box attests, because the external `carlos-litestream` binary replicates unit-backed and always-on routes outside the ledger. The chosen way out is the scoped attestation (attestation plan, "Decision and progress"): its console half and scope computation are built and tested, and the reader of the replicator's state and the agent's call are not. Do not set the flag to pass a test.

+- `durability_writes_1k`: no box attests, because the external `carlos-litestream` binary replicates unit-backed and always-on routes outside the ledger. The chosen way out is the scoped attestation (attestation plan, "Decision and progress"), built end to end behind a switch that is off. Before it may be set anywhere: an independent review of the call and the reader, a week on a dev box, the flagship's hand-kept litestream config cut over to the generated one, and a scoped approval. Do not set the flag to pass a test.

## Still missing from the full requirements audit

@@ -58,7 +58,9 @@ The monthly freeze requires all five billed meters complete. Two cannot be, in p

- Dormancy archive and warnings, recognised-revenue pool accounting at 15 percent, the books site: not started.

- Statement rebuild door for a closed month: missing.

- An operator verb to backfill bucket ownership for existing stores: missing.

-- A store's first clock hour holds the month if it has a charged line, and nothing releases the hold. Needs a decision before the AWS principal inventory lands (collector plan).

+- A store's partial first hour holds the month if it has a charged line, and nothing releases the hold. Needs a decision before the AWS principal inventory lands (collector plan).

+- A box whose ledger opened after the box began serving holds that day for everyone. Whether a box's first minutes may be waved through is undecided, so they hold.

+- Rolling back to a build from before `5f2b4faf` on a database that has recorded a `landed_unverified` outcome marks those accounts `history_unproven`, a durable hold: the older build's audit sweep does not know the outcome. Nothing has recorded one (the proration switch is unset).

## Verification in this run

@@ -73,7 +75,7 @@ Merchant `acct_1UD7LXI4Nrr6AEsO`, Team Tito Limited, Ireland, EUR; Irish standar

## Next actions, in order

1. Apply approved copy from both reviews when `result.json` arrives.

-2. Independent review: Astra rejected rounds 1 to 4 (ten, eight, five and five findings); Opus accepted with fixes three times (eight each). All were accepted and fixed with reproductions (`docs/superpowers/specs/CODEX-DISPOSITIONS-carloku-paid-launch-overnight.md`). Round five of both must pass on the exact tip before anything lands; do not read "fixed" as "accepted". The scoped-attestation code and the teardown guard have had no independent review yet.

+2. Independent review: Astra rejected rounds 1 to 5 (ten, eight, five, five and eleven findings); Opus accepted with fixes four times (eight, eight, eight, nine). All were accepted and fixed with reproductions (`docs/superpowers/specs/CODEX-DISPOSITIONS-carloku-paid-launch-overnight.md`). Round six of both must pass on the exact tip before anything lands; do not read "fixed" as "accepted". The agent's attestation call and the rewritten teardown decision have had no independent review yet.

3. Scoped approvals: Cost and Usage Report export; Stripe catalog, portal, webhook and the `rk_live` key; then a test-mode rehearsal and a real purchase.

4. Build the principal inventory and the bucket ownership attestation (designed in `docs/superpowers/plans/`), quantity reduction at renewal, a `carlos` verb and documentation for the operator doors, then Free-tier enforcement.

-5. Finish the scoped attestation: the reader of the replicator's state, the agent's call behind a switch, their review, a week on dev. Until then replication writes hold every month.

+5. Take the scoped attestation through its review, a week on dev and the flagship's config cutover. Until then replication writes hold every month.