amadan
Decision 16: the box side needs no change, activation is a reviewed change of its own, and 16d names the pass's conditions
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
1 file changed,
+3
−3
implementation/carloku-paid-launch/DECISIONS-FOR-PAUL.md+3 −3
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 9a1670544..0e3018587 100644 |
| --- a/implementation/carloku-paid-launch/DECISIONS-FOR-PAUL.md |
| +++ b/implementation/carloku-paid-launch/DECISIONS-FOR-PAUL.md |
| @@ -51,13 +51,13 @@ Context: a store bucket's transfer is billed to its tenant only if the ledger ca |
| 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. |
| -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's daily usage then has to be carried for every month, not only for a partly covered one, which is a small change 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). |
| +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 review (`docs/superpowers/specs/2026-10-03-per-line-tax-codes-design.md`, revision 2); the design builds so that any answer is one body of one function and chooses none of them: |
| + 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`: |
| - **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. |
| - - **16d, months already held.** A month held today stays held until an operator resolves its review (`carlos billing resolve`); the next pass then prices it under the chosen rule. All at once on the day, or case by case. |
| + - **16d, months already held.** A month held today stays held until an operator resolves its review (`carlos billing resolve`); the pass then prices it under the chosen rule only when no other review of the account is open (release is account-wide where others remain), its retry backoff has passed, and the month is within the pass's twelve-month lookback; an older held month is not scheduled by resolving its review and needs its own handling. All at once on the day, or case by case. |
| ## What each answer unblocks |