docs(roadmap): add #334 — version json omits build_date and uses short sha only

ROADMAP.md

@@ -6261,3 +6261,5 @@ Original filing (2026-04-18): the session emitted `SessionStart hook (completed)
 322. **Config deprecation warnings are emitted to stderr even under `--output-format json`, making JSON output unparseable from combined stdout+stderr capture** — dogfooded 2026-04-29 by Jobdori on current main (`8e22f75`). Running `cargo run --bin claw -- doctor --output-format json 2>&1 | python3 -c "import sys,json; json.loads(sys.stdin.read())"` fails with `Expecting value: line 1 column 1 (char 0)` because a `warning: /path/settings.json: field "enabledPlugins" is deprecated. Use "plugins.enabled" instead` line is emitted to stderr before the JSON body begins. When a caller captures combined output (the common automation pattern: `2>&1`, subprocess `STDOUT | STDERR`, PTY capture, or tmux pane scrape) the warning prefix breaks JSON parse for every downstream consumer. Root cause: `rust/crates/runtime/src/config.rs` line ~300 calls `eprintln!("warning: {warning}")` unconditionally during `ClawSettings::load_merged()` regardless of active output format. **Required fix shape:** (a) thread the active `CliOutputFormat` through the config loading path and suppress or defer human-readable warning strings when `json` mode is active; (b) instead, collect deprecation diagnostics and inject them into the JSON output as a top-level `"warnings": [...]` array (same field already used by `doctor`); (c) ensure the JSON body is always the first bytes on stdout and all prose warnings stay on stderr or are suppressed in json mode; (d) add regression coverage proving `claw <any-cmd> --output-format json` stdout is valid JSON regardless of config deprecation state. **Why this matters:** `--output-format json` is the automation/claw contract; if config warnings can silently corrupt the JSON stream, every orchestration layer that captures combined output gets broken parse-on-warning with no stable fallback. Source: Jobdori live dogfood on mengmotaHost, claw-code main `8e22f75`, 2026-04-29.
 
 323. **`status --output-format json` reports `session.session = "live-repl"` while simultaneously reporting `session_lifecycle.kind = "saved_only"` — contradictory session identity in a single status snapshot** — dogfooded 2026-04-29 by Jobdori on current main (`804d96b`). Running `claw status --output-format json` from an active REPL-style invocation produced `"session": "live-repl"` in the `workspace` block and `"session_lifecycle": {"kind": "saved_only", "pane_id": null, ...}` in the same object. Those two fields carry contradictory claims: `"live-repl"` asserts there is an active interactive session, while `"saved_only"` asserts there is no live tmux pane hosting the session — the session exists only as a saved artifact. A downstream claw reading this snapshot cannot tell which claim to trust: is this a running session whose pane is undetectable, or a saved-only session that the `session` field is misclassifying? Root cause: `"live-repl"` is a fallback sentinel emitted by `main.rs:6070` when `context.session_path` is `None`, while `session_lifecycle` is computed independently by `classify_session_lifecycle_for()` from tmux pane discovery; the two fields share no common source and can diverge. **Required fix shape:** (a) derive both `session.session` and `session_lifecycle.kind` from the same lifecycle classification result so they cannot diverge; (b) replace the `"live-repl"` free-form sentinel with a structured `session_kind` field (`live_repl`, `saved`, `resume`, etc.) that carries the same type vocabulary as `session_lifecycle.kind`; (c) when `session_lifecycle.kind = "saved_only"`, never emit `"session": "live-repl"` (or vice versa); (d) add a regression test proving `status --output-format json` never emits `session.kind = "live_repl"` and `session_lifecycle.kind = "saved_only"` simultaneously. **Why this matters:** `status --output-format json` is the machine-readable truth surface for session state; if two fields in the same snapshot contradict each other, every lane, monitor, and orchestrator has to pick a winner instead of reading a coherent state. Source: Jobdori live dogfood on mengmotaHost, claw-code `804d96b`, 2026-04-29.
+
+334. **`version --output-format json` omits `build_date` as a structured field and only exposes a 7-char `git_sha`, forcing callers to scrape the embedded `message` prose** — dogfooded 2026-04-29 by Jobdori on current main (`e7074f4`). Running `claw version --output-format json` produces `{"git_sha": "b878b3c", "kind": "version", "message": "Claw Code\n  Version          0.1.0\n  Git SHA          b878b3c\n  Target           aarch64-apple-darwin\n  Build date       2026-04-29", "target": "aarch64-apple-darwin", "version": "0.1.0"}`. The `build_date` is only accessible by splitting the `message` string on `\n` and searching for `Build date`. The `git_sha` is a 7-char short SHA — too short to uniquely identify a commit across forks or when cherry-picks are present, and not sufficient to do `git log --format=... <sha>` without ambiguity risk. The `message` field carries a multi-line prose block that duplicates the structured fields, adding noise without adding machine-readable value. **Required fix shape:** (a) add `"build_date"` as a top-level structured field in `kind=version` JSON; (b) add `"git_sha_long"` (or rename `git_sha` to the full 40-char SHA with `"git_sha_short"` alias) so callers have an unambiguous commit identity; (c) deprecate or remove the `"message"` prose block from JSON mode since its content is fully covered by structured fields; (d) add regression coverage proving `version --output-format json` includes `build_date`, `git_sha` (≥ 40 chars or explicitly documented length), `version`, `target`, and `kind`. **Why this matters:** `version` is the provenance surface; if its JSON form hides `build_date` in prose and truncates `git_sha`, automated provenance checks and CI gates have to scrape human text instead of reading stable structured fields. Source: Jobdori live dogfood on mengmotaHost, claw-code `e7074f4`, 2026-04-29.