carlos / platform Public

Decision 16: the design is at revision 6

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

claude 3 weeks ago 1bda76a744cca018199ebff56210fe89b5c12ac8 parent 68b16c5

1 file changed, +1 −1

implementation/carloku-paid-launch/DECISIONS-FOR-PAUL.md +1 −1

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 c3e38be4f..f5622cc90 100644

--- a/implementation/carloku-paid-launch/DECISIONS-FOR-PAUL.md

+++ b/implementation/carloku-paid-launch/DECISIONS-FOR-PAUL.md

@@ -53,7 +53,7 @@ Context: the overage invoice for a month is one line per meter, and every line c

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 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`:

+ Four refinements are choices too, found by the design's reviews (`docs/superpowers/specs/2026-10-03-per-line-tax-codes-design.md`, revision 6; 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.