amadan
Decisions file corrected: stage 1 of the retirement protocol is designed, not built; the flush-only class's contract is a decision (10a) and nothing of its options is built
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
1 file changed,
+8
−5
implementation/carloku-paid-launch/DECISIONS-FOR-PAUL.md+8 −5
CI passed — run details
diff --git a/implementation/carloku-paid-launch/DECISIONS-FOR-PAUL.md b/implementation/carloku-paid-launch/DECISIONS-FOR-PAUL.md| index 1d24ab498..92015babf 100644 |
| --- a/implementation/carloku-paid-launch/DECISIONS-FOR-PAUL.md |
| +++ b/implementation/carloku-paid-launch/DECISIONS-FOR-PAUL.md |
| @@ -1,15 +1,15 @@ |
| # Decisions for Paul, in one place |
| -Written 2026-10-02, 11:05 Dublin. Each item is a choice only Paul can make, with what was proposed and what it unblocks. Nothing here is decided. Billing is off; nothing was deployed. The lettered approvals A to M (copy, proration, partial month, test mode, live provisioning, the book, the cutover note, and the meters' G, H, J, K) are in `OUTSTANDING.md` and `ENABLEMENT.md` section 8 and are not repeated here. |
| +Written 2026-10-02, 11:02 Dublin; items 2 and 10a revised 11:04 after two more reviews. Each item is a choice only Paul can make, with what was proposed and what it unblocks. Nothing here is decided. Billing is off; nothing was deployed. The lettered approvals A to M (copy, proration, partial month, test mode, live provisioning, the book, the cutover note, and the meters' G, H, J, K) are in `OUTSTANDING.md` and `ENABLEMENT.md` section 8 and are not repeated here. |
| Answer by number. "As proposed" is a complete answer to any of them. |
| ## A. A refused purchase (multi-currency branch; blocks its merge) |
| -Context: when a checkout is refused (wrong currency, a hand-made subscription), the console files a review and holds the account. Review eighteen found that an operator's `retire` can delete the purchase while its checkout page is still payable. The fix is a recorded protocol, designed in `2026-10-02-intent-retirement-protocol-design.md` (multi-currency branch). **This defect is open in code.** The first stage needs none of these answers: it lets an operator retire only an expired, unpaid checkout, or keep a corrected paid one, and holds everything else. These decide what happens to what is held. |
| +Context: when a checkout is refused (wrong currency, a hand-made subscription), the console files a review and holds the account. Review eighteen found that an operator's `retire` can delete the purchase while its checkout page is still payable. The fix is a recorded protocol, designed in `2026-10-02-intent-retirement-protocol-design.md` (multi-currency branch). **This defect is open in code.** The design has been reviewed three times and rejected three times; each review narrowed what can be built without your answers. What can be built without your answers (stage 1, designed, not built yet) lets an operator retire only an expired, unpaid checkout that no other subscription is attached to, or keep a corrected paid one that no other subscription is attached to, and holds everything else: anything paid and not kept, anything a hand-made subscription touched, anything Stripe contradicted itself about, and every review opened before the new build. These decide what happens to what is held. |
| 1. **Money taken on a refused purchase.** May the platform ever keep it without recording a purchase (a one-off)? Proposed: no. It is refunded and the case closed as settled, or corrected at Stripe and kept. |
| -2. **What "settled" requires.** Before a paid, refused purchase can be closed. Proposed: the payment refunded in full (a refund that has succeeded, not one pending), the subscription it created canceled, no open or collectible invoice on it; the operator names the refund and the subscription; the console checks the subscription is canceled and holds the case while a refund is pending. |
| +2. **What "settled" requires.** Before a refused purchase that took money, or that a hand-made subscription was attached to, can be closed. Proposed: for every subscription attached to the case (the checkout's own and any made by hand), the payment refunded in full (a refund that has succeeded, not one pending), the subscription canceled, no open or collectible invoice on it; the operator names each refund and subscription; the console checks each subscription is canceled and holds the case while a refund is pending. Canceling a subscription is not by itself settling it. |
| 3. **Stripe contradicting itself** about one checkout (expired, then paid; or its account changed). Proposed: hold the account and let a person close it only after a fresh read of Stripe agrees with what they are closing it as; no exception for a checkout whose account stays wrong (it stays held). |
| 4. **A checkout the console never bound** (its creation answer was lost, and it was found paid later). May it be kept as the purchase? Proposed: no; it can be closed (expired or settled), never kept. |
| 5. **What the buyer sees** while their purchase is under review. Proposed copy, for review: "we are checking this purchase. nothing more will be charged. we will email you." |
| @@ -24,10 +24,12 @@ Context: the approved rule is "people who leave come off at renewal". The design |
| ## C. The Free plan |
| -Context: the approved Free plan (3 apps, 100 awake hours, 250 MB, 1 GB egress, 2-minute hibernation, flush-only durability) has no enforcement in code. One piece is built and needs no decision (the flush-only replication class, `feat/carloku-flush-only-class-20261002`). The rest starts with: |
| +Context: the approved Free plan (3 apps, 100 awake hours, 250 MB, 1 GB egress, 2-minute hibernation, flush-only durability) has no enforcement in code. One piece was started on the assumption it needed no decision (the flush-only replication class, `feat/carloku-flush-only-class-20261002`); its first review (Opus accept with fixes, Astra reject) showed its durability contract needs one, item 10a. The rest starts with: |
| 9. **Who is Free on the day it is switched on.** Proposed: every account with no paid subscription and no house marker, from a date announced beforehand; an account over a Free cap that day keeps what it has and can add nothing until it is under the cap (no app is stopped or archived by the switch); house accounts are unaffected. |
| +10a. **What "flush-only" promises.** The approved wording is "hibernate-flush only: no continuous replication, no restore to an earlier moment". As built (replicate at wake and at sleep, nothing between) review found three things: the vendored replicator still uploads a full snapshot once a day while an app is awake; everything written while awake waits on the box for the flush at sleep, which has 30 seconds, so a long-awake app's sleep may not be durable; and the restore drill reads the intended lag as a failure. Options: (a) a backstop copy at a fixed interval while awake (an hour was suggested: a Free app is awake at most 100 hours a month); (b) no backstop, and the flush at sleep given as long as it needs, with the app not reported asleep until it finishes, which changes how every class sleeps; (c) Free uses the existing daily class, and flush-only is not built. Nothing is built for any of the three; the branch stays unmerged until you choose. |
| + |
| ## D. The platform's own replicator (replication-writes meter; unwired) |
| Context: `feat/carloku-metered-replicator-20261001` has had twenty builds; Opus accepts, Astra rejects on items that need a design, not another build. These decide what that design must do. |
| @@ -41,8 +43,9 @@ Context: `feat/carloku-metered-replicator-20261001` has had twenty builds; Opus |
| | Answers | Unblocks | |
| | --- | --- | |
| -| 1 to 4 | stage 2 of the retirement protocol (closing paid and contradicted cases); stage 1 is built without them | |
| +| 1 to 4 | stage 2 of the retirement protocol (closing paid and contradicted cases). Stage 1 needs none of them; it is designed and **not built** as of this file, and the defect it answers is open in code until reviewed, tested code closes it | |
| | 5 | the billing page under review; with the 40 billing strings (approval A) | |
| | 6 to 8 | the reduction design's second draft, then team plans | |
| | 9 | the Free entitlement, the app cap, per-plan idle, storage refusal | |
| +| 10a | the flush-only class's contract. The branch has the class with a ten-year interval, which both reviews showed does not give "wake and sleep only" and can leave sleep not durable; the hourly backstop is a proposal and is **not built** | |
| | 10 to 13 | the replicator's design for the deferred items, then wiring, then the replication-writes meter | |