carlos / platform Public

pricing: record a seventh billing prerequisite, the box lifecycle record

Found by the whole-branch review of the plan that implements the first
three. Completeness asks whether every discovered box reported a day,
and boxes are discovered by listing what has ever written. So a box
provisioned on 2 September has no August day objects and August reads
incomplete for every account, permanently once the month closes.

The decommission direction was already an accepted fail-safe bound.
This is the same mechanism running the other way, and it is not a
corner case: any month in which fleet capacity changed can never report
complete, which is most months on a growing platform.

Scoping discovery to boxes that produced something in the period would
reintroduce exactly the hole the third prerequisite closes, where a
silent box vouches for itself by staying silent. It needs a first-seen
and decommissioned-at record instead. Recorded, not built.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Paul Campbell pushed by paul@keymail.dev 1 month ago 1775c912bed8718e0adf47a9bf434471154788e0 parent a220b83

2 files changed, +20 −2

docs/superpowers/plans/2026-09-08-invoice-grade-statements.md +1 −1
docs/superpowers/specs/2026-09-07-carloku-pricing-plans-design.md +19 −1

diff --git a/docs/superpowers/plans/2026-09-08-invoice-grade-statements.md b/docs/superpowers/plans/2026-09-08-invoice-grade-statements.md

index 31a3d713f..970d5109c 100644

--- a/docs/superpowers/plans/2026-09-08-invoice-grade-statements.md

+++ b/docs/superpowers/plans/2026-09-08-invoice-grade-statements.md

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

**Tech Stack:** Go, no new dependencies. Deployment-bucket JSON objects via `release.Store`.

-**Spec:** `docs/superpowers/specs/2026-09-07-carloku-pricing-plans-design.md` — this plan is build steps 1–3 of that spec's "Needs building" list, the first three of six prerequisites that gate raising any invoice.

+**Spec:** `docs/superpowers/specs/2026-09-07-carloku-pricing-plans-design.md` — this plan is build steps 1–3 of that spec's "Needs building" list, the first three of the prerequisites that gate raising any invoice (six at the time of writing; a seventh, a box lifecycle record, was found by this plan's own whole-branch review and added to the spec).

## Global Constraints

diff --git a/docs/superpowers/specs/2026-09-07-carloku-pricing-plans-design.md b/docs/superpowers/specs/2026-09-07-carloku-pricing-plans-design.md

index 715bde211..d4b48659f 100644

--- a/docs/superpowers/specs/2026-09-07-carloku-pricing-plans-design.md

+++ b/docs/superpowers/specs/2026-09-07-carloku-pricing-plans-design.md

@@ -501,6 +501,24 @@ must not claim otherwise.

section above: `durability_writes_1k` is a new meter, not a reuse of

`requests_1k`.

+**P7. A box needs a lifecycle record (found 2026-09-10, in the whole-branch

+review of the plan implementing P1–P3).** Completeness asks whether every

+discovered box reported a given day, and boxes are discovered by listing what

+has *ever* written. So a box provisioned on 2 September has no August day

+objects, and August reads as incomplete for every account — permanently, once

+the month closes. The decommission direction was already accepted as a

+fail-safe bound; this is the same mechanism running the other way, and it is

+not a corner case. **Any month in which fleet capacity changed can never

+report complete**, which is most months on a growing platform.

+The fix is not to scope discovery to "boxes that produced something in the

+period" — that reintroduces exactly the hole P3 closes, where a silent box

+vouches for itself by staying silent. It needs a first-seen and

+decommissioned-at record per box, so a box is only expected on the days it

+existed. Recorded here rather than built: it is a seventh prerequisite, and

+without it "safe to bill from" is unreachable in practice however good the

+other six are.

Only then does the monthly step run:

1. read the **closed** month's statement, after the catch-up stage has

@@ -543,7 +561,7 @@ usage-based billing to Metronome, but our statements are already the source of

truth, computed hourly against real AWS bills. Paying a second metering system

to recount what we already count would add a reconciliation surface and remove

none. This is a deliberate departure from the default recommendation and is

-recorded as such. It does mean the six prerequisites above are ours to build

+recorded as such. It does mean the seven prerequisites above are ours to build

rather than bought, which is the honest cost of the choice.

**Quantity proration is a choice, not a default.** Adding a member prorates,