server-26#23 (commit 82c8837) made an incident's location_coords valid only when the new location_coords_source field still matches its location. _verified_pin() drops any pin that cannot be tied back to the label.
Every incident written before that commit has no location_coords_source, so its pin is unverifiable — and per CORRELATION_REVIEW_0820.md section 5, 5 of 6 of those pins are on the wrong place. The drop only happens when _update_incident next runs on the incident, i.e. when another call links to it. An idle or already-resolved incident is never touched, so it keeps displaying a known-unreliable pin indefinitely.
Not fixed in that commit because a backfill has to page every historical incidents document against production Firestore, which the authoring machine cannot do.
Fix shape: an admin route (or a script under drb-c2-core/scripts/) that pages incidents and clears location_coords wherever location_coords_source is absent, leaving location and location_mentions intact.
Also tracked in DEFERRED.md (Version 5C root, Server section).
server-26#23 (commit 82c8837) made an incident's `location_coords` valid only when the new `location_coords_source` field still matches its `location`. `_verified_pin()` drops any pin that cannot be tied back to the label.
Every incident written before that commit has no `location_coords_source`, so its pin is unverifiable — and per CORRELATION_REVIEW_0820.md section 5, 5 of 6 of those pins are on the wrong place. The drop only happens when `_update_incident` next runs on the incident, i.e. when another call links to it. An idle or already-resolved incident is never touched, so it keeps displaying a known-unreliable pin indefinitely.
Not fixed in that commit because a backfill has to page every historical `incidents` document against production Firestore, which the authoring machine cannot do.
Fix shape: an admin route (or a script under `drb-c2-core/scripts/`) that pages `incidents` and clears `location_coords` wherever `location_coords_source` is absent, leaving `location` and `location_mentions` intact.
Also tracked in DEFERRED.md (Version 5C root, Server section).
Board minutes #62 (2026-08-24), section 9. Recording so this does not get quietly marked covered.
#57 recurring correlation dump does not cover this issue and structurally cannot: a passive recurring scan cannot surface a document that nothing links to. #28 is about pre-fix incidents that never get touched again.
This needs the one-time backfill route named in DEFERRED.md:51, not a repeating instrument (CTO draft #60 rec. 3). Not folded into #57.
**Board minutes #62 (2026-08-24), section 9.** Recording so this does not get quietly marked covered.
#57 recurring correlation dump **does not** cover this issue and structurally cannot: a passive recurring scan cannot surface a document that nothing links to. #28 is about pre-fix incidents that never get touched again.
This needs the **one-time backfill route** named in `DEFERRED.md:51`, not a repeating instrument (CTO draft #60 rec. 3). Not folded into #57.
Extension found by the standing correlation pass, unattended run 2026-08-27 — unconfirmed against live data.
The server-side pin guard cannot cover the call-level case, because the frontend does not go through the server.
_verified_pin (incident_correlator.py:316) only ever runs on incidents. location_coords_source is never written to a call doc at all. Meanwhile drb-frontend/components/MapView.tsx:379-394 draws the incident path polyline straight from call.location_coords, read directly from Firestore in the browser.
So every vertex of a plotted path is an unverified coordinate, and no server-side guard can intervene on it — the read never touches auth.py or the correlator. Tightening _verified_pin further will not fix this.
This matters for the product claim specifically: a pursuit rendered as a PATH is the flagship output, and its vertices are exactly the unguarded values.
Fix shape is one of: write location_coords_source onto call docs and have MapView filter on it, or move the path read behind a server route. Not attempted this run — it is a frontend change and there are zero JS/TS tests in the project, so typecheck is the only safety net.
**Extension found by the standing correlation pass, unattended run 2026-08-27 — unconfirmed against live data.**
The server-side pin guard cannot cover the call-level case, because the frontend does not go through the server.
`_verified_pin` (`incident_correlator.py:316`) only ever runs on **incidents**. `location_coords_source` is never written to a **call** doc at all. Meanwhile `drb-frontend/components/MapView.tsx:379-394` draws the incident path polyline straight from `call.location_coords`, read **directly from Firestore in the browser**.
So every vertex of a plotted path is an unverified coordinate, and no server-side guard can intervene on it — the read never touches `auth.py` or the correlator. Tightening `_verified_pin` further will not fix this.
This matters for the product claim specifically: a pursuit rendered as a PATH is the flagship output, and its vertices are exactly the unguarded values.
Fix shape is one of: write `location_coords_source` onto call docs and have `MapView` filter on it, or move the path read behind a server route. Not attempted this run — it is a frontend change and there are zero JS/TS tests in the project, so typecheck is the only safety net.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
server-26#23 (commit
82c8837) made an incident'slocation_coordsvalid only when the newlocation_coords_sourcefield still matches itslocation._verified_pin()drops any pin that cannot be tied back to the label.Every incident written before that commit has no
location_coords_source, so its pin is unverifiable — and per CORRELATION_REVIEW_0820.md section 5, 5 of 6 of those pins are on the wrong place. The drop only happens when_update_incidentnext runs on the incident, i.e. when another call links to it. An idle or already-resolved incident is never touched, so it keeps displaying a known-unreliable pin indefinitely.Not fixed in that commit because a backfill has to page every historical
incidentsdocument against production Firestore, which the authoring machine cannot do.Fix shape: an admin route (or a script under
drb-c2-core/scripts/) that pagesincidentsand clearslocation_coordswhereverlocation_coords_sourceis absent, leavinglocationandlocation_mentionsintact.Also tracked in DEFERRED.md (Version 5C root, Server section).
Board minutes #62 (2026-08-24), section 9. Recording so this does not get quietly marked covered.
#57 recurring correlation dump does not cover this issue and structurally cannot: a passive recurring scan cannot surface a document that nothing links to. #28 is about pre-fix incidents that never get touched again.
This needs the one-time backfill route named in
DEFERRED.md:51, not a repeating instrument (CTO draft #60 rec. 3). Not folded into #57.Extension found by the standing correlation pass, unattended run 2026-08-27 — unconfirmed against live data.
The server-side pin guard cannot cover the call-level case, because the frontend does not go through the server.
_verified_pin(incident_correlator.py:316) only ever runs on incidents.location_coords_sourceis never written to a call doc at all. Meanwhiledrb-frontend/components/MapView.tsx:379-394draws the incident path polyline straight fromcall.location_coords, read directly from Firestore in the browser.So every vertex of a plotted path is an unverified coordinate, and no server-side guard can intervene on it — the read never touches
auth.pyor the correlator. Tightening_verified_pinfurther will not fix this.This matters for the product claim specifically: a pursuit rendered as a PATH is the flagship output, and its vertices are exactly the unguarded values.
Fix shape is one of: write
location_coords_sourceonto call docs and haveMapViewfilter on it, or move the path read behind a server route. Not attempted this run — it is a frontend change and there are zero JS/TS tests in the project, so typecheck is the only safety net.