feat(supervisor): record manual status for existing doors #191

New issue

Open

opened 2026-09-30 15:25:55 +00:00 by gabogg · 0 comments

gabogg commented

2026-09-30 15:25:55 +00:00

Owner

Part of #187 — milestone: Focused operator and supervisor door operations.

Intended outcome

Let a Supervisor record a human-observed status for an existing door when HikCentral reports an unreliable state. The door remains identified by its existing HikCentral door ID. This is a door-status record, not manual creation of a door identity or a generic incident log. The system must retain the hardware-reported status alongside the manual record so disagreements are visible.

Agreed behavior

Show both the raw HikCentral status and the current manual status, clearly identifying the latter as the operational assessment while it is valid.
Supervisors and administrators may enter a manual status. Require a reason, actor, observation time, entry time, and an audit trail for corrections and confirmations.
Every entry must select a reconfirmation interval of one day, one week, or one month. There is no indefinite option. At the deadline, the entry is no longer current until reconfirmed; retain its history and show that the assessment is overdue.
Keep hardware alarms visible. Historical open-time reports show manual status records separately from hardware-derived durations until calculation rules are agreed.

Triage questions

Which statuses may be recorded manually (for example open, closed, unknown, offline, needs inspection), and what observation supports each?
Who may correct, revoke, or reconfirm an entry, and what correction flow preserves the audit trail? May observation time be backdated?
What should the Operator view use as its primary status after an assessment expires, and how should it present contradictory hardware readings while a manual assessment is current?
How are conflicting or duplicate entries resolved? Should reconfirmation require a new observation and reason?
How should manual status interact with locally inferred alarms and exclusions (#194)? Which views must show source and confidence clearly?

Ready-to-spec outcome

A status vocabulary, authority and lifecycle rules, provenance/audit fields, and explicit behavior for conflicting hardware readings, alarms, reports, and exclusions. Include one worked example of a door whose HikCentral state cannot be trusted.

Part of #187 — milestone: Focused operator and supervisor door operations. ## Intended outcome Let a Supervisor record a human-observed status for an existing door when HikCentral reports an unreliable state. The door remains identified by its existing HikCentral door ID. This is a door-status record, not manual creation of a door identity or a generic incident log. The system must retain the hardware-reported status alongside the manual record so disagreements are visible. ## Agreed behavior - Show both the raw HikCentral status and the current manual status, clearly identifying the latter as the operational assessment while it is valid. - Supervisors and administrators may enter a manual status. Require a reason, actor, observation time, entry time, and an audit trail for corrections and confirmations. - Every entry must select a reconfirmation interval of **one day, one week, or one month**. There is no indefinite option. At the deadline, the entry is no longer current until reconfirmed; retain its history and show that the assessment is overdue. - Keep hardware alarms visible. Historical open-time reports show manual status records separately from hardware-derived durations until calculation rules are agreed. ## Triage questions 1. Which statuses may be recorded manually (for example open, closed, unknown, offline, needs inspection), and what observation supports each? 2. Who may correct, revoke, or reconfirm an entry, and what correction flow preserves the audit trail? May observation time be backdated? 3. What should the Operator view use as its primary status after an assessment expires, and how should it present contradictory hardware readings while a manual assessment is current? 4. How are conflicting or duplicate entries resolved? Should reconfirmation require a new observation and reason? 5. How should manual status interact with locally inferred alarms and exclusions (#194)? Which views must show source and confidence clearly? ## Ready-to-spec outcome A status vocabulary, authority and lifecycle rules, provenance/audit fields, and explicit behavior for conflicting hardware readings, alarms, reports, and exclusions. Include one worked example of a door whose HikCentral state cannot be trusted.

gabogg added this to the Focused operator and supervisor door operations milestone

2026-09-30 15:25:55 +00:00

gabogg added the

needs-triage

label

2026-09-30 15:25:55 +00:00

gabogg referenced this issue

2026-09-30 15:26:53 +00:00

epic(ui): focus Operator on doors and alarms; introduce Supervisor workspace #187

gabogg referenced this issue

2026-09-30 16:03:53 +00:00

feat(supervisor): manage existing door inventory and metadata #190

gabogg changed title from ~~feat(supervisor): define a manual operational registry~~ to feat(supervisor): record manual status for existing doors

2026-09-30 16:03:57 +00:00

gabogg referenced this issue

2026-09-30 16:04:04 +00:00

feat(doors): report selected doors' open time over a range #193

gabogg referenced this issue

2026-09-30 16:04:10 +00:00

feat(doors): manage exclusions with provenance and review #194

gabogg referenced this issue

2026-09-30 17:51:17 +00:00

feat(operator-view): focus on doors and alarms #188

gabogg referenced this issue

2026-09-30 18:04:03 +00:00