Files
julian 35e593ab63 docs(wiki): DT-008 phantom-scan diagnosis + backfill bypass/relay-test concept pages
Two independent wiki updates bundled (all docs):

1. dingtian-dt008-reader.md: phantom optical decodes on the park-buzi EXIT
   reader (empty pre-opening site, low-sun afternoons). Chain of evidence:
   READ log lines carry the reader's own serial (H05MA5B0) → physical device,
   not a network source; snapshot shows nobody present; code shapes are the
   giveaway (6-digit numerics = checksum-less Interleaved 2-of-5, lone "C" =
   Code39/Codabar artifact) → 1D engine decoding sun-made stripe patterns
   (striped arm, fence shadows, glare). No fraud exposure (11-digit Luhn ids
   can't match); noise only. Fix on the entity page: vendor-tool symbology cut
   to QR+Code128 + min decode length, BOTH readers; config lives ON the device
   → re-apply after any factory reset/swap. Deliberately NOT filtering
   impossible codes server-side — probe recording is the anomaly path's job.

2. Backfilled two shipped-but-undocumented features (six code files already
   linked the first page as if it existed):
   - concepts/entry-presence-bypass.md — admin drops a FAULTY presence signal
     (granular radar/camera by decision, not a master switch); every flip is a
     signed config_change; persists till off; tickets stamped presenceBypassed;
     radar-bypass cooldown tradeoff; "the admin is not the adversary, but
     trusted never means invisible".
   - concepts/setup-relay-test.md — admin-only commissioning pulse, signed
     barrier_open_command BEFORE the fire so a test open never reads as the
     out-of-band-open fraud signal; saved controllers/declared relays only;
     radarAlert lamps excluded; pulseOpen only.
   Cross-linked from operator-issued-entry.md, cataloged in index.md, logged.

Claude-Session: https://claude.ai/code/session_01Xcm6ikLgGoCxxHrxtjkk5V
2026-07-04 19:00:49 +02:00

4.7 KiB

type, tags, sources, updated, status
type tags sources updated status
concept
parking
booth
entry
threat-model
anpr
presence
2026-07-04 settled

Operator-issued entry (broken entry button)

When the physical entry button is broken, an operator can issue an entry ticket from the booth so a real car isn't blocked out of the lot. This hands the threat-model a way to mint entries — so it is flagged, presence-gated, and paired with an exit defense (plate-reconciliation). Built 2026-07-01. Companion to entry-exit-points (the entry flow it reuses) and capacity-occupancy.

Why give the operator this at all

An operator could mint tickets to defraud — but a broken entry button otherwise blocks the whole lot, which is worse and more common. So the feature exists, and the fraud it enables is defended downstream (see the "ticket-swap" scenario in plate-reconciliation) rather than by withholding the capability.

The three controls that make it safe

1. PRESENCE-GATED — a real car must be there (radar AND camera)

The operator button obeys the same rule as the physical button: it is only active when BOTH presence conditions meet —

  • radar/loop present (a presence input is shorted at the entry barrier), AND
  • camera confirms a vehicle in the zone (the entry lane is "busy").

This ties every mint to a real vehicle physically at the entry — the operator can't pad occupancy with phantom tickets, and (crucially) it guarantees the entry snapshot captures a plate, which is what plate-reconciliation reads at exit. No presence loop configured → the feature is unavailable at that site (we require both; no weaker camera-only fallback).

Bypass (2026-07-02): when one of the two devices is FAULTY, the admin can drop that signal as a requirement via entry-presence-bypass (granular, signed config_change, persists till turned off). The gate then requires only the still-working signal; tickets minted under a bypass carry presenceBypassed on the signed entry, and refusal anomalies record it too.

Enforced on BOTH sides. The UI only enables the entry booth-console as a clickable issue-control when radar.entry && lanes.entry (both true) and the operator holds session:create. The server re-checks current presence (LaneStatus.snapshot().entry === true AND the entry relay's guard present === true) and refuses otherwise — so a direct POST /api/entry/issue by the operator-adversary can't bypass a disabled button. A refused (no-presence) attempt signs an anomaly (entry.issue.noPresence) so probing the endpoint is itself in the tamper-evident record.

2. FLAGGED — every operator mint leaves a red-flag row

The issued entry is a real vehicle_entry (so occupancy/tariff/exit all work), but:

  • source: "manual" + operatorInitiated: true + operator on the signed payload, AND
  • a companion anomaly (entry.operatorIssued) — mirroring the [[booth-exit-flow|barrier re-open]]: the operator-adversary path always leaves an explicit anomaly for reconciliation.

3. Capacity OVERRIDE is allowed but recorded

Unlike the physical button (which refuses transient entry when the lot is capacity-occupancy), the operator can issue over capacity — a broken button mustn't trap a legit car when the count is near/at the cap (and the count may itself be inflated by the very fraud this defends). But an over-cap mint stamps lotFull: true + the occupancy on the events, so the override is visible.

Wiring

  • Permission: session:create (new; migration 0019 grants it to the default operator role; admin-revocable per role, so an admin can turn off an operator's ability to mint). Admin has it in code.
  • Route: POST /api/entry/issue — session:create + an open shift (a minted entry belongs to an accountable operator, like the money path).
  • Server: EntryFlow.issueForOperator(operator, cameraBusy). The fraud-critical print → sign(vehicle_entry) → pulseOpen → snapshot → cache sequence is a single shared #issueTicket used by both the physical button and this path (no divergent copy).
  • UI: the entry BarrierLight becomes clickable (confirm → issue) only when presence + permission + shift are satisfied; the exit light stays a pure indicator.

Relates