Document accepted Display evidence reconciliation

AGENTS.md

@@ -1,58 +1,73 @@
 # OpenGauge Agent Guide
 
-## Scope
+## Applicability and project identity
 
-This directory is the complete boundary for OpenGauge. Do not place OpenGauge files in `D:\ESP32`, `OpenTrail`, or a root-level shared directory. A reusable dependency should be evaluated as a separately versioned library rather than an informal root folder.
+C:\lu\AGENTS.md applies in full. This file adds OpenGauge-specific constraints and may not weaken the workspace rules. Stop and report any conflict.
 
-## Current phase
+- Canonical engineering root: C:\lu\OpenGauge
+- The customer-facing repository and product name is Display; OpenGauge, opengauge, and OG- remain the engineering identifiers.
+- Do not create a separate C:\lu\Display directory or place OpenGauge source in D:\ESP32, C:\lu\OpenTrail, or a shared root directory.
+- OpenGauge owns listen-only CAN/J1939 ingestion, normalized vehicle telemetry, gauge rendering, and vehicle validation.
+- Do not begin a complete gauge UI or vehicle integration until the applicable interfaces and safety boundaries have been reviewed and accepted.
 
-OpenGauge is in architecture and proof-of-concept planning. Candidate displays and network roles are not selected or validated. Do not begin a complete gauge UI or vehicle integration before the interfaces and safety boundaries are reviewed.
+After the minimal workspace bootstrap, read only project documents relevant to the task. For implementation that changes product behavior or architecture, consult README.md, docs\ARCHITECTURE.md, docs\PROJECT_STATUS.md, and tasks\BACKLOG.md as applicable.
 
-## Brand and trademark safeguards
-
-- `Limited Underground` and `Limited Underground Business` are owner-approved working identities pending attorney clearance, not cleared or registered names.
-- Use `LU` only as a monogram visibly paired with the full words `Limited Underground`. Do not create or publish `LU Link`, `LU Studio`, or an `LU`-plus-number public model name such as `LU300`, `LU-300`, or `LU 300`.
-- Never use `®` without documented federal registration for the exact mark and relevant goods or services. Use `™` only where an unregistered trademark symbol is appropriate.
-- New public product or family names require documented preliminary screening and explicit owner approval; obtain professional clearance before permanent hardware marking, packaging, sales, or another hard-to-reverse release.
-- Keep working names out of protocol fields, compatibility identifiers, device IDs, persistent schemas, API contracts, cryptographic material, and board identifiers so branding remains replaceable.
-- Existing `OG-` engineering, protocol, test, and inventory identifiers remain allowed. They are OpenGauge technical identifiers, not `LU` model names.
-
-## Working rules
+## Architecture boundaries
 
-1. Read `README.md`, `docs/ARCHITECTURE.md`, `docs/PROJECT_STATUS.md`, and `tasks/BACKLOG.md` first.
-2. Preserve existing work. Do not delete, rename, or broadly restructure without a documented reason.
-3. Isolate board, CAN controller/transceiver, display/touch, storage, and radio code behind interfaces.
-4. Keep gateway, gauge display, GPS, and auxiliary/APU roles as separate target compositions.
-5. Avoid giant `.ino` files. Keep J1939 parsing, decoding, normalization, telemetry caching, alarms, and wire codecs host-testable.
-6. Never transmit raw C/C++ structs over ESP-NOW. Use explicit, versioned serialization and length/range validation.
-7. Treat vehicle data as untrusted and possibly stale, unavailable, not installed, or erroneous. Never invent a numeric value.
-8. This project must not perform safety-critical vehicle control without a separately reviewed fail-safe design. Early CAN work is listen-only.
-9. Do not hard-code credentials, pairing secrets, private keys, or vehicle-specific identifiers.
-10. Record exact hardware, wiring, termination, bus conditions, firmware/toolchain, and observed results for physical tests.
+1. Isolate board, CAN controller/transceiver, display/touch, storage, and radio code behind interfaces.
+2. Keep gateway, gauge display, GPS, and auxiliary/APU roles as separate target compositions.
+3. Avoid giant .ino files. Keep J1939 parsing, decoding, normalization, telemetry caching, alarms, and wire codecs bounded and host-testable.
+4. Never transmit raw C or C++ structs over ESP-NOW. Use explicit, versioned serialization with length and range validation.
+5. Treat vehicle data as untrusted and possibly stale, unavailable, not installed, invalid, or erroneous. Represent those states explicitly and never invent a numeric value.
+6. Early CAN work is listen-only. Do not perform safety-critical vehicle control without a separately reviewed and accepted fail-safe design, explicit scope, and explicit authorization.
+7. Do not hard-code credentials, pairing secrets, private keys, or vehicle-specific identifiers.
 
-## Validation expectations
+## OpenTrail relationship
 
-- Parser/decoder/cache/alarm/protocol work: deterministic host tests including malformed, boundary, timeout, and compatibility cases.
-- Firmware: build every affected target and record the board/toolchain configuration.
-- CAN/J1939 work: start with captured/synthetic frames; physical connection requires correct transceiver, voltage compatibility, isolation assessment, termination, and explicit authorization.
-- Display compatibility: report measured boot time, memory, frame/update performance, touch behavior, power, and recovery—not specifications alone.
+- Only bounded, normalized, versioned alerts may cross into OpenTrail.
+- Raw CAN/J1939, VINs, unrestricted text, credentials, keys, and vehicle-control commands must not enter OpenTrail, LoRa, or Trail Server.
+- Cross-project contracts must be versioned, independently implemented, and backed by mirrored normative fixtures.
+- Transport authentication, authorization, replay protection, and key lifecycle must be explicit; CRC alone is only corruption detection.
+- OpenGauge and OpenTrail remain optional to one another.
 
-## Safety boundary
+## Vehicle and hardware safety
 
-A gauge warning is supplemental instrumentation. Stale or missing gateway data must be conspicuous. Gateway/display loss must not affect vehicle operation. APU or auxiliary control remains outside the core telemetry path and requires authentication, authorization, interlocks, and independent safety analysis.
+- Parser, decoder, cache, alarm, and protocol work requires deterministic host tests including malformed, boundary, timeout, and compatibility cases.
+- Build every affected target and record the exact board and toolchain configuration.
+- Start CAN/J1939 work with captured or synthetic frames.
+- Before physical vehicle connection, verify the correct transceiver, voltage compatibility, protection, isolation assessment, termination, and explicit owner authorization.
+- Record exact hardware, wiring, termination, bus conditions, firmware/toolchain, and observed results for physical tests.
+- Report display compatibility using measured boot time, memory, frame/update performance, touch behavior, power, and recovery rather than specifications alone.
+- Gauge warnings are supplemental instrumentation. Stale or missing gateway data must be conspicuous.
+- Gateway or display loss must not affect vehicle operation.
+- APU or auxiliary control remains outside the core telemetry path and requires authentication, authorization, interlocks, and independent safety analysis.
 
-## Completion and publication gate
-
-- Follow the workspace-wide completion and publication gate in `D:\ESP32\AGENTS.md`.
-- Once an OpenGauge task is implemented and validated, update every affected canonical record and dated public progress entry, commit and push the relevant public-ready OpenGauge changes, and verify the remote commit before calling the task complete.
-- If accepted evidence changes public project status or V1 progress, synchronize and validate the Limited Underground website projection, commit and push the website update, deploy it, and verify the live OpenGauge status before calling the task complete.
-- If no public website status changed, say so explicitly in the completion report. If any required push, synchronization, deployment, or verification is blocked, report `implementation complete; publication pending` and identify the remaining step.
-- Do not bundle unrelated or unvalidated dirty-worktree changes merely to satisfy this gate, and never publish private or unsafe material.
-
-## V1 progress completion gate
+## Brand and trademark safeguards
 
-- `docs/V1_PROGRESS.json` is the canonical OpenGauge V1 progress record. Do not maintain a separate percentage in the README, firmware, or website source.
-- Before calling any task complete, compare its accepted evidence with every affected V1 milestone. Planning, code volume, or an unvalidated implementation does not increase completion.
-- When evidence changes a milestone, update its completion, evidence references, next gate, and `as_of` date; append a dated `change_log` entry with the newly calculated weighted overall. Never rewrite prior history.
-- Milestone weights must remain positive and total exactly 100. A regression or newly discovered blocker may lower completion and must be recorded just like an increase.
-- The public website projection is generated separately from this canonical record. After changing it, run the Limited Underground website's V1 sync/check flow and publish the result when website publication is in scope. If publication is not authorized or available, report the pending website synchronization explicitly.
+- Limited Underground and Limited Underground Business are owner-approved working identities pending attorney clearance, not cleared or registered names.
+- Use LU only as a monogram visibly paired with Limited Underground. Do not create or publish LU Link, LU Studio, or an LU-plus-number public model name such as LU300, LU-300, or LU 300.
+- Never use ® without documented federal registration. Use ™ only where appropriate for an unregistered mark.
+- New public product or family names require preliminary screening, explicit owner approval, and professional clearance before permanent marking, packaging, sales, or another hard-to-reverse release.
+- Keep working names out of protocol fields, compatibility identifiers, device IDs, persistent schemas, API contracts, cryptographic material, and board identifiers.
+- Existing OG- identifiers remain technical identifiers, not public model names.
+
+## Documentation and progress authority
+
+- docs\PROJECT_STATUS.md owns detailed current engineering state.
+- tasks\BACKLOG.md owns project sequencing and acceptance gates.
+- docs\V1_PROGRESS.json owns detailed V1 progress mechanics.
+- C:\lu\.tracker\PROJECTS\OpenGauge.md owns only a dated workspace summary and links.
+- C:\lu\.tracker\CURRENT-FOCUS.md solely owns any active objective, blocker, next action, and acceptance criteria.
+- Planning, code volume, and unvalidated implementation do not increase progress.
+- Progress history is append-only; milestone weights must remain positive and total 100; regressions may lower completion.
+- The public website is a generated sanitized projection and never progress authority.
+
+## Completion and publication
+
+- Follow C:\lu\AGENTS.md and C:\lu\.tracker for workspace authority.
+- Documentation does not authorize commit, push, PR creation, website work, deployment, or remote verification.
+- When a distinct publication operation is explicitly authorized, publish only validated public-ready scope through the intended repository and independently verify the remote result only when that verification is separately authorized.
+- Website synchronization or deployment requires separate explicit scope and authorization.
+- State explicitly when accepted evidence did not change public website status.
+- If implementation is complete but a required publication operation is unavailable or unauthorized, report implementation complete; publication pending and name the exact remaining action.
+- Never bundle unrelated or unvalidated dirty-worktree changes and never publish private or unsafe material.

docs/PROJECT_STATUS.md

@@ -1,6 +1,6 @@
 # OpenGauge Project Status, Assumptions, and Open Questions
 
-Status date: 2026-08-31
+Status date: 2026-09-23
 
 Public repository: <https://github.com/Limited-Underground/Display>
 
@@ -12,6 +12,10 @@ visibility. Git redirects the former URL to the current repository. Stable
 This administrative migration changes no hardware, V1 evidence, or readiness
 claim.
 
+## Evidence reconciliation
+
+[OG-0021a](testing/OG-0021a-EVIDENCE-RECONCILIATION-2026-09-23.md) maps the five Display outcomes to existing host components, bounded historical physical evidence and missing target/vehicle gates. This evidence reconciliation is owner-accepted. Completed host work is not reopened; no new hardware, support or V1 completion claim is added.
+
 ## Conceptual goals
 
 - Separate ESP32 CAN/J1939 gateway and round touchscreen gauge nodes