docs(roadmap): add #421 — version json omits build_date field despite ROADMAP #79 documenting it present

ROADMAP.md

@@ -6301,4 +6301,4 @@ Original filing (2026-04-18): the session emitted `SessionStart hook (completed)
 380. **Top-level `tokens --help --output-format json` hangs with zero stdout/stderr instead of returning bounded command help JSON** — dogfooded 2026-04-30 for the 02:30 nudge on current `origin/main` / rebuilt `./rust/target/debug/claw` with embedded `git_sha` `d95b230c`. After verifying #358 covered `cost --help`, a fresh adjacent probe on the token-budget surface showed the same silent failure class: repeated bounded runs of `timeout 8 ./rust/target/debug/claw tokens --help --output-format json` exited `124` with `stdout=0` and `stderr=0`. In the same rebuilt binary, `version --output-format json` returned promptly with version/build metadata, proving the binary itself and JSON output path are reachable. This is distinct from #358's cost help hang: the affected surface is the sibling `tokens` command help, which agents use before estimating prompt/session token budgets. **Required fix shape:** (a) make `tokens --help --output-format json` return static/bounded stdout JSON with `kind:"help"` or `kind:"tokens"`, `action:"help"`, usage, options, examples, supported output formats, and related slash/direct commands; (b) ensure help rendering does not initialize slow token accounting, session, or provider state; (c) if any dynamic provider is consulted, return a typed JSON timeout/unavailable error instead of hanging; (d) add regression coverage proving tokens help in JSON mode returns within a deterministic budget. **Why this matters:** token budgeting is a preflight clawability surface. If help hangs silently, automation cannot safely discover how to inspect or constrain token usage before running expensive prompts, and budget-aware wrappers stall at the discovery step. Source: gaebal-gajae dogfood follow-up for the 02:30 nudge on rebuilt `./rust/target/debug/claw` `d95b230c`.
 381. **Top-level `cache --help --output-format json` hangs with zero stdout/stderr instead of returning bounded command help JSON** — dogfooded 2026-04-30 for the 03:00 nudge on current `origin/main` / rebuilt `./rust/target/debug/claw` with embedded `git_sha` `d95b230c`. After #358 and #380 landed for the cost/tokens preflight help hangs, a fresh adjacent probe on the cache-control surface showed the same silent failure class: repeated bounded runs of `timeout --kill-after=1s 8s ./rust/target/debug/claw cache --help --output-format json` exited `124` with `stdout=0` and `stderr=0`. In the same rebuilt binary, `version --output-format json` returned promptly with version/build metadata, proving the binary itself and JSON output path are reachable. This is distinct from the separate `/cache` slash-command envelope mismatch class: the affected surface here is top-level `cache` command help, where agents need bounded local discovery before deciding whether to inspect, clear, or summarize cache state. **Required fix shape:** (a) make `cache --help --output-format json` return static/bounded stdout JSON with `kind:"help"` or `kind:"cache"`, `action:"help"`, usage, options, examples, supported output formats, and related slash/direct commands; (b) ensure help rendering does not initialize slow cache/session/provider state; (c) if any dynamic provider is consulted, return a typed JSON timeout/unavailable error instead of hanging; (d) add regression coverage proving cache help in JSON mode returns within a deterministic budget. **Why this matters:** cache inspection and cleanup are recovery/control-plane operations. If cache help hangs silently, claws cannot safely discover cache semantics before attempting cleanup, and automation stalls before it can choose a non-destructive cache action. Source: gaebal-gajae dogfood follow-up for the 03:00 nudge on rebuilt `./rust/target/debug/claw` `d95b230c`.
 
-365. **`doctor --output-format json` `system` check includes `git_sha` of the compiled binary but does not compare it against the current repository HEAD, emits no `stale_binary` warning, and reports `status:"ok"` even when the binary SHA differs from HEAD; `default_model` is `null` when no auth is configured but has no typed `reason` or `auth_required` flag** — dogfooded 2026-04-30 by Jobdori on `e939777f`. Running `./rust/target/debug/claw --output-format json doctor` when binary was compiled at `5eb1d7d8` and repo HEAD is `e939777f`: `system.git_sha: "5eb1d7d8"`, `system.status: "ok"` — no indication of staleness. No `stale`, `git_sha_matches_head`, or `head_sha` field in the system check. Separately, `system.default_model: null` with no accompanying `model_unavailable_reason`, `auth_required: bool`, or `config_source` field. Automation that reads `doctor` to validate pre-flight state cannot determine: (a) whether the binary is current; (b) why the model is null; (c) whether auth is missing or the model is intentionally unset. **Required fix shape:** (a) add `head_sha`, `git_sha_matches_head: bool` and `stale: bool` to the `system` check; (b) when `git_sha_matches_head: false`, set `status: "warn"` and add a summary message; (c) when `default_model: null`, add `model_unavailable_reason: "no_auth"|"no_config"|"other"` and `auth_required: bool`; (d) add regression coverage. Source: Jobdori live dogfood, mengmotaHost, `e939777f`, 2026-04-30.
+421. **`version --output-format json` omits the `build_date` field — ROADMAP entry #79 documents `build_date` as a present top-level field but the live binary emits `{git_sha, kind, message, target, version}` without it** — dogfooded 2026-05-01 by Jobdori on `e939777f`. Running `claw version --output-format json` returns five fields: `git_sha`, `kind`, `message`, `target`, `version`. ROADMAP entry #79 (line 1380 on main) explicitly documents the version command schema as `{kind, message, version, git_sha, target, build_date}` — listing `build_date` as a first-class structured field on equal footing with `git_sha` and `target`. The `build_date` value (`2026-04-30`) is present inside the prose `message` field as `Build date       2026-04-30` but is not emitted as a separate top-level JSON key. Automation that reads `build_date` directly from the JSON object gets `undefined`/`null`/KeyError and must fall back to parsing the `message` string, which is the same prose-scraping antipattern the JSON surface is supposed to avoid. This is adjacent to #324 (stale-binary provenance gap) and #391 (version prose mismatch) but distinct: the pinpoint is a schema field documented as present that the binary never emits, not a staleness comparison or a prose string format inconsistency. **Required fix shape:** (a) emit `build_date` as a top-level string field in `version --output-format json` alongside `git_sha`, `target`, and `version`; (b) use an ISO-8601 date format (`YYYY-MM-DD`) for machine parseability rather than a space-padded prose format; (c) verify that `message` and the new `build_date` field agree on the same date; (d) add regression coverage proving `version --output-format json` output contains a `build_date` field matching the pattern `\\d{4}-\\d{2}-\\d{2}` and that it is consistent with the `message` prose date. **Why this matters:** `build_date` is a provenance signal used by claws to decide whether a binary is recent enough for a given task. If it exists only inside a human-formatted prose string, claws must scrape the `message` to extract it, re-introducing the exact prose dependency the structured JSON field was supposed to eliminate. ROADMAP #79's documented schema creates a false expectation of machine accessibility that the live binary does not fulfill. Source: Jobdori live dogfood, `e939777f`, 2026-05-01.