docs(roadmap): add #404 — status allowed_tools entries:null ambiguous (unrestricted vs empty-blocking)

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`.
 
-402. **`doctor --output-format json` `config` check has `resolved_model: null` and `status:"ok"` simultaneously — a null/unresolved model is not flagged as a warning or misconfiguration, and `loaded_config_files` is an integer count while `discovered_files` is an array, making the two fields inconsistently typed for the same domain** — dogfooded 2026-04-30 by Jobdori on `e939777f`. Running `./claw --output-format json doctor` returns `{"name":"config","status":"ok","resolved_model":null,"loaded_config_files":2,"discovered_files":[...2 paths...]}`. Two issues: (1) `resolved_model: null` with `status:"ok"` — automation that reads doctor JSON to validate pre-flight state cannot tell from the config check alone that no model is configured; only the `system` check's `default_model: null` exposes the same gap, but from a different check with no cross-reference; (2) `loaded_config_files: 2` is an int count while `discovered_files: [...]` is an array — the two fields describe the same set of files but one is a scalar and the other a collection, preventing automation from correlating which loaded files map to which count. **Required fix shape:** (a) add `model_configured: bool` and `model_source: "config"|"default"|"env"|null` to the `config` check; (b) when `resolved_model: null`, set `status:"warn"` or add a structured `issues[]` entry rather than `status:"ok"`; (c) rename `loaded_config_files` to `loaded_config_file_count` or change it to a `loaded_config_files[]` array matching `discovered_files[]`; (d) add regression coverage. Source: Jobdori live dogfood, `e939777f`, 2026-04-30.
+404. **`status --output-format json` `allowed_tools` object has `entries: null` and `restricted: false` with no distinction between "no restriction configured" and "allow-set is empty/unconfigured" — automation cannot tell whether `entries:null` means unrestricted or unresolved** — dogfooded 2026-04-30 by Jobdori on `e939777f`. Running `./claw --output-format json status` returns `"allowed_tools":{"entries":null,"restricted":false,"source":"default"}`. When no `--allowedTools` is passed, `restricted:false` is correct — but `entries:null` is ambiguous: does null mean "unrestricted/wildcard" (all tools allowed), "unset" (same as unrestricted but configuration origin is unknown), or "empty set" (no tools allowed)? The `source:"default"` field signals the origin, but does not disambiguate null-means-all from null-means-unset. Per #97, `--allowedTools ""` silently produces an empty BTreeSet that blocks all tools — if that state also produces `entries:null` in status JSON, automation reading status cannot tell the lane is fully tool-restricted. **Required fix shape:** (a) emit `entries:[]` (empty array) instead of `null` when the allow-set is empty/blocking; (b) emit `entries:["*"]` or `unrestricted:true` when the allow-set is genuinely wildcard/all-tools; (c) keep `null` only if there is a third distinct state (configuration not loaded/unresolvable) and document it; (d) add regression coverage proving that three states — unrestricted, empty-blocking, and partially restricted — produce distinguishable `allowed_tools` shapes in `status --output-format json`. Source: Jobdori live dogfood, `e939777f`, 2026-04-30.