amadan
pricing: codex review brief for the pricing spec
Committed so a quota-interrupted review can restart from the same instructions against the same commit.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XUCJBDGHJoA8PbaTCo4zoD
1 file changed,
+89
−0
docs/superpowers/specs/CODEX-REVIEW-BRIEF-carloku-pricing.md+89 −0
diff --git a/docs/superpowers/specs/CODEX-REVIEW-BRIEF-carloku-pricing.md b/docs/superpowers/specs/CODEX-REVIEW-BRIEF-carloku-pricing.md| new file mode 100644 |
| index 000000000..2007f56bf |
| --- /dev/null |
| +++ b/docs/superpowers/specs/CODEX-REVIEW-BRIEF-carloku-pricing.md |
| @@ -0,0 +1,89 @@ |
| +# Codex review brief — Carloku pricing spec |
| + |
| +You are GPT-6, acting as an **independent second reader** on a design spec |
| +written by Claude. Your job is to find what the author's context hid from |
| +them. A prior review in this repo found six P1 mechanism failures in a |
| +roadmap the author believed was sound, so read adversarially. |
| + |
| +## What to review |
| + |
| +**Spec:** `docs/superpowers/specs/2026-09-07-carloku-pricing-plans-design.md` |
| +**Commit:** `1dc2494` on branch `worktree-pricing-plans-spec` |
| +**Repo:** carlos/platform — a bucket-as-control-plane deployment platform. |
| +Carloku is its flagship public deployment. `AGENTS.md` is the guide for |
| +agents working here. |
| + |
| +Read the spec, then verify its claims against the actual code. Every file |
| +and line reference in the spec is checkable — check them. |
| + |
| +## Context you need |
| + |
| +Two earlier specs were **deleted from the tree** in the open-source redaction |
| +pass and are only in git history. Read them, they are the approved ground |
| +this spec builds on: |
| + |
| + git show 2adc71f^:docs/superpowers/specs/2026-08-13-carloku-business-model-design.md |
| + git show 2adc71f^:docs/superpowers/specs/2026-08-11-unit-economics-design.md |
| + |
| +The metering machinery is **built and live**. Key files: `internal/usage/` |
| +(frozen meter vocabulary), `internal/economics/` (rate card, scenarios, |
| +pricing arithmetic), `internal/console/economicspass.go` (the hourly |
| +collection pass), `internal/console/economicsview.go` (the pool ledger), |
| +`internal/activator/activator.go` (hibernation). |
| + |
| +## Rulings that are FIXED — do not re-argue these |
| + |
| +Paul decided these in conversation on 2026-09-07. Report only mechanisms |
| +that fail to honour them, never the decisions themselves: |
| + |
| +1. Yearly subscriptions only. No monthly option. |
| +2. Three plans (Personal, Community, Business) replace the Hosted rung. |
| + Fleet and Dedicated survive unchanged and are out of scope here. |
| +3. The customer-facing compute unit is **awake hours**, not memory GB-hours. |
| +4. A billable member is **a person with console access to the account**. |
| + App end-users are never counted. |
| +5. Overage is metered and billed monthly in arrears, not prepaid, not refused. |
| +6. The 50% no-questions-asked price is a public promotion code. |
| +7. One free tier, funded by the revenue pool. Try and the old free pool merge. |
| +8. The 80/20 margin rule, indexed by a global affordability index. |
| +9. Dormant free apps are archived at 90 days and restorable, never deleted. |
| +10. Free durability is hibernate-flush only. |
| +11. Stripe is the processor, EUR settlement, live account |
| + `acct_1UD7LXI4Nrr6AEsO` (Ireland). |
| + |
| +## What I want from you |
| + |
| +Ordered by how much I care: |
| + |
| +1. **Mechanism failures.** Where will this break in production? Race |
| + conditions, double-billing, silent no-ops, states the design does not |
| + cover. The overage pass runs hourly against a monthly boundary and talks |
| + to a payment processor — that is the highest-risk surface here. |
| +2. **Stripe API errors.** The spec makes specific claims about Checkout |
| + coupon slots, Adaptive Pricing constraints, €0 subscriptions producing no |
| + PaymentIntent, subscription quantity proration, and `automatic_tax` |
| + failing silently without registrations. Verify them. Flag anything that is |
| + wrong, out of date, or true but incomplete in a way that matters. |
| +3. **Arithmetic and unit errors.** Every table in the spec was computed from |
| + `internal/economics/scenario.go` anchors at USD→EUR 0.92. Recompute them. |
| + Check the break-even claims and the constant-margin claim across index |
| + bands. An earlier draft in this repo's history shipped a cost×1.2 error |
| + that survived in people's heads for weeks. |
| +4. **Gaps between the spec and the code.** The spec asserts things exist |
| + (frozen meters, the pool ledger, the static app kind, statement files, |
| + the tier column). Verify each. Also flag anything the spec assumes it can |
| + read that the metering does not actually capture. |
| +5. **Anything the spec prices that it cannot measure**, or measures but does |
| + not price, given the frozen meter vocabulary in `internal/usage/usage.go`. |
| + |
| +## What good output looks like |
| + |
| +A numbered list of findings, most severe first. For each: a one-line claim, |
| +the file:line or spec section it concerns, why it fails, and what to do |
| +instead. Cite real code — I will verify every citation before accepting a |
| +finding, and a citation that does not hold discredits the finding. |
| + |
| +Say plainly if a section is sound. Do not manufacture findings to fill a |
| +list. A mechanism that is named, bounded and assigned to an implementation |
| +step is complete at spec level — do not pull implementation-plan depth |
| +upward into a design spec. |