docs(v0.6.0): cycle plan ("Real Hardware") - #76
Conversation
Continuation of the v0.5.0 close-out pattern. Doc-only. Auto-merge eligible per CLAUDE.md rule 2. What this PR ships: - docs/v0.6.0_plan.md — the proposed v0.6.0 cycle scope and PR sequence. The cycle is named 'Real Hardware' because the work is about turning the now-validated decoder pipeline (v0.3 / v0.4) plus the real-car harness (v0.5.0) into actual tuner-facing workflows on real data. Cycle spine (3 PRs, in order): - PR #1 — Log-merge / comparison (PR #2 in cycle-plan numbering; this is the first v0.6.0 PR). Pure JS / CSS. Adds a 'Compare logs' button next to 'Export CSV' on the Logging tab. Diff-modal shows per-channel meanΔ, std-devΔ, maxΔ, countΔ. ~30 lines of business logic in a new src/js/log_diff.js, ~150 lines of UI. Tested via the existing node --test harness. - PR #2 — Injector duty cycle (decoder + DIDs). Touches src-tauri/src/data/live.rs (new decoder) and the profile TOMLs. Protected path — flag for human review. - PR #3 — OBD-II PID auto-discovery. Pure diagnostic utility (scans standard 0x01 PIDs 0x00..0x7F, reports which respond). The first non-BMW-specific surface shipped via UDS. Touches src-tauri/src/protocol/mod.rs (new scan helper) and src-tauri/src/commands.rs (new #[tauri::command]). Protected path — flag for human review. Out of v0.6.0 scope (deferred per the cycle-plan): The remaining ROADMAP 🟡 items (custom math channels, knock viz polish, AFR polish, adaptation / fuel trim readout polish, trigger-based logging, OBDLink MX+, ENET/DoIP auto-detection, real-car validation B58 / N55 F-series) move to v0.7.0+. All Backlog items (i18n, plugin system, web log viewer, Bootmod3, automatic service manual lookup, OBD-II PID auto-discovery, VIN database) also stay deferred. The plan explicitly notes: - 'No feature without a Discussion' per COMMUNITY_FRAMEWORK.md. This plan is a seed for the Discussion thread, not a substitute for it. No v0.6.0 code should land before the Discussion concludes. - Sibling-agent race in this repo (CLAUDE.md + multi-writer skill): work in fresh sibling clones, branch off origin/main, push from the clone. - origin/main drift (local main was stale during the v0.4 and v0.5 cycles): always git fetch origin before basing a branch, diff against origin/main not main. - CLAUDE.md rule 2: only doc-only PRs auto-merge. PRs #2 and #3 must go through human review. Verification: - node --test server/dtc/test/ingestor.test.js → all green (no regression) - node --test src/js/histogram.test.js → all green - node --test src/js/test/live_format.test.cjs → all green - git diff origin/main...HEAD --stat → 1 file, 210 insertions, 0 deletions (clean; this PR is a new doc file only) - This PR does not touch code, workflows, or protected paths.
|
🤖 Doc-only change — auto-merge enabled. Will merge once required checks pass. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f7fee71afc
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - **CLAUDE.md rule 2** — only doc-only PRs auto-merge. PR #1 | ||
| (log-diff) is pure JS / CSS and eligible; PRs #2 and #3 |
There was a problem hiding this comment.
This says the log-diff PR is auto-merge eligible because it is “pure JS / CSS,” but I checked .github/workflows/claude-auto-merge.yml and the allowlist only treats docs, text, images, LICENSE, and issue templates as safe; src/js/main.js and src/css/app.css will be marked UNSAFE and left for human review. Following this handoff either fails the automation or bypasses the repo’s documented “only doc-only PRs may auto-merge” rule, so PR #1 should be described as requiring human review even though it avoids protected Rust paths.
Useful? React with 👍 / 👎.
| - `community/profiles/{b58,n55}.toml` — add the injector duty | ||
| cycle DID(s). Likely `0x401F` on N55 / `0x4xxx` on B58 | ||
| (placeholder until a community source confirms). Marked |
There was a problem hiding this comment.
For the injector-duty PR, this suggests 0x401F as the likely N55 DID, but the current profiles already use did:401F for knock_detect in both community/profiles/n55.toml and community/profiles/b58.toml. If the follow-up PR follows this plan, it will either duplicate an existing channel with a different meaning or overwrite the knock-detection mapping, so the placeholder should not name 0x401F unless a source proves the existing mapping is wrong.
Useful? React with 👍 / 👎.
|
|
||
| **Acceptance.** Profile TOMLs parse, live-data tick returns | ||
| non-NaN numbers in the simulator, [needs verification] stays | ||
| in the profile label until real-car validation. |
There was a problem hiding this comment.
This acceptance criterion depends on the simulator returning decodable bytes for the new injector-duty DID, but SimTransport::live_value currently has explicit DIDs only through 0x1010 and returns a single 0x00 for unknown DIDs. With the planned u16_div10-style decoder, read_live_data drops that value because two bytes are required, so the PR will not produce “non-NaN numbers in the simulator” unless the plan also includes updating src-tauri/src/transport/sim.rs or chooses a decoder that matches the existing simulator response.
Useful? React with 👍 / 👎.
| - `src-tauri/src/protocol/mod.rs` — new `scan_obd2_pids()` | ||
| helper that reads standard service 0x01 PIDs `0x00` to | ||
| `0x7F` and reports which respond. ~30 lines, well-contained. |
There was a problem hiding this comment.
For service 01 discovery, treating every PID from 0x00 to 0x7F that responds as a supported PID is the wrong loop for this codebase: connection_test already labels 01 00 as the supported-PIDs bitmask, and the simulator returns that bitmask from obd_value(0x00). A brute-response scan can list metadata PIDs such as 0x00/0x20 as user-facing supported PIDs and can miss the <2s real-car target on adapters that timeout unsupported PID requests, so the helper should parse the support bitmasks (0x00, then indicated extension ranges) rather than probing all responders.
Useful? React with 👍 / 👎.
1 participant
Summary
Kicks off v0.6.0 planning. Doc-only. Auto-merge eligible
per CLAUDE.md rule 2.
The plan defines the v0.6.0 "Real Hardware" cycle — three
small PRs focused on turning the now-validated decoder pipeline
(v0.3 / v0.4) plus the real-car harness (v0.5.0) into actual
tuner-facing workflows on real data.
Cycle spine
Three PRs, in order:
src/js/live.rsadjacentprotocol/,commands.rsPR #1 is pure JS / CSS — a "Compare logs" button next to
"Export CSV" with a diff-modal that shows per-channel meanΔ,
std-devΔ, maxΔ, countΔ between two logged CSV sessions. The
single most common tuner workflow: "before vs. after my tune."
Testable via the existing
node --testharness.PR #2 fills the third leg of the tuner model — fuel-trim and
knock shipped in v0.4 / v0.5; injector duty cycle was the
missing piece. New decoder in
live.rs(probablyu16_div10or similar, 8-line change to the existing decoder enum), new
DIDs in the profile TOMLs marked
[needs verification].Protected path — flag for human review.
PR #3 ships the first non-BMW-specific surface — scans
standard OBD-II service 0x01 PIDs
0x00–0x7Fand reportswhich respond. Useful diagnostic check. Protected path —
flag for human review.
What's deferred (out of v0.6.0 scope)
The remaining 🟡 items move to v0.7.0+:
adaptation / fuel trim readout polish, trigger-based
logging, OBDLink MX+, ENET/DoIP auto-detection, real-car
validation B58 / N55 F-series.
All Backlog items (i18n, plugin system, web log viewer,
Bootmod3, automatic service manual lookup, OBD-II PID
auto-discovery, VIN database) also stay deferred.
What's notable about the plan
turning validated decoder + harness into productive tuner
workflows on real data.
prior two cycles (each shipped 3 PRs in order).
pattern, the
origin/maindrift risk, and the rule thatPRs ci(deps): bump actions/checkout from 4 to 7 #2 and chore(deps): bump toml from 0.8.2 to 0.8.23 in /src-tauri in the cargo-minor-patch group #3 must go through human review.
COMMUNITY_FRAMEWORK.md"no feature without a Discussion"rule — this plan is the seed for the Discussion thread,
not a substitute for it. No v0.6.0 code should land
before the Discussion concludes.
Verification
git diff origin/main...HEAD --stat→ 1 file, 233insertions, 0 deletions (clean; this PR is a new doc
file only)
node --test server/dtc/test/ingestor.test.js→ allgreen (no regression)
node --test src/js/histogram.test.js→ all green(no regression)
node --test src/js/test/live_format.test.cjs→ allgreen (no regression)
paths.
Files
Related
docs/v0.5.0_plan.md(PR docs(v0.5.0): cycle plan ("Ground Truth") #70) — thev0.5.0 cycle this plan follows. PR release(v0.5.0): cut the v0.5.0 release #75 (release cut) is
pending review as of this PR's authoring; once it merges,
ROADMAP shows v0.5.0 marked Shipped.
docs/v0.6.0_plan.md(this PR).
comparison) — pure JS / CSS, lands right after the
required Discussion thread concludes.
Author note
Commit authored with
ohgeeceee@users.noreply.github.comto bypass GH007 (private-email push block). Content
unchanged.