feat(entry): admin bypass of the presence gate for faulty radar/camera
The entry button (physical press AND the operator-issued mint) requires
radar/loop presence + camera detection to confirm a real vehicle. When one
of those devices is faulty, the gate blocks legitimate transient entry. Let
the ADMIN drop a specific signal as a requirement until support fixes the
hardware — the admin is not the adversary, but weakening an anti-fraud gate
stays attributed and auditable:
- Granular: bypass radar and camera independently (Setup → controller
section). A dead camera drops only the camera check; a dead radar only
radar. Both off = normal gate; both on = press-to-print.
- Signed: a DEDICATED endpoint (PUT /api/site-config/presence-bypass,
site:update) appends a signed config_change {setting, value, prev,
operator} per actually-changed signal — new ledger type. No-op toggles
sign nothing; disabling signs too. Kept out of the generic site PUT.
- Flagged: every vehicle_entry issued (and every refusal anomaly) while
bypassed carries presenceBypassed:[...] in its signed payload.
- Persists until turned off; amber warning in Setup while active. The
booth entry light treats a bypassed signal as satisfied (server
re-checks authoritatively). Physical-button path falls through to the
cooldown backstop when radar is bypassed.
- Migration 0020: two boolean site_config columns (default off).
Fixes a latent bug surfaced by the tests: firstRelayByDirection returned no
presenceInput, so issueForOperator's radar gate always read "presence loop
unavailable" — operator-issue never actually gated on radar. The resolver
now attaches the presence input serving the relay (mirrors relayForButton).
10 new tests: 5 gate combinations (each bypass drops only its signal +
records it), 5 route tests (RBAC, signed transitions, no-op, validation).
Claude-Session: https://claude.ai/code/session_01Xcm6ikLgGoCxxHrxtjkk5V
This commit is contained in:
@@ -0,0 +1,12 @@
|
||||
-- Entry presence-gate bypass (2026-07-02). The operator-issued entry button (and the
|
||||
-- physical entry button) require a REAL vehicle at the barrier: radar/loop presence AND a
|
||||
-- camera vehicle-detection. When a device is FAULTY (dead radar, dead camera), that gate
|
||||
-- blocks legitimate transient entry. These flags let the ADMIN drop a specific signal as a
|
||||
-- requirement until support fixes the hardware. Granular on purpose: a faulty camera drops
|
||||
-- only the camera check (radar still gates); a faulty radar drops only radar. Both null/0 =
|
||||
-- the normal both-required gate. Enabling/disabling is ALSO signed into the ledger
|
||||
-- (config_change) — the admin is not the adversary, but weakening an anti-fraud gate stays
|
||||
-- attributed + auditable. See wiki/concepts/entry-presence-bypass.md.
|
||||
ALTER TABLE `site_config` ADD `bypass_presence_radar` integer DEFAULT 0 NOT NULL;
|
||||
--> statement-breakpoint
|
||||
ALTER TABLE `site_config` ADD `bypass_presence_camera` integer DEFAULT 0 NOT NULL;
|
||||
@@ -141,6 +141,13 @@
|
||||
"when": 1781886200000,
|
||||
"tag": "0019_operator_session_create",
|
||||
"breakpoints": true
|
||||
},
|
||||
{
|
||||
"idx": 20,
|
||||
"version": "6",
|
||||
"when": 1781886300000,
|
||||
"tag": "0020_entry_presence_bypass",
|
||||
"breakpoints": true
|
||||
}
|
||||
]
|
||||
}
|
||||
Reference in New Issue
Block a user