docs(wiki): venue modules design — Car Wash pilot, Parking as a peer module (open decision)

Records the 2026-09-04/05 design sessions on wiki/decisions/venue-modules.md:
manifest-registry module system (folder per module, always-migrated schema,
one ledger union with prefixed event types, relations only via manifest
dependsOn + ledger events), enablement as entitled ∩ activated (vendor-set
Komodo env, site-admin site-config toggle recorded as config_change; server
enforces with requireModule, web only hides; disabling never deletes),
Parking recast as one module on a venue POS/audit core, Car Wash as the
pilot (inside the parking, entry snapshot as identity, bay camera for the
unrecorded-wash anti-fraud signals, v1 scope + build order), and vision
vehicle category as an advisory anomaly flag. Name stays parking-system;
validation stays for the Bar, only the Lavazh station retires with Car Wash.
Open-questions #15, index, log.

Claude-Session: https://claude.ai/code/session_01FWncR69HgGPuei1dLrW3cU
This commit is contained in:
2026-09-05 10:24:20 +02:00
parent d86bffa500
commit db9c3e0e31
4 changed files with 282 additions and 1 deletions
+37
View File
@@ -2885,3 +2885,40 @@ Decision (user, 2026-09-04): the .deb stays, updates are an admin action behind
in-app prompt now says so (en + sq). A root systemd updater timer shipped in the .deb (minisign-
verified, notify-only in-app) is recorded as the deferred fleet-grade option on
[[desktop-shell-tauri]].
## [2026-09-04] decision | Venue modules design recorded as OPEN — Car Wash / Bar as peers of Parking
Captured the 2026-09-04 design conversation on [[venue-modules]]: a manifest-registry module
system (folder per module, always-migrated schema, one ledger union with prefixed event types,
relations only via manifest dependsOn + ledger events), enablement as entitled ∩ activated
(vendor-set Komodo env vs site-admin site-config toggle recorded as config_change; server
enforces with requireModule, web only hides; disabling never deletes), Parking recast as one
module on a venue POS/audit core, validation decommissioned (ledger type kept for history), the
desktop identifier / .deb name flagged as the one irreversible naming step, and vision-derived
vehicle category (SUV vs Car for the wash tariff) as an advisory signal that raises an `anomaly`
ledger event on operator override — never a tariff input by itself. Added as open-questions #15;
indexed.
## [2026-09-05] decision | Car Wash is the pilot module; wash inside the parking; bay camera
Settled with the user on [[venue-modules]]: Car Wash is built as the first module and is the
acceptance test of the registry (zero changes outside its folder). The wash sits inside the
parking, so every vehicle already has a session, plate and entry snapshot — no intake capture,
walk-ins out of scope. A bay camera (same stateless vision service, presence/counting not
plates) gives two anti-fraud signals for the unrecorded-wash vector: session-vs-order and
bay-count-vs-order-count per shift, both as `anomaly` ledger events, never blocking. v1 scope
(catalogue by category, queue, advisory vision category, existing shift/cash/receipts, one
parking comp/credit event, per-operator reports) and the out-list (memberships, loyalty, stock,
scheduling, booking, accounts) recorded, plus the build order. Remaining before code: platform
name (→ desktop identifier) and the validation-removal go.
## [2026-09-05] decision | Name stays parking-system; validation kept for the Bar, only the Lavazh station retires
Two revisions to [[venue-modules]] from the user: (1) the platform name stays — "this is a
Parking Systems after all" — so `com.parking.desktop` and the .deb name are untouched and the
irreversible-identifier concern is moot; the peer-module architecture, not a rename, answers the
second-tier worry. (2) Validation is NOT decommissioned: the merchant-scan flow is needed as is
for the Bar until a Bar module exists and absorbs it. Only the Lavazh station is retired when Car
Wash ships (Car Wash sponsors parking via its own order event). Two sponsorship mechanisms
coexist for now, accepted. Build order updated; validation is registered as its own module in the
registry so Bar can later depend on or absorb it.