fix: record subscription sale as a signed payment (close off-book hole)

Creating a priced subscription wrote only the mutable `subscriptions`
master row and appended NOTHING to the signed ledger — so the cash an
operator collected showed in the live feed, drawer, and shift Z-report
nowhere, leaving no signed trace. A booth operator could sell
subscriptions and pocket the money untraceably — the exact
operator-as-adversary path the append-only signed ledger exists to close.
Found live: 3 priced subscriptions (27,000 ALL) had zero payment events.

Selling a priced subscription now appends a signed `payment` event at
create time: amount = priceMinor x months (full multi-month prepay),
operator-chosen tender (cash->drawer / card->bank), payload
{ subscriptionSale: true, permitId, operator, months }. Folds into the
shift Z-report/drawer with no new summing logic; the feed badges it
"subscription sale" and resolves the holder name. The create response
returns the recorded { sale }; subscriptionRoutes now takes the EventLog
and ShiftService.

Not hard-gated on an open shift (a sale can happen outside the booth money
path) — it warns instead. The 3 historical off-book sales are not
back-fillable (append-only forbids forging dated events) — reconcile via
cash_movement or a Z-report note.

Verified against a copy of the live DB with the real signing modules:
signed payment appended, hash-chain still verifies, lands in shift cash
totals. Build + lint 12/12.

Wiki: subscription "Collecting the fee" deferred -> BUILT (+ the off-book
hole and why); shift sale-folds-in; threat-model worked example
("store the price != account for the sale").

Claude-Session: https://claude.ai/code/session_01Xcm6ikLgGoCxxHrxtjkk5V

wiki/concepts/shift.md

@@ -2,7 +2,7 @@
 type: concept
 tags: [parking, domain, business, shifts, anti-fraud]
 sources: []
-updated: 2026-06-19
+updated: 2026-06-20
 status: open
 ---
 
@@ -64,8 +64,11 @@ login ————————————————————————
 
 1. Determine the shift's payment set: the signed `payment` events ([[parking-session]],
    [[append-only-event-chain]]) between this shift's start mark and now. This includes a
-   **[[subscription]] fee** an operator collects during the shift (sold/renewed at the booth → a
-   signed `payment`, deferred build) — it folds into this set like any transient taking.
+   **[[subscription]] sale fee** an operator collects during the shift (selling/renewing at the booth
+   appends a signed `payment` with `subscriptionSale: true`, amount `priceMinor × months` — **built
+   2026-06-20**) — it folds into this set like any transient taking, no special-casing. *(Before that
+   date subscription sales appended nothing, so the cash was off the Z-report entirely — a real
+   [[threat-model]] hole; see [[subscription]] "Collecting the fee".)*
 2. Sum by **tender**: `cashTotal`, and `cardTotal` from the POS/terminal **if a POS is configured**
    (the card line is omitted when there's no terminal).
 3. Append a signed **`shift_z_report`** event (type already in `packages/shared`): `{ operator,

wiki/concepts/threat-model.md

@@ -2,7 +2,7 @@
 type: concept
 tags: [parking, security, foundational]
 sources: [parking-system-architecture]
-updated: 2026-06-14
+updated: 2026-06-20
 ---
 
 # Threat Model
@@ -36,6 +36,17 @@ The same reframing recurs at the device layer: the [[uhppote-controller]]'s real
 unauthenticated commands ([[uhppote-udp-protocol]]), addressed by detection
 ([[event-log-ingestion]]) or prevention ([[esp32-custom-controller]]).
 
+> **Worked example — "store the price" ≠ "account for the sale" (found + fixed 2026-06-20).** Every
+> money-taking action must append a signed `payment` event, or it is invisible to
+> [[reconciliation]]. A concrete miss: selling a [[subscription]] wrote only the mutable
+> `subscriptions` master row (the agreed *price*) and **appended nothing to the ledger**, so the cash
+> the operator collected showed up in the feed/drawer/Z-report **nowhere** — a clean off-book channel
+> (three real sales, 27,000 ALL, untraceable). The fix is the textbook control: append a signed
+> `payment` (`subscriptionSale: true`) at sale time so it folds into the [[shift]] like any taking.
+> **The lesson generalises:** whenever a feature records *an amount* in a mutable table, ask "where is
+> the signed event that says money changed hands?" — a price in master data is not an accountable
+> transaction. See [[subscription]] "Collecting the fee".
+
 > **Direction shift:** the system is heading toward **fully unmanned operation** — no operator, no
 > booth ([[autonomous-direction]]). That removes the booth-operator as the *primary* adversary, but
 > swaps in **unattended-machine threats** (tailgating, plate spoofing, physical tampering, forced

wiki/entities/subscription.md

@@ -2,7 +2,7 @@
 type: entity
 tags: [parking, domain, business, subscriptions, identity, pricing]
 sources: []
-updated: 2026-06-18
+updated: 2026-06-20
 status: open
 ---
 
@@ -39,7 +39,8 @@ A customer paying for **more than one month** is handled by the **coverage windo
 records. The form takes a **`months`** count; with `validFrom` set, the server computes **`validTo =
 validFrom + N months`** (whole-month add, with day-overflow clamp — e.g. Jan 31 + 3mo → Apr 30). One
 subscription row, one window. The amount the operator should collect is **N × the monthly price**
-(the form previews `end date · total`); collection into the ledger is still deferred (below).
+(the form previews `end date · total`), and that **full N-month amount is now collected as one signed
+`payment` at sale time** (see "Collecting the fee" below — built 2026-06-20).
 
 - `months` is **input-only** — it's not stored; the stored truth is `validFrom`/`validTo`. Renewing
   for more months is just editing the window (set a new `months` or an explicit `validTo`).
@@ -47,32 +48,61 @@ subscription row, one window. The amount the operator should collect is **N × t
   `now` ∈ [validFrom, validTo]** — so a 3-month window simply stays valid for three months.
 - An explicit **`validTo` override** is still accepted (manual end date) when `months` isn't used.
 
-### Collecting the fee is a SHIFT transaction (decided 2026-06-18, deferred build)
+### Collecting the fee is a SHIFT transaction — BUILT 2026-06-20
 
 Selling/renewing a subscription is a **financial transaction a common operator makes during their
 [[shift]]** — the subscriber pays the monthly fee at the booth like any other customer. So it is
-**not** an admin-only master-data edit; the money must land in **that operator's shift**: their
-drawer (if cash) and their [[shift|Z-report]].
+**not** an admin-only master-data edit; the money lands in **that operator's shift**: their drawer
+(if cash) and their [[shift|Z-report]].
 
-The clean way (the model already supports it): collection writes a signed **`payment`** ledger event
-— same shape the transient pay-station uses (`{ amountMinor, currency, tender }`) — at collection
-time, tagged with `{ subscriptionId }` so it's identifiable as subscription revenue.
+> ⚠ **Why this got built — an off-book accountability hole ([[threat-model]] core path).** Until
+> 2026-06-20, creating a priced subscription wrote **only** the mutable `subscriptions` master row
+> and **appended nothing to the signed ledger**. The operator collected real cash (e.g. 10,000 ALL),
+> and it appeared in the live feed: **no**; the drawer: **no**; the Z-report: **no**; left any signed
+> trace: **no**. The `subscriptions` row records the *plan price*, not that *money changed hands* —
+> and it's a table the operator could even edit. So a booth operator could sell subscriptions and
+> pocket the money untraceably — exactly the **operator-as-adversary** path the
+> [[append-only-event-chain|signed append-only ledger]] exists to close. Found live: three priced
+> subscriptions on the appliance (27,000 ALL sold) had **zero** payment events. This is the canonical
+> reason "store the price" is not the same as "account for the sale."
 
-- It folds into the shift automatically: the Z-report sums `payment` events in `[start, end]` **by
-  payment time**, and the drawer fold adds **cash** tenders (card settles to the bank) — no new
-  summing logic needed. The fee lands in **whichever shift was open when it was taken**, attributed
-  to that operator. (See [[shift]] "drawer balance".)
-- **Admin** still edits the subscription master data (price, window, credentials); the **operator**
-  takes the money. Two different acts.
+**As built** (chosen of the two options below): a subscription **sold with a price** appends a signed
+**`payment`** ledger event — the same shape the transient pay-station uses — at create time:
+
+- **Amount = the full sale.** `priceMinor × months` (a 3-month prepay records all 30,000 today, not
+  one month), so the ledger matches what's actually in the drawer.
+- **Tender is operator-chosen** (cash/card) on the create form, defaulting to cash. Cash enters the
+  drawer; card settles to the bank — identical to the parking pay path.
+- **Folds into the shift automatically** — no new summing logic. The Z-report sums `payment` events in
+  `[start, end]` by payment time; the drawer fold adds **cash** tenders. The fee lands in **whichever
+  shift was open when taken**, attributed to that operator (recorded `operator` on the payload).
+- **Identifiable as subscription revenue.** The payload carries **`subscriptionSale: true`** + the
+  subscription id (as both `identity` and `permitId`, so [[booth-console|the feed]] resolves the
+  holder name and badges it **"subscription sale"**) + `months` for audit.
+- **Free/comp = no event.** A subscription with no price appends nothing (nothing was collected).
 - A subscription's own [[parking-session|entry/exit]] events stay **free** (no per-stay `payment`) —
   only the *plan fee* is a payment, decoupled from any individual stay.
+- **Admin** still edits subscription master data; the act of **selling** writes the money event.
 
-> **Deferred build.** Today we only *record* the agreed price + coverage window
-> (`validFrom`/`validTo`); no collection event is written yet, so subscription revenue does not flow
-> into the drawer/Z-report or [[reconciliation]]. Open detail when built: whether to model it as a
-> plain `payment` (simplest, folds today) or a distinct `subscription_payment` type (clearer in
-> reports, but the shift/drawer fold would need to count it too). Leaning **plain `payment` +
-> `subscriptionId` tag**. (Decision 2026-06-18: store price now, collect-in-shift later.)
+**Decision on event type (resolved):** modelled as a **plain `payment` + `subscriptionSale` flag**,
+not a distinct `subscription_payment` type. Reusing `payment` means the existing shift/drawer/Z-report
+folds count it with **zero** new summing surface; the flag is enough for the feed/reports to label it.
+
+**Not hard-gated on an open shift** (deliberate — differs from the booth pay path). A subscription can
+be sold outside the booth money flow, so `recordSale` does **not** refuse when no shift is open; it
+still appends the signed payment (operator recorded) and the UI **warns** "no shift was open — open
+one so the takings land in a Z-report." The payment folds into any shift whose window later covers its
+timestamp. *(If a site wants subscription sales to be impossible without an open shift, add the
+`requireOpenShift` gate the `/api/pay` path uses — flagged, not done.)*
+
+> **Historical gap is not back-fillable.** The append-only ledger means the three pre-2026-06-20
+> off-book sales can't be retroactively turned into dated payment events (forging back-dated signed
+> events is exactly what the chain forbids). Reconcile them via an operator `cash_movement` (drawer
+> adjustment with a reason) or a note on the next Z-report — not by inserting fake history.
+
+Verified 2026-06-20 against a copy of the live DB with the real signing modules: the sale appends a
+signed `payment` (30,000 ALL, 3-month, `subscriptionSale`), the **hash-chain still verifies**, and a
+shift window covering it picks the amount up in cash takings.
 
 ## Credentials (how a subscription is presented) — confirmed 2026-06-15
 
@@ -254,15 +284,21 @@ subscription** (card/QR credential, or a bound plate) — otherwise to the trans
   `null`; `priceMinor` non-negative int (currency required when set); at least one credential or one
   bound plate.
 - **Pricing** stored on each subscription (`priceMinor`/`period`/`currency`), pre-filled from
-  `site_config.subscription_monthly_price_minor`; **fee collection into the ledger is deferred**
-  (see Pricing above).
+  `site_config.subscription_monthly_price_minor`. **Selling a priced subscription now appends a signed
+  `payment`** (`subscriptionSale: true`, amount = `priceMinor × months`, operator-chosen tender) so it
+  flows into the drawer/Z-report — built 2026-06-20 (see "Collecting the fee" above). The create
+  response returns the recorded `{ sale }`; `subscriptionRoutes(...)` now takes the `EventLog` +
+  `ShiftService`.
 
 ## Open questions
 
 1. **Reader hardware** — confirm the RF reader and QR/optical reader models (procurement; [[bom]],
    [[open-questions]]).
 2. **Lapsed-mid-stay & revoked** policy (fall back to transient [[tariff]] vs. refuse) — confirm.
-3. **Subscription-fee collection** — a **shift transaction** (operator takes the monthly fee at the
-   booth → signed `payment` → folds into their drawer/Z-report). Deferred build; see Pricing.
+3. ~~**Subscription-fee collection**~~ — **RESOLVED + BUILT 2026-06-20.** Selling a priced
+   subscription appends a signed `payment` (`subscriptionSale` flag, `priceMinor × months`,
+   operator-chosen tender) that folds into the drawer/Z-report. Remaining sub-question: should a sale
+   be **hard-blocked without an open shift** (it isn't today — it warns instead)? See "Collecting the
+   fee".
 4. **Time-of-day access windows** (overnight subscribers) — design + build; boundary-case policy
    above (see the design note).

wiki/log.md

@@ -1053,3 +1053,50 @@ red warning when base.mode==="stepped" && tiers>0. Also: ApiError now carries th
 server's problems[] so the publish error shows the SPECIFIC reason (was generic "invalid
 tariff structure"). 2 new validation tests (55 pass). Verified live: warning renders +
 publish blocked with the full message. Build+lint green. Updated [[tariff]].
+
+## [2026-06-20] query | "Tariff Lab wrong: weekend 3h shows 600, expected 300"
+
+NOT a bug — the engine was correct. The active tariff's billing increment is 30 min,
+and `priceMinorPerIncrement` is PER INCREMENT, not per hour. The Fundjava (weekend) tier
+DID apply (traced: every increment of the Saturday stay selected the Fundjava card), but
+it bills 100 per 30-min increment = 200/hour, so 3h = 6 increments x 100 = 600. To get
+300, set the price to 50/increment OR the increment to 60 min. This per-increment-vs-per-
+hour confusion has recurred; documented it as a ⚠ callout in [[tariff]] and filed a
+per-hour-preview composer UX idea under Open. No code change.
+
+## [2026-06-20] fix | Subscription sale was off the books — append a signed payment
+
+Operator-reported [[threat-model]] hole: creating a priced [[subscription]] wrote ONLY the
+mutable `subscriptions` master row and appended NOTHING to the signed ledger. The cash the
+operator collected (e.g. 10,000 ALL) showed in the live feed / drawer / Z-report nowhere —
+a clean off-book channel. Confirmed live on the appliance: three priced subscriptions
+(27,000 ALL sold) had ZERO payment events. This is the canonical booth-operator-as-adversary
+path the [[append-only-event-chain]] exists to close; the "collect-in-shift later" deferral
+(decided 2026-06-18) had left it open.
+
+Fix: selling a priced subscription now appends a signed `payment` event (the long-planned
+plain-`payment`-not-new-type choice, resolved) at create time — amount = `priceMinor x
+months` (full multi-month prepay), operator-chosen tender (cash->drawer / card->bank),
+payload `{ subscriptionSale: true, permitId, operator, months }`. Folds into the [[shift]]
+Z-report/drawer with no new summing logic; the live feed badges it "subscription sale" and
+resolves the holder name. NOT hard-gated on an open shift (a sale can happen outside the
+booth money path) — it warns instead; flagged as a remaining sub-question. The 3 historical
+off-book sales are NOT back-fillable (append-only forbids forging dated events) —
+reconcile via `cash_movement` / a Z-report note.
+
+Verified against a COPY of the live DB with the real signing modules: signed payment
+appended (30,000 ALL, 3-month), hash-chain still verifies, lands in shift cash totals.
+Build + lint 12/12. Updated [[subscription]] (Collecting the fee → BUILT; data model;
+open-question #3 resolved), [[shift]] (sale folds in), [[threat-model]] (worked example:
+"store the price ≠ account for the sale").
+
+## [2026-06-20] feat | Show recognized plate in live feed + active sessions
+
+The advisory ANPR plate (device_events kind="read", keyed by session identity — unsigned,
+prunable, NEVER an access decision) is now surfaced next to entry/exit events in the live
+feed and on active-session rows. Resolved at serialize time (new `plate-lookup.ts`, prefers
+an entry read; one device_events scan for the whole page), like subscriber-name enrichment —
+the signed ledger is untouched. Added `plate?` to the shared `LedgerEvent` + `ActiveSession`/
+`SessionLookup`; a small amber badge in the UI. Caveat: a `vehicle_entry` is signed + pushed
+over WS BEFORE the async ANPR read lands, so a fresh feed row may show no plate until reload;
+always present on active sessions. Build + lint 12/12.