amadan
Decision 16: the mechanics are built behind the hold; activation switches freeze to the glue; revision 5
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
1 file changed,
+2
−2
implementation/carloku-paid-launch/DECISIONS-FOR-PAUL.md+2 −2
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 0e3018587..c3e38be4f 100644 |
| --- a/implementation/carloku-paid-launch/DECISIONS-FOR-PAUL.md |
| +++ b/implementation/carloku-paid-launch/DECISIONS-FOR-PAUL.md |
| @@ -49,11 +49,11 @@ Context: a store bucket's transfer is billed to its tenant only if the ledger ca |
| ## F. A month in which the plan changed (per-line tax codes; OUTSTANDING item 17) |
| -Context: the overage invoice for a month is one line per meter, and every line carries one product tax code. Personal and Community share one code (`txcd_10102001`, software for personal use) and Business has another (`txcd_10102000`, software for business use). Allowances are already time-weighted across a month's paid spans and overage rates are per currency, not per plan, so a plan change inside a month changes nothing in the money; it changes which tax code the overage lines should carry. Today a month whose paid spans carry two tax codes (a change to or from Business) is not invoiced: it holds with a review (`billing_invoice_tax_code_mixed`) for a person. Nothing is built for it. |
| +Context: the overage invoice for a month is one line per meter, and every line carries one product tax code. Personal and Community share one code (`txcd_10102001`, software for personal use) and Business has another (`txcd_10102000`, software for business use). Allowances are already time-weighted across a month's paid spans and overage rates are per currency, not per plan, so a plan change inside a month changes nothing in the money; it changes which tax code the overage lines should carry. Today a month whose paid spans carry two tax codes (a change to or from Business) is not invoiced: it holds with a review (`billing_invoice_tax_code_mixed`) for a person. The mechanics either answer needs are built behind that hold on `design-per-line-tax-codes`; nothing chooses an answer. |
| 16. **Which tax code an overage line carries when the plan changed during the month.** Proposed: split by span, so each meter has one line per tax code, with the usage of each UTC day attributed to the plan in force on that day and each line taxed by that plan's code (the amounts in total are unchanged; the box already writes the daily usage every statement needs, so nothing changes on the box side). The alternative: one line per meter taxed by the plan in force at the month's end, which needs no daily split and is a simpler invoice but taxes some days' usage under the other plan's code. If the accountant says one code per invoice is acceptable in that case, the alternative is the smaller build; otherwise the split. Until either is chosen the hold stays, and it is rare (a change to or from Business in a month with overage). |
| - Four refinements are choices too, found by the design's reviews (`docs/superpowers/specs/2026-10-03-per-line-tax-codes-design.md`, revision 4; built on `design-per-line-tax-codes`); the mechanics for either answer are built behind the hold and choose none of them. Activation after the answer is a reviewed change on its own: the switch in `taxCodesForLines`, the glue that prices a two-code month (built, uncalled), its tests, and the roll rule in `ENABLEMENT.md`: |
| + Four refinements are choices too, found by the design's reviews (`docs/superpowers/specs/2026-10-03-per-line-tax-codes-design.md`, revision 5; built on `design-per-line-tax-codes`); the mechanics for either answer are built behind the hold and choose none of them. Activation after the answer is a reviewed change on its own: `freeze` switched from the hold to the glue that prices a two-code month (`twoCodeCalculation`, built and uncalled) with the decided body, its tests through `freeze`, and the roll rule in `ENABLEMENT.md`: |
| - **16a, the change day.** The box records usage by UTC day, so a day a plan changed on cannot be split exactly. Proposed: the day follows the plan in force at its start (00:00 UTC). |
| - **16b, how a meter's unchanged amount is divided between the two codes.** Proposed: in proportion to the usage under each plan. Alternatives: by each span's own excess over its share of the allowance (a span that stayed under its allowance gets nothing), or by using up the pooled allowance in time order and attributing only what came after. Example, allowances 100 and 100, usage 50 then 250, overage 100: the proposal gives the first span a sixth of it, the alternatives nothing. None changes the amount. |
| - **16c, no paid plan at the month's end.** If "the month-end plan" is chosen and the last paid span ended before the month did (a cancellation), the last paid span's code, or a hold. |