openspec: scan-alert-hardening change — different-finder re-alert + fingerprint 24h block
This commit is contained in:
12
openspec/changes/scan-alert-hardening/specs/database/spec.md
Normal file
12
openspec/changes/scan-alert-hardening/specs/database/spec.md
Normal file
@@ -0,0 +1,12 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: scans.fingerprint column
|
||||
The `scans` table SHALL include a nullable `fingerprint` text column, added idempotently so existing databases migrate cleanly.
|
||||
|
||||
#### Scenario: Fresh database
|
||||
- **WHEN** `db/schema.sql` is applied to an empty database
|
||||
- **THEN** `scans.fingerprint` exists and is nullable
|
||||
|
||||
#### Scenario: Existing database
|
||||
- **WHEN** `db/schema.sql` is re-applied to a database created before this column
|
||||
- **THEN** the column is added without error, nullable
|
||||
@@ -0,0 +1,26 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Fingerprint on scans
|
||||
The tag page SHALL compute a lightweight browser fingerprint (UA, language, timezone, screen, platform hash) and include it with every scan POST and finder-contact POST. The scan SHALL store it in `scans.fingerprint`.
|
||||
|
||||
#### Scenario: Scan carries fingerprint
|
||||
- **WHEN** the tag page scripts a scan POST
|
||||
- **THEN** the request includes a fingerprint and the scan row stores it
|
||||
|
||||
### Requirement: 24-hour per-device alert block
|
||||
When a scan arrives with a fingerprint that was seen on an earlier scan within the last 24 hours, the system SHALL record the scan but SHALL NOT send an alert.
|
||||
|
||||
#### Scenario: Same device within 24 h
|
||||
- **WHEN** a scan arrives with a fingerprint matching a scan from under 24 h ago
|
||||
- **THEN** the scan is recorded with `alert_sent = false` and no SMS is sent
|
||||
|
||||
#### Scenario: Fresh device
|
||||
- **WHEN** a scan arrives with a fingerprint not seen in the last 24 h
|
||||
- **THEN** normal alert rules apply (an alert is sent if the throttle conditions permit)
|
||||
|
||||
### Requirement: Contact path coverage
|
||||
The finder-contact submission SHALL also be subject to the fingerprint block when a fingerprint is provided.
|
||||
|
||||
#### Scenario: Contact from a blocked device
|
||||
- **WHEN** a contact submission carries a fingerprint seen within 24 h
|
||||
- **THEN** the number is stored but no owner SMS is sent
|
||||
@@ -0,0 +1,19 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Different-finder re-alert
|
||||
Within the 10-minute alert window, an alert SHALL also be sent when the new scan carries a finder phone that differs from the phone on the last alerted scan, even if the location moved less than 250 m.
|
||||
|
||||
#### Scenario: Second finder at same spot
|
||||
- **WHEN** a scan within the window arrives with a phone different from the last alerted scan's phone
|
||||
- **THEN** a new alert is sent to the owner
|
||||
|
||||
#### Scenario: Same finder re-submits
|
||||
- **WHEN** a scan within the window arrives with the same phone as the last alerted scan
|
||||
- **THEN** no new alert is sent
|
||||
|
||||
### Requirement: Contact-path phone dedup
|
||||
The finder-contact submission SHALL not send an owner SMS if the submitted phone matches the last alerted scan's phone within the window (the number is still stored).
|
||||
|
||||
#### Scenario: Same number twice in window
|
||||
- **WHEN** a finder submits the same number again within the window
|
||||
- **THEN** the number is stored but no duplicate SMS is sent
|
||||
Reference in New Issue
Block a user