Classify driver diagnostics without inventing GPS failures - #474
Merged
Merged
Conversation
…failures Constraint: Preserve production delivery data, GPS persistence truth and the existing diagnostic isolation contract. Confidence: high Scope-risk: moderate Directive: Deploy the additive storage diagnostic contract before the matching Routes release. Tested: API lint/typecheck/build and 2972 tests; Route Ops lint/typecheck/build and 194 tests; diagnostic/privacy regressions; diff and secret checks. Not-tested: 211 environment-gated API tests; exact Node 22 CI and physical candidate verification follow the source commit.
This was referenced Oct 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fresh direct GPS sends were classified as insufficient or stale because they did not write to the retry queue. The classifier now recognizes fresh collection, transmission and client acknowledgement with an observed empty queue without inventing a persistence timestamp. It reports unrelated runtime storage failures separately from GPS blockage, and retains current authentication/route evidence ahead of unrelated stale blockers.
The additive contract accepts precise storage-read failures and bounded completion-storage operation identifiers. The public Routes privacy notice now describes account-linked automatic diagnostics, authorized operator access and the existing server/device retention boundaries.
Closes #473. Change control: EVNSolution/clever-change-control#307 (parent #145). App companion: EVNSolution/clever-routes-app#294; app PR #291 remains excluded.
Validation (Node 20.19.4 locally; exact-head Node 22 CI successful: https://github.com/EVNSolution/clever-route-server/actions/runs/36975015832):
Concurrent Work Gate: allowed-with-non-overlap with #463, #460, #427 and #402. Scope: API classifier/contract and public privacy page only; no Prisma schema/migration, runtime settings, business delivery data, Shopify writes or notifications. No deployment is claimed by this PR.
Service/API context is updated in the owning API contract document. No service ownership, deployment profile or secret category changes; no additional global context change is required. Deployment will use the exact successful main-push CI revision and preserve the existing web artifact and rollback image. Physical device, deployed revision, and Play submission remain separately evidenced release gates.
Physical Android validation against this exact candidate: fresh direct-send HEALTHY; actual SQLite READONLY failure was independently received as STORAGE_WRITE_FAILED and cleared after recovery; ongoing business 401s remain observable as AUTH_OR_ROUTE_BLOCKED while the diagnostic channel continues. The local test packaging issue was repaired by regenerating Prisma Client; production Dockerfile already generates it during the build. No production delivery data was used.