# Claw Code 2.0 Canonical Board Generated from board schema: `2026-05-25T04:30:33+00:00` Schema version: `cc2.board.v1` Ultragoal mutation policy: `.omx/ultragoal` is leader-owned and was not modified by this rendering task. ## Evidence Freeze | Source | Frozen evidence | | --- | --- | | Roadmap | `ROADMAP.md` sha256 prefix `2aba3315e52f3079`; 127 headings; 542 ordered actions | | Approved plan | `.omx/plans/claw-code-2-0-adaptive-plan.md` sha256 prefix `e7ef6faf23bfc16b` | | Research bundle | root `/Users/bellman/Documents/Workspace/claw-code/.omx/research`; latest open issues 30; issue corpus 1000; codex/opencode clone metadata included | ## Roadmap Coverage Summary | Coverage gate | Mapped | Total | Status | | --- | --- | --- | --- | | ROADMAP headings | 127 | 127 | PASS | | ROADMAP ordered actions | 542 | 542 | PASS | | Duplicate heading lines | 0 | 0 | PASS | Total canonical board items: **732** ## Lifecycle Enum Reference | Lifecycle | Count | Meaning | | --- | --- | --- | | `active` | 73 | Current Claw Code 2.0 implementation surface that should remain visible on the board. | | `context` | 15 | Context-only heading or evidence anchor; not an implementation work item. | | `deferred_with_rationale` | 9 | Intentionally deferred; rationale must be present in the board item. | | `done_verify` | 316 | Marked as done upstream but retained for verification against current CC2 behavior. | | `open` | 285 | Actionable unresolved work that needs implementation or acceptance evidence. | | `rejected_not_claw` | 2 | Excluded because it is not Claw Code product work. | | `stale_done` | 31 | Historically completed or merged work that may be stale and needs freshness checks before relying on it. | | `superseded` | 1 | Replaced by a newer item; keep as traceability context only. | ## Release Bucket Reference | Bucket | Count | Meaning | | --- | --- | --- | | `2.x_intake` | 30 | Post-2.0 intake or follow-up candidate retained for sequencing. | | `alpha_blocker` | 243 | Must be resolved before alpha-quality autonomous coding lanes are dependable. | | `beta_adoption` | 417 | Important for broader dogfood/adoption once alpha blockers are controlled. | | `context` | 15 | Non-actionable roadmap context. | | `ga_ecosystem` | 22 | Required for mature plugin/MCP/provider ecosystem behavior. | | `post_2_0_research` | 3 | Research-oriented item not required for the CC2 board cut. | | `rejected_not_claw` | 2 | Explicit non-Claw rejection bucket. | ## Stream Summaries | Stream / lane | Items | Active+open+verify | Lifecycle mix | | --- | --- | --- | --- | | Adoption overlay — user-visible parity and release polish | 357 | 329 | `deferred_with_rationale` 3, `done_verify` 237, `open` 92, `rejected_not_claw` 2, `stale_done` 23 | | Parity overlay — opencode/codex comparison context | 20 | 16 | `context` 2, `deferred_with_rationale` 1, `done_verify` 5, `open` 11, `stale_done` 1 | | Stream 0 — Governance, intake, and cross-cutting roadmap triage | 221 | 198 | `active` 6, `context` 13, `deferred_with_rationale` 4, `done_verify` 45, `open` 147, `stale_done` 5, `superseded` 1 | | Stream 1 — Worker boot and session control | 17 | 16 | `active` 8, `deferred_with_rationale` 1, `done_verify` 2, `open` 6 | | Stream 2 — Event/reporting contracts | 73 | 73 | `active` 45, `done_verify` 20, `open` 8 | | Stream 3 — Branch/test recovery | 17 | 15 | `active` 6, `done_verify` 2, `open` 7, `stale_done` 2 | | Stream 4 — Claws-first task execution | 5 | 5 | `active` 4, `done_verify` 1 | | Stream 5 — Plugin/MCP lifecycle | 22 | 22 | `active` 4, `done_verify` 4, `open` 14 | ## Source-Type Mix | Source type | Items | | --- | --- | | `issue_theme` | 31 | | `latest_open_issue` | 30 | | `parity_repo_context` | 2 | | `roadmap_action` | 542 | | `roadmap_heading` | 127 | ## Board Items by Stream ### Adoption overlay — user-visible parity and release polish | ID | Title | Source | Bucket | Lifecycle | Verification | Dependencies | Deferral | | --- | --- | --- | --- | --- | --- | --- | --- | | `CC2-RM-H0090-provider-routing-model-name-prefix-must` | Provider Routing: Model-Name Prefix Must Win Over Env-Var Presence (fixed 2026-04-08, `0530c50`) | `ROADMAP.md:L1188` / `roadmap_heading` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-H0091-openai-gpt-4-1-mini-was-silently-misrout` | `openai/gpt-4.1-mini` was silently misrouted to Anthropic when ANTHROPIC_API_KEY was set | `ROADMAP.md:L1190` / `roadmap_heading` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-H0095-pinpoint-136-compact-flag-output-is-not` | Pinpoint #136. `--compact` flag output is not machine-readable — compact turn emits plain text instead of JSON when `--output-format json` is also passed | `ROADMAP.md:L5125` / `roadmap_heading` | `beta_adoption` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-H0114-pinpoint-153-readme-usage-missing-add-bi` | Pinpoint #153. README/USAGE missing "add binary to PATH" and "verify install" bridge | `ROADMAP.md:L5924` / `roadmap_heading` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-H0116-pinpoint-155-usage-md-missing-docs-for-u` | Pinpoint #155. USAGE.md missing docs for `/ultraplan`, `/teleport`, `/bughunter` commands | `ROADMAP.md:L5979` / `roadmap_heading` | `beta_adoption` | `open` | `docs_snapshot_or_help_output_check` | `adoption_overlay_triage` | — | | `CC2-RM-H0119-pinpoint-158-compact-messages-if-needed` | Pinpoint #158. `compact_messages_if_needed` drops turns silently — no structured compaction event emitted | `ROADMAP.md:L6062` / `roadmap_heading` | `alpha_blocker` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-A0016-add-container-first-test-run-docs-done-c` | Add container-first test/run docs — **done**: `Containerfile` + `docs/container.md` document the canonical Docker/Podman workflow for build, bind-mount, and `cargo test --workspace` usage | `ROADMAP.md:L1070` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0017-surface-doctor-preflight-diagnostics-in` | Surface `doctor` / preflight diagnostics in onboarding docs and help — **done**: README + USAGE now put `claw doctor` / `/doctor` in the first-run path and point at the built-in preflight report | `ROADMAP.md:L1071` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0018-automate-branding-source-of-truth-residu` | Automate branding/source-of-truth residue checks in CI — **done**: `.github/scripts/check_doc_source_of_truth.py` and the `doc-source-of-truth` CI job now block stale repo/org/invite residue in tracked docs and metadata | `ROADMAP.md:L1072` / `roadmap_action` | `beta_adoption` | `stale_done` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | Marked done in roadmap but needs freshness re-verification before being used as release evidence. | | `CC2-RM-A0032-failure-taxonomy-blocker-normalization-d` | Failure taxonomy + blocker normalization — **done**: `WorkerFailureKind` enum (`TrustGate/PromptDelivery/Protocol/Provider`), `FailureScenario::from_worker_failure_kind()` bridge to recovery recipes | `ROADMAP.md:L1090` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0037-session-completion-failure-classificatio` | **Session completion failure classification** — **done**: `WorkerFailureKind::Provider` + `observe_completion()` + recovery recipe bridge landed | `ROADMAP.md:L1095` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0042-context-window-preflight-gap-done-provid` | **Context-window preflight gap** — **done**: provider request sizing now emits `context_window_blocked` before oversized requests leave the process, using a model-context registry instead of the old naive max-token heuristic. | `ROADMAP.md:L1101` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage`, `stable_alpha_contracts` | — | | `CC2-RM-A0043-subcommand-help-falls-through-into-runti` | **Subcommand help falls through into runtime/API path** — **done**: `claw doctor --help`, `claw status --help`, `claw sandbox --help`, and nested `mcp`/`skills` help are now intercepted locally without runtime/provider startup, with regression tests covering the direct CLI paths. | `ROADMAP.md:L1102` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0046-opaque-failure-surface-for-session-runti` | **Opaque failure surface for session/runtime crashes** — **done**: `safe_failure_class()` in `error.rs` classifies all API errors into 8 user-safe classes (`provider_auth`, `provider_internal`, `provider_retry_exhausted`, `provider_rate_limit`, `provider_transport`, `provider_error`, `context_window`, `runtime_io`). `format_user_visible_api_error` in `main.rs` attaches session ID + request trace ID to every user-visible error. Coverage in `opaque_provider_wrapper_surfaces_failure_class_session_and_trace` and 3 related tests. | `ROADMAP.md:L1105` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0051-dev-rust-cargo-test-p-rusty-claude-cli-r` | **`dev/rust` `cargo test -p rusty-claude-cli` reads host `~/.claude/plugins/installed/` from real `$HOME` and fails parse-time on any half-installed user plugin** — dogfooding on 2026-04-08 (filed from gaebal-gajae's clawhip bullet at message `1491322807026454579` after the provider-matrix branch QA surfaced it) reproduced 11 deterministic failures on clean `dev/rust` HEAD of the form `panicked at crates/rusty-claude-cli/src/main.rs:3953:31: args should parse: "hook path \`/Users/yeongyu/.claude/plugins/installed/sample-hooks-bundled/./hooks/pre.sh\` does not exist; hook path \`...\post.sh\` does not exist"` covering `parses_prompt_subcommand`, `parses_permission_mode_flag`, `defaults_to_repl_when_no_args`, `parses_resume_flag_with_slash_command`, `parses_system_prompt_options`, `parses_bare_prompt_and_json_output_flag`, `rejects_unknown_allowed_tools`, `parses_resume_flag_with_multiple_slash_commands`, `resolves_model_aliases_in_args`, `parses_allowed_tools_flags_with_aliases_and_lists`, `parses_login_and_logout_subcommands`. **Same failures do NOT reproduce on `main`** (re-verified with `cargo test --release -p rusty-claude-cli` against `main` HEAD `79da4b8`, all 156 tests pass). **Root cause is two-layered.** First, on `dev/rust` `parse_args` eagerly walks user-installed plugin manifests under `~/.claude/plugins/installed/` and validates that every declared hook script exists on disk before returning a `CliAction`, so any half-installed plugin in the developer's real `$HOME` (in this case `~/.claude/plugins/installed/sample-hooks-bundled/` whose `.claude-plugin` manifest references `./hooks/pre.sh` and `./hooks/post.sh` but whose `hooks/` subdirectory was deleted) makes argv parsing itself fail. Second, the test harness on `dev/rust` does not redirect `$HOME` or `XDG_CONFIG_HOME` to a fixture for the duration of the test — there is no `env_lock`-style guard equivalent to the one `main` already uses (`grep -n env_lock rust/crates/rusty-claude-cli/src/main.rs` returns 0 hits on `dev/rust` and 30+ hits on `main`). Together those two gaps mean `dev/rust` `cargo test -p rusty-claude-cli` is non-deterministic on every clean clone whose owner happens to have any non-pristine plugin in `~/.claude/`. **Action (two parts).** (a) Backport the `env_lock`-based test isolation pattern from `main` into `dev/rust`'s `rusty-claude-cli` test module so each test runs against a temp `$HOME`/`XDG_CONFIG_HOME` and cannot read host plugin state. (b) Decouple `parse_args` from filesystem hook validation on `dev/rust` (the same decoupling already on `main`, where hook validation happens later in the lifecycle than argv parsing) so even outside tests a partially installed user plugin cannot break basic CLI invocation. **Branch scope.** This is a `dev/rust` catchup against `main`, not a `main` regression. Tracking it here so the dev/rust merge train picks it up before the next dev/rust release rather than rediscovering it in CI. | `ROADMAP.md:L1110` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0052-auth-provider-truth-error-copy-fails-rea` | **Auth-provider truth: error copy fails real users at the env-var-vs-header layer** — dogfooded live on 2026-04-08 in #claw-code (Sisyphus Labs guild), two separate new users hit adjacent failure modes within minutes of each other that both trace back to the same root: the `MissingApiKey` / 401 error surface does not teach users how the auth inputs map to HTTP semantics, so a user who sets a "reasonable-looking" env var still hits a hard error with no signpost. **Case 1 (varleg, Norway).** Wanted to use OpenRouter via the OpenAI-compat path. Found a comparison table claiming "provider-agnostic (Claude, OpenAI, local models)" and assumed it Just Worked. Set `OPENAI_API_KEY` to an OpenRouter `sk-or-v1-...` key and a model name without an `openai/` prefix; claw's provider detection fell through to Anthropic first because `ANTHROPIC_API_KEY` was still in the environment. Unsetting `ANTHROPIC_API_KEY` got them `ANTHROPIC_AUTH_TOKEN or ANTHROPIC_API_KEY is not set` instead of a useful hint that the OpenAI path was right there. Fix delivered live as a channel reply: use `main` branch (not `dev/rust`), export `OPENAI_BASE_URL=https://openrouter.ai/api/v1` alongside `OPENAI_API_KEY`, and prefix the model name with `openai/` so the prefix router wins over env-var presence. **Case 2 (stanley078852).** Had set `ANTHROPIC_AUTH_TOKEN="sk-ant-..."` and was getting 401 `Invalid bearer token` from Anthropic. Root cause: `sk-ant-` keys are `x-api-key`-header keys, not bearer tokens. `ANTHROPIC_API_KEY` path in `anthropic.rs` sends the value as `x-api-key`; `ANTHROPIC_AUTH_TOKEN` path sends it as `Authorization: Bearer` (for OAuth access tokens from `claw login`). Setting an `sk-ant-` key in the wrong env var makes claw send it as `Bearer sk-ant-...` which Anthropic rejects at the edge with 401 before it ever reaches the completions endpoint. The error text propagated all the way to the user (`api returned 401 Unauthorized (authentication_error) ... Invalid bearer token`) with zero signal that the problem was env-var choice, not key validity. Fix delivered live as a channel reply: move the `sk-ant-...` key to `ANTHROPIC_API_KEY` and unset `ANTHROPIC_AUTH_TOKEN`. **Pattern.** Both cases are failures at the *auth-intent translation* layer: the user chose an env var that made syntactic sense to them (`OPENAI_API_KEY` for OpenAI, `ANTHROPIC_AUTH_TOKEN` for Anthropic auth) but the actual wire-format routing requires a more specific choice. The error messages surface the HTTP-layer symptom (401, missing-key) without bridging back to "which env var should you have used and why." **Action.** Three concrete improvements, scoped for a single `main`-side PR: (a) In `ApiError::MissingCredentials` Display, when the Anthropic path is the one being reported but `OPENAI_API_KEY`, `XAI_API_KEY`, or `DASHSCOPE_API_KEY` are present in the environment, extend the message with "— but I see `$OTHER_KEY` set; if you meant to use that provider, prefix your model name with `openai/`, `grok`, or `qwen/` respectively so prefix routing selects it." (b) In the 401-from-Anthropic error path in `anthropic.rs`, when the failing auth source is `BearerToken` AND the bearer token starts with `sk-ant-`, append "— looks like you put an `sk-ant-*` API key in `ANTHROPIC_AUTH_TOKEN`, which is the Bearer-header path. Move it to `ANTHROPIC_API_KEY` instead (that env var maps to `x-api-key`, which is the correct header for `sk-ant-*` keys)." Same treatment for OAuth access tokens landing in `ANTHROPIC_API_KEY` (symmetric mis-assignment). (c) In `rust/README.md` on `main` and the matrix section on `dev/rust`, add a short "Which env var goes where" paragraph mapping `sk-ant-*` → `ANTHROPIC_API_KEY` and OAuth access token → `ANTHROPIC_AUTH_TOKEN`, with the one-line explanation of `x-api-key` vs `Authorization: Bearer`. **Verification path.** Both improvements can be tested with unit tests against `ApiError::fmt` output (the prefix-routing hint) and with a targeted integration test that feeds an `sk-ant-*`-shaped token into `BearerToken` and asserts the fmt output surfaces the correction hint (no HTTP call needed). **Source.** Live users in #claw-code at `1491328554598924389` (varleg) and `1491329840706486376` (stanley078852) on 2026-04-08. **Partial landing (`ff1df4c`).** Action parts (a), (b), (c) shipped on `main`: `MissingCredentials` now carries an optional hint field and renders adjacent-provider signals, Anthropic 401 + `sk-ant-*` bearer gets a correction hint, USAGE.md has a "Which env var goes where" section. BUT the copy fix only helps users who fell through to the Anthropic auth path by accident — it does NOT fix the underlying routing bug where the CLI instantiates `AnthropicRuntimeClient` unconditionally and ignores prefix routing at the runtime-client layer. That deeper routing gap is tracked separately as #29 below and was filed within hours of #28 landing when live users still hit `missing Anthropic credentials` with `--model openai/gpt-4` and all `ANTHROPIC_*` env vars unset. | `ROADMAP.md:L1111` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage`, `stable_alpha_contracts` | — | | `CC2-RM-A0053-cli-provider-dispatch-is-hardcoded-to-an` | **CLI provider dispatch is hardcoded to Anthropic, ignoring prefix routing** — **done at `8dc6580` on 2026-04-08**. Changed `AnthropicRuntimeClient.client` from concrete `AnthropicClient` to `ApiProviderClient` (the api crate's `ProviderClient` enum), which dispatches to Anthropic / xAI / OpenAi at construction time based on `detect_provider_kind(&resolved_model)`. 1 file, +59 −7, all 182 rusty-claude-cli tests pass, CI green at run `24125825431`. Users can now run `claw --model openai/gpt-4.1-mini prompt "hello"` with only `OPENAI_API_KEY` set and it routes correctly. **Original filing below for the trace record.** Dogfooded live on 2026-04-08 within hours of ROADMAP #28 landing. Users in #claw-code (nicma at `1491342350960562277`, Jengro at `1491345009021030533`) followed the exact "use main, set OPENAI_API_KEY and OPENAI_BASE_URL, unset ANTHROPIC_*, prefix the model with `openai/`" checklist from the #28 error-copy improvements AND STILL hit `error: missing Anthropic credentials; export ANTHROPIC_AUTH_TOKEN or ANTHROPIC_API_KEY before calling the Anthropic API`. **Reproduction on `main` HEAD `ff1df4c`:** `unset ANTHROPIC_API_KEY ANTHROPIC_AUTH_TOKEN; export OPENAI_API_KEY=sk-...; export OPENAI_BASE_URL=https://api.openai.com/v1; claw --model openai/gpt-4 prompt 'test'` → reproduces the error deterministically. **Root cause (traced).** `rust/crates/rusty-claude-cli/src/main.rs` at `build_runtime_with_plugin_state` (line ~6221) unconditionally builds `AnthropicRuntimeClient::new(session_id, model, ...)` without consulting `providers::detect_provider_kind(&model)`. `BuiltRuntime` at line ~2855 is statically typed as `ConversationRuntime`, so even if the dispatch logic existed there would be nowhere to slot an alternative client. `providers/mod.rs::metadata_for_model` correctly identifies `openai/gpt-4` as `ProviderKind::OpenAi` at the metadata layer — the routing decision is *computed* correctly, it's just *never used* to pick a runtime client. The result is that the CLI is structurally single-provider (Anthropic only) even though the `api` crate's `openai_compat.rs`, `XAI_ENV_VARS`, `DASHSCOPE_ENV_VARS`, and `send_message_streaming` all exist and are exercised by unit tests inside the `api` crate. The provider matrix in `rust/README.md` is misleading because it describes the api-crate capabilities, not the CLI's actual dispatch behaviour. **Why #28 didn't catch this.** ROADMAP #28 focused on the `MissingCredentials` error *message* (adding hints when adjacent provider env vars are set, or when a bearer token starts with `sk-ant-*`). None of its tests exercised the `build_runtime` code path — they were all unit tests against `ApiError::fmt` output. The routing bug survives #28 because the `Display` improvements fire AFTER the hardcoded Anthropic client has already been constructed and failed. You need the CLI to dispatch to a different client in the first place for the new hints to even surface at the right moment. **Action (single focused commit).** (1) New `OpenAiCompatRuntimeClient` struct in `rust/crates/rusty-claude-cli/src/main.rs` mirroring `AnthropicRuntimeClient` but delegating to `openai_compat::send_message_streaming`. One client type handles OpenAI, xAI, DashScope, and any OpenAI-compat endpoint — they differ only in base URL and auth env var, both of which come from the `ProviderMetadata` returned by `metadata_for_model`. (2) New enum `DynamicApiClient { Anthropic(AnthropicRuntimeClient), OpenAiCompat(OpenAiCompatRuntimeClient) }` that implements `runtime::ApiClient` by matching on the variant and delegating. (3) Retype `BuiltRuntime` from `ConversationRuntime` to `ConversationRuntime`, update the Deref/DerefMut/new spots. (4) In `build_runtime_with_plugin_state`, call `detect_provider_kind(&model)` and construct either variant of `DynamicApiClient`. Prefix routing wins over env-var presence (that's the whole point). (5) Integration test using a mock OpenAI-compat server (reuse `mock_parity_harness` pattern from `crates/api/tests/`) that feeds `claw --model openai/gpt-4 prompt 'test'` with `OPENAI_BASE_URL` pointed at the mock and no `ANTHROPIC_*` env vars, asserts the request reaches the mock, and asserts the response round-trips as an `AssistantEvent`. (6) Unit test that `build_runtime_with_plugin_state` with `model="openai/gpt-4"` returns a `BuiltRuntime` whose inner client is the `DynamicApiClient::OpenAiCompat` variant. **Verification.** `cargo test --workspace`, `cargo fmt --all`, `cargo clippy --workspace`. **Source.** Live users nicma (`1491342350960562277`) and Jengro (`1491345009021030533`) in #claw-code on 2026-04-08, within hours of #28 landing. | `ROADMAP.md:L1112` / `roadmap_action` | `alpha_blocker` | `stale_done` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | Marked done in roadmap but needs freshness re-verification before being used as release evidence. | | `CC2-RM-A0054-immediate-backlog-visibility-gap-active` | **Immediate-backlog visibility gap: active dogfood pinpoints are easy to rediscover because ROADMAP lacks a concise in-progress board** — dogfooding on 2026-04-21 surfaced a softer but recurring clawability failure: there are real active branches/sessions (`claw-code-issue-21-resumed-status-json`, `claw-code-issue-24-plugin-lifecycle-flake`, `claw-code-issue-33-xai-integration`), but a claw doing a fresh sweep still has to scrape tmux names, branch diffs, and long-form ROADMAP prose to answer a simple question: "what pinpoint is already active right now, and what delta is in flight?" The result is rediscovery churn, duplicate reporting, and weak handoff quality even when the actual engineering work is already moving. **Concrete gap.** `ROADMAP.md` has rich long-form entries and a large done/archive surface, but no compact machine-friendly `In Progress Now` section that binds `{roadmap_id, pinpoint, owner/session, branch, status, blocker}`. **Action.** Add a small top-of-file/current-work section (or generated JSON companion) that lists only active dogfood items with stable ids and lifecycle state, and require dogfood updates to reference that id when reporting progress. Minimum fields: item id, lifecycle state, current session/branch, one-line delta, blocker/none, last-updated timestamp. **Acceptance.** A fresh claw can answer "what is active now?" from one short section without scraping panes, and repeat dogfood nudges can distinguish `already in progress` from `new pinpoint` automatically. | `ROADMAP.md:L1113` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | none | — | | `CC2-RM-A0066-dashscope-model-routing-in-providerclien` | **DashScope model routing in ProviderClient dispatch uses wrong config** — **done at `adcea6b` on 2026-04-08**. `ProviderClient::from_model_with_anthropic_auth` dispatched all `ProviderKind::OpenAi` matches to `OpenAiCompatConfig::openai()` (reads `OPENAI_API_KEY`, points at `api.openai.com`). But DashScope models (`qwen-plus`, `qwen/qwen-max`) return `ProviderKind::OpenAi` because DashScope speaks the OpenAI wire format — they need `OpenAiCompatConfig::dashscope()` (reads `DASHSCOPE_API_KEY`, points at `dashscope.aliyuncs.com/compatible-mode/v1`). Fix: consult `metadata_for_model` in the `OpenAi` dispatch arm and pick `dashscope()` vs `openai()` based on `metadata.auth_env`. Adds regression test + `pub base_url()` accessor. 2 files, +94/−3. Authored by droid (Kimi K2.5 Turbo) via acpx, cleaned up by Jobdori. | `ROADMAP.md:L1205` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage`, `stable_alpha_contracts` | — | | `CC2-RM-A0067-code-on-disk-verified-commit-lands-depen` | **`code-on-disk → verified commit lands` depends on undocumented executor quirks** — **verified external/non-actionable on 2026-04-12:** current `main` has no repo-local implementation surface for `acpx`, `use-droid`, `run-acpx`, `commit-wrapper`, or the cited `spawn ENOENT` behavior outside `ROADMAP.md`; those failures live in the external droid/acpx executor-orchestrator path, not claw-code source in this repository. Treat this as an external tracking note instead of an in-repo Immediate Backlog item. **Original filing below.** | `ROADMAP.md:L1207` / `roadmap_action` | `rejected_not_claw` | `rejected_not_claw` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage`, `stable_alpha_contracts` | Rejected because the source describes clone-only breadth or behavior outside Claw's machine-truth/clawable-harness identity. | | `CC2-RM-A0068-code-on-disk-verified-commit-lands-depen` | **`code-on-disk → verified commit lands` depends on undocumented executor quirks** — dogfooded 2026-04-08 during live fix session. Three hidden contracts tripped the "last mile" path when using droid via acpx in the claw-code workspace: **(a) hidden CWD contract** — droid's `terminal/create` rejects `cd /path && cargo build` compound commands with `spawn ENOENT`; callers must pass `--cwd` or split commands; **(b) hidden commit-message transport limit** — embedding a multi-line commit message in a single shell invocation hits `ENAMETOOLONG`; workaround is `git commit -F ` but the caller must know to write the file first; **(c) hidden workspace lint/edition contract** — `unsafe_code = "forbid"` workspace-wide with Rust 2021 edition makes `unsafe {}` wrappers incorrect for `set_var`/`remove_var`, but droid generates Rust 2024-style unsafe blocks without inspecting the workspace Cargo.toml or clippy config. Each of these required the orchestrator to learn the constraint by failing, then switching strategies. **Acceptance bar:** a fresh agent should be able to verify/commit/push a correct diff in this workspace without needing to know executor-specific shell trivia ahead of time. **Fix shape:** (1) `run-acpx.sh`-style wrapper that normalizes the commit idiom (always writes to temp file, sets `--cwd`, splits compound commands); (2) inject workspace constraints into the droid/acpx task preamble (edition, lint gates, known shell executor quirks) so the model doesn't have to discover them from failures; (3) or upstream a fix to the executor itself so `cd /path && cmd` chains work correctly. | `ROADMAP.md:L1209` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage`, `stable_alpha_contracts` | — | | `CC2-RM-A0069-openai-compatible-provider-model-id-pass` | **OpenAI-compatible provider/model-id passthrough is not fully literal** — **verified no-bug on 2026-04-09**: `resolve_model_alias()` only matches bare shorthand aliases (`opus`/`sonnet`/`haiku`) and passes everything else through unchanged, so `openai/gpt-4` reaches the dispatch layer unmodified. `strip_routing_prefix()` at `openai_compat.rs:732` then strips only recognised routing prefixes (`openai`, `xai`, `grok`, `qwen`) so the wire model is the bare backend id. No fix needed. **Original filing below.** | `ROADMAP.md:L1211` / `roadmap_action` | `beta_adoption` | `stale_done` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | Marked done in roadmap but needs freshness re-verification before being used as release evidence. | | `CC2-RM-A0070-hook-json-failure-opacity-invalid-hook-o` | **Hook JSON failure opacity: invalid hook output does not surface the offending payload/context** — dogfooding on 2026-04-13 in the live `clawcode-human` lane repeatedly hit `PreToolUse/PostToolUse/Stop hook returned invalid ... JSON output` while the operator had no immediate visibility into which hook emitted malformed JSON, what raw stdout/stderr came back, or whether the failure was hook-formatting breakage vs prompt-misdelivery fallout. This turns a recoverable hook/schema bug into generic lane fog. **Impact.** Lanes look blocked/noisy, but the event surface is too lossy to classify whether the next action is fix the hook serializer, retry prompt delivery, or ignore a harmless hook-side warning. **Concrete delta landed now.** Recorded as an Immediate Backlog item so the failure is tracked explicitly instead of disappearing into channel scrollback. **Recommended fix shape:** when hook JSON parse fails, emit a typed hook failure event carrying hook phase/name, command/path, exit status, and a redacted raw stdout/stderr preview (bounded + safe), plus a machine class like `hook_invalid_json`. Add regression coverage for malformed-but-nonempty hook output so the surfaced error includes the preview instead of only `invalid ... JSON output`. | `ROADMAP.md:L1213` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0071-openai-compatible-provider-model-id-pass` | **OpenAI-compatible provider/model-id passthrough is not fully literal** — dogfooded 2026-04-08 via live user in #claw-code who confirmed the exact backend model id works outside claw but fails through claw for an OpenAI-compatible endpoint. The gap: `openai/` prefix is correctly used for **transport selection** (pick the OpenAI-compat client) but the **wire model id** — the string placed in `"model": "..."` in the JSON request body — may not be the literal backend model string the user supplied. Two candidate failure modes: **(a)** `resolve_model_alias()` is called on the model string before it reaches the wire — alias expansion designed for Anthropic/known models corrupts a user-supplied backend-specific id; **(b)** the `openai/` routing prefix may not be stripped before `build_chat_completion_request` packages the body, so backends receive `openai/gpt-4` instead of `gpt-4`. **Fix shape:** cleanly separate transport selection from wire model id. Transport selection uses the prefix; wire model id is the user-supplied string minus only the routing prefix — no alias expansion, no prefix leakage. **Trace path for next session:** (1) find where `resolve_model_alias()` is called relative to the OpenAI-compat dispatch path; (2) inspect what `build_chat_completion_request` puts in `"model"` for an `openai/some-backend-id` input. **Source:** live user in #claw-code 2026-04-08, confirmed exact model id works outside claw, fails through claw for OpenAI-compat backend. | `ROADMAP.md:L1215` / `roadmap_action` | `rejected_not_claw` | `rejected_not_claw` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | Rejected because the source describes clone-only breadth or behavior outside Claw's machine-truth/clawable-harness identity. | | `CC2-RM-A0072-openai-responses-endpoint-rejects-claw-s` | **OpenAI `/responses` endpoint rejects claw's tool schema: `object schema missing properties` / `invalid_function_parameters`** — **done at `e7e0fd2` on 2026-04-09**. Added `normalize_object_schema()` in `openai_compat.rs` which recursively walks JSON Schema trees and injects `"properties": {}` and `"additionalProperties": false` on every object-type node (without overwriting existing values). Called from `openai_tool_definition()` so both `/chat/completions` and `/responses` receive strict-validator-safe schemas. 3 unit tests added. All api tests pass. **Original filing below.** | `ROADMAP.md:L1217` / `roadmap_action` | `beta_adoption` | `stale_done` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | Marked done in roadmap but needs freshness re-verification before being used as release evidence. | | `CC2-RM-A0073-openai-responses-endpoint-rejects-claw-s` | **OpenAI `/responses` endpoint rejects claw's tool schema: `object schema missing properties` / `invalid_function_parameters`** — dogfooded 2026-04-08 via live user in #claw-code. Repro: startup succeeds, provider routing succeeds (`Connected: gpt-5.4 via openai`), but request fails when claw sends tool/function schema to a `/responses`-compatible OpenAI backend. Backend rejects `StructuredOutput` with `object schema missing properties` and `invalid_function_parameters`. This is distinct from the `#32` model-id passthrough issue — routing and transport work correctly. The failure is at the schema validation layer: claw's tool schema is acceptable for `/chat/completions` but not strict enough for `/responses` endpoint validation. **Sharp next check:** emit what schema claw sends for `StructuredOutput` tool functions, compare against OpenAI `/responses` spec for strict JSON schema validation (required `properties` object, `additionalProperties: false`, etc). Likely fix: add missing `properties: {}` on object types, ensure `additionalProperties: false` is present on all object schemas in the function tool JSON. **Source:** live user in #claw-code 2026-04-08 with `gpt-5.4` on OpenAI-compat backend. | `ROADMAP.md:L1218` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0074-reasoning-effort-budget-tokens-not-surfa` | **`reasoning_effort` / `budget_tokens` not surfaced on OpenAI-compat path** — **done (verified 2026-04-11):** current `main` already carries the Rust-side OpenAI-compat parity fix. `MessageRequest` now includes `reasoning_effort: Option` in `rust/crates/api/src/types.rs`, `build_chat_completion_request()` emits `"reasoning_effort"` in `rust/crates/api/src/providers/openai_compat.rs`, and the CLI threads `--reasoning-effort low\|medium\|high` through to the API client in `rust/crates/rusty-claude-cli/src/main.rs`. The OpenAI-side parity target here is `reasoning_effort`; Anthropic-only `budget_tokens` remains handled on the Anthropic path. Re-verified on current `origin/main` / HEAD `2d5f836`: `cargo test -p api reasoning_effort -- --nocapture` passes (2 passed), and `cargo test -p rusty-claude-cli reasoning_effort -- --nocapture` passes (2 passed). Historical proof: `e4c3871` added the request field + OpenAI-compatible payload serialization, `ca8950c2` wired the CLI end-to-end, and `f741a425` added CLI validation coverage. **Original filing below.** | `ROADMAP.md:L1220` / `roadmap_action` | `beta_adoption` | `stale_done` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | Marked done in roadmap but needs freshness re-verification before being used as release evidence. | | `CC2-RM-A0075-reasoning-effort-budget-tokens-not-surfa` | **`reasoning_effort` / `budget_tokens` not surfaced on OpenAI-compat path** — dogfooded 2026-04-09. Users asking for "reasoning effort parity with opencode" are hitting a structural gap: `MessageRequest` in `rust/crates/api/src/types.rs` has no `reasoning_effort` or `budget_tokens` field, and `build_chat_completion_request` in `openai_compat.rs` does not inject either into the request body. This means passing `--thinking` or equivalent to an OpenAI-compat reasoning model (e.g. `o4-mini`, `deepseek-r1`, any model that accepts `reasoning_effort`) silently drops the field — the model runs without the requested effort level, and the user gets no warning. **Contrast with Anthropic path:** `anthropic.rs` already maps `thinking` config into `anthropic.thinking.budget_tokens` in the request body. **Fix shape:** (a) Add optional `reasoning_effort: Option` field to `MessageRequest`; (b) In `build_chat_completion_request`, if `reasoning_effort` is `Some`, emit `"reasoning_effort": value` in the JSON body; (c) In the CLI, wire `--thinking low/medium/high` or equivalent to populate the field when the resolved provider is `ProviderKind::OpenAi`; (d) Add unit test asserting `reasoning_effort` appears in the request body when set. **Source:** live user questions in #claw-code 2026-04-08/09 (dan_theman369 asking for "same flow as opencode for reasoning effort"; gaebal-gajae confirmed gap at `1491453913100976339`). Companion gap to #33 on the OpenAI-compat path. | `ROADMAP.md:L1222` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0076-openai-gpt-5-x-requires-max-completion-t` | **OpenAI gpt-5.x requires max_completion_tokens not max_tokens** — **done (verified 2026-04-11):** current `main` already carries the Rust-side OpenAI-compat fix. `build_chat_completion_request()` in `rust/crates/api/src/providers/openai_compat.rs` switches the emitted key to `"max_completion_tokens"` whenever the wire model starts with `gpt-5`, while older models still use `"max_tokens"`. Regression test `gpt5_uses_max_completion_tokens_not_max_tokens()` proves `gpt-5.2` emits `max_completion_tokens` and omits `max_tokens`. Re-verified against current `origin/main` `d40929ca`: `cargo test -p api gpt5_uses_max_completion_tokens_not_max_tokens -- --nocapture` passes. Historical proof: `eb044f0a` landed the request-field switch plus regression test on 2026-04-09. Source: rklehm in #claw-code 2026-04-09. | `ROADMAP.md:L1224` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0077-custom-project-skill-invocation-disconne` | **Custom/project skill invocation disconnected from skill discovery** — **done (verified 2026-04-11):** current `main` already routes bare-word skill input in the REPL through `resolve_skill_invocation()` instead of forwarding it to the model. `rust/crates/rusty-claude-cli/src/main.rs` now treats a leading bare token that matches a known skill name as `/skills `, while `rust/crates/commands/src/lib.rs` validates the skill against discovered project/user skill roots and reports available-skill guidance on miss. Fresh regression coverage proves the known-skill dispatch path and the unknown/non-skill bypass. Historical proof: `8d0308ee` landed the REPL dispatch fix. Source: gaebal-gajae dogfood 2026-04-09. | `ROADMAP.md:L1226` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0078-claude-subscription-login-path-should-be` | **Claude subscription login path should be removed, not deprecated** -- dogfooded 2026-04-09. Official auth should be API key only (`ANTHROPIC_API_KEY`) or OAuth bearer token via `ANTHROPIC_AUTH_TOKEN`; the local `claw login` / `claw logout` subscription-style flow created legal/billing ambiguity and a misleading saved-OAuth fallback. **Done (verified 2026-04-11):** removed the direct `claw login` / `claw logout` CLI surface, removed `/login` and `/logout` from shared slash-command discovery, changed both CLI and provider startup auth resolution to ignore saved OAuth credentials, and updated auth diagnostics to point only at `ANTHROPIC_API_KEY` / `ANTHROPIC_AUTH_TOKEN`. Verification: targeted `commands`, `api`, and `rusty-claude-cli` tests for removed login/logout guidance and ignored saved OAuth all pass, and `cargo check -p api -p commands -p rusty-claude-cli` passes. Source: gaebal-gajae policy decision 2026-04-09. | `ROADMAP.md:L1228` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0079-dead-session-opacity-bot-cannot-self-det` | **Dead-session opacity: bot cannot self-detect compaction vs broken tool surface** -- dogfooded 2026-04-09. Jobdori session spent ~15h declaring itself "dead" in-channel while tools were actually returning correct results within each turn. Root cause: context compaction causes tool outputs to be summarised away between turns, making the bot interpret absence-of-remembered-output as tool failure. This is a distinct failure mode from ROADMAP #31 (executor quirks): the session is alive and tools are functional, but the agent cannot tell the difference between "my last tool call produced no output" (compaction) and "the tool is broken". **Done (verified 2026-04-11):** `ConversationRuntime::run_turn()` now runs a post-compaction session-health probe through `glob_search`, fails fast with a targeted recovery error if the tool surface is broken, and skips the probe for a freshly compacted empty session. Fresh regression coverage proves both the failure gate and the empty-session bypass. Source: Jobdori self-dogfood 2026-04-09; observed in #clawcode-building-in-public across multiple Clawhip nudge cycles. | `ROADMAP.md:L1230` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0080-several-slash-commands-were-registered-b` | **Several slash commands were registered but not implemented: /branch, /rewind, /ide, /tag, /output-style, /add-dir** — **done (verified 2026-04-12):** current `main` already hides those stub commands from the user-facing discovery surfaces that mattered for the original report. Shared help rendering excludes them via `render_slash_command_help_filtered(...)`, and REPL completions exclude them via `STUB_COMMANDS`. Fresh proof: `cargo test -p commands renders_help_from_shared_specs -- --nocapture`, `cargo test -p rusty-claude-cli shared_help_uses_resume_annotation_copy -- --nocapture`, and `cargo test -p rusty-claude-cli stub_commands_absent_from_repl_completions -- --nocapture` all pass on current `origin/main`. Source: mezz2301 in #claw-code 2026-04-09; pinpointed in main.rs:3728. | `ROADMAP.md:L1232` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0081-surface-broken-installed-plugins-before` | **Surface broken installed plugins before they become support ghosts** — community-support lane. Clawhip commit `ff6d3b7` on worktree `claw-code-community-support-plugin-list-load-failures` / branch `community-support/plugin-list-load-failures`. When an installed plugin has a broken manifest (missing hook scripts, parse errors, bad json), the plugin silently fails to load and the user sees nothing — no warning, no list entry, no hint. Related to ROADMAP #27 (host plugin path leaking into tests) but at the user-facing surface: the test gap and the UX gap are siblings of the same root. **Done (verified 2026-04-11):** `PluginManager::plugin_registry_report()` and `installed_plugin_registry_report()` now preserve valid plugins while collecting `PluginLoadFailure`s, and the command-layer renderer emits a `Warnings:` block for broken plugins instead of silently hiding them. Fresh proof: `cargo test -p plugins plugin_registry_report_collects_load_failures_without_dropping_valid_plugins -- --nocapture`, `cargo test -p plugins installed_plugin_registry_report_collects_load_failures_from_install_root -- --nocapture`, and a new `commands` regression covering `render_plugins_report_with_failures()` all pass on current main. | `ROADMAP.md:L1234` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0082-stop-ambient-plugin-state-from-skewing-c` | **Stop ambient plugin state from skewing CLI regression checks** — community-support lane. Clawhip commit `7d493a7` on worktree `claw-code-community-support-plugin-test-sealing` / branch `community-support/plugin-test-sealing`. Companion to #40: the test sealing gap is the CI/developer side of the same root — host `~/.claude/plugins/installed/` bleeds into CLI test runs, making regression checks non-deterministic on any machine with a non-pristine plugin install. Closely related to ROADMAP #27 (dev/rust `cargo test` reads host plugin state). **Done (verified 2026-04-11):** the plugins crate now carries dedicated test-isolation helpers in `rust/crates/plugins/src/test_isolation.rs`, and regression `claw_config_home_isolation_prevents_host_plugin_leakage()` proves `CLAW_CONFIG_HOME` isolation prevents host plugin state from leaking into installed-plugin discovery during tests. | `ROADMAP.md:L1236` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0083-output-format-json-errors-emitted-as-pro` | **`--output-format json` errors emitted as prose, not JSON** — dogfooded 2026-04-09. When `claw --output-format json prompt` hits an API error, the error was printed as plain text (`error: api returned 401 ...`) to stderr instead of a JSON object. Any tool or CI step parsing claw's JSON output gets nothing parseable on failure — the error is invisible to the consumer. **Fix (`a...`):** detect `--output-format json` in `main()` at process exit and emit `{"type":"error","error":""}` to stderr instead of the prose format. Non-JSON path unchanged. **Done** in this nudge cycle. | `ROADMAP.md:L1238` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0084-hook-ingress-opacity-typed-hook-health-d` | **Hook ingress opacity: typed hook-health/delivery report missing** — **verified likely external tracking on 2026-04-12:** repo-local searches for `/hooks/health`, `/hooks/status`, and hook-ingress route code found no implementation surface outside `ROADMAP.md`, and the prior state-surface note below already records that the HTTP server is not owned by claw-code. Treat this as likely upstream/server-surface tracking rather than an immediate claw-code task. **Original filing below.** | `ROADMAP.md:L1240` / `roadmap_action` | `beta_adoption` | `stale_done` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | Marked done in roadmap but needs freshness re-verification before being used as release evidence. | | `CC2-RM-A0085-hook-ingress-opacity-typed-hook-health-d` | **Hook ingress opacity: typed hook-health/delivery report missing** — dogfooded 2026-04-09 while wiring the agentika timer→hook→session bridge. Debugging hook delivery required manual HTTP probing and inferring state from raw status codes (404 = no route, 405 = route exists, 400 = body missing required field). No typed endpoint exists to report: route present/absent, accepted methods, mapping matched/not matched, target session resolved/not resolved, last delivery failure class. Fix shape: add `GET /hooks/health` (or `/hooks/status`) returning a structured JSON diagnostic — no auth exposure, just routing/matching/session state. Source: gaebal-gajae dogfood 2026-04-09. | `ROADMAP.md:L1241` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0086-broad-cwd-guardrail-is-warning-only-need` | **Broad-CWD guardrail is warning-only; needs policy-level enforcement** — dogfooded 2026-04-09. `5f6f453` added a stderr warning when claw starts from `$HOME` or filesystem root (live user kapcomunica scanned their whole machine). Warning is a mitigation, not a guardrail: the agent still proceeds with unbounded scope. Follow-up fix shape: (a) add `--allow-broad-cwd` flag to suppress the warning explicitly (for legitimate home-dir use cases); (b) in default interactive mode, prompt "You are running from your home directory — continue? [y/N]" and exit unless confirmed; (c) in `--output-format json` or piped mode, treat broad-CWD as a hard error (exit 1) with `{"type":"error","error":"broad CWD: running from home directory requires --allow-broad-cwd"}`. Source: kapcomunica in #claw-code 2026-04-09; gaebal-gajae ROADMAP note same cycle. | `ROADMAP.md:L1243` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0087-claw-dump-manifests-fails-with-opaque-no` | **`claw dump-manifests` fails with opaque "No such file or directory"** — dogfooded 2026-04-09. `claw dump-manifests` emits `error: failed to extract manifests: No such file or directory (os error 2)` with no indication of which file or directory is missing. **Partial fix at `47aa1a5`+1**: error message now includes `looked in: ` so the build-tree path is visible, what manifests are, or how to fix it. Fix shape: (a) surface the missing path in the error message; (b) add a pre-check that explains what manifests are and where they should be (e.g. `.claw/manifests/` or the plugins directory); (c) if the command is only valid after `claw init` or after installing plugins, say so explicitly. Source: Jobdori dogfood 2026-04-09. | `ROADMAP.md:L1245` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0088-claw-dump-manifests-fails-with-opaque-no` | **`claw dump-manifests` fails with opaque `No such file or directory`** — **done (verified 2026-04-12):** current `main` now accepts `claw dump-manifests --manifests-dir PATH`, pre-checks for the required upstream manifest files (`src/commands.ts`, `src/tools.ts`, `src/entrypoints/cli.tsx`), and replaces the opaque os error with guidance that points users to `CLAUDE_CODE_UPSTREAM` or `--manifests-dir`. Fresh proof: parser coverage for both flag forms, unit coverage for missing-manifest and explicit-path flows, and `output_format_contract` JSON coverage via the new flag all pass. **Original filing below.** | `ROADMAP.md:L1247` / `roadmap_action` | `beta_adoption` | `stale_done` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | Marked done in roadmap but needs freshness re-verification before being used as release evidence. | | `CC2-RM-A0089-claw-dump-manifests-fails-with-opaque-no` | **`claw dump-manifests` fails with opaque `No such file or directory`** — **done (verified 2026-04-12):** current `main` now accepts `claw dump-manifests --manifests-dir PATH`, pre-checks for the required upstream manifest files (`src/commands.ts`, `src/tools.ts`, `src/entrypoints/cli.tsx`), and replaces the opaque os error with guidance that points users to `CLAUDE_CODE_UPSTREAM` or `--manifests-dir`. Fresh proof: parser coverage for both flag forms, unit coverage for missing-manifest and explicit-path flows, and `output_format_contract` JSON coverage via the new flag all pass. **Original filing below.** | `ROADMAP.md:L1248` / `roadmap_action` | `beta_adoption` | `stale_done` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | Marked done in roadmap but needs freshness re-verification before being used as release evidence. | | `CC2-RM-A0090-tokens-cache-stats-were-dead-spec-parse` | **`/tokens`, `/cache`, `/stats` were dead spec — parse arms missing** — dogfooded 2026-04-09. All three had spec entries with `resume_supported: true` but no parse arms, producing the circular error "Unknown slash command: /tokens — Did you mean /tokens". Also `SlashCommand::Stats` existed but was unimplemented in both REPL and resume dispatch. **Done at `60ec2ae` 2026-04-09**: `"tokens" \| "cache"` now alias to `SlashCommand::Stats`; `Stats` is wired in both REPL and resume path with full JSON output. Source: Jobdori dogfood. | `ROADMAP.md:L1249` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0091-diff-fails-with-cryptic-unknown-option-c` | **`/diff` fails with cryptic "unknown option 'cached'" outside a git repo; resume /diff used wrong CWD** — dogfooded 2026-04-09. `claw --resume /diff` in a non-git directory produced `git diff --cached failed: error: unknown option 'cached'` because git falls back to `--no-index` mode outside a git tree. Also resume `/diff` used `session_path.parent()` (the `.claw/sessions//` dir) as CWD for the diff — never a git repo. **Done at `aef85f8` 2026-04-09**: `render_diff_report_for()` now checks `git rev-parse --is-inside-work-tree` first and returns a clear "no git repository" message; resume `/diff` uses `std::env::current_dir()`. Source: Jobdori dogfood. | `ROADMAP.md:L1251` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0092-piped-stdin-triggers-repl-startup-and-ba` | **Piped stdin triggers REPL startup and banner instead of one-shot prompt** — dogfooded 2026-04-09. `echo "hello" \| claw` started the interactive REPL, printed the ASCII banner, consumed the pipe without sending anything to the API, then exited. `parse_args` always returned `CliAction::Repl` when no args were given, never checking whether stdin was a pipe. **Done at `84b77ec` 2026-04-09**: when `rest.is_empty()` and stdin is not a terminal, read the pipe and dispatch as `CliAction::Prompt`. Empty pipe still falls through to REPL. Source: Jobdori dogfood. | `ROADMAP.md:L1253` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0093-resumed-slash-command-errors-emitted-as` | **Resumed slash command errors emitted as prose in `--output-format json` mode** — dogfooded 2026-04-09. `claw --output-format json --resume /commit` called `eprintln!()` and `exit(2)` directly, bypassing the JSON formatter. Both the slash-command parse-error path and the `run_resume_command` Err path now check `output_format` and emit `{"type":"error","error":"...","command":"..."}`. **Done at `da42421` 2026-04-09**. Source: gaebal-gajae ROADMAP #26 track; Jobdori dogfood. | `ROADMAP.md:L1255` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0094-powershell-tool-is-registered-as-danger` | **PowerShell tool is registered as `danger-full-access` — workspace-aware reads still require escalation** — dogfooded 2026-04-10. User running `workspace-write` session mode (tanishq_devil in #claw-code) had to use `danger-full-access` even for simple in-workspace reads via PowerShell (e.g. `Get-Content`). Root cause traced by gaebal-gajae: `PowerShell` tool spec is registered with `required_permission: PermissionMode::DangerFullAccess` (same as the `bash` tool in `mvp_tool_specs`), not with per-command workspace-awareness. Bash shell and PowerShell execute arbitrary commands, so blanket promotion to `danger-full-access` is conservative — but it over-escalates read-only in-workspace operations. Fix shape: (a) add command-level heuristic analysis to the PowerShell executor (read-only commands like `Get-Content`, `Get-ChildItem`, `Test-Path` that target paths inside CWD → `WorkspaceWrite` required; everything else → `DangerFullAccess`); (b) mirror the same workspace-path check that the bash executor uses; (c) add tests covering the permission boundary for PowerShell read vs write vs network commands. Note: the `bash` tool in `mvp_tool_specs` is also `DangerFullAccess` and has the same gap — both should be fixed together. Source: tanishq_devil in #claw-code 2026-04-10; root cause identified by gaebal-gajae. | `ROADMAP.md:L1257` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0095-windows-first-run-onboarding-missing-no` | **Windows first-run onboarding missing: no explicit Rust + shell prerequisite branch** — dogfooded 2026-04-10 via #claw-code. User hit `bash: cargo: command not found`, `C:\...` vs `/c/...` path confusion in Git Bash, and misread `MINGW64` prompt as a broken MinGW install rather than normal Git Bash. Root cause: README/docs have no Windows-specific install path that says (1) install Rust first via rustup, (2) open Git Bash or WSL (not PowerShell or cmd), (3) use `/c/Users/...` style paths in bash, (4) then `cargo install claw-code`. Users can reach chat mode confusion before realizing claw was never installed. Fix shape: add a **Windows setup** section to README.md (or INSTALL.md) with explicit prerequisite steps, Git Bash vs WSL guidance, and a note that `MINGW64` in the prompt is expected and normal. Source: tanishq_devil in #claw-code 2026-04-10; traced by gaebal-gajae. | `ROADMAP.md:L1259` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0096-cargo-install-claw-code-false-positive-i` | **`cargo install claw-code` false-positive install: deprecated stub silently succeeds** — dogfooded 2026-04-10 via #claw-code. User runs `cargo install claw-code`, install succeeds, Cargo places `claw-code-deprecated.exe`, user runs `claw` and gets `command not found`. The deprecated binary only prints `"claw-code has been renamed to agent-code"`. The success signal is false-positive: install appears to work but leaves the user with no working `claw` binary. Fix shape: (a) README must warn explicitly against `cargo install claw-code` with the hyphen (current note only warns about `clawcode` without hyphen); (b) if the deprecated crate is in our control, update its binary to print a clearer redirect message including `cargo install agent-code`; (c) ensure the Windows setup doc path mentions `agent-code` explicitly. Source: user in #claw-code 2026-04-10; traced by gaebal-gajae. | `ROADMAP.md:L1261` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0097-cargo-install-agent-code-produces-agent` | **`cargo install agent-code` produces `agent.exe`, not `agent-code.exe` — binary name mismatch in docs** — dogfooded 2026-04-10 via #claw-code. User follows the `claw-code` rename hint to run `cargo install agent-code`, install succeeds, but the installed binary is `agent.exe` (Unix: `agent`), not `agent-code` or `agent-code.exe`. User tries `agent-code --version`, gets `command not found`, concludes install is broken. The package name (`agent-code`), the crate name, and the installed binary name (`agent`) are all different. Fix shape: docs must show the full chain explicitly: `cargo install agent-code` → run via `agent` (Unix) / `agent.exe` (Windows). ROADMAP #52 note updated with corrected binary name. Source: user in #claw-code 2026-04-10; traced by gaebal-gajae. | `ROADMAP.md:L1263` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0098-circular-did-you-mean-x-error-for-spec-r` | **Circular "Did you mean /X?" error for spec-registered commands with no parse arm** — dogfooded 2026-04-10. 23 commands in the spec (shown in `/help` output) had no parse arm in `validate_slash_command_input`, so typing them produced `"Unknown slash command: /X — Did you mean /X?"`. The "Did you mean" suggestion pointed at the exact command the user just typed. Root cause: spec registration and parse-arm implementation were independent — a command could appear in help and completions without being parseable. **Done at `1e14d59` 2026-04-10**: added all 23 to STUB_COMMANDS and added pre-parse intercept in resume dispatch. Source: Jobdori dogfood. | `ROADMAP.md:L1265` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0099-session-list-unsupported-in-resume-mode` | **`/session list` unsupported in resume mode despite only needing directory read** — dogfooded 2026-04-10. `/session list` in `--output-format json --resume` mode returned `"unsupported resumed slash command"`. The command only reads the sessions directory — no live runtime needed. **Done at `8dcf103` 2026-04-10**: added `Session{action:"list"}` arm in `run_resume_command()`. Emits `{kind:session_list, sessions:[...ids], active:}`. Partial progress on ROADMAP #21. Source: Jobdori dogfood. | `ROADMAP.md:L1267` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0100-resume-with-no-command-ignores-output-fo` | **`--resume` with no command ignores `--output-format json`** — dogfooded 2026-04-10. `claw --output-format json --resume ` (no slash command) printed prose `"Restored session from (N messages)."` to stdout, ignoring the JSON output format flag. **Done at `4f670e5` 2026-04-10**: empty-commands path now emits `{kind:restored, session_id, path, message_count}` in JSON mode. Source: Jobdori dogfood. | `ROADMAP.md:L1269` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0101-session-load-errors-bypass-output-format` | **Session load errors bypass `--output-format json` — prose error on corrupt JSONL** — dogfooded 2026-04-10. `claw --output-format json --resume /status` printed bare prose `"failed to restore session: ..."` to stderr, not a JSON error object. Both the path-resolution and JSONL-load error paths ignored `output_format`. **Done at `cf129c8` 2026-04-10**: both paths now emit `{type:error, error:"failed to restore session: "}` in JSON mode. Source: Jobdori dogfood. | `ROADMAP.md:L1271` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0102-windows-startup-crash-home-is-not-set-us` | **Windows startup crash: `HOME is not set`** — user report 2026-04-10 in #claw-code (MaxDerVerpeilte). On Windows, `HOME` is often unset — `USERPROFILE` is the native equivalent. Four code paths only checked `HOME`: `config_home_dir()` (tools), `credentials_home_dir()` (runtime/oauth), `detect_broad_cwd()` (CLI), and skill lookup roots (tools). All crashed or silently skipped on stock Windows installs. **Done at `b95d330` 2026-04-10**: all four paths now fall back to `USERPROFILE` when `HOME` is absent. Error message updated to suggest `USERPROFILE` or `CLAW_CONFIG_HOME`. Source: MaxDerVerpeilte in #claw-code. | `ROADMAP.md:L1273` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0103-session-metadata-does-not-persist-the-mo` | **Session metadata does not persist the model used** — dogfooded 2026-04-10. When resuming a session, `/status` reports `model: null` because the session JSONL stores no model field. A claw resuming a session cannot tell what model was originally used. The model is only known at runtime construction time via CLI flag or config. **Done at `0f34c66` 2026-04-10**: added `model: Option` to Session struct, persisted in session_meta JSONL record, surfaced in resumed `/status`. Source: Jobdori dogfood. | `ROADMAP.md:L1275` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0104-glob-search-silently-returns-0-results-f` | **`glob_search` silently returns 0 results for brace expansion patterns** — user report 2026-04-10 in #claw-code (zero, Windows/Unity). Patterns like `Assets/**/*.{cs,uxml,uss}` returned 0 files because the `glob` crate (v0.3) does not support shell-style brace groups. The agent fell back to shell tools as a workaround. **Done at `3a6c9a5` 2026-04-10**: added `expand_braces()` pre-processor that expands brace groups before passing to `glob::glob()`. Handles nested braces. Results deduplicated via `HashSet`. 5 regression tests. Source: zero in #claw-code; traced by gaebal-gajae. | `ROADMAP.md:L1277` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0105-openai-base-url-ignored-when-model-name` | **`OPENAI_BASE_URL` ignored when model name has no recognized prefix** — user report 2026-04-10 in #claw-code (MaxDerVerpeilte, Ollama). User set `OPENAI_BASE_URL=http://127.0.0.1:11434/v1` with model `qwen2.5-coder:7b` but claw asked for Anthropic credentials. `detect_provider_kind()` checks model prefix first, then falls through to env-var presence — but `OPENAI_BASE_URL` was not in the cascade, so unrecognized model names always hit the Anthropic default. **Done at `1ecdb10` 2026-04-10**: `OPENAI_BASE_URL` + `OPENAI_API_KEY` now beats Anthropic env-check. `OPENAI_BASE_URL` alone (no key, e.g. Ollama) is last-resort before Anthropic default. Source: MaxDerVerpeilte in #claw-code; traced by gaebal-gajae. | `ROADMAP.md:L1279` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage`, `stable_alpha_contracts` | — | | `CC2-RM-A0106-worker-state-file-surface-not-implemente` | **Worker state file surface not implemented** — **done (verified 2026-04-12):** current `main` already wires `emit_state_file(worker)` into the worker transition path in `rust/crates/runtime/src/worker_boot.rs`, atomically writes `.claw/worker-state.json`, and exposes the documented reader surface through `claw state` / `claw state --output-format json` in `rust/crates/rusty-claude-cli/src/main.rs`. Fresh proof exists in `runtime` regression `emit_state_file_writes_worker_status_on_transition`, the end-to-end `tools` regression `recovery_loop_state_file_reflects_transitions`, and direct CLI parsing coverage for `state` / `state --output-format json`. Source: Jobdori dogfood. | `ROADMAP.md:L1281` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0107-droid-session-completion-semantics-broke` | **Droid session completion semantics broken: code arrives after "status: completed"** — dogfooded 2026-04-12. Ultraclaw droid sessions (use-droid via acpx) report `session.status: completed` before file writes are fully flushed/synced to the working tree. Discovered +410 lines of "late-arriving" droid output that appeared after I had already assessed 8 sessions as "no code produced." This creates false-negative assessments and duplicate work. **Fix shape:** (a) droid agent should only report completion after explicit file-write confirmation (fsync or existence check); (b) or, claw-code should expose a `pending_writes` status that indicates "agent responded, disk flush pending"; (c) lane orchestrators should poll for file changes for N seconds after completion before final assessment. **Blocker:** none. Source: Jobdori ultraclaw dogfood 2026-04-12. | `ROADMAP.md:L1285` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage`, `stable_alpha_contracts` | — | | `CC2-RM-A0108-backlog-scanning-team-lanes-emit-opaque` | **Backlog-scanning team lanes emit opaque stops, not structured selection outcomes** — **done (verified 2026-04-12):** completed lane persistence in `rust/crates/tools/src/lib.rs` now recognizes backlog-scan selection summaries and records structured `selectionOutcome` metadata on `lane.finished`, including `chosenItems`, `skippedItems`, `action`, and optional `rationale`, while preserving existing non-selection and review-lane behavior. Regression coverage locks the structured backlog-scan payload alongside the earlier quality-floor and review-verdict paths. **Original filing below.** | `ROADMAP.md:L1292` / `roadmap_action` | `beta_adoption` | `stale_done` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | Marked done in roadmap but needs freshness re-verification before being used as release evidence. | | `CC2-RM-A0109-completion-aware-reminder-shutdown-missi` | **Completion-aware reminder shutdown missing** — **done (verified 2026-04-12):** completed lane persistence in `rust/crates/tools/src/lib.rs` now disables matching enabled cron reminders when the associated lane finishes successfully, and records the affected cron ids in `lane.finished.data.disabledCronIds`. Regression coverage locks the path where a ROADMAP-linked reminder is disabled on successful completion while leaving incomplete work untouched. **Original filing below.** | `ROADMAP.md:L1294` / `roadmap_action` | `beta_adoption` | `stale_done` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | Marked done in roadmap but needs freshness re-verification before being used as release evidence. | | `CC2-RM-A0110-scoped-review-lanes-do-not-emit-structur` | **Scoped review lanes do not emit structured verdicts** — **done (verified 2026-04-12):** completed lane persistence in `rust/crates/tools/src/lib.rs` now recognizes review-style `APPROVE`/`REJECT`/`BLOCKED` results and records structured `reviewVerdict`, `reviewTarget`, and `reviewRationale` metadata on the `lane.finished` event while preserving existing non-review lane behavior. Regression coverage locks both the normal completion path and a scoped review-lane completion payload. **Original filing below.** | `ROADMAP.md:L1296` / `roadmap_action` | `alpha_blocker` | `stale_done` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | Marked done in roadmap but needs freshness re-verification before being used as release evidence. | | `CC2-RM-A0111-internal-reinjection-resume-paths-leak-o` | **Internal reinjection/resume paths leak opaque control prose** — **done (verified 2026-04-12):** completed lane persistence in `rust/crates/tools/src/lib.rs` now recognizes `[OMX_TMUX_INJECT]`-style recovery control prose and records structured `recoveryOutcome` metadata on `lane.finished`, including `cause`, optional `targetLane`, and optional `preservedState`. Recovery-style summaries now normalize to a human-meaningful fallback instead of surfacing the raw internal marker as the primary lane result. Regression coverage locks both the tmux-idle reinjection path and the `Continue from current mode state` resume path. Source: gaebal-gajae / Jobdori dogfood 2026-04-12. | `ROADMAP.md:L1298` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0112-lane-stop-summaries-have-no-minimum-qual` | **Lane stop summaries have no minimum quality floor** — **done (verified 2026-04-12):** completed lane persistence in `rust/crates/tools/src/lib.rs` now normalizes vague/control-only stop summaries into a contextual fallback that includes the lane target and status, while preserving structured metadata about whether the quality floor fired (`qualityFloorApplied`, `rawSummary`, `reasons`, `wordCount`). Regression coverage locks both the pass-through path for good summaries and the fallback path for mushy summaries like `commit push everyting, keep sweeping $ralph`. **Original filing below.** | `ROADMAP.md:L1300` / `roadmap_action` | `beta_adoption` | `stale_done` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | Marked done in roadmap but needs freshness re-verification before being used as release evidence. | | `CC2-RM-A0113-install-source-ambiguity-misleads-real-u` | **Install-source ambiguity misleads real users** — **done (verified 2026-04-12):** repo-local Rust guidance now makes the source of truth explicit in `claw doctor` and `claw --help`, naming `ultraworkers/claw-code` as the canonical repo and warning that `cargo install claw-code` installs a deprecated stub rather than the `claw` binary. Regression coverage locks both the new doctor JSON check and the help-text warning. **Original filing below.** | `ROADMAP.md:L1302` / `roadmap_action` | `alpha_blocker` | `stale_done` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | Marked done in roadmap but needs freshness re-verification before being used as release evidence. | | `CC2-RM-A0114-wrong-task-prompt-receipt-is-not-detecte` | **Wrong-task prompt receipt is not detected before execution** — **done (verified 2026-04-12):** worker boot prompt dispatch now accepts an optional structured `task_receipt` (`repo`, `task_kind`, `source_surface`, `expected_artifacts`, `objective_preview`) and treats mismatched visible prompt context as a `WrongTask` prompt-delivery failure before execution continues. The prompt-delivery payload now records `observed_prompt_preview` plus the expected receipt, and regression coverage locks both the existing shell/wrong-target paths and the new KakaoTalk-style wrong-task mismatch case. **Original filing below.** | `ROADMAP.md:L1304` / `roadmap_action` | `alpha_blocker` | `stale_done` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | Marked done in roadmap but needs freshness re-verification before being used as release evidence. | | `CC2-RM-A0115-latest-managed-session-selection-depends` | **`latest` managed-session selection depends on filesystem mtime before semantic session recency** — **done (verified 2026-04-12):** managed-session summaries now carry `updated_at_ms`, `SessionStore::list_sessions()` sorts by semantic recency before filesystem mtime, and regression coverage locks the case where `latest` must prefer the newer session payload even when file mtimes point the other way. The CLI session-summary wrapper now stays in sync with the runtime field so `latest` resolution uses the same ordering signal everywhere. **Original filing below.** | `ROADMAP.md:L1306` / `roadmap_action` | `beta_adoption` | `stale_done` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | Marked done in roadmap but needs freshness re-verification before being used as release evidence. | | `CC2-RM-A0116-session-timestamps-are-not-monotonic-eno` | **Session timestamps are not monotonic enough for latest-session ordering under tight loops** — **done (verified 2026-04-12):** runtime session timestamps now use a process-local monotonic millisecond source, so back-to-back saves still produce increasing `updated_at_ms` even when the wall clock does not advance. The temporary sleep hack was removed from the resume-latest regression, and fresh workspace verification stayed green with the semantic-recency ordering path from #72. **Original filing below.** | `ROADMAP.md:L1307` / `roadmap_action` | `beta_adoption` | `stale_done` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | Marked done in roadmap but needs freshness re-verification before being used as release evidence. | | `CC2-RM-A0117-poisoned-test-locks-cascade-into-unrelat` | **Poisoned test locks cascade into unrelated Rust regressions** — **done (verified 2026-04-12):** test-only env/cwd lock acquisition in `rust/crates/tools/src/lib.rs`, `rust/crates/plugins/src/lib.rs`, `rust/crates/commands/src/lib.rs`, and `rust/crates/rusty-claude-cli/src/main.rs` now recovers poisoned mutexes via `PoisonError::into_inner`, and new regressions lock that behavior so one panic no longer causes later tests to fail just by touching the shared env/cwd locks. Source: Jobdori dogfood 2026-04-12. | `ROADMAP.md:L1309` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0118-claw-init-leaves-clawhip-runtime-artifac` | **`claw init` leaves `.clawhip/` runtime artifacts unignored** — **done (verified 2026-04-12):** `rust/crates/rusty-claude-cli/src/init.rs` now treats `.clawhip/` as a first-class local artifact alongside `.claw/` paths, and regression coverage locks both the create and idempotent update paths so `claw init` adds the ignore entry exactly once. The repo `.gitignore` now also ignores `.clawhip/` for immediate dogfood relief, preventing repeated OMX team merge conflicts on `.clawhip/state/prompt-submit.json`. Source: Jobdori dogfood 2026-04-12. | `ROADMAP.md:L1311` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0119-real-acp-zed-daemon-contract-is-still-mi` | **Real ACP/Zed daemon contract is still missing after the discoverability fix** — follow-up filed 2026-04-16. ROADMAP #64 made the current status explicit via `claw acp`, but editor-first users still cannot actually launch claw-code as an ACP/Zed daemon because there is no protocol-serving surface yet. **Fix shape:** add a real ACP entrypoint (for example `claw acp serve`) only when the underlying protocol/transport contract exists, then document the concrete editor wiring in `claw --help` and first-screen docs. **Acceptance bar:** an editor can launch claw-code for ACP/Zed from a documented, supported command rather than a status-only alias. **Blocker:** protocol/runtime work not yet implemented; current `acp serve` spelling is intentionally guidance-only. | `ROADMAP.md:L1313` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage`, `stable_alpha_contracts` | — | | `CC2-RM-A0120-output-format-json-error-payload-carries` | **`--output-format json` error payload carries no machine-readable error class, so downstream claws cannot route failures without regex-scraping the prose** — dogfooded 2026-04-17 in `/tmp/claw-dogfood-*` on main HEAD `00d0eb6`. ROADMAP #42/#49/#56/#57 made stdout/stderr JSON-shaped on error, but the shape itself is still lossy: every failure emits the exact same three-field envelope `{"type":"error","error":""}`. Concrete repros on the same binary, same JSON flag: | `ROADMAP.md:L1315` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0121-claw-plugins-cli-route-is-wired-as-a-cli` | **`claw plugins` CLI route is wired as a `CliAction` variant but never constructed by `parse_args`; invocation falls through to LLM-prompt dispatch** — dogfooded 2026-04-17 on main HEAD `d05c868`. `claw agents`, `claw mcp`, `claw skills`, `claw acp`, `claw bootstrap-plan`, `claw system-prompt`, `claw init`, `claw dump-manifests`, and `claw export` all resolve to local CLI routes and emit structured JSON (`{"kind": "agents", ...}` / `{"kind": "mcp", ...}` / etc.) without provider credentials. `claw plugins` does not — it is the sole documented-shaped subcommand that falls through to the `_other => CliAction::Prompt { ... }` arm in `parse_args`. Concrete repros on a clean workspace (`/tmp/claw-dogfood-2`, throwaway git init): | `ROADMAP.md:L1337` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage`, `stable_alpha_contracts` | — | | `CC2-RM-A0122-claw-output-format-json-init-discards-an` | **`claw --output-format json init` discards an already-structured `InitReport` and ships only the rendered prose as `message`** — dogfooded 2026-04-17 on main HEAD `9deaa29`. The init pipeline in `rust/crates/rusty-claude-cli/src/init.rs:38-113` already produces a fully-typed `InitReport { project_root: PathBuf, artifacts: Vec }` where `InitStatus` is the enum `{ Created, Updated, Skipped }` (line 15-20). `run_init()` at `rust/crates/rusty-claude-cli/src/main.rs:5436-5446` then funnels that structured report through `init_claude_md()` which calls `.render()` and throws away the structure, and `init_json_value()` at 5448-5454 wraps *only* the prose string into `{"kind":"init","message":"/` where `workspace_fingerprint()` at line 295-303 is a 16-char FNV-1a hex hash of the absolute CWD path. The gap is user-visible and trivially reproducible. | `ROADMAP.md:L1419` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0124-claw-status-reports-the-same-project-roo` | **`claw status` reports the same `Project root` for two CWDs that silently land in *different* session partitions — project-root identity is a lie at the session layer** — dogfooded 2026-04-17 on main HEAD `a48575f` inside `~/clawd/claw-code` (itself) and reproduced on a scratch repo at `/tmp/claw-split-17`. The `Workspace` block in `claw status` advertises a single `Project root` derived from the git toplevel, but `SessionStore::from_cwd` at `rust/crates/runtime/src/session_control.rs:32-40` uses the raw **CWD path** as input to `workspace_fingerprint()` (line 295-303), not the project root. The result: two invocations in the same git repo but different CWDs (`~/clawd/claw-code` vs `~/clawd/claw-code/rust`, or `/tmp/claw-split-17` vs `/tmp/claw-split-17/sub`) report the same `Project root` in `claw status` but land in two separate `.claw/sessions//` dirs that cannot see each other's sessions. `claw --resume latest` from one subdir returns `no managed sessions found` even though the adjacent CWD in the same project has a live session that `/session list` from that CWD resolves fine. | `ROADMAP.md:L1453` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0125-claw-sandbox-advertises-filesystem-activ` | **`claw sandbox` advertises `filesystem_active=true, filesystem_mode=workspace-only` on macOS but the "isolation" is just `HOME`/`TMPDIR` env-var rebasing — subprocesses can still write anywhere on disk** — dogfooded 2026-04-17 on main HEAD `1743e60` against `/tmp/claw-dogfood-2`. `claw --output-format json sandbox` on macOS reports `{"supported":false, "active":false, "filesystem_active":true, "filesystem_mode":"workspace-only", "fallback_reason":"namespace isolation unavailable (requires Linux with `unshare`)"}`. The `fallback_reason` correctly admits namespace isolation is off, but `filesystem_active=true` + `filesystem_mode="workspace-only"` reads — to a claw or a human — as *"filesystem isolation is live, restricted to the workspace."* It is not. | `ROADMAP.md:L1480` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0126-claw-injects-the-build-date-into-the-liv` | **`claw` injects the *build date* into the live agent system prompt as "today's date" — agents run one week (or any N days) behind real time whenever the binary has aged** — dogfooded 2026-04-17 on main HEAD `e58c194` against `/tmp/cd3`. The binary was built on 2026-04-10 (`claw --version` → `Build date 2026-04-10`). Today is 2026-04-17. Running `claw system-prompt` from a fresh workspace yields: | `ROADMAP.md:L1519` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0127-compute-current-date-at-runtime-not-comp` | Compute `current_date` at runtime, not compile time. Add a small helper in `runtime::prompt` (or a new `clock.rs`) that returns today's UTC date as `YYYY-MM-DD`, using `chrono::Utc::now().date_naive()` or equivalent. No new heavy dependency — `chrono` is already transitively in the tree. ~10 lines. | `ROADMAP.md:L1539` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0128-replace-every-default-date-use-site-in-r` | Replace every `DEFAULT_DATE` use site in `rusty-claude-cli/src/main.rs` (call sites enumerated above) with a call to that helper. Leave `DEFAULT_DATE` intact *only* for the `claw version` / `--version` build-metadata path (its honest meaning). | `ROADMAP.md:L1540` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0129-preserve-date-yyyy-mm-dd-override-on-sys` | Preserve `--date YYYY-MM-DD` override on `system-prompt` as-is; add an env-var escape hatch (`CLAWD_OVERRIDE_DATE=YYYY-MM-DD`) for deterministic tests and SOURCE_DATE_EPOCH-style reproducible agent prompts. | `ROADMAP.md:L1541` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0130-regression-test-freeze-the-clock-via-the` | Regression test: freeze the clock via the env escape, assert `load_system_prompt(cwd, , ...)` emits the *frozen* date, not the build date. Also a smoke test that the *actual* runtime default rejects any value matching `option_env!("BUILD_DATE")` unless the env override is set. | `ROADMAP.md:L1542` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0131-claw-dump-manifests-default-search-path` | **`claw dump-manifests` default search path is the build machine's absolute filesystem path baked in at compile time — broken and information-leaking for any user running a distributed binary** — dogfooded 2026-04-17 on main HEAD `70a0f0c` from `/tmp/cd4` (fresh workspace). Running `claw dump-manifests` with no arguments emits: | `ROADMAP.md:L1550` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0132-broken-default-for-any-distributed-binar` | *Broken default for any distributed binary.* A claw or operator running a packaged/shipped `claw` binary on their own machine will see a path they do not own, cannot create, and cannot reason about. The error surface advertises a default behavior that is contingent on the end user having reconstructed the build machine's filesystem layout verbatim. | `ROADMAP.md:L1567` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0133-privacy-leak-the-build-machine-s-absolut` | *Privacy leak.* The build machine's absolute filesystem path — including the compiling user's `$HOME` segment (`/Users/yeongyu`) — is baked into the binary and surfaced to every recipient who ever runs `dump-manifests` without `--manifests-dir`. This lands in logs, CI output, transcripts, bug reports, the binary itself. For a tool that aspires to be embedded in clawhip / batch orchestrators this is a sharp edge. | `ROADMAP.md:L1568` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0134-reproducibility-violation-two-binaries-b` | *Reproducibility violation.* Two binaries built from the same source at the same commit but on different machines produce different runtime behavior for the *default* `dump-manifests` invocation. This is the same reproducibility-breaking shape as ROADMAP #83 (build date injected as "today") — compile-time context leaking into runtime decisions. | `ROADMAP.md:L1569` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0135-discovery-gap-the-hint-correctly-names-c` | *Discovery gap.* The hint correctly names `CLAUDE_CODE_UPSTREAM` and `--manifests-dir`, but the user only learns about them *after* the default has already failed in a confusing way. A clawhip running this probe to detect whether an upstream manifest source is available cannot distinguish "user hasn't configured an upstream path yet" from "user's config is wrong" from "the binary was built on a different machine" — same error in all three cases. | `ROADMAP.md:L1570` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0136-drop-the-compile-time-default-remove-env` | *Drop the compile-time default.* Remove `env!("CARGO_MANIFEST_DIR")` from the runtime default path in `main.rs:2016`. Replace with either (a) `env::current_dir()` as the starting point for `resolve_upstream_repo_root`, or (b) a hardcoded `None` that requires `CLAUDE_CODE_UPSTREAM` / `--manifests-dir` / a settings-file entry before any lookup happens. | `ROADMAP.md:L1573` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0137-when-the-default-is-missing-fail-with-a` | *When the default is missing, fail with a user-legible message — not a leaked absolute path.* Example: `dump-manifests requires an upstream Claude Code source checkout. Set CLAUDE_CODE_UPSTREAM or pass --manifests-dir /path/to/claude-code. No default path is configured for this binary.` No compile-time path, no `$HOME` leak, no confusing "missing files" message for a path the user never asked for. | `ROADMAP.md:L1574` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0138-add-a-claw-config-upstream-settings-json` | *Add a `claw config upstream` / `settings.json` `[upstream]` entry* so the upstream source path is a first-class, persisted piece of workspace config — not an env var or a command-line flag the user has to remember each time. Matches the settings-based approach used elsewhere (e.g. the `trusted_roots` gap called out in the 2026-04-08 startup-friction note). | `ROADMAP.md:L1575` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0139-claw-skills-walks-cwd-ancestors-unbounde` | **`claw skills` walks `cwd.ancestors()` unbounded and treats every `.claw/skills`, `.omc/skills`, `.agents/skills`, `.codex/skills`, `.claude/skills` it finds as active project skills — cross-project leakage and a cheap skill-injection path from any ancestor directory** — dogfooded 2026-04-17 on main HEAD `2eb6e0c` from `/tmp/trap/inner/work`. A directory I do not own (`/tmp/trap/.agents/skills/rogue/SKILL.md`) above the worker's CWD is enumerated as an `active: true` skill by `claw --output-format json skills`, sourced as `project_claw`/`Project roots`, even after the worker's own CWD is `git init`ed to declare a project boundary. Same effect from any ancestor walk up to `/`. | `ROADMAP.md:L1583` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0140-cross-tenant-skill-injection-from-a-shar` | *Cross-tenant skill injection from a shared `/tmp` ancestor.* | `ROADMAP.md:L1586` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0141-cwd-dependent-skill-set-from-users-yeong` | *CWD-dependent skill set.* From `/Users/yeongyu/scratch-nonrepo` (CWD under `$HOME`) `claw --output-format json skills` returns 50 skills — including every `SKILL.md` under `~/.agents/skills/*`, surfaced via `ancestor.join(".agents").join("skills")` at `rust/crates/commands/src/lib.rs:2811`. From `/tmp/cd5` (same user, same binary, CWD *outside* `$HOME`) the same command returns 24 — missing the entire `~/.agents/skills/*` set because `~` is no longer in the ancestor chain. Skill availability silently flips based on where the worker happened to be started from. | `ROADMAP.md:L1602` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0142-non-deterministic-skill-surface-two-claw` | *Non-deterministic skill surface.* Two claws started from `/tmp/worker-A/` and `/Users/yeongyu/worker-B/` on the same machine see different skill sets. Principle #1 ("deterministic to start") is violated on a per-CWD basis. | `ROADMAP.md:L1611` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0143-cross-project-leakage-a-parent-repo-s-ag` | *Cross-project leakage.* A parent repo's `.agents/skills` silently bleeds into a nested sub-checkout's skill namespace. Nested worktrees, monorepo subtrees, and temporary orchestrator workspaces all inherit ancestor skills they may not own. | `ROADMAP.md:L1612` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0144-skill-injection-primitive-any-directory` | *Skill-injection primitive.* Any directory writable to the attacker on an ancestor path of the worker's CWD (shared `/tmp`, a nested CI mount, a dropbox/iCloud folder, a multi-tenant build agent, a git submodule whose parent repo is attacker-influenced) can drop a `.agents/skills//SKILL.md` and have it surface as an `active: true` skill with full dispatch via `claw`'s slash-command path. Skill descriptions are free-form Markdown fed into the agent's context; a crafted `description:` becomes a prompt-injection payload the agent willingly reads before it realizes which file it's reading. | `ROADMAP.md:L1613` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0145-asymmetric-with-agents-discovery-project` | *Asymmetric with agents discovery.* Project agents (`/agents` surface) have explicit project-scoping via `ConfigLoader`; skills discovery does not. The two diverge on which context is considered "project." | `ROADMAP.md:L1614` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0146-terminate-the-ancestor-walk-at-the-proje` | *Terminate the ancestor walk at the project root.* Plumb `ConfigLoader::project_root()` (or git-toplevel) into `discover_skill_roots` and stop at that boundary. Skills above the project root are ignored — they must be installed explicitly (via `claw skills install` or a settings entry). | `ROADMAP.md:L1617` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0147-optionally-also-terminate-at-home-if-the` | *Optionally also terminate at `$HOME`.* If the project root can't be resolved, stop at `$HOME` so a worker in `/Users/me/foo` never reads from `/Users/`, `/`, `/private`, etc. | `ROADMAP.md:L1618` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0148-require-acknowledgment-for-cross-project` | *Require acknowledgment for cross-project skills.* If an ancestor skill is inherited (intentional monorepo case), require an explicit `allow_ancestor_skills` toggle in `settings.json` and emit an event when ancestor-sourced skills are loaded. Matches the intent of ROADMAP principle #5 ("partial success / degraded mode is first-class") — surface the fact that skills are coming from outside the canonical project root. | `ROADMAP.md:L1619` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0149-mirror-the-same-fix-in-rust-crates-tools` | *Mirror the same fix in `rust/crates/tools/src/lib.rs::push_project_skill_lookup_roots`* so the *executable* skill surface matches the *listed* skill surface. Today they share the same ancestor-walk bug, so the fix must apply to both. | `ROADMAP.md:L1620` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0150-regression-tests-a-worker-in-tmp-attacke` | *Regression tests:* (a) worker in `/tmp/attacker/.agents/skills/rogue` + inner CWD → `rogue` must not be surfaced; (b) worker in a user home subdir → `~/.agents/skills/*` must not leak unless explicitly allowed; (c) explicit monorepo case: `settings.json { "skills": { "allow_ancestor": true } }` → inherited skills reappear, annotated with their source path. | `ROADMAP.md:L1621` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0151-claw-json-with-invalid-json-is-silently` | **`.claw.json` with invalid JSON is silently discarded and `claw doctor` still reports `Config: ok — runtime config loaded successfully`** — dogfooded 2026-04-17 on main HEAD `586a92b` against `/tmp/cd7`. A user's own legacy config file is parsed, fails, gets dropped on the floor, and every diagnostic surface claims success. Permissions revert to defaults, MCP servers go missing, provider fallbacks stop applying — without a single signal that the operator's config never made it into `RuntimeConfig`. | `ROADMAP.md:L1629` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0152-the-user-s-current-claw-json-is-now-indi` | The user's *current* `.claw.json` is now indistinguishable from a historical stale `.claw.json` — any typo silently wipes out their permissions/MCP/aliases config on the next invocation. | `ROADMAP.md:L1655` / `roadmap_action` | `beta_adoption` | `stale_done` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | Marked done in roadmap but needs freshness re-verification before being used as release evidence. | | `CC2-RM-A0153-no-signal-is-emitted-a-claw-reading-claw` | No signal is emitted. A claw reading `claw --output-format json doctor` sees `config ok`, reports "config is fine," and proceeds to run with wrong permissions/missing MCP. This is exactly the "surface lies about runtime truth" shape from the #80–#84 cluster, at the config layer. | `ROADMAP.md:L1656` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0154-replace-the-silent-skip-with-a-loud-warn` | *Replace the silent skip with a loud warn-and-skip.* In `read_optional_json_object` at `config.rs:690` and `:695`, instead of `return Ok(None)` on parse failure for `.claw.json`, return `Ok(Some(ParsedConfigFile::empty_with_warning(…)))` (or similar) with the parse error captured as a structured warning. Plumb that warning into `ConfigLoader::load()` alongside the existing `all_warnings` collection so it surfaces on stderr and in `doctor`'s detail block. | `ROADMAP.md:L1661` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0155-flip-the-doctor-verdict-when-loaded-coun` | *Flip the doctor verdict when `loaded_count < present_count`.* In `rusty-claude-cli/src/main.rs:1747-1755`, when `present_count > 0 && loaded_count < present_count`, emit `DiagnosticLevel::Warn` (or `Fail` when *all* discovered files fail to load) with a summary like `"loaded N/{present_count} config files; {present_count - N} skipped due to parse errors"`. Add a structured field `skipped_files` / `skip_reasons` to the JSON surface so clawhip can branch on it. | `ROADMAP.md:L1662` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0156-regression-tests-a-corrupt-claw-json-doc` | *Regression tests:* (a) corrupt `.claw.json` → `doctor` emits `warn` with a skipped-files detail; (b) corrupt `.claw.json` → `status` shows a `config_skipped: 1` marker; (c) `loaded_entries.len()` equals zero while `discover()` returns one → never `DiagnosticLevel::Ok`. | `ROADMAP.md:L1663` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0157-fresh-workspace-default-permission-mode` | **Fresh workspace default `permission_mode` is `danger-full-access` with zero warning in `claw doctor` and no auditable trail of how the mode was chosen — every unconfigured claw spawn runs fully unattended at maximum permission** — dogfooded 2026-04-17 on main HEAD `d6003be` against `/tmp/cd8`. A fresh workspace with no `.claw.json`, no `RUSTY_CLAUDE_PERMISSION_MODE` env var, no `--permission-mode` flag produces: | `ROADMAP.md:L1671` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0158-no-preflight-signal-roadmap-section-3-5` | *No preflight signal.* ROADMAP section 3.5 ("Boot preflight / doctor contract") explicitly requires machine-readable preflight to surface state that determines whether a lane is safe to start. Permission mode is precisely that kind of state — a lane at `danger-full-access` has a larger blast radius than one at `workspace-write` — and `doctor` omits it entirely. | `ROADMAP.md:L1691` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0159-no-provenance-a-clawhip-orchestrator-spa` | *No provenance.* A clawhip orchestrator spawning 20 lanes has no way to distinguish "operator intentionally set `defaultMode: danger-full-access` in the shared config" from "config was missing or typo'd (see #86) and all 20 workers silently fell back to `danger-full-access`." The two outcomes are observably identical at the status layer. | `ROADMAP.md:L1692` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0160-least-privilege-inversion-for-an-interac` | *Least-privilege inversion.* For an `interactive` harness a permissive default is defensible; for a *batch claw harness* it inverts the normal least-privilege principle. A worker should have to *opt in* to full access, not have it handed to them when config is missing. | `ROADMAP.md:L1693` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0161-interacts-badly-with-86-a-corrupted-claw` | *Interacts badly with #86.* A corrupted `.claw.json` that specifies `permissions.defaultMode: "plan"` is silently dropped, and the fallback reverts to `danger-full-access` with `doctor` reporting `Config: ok`. So the same typo path that wipes a user's permission choice also escalates them to maximum permission, and nothing in the diagnostic surface says so. | `ROADMAP.md:L1694` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0162-add-a-permission-or-permissions-doctor-c` | *Add a `permission` (or `permissions`) doctor check.* Mirror `check_sandbox_health`'s shape: emit `DiagnosticLevel::Warn` when the effective mode is `DangerFullAccess` *and* the mode was chosen by fallback (not by explicit env / config / CLI flag). Emit `DiagnosticLevel::Ok` otherwise. Detail lines should include the effective mode, the source (`fallback` / `env:RUSTY_CLAUDE_PERMISSION_MODE` / `config:.claw.json` / `cli:--permission-mode`), and the set of tools whose `required_permission` the current mode satisfies. | `ROADMAP.md:L1697` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0163-surface-permission-mode-source-in-status` | *Surface `permission_mode_source` in `status` JSON.* Alongside the existing `permission_mode` field, add `permission_mode_source: "fallback" \| "env" \| "config" \| "cli"`. `fn default_permission_mode` becomes `fn resolve_permission_mode() -> (PermissionMode, PermissionModeSource)`. No behavior change; just provenance a claw can audit. | `ROADMAP.md:L1698` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0164-consider-flipping-the-fallback-default-f` | *Consider flipping the fallback default.* For the subset of invocations that are clearly non-interactive (`--output-format json`, `--resume`, piped stdin) make the fallback `WorkspaceWrite` or `Prompt`, and require an explicit flag / config / env var to escalate to `DangerFullAccess`. Keep `DangerFullAccess` as the interactive-REPL default if that is the intended philosophy, but *announce* it via the new doctor check so a claw can branch on it. This third piece is a judgment call and can ship separately from pieces 1+2. | `ROADMAP.md:L1699` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0165-discover-instruction-files-walks-cwd-anc` | **`discover_instruction_files` walks `cwd.ancestors()` unbounded and loads every `CLAUDE.md` / `CLAUDE.local.md` / `.claw/CLAUDE.md` / `.claw/instructions.md` it finds into the *system prompt* as trusted "Claude instructions" — direct prompt injection from any ancestor directory, including world-writable `/tmp`** — dogfooded 2026-04-17 on main HEAD `82bd8bb` from `/tmp/claude-md-injection/inner/work`. An attacker-controlled `CLAUDE.md` one directory above the worker is read verbatim into the agent's system prompt under the `# Claude instructions` section. | `ROADMAP.md:L1707` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0166-system-prompt-not-tool-surface-85-s-inje` | *System prompt, not tool surface.* #85's injection primitive placed a crafted skill on disk and required the agent to invoke it (via `/rogue` slash-command or equivalent). #88 places crafted *text* into the system prompt verbatim, with no agent action required — the injection fires on every turn, before the user even sends their first message. | `ROADMAP.md:L1745` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0167-lower-bar-for-the-attacker-a-claude-md-i` | *Lower bar for the attacker.* A `CLAUDE.md` is raw Markdown with no frontmatter; it doesn't even need a YAML header; it doesn't need a subdirectory structure. `/tmp/CLAUDE.md` alone is sufficient. | `ROADMAP.md:L1746` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0168-world-writable-drop-point-is-standard-tm` | *World-writable drop point is standard.* `/tmp` is writable by every local user on the default macOS / Linux configuration. A malicious local user (or a runaway build artifact, or a `curl \| sh` installer that dropped `/tmp/CLAUDE.md` by accident) sets up the injection for every `claw` invocation under `/tmp/anything` until someone notices. | `ROADMAP.md:L1747` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0169-no-visible-signal-in-claw-doctor-claw-sy` | *No visible signal in `claw doctor`.* `claw system-prompt` exposes the loaded files if the operator happens to run it, but `claw doctor` / `claw status` / `claw --output-format json doctor` say nothing about how many instruction files were loaded or where they came from. The `workspace` check reports `memory_files: N` as a count, but not the paths. An orchestrator preflighting lanes cannot tell "this lane will ingest `/tmp/CLAUDE.md` as authoritative agent guidance." | `ROADMAP.md:L1748` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0170-same-structural-bug-family-as-85-same-st` | *Same structural bug family as #85, same structural fix.* Both `discover_skill_roots` (`commands/src/lib.rs:2795`) and `discover_instruction_files` (`prompt.rs:203`) are unbounded `cwd.ancestors()` walks. `discover_definition_roots` for agents (`commands/src/lib.rs:2724`) is the third sibling. All three need the same project-root / `$HOME` bound with an explicit opt-in for monorepo inheritance. | `ROADMAP.md:L1749` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0171-terminate-the-ancestor-walk-at-the-proje` | *Terminate the ancestor walk at the project root.* Plumb `ConfigLoader::project_root()` (git toplevel, or the nearest ancestor containing `.claw.json` / `.claw/`) into `discover_instruction_files` and stop at that boundary. Ancestor instruction files above the project root are ignored unless an explicit opt-in is set. | `ROADMAP.md:L1752` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0172-fallback-bound-at-home-if-the-project-ro` | *Fallback bound at `$HOME`.* If the project root cannot be resolved, stop at `$HOME` so a worker under `/Users/me/foo` never reads from `/Users/`, `/`, `/private`, etc. | `ROADMAP.md:L1753` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0173-surface-loaded-instruction-files-in-doct` | *Surface loaded instruction files in `doctor`.* Add a `memory` / `instructions` check that emits the resolved path list + per-file byte count. A clawhip preflight can then gate on "unexpected instruction files above the project root." | `ROADMAP.md:L1754` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0174-require-opt-in-for-cross-project-inherit` | *Require opt-in for cross-project inheritance.* `settings.json { "instructions": { "allow_ancestor": true } }` to preserve the legitimate monorepo use case where a parent `CLAUDE.md` should apply to nested checkouts. Annotate ancestor-sourced files with `source: "ancestor"` in the doctor/status JSON so orchestrators see the inheritance explicitly. | `ROADMAP.md:L1755` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0175-regression-tests-a-worker-under-tmp-atta` | *Regression tests:* (a) worker under `/tmp/attacker/CLAUDE.md` → `/tmp/attacker/CLAUDE.md` must not appear in the system prompt; (b) worker under `$HOME/scratch` with `~/CLAUDE.md` present → home-level `CLAUDE.md` must not leak unless `allow_ancestor` is set; (c) legitimate repo layout (`/project/CLAUDE.md` with worker at `/project/sub/worker`) → still works; (d) explicit opt-in case → ancestor file appears with `source: "ancestor"` in status JSON. | `ROADMAP.md:L1756` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0176-claw-is-blind-to-mid-operation-git-state` | **`claw` is blind to mid-operation git states (rebase-in-progress, merge-in-progress, cherry-pick-in-progress, bisect-in-progress) — `doctor` returns `Workspace: ok` on a workspace that is literally paused on a conflict** — dogfooded 2026-04-17 on main HEAD `9882f07` from `/tmp/git-state-probe`. A branch rebase that halted on a conflict leaves the workspace in the `rebase-merge` state with conflict files in the index and `HEAD` detached on the rebase's intermediate commit. `claw`'s workspace surface reports this as a plain dirty workspace on "branch detached HEAD," with no signal that the lane is mid-operation and cannot safely accept new work. | `ROADMAP.md:L1764` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0177-preflight-blindness-a-clawhip-orchestrat` | *Preflight blindness.* A clawhip orchestrator that runs `claw doctor` before spawning a lane gets `workspace: ok` on a workspace whose next `git commit` will corrupt rebase metadata, whose `HEAD` moves on `git rebase --continue`, and whose test suite is currently running against an intermediate tree that does not correspond to any real branch tip. | `ROADMAP.md:L1788` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0178-stale-branch-detection-breaks-the-princi` | *Stale-branch detection breaks.* The principle-4 test ("is this branch up to date with base?") is meaningless when `HEAD` is pointing at a rebase's intermediate commit. A claw that runs `git log base..HEAD` against a rebase-in-progress `HEAD` gets noise, not a freshness verdict. | `ROADMAP.md:L1789` / `roadmap_action` | `beta_adoption` | `stale_done` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | Marked done in roadmap but needs freshness re-verification before being used as release evidence. | | `CC2-RM-A0179-no-recovery-surface-even-when-a-claw-som` | *No recovery surface.* Even when a claw somehow detects the bad state from another source, it has nothing in `claw`'s own machine-readable output to anchor its recovery: no `operation.kind = "rebase"`, no `operation.abort_hint = "git rebase --abort"`, no `operation.resume_hint = "git rebase --continue"`. Recovery becomes text-scraping terminal output — exactly the shape ROADMAP principle #6 ("Terminal is transport, not truth") argues against. | `ROADMAP.md:L1790` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0180-same-surface-lies-about-runtime-truth-fa` | *Same "surface lies about runtime truth" family as #80–#87.* The workspace doctor check asserts `ok` for a state that is anything but. Operator reads the doctor output, believes the workspace is healthy, launches a worker, corrupts the rebase. | `ROADMAP.md:L1791` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0181-detect-in-progress-git-operations-in-par` | *Detect in-progress git operations.* In `parse_git_workspace_summary` (or a sibling `detect_git_operation`), check for marker files: `.git/rebase-merge/`, `.git/rebase-apply/`, `.git/MERGE_HEAD`, `.git/CHERRY_PICK_HEAD`, `.git/BISECT_LOG`, `.git/REVERT_HEAD`. Map each to a typed `GitOperation::{ Rebase, Merge, CherryPick, Bisect, Revert }` enum variant. ~20 lines including tests. | `ROADMAP.md:L1794` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0182-expose-the-operation-in-status-and-docto` | *Expose the operation in `status` and `doctor` JSON.* Add `workspace.git_operation: null \| { kind: "rebase"\|"merge"\|"cherry_pick"\|"bisect"\|"revert", paused: bool, abort_hint: string, resume_hint: string }` to the workspace block. When `git_operation != null`, `check_workspace_health` emits `DiagnosticLevel::Warn` (not `Ok`) with a summary like `"rebase in progress; lane is not safe to accept new work"`. | `ROADMAP.md:L1795` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0183-preserve-the-existing-counts-changed-fil` | *Preserve the existing counts*. `changed_files` / `conflicted_files` / `staged_files` stay where they are; the new `git_operation` field is additive so existing consumers don't break. | `ROADMAP.md:L1796` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0184-claw-mcp-json-text-surface-redacts-mcp-s` | **`claw mcp` JSON/text surface redacts MCP server `env` values but dumps `args`, `url`, and `headersHelper` verbatim — standard secret-carrying fields leak to every consumer of the machine-readable MCP surface** — dogfooded 2026-04-17 on main HEAD `64b29f1` from `/tmp/cdB`. The MCP details surface deliberately redacts `env` to `env_keys` (only key names, not values) and `headers` to `header_keys` — a correct design choice. The same surface then dumps `args`, the `url`, and `headersHelper` unredacted, even though all three routinely carry inline credentials. | `ROADMAP.md:L1804` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0185-machine-readable-surface-consumed-by-aut` | *Machine-readable surface consumed by automation.* `mcp list --output-format json` is the surface clawhip / orchestrators are designed to scrape for preflight and lane setup. Any consumer that logs the JSON (Discord announcement, CI artifact, debug log, session transcript export — see `claw export` — bug tracker attachment) now carries the MCP server's secret material in plain text. | `ROADMAP.md:L1856` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0186-asymmetric-redaction-sends-the-wrong-sig` | *Asymmetric redaction sends the wrong signal.* Because `env_keys` and `header_keys` are correctly redacted, a consumer reasonably assumes the surface is "secret-aware" across the board. The `args` / `url` / `headers_helper` leak is therefore *unexpected*, not loudly documented as caveat, and easy to miss during review. | `ROADMAP.md:L1857` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0187-standard-patterns-are-hit-every-one-of-t` | *Standard patterns are hit.* Every one of the examples above is a **standard** way of wiring MCP servers: `--api-key`, `--token=...`, `postgres://user:pass@host/db`, `--url=https://@host/...`, helper scripts that take credentials as args. The MCP docs and most community server configs look exactly like this. The leak isn't a weird edge case; it's the common case. | `ROADMAP.md:L1858` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0188-no-mcp-secret-leak-risk-preflight-claw-d` | *No `mcp.secret_leak_risk` preflight.* `claw doctor` says nothing about whether an MCP server's args or URL look like they contain high-entropy secret material. Even a primitive `token=` / `api[-_]key` / `password=` / `https?://[^/:]+:[^@]+@` regex sweep would raise a `warn` in exactly these cases. | `ROADMAP.md:L1859` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0189-redact-args-to-args-summary-shape-preser` | *Redact args to `args_summary` (shape-preserving) + `args_len` (count).* Replace `args: &config.args` with `args_summary` that records the count, which flags look like they carry secrets (heuristic: `--api-key`, `--token`, `--password`, `--auth`, `--secret`, `=` containing high-entropy tail, inline `user:pass@`), and emits redacted placeholders like `"--api-key="`. A `--show-sensitive` flag on `claw mcp show` can opt back into full args when the operator explicitly wants them. | `ROADMAP.md:L1862` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0190-redact-url-basic-auth-for-any-url-that-c` | *Redact URL basic-auth.* For any URL that contains `user:pass@`, emit the URL with the password segment replaced by `` and add `url_has_credentials: true` so consumers can branch on it. Query-string secrets (`?api_key=...`, `?token=...`) get the same redaction heuristic as args. | `ROADMAP.md:L1863` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0191-redact-headershelper-argv-split-on-white` | *Redact `headersHelper` argv.* Split on whitespace, keep `argv[0]` (the command path), apply the args heuristic from piece 1 to the rest. | `ROADMAP.md:L1864` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0192-optional-add-a-mcp-secret-posture-doctor` | *Optional: add a `mcp_secret_posture` doctor check.* Emit `warn` when any configured MCP server has args/URL/helper matching the secret heuristic and no opt-in has been granted. Actionable: "move the secret to `env`, reference it via `${ENV_VAR}` interpolation, or explicitly `allow_sensitive_in_args` in settings." | `ROADMAP.md:L1865` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0193-config-accepts-5-undocumented-permission` | **Config accepts 5 undocumented permission-mode aliases (`default`, `plan`, `acceptEdits`, `auto`, `dontAsk`) that silently collapse onto 3 canonical modes — `--permission-mode` CLI flag rejects all 5 — and `"dontAsk"` in particular sounds like "quiet mode" but maps to `danger-full-access`** — dogfooded 2026-04-18 on main HEAD `478ba55` from `/tmp/cdC`. Two independent permission-mode parsers disagree on which labels are valid, and the config-side parser collapses the semantic space silently. | `ROADMAP.md:L1873` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0194-surface-to-surface-disagreement-principl` | *Surface-to-surface disagreement.* Principle #2 ("Truth is split across layers") is violated: the same binary accepts a label in one surface and rejects it in another. An orchestrator that attempts to mirror a lane's config into a child lane via `--permission-mode` cannot round-trip through its own `permissions.defaultMode` if the original uses an alias. | `ROADMAP.md:L1910` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0195-dontask-is-a-footgun-the-most-permissive` | *`"dontAsk"` is a footgun.* The most permissive mode has the friendliest-sounding alias. No security copy-review step will flag `"dontAsk"` as alarming; it reads like a noise preference. Clawhip / batch orchestrators that replay other operators' configs inherit the full-access escalation without a `danger` keyword ever appearing in the audit trail. | `ROADMAP.md:L1911` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0196-lossy-provenance-status-permission-mode` | *Lossy provenance.* `status.permission_mode` reports the collapsed canonical label. A claw that logs its own permission posture cannot reconstruct whether the operator wrote `"plan"` and expected plan-mode behavior, or wrote `"read-only"` intentionally. | `ROADMAP.md:L1912` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0197-plan-implies-runtime-semantics-that-don` | *`"plan"` implies runtime semantics that don't exist.* Writing `"defaultMode": "plan"` is a reasonable attempt to use plan-mode (see `ExitPlanMode` in `--allowedTools` enumeration, see REPL `/plan [on\|off]` slash command in `--help`). The config-time collapse to `ReadOnly` means the agent does *not* treat `ExitPlanMode` as a meaningful exit event; a claw relying on `ExitPlanMode` as a typed "agent proposes to execute" signal sees nothing, because the agent was never in plan mode to begin with. | `ROADMAP.md:L1913` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0198-align-the-two-parsers-either-a-drop-the` | *Align the two parsers.* Either (a) drop the non-canonical aliases from `parse_permission_mode_label`, or (b) extend `normalize_permission_mode` to accept the same set and emit them canonicalized via a shared helper. Whichever direction, the two surfaces must accept and reject identical strings. | `ROADMAP.md:L1916` / `roadmap_action` | `post_2_0_research` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage`, `stable_alpha_contracts` | — | | `CC2-RM-A0199-promote-provenance-in-status-add-permiss` | *Promote provenance in `status`.* Add `permission_mode_raw: "plan"` alongside `permission_mode: "read-only"` so a claw can see the original label. Pair with the existing `permission_mode_source` from #87 so provenance is complete. | `ROADMAP.md:L1917` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0200-kill-dontask-or-warn-on-it-either-a-remo` | *Kill `"dontAsk"` or warn on it.* Either (a) remove the alias entirely (forcing operators to spell `"danger-full-access"` when they mean it — the name should carry the risk), or (b) keep the alias but have `doctor` emit a `warn` check when `permission_mode_raw == "dontAsk"` that explicitly says "this alias maps to danger-full-access; spell it out to confirm intent." Option (a) is more honest; option (b) is less breaking. | `ROADMAP.md:L1918` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0201-decide-whether-plan-should-map-to-someth` | *Decide whether `"plan"` should map to something real.* Either (a) drop the alias and require operators to use `"read-only"` if that's what they want, or (b) introduce a real `PermissionMode::Plan` runtime variant with distinct semantics (e.g., deny all tools except `ExitPlanMode` and read-only tools) so `"plan"` means plan-mode. Orthogonal to pieces 1–3 and can ship independently. | `ROADMAP.md:L1919` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0202-mcp-command-args-and-url-config-fields-a` | **MCP `command`, `args`, and `url` config fields are passed to `execve`/URL-parse **verbatim** — no `${VAR}` interpolation, no `~/` home expansion, no preflight check, no doctor warning — so standard config patterns silently fail at MCP connect time with confusing "No such file or directory" errors** — dogfooded 2026-04-18 on main HEAD `d0de86e` from `/tmp/cdE`. Every MCP stdio configuration on the web uses `${VAR}` / `~/...` syntax for command paths and credentials; `claw` stores them literally and hands the literal strings to `Command::new` at spawn time. | `ROADMAP.md:L1927` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0203-silent-mismatch-with-ecosystem-conventio` | *Silent mismatch with ecosystem convention.* Every public MCP server README (`@modelcontextprotocol/server-filesystem`, `@modelcontextprotocol/server-github`, etc.) uses `${VAR}` / `~/` in example configs. Operators copy-paste those configs expecting standard shell-style interpolation. `claw` accepts the config, reports `doctor: ok`, and fails opaquely at spawn. The failure mode is far from the cause. | `ROADMAP.md:L1953` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0204-secret-placement-footgun-operators-who-k` | *Secret-placement footgun.* Operators who know the interpolation is missing are forced to either (a) hardcode secrets in `.claw.json` (which triggers the #90 redaction problem) or (b) write a wrapper shell script as the `command` and interpolate there. Both paths push them toward worse security postures than the ecosystem norm. | `ROADMAP.md:L1954` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0205-doctor-surface-is-silent-about-the-risk` | *Doctor surface is silent about the risk.* No check in `claw doctor` greps `command` / `args` / `url` / `headers` for literal `${`, `$`, `~/` and flags them. A clawhip preflight that gates on `doctor.status == "ok"` proceeds to spawn a lane whose MCP server will fail. | `ROADMAP.md:L1955` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0206-error-at-the-far-end-is-unhelpful-when-t` | *Error at the far end is unhelpful.* When the spawn does fail at MCP connect time, the error originates in `mcp_stdio.rs`'s `spawn()` returning an `io::Error` whose text is something like `"No such file or directory (os error 2)"`. The user-facing error path strips the command path, loses the "we passed `${HOME}/bin/my-server` to execve literally" context, and prints a generic `ENOENT` with no pointer back to the config source. | `ROADMAP.md:L1956` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0207-round-trip-from-upstream-configs-fails-r` | *Round-trip from upstream configs fails.* ROADMAP #88 (Claude Code parity) and the general "run existing MCP configs on claw" use case presume operators can copy Claude Code / other-harness `.mcp.json` files over. Literal-`${VAR}` behavior breaks that assumption for any config that uses interpolation — which is most of them. | `ROADMAP.md:L1957` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0208-add-interpolation-at-config-load-time-in` | *Add interpolation at config-load time.* In `parse_mcp_server_config` (or a shared `resolve_config_strings` helper in `runtime/src/config.rs`), expand `${VAR}` and `~/` in `command`, `args`, `url`, `headers`, `headers_helper`, `install_root`, `registry_path`, `bundled_root`, and similar string-path fields. Use a conservative substitution (only fully-formed `${VAR}` / leading `~/`; do not touch bare `$VAR`). Missing-variable policy: default to empty string with a `warning:` printed on stderr + captured into `ConfigLoader::all_warnings`, so a typo like `${APIP_KEY}` (missing `_`) is loud. Make the substitution optional via a `{"config": {"expand_env": false}}` settings toggle for operators who specifically want literal `$`/`~` in paths. | `ROADMAP.md:L1960` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0209-add-a-mcp-config-interpolation-doctor-ch` | *Add a `mcp_config_interpolation` doctor check.* When any MCP `command`/`args`/`url`/`headers`/`headers_helper` contains a literal `${`, bare `$VAR`, or leading `~/`, emit `DiagnosticLevel::Warn` naming the field and server. Lets a clawhip preflight distinguish "operator forgot to export the env var" from "operator's config is fundamentally wrong." Pairs cleanly with #90's `mcp_secret_posture` check. | `ROADMAP.md:L1961` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0210-resume-reference-semantics-silently-fork` | **`--resume ` semantics silently fork on a brittle "looks-like-a-path" heuristic — `session-X` goes to the managed store but `session-X.jsonl` opens a workspace-relative file, and any absolute path is opened verbatim with no workspace scoping** — dogfooded 2026-04-18 on main HEAD `bab66bb` from `/tmp/cdH`. The flag accepts the same-looking string in two very different code paths depending on whether `PathBuf::extension()` returns `Some` or `path.components().count() > 1`. | `ROADMAP.md:L1969` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0211-two-user-visible-shapes-for-one-intended` | *Two user-visible shapes for one intended contract.* The `/session list` REPL command presents session ids as `session-1776441782197-0`. Operators naturally try `--resume session-1776441782197-0` (works) and `--resume session-1776441782197-0.jsonl` (silently breaks). The mental model "it's a file; I'll add the extension" is wrong, and nothing in the error message (`session not found: session-1776441782197-0.jsonl`) explains that the extension silently switched the lookup mode. | `ROADMAP.md:L2020` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0212-batch-orchestrator-surprise-clawhip-styl` | *Batch orchestrator surprise.* Clawhip-style tooling that persists session ids and passes them back through `--resume` cannot depend on round-tripping: a session id that came out of `claw --output-format json status` as `"session-...-0"` under `workspace.session_id` must be passed *without* a `.jsonl` suffix or without any slash-containing directory prefix. Any path-munging that an orchestrator does along the way flips the lookup mode. | `ROADMAP.md:L2021` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0213-no-workspace-scoping-even-if-the-heurist` | *No workspace scoping.* Even if the heuristic is kept as-is, `candidate.exists()` should canonicalize the path and refuse it if it escapes `self.workspace_root`. As shipped, `--resume /etc/passwd` / `--resume ../other-project/.claw/sessions//foreign.jsonl` both proceed to read arbitrary files. | `ROADMAP.md:L2022` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0214-symlink-follow-inside-managed-path-the-m` | *Symlink-follow inside managed path.* The managed-path branch (where operators trust that `.claw/sessions/` is internally safe) silently follows symlinks out of the workspace, turning a weak "managed = scoped" assumption into a false one. | `ROADMAP.md:L2023` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0215-principle-6-violation-terminal-is-transp` | *Principle #6 violation.* "Terminal is transport, not truth" is echoed by "session id is an opaque handle, not a path." Letting the flag accept both shapes interchangeably — with a heuristic that the operator can only learn by experiment — is the exact "semantics leak through accidental inputs" shape principle #6 argues against. | `ROADMAP.md:L2024` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0216-separate-the-two-shapes-into-explicit-su` | *Separate the two shapes into explicit sub-arguments.* `--resume ` for managed ids (stricter character class; reject `.` and `/`); `--resume-file ` for explicit file paths. Deprecate the combined shape behind a single rewrite cycle. Keep the `latest` alias. | `ROADMAP.md:L2027` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0217-if-keeping-the-combined-shape-canonicali` | *If keeping the combined shape, canonicalize and scope the path.* After resolving `candidate`, call `candidate.canonicalize()?` and assert the result starts with `self.workspace_root.canonicalize()?` (or an allow-listed set of roots). Reject with a typed error `SessionControlError::OutsideWorkspace { requested, workspace_root }` otherwise. This also covers the symlink-escape inside `.claw/sessions//`. | `ROADMAP.md:L2028` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0218-surface-the-resolved-path-in-resume-succ` | *Surface the resolved path in `--resume` success.* `status` / `session list` already print the path; `--resume` currently prints `{"kind":"restored","path":…}` on success, but on the *failure* path the resolved vs requested distinction is lost (error shows only the requested string). Return both so an operator can tell whether the file-path branch or the managed-id branch was chosen. | `ROADMAP.md:L2029` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0219-permission-rules-permissions-allow-permi` | **Permission rules (`permissions.allow` / `permissions.deny` / `permissions.ask`) are loaded without validating tool names against the known tool registry, case-sensitively matched against the lowercase runtime tool names, and invisible in every diagnostic surface — so typos and case mismatches silently become non-enforcement** — dogfooded 2026-04-18 on main HEAD `7f76e6b` from `/tmp/cdI`. Operators copy `"Bash(rm:*)"` (capital-B, the convention used in most Claude Code docs and community configs) into `permissions.deny`; `claw doctor` reports `config: ok`; the rule never fires because the runtime tool name is lowercase `bash`. | `ROADMAP.md:L2037` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0220-silent-non-enforcement-of-safety-rules-a` | *Silent non-enforcement of safety rules.* An operator who writes `"deny":["Bash(rm:*)"]` expecting rm to be denied gets **no** enforcement on two independent failure modes: (a) the tool name `Bash` doesn't match the runtime's `bash`; (b) even if spelled correctly, a typo like `"Bsh(rm:*)"` accepts silently. Both produce the same observable state as "no rule configured" — `config: ok`, `permission_mode: ...`, indistinguishable from never having written the rule at all. | `ROADMAP.md:L2060` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0221-cross-harness-config-portability-break-r` | *Cross-harness config-portability break.* ROADMAP's implicit goal of running existing `.mcp.json` / Claude Code configs on `claw` (see PARITY.md) assumes the convention overlap is wide. Case-sensitive tool-name matching breaks portability at the permission layer specifically, silently, in exactly the direction that fails *open* (permissive) rather than fails *closed* (denying unknown tools). | `ROADMAP.md:L2061` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0222-no-preflight-audit-surface-clawhip-style` | *No preflight audit surface.* Clawhip-style orchestrators cannot implement "refuse to spawn this lane unless it denies `Bash(rm:*)`" because they can't read the policy post-parse. They have to re-parse `.claw.json` themselves — which means they also have to re-implement the `parse_optional_permission_rules` + `PermissionRule::parse` semantics to match what claw actually loaded. | `ROADMAP.md:L2062` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0223-runs-contrary-to-the-existing-allowedtoo` | *Runs contrary to the existing `--allowedTools` validation precedent.* The binary already knows the tool registry (as the `--allowedTools` error proves). Not threading the same list into the permission-rule parser is a small oversight with a large blast radius. | `ROADMAP.md:L2063` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0224-validate-rule-tool-names-against-the-reg` | *Validate rule tool names against the registered tool set at config-load time.* In `parse_optional_permission_rules`, call into the same tool-alias table used by `--allowedTools` normalization (likely `tools::normalize_tool_alias` or similar) and either (a) reject unknown names with `ConfigError::Parse`, or (b) capture them into `ConfigLoader::all_warnings` so a typo becomes visible in `doctor` without hard-failing startup. Option (a) is stricter; option (b) is less breaking for existing configs that already work by accident. | `ROADMAP.md:L2066` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0225-case-fold-the-tool-name-compare-in-permi` | *Case-fold the tool-name compare in `PermissionRule::matches`.* Normalize both sides to lowercase (or to the registry's canonical casing) before the `!=` compare. Covers the `Bash` vs `bash` ecosystem-convention gap. Document the normalization in `USAGE.md` / `CLAUDE.md`. | `ROADMAP.md:L2067` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0226-expose-loaded-permission-rules-in-status` | *Expose loaded permission rules in `status` and `doctor` JSON.* Add `workspace.permission_rules: { allow: [...], deny: [...], ask: [...] }` to status JSON (each entry carrying `raw`, `resolved_tool_name`, `matcher`, and an `unknown_tool: bool` flag that flips true when the tool name didn't match the registry). Emit a `permission_rules` doctor check that reports `Warn` when any loaded rule references an unknown tool. Clawhip can now preflight on a typed field instead of re-parsing `.claw.json`. | `ROADMAP.md:L2068` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0227-claw-skills-install-path-always-writes-t` | **`claw skills install ` always writes to the *user-level* registry (`~/.claw/skills/`) with no project-level scope, no uninstall subcommand, and no per-workspace confirmation — a skill installed from one workspace silently becomes active in every other workspace on the same machine** — dogfooded 2026-04-18 on main HEAD `b7539e6` from `/tmp/cdJ`. The install registry defaults to `$HOME/.claw/skills/`, the install subcommand has no sibling `uninstall` (only `/skills [list\|install\|help]` — no remove verb), and the installed skill is immediately visible as `active: true` under `source: user_claw` from every `claw` invocation on the same account. | `ROADMAP.md:L2076` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0228-least-privilege-least-scope-inversion-fo` | *Least-privilege / least-scope inversion for skill surface.* A skill is live code the agent can invoke via slash-dispatch. Installing "this workspace's skill" into user scope by default is the skill analog of setting `permission_mode=danger-full-access` without asking — the default widens the blast radius beyond what the operator probably intended. | `ROADMAP.md:L2115` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0229-no-round-trip-a-clawhip-orchestrator-tha` | *No round-trip.* A clawhip orchestrator that installs a skill for a lane, runs the lane, and wants to clean up has no machine-readable way to remove the skill it just installed. Forces orchestrators to shell out to `rm -rf` on a path they parsed out of the install output's `Installed path` line. | `ROADMAP.md:L2116` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0230-cross-workspace-contamination-any-mistak` | *Cross-workspace contamination.* Any mistake in one workspace's skill install pollutes every other workspace on the same account. Doubly compounds with #85 (skill discovery walks ancestors unbounded) — an attacker who can write under an ancestor OR who can trick the operator into one bad `skills install` in any workspace lands a skill in the user-level registry that's now active in every future `claw` invocation. | `ROADMAP.md:L2117` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0231-runs-contrary-to-the-project-user-split` | *Runs contrary to the project/user split ROADMAP already uses for settings.* `.claw/settings.local.json` is explicitly gitignored and explicitly project-local (`ConfigSource::Local`). Settings have a three-tier scope (`User` / `Project` / `Local`). Skills collapse all three tiers onto `User` at install time. The asymmetry makes the "project-scoped" mental model operators build from settings break when they reach skills. | `ROADMAP.md:L2118` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0232-add-a-scope-flag-to-claw-skills-install` | *Add a `--scope` flag to `claw skills install`.* `--scope user` (current default behavior), `--scope project` (writes to `/.claw/skills//`), `--scope local` (writes to `/.claw/skills//` and adds an entry to `.claw/settings.local.json` if needed). Default: **prompt** the operator in interactive use, error-out with `--scope must be specified` in `--output-format json` use. Let orchestrators commit to a scope explicitly. | `ROADMAP.md:L2121` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0233-add-claw-skills-uninstall-name-and-skill` | *Add `claw skills uninstall ` and `/skills uninstall ` slash-command.* Shares a helper with install; symmetric semantics; `--scope` aware; emits a structured JSON result identical in shape to the install receipt. Covers the machine-readable round-trip that #95 is missing. | `ROADMAP.md:L2122` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0234-surface-the-install-scope-in-claw-skills` | *Surface the install scope in `claw skills` list output.* The current `source: user_claw / Project roots / etc.` label is close but collapses multiple physical locations behind a single bucket. Add `installed_path` to each skill record so an orchestrator can tell *"this one came from my workspace / this one is inherited from user home / this one is pulled in via ancestor walk (#85)."* Pairs cleanly with the #85 ancestor-walk bound — together the skill surface becomes auditable across scope. | `ROADMAP.md:L2123` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0235-claw-help-s-resume-safe-commands-one-lin` | **`claw --help`'s "Resume-safe commands:" one-liner summary does not filter `STUB_COMMANDS` — 62 documented slash commands that are explicitly marked unimplemented still show up as valid resume-safe entries, contradicting the main Interactive slash commands list just above it (which *does* filter stubs per ROADMAP #39)** — **done (verified 2026-04-29):** the Resume-safe command summary now applies the same `STUB_COMMANDS` filter as the Interactive slash command block before rendering help, so unimplemented slash-command stubs no longer advertise as resume-safe. Added `stub_commands_absent_from_resume_safe_help` to lock the filtered one-liner contract alongside the existing REPL completion filter. Fresh proof: `cargo fmt --all --check`, `cargo test -p rusty-claude-cli stub_commands_absent_from_resume_safe_help -- --nocapture`, and `cargo test -p rusty-claude-cli parses_direct_cli_actions -- --nocapture` pass. Original filing below for traceability. | `ROADMAP.md:L2131` / `roadmap_action` | `beta_adoption` | `stale_done` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | Marked done in roadmap but needs freshness re-verification before being used as release evidence. | | `CC2-RM-A0236-advertisement-contradicts-behavior-the-i` | *Advertisement contradicts behavior.* The Interactive slash commands block (what operators read when they run `claw --help`) correctly hides stubs. The Resume-safe summary immediately below it re-advertises them. Two sections of the same help output disagree on what exists. | `ROADMAP.md:L2171` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0237-roadmap-39-is-partially-regressed-that-f` | *ROADMAP #39 is partially regressed.* That filing locked in "hide stub commands from the discovery surfaces that mattered for the original report." Shared help rendering + REPL completions got the filter. The `--help` Resume-safe one-liner was missed. New stubs added to `STUB_COMMANDS` since #39 landed (budget, rate-limit, metrics, diagnostics, workspace, etc.) propagate straight into the Resume-safe listing without any guard. | `ROADMAP.md:L2172` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0238-claws-scraping-help-output-to-build-resu` | *Claws scraping `--help` output to build resume-safe command lists get a 62-item superset of what actually works.* Orchestrators that parse the Resume-safe line to know which slash commands they can safely attempt in resume mode will generate invalid invocations for every stub. | `ROADMAP.md:L2173` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0239-apply-the-same-filter-used-by-the-intera` | *Apply the same filter used by the Interactive block.* Change `resume_supported_slash_commands()` call at `main.rs:8270` to filter out entries whose name is in `STUB_COMMANDS`: | `ROADMAP.md:L2176` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0240-regression-test-add-an-assertion-paralle` | *Regression test.* Add an assertion parallel to `stub_commands_absent_from_repl_completions` that parses the Resume-safe line from `render_help` output and asserts no entry matches `STUB_COMMANDS`. Lock the contract to prevent future regressions. | `ROADMAP.md:L2184` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0241-allowedtools-and-allowedtools-silently-y` | **`--allowedTools ""` and `--allowedTools ",,"` silently yield an empty allow-set that blocks every tool, with no error, no warning, and no trace of the active tool-restriction anywhere in `claw status` / `claw doctor` / `claw --output-format json` surfaces — compounded by `allowedTools` being a *rejected unknown key* in `.claw.json`, so there is no machine-readable way to inspect or recover what the current active allow-set actually is** — dogfooded 2026-04-18 on main HEAD `3ab920a` from `/tmp/cdL`. `--allowedTools "nonsense"` correctly returns a structured error naming every valid tool. `--allowedTools ""` silently produces `Some(BTreeSet::new())` and all subsequent tool lookups fail `contains()` because the set is empty. Neither `status` JSON nor `doctor` JSON exposes `allowed_tools`, so a claw that accidentally restricted itself to zero tools has no observable signal to recover from. | `ROADMAP.md:L2192` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0242-silent-vs-loud-asymmetry-for-equivalent` | *Silent vs. loud asymmetry for equivalent mis-input.* Typo `--allowedTools "nonsens"` → loud structured error naming every valid tool. Typo `--allowedTools ""` (likely produced by a shell variable that expanded to empty: `--allowedTools "$TOOLS"`) → silent zero-tool lane. Shell interpolation failure modes land in the silent branch. | `ROADMAP.md:L2242` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0243-no-observable-recovery-surface-a-claw-th` | *No observable recovery surface.* A claw that booted with `--allowedTools ""` has no way to tell from `claw status`, `claw --output-format json status`, or `claw doctor` that its tool surface is empty. Every diagnostic says "ok." Failures surface only when the agent tries to call a tool and gets denied — pushing the problem to runtime prompt failures instead of preflight. | `ROADMAP.md:L2243` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0244-config-file-surface-is-locked-out-claw-j` | *Config-file surface is locked out.* `.claw.json` cannot declare `allowedTools` — it fails validation with "unknown key." So a team that wants committed, reviewable tool-restriction policy has no path; they can only pass CLI flags at boot. And the CLI flag has the silent-empty footgun. Asymmetric hygiene. | `ROADMAP.md:L2244` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0245-semantically-ambiguous-allowedtools-coul` | *Semantically ambiguous.* `--allowedTools ""` could reasonably mean (a) "no restriction, fall back to default," (b) "restrict to nothing, disable all tools," or (c) "invalid, error." The current behavior is silently (b) — the most surprising and least recoverable option. Compare to `.claw.json` where `"allowedTools": []` would be an explicit array literal — but that surface is disabled entirely. | `ROADMAP.md:L2245` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0246-adds-to-the-permission-audit-cluster-50` | *Adds to the permission-audit cluster.* #50 / #87 / #91 / #94 already cover permission-mode / permission-rule validation, default dangers, parser disagreement, and rule typo tolerance. #97 covers the *tool-allow-list* axis of the same problem: the knob exists, parses empty input silently, disables all tools, and hides its own active value from every diagnostic surface. | `ROADMAP.md:L2246` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0247-reject-empty-token-input-at-parse-time-i` | *Reject empty-token input at parse time.* In `normalize_allowed_tools` (tools/src/lib.rs:192), after the inner token loop, if the accumulated `allowed` set is empty *and* `values` was non-empty, return `Err("--allowedTools was provided with no usable tool names (got '{raw}'). To restrict to no tools explicitly, pass --allowedTools none; to remove the restriction, omit the flag.")`. ~10 lines. | `ROADMAP.md:L2249` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0248-support-an-explicit-none-sentinel-if-the` | *Support an explicit "none" sentinel if the "zero tools" lane is actually desirable.* If a claw legitimately wants "zero tools, purely conversational," accept `--allowedTools none` / `--allowedTools ""` with an explicit opt-in. But reject the ambiguous silent path. | `ROADMAP.md:L2250` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0249-surface-active-allow-set-in-status-json` | *Surface active allow-set in `status` JSON and `doctor` JSON.* Add a top-level `allowed_tools: {source: "flag"\|"config"\|"default", entries: [...]}` field to the status JSON builder (main.rs `:4951`). Add a `tool_restrictions` doctor check that reports the active allow-set and flags suspicious shapes (empty, single tool, missing Read/Bash for a coding lane). ~40 lines across status + doctor. | `ROADMAP.md:L2251` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0250-accept-allowedtools-or-a-safer-alternati` | *Accept `allowedTools` (or a safer alternative name) in `.claw.json`.* Or emit a clearer error pointing to the CLI flag as the correct surface. Right now `allowedTools` is silently treated as "unknown field," which is technically correct but operationally hostile — the user typed a plausible key name and got a generic schema failure. | `ROADMAP.md:L2252` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0251-regression-tests-one-for-normalize-allow` | *Regression tests.* One for `normalize_allowed_tools(&[""])` returning `Err`. One for `--allowedTools ""` on the CLI returning a non-zero exit with a structured error. One for status JSON exposing `allowed_tools` when the flag is active. | `ROADMAP.md:L2253` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0252-compact-is-silently-ignored-outside-the` | **`--compact` is silently ignored outside the `Prompt → Text` path: `--compact --output-format json` (explicitly documented as "text mode only" in `--help` but unenforced), `--compact status`, `--compact doctor`, `--compact sandbox`, `--compact init`, `--compact export`, `--compact mcp`, `--compact skills`, `--compact agents`, and `claw --compact` with piped stdin (hardcoded `compact: false` at the stdin fallthrough). No error, no warning, no diagnostic trace anywhere** — dogfooded 2026-04-18 on main HEAD `7a172a2` from `/tmp/cdM`. `--help` at `main.rs:8251` explicitly documents "`--compact` (text mode only; useful for piping)"; the implementation *knows* the flag is only meaningful for the text branch of the prompt turn output, but does not refuse or warn in any other case. A claw piping output through `claw --compact --output-format json prompt "..."` gets the same verbose JSON blob as without the flag, silently, with no indication that its documented behavior was discarded. | `ROADMAP.md:L2261` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0253-documented-behavior-silently-discarded-h` | *Documented behavior, silently discarded.* `--help` tells operators the flag applies in "text mode only." That is the honest constraint. But the implementation never refuses non-text use — it just quietly drops the flag. A claw that piped `claw --compact --output-format json "..."` into a downstream parser would reasonably expect the JSON to be compacted (the human-readable `--help` sentence is ambiguous about whether "text mode only" means "ignored in JSON" or "does not apply in JSON, but will be applied if you pass text"). The current behavior is option 1; the documented intent could be read as either. | `ROADMAP.md:L2306` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0254-silent-no-op-scope-is-broad-nine-cliacti` | *Silent no-op scope is broad.* Nine CliAction variants (Status, Sandbox, Doctor, Init, Export, Mcp, Skills, Agents, plus stdin-piped Prompt) accept `--compact` on the command line, parse it successfully, and throw the value away without surfacing anything. That's a large set of commands that silently lie about flag support. | `ROADMAP.md:L2307` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0255-stdin-piped-prompt-hardcodes-compact-fal` | *Stdin-piped Prompt hardcodes `compact: false`.* The stdin fallthrough at `:614` constructs `CliAction::Prompt { ..., compact: false, ... }` regardless of the user's `--compact`. This is actively hostile: the user opted in, the flag was parsed, and the value is silently overridden by a hardcoded `false`. A claw running `echo "summarize" \| claw --compact "$model"` gets full verbose output, not the piping-friendly compact form advertised in `--help`'s own `claw --compact "summarize Cargo.toml" \| wc -l` example. | `ROADMAP.md:L2308` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0256-no-observable-diagnostic-neither-status` | *No observable diagnostic.* Neither `status` / `doctor` / the error stream nor the actual JSON output reveals whether `--compact` was honored or dropped. A claw cannot tell from the output shape alone whether the flag worked or was a no-op. | `ROADMAP.md:L2309` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0257-adds-to-the-silent-flag-no-op-class-sibl` | *Adds to the "silent flag no-op" class.* Sibling of #97 (`--allowedTools ""` silently produces an empty allow-set) and #96 (`--help` Resume-safe summary silently lies about what commands work) — three different flavors of the same underlying problem: flags / surfaces that parse successfully, do nothing useful (or do something harmful), and emit no diagnostic. | `ROADMAP.md:L2310` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0258-reject-compact-with-output-format-json-a` | *Reject `--compact` with `--output-format json` at parse time.* In `parse_args` after `let allowed_tools = normalize_allowed_tools(...)?`, if `compact && matches!(output_format, CliOutputFormat::Json)`, return `Err("--compact has no effect in --output-format json; drop the flag or switch to --output-format text")`. ~5 lines. | `ROADMAP.md:L2313` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0259-reject-compact-on-non-prompt-subcommands` | *Reject `--compact` on non-Prompt subcommands.* In the dispatch match around `main.rs:642-770`, when `compact == true` and the subcommand is `status` / `sandbox` / `doctor` / `init` / `export` / `mcp` / `skills` / `agents` / `system-prompt` / `bootstrap-plan` / `dump-manifests`, return `Err("--compact only applies to prompt turns; the '{cmd}' subcommand does not produce tool-call output to strip")`. ~15 lines + a shared helper to name the subcommand in the error. | `ROADMAP.md:L2314` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0260-honor-compact-in-the-stdin-piped-prompt` | *Honor `--compact` in the stdin-piped Prompt fallthrough.* At `main.rs:614` change `compact: false` to `compact`. One line. Add a parity test: `echo "hi" \| claw --compact prompt "..."` should produce the same compact output as `claw --compact prompt "hi"`. | `ROADMAP.md:L2315` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0261-optionally-support-compact-for-json-mode` | *Optionally — support `--compact` for JSON mode too.* If the compact-JSON lane is actually useful (strip `tool_uses` / `tool_results` / `prompt_cache_events` and keep only `message` / `model` / `usage`), add a fourth arm to `run_turn_with_output`: `CliOutputFormat::Json if compact => self.run_prompt_json_compact(input)`. Not required for the fix — just a forward-looking note. If not supported, rejection in step 1 is the right answer. | `ROADMAP.md:L2316` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0262-regression-tests-one-per-rejected-combin` | *Regression tests.* One per rejected combination. One for the stdin-piped-Prompt fix. Lock parser behavior so this cannot silently regress. | `ROADMAP.md:L2317` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0263-claw-system-prompt-cwd-path-date-yyyy-mm` | **`claw system-prompt --cwd PATH --date YYYY-MM-DD` performs zero validation on either value: nonexistent paths, empty strings, multi-line strings, SQL-injection payloads, and arbitrary prompt-injection text are all accepted verbatim and interpolated straight into the rendered system-prompt output in two places each (`# Environment context` and `# Project context` sections) — a classic unvalidated-input → system-prompt surface that a downstream consumer invoking `claw system-prompt --date "$USER_INPUT"` or `--cwd "$TAINTED_PATH"` could weaponize into prompt injection** — dogfooded 2026-04-18 on main HEAD `0e263be` from `/tmp/cdN`. `--help` documents the format as `[--cwd PATH] [--date YYYY-MM-DD]` — implying a filesystem path and an ISO date — but the parser (`main.rs:1162-1190`) just does `PathBuf::from(value)` and `date.clone_from(value)` with no further checks. Both values then reach `SystemPromptBuilder::render_env_context()` at `prompt.rs:176-186` and `render_project_context()` at `prompt.rs:289-293` where they are formatted into the output via `format!("Working directory: {}", cwd.display())` and `format!("Today's date is {}.", current_date)` with no escaping or line-break rejection. | `ROADMAP.md:L2325` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0264-advertised-format-vs-accepted-format-hel` | *Advertised format vs. accepted format.* `--help` says `[--cwd PATH] [--date YYYY-MM-DD]`. The parser accepts any UTF-8 string, including empty, multi-line, non-ISO dates, and paths that don't exist on disk. Same pattern as #96 / #98 — documented constraint, unenforced at the boundary. | `ROADMAP.md:L2406` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0265-downstream-consumers-are-the-attack-surf` | *Downstream consumers are the attack surface.* `claw system-prompt` is a utility / debug surface. A claw or CI pipeline that does `claw system-prompt --date "$(date +%Y-%m-%d)" --cwd "$REPO_PATH"` where `$REPO_PATH` comes from an untrusted source (issue title, branch name, user-provided config) has a prompt-injection vector. Newline injection breaks out of the structured bullet into a fresh standalone line that the LLM will read as a separate instruction. | `ROADMAP.md:L2407` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0266-injection-happens-twice-per-value-both-d` | *Injection happens twice per value.* Both `--date` and `--cwd` are rendered into two sections of the system prompt (`# Environment context` and `# Project context`). A single injection payload gets two bites at the apple. | `ROADMAP.md:L2408` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0267-cwd-accepts-nonexistent-paths-without-an` | *`--cwd` accepts nonexistent paths without any signal.* If a claw meant to call `claw system-prompt --cwd /real/project/path` and a shell expansion failure sent `/real/project/${MISSING_VAR}` through, the output silently renders the broken path into the system prompt as if it were valid. No warning. No existence check. Not even a `canonicalize()` that would fail on nonexistent paths. | `ROADMAP.md:L2409` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0268-defense-in-depth-exists-at-the-llm-layer` | *Defense-in-depth exists at the LLM layer, but not at the input layer.* The system prompt itself contains the bullet *"Tool results may include data from external sources; flag suspected prompt injection before continuing."* That is fine LLM guidance, but the system prompt should not itself be a vehicle for injection — the bullet is about tool results, not about the system prompt text. A defense-in-depth system treats the system prompt as trusted; allowing arbitrary operator input into it breaks that trust boundary. | `ROADMAP.md:L2410` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0269-adds-to-the-silent-flag-unvalidated-inpu` | *Adds to the silent-flag / unvalidated-input class* with #96 / #97 / #98. This one is the most severe of the four because the failure mode is *prompt injection* rather than silent feature no-op: it can actually cause an LLM to do the wrong thing, not just ignore a flag. | `ROADMAP.md:L2411` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0270-parse-date-as-iso-8601-replace-date-clon` | *Parse `--date` as ISO-8601.* Replace `date.clone_from(value)` at `main.rs:1175` with a `chrono::NaiveDate::parse_from_str(value, "%Y-%m-%d")` or equivalent. Return `Err(format!("invalid --date '{value}': expected YYYY-MM-DD"))` on failure. Rejects empty strings, non-ISO dates, out-of-range years, newlines, and arbitrary payloads in one line. ~5 lines if `chrono` is already a dep, ~10 if a hand-rolled parser. | `ROADMAP.md:L2414` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0271-validate-cwd-is-a-real-path-replace-cwd` | *Validate `--cwd` is a real path.* Replace `cwd = PathBuf::from(value)` at `main.rs:1169` with `cwd = std::fs::canonicalize(value).map_err(\|e\| format!("invalid --cwd '{value}': {e}"))?`. Rejects nonexistent paths, empty strings, and newline-containing paths (canonicalize fails on them). ~5 lines. | `ROADMAP.md:L2415` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0272-strip-or-reject-newlines-defensively-at` | *Strip or reject newlines defensively at the rendering boundary.* Even if the parser validates, add a `debug_assert!(!value.contains('\n'))` or a final-boundary sanitization pass in `render_env_context` / `render_project_context` so that any future entry point into these functions cannot smuggle newlines. Defense in depth. ~3 lines per site. | `ROADMAP.md:L2416` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0273-regression-tests-one-per-rejected-case-e` | *Regression tests.* One per rejected case (empty `--date`, non-ISO `--date`, newline-containing `--date`, nonexistent `--cwd`, empty `--cwd`, newline-containing `--cwd`). Lock parser behavior. | `ROADMAP.md:L2417` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0274-claw-status-claw-doctor-json-surfaces-ex` | **`claw status` / `claw doctor` JSON surfaces expose no commit identity: no HEAD SHA, no expected-base SHA, no stale-base state, no upstream tracking info (ahead/behind), no merge-base — making the "branch-freshness before blame" principle from this very roadmap (§Product Principles #4) unachievable without a claw shelling out to `git rev-parse HEAD` / `git merge-base` / `git rev-list` itself. The `--base-commit` flag is silently accepted by `status` / `doctor` / `sandbox` / `init` / `export` / `mcp` / `skills` / `agents` and silently dropped — same silent-no-op pattern as #98 but on the stale-base axis. The `.claw-base` file support exists in `runtime::stale_base` but is invisible to every JSON diagnostic surface. Even the detached-HEAD signal is a magic string (`git_branch: "detached HEAD"`) rather than a typed state, with no accompanying commit SHA to tell *which* commit HEAD is detached on** — dogfooded 2026-04-18 on main HEAD `63a0d30` from `/tmp/cdU` and scratch repos under `/tmp/cdO*`. `claw --base-commit abc1234 status` exits 0 with identical JSON to `claw status`; the flag had zero effect on the status/doctor surface. `run_stale_base_preflight` at `main.rs:3058` is wired into `CliAction::Prompt` and `CliAction::Repl` dispatch paths only, and it writes its output to stderr as human prose — never into the JSON envelope. | `ROADMAP.md:L2425` / `roadmap_action` | `alpha_blocker` | `stale_done` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | Marked done in roadmap but needs freshness re-verification before being used as release evidence. | | `CC2-RM-A0275-claw-status-claw-doctor-json-surfaces-ex` | **`claw status` / `claw doctor` JSON surfaces expose no commit identity: no HEAD SHA, no expected-base SHA, no stale-base state, no upstream tracking info (ahead/behind), no merge-base — making the "branch-freshness before blame" principle from this very roadmap (Product Principle 4) unachievable without a claw shelling out to `git rev-parse HEAD` / `git merge-base` / `git rev-list` itself. The `--base-commit` flag is silently accepted by `status` / `doctor` / `sandbox` / `init` / `export` / `mcp` / `skills` / `agents` and silently dropped — same silent-no-op pattern as #98 but on the stale-base axis. The `.claw-base` file support exists in `runtime::stale_base` but is invisible to every JSON diagnostic surface. Even the detached-HEAD signal is a magic string (`git_branch: "detached HEAD"`) rather than a typed state, with no accompanying commit SHA to tell *which* commit HEAD is detached on** — dogfooded 2026-04-18 on main HEAD `63a0d30` from `/tmp/cdU` and scratch repos under `/tmp/cdO*`. `claw --base-commit abc1234 status` exits 0 with identical JSON to `claw status`; the flag had zero effect on the status/doctor surface. `run_stale_base_preflight` at `main.rs:3058` is wired into `CliAction::Prompt` and `CliAction::Repl` dispatch paths only, and it writes its output to stderr as human prose — never into the JSON envelope. | `ROADMAP.md:L2450` / `roadmap_action` | `alpha_blocker` | `stale_done` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | Marked done in roadmap but needs freshness re-verification before being used as release evidence. | | `CC2-RM-A0276-rusty-claude-permission-mode-env-var-sil` | **`RUSTY_CLAUDE_PERMISSION_MODE` env var silently swallows any invalid value — including common typos and valid-config-file aliases — and falls through to the ultimate default `danger-full-access`. A lane that sets `export RUSTY_CLAUDE_PERMISSION_MODE=readonly` (missing hyphen), `read_only` (underscore), `READ-ONLY` (case), `dontAsk` (config-file alias not recognized at env-var path), or any garbage string gets the LEAST safe mode silently, while `--permission-mode readonly` loudly errors. The env var itself is also undocumented — not referenced in `--help`, README, or any docs — an undocumented knob with fail-open semantics** — dogfooded 2026-04-18 on main HEAD `d63d58f` from `/tmp/cdV`. Matrix of tested values: `"read-only"` / `"workspace-write"` / `"danger-full-access"` / `" read-only "` all work. `""` / `"garbage"` / `"redonly"` / `"readonly"` / `"read_only"` / `"READ-ONLY"` / `"ReadOnly"` / `"dontAsk"` / `"readonly\n"` all silently resolve to `danger-full-access`. | `ROADMAP.md:L2491` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage`, `stable_alpha_contracts` | — | | `CC2-RM-A0278-claw-agents-silently-discards-every-agen` | **`claw agents` silently discards every agent definition that is not a `.toml` file — including `.md` files with YAML frontmatter, which is the Claude Code convention that most operators will reach for first. A `.claw/agents/foo.md` file is silently skipped by the agent-discovery walker; `agents list` reports zero agents; doctor reports ok; neither `agents help` nor `--help` nor any docs mention that `.toml` is the accepted format — the gate is entirely code-side and invisible at the operator layer. Compounded by the agent loader not validating *any* of the values inside a discovered `.toml` (model names, tool names, reasoning effort levels) — so the `.toml` gate filters *form* silently while downstream ignores *content* silently** — dogfooded 2026-04-18 on main HEAD `6a16f08` from `/tmp/cdX`. A `.claw/agents/broken.md` with claude-code-style YAML frontmatter is invisible to `agents list`. The same content moved into `.claw/agents/broken.toml` is loaded instantly — including when it references `model: "nonexistent/model-that-does-not-exist"` and `tools: ["DoesNotExist", "AlsoFake"]`, both of which are accepted without complaint. | `ROADMAP.md:L2670` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0279-export-path-slash-command-and-claw-expor` | **`/export ` (slash command) and `claw export ` (CLI) are two different code paths with incompatible filename semantics: the slash path silently appends `.txt` to any non-`.txt` filename (`/export foo.md` → `foo.md.txt`, `/export report.json` → `report.json.txt`), and neither path does any path-traversal validation so a relative path like `../../../tmp/pwn.md` resolves to the computed absolute path outside the project root. The slash path's rendered content is full Markdown (`# Conversation Export`, `- **Session**: ...`, fenced code blocks) but the forced `.txt` extension misrepresents the file type. Meanwhile `/export`'s `--help` documentation string is just `/export [file]` — no mention of the forced-`.txt` behavior, no mention of the path-resolution semantics** — dogfooded 2026-04-18 on main HEAD `7447232` from `/tmp/cdY`. A claw orchestrating session transcripts via the slash command and expecting `.md` output gets a `.md.txt` file it cannot find with a glob for `*.md`. A claw writing session exports under a trusted output directory gets silently path-traversed outside it when the caller's filename input contains `../` segments. | `ROADMAP.md:L2757` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0280-claw-status-ignores-claw-json-s-model-fi` | **`claw status` ignores `.claw.json`'s `model` field entirely and always reports the compile-time `DEFAULT_MODEL` (`claude-opus-4-6`), while `claw doctor` reports the raw *configured* alias string (e.g. `haiku`) mislabeled as "Resolved model", and the actual turn-dispatch path resolves the alias to the canonical name (e.g. `claude-haiku-4-5-20251213`) via a third code path (`resolve_repl_model`). Four separate surfaces disagree on "what is this lane's active model?": config file (alias as written), `doctor` (alias mislabeled as resolved), `status` (hardcoded default, config ignored), and turn dispatch (canonical, alias-resolved). A claw reading `status` JSON to pick a tool/routing strategy based on the active model will make decisions against a model string that is neither configured nor actually used** — dogfooded 2026-04-18 on main HEAD `6580903` from `/tmp/cdZ`. `.claw.json` with `{"model":"haiku"}` produces `status.model = "claude-opus-4-6"` and `doctor` config detail `Resolved model haiku` simultaneously. Neither value matches what an actual turn would use (`claude-haiku-4-5-20251213`). | `ROADMAP.md:L2850` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0281-config-merge-uses-deep-merge-objects-whi` | **Config merge uses `deep_merge_objects` which recurses into nested objects but REPLACES arrays — so `permissions.allow`, `permissions.deny`, `permissions.ask`, `hooks.PreToolUse`, `hooks.PostToolUse`, `hooks.PostToolUseFailure`, and `plugins.externalDirectories` from an earlier config layer are silently discarded whenever a later layer sets the same key. A user-home `~/.claw/settings.json` with `permissions.deny: ["Bash(rm *)"]` is silently overridden by a project `.claw.json` with `permissions.deny: ["Bash(sudo *)"]` — the user's `Bash(rm *)` deny is GONE and never surfaced. Worse: a workspace-local `.claw/settings.local.json` with `permissions.deny: []` silently removes every deny rule from every layer above it** — dogfooded 2026-04-18 on main HEAD `71e7729` from `/tmp/cdAA`. MCP servers *are* merged by-key (distinct server names from different layers coexist), but permission-rule arrays and hook arrays are NOT — they are last-writer-wins for the entire list. This makes claw-code's config merge incompatible with any multi-tier permission policy (team default → project override → local tweak) that a security-conscious team would want, and it is the exact failure mode #91 / #94 / #101 warned about on adjacent axes. | `ROADMAP.md:L2935` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0282-the-entire-hook-subsystem-is-invisible-t` | **The entire hook subsystem is invisible to every JSON diagnostic surface. `doctor` reports no hook count and no hook health. `mcp`/`skills`/`agents` list-surfaces have no hook sibling. `/hooks list` is in `STUB_COMMANDS` and returns "not yet implemented in this build." `/config hooks` shows `merged_keys: 1` but not the hook commands. Hook execution progress events (`Started`/`Completed`/`Cancelled`) route to `eprintln!` as human prose ("[hook PreToolUse] tool: command"), never into the `--output-format json` envelope. Hook commands are executed via `sh -lc ` so they get full shell expansion; command strings are accepted at config-load without any validation (nonexistent paths, garbage strings, and shell-expansion payloads all accepted as "Config: ok"). Compounded by #106: a downstream `.claw/settings.local.json` can silently REPLACE the entire upstream hook array — so a team-level security-audit hook can be erased and replaced by an attacker-controlled hook with zero visibility anywhere machine-readable** — dogfooded 2026-04-18 on main HEAD `a436f9e` from `/tmp/cdBB`. Hooks exist as a runtime capability (`runtime::hooks` module, `HookProgressReporter` trait, shell dispatcher at `hooks.rs:739-754`) but they are the least-observable subsystem in claw-code from the machine-orchestration perspective. | `ROADMAP.md:L3020` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0283-cli-subcommand-typos-fall-through-to-the` | **CLI subcommand typos fall through to the LLM prompt dispatch path and silently burn tokens — `claw doctorr`, `claw skilsl`, `claw statuss`, `claw deply` all resolve to `CliAction::Prompt { prompt: "doctorr", ... }` and attempt a live LLM turn. Slash commands have a "Did you mean /skill, /skills" suggestion system that works correctly; subcommands have the same infrastructure available but it is never applied. A claw or CI pipeline that typos a subcommand name gets no structural signal — just the prompt API error (usually "missing credentials" in local dev, or actual billed LLM output with provider keys configured)** — dogfooded 2026-04-18 on main HEAD `91c79ba` from `/tmp/cdCC`. Every unrecognized first-positional falls through the `_other => Ok(CliAction::Prompt { ... })` arm at `main.rs:707`, which is the documented shorthand-prompt mode — but with no levenshtein / prefix matching against the known subcommand set to offer a suggestion first. A claw running with `ANTHROPIC_API_KEY` set that runs `claw doctorr` actually sends the string "doctorr" to the configured LLM provider and pays for the tokens. | `ROADMAP.md:L3091` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage`, `stable_alpha_contracts` | — | | `CC2-RM-A0284-config-validation-emits-structured-diagn` | **Config validation emits structured diagnostics (`ConfigDiagnostic` with `path`, `field`, `line`, `kind: UnknownKey \| WrongType \| Deprecated`) but the loader flattens ALL warnings to prose via `eprintln!("warning: {warning}")` at `config.rs:298-300`. Deprecation notices for `permissionMode` (now `permissions.defaultMode`) and `enabledPlugins` (now `plugins.enabled`) appear only on stderr — never in the `config` check's JSON output, never as a top-level doctor `warnings` array, never surfaced in `status` JSON, never captured in any machine-readable envelope. A claw reading `--output-format json doctor` with `2>/dev/null` gets `status: "ok", summary: "runtime config loaded successfully"` even when the config uses deprecated field names. Migration-friction and truth-audit gap — the validator knows, the claw does not** — dogfooded 2026-04-18 on main HEAD `21b2773` from `/tmp/cdDD`. The `ValidationResult { errors, warnings }` struct exists; `ConfigDiagnostic` Display impl formats precisely; `DEPRECATED_FIELDS` const lists both migration paths. None of this is surfaced. `errors` (load-failing) correctly propagate into `config.status = fail` with the diagnostic string in `summary`. `warnings` (non-failing) do not. | `ROADMAP.md:L3165` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0285-configloader-discover-only-looks-at-cwd` | **`ConfigLoader::discover` only looks at `$CWD/.claw.json`, `$CWD/.claw/settings.json`, and `$CWD/.claw/settings.local.json` — it does not walk up to `project_root` (the detected git root) to find config. A developer with `.claw.json` at the repo root who runs claw from a subdirectory gets ZERO config loaded. `doctor` reports `config: ok, no config files present; defaults are active`. `status.permission_mode` resolves to `danger-full-access` (the compile-time fallback) silently. Meanwhile CLAUDE.md / instruction files DO walk ancestors unbounded (per #85). Two adjacent discovery mechanisms, opposite strategies, no documentation, silently inconsistent behavior** — dogfooded 2026-04-18 on main HEAD `16244ce` from `/tmp/cdGG/nested/deep/dir`. The workspace-check correctly identifies `project_root: /tmp/cdGG` (via git-root walk), but config discovery never reaches that directory. A `.claw.json` at `/tmp/cdGG/.claw.json` (the project root) is INVISIBLE from any subdirectory below it. Under-discovery is the opposite failure mode from #85's over-discovery — same meta-issue: "ancestor walk policy is subsystem-by-subsystem ad-hoc, not principled." | `ROADMAP.md:L3237` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0286-providers-slash-command-is-documented-as` | **`/providers` slash command is documented as "List available model providers" in both `--help` and the shared command-spec registry, but its parser at `commands/src/lib.rs:1386` maps it to `SlashCommand::Doctor` — so invoking `/providers` runs the six-check health report (auth/config/install_source/workspace/sandbox/system) and returns `{kind: "doctor", checks: [...]}`. A claw expecting a structured list of `{providers: [{name, models, base_url, reachable}]}` gets workspace-health JSON instead** — dogfooded 2026-04-18 on main HEAD `b2366d1` from `/tmp/cdHH`. The command-spec registry at `commands/src/lib.rs:716-718` declares `name: "providers", summary: "List available model providers"`. `--help` echoes that summary in the slash-command listing and in the Resume-safe line. Actual dispatch routes to doctor. Declared contract and implementation diverge completely; this is a specification mismatch rather than a stub — `/providers` has documented semantics claw does not implement and silently delivers the wrong subsystem. | `ROADMAP.md:L3321` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0287-concurrent-claw-invocations-that-touch-t` | **Concurrent claw invocations that touch the same session file (e.g. two `/clear --confirm` or two `/compact` calls on the same session-id race) fail intermittently with a raw OS errno — `{"type":"error","error":"No such file or directory (os error 2)"}` — instead of a domain-specific concurrent-modification error. There is no file locking, no read-modify-write protection, no rename-race guard. The loser of the race gets ENOENT because the winner rotated, renamed, or deleted the session file between the loser's `fs::read_to_string` and its own `fs::write`. A claw orchestrating multiple lanes that happen to share a session id (because the operator reuses one, or because a CI matrix is re-running with the same state) gets unpredictable partial failures with un-actionable raw-io errors** — dogfooded 2026-04-18 on main HEAD `a049bd2` from `/tmp/cdII`. Five concurrent `/compact` calls on the same session: 4 succeed, 1 fails with `os error 2`. Two concurrent `/clear --confirm` calls: same pattern. | `ROADMAP.md:L3398` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0288-session-switch-session-fork-and-session` | **`/session switch`, `/session fork`, and `/session delete` are registered by the parser (produce `SlashCommand::Session { action, target }`), documented in `--help` as first-class session-management verbs, but dispatch in `run_resume_command` implements ONLY `/session list` with a dedicated handler at `main.rs:2908` — every other `Session { .. }` variant falls through to the "unsupported resumed slash command" bucket at `main.rs:2936`. There is also no `claw session ` CLI subcommand: `claw session delete s` falls through to Prompt dispatch per #108. Net effect: claws can enumerate sessions via `/session list`, but CANNOT programmatically switch, fork, or delete — those are REPL-interactive only, with no `--output-format json`-compatible alternative and no `claw session ...` CLI equivalent. Help advertises the capability universally; implementation surfaces it only in the REPL** — dogfooded 2026-04-18 on main HEAD `8b25daf` from `/tmp/cdJJ`. Full test matrix: `/session list` works from `--resume` (returns structured JSON), `/session switch s` / `/session fork foo` / `/session delete s` / `/session delete s --force` all return `{"type":"error","error":"unsupported resumed slash command"}`. | `ROADMAP.md:L3478` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0289-session-reference-resolution-is-asymmetr` | **Session reference-resolution is asymmetric with `/session list`: after `/clear --confirm`, the new session_id baked into the meta header diverges from the filename (the file is renamed-in-place as `.jsonl`). `/session list` reads the meta header and reports the NEW session_id (e.g. `session-1776481564268-1`). But `claw --resume ` looks up by FILENAME stem in `sessions_root`, not by meta-header id, and fails with `"session not found"`. Net effect: `/session list` returns session ids that the `--resume` reference resolver cannot find. Also: `/clear` backup files (`.jsonl.before-clear-.bak`) are filtered out of `/session list` (zero discoverability via JSON surface), and 0-byte session files at lookup path cause `--resume` to silently construct ephemeral-never-persisted sessions with fabricated ids not in `/session list` either** — dogfooded 2026-04-18 on main HEAD `43eac4d` from `/tmp/cdNN` and `/tmp/cdOO`. | `ROADMAP.md:L3550` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0290-claw-init-generates-claw-json-with-permi` | **`claw init` generates `.claw.json` with `"permissions": {"defaultMode": "dontAsk"}` — where "dontAsk" is an alias for `danger-full-access`, hardcoded in `rust/crates/runtime/src/config.rs:858`. The init output is prose-only with zero mention of "danger", "permission", or "access" — a claw (or human) running `claw init` in a fresh project gets no signal that the generated config turns permissions off. `claw init --output-format json` returns `{kind: "init", message: ""}` instead of structured `{files_created: [...], defaultMode: "dontAsk", security_posture: "danger-full-access"}`. The alias choice itself ("dontAsk") obscures the behavior: a user seeing `"defaultMode": "dontAsk"` in their new repo naturally reads it as "don't ask me to confirm" — NOT "grant every tool every permission unconditionally" — but the two are identical per the parser at `config.rs:858`. `claw init` is effectively a silent bootstrap to maximum-permissions mode** — dogfooded 2026-04-18 on main HEAD `ca09b6b` from `/tmp/cdPP`. | `ROADMAP.md:L3655` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0291-unknown-keys-in-claw-json-are-strict-err` | **Unknown keys in `.claw.json` are strict ERRORS, not warnings — `claw` hard-fails at startup with exit 1 if any field is unrecognized. Only the FIRST error is reported; all subsequent validation messages are lost. Valid Claude Code config fields (`apiKeyHelper`, `env`, and other Claude-Code-native keys) trigger the same hard-fail, so a user renaming `.claude.json → .claw.json` for migration gets `"unknown key \"apiKeyHelper\"" ... exit 1` with zero guidance on what to delete. The error goes to stderr as structured JSON (`{"type":"error","error":"..."}`) but a `--output-format json` consumer has to read BOTH stdout AND stderr to capture success-or-error — the stdout side is empty on error. There is no `--ignore-unknown-config` flag, no `strict` vs `warn` mode toggle, no forward-compat path — a claw's future-self putting a single new field in the config kills every older claw binary** — dogfooded 2026-04-18 on main HEAD `ad02761` from `/tmp/cdRR`. | `ROADMAP.md:L3752` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage`, `stable_alpha_contracts` | — | | `CC2-RM-A0292-p-claude-code-compat-shortcut-for-prompt` | **`-p` (Claude Code compat shortcut for "prompt") is super-greedy: the parser at `main.rs:524-538` does `let prompt = args[index + 1..].join(" ")` and immediately returns, swallowing EVERY subsequent arg into the prompt text. `--model sonnet`, `--output-format json`, `--help`, `--version`, and any other flag placed AFTER `-p` are silently consumed into the prompt that gets sent to the LLM. Flags placed BEFORE `-p` are also dropped when parser-state variables like `wants_help` are set and then discarded by the early `return Ok(CliAction::Prompt {...})`. The emptiness check (`if prompt.trim().is_empty()`) is too weak: `claw -p --model sonnet` produces prompt=`"--model sonnet"` which is non-empty, so no error is raised and the literal flag string is sent to the LLM as user input** — dogfooded 2026-04-18 on main HEAD `f2d6538` from `/tmp/cdSS`. | `ROADMAP.md:L3847` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0293-three-slash-commands-stats-tokens-and-ca` | **Three slash commands — `/stats`, `/tokens`, and `/cache` — all collapse to `SlashCommand::Stats` at `commands/src/lib.rs:1405` (`"stats" \| "tokens" \| "cache" => SlashCommand::Stats`), returning bit-identical output (`{"kind":"stats", ...}`) despite `--help` advertising three distinct capabilities: `/stats` = "Show workspace and session statistics", `/tokens` = "Show token count for the current conversation", `/cache` = "Show prompt cache statistics". A claw invoking `/cache` expecting cache-focused output gets a grab-bag that says `kind: "stats"` — not even `kind: "cache"`. A claw invoking `/tokens` expecting a focused token report gets the same grab-bag labeled `kind: "stats"`. This is the 2-dimensional-superset of #111 (2-way dispatch collapse) — #118 is a 3-way collapse where each collapsed alias has a DIFFERENT help description, compounding the documentation-vs-implementation gap** — dogfooded 2026-04-18 on main HEAD `b9331ae` from `/tmp/cdTT`. | `ROADMAP.md:L3943` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0294-the-this-is-a-slash-command-use-resume-h` | **The "this is a slash command, use `--resume`" helpful-error path only triggers for EXACTLY-bare slash verbs (`claw hooks`, `claw plan`) — any argument after the verb (`claw hooks --help`, `claw plan list`, `claw theme dark`, `claw tokens --json`, `claw providers --output-format json`) silently falls through to Prompt dispatch and burns billable tokens on a nonsensical "hooks --help" user-prompt. The helpful-error function at `main.rs:765` (`bare_slash_command_guidance`) is gated by `if rest.len() != 1 { return None; }` at `main.rs:746`. Nine known slash-only verbs (`hooks`, `plan`, `theme`, `tasks`, `subagent`, `agent`, `providers`, `tokens`, `cache`) ALL exhibit this: bare → clean error; +any-arg → billable LLM call. Users discovering `claw hooks` by pattern-following from `claw status --help` get silently charged** — dogfooded 2026-04-18 on main HEAD `3848ea6` from `/tmp/cdUU`. | `ROADMAP.md:L4025` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0295-claw-json-is-parsed-by-a-custom-json-ish` | **`.claw.json` is parsed by a custom JSON-ish parser (`JsonValue::parse` in `rust/crates/runtime/src/json.rs`) that accepts trailing commas (one), but silently drops files containing line comments, block comments, unquoted keys, UTF-8 BOM, single quotes, hex numbers, leading commas, or multiple trailing commas. The user sees `.claw.json` behave partially like JSON5 (trailing comma works) and reasonably assumes JSON5 tolerance. Comments or unquoted keys — the two most common JSON5 conveniences a developer would reach for — silently cause the entire config to be dropped with ZERO stderr, exit 0, `loaded_config_files: 0`. Since the no-config default is `danger-full-access` per #87, a commented-out `.claw.json` with `"defaultMode": "default"` silently UPGRADES permissions from intended `read-only` to `danger-full-access` — a security-critical semantic flip from the user's expressed intent to the polar opposite** — dogfooded 2026-04-18 on main HEAD `7859222` from `/tmp/cdVV`. Extends #86 (silent-drop) with the JSON5-partial-tolerance + alias-collapse angle. | `ROADMAP.md:L4124` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0296-hooks-configuration-schema-is-incompatib` | **`hooks` configuration schema is INCOMPATIBLE with Claude Code. claw-code expects `{"hooks": {"PreToolUse": [, ...]}}` — a flat array of command strings. Claude Code's schema is `{"hooks": {"PreToolUse": [{"matcher": "", "hooks": [{"type": "command", "command": "..."}]}]}}` — a matcher-keyed array of objects with nested command arrays. A user migrating their Claude Code `.claude.json` hooks block gets parse-fail: `field "hooks.PreToolUse" must be an array of strings, got an array (line 3)`. The error message is ALSO wrong — both schemas use arrays; the correct diagnosis is "array-of-objects where array-of-strings was expected." Separately, `claw --output-format json doctor` when failures present emits TWO concatenated JSON objects on stdout (`{kind:"doctor",...}` then `{type:"error",error:"doctor found failing checks"}`), breaking single-document parsing for any claw that does `json.load(stdout)`. Doctor output also has both `message` and `report` top-level fields containing identical prose — byte-duplicated** — dogfooded 2026-04-18 on main HEAD `b81e642` from `/tmp/cdWW`. | `ROADMAP.md:L4227` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0297-base-commit-accepts-any-string-as-its-va` | **`--base-commit` accepts ANY string as its value with zero validation — no SHA-format check, no `git cat-file -e` probe, no rejection of values that start with `--` or match known subcommand names. The parser at `main.rs:487` greedily takes `args[index+1]` no matter what. So `claw --base-commit doctor` silently uses the literal string `"doctor"` as the base commit, absorbs the subcommand, falls through to Prompt dispatch, emits stderr `"warning: worktree HEAD (...) does not match expected base commit (doctor). Session may run against a stale codebase."` (using the bogus value verbatim), AND burns billable LLM tokens on an empty prompt. Similarly `claw --base-commit --model sonnet status` takes `--model` as the base-commit value, swallowing the model flag. Separately: the stale-base check runs ONLY on the Prompt path; `claw --output-format json --base-commit status` or `doctor` emit NO stale_base field in the JSON surface, silently dropping the signal (plumbing gap adjacent to #100)** — dogfooded 2026-04-18 on main HEAD `d1608ae` from `/tmp/cdYY`. | `ROADMAP.md:L4346` / `roadmap_action` | `beta_adoption` | `stale_done` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | Marked done in roadmap but needs freshness re-verification before being used as release evidence. | | `CC2-RM-A0298-allowedtools-tool-name-normalization-is` | **`--allowedTools` tool name normalization is asymmetric: `normalize_tool_name` converts `-` → `_` and lowercases, but canonical names aren't normalized the same way, so tools with snake_case canonical (`read_file`) accept underscore + hyphen + lowercase variants (`read_file`, `READ_FILE`, `Read-File`, `read-file`, plus aliases `read`/`Read`), while tools with PascalCase canonical (`WebFetch`) REJECT snake_case variants (`web_fetch`, `web-fetch` both fail). A user or claw defensively writing `--allowedTools WebFetch,web_fetch` gets half the tools accepted and half rejected. The acceptance list mixes conventions: `bash`, `read_file`, `write_file` are snake_case; `WebFetch`, `WebSearch`, `TodoWrite`, `Skill`, `Agent` are PascalCase. Help doesn't explain which convention to use when. Separately: `--allowedTools` splits on BOTH commas AND whitespace (`Bash Read` parses as two tools), duplicate/case-variant tokens like `bash,Bash,BASH` are silently accepted with no dedup warning, and the allowed-tool set is NOT surfaced in `status` / `doctor` JSON output — a claw invoking with `--allowedTools` has no post-hoc way to verify what the runtime actually accepted** — dogfooded 2026-04-18 on main HEAD `2bf2a11` from `/tmp/cdZZ`. | `ROADMAP.md:L4433` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage`, `stable_alpha_contracts` | — | | `CC2-RM-A0299-model-accepts-any-string-with-zero-valid` | **`--model` accepts any string with zero validation — typos like `sonet` silently pass through to the API where they fail late with an opaque error; empty string `""` is silently accepted as a model name; `status` JSON shows the resolved model but not the user's raw input, so post-hoc debugging of "why did my model flag not work?" requires re-reading the process argv** — dogfooded 2026-04-18 on main HEAD `bb76ec9` from `/tmp/cdAA2`. | `ROADMAP.md:L4549` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0300-git-state-clean-is-emitted-by-both-statu` | **`git_state: "clean"` is emitted by both `status` and `doctor` JSON even when `in_git_repo: false` — a non-git directory reports the same sentinel as a git repo with no changes. `GitWorkspaceSummary::default()` returns all-zero fields; `is_clean()` checks `changed_files == 0` → true → `headline() = "clean"`. A claw checking `if git_state == "clean" then proceed` would proceed even in a non-git directory. Doctor correctly surfaces `in_git_repo: false` and `summary: "current directory is not inside a git project"`, but the `git_state` field contradicts this by claiming "clean." Separately, `claw init` creates a `.gitignore` file even in non-git directories — not harmful (ready for future `git init`) but misleading** — dogfooded 2026-04-18 on main HEAD `debbcbe` from `/tmp/cdBB2`. | `ROADMAP.md:L4625` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0301-config-env-hooks-model-plugins-ignores-t` | **`/config [env\|hooks\|model\|plugins]` ignores the section argument — all four subcommands return bit-identical output: the same config-file-list envelope `{kind:"config", files:[...], loaded_files, merged_keys, cwd}`. Help advertises "/config [env\|hooks\|model\|plugins] — Inspect Claude config files or merged sections [resume]" — implying section-specific output. A claw invoking `/config model` expecting the resolved model config gets the file-list envelope identical to `/config hooks`. The section argument is parsed and discarded** — dogfooded 2026-04-18 on main HEAD `b56841c` from `/tmp/cdFF2`. | `ROADMAP.md:L4693` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0302-claw-subcommand-json-and-claw-subcommand` | **`claw --json` and `claw

` silently fall through to LLM Prompt dispatch — every diagnostic verb (`doctor`, `status`, `sandbox`, `skills`, `version`, `help`) accepts the documented `--output-format json` global only BEFORE the subcommand. The natural shape `claw doctor --json` parses as: subcommand=`doctor` is consumed, then `--json` becomes prompt text, the parser dispatches to `CliAction::Prompt { prompt: "--json" }`, the prompt path demands Anthropic credentials, and a fresh box with no auth fails hard with exit=1. Same for `claw doctor --garbageflag`, `claw doctor garbage args here`, `claw status --json`, `claw skills --json`, etc. The text-mode form `claw doctor` works fine without auth (it's a pure local diagnostic), so this is a pure CLI-surface failure that breaks every observability tool that pipes JSON. README.md says "`claw doctor` should be your first health check" — but any claw, CI step, or monitoring tool that adds `--json` to that exact suggested command gets a credential-required error instead of structured output** — dogfooded 2026-04-20 on main HEAD `7370546` from `/tmp/claw-dogfood` (no `.git`, no `.claw.json`, all `ANTHROPIC_*` / `OPENAI_*` env vars unset via `env -i`). | `ROADMAP.md:L4737` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0303-closed-2026-04-21-claw-model-malformed-s` | **[CLOSED 2026-04-21]** **`claw --model ` (spaces, empty string, special chars, invalid provider/model syntax) silently falls through to API-layer cred error instead of rejecting at parse time** — dogfooded 2026-04-20 on main HEAD `d284ef7` from a fresh environment (no config, no auth). The `--model` flag accepts any string without syntactic validation: spaces (`claw --model "bad model"`), empty strings (`claw --model ""`), special characters (`claw --model "@invalid"`), non-existent provider/model combinations all parse successfully. The malformed model string then flows into the runtime's provider-detection layer, which silently accepts it as Anthropic fallback or passes it to an API layer that fails with `missing Anthropic credentials` (misdirection) rather than a clear "invalid model syntax" error at parse time. With API credentials configured, a malformed model string gets sent to the API, billing tokens against a request that should have failed client-side. | `ROADMAP.md:L4833` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0304-mcp-server-startup-blocks-credential-val` | **MCP server startup blocks credential validation — `claw ` with any `.claw.json` `mcpServers` entry awaits the MCP server's stdio handshake BEFORE checking whether the operator has Anthropic credentials. With no `ANTHROPIC_AUTH_TOKEN` / `ANTHROPIC_API_KEY` set and `mcpServers.everything = { command: "npx", args: ["-y", "@modelcontextprotocol/server-everything"] }` configured, the CLI hangs forever (verified via `timeout 30s` — still in MCP startup at 30s with three repeated `"Starting default (STDIO) server..."` lines), instead of fail-fasting with the same `missing Anthropic credentials` error that fires in milliseconds when no MCP is configured. A misconfigured-but-running MCP server (one that spawns successfully but never completes its `initialize` handshake) wedges every `claw ` invocation permanently. A misconfigured MCP server with a slow-but-eventually-succeeding init (npx download, container pull, network roundtrip) burns startup latency on every Prompt invocation regardless of whether the LLM call would even succeed. This is the runtime-side companion to #102's config-time MCP diagnostic gap: #102 says doctor doesn't surface MCP reachability; #129 says the Prompt path's reachability check is implicit, blocking, retried, and runs *before* the cheaper auth precondition that should run first** — dogfooded 2026-04-20 on main HEAD `d284ef7` from `/tmp/claw-mcp-test` with `env -i PATH=$PATH HOME=$HOME` (all auth env vars unset). | `ROADMAP.md:L4847` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0305-claw-export-output-path-filesystem-error` | **`claw export --output ` filesystem errors surface raw OS errno strings with zero context — no path that failed, no operation that failed (open/write/mkdir), no structured error kind, no actionable hint, and the `--output-format json` envelope flattens everything to `{"error":"","type":"error"}`. Five distinct filesystem failure modes all produce different raw errno strings but the same zero-context shape. The boilerplate `Run claw --help for usage` trailer is also misleading because these are filesystem errors, not usage errors** — dogfooded 2026-04-20 on main HEAD `d2a8341` from `/Users/yeongyu/clawd/claw-code/rust` (real session file present). | `ROADMAP.md:L4921` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0313-add-a-clioutputformat-json-if-compact-ar` | Add a `CliOutputFormat::Json if compact` arm (or merge compact flag into `run_prompt_json` as a parameter) that produces a JSON object with `message: ` and a `compact: true` marker. Tool-use fields remain present but empty arrays (consistent with compact semantics — tools ran but are not returned verbatim). | `ROADMAP.md:L5141` / `roadmap_action` | `beta_adoption` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-A0314-emit-a-warning-or-error-kind-flag-confli` | Emit a warning or `error.kind: "flag_conflict"` if conflicting flags are passed in a way that silently wins (or document the precedence explicitly in `--help`). | `ROADMAP.md:L5142` / `roadmap_action` | `beta_adoption` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-A0315-regression-tests-claw-compact-output-for` | Regression tests: `claw --compact --output-format json ` must produce valid JSON with at minimum `{message: "...", compact: true}`. | `ROADMAP.md:L5143` / `roadmap_action` | `beta_adoption` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-A0325-store-closure-state-in-a-shared-metadata` | Store closure state in a **shared metadata surface** (Discord message edit, ROADMAP inline, or compact JSON file) so next cycle can read it. | `ROADMAP.md:L5172` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | none | — | | `CC2-RM-A0392-where-the-binary-actually-ends-up-e-g-ru` | Where the binary actually ends up (e.g., `rust/target/debug/claw` vs. expecting it in `/usr/local/bin`) | `ROADMAP.md:L5927` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0393-how-to-verify-the-build-succeeded-e-g-cl` | How to verify the build succeeded (e.g., `claw --help`, `which claw`, `claw doctor`) | `ROADMAP.md:L5928` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0394-how-to-add-it-to-path-for-shell-integrat` | How to add it to PATH for shell integration (optional but common follow-up) | `ROADMAP.md:L5929` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0395-where-the-binary-lives-rust-target-debug` | **Where the binary lives:** `rust/target/debug/claw` (debug build) or `rust/target/release/claw` (release) | `ROADMAP.md:L5939` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0396-verify-it-works-run-rust-target-debug-cl` | **Verify it works:** Run `./rust/target/debug/claw --help` and `./rust/target/debug/claw doctor` | `ROADMAP.md:L5940` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0397-optional-add-to-path-three-approaches` | **Optional: Add to PATH** — three approaches: | `ROADMAP.md:L5941` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0398-windows-equivalent-point-to-rust-target` | **Windows equivalent:** Point to `rust\target\debug\claw.exe` and `cargo install --path .\rust` | `ROADMAP.md:L5945` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0399-detect-if-the-model-name-looks-like-it-b` | Detect if the model name looks like it belongs to a known provider (prefix `gpt-`, `openai/`, `qwen`, etc.) | `ROADMAP.md:L5969` / `roadmap_action` | `beta_adoption` | `open` | `provider_routing_contract_test` | `adoption_overlay_triage` | — | | `CC2-RM-A0400-if-it-does-check-if-that-provider-s-env` | If it does, check if that provider's env var is missing | `ROADMAP.md:L5970` / `roadmap_action` | `beta_adoption` | `open` | `provider_routing_contract_test` | `adoption_overlay_triage` | — | | `CC2-RM-A0401-append-a-hint-did-you-mean-inferred-pref` | Append a hint: "Did you mean \`{inferred_prefix}/{model}\`? (requires `{PROVIDER_KEY}` env var)" | `ROADMAP.md:L5971` / `roadmap_action` | `beta_adoption` | `open` | `provider_routing_contract_test` | `adoption_overlay_triage` | — | | `CC2-RM-A0402-what-each-does` | What each does | `ROADMAP.md:L5987` / `roadmap_action` | `beta_adoption` | `open` | `docs_snapshot_or_help_output_check` | `adoption_overlay_triage` | — | | `CC2-RM-A0403-how-to-use-it` | How to use it | `ROADMAP.md:L5988` / `roadmap_action` | `beta_adoption` | `open` | `docs_snapshot_or_help_output_check` | `adoption_overlay_triage` | — | | `CC2-RM-A0404-what-kind-of-input-it-expects` | What kind of input it expects | `ROADMAP.md:L5989` / `roadmap_action` | `beta_adoption` | `open` | `docs_snapshot_or_help_output_check` | `adoption_overlay_triage` | — | | `CC2-RM-A0405-when-to-use-it-vs-other-commands` | When to use it (vs. other commands) | `ROADMAP.md:L5990` / `roadmap_action` | `beta_adoption` | `open` | `docs_snapshot_or_help_output_check` | `adoption_overlay_triage` | — | | `CC2-RM-A0406-any-limitations-or-prerequisites` | Any limitations or prerequisites | `ROADMAP.md:L5991` / `roadmap_action` | `beta_adoption` | `open` | `docs_snapshot_or_help_output_check` | `adoption_overlay_triage` | — | | `CC2-RM-A0407-planning-reasoning-ultraplan-task` | **Planning & Reasoning** — `/ultraplan [task]` | `ROADMAP.md:L5996` / `roadmap_action` | `beta_adoption` | `open` | `docs_snapshot_or_help_output_check` | `adoption_overlay_triage` | — | | `CC2-RM-A0408-navigation-teleport-symbol-or-path` | **Navigation** — `/teleport ` | `ROADMAP.md:L6001` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0409-code-analysis-bughunter-scope` | **Code Analysis** — `/bughunter [scope]` | `ROADMAP.md:L6006` / `roadmap_action` | `beta_adoption` | `open` | `docs_snapshot_or_help_output_check` | `adoption_overlay_triage` | — | | `CC2-RM-A0413-add-compaction-occurred-bool-and-turns-d` | Add `compaction_occurred: bool` and `turns_dropped: int` to `TurnResult`. | `ROADMAP.md:L6083` / `roadmap_action` | `alpha_blocker` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-A0414-in-compact-messages-if-needed-return-boo` | In `compact_messages_if_needed`, return `(bool, int)` — whether compaction ran and how many turns were dropped. | `ROADMAP.md:L6084` / `roadmap_action` | `alpha_blocker` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-A0415-propagate-into-turnresult-in-submit-mess` | Propagate into `TurnResult` in `submit_message`. | `ROADMAP.md:L6085` / `roadmap_action` | `alpha_blocker` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-A0416-in-stream-submit-message-include-compact` | In `stream_submit_message`, include `compaction_occurred` and `turns_dropped` in the `message_stop` event. | `ROADMAP.md:L6086` / `roadmap_action` | `alpha_blocker` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-A0424-interactive-work-can-start-with-updater` | **Interactive work can start with updater/setup churn before the actual user task, blurring startup truth and first-action latency** — dogfooded 2026-04-19 from `clawcode-human`. Launching `omx` inside the claw-code worktree did not begin with the requested ROADMAP task; it first diverted through an update prompt (`Update available: v0.12.6 → v0.13.0. Update now? [Y/n]`), global install, full setup refresh, config rewrite/backups, notification/HUD setup, and a `Restart to use new code` notice before returning to the actual prompt. None of that was the operator’s requested work, but it consumed the critical startup window and mixed setup chatter with task-relevant execution. This creates a clawability gap: downstream observers cannot cleanly distinguish `startup succeeded and work began` from `startup mutated the environment and maybe changed the toolchain before work began`, and first-action latency gets polluted by maintenance side effects. **Required fix shape:** (a) make updater/setup detours a first-class startup phase with explicit classification (`startup.update_gate`, `startup.setup_refresh`) instead of letting them masquerade as normal task progress; (b) allow noninteractive or automation-oriented launches to suppress or defer update/setup churn until after the first user task/result boundary; (c) preserve a clean timestamped boundary between maintenance work and task work in lane events/status surfaces; (d) add regression coverage proving a prompt can start without forced updater/setup interposition when policy says "do work now." **Why this matters:** startup truth should reflect the user’s requested work, not hide it behind self-mutation and config churn that change latency, logs, and reproducibility before the first real action. Source: live dogfood session `clawcode-human` on 2026-04-19. | `ROADMAP.md:L6170` / `roadmap_action` | `alpha_blocker` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0429-npm-ci-can-report-a-clean-install-while` | **`npm ci` can report a clean install while leaving the JS extract build path non-buildable (false-green bootstrap)** — dogfooded 2026-04-19 from `dogfood-1776184671`. The lane explicitly checked that `node_modules/typescript` was missing, then ran `npm ci`, which succeeded (`added 3 packages`, `found 0 vulnerabilities`), but the subsequent build path still surfaced a missing/invalid TypeScript toolchain situation instead of a clearly ready extract CLI bootstrap. From the operator side this is a false-green signal: the canonical package-manager bootstrap step says success, yet the next immediate action is still not reliably build-ready. Whether the root cause is missing declaration in `package.json`, lockfile drift, wrong dependency bucket, or build contract mismatch, the clawability gap is the same — `npm ci` success is not a trustworthy readiness signal for the JS extract path. **Required fix shape:** (a) define the exact dependency contract for the extract build path so `npm ci` alone yields a buildable state, or else emit an explicit follow-up requirement if another step is mandatory; (b) add a readiness assertion after install (for example checking required toolchain/deps like `typescript`) so bootstrap can fail closed instead of greenwashing; (c) add regression coverage that a clean install on a fresh worktree reaches a buildable/help-capable extract CLI state; (d) surface a typed `bootstrap_false_green` / `deps_incomplete_after_install` class when install succeeds but required build deps are still absent. **Why this matters:** bootstrap steps must mean what they say; a green install that leaves the next command red burns operator trust and makes every later failure harder to localize. Source: live dogfood session `dogfood-1776184671` on 2026-04-19. | `ROADMAP.md:L6180` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0430-updater-says-restart-to-use-new-code-but` | **Updater says `Restart to use new code`, but the same interactive session continues immediately with ambiguous code provenance** — dogfooded 2026-04-19 from `clawcode-human`. After the `omx` updater ran and explicitly reported `[omx] Updated to v0.13.0. Restart to use new code.`, the same visible interactive session proceeded straight into the requested task prompt instead of forcing or clearly fencing the restart boundary. That creates a stale-binary truth gap: neither the operator nor downstream claws can tell whether the subsequent behavior is coming from the newly installed version, the pre-update in-memory process, or some mixed state where setup artifacts are refreshed but the active runtime is still old. **Required fix shape:** (a) when an update declares restart-required, surface that as a first-class blocked/degraded state (`update_applied_restart_pending`) instead of silently continuing as if task execution provenance were clean; (b) either force a real restart before accepting task prompts or stamp all subsequent events with the pre-restart runtime identity until restart happens; (c) expose version-before/version-after/runtime-active-version distinctly in status surfaces; (d) add regression coverage proving that post-update task work cannot masquerade as running on the fresh version when restart is still pending. **Why this matters:** after self-update, code provenance is the truth boundary; if the tool says "restart required" but still keeps working, every later success or failure becomes harder to attribute to the right build. Source: live dogfood session `clawcode-human` on 2026-04-19. | `ROADMAP.md:L6182` / `roadmap_action` | `alpha_blocker` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0434-task-start-transcript-leaks-internal-imp` | **Task-start transcript leaks internal implementation/config choreography (`HUD config`, `[tui]` ownership, section-left-untouched notes) instead of surfacing only operator-relevant state** — dogfooded 2026-04-19 from `clawcode-human`. The startup/update flow printed lines like `HUD config created (preset: focused).` and `Codex CLI >= 0.107.0 manages [tui]; OMX left that section untouched.` Those may be useful during installer development, but on a task-start surface they are low-level implementation chatter: they expose config ownership details and internal orchestration mechanics that are not the operator’s actual question (`can work start yet? what changed? what is blocked?`). **Required fix shape:** (a) separate installer/debug implementation detail logs from the operator-facing startup/task transcript; (b) summarize them into a higher-level state only when they materially affect readiness (for example `ui_config_deferred_to_host_cli`), otherwise suppress them in normal task launches; (c) provide a verbose/debug mode where maintainers can still inspect the raw choreography intentionally; (d) add regression coverage proving default task-start transcripts carry readiness/provenance/blocker facts, not installer internals. **Why this matters:** when internal config chatter and operational truth share the same transcript, claws have to reverse-engineer which lines matter; startup should communicate state, not make maintainers parse implementation archaeology every run. Source: live dogfood session `clawcode-human` on 2026-04-19. | `ROADMAP.md:L6190` / `roadmap_action` | `beta_adoption` | `deferred_with_rationale` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | Deferred by roadmap/approved plan until prerequisite contracts or post-2.0 research admission gates are satisfied. | | `CC2-RM-A0435-setup-scope-selection-defaults-to-user-g` | **Setup-scope selection defaults to user/global mutation during task startup, creating project-vs-global provenance ambiguity** — dogfooded 2026-04-19 from `clawcode-human`. The updater/setup flow prompted `Select setup scope:` and defaulted to `1) user (default)`, then continued with `Using setup scope: user` and `User scope leaves project AGENTS.md unchanged.` In a task-launch context inside a specific project worktree, this is a clawability gap: the default mutation target is the operator’s global `~/.codex` environment rather than the current project, so the startup path can change cross-project state before the task even begins. That makes it ambiguous whether later behavior comes from project-local config, user-global config, or some mixed overlay. **Required fix shape:** (a) make scope choice explicit and policy-driven in task/worktree launches instead of defaulting silently to user/global scope; (b) expose the active config/provenance stack clearly after setup (`project`, `user`, or layered`) so later behavior can be attributed correctly; (c) allow automation/worktree mode to prefer or require project-local scope by default; (d) add regression coverage proving a bare Enter at setup-scope prompt does not unexpectedly widen mutation scope beyond the current project unless policy explicitly allows it. **Why this matters:** when startup mutates global state from inside a project task flow, reproducibility and blame assignment get muddy fast; scope is part of runtime truth and needs to be explicit, not an installer default hidden in startup chatter. Source: live dogfood session `clawcode-human` on 2026-04-19. | `ROADMAP.md:L6192` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0436-installer-refresh-count-dumps-updated-un` | **Installer refresh-count dumps (`updated=`, `unchanged=`, `skipped=`...) are mixed into task-start transcript even when the operator only needs readiness truth** — dogfooded 2026-04-19 from `clawcode-human`. The startup flow printed a full `Setup refresh summary:` block with counters for prompts, skills, native agents, AGENTS.md, and config. Those counters may be useful for installer debugging, but in a task-launch transcript they are mostly bookkeeping noise: they consume operator attention without answering the task-critical questions (`did startup finish? what mutated? is restart pending? can work begin?`). **Required fix shape:** (a) move raw refresh-count summaries behind verbose/debug output or a separate installer report surface; (b) collapse default task-start output to a higher-level mutation summary only when something materially changed; (c) mark detailed installer accounting as non-operational metadata when it must remain available; (d) add regression coverage proving default task-start transcripts do not include raw installer counter dumps in automation/worktree contexts. **Why this matters:** startup transcripts should optimize for execution truth, not make claws parse installer bookkeeping while they are trying to classify blockers and begin work. Source: live dogfood session `clawcode-human` on 2026-04-19. | `ROADMAP.md:L6194` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0437-post-setup-onboarding-checklists-next-st` | **Post-setup onboarding checklists (`Next steps:`) are injected into an already-active task-launch flow, re-framing the operator as a first-time user** — dogfooded 2026-04-19 from `clawcode-human`. After the updater/setup churn, the transcript printed a `Next steps:` block (`Start Codex CLI in your project directory`, `Browse skills with /skills`, `The AGENTS.md orchestration brain is loaded automatically`, etc.) immediately before the actual task prompt. In a live project-task session this is a clawability gap: the tool already knows it is inside a project directory and about to execute a concrete prompt, yet it still emits a generic first-run onboarding checklist that competes with the real work context. **Required fix shape:** (a) suppress or relocate first-run/onboarding guidance when the launch context is an active task/worktree session rather than a fresh human install flow; (b) surface onboarding guidance only when the runtime has evidence the user actually needs it; (c) keep detailed onboarding available via explicit help/doctor/docs surfaces instead of the main task-start transcript; (d) add regression coverage proving task-launch transcripts do not append generic `Next steps` blocks once the system has already crossed into execution mode. **Why this matters:** startup truth should narrow toward the requested task, not widen back out into beginner-mode guidance after the operator has already initiated concrete work. Source: live dogfood session `clawcode-human` on 2026-04-19. | `ROADMAP.md:L6196` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0439-the-full-startup-banner-still-occupies-p` | **The full startup banner still occupies prime task-start transcript space even in an execution-bound session** — dogfooded 2026-04-19 from `clawcode-human`. Before any real work state was surfaced, the session rendered the large `OpenAI Codex (v0.120.0)` banner block with model and directory chrome. A banner is fine for an interactive REPL landing page, but in a task-launch/worktree context it is another large piece of non-operational framing that pushes actual readiness/provenance/blocker signals further down the transcript. This is distinct from the old piped-stdin bug (#48): here the issue is not wrong mode selection, but that once execution mode is already known, the banner still claims the most visible part of the startup surface. **Required fix shape:** (a) suppress or collapse the full banner in task/worktree/automation launches once the system knows it is entering execution immediately; (b) if some context is still useful, reduce it to one compact machine-readable/header line rather than a decorative block; (c) keep the full banner for explicit interactive landing contexts only; (d) add regression coverage proving execution-bound launches surface readiness/provenance first, not the decorative REPL chrome. **Why this matters:** startup transcript real estate is scarce; when the banner consumes the top of the screen, claws and operators pay a tax just to get to the lines that actually determine whether work can proceed. Source: live dogfood session `clawcode-human` on 2026-04-19. | `ROADMAP.md:L6200` / `roadmap_action` | `beta_adoption` | `open` | `provider_routing_contract_test` | none | — | | `CC2-RM-A0440-model-directory-context-is-only-exposed` | **Model/directory context is only exposed as decorative banner chrome instead of a stable structured startup state surface** — dogfooded 2026-04-19 from `clawcode-human`. The session showed useful facts like `model: gpt-5.4 high` and `directory: /mnt/offloading/Workspace/claw-code`, but only inside the decorative startup banner block. That means the context is visually present for a human yet not surfaced as a clearly structured, low-noise state line/event that claws can reliably consume once banners are suppressed or compacted. **Required fix shape:** (a) expose active model, cwd/project root, and similar startup context as a compact structured state surface independent of the decorative banner; (b) keep the data available even when banners are hidden in task/worktree/automation mode; (c) ensure downstream status/lane events can consume the same fields without scraping presentation text; (d) add regression coverage proving model/cwd context survives banner suppression and remains visible in a machine-usable form. **Why this matters:** some startup context is genuinely important, but if it only exists as banner chrome then operators must choose between noisy presentation and losing state; the truth should live in structured state, not decorative formatting. Source: live dogfood session `clawcode-human` on 2026-04-19. | `ROADMAP.md:L6202` / `roadmap_action` | `alpha_blocker` | `open` | `provider_routing_contract_test` | none | — | | `CC2-RM-A0442-task-start-transcript-still-tells-the-op` | **Task-start transcript still tells the operator to `Run "omx doctor" to verify installation` even after the session has already crossed into active execution flow** — dogfooded 2026-04-19 from `clawcode-human`. The updater/setup path printed `Setup complete! Run "omx doctor" to verify installation.` immediately before continuing into the live project task prompt. In a first-run install flow that guidance is fine; in an already-active task/worktree launch it is a diversionary fork that reintroduces setup validation as if the operator were still onboarding instead of already trying to execute concrete work. **Required fix shape:** (a) suppress doctor/verification nudges once the runtime knows it is in an execution-bound task launch rather than a fresh install session; (b) if verification remains relevant, encode it as a structured optional recommendation separate from the main transcript, not a blocking-looking imperative sentence; (c) keep `doctor` guidance available on explicit help/status/install surfaces; (d) add regression coverage proving task-launch transcripts do not instruct users to re-verify installation mid-launch unless a real installation-health blocker is present. **Why this matters:** task-start truth should converge on the requested work; reintroducing `run doctor` guidance at the last moment makes the runtime look uncertain about whether startup is complete and distracts both humans and claws from execution. Source: live dogfood session `clawcode-human` on 2026-04-19. | `ROADMAP.md:L6206` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0443-capability-detection-chatter-omx-team-ap` | **Capability-detection chatter (`omx team api command detected`, `CLI-first interop ready`) leaks into task-start transcript instead of being summarized as stable readiness state** — dogfooded 2026-04-19 from `clawcode-human`. During setup the transcript printed lines like `omx team api command detected (CLI-first interop ready)`. That may be useful during installer debugging, but in a task-launch transcript it is low-level capability-probing chatter: it tells the operator how the installer discovered a capability instead of simply surfacing the resulting readiness fact, if that fact even matters to the current task. **Required fix shape:** (a) hide raw capability-detection chatter from the default task-start transcript; (b) if the result matters, summarize it as a stable named readiness capability or degraded state rather than a probe log; (c) keep raw probe details in verbose/debug output only; (d) add regression coverage proving startup surfaces do not emit ephemeral detection strings in execution-bound launches. **Why this matters:** claws need canonical state, not probe narration; when startup transcripts describe how readiness was detected rather than the readiness outcome itself, downstream consumers have to reverse-engineer transient strings instead of reading stable state. Source: live dogfood session `clawcode-human` on 2026-04-19. | `ROADMAP.md:L6208` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage`, `stable_alpha_contracts` | — | | `CC2-RM-A0444-backup-side-effects-are-reported-only-as` | **Backup side effects are reported only as installer bookkeeping (`backed_up=...`) inside startup chatter instead of as an explicit auditable mutation surface** — dogfooded 2026-04-19 from `clawcode-human`. The setup refresh summary included counts like `config: updated=1, unchanged=1, backed_up=1`, which means startup created backup artifacts or backup state as part of the run. That is a real side effect, but it is only exposed as a counter inside noisy installer bookkeeping. In a task-launch context this is a clawability gap: backups are mutation/audit facts, not just installer trivia, and they should be easy to attribute and inspect without scraping summary counts. **Required fix shape:** (a) surface backup creation as an explicit structured mutation event (what was backed up, where, why) rather than only a counter; (b) keep backup/audit details in a dedicated mutation report separate from the main task-start transcript; (c) allow operators to inspect or suppress routine backup chatter without losing auditability; (d) add regression coverage proving backup side effects remain attributable even when installer counter dumps are hidden. **Why this matters:** when startup mutates disk state, the audit trail should be crisp and intentional; hiding backups inside generic `updated/unchanged/backed_up` counters makes real side effects look like disposable noise. Source: live dogfood session `clawcode-human` on 2026-04-19. | `ROADMAP.md:L6210` / `roadmap_action` | `alpha_blocker` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0445-installer-mutation-summaries-are-aggrega` | **Installer mutation summaries are aggregate-only (`updated=`, `skipped=`, `removed=` counts) and hide which concrete artifacts changed** — dogfooded 2026-04-19 from `clawcode-human`. The `Setup refresh summary` reported counters for prompts, skills, native agents, AGENTS.md, and config, but not the identities of the files/items that were actually updated, skipped, backed up, or removed. That creates an item-level opacity gap: even when the operator accepts that startup did maintenance, they still cannot tell what concretely changed without diffing the filesystem or rerunning in a more verbose mode. **Required fix shape:** (a) expose a structured per-item mutation report (or stable pointer to one) alongside the aggregate counts; (b) let the default task-start transcript stay quiet while still preserving an auditable item list off the main path; (c) distinguish no-op categories from real mutated identities so downstream claws can tell whether a count reflects actual risk; (d) add regression coverage proving installer summaries remain attributable at the item level even when only compact high-level output is shown by default. **Why this matters:** counts alone are not enough for trust — when startup says it changed "some" prompts/skills/config, claws need a stable way to know exactly which artifacts moved without scraping or manual archaeology. Source: live dogfood session `clawcode-human` on 2026-04-19. | `ROADMAP.md:L6212` / `roadmap_action` | `alpha_blocker` | `open` | `targeted_regression_or_acceptance_test_required` | `adoption_overlay_triage` | — | | `CC2-RM-A0446-installer-summary-status-labels-unchange` | **Installer summary status labels (`unchanged`, `skipped`, `removed`, `updated`) are not semantically crisp enough for downstream interpretation** — dogfooded 2026-04-19 from `clawcode-human`. The startup transcript emitted category counters like `updated=0, unchanged=20, skipped=13, removed=0`, but the semantics of those buckets are not self-evident in a machine-usable way: does `skipped` mean policy-blocked, out-of-scope, user-owned, version-pinned, or transient failure? Does `unchanged` mean verified identical, or merely not touched? That ambiguity makes the counts hard to trust even before item-level detail is considered. **Required fix shape:** (a) define stable semantics for each installer outcome bucket and expose them in machine-readable form; (b) avoid overloading `skipped`/`unchanged` for multiple reasons — use typed subreasons when needed; (c) ensure compact summaries can still distinguish harmless no-op from policy suppression or deferred action; (d) add regression coverage proving outcome labels remain stable and unambiguous across installer changes. **Why this matters:** if the status words themselves are fuzzy, aggregate counts become misleading telemetry — claws cannot tell whether startup was clean, partially suppressed, or silently deferred without reverse-engineering installer internals. Source: live dogfood session `clawcode-human` on 2026-04-19. | `ROADMAP.md:L6214` / `roadmap_action` | `alpha_blocker` | `deferred_with_rationale` | `targeted_regression_or_acceptance_test_required` | `adoption_overlay_triage` | Deferred by roadmap/approved plan until prerequisite contracts or post-2.0 research admission gates are satisfied. | | `CC2-RM-A0447-task-startup-degrades-into-an-interactiv` | **Task startup degrades into an interactive installer questionnaire (update? scope?) instead of a deterministic launch contract** — dogfooded 2026-04-19 from `clawcode-human`. Before any project work began, the launch path required answering multiple setup questions (`Update now? [Y/n]`, `Select setup scope: ... Scope [1-2]`) and only then continued into updater/setup churn and the eventual task prompt. This is a distinct clawability gap from the individual prompt defaults: even if each default were safer, the overall startup contract is still questionnaire-driven rather than deterministic. A task/worktree launch should be able to evaluate policy and either proceed or surface a typed blocked state, not stop for a mini installer interview. **Required fix shape:** (a) replace startup questionnaires with explicit policy-driven decisions and typed states (`update_required`, `scope_resolution_required`, etc.); (b) reserve interactive questioning for explicit install/setup commands, not ordinary task-launch paths; (c) provide a noninteractive/automation-safe mode where launch decisions are resolved from config/policy alone; (d) add regression coverage proving execution-bound launches either start deterministically or fail with structured blockers instead of pausing for ad-hoc Q&A. **Why this matters:** questionnaires destroy launch determinism; claws cannot reliably classify or replay startup when the runtime keeps asking humans to steer installer choices in the middle of task execution. Source: live dogfood session `clawcode-human` on 2026-04-19. | `ROADMAP.md:L6216` / `roadmap_action` | `alpha_blocker` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0448-startup-success-confirmations-collapse-i` | **Startup success confirmations collapse into repeated generic `Done.` lines with weak object identity** — dogfooded 2026-04-19 from `clawcode-human`. Across the setup flow, multiple steps ended with bare confirmations like `Done.` after labels such as `Creating directories`, `Configuring notification hook`, and similar installer actions. That is a small but real event/log opacity gap: once the transcript gets longer, a claw or human skimming later cannot tell what exact artifact or side effect each `Done.` line is attesting to without walking back through the surrounding prose. **Required fix shape:** (a) emit success confirmations with stable object identity (`directories_created`, `notification_hook_configured`, etc.) instead of bare `Done.`; (b) keep human-friendly summaries if desired, but pair them with structured outcome ids; (c) make compact task-start transcripts collapse repetitive successful maintenance lines unless they materially affect readiness; (d) add regression coverage proving startup confirmations remain attributable even after transcript compaction or banner suppression. **Why this matters:** opaque success acknowledgments are the mirror image of opaque failures — if the runtime cannot say what specifically succeeded, later audits and parsers have to reconstruct state from surrounding noise instead of reading a stable event surface. Source: live dogfood session `clawcode-human` on 2026-04-19. | `ROADMAP.md:L6218` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0451-task-start-transcript-uses-internal-anth` | **Task-start transcript uses internal/anthropomorphic claims (`The AGENTS.md orchestration brain is loaded automatically`) instead of verifiable readiness facts** — dogfooded 2026-04-19 from `clawcode-human`. The `Next steps:` block included `The AGENTS.md orchestration brain is loaded automatically`, which is not a crisp operational fact but an internal/marketing-ish claim about the system’s conceptual model. In a task-launch transcript this is a clawability gap: the line sounds important, but it does not say what was actually loaded, how to verify it, or whether it affects current readiness. **Required fix shape:** (a) replace anthropomorphic/internal claims in startup/task surfaces with verifiable state facts (`AGENTS.md loaded: yes/no`, `policy file path`, `load source`, etc.) when such state matters; (b) keep conceptual/product-language copy out of operational transcripts or confine it to docs/onboarding surfaces; (c) make every startup claim testable against observable runtime state; (d) add regression coverage proving task-launch transcripts surface factual state instead of unverifiable product prose. **Why this matters:** claws can only reason over checkable truth; when startup surfaces speak in metaphor or internal branding, downstream consumers cannot distinguish “important state” from “colorful copy,” and auditability collapses. Source: live dogfood session `clawcode-human` on 2026-04-19. | `ROADMAP.md:L6224` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0453-startup-and-task-execution-share-one-und` | **Startup and task execution share one undifferentiated transcript stream; there is no explicit handoff boundary from setup/maintenance into real work** — dogfooded 2026-04-19 from `clawcode-human`. The same surface flowed from updater prompts, setup-scope questions, installer progress, summaries, tips, and onboarding text directly into the actual task prompt with no clean phase break that said “startup is over; execution has begun.” This is distinct from #232’s missing final verdict: even if a verdict existed, claws still need a visible handoff boundary so later lines can be interpreted as task execution rather than residual setup chatter. **Required fix shape:** (a) emit an explicit phase transition when control passes from startup/setup into execution (`startup_finished`, `execution_begin`, or equivalent); (b) keep startup/maintenance events logically grouped and separate from task-turn events in lane history; (c) make the handoff boundary machine-readable so downstream consumers can split logs without heuristic scraping; (d) add regression coverage proving execution-bound launches expose one clear startup→execution boundary even when startup performs updates or setup work first. **Why this matters:** without a crisp handoff, every later line is ambiguous — claws cannot tell whether they are reading installer residue or real task progress, so monitoring, replay, and blame assignment all stay fuzzy. Source: live dogfood session `clawcode-human` on 2026-04-19. | `ROADMAP.md:L6228` / `roadmap_action` | `alpha_blocker` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0454-startup-phases-expose-almost-no-elapsed` | **Startup phases expose almost no elapsed-time signal, so operators cannot tell which pre-task step actually consumed launch latency** — dogfooded 2026-04-19 from `clawcode-human`. The launch path spent real time in update prompting, setup scope selection, setup refresh, interop checks, config work, and onboarding chatter before real work began, but the transcript gave almost no per-phase timing or duration summary. That makes startup friction hard to localize: claws can see that startup felt long, but not whether the time went to update/install, config rewrite, capability probing, restart-pending drift, or UI chatter. **Required fix shape:** (a) attach elapsed timing to major startup phases and the final startup verdict; (b) expose a compact duration breakdown for update/setup/probe/handoff phases in machine-readable form; (c) keep detailed timings available even when the visible transcript is compacted; (d) add regression coverage proving execution-bound launches can report where pre-task latency was spent without log scraping. **Why this matters:** if startup latency is opaque, every slowdown becomes anecdotal. Claws need timing attribution to decide whether to suppress noise, precompute setup, change policy defaults, or fix a real blocker. Source: live dogfood session `clawcode-human` on 2026-04-19. | `ROADMAP.md:L6230` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0455-startup-decisions-have-no-policy-source` | **Startup decisions have no policy-source attribution, so prompts and mutations appear arbitrary (`why am I being asked to update/scope-switch/force-maintain?`)** — dogfooded 2026-04-19 from `clawcode-human`. The launch path asked about updates, defaulted to user scope, entered force mode, and emitted various setup actions, but the transcript never said which config, policy, default rule, or caller context caused those decisions. The operator can see *what* happened, but not *why this branch was chosen*. That creates a policy-opacity gap on top of the noise: even if the prompts were fewer, claws still could not audit whether a choice came from explicit config, a default fallback, current repo context, or installer hardcode. **Required fix shape:** (a) attach policy-source metadata to startup decisions (`source=config`, `source=default`, `source=interactive_override`, `source=repo_policy`, etc.); (b) surface compact reason/source tags for major mutations and prompts without dumping raw config internals; (c) make the final startup verdict include the key policy inputs that shaped launch; (d) add regression coverage proving update/scope/force-mode decisions remain attributable after transcript compaction. **Why this matters:** startup trust is not just about the visible action — it is about whether claws can trace that action back to an intentional policy source instead of treating it like arbitrary runtime whim. Source: live dogfood session `clawcode-human` on 2026-04-19. | `ROADMAP.md:L6232` / `roadmap_action` | `alpha_blocker` | `open` | `targeted_regression_or_acceptance_test_required` | `adoption_overlay_triage` | — | | `CC2-RM-A0456-setup-refresh-has-no-drift-trigger-expla` | **Setup refresh has no drift/trigger explanation, so repeated pre-task maintenance looks unconditional even when it may be idempotent or unnecessary** — dogfooded 2026-04-19 from `clawcode-human`. The launch path ran a broad setup refresh and printed counts (`updated`, `unchanged`, `skipped`, `backed_up`), but never explained why this refresh was needed on this run: stale install detected, version mismatch, missing files, policy-enforced reapply, or just unconditional startup behavior. That leaves a critical ambiguity: the operator can see maintenance happened, but cannot tell whether it was justified by detected drift or simply rerun every time. **Required fix shape:** (a) emit a compact trigger reason for startup maintenance (`version_drift`, `missing_artifacts`, `policy_reapply`, `first_run`, `forced_refresh`, etc.); (b) include whether the refresh was necessary, opportunistic, or unconditional; (c) surface the trigger reason in the final startup verdict and structured mutation report; (d) add regression coverage proving repeated launches can distinguish "no drift, no refresh needed" from "refresh intentionally rerun because X." **Why this matters:** without drift/trigger attribution, startup maintenance feels arbitrary and expensive — claws cannot decide whether to cache, suppress, precompute, or eliminate the work because they do not know why it fired. Source: live dogfood session `clawcode-human` on 2026-04-19. | `ROADMAP.md:L6234` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0457-repeated-startup-maintenance-exposes-no` | **Repeated startup maintenance exposes no idempotence/fast-path signal, so claws cannot tell whether the runtime short-circuited safely or re-executed the whole setup pipeline** — dogfooded 2026-04-19 from `clawcode-human`. The setup flow reported lots of `unchanged` counts, but the transcript never made clear whether that meant a true cheap no-op fast path, a full scan/rewrite pass that happened to find no diffs, or a partially skipped installer run. This is distinct from #236’s missing trigger reason: even if a refresh was justified, the operator still cannot tell whether repeated launches are paying the full maintenance cost or benefiting from a stable idempotent shortcut. **Required fix shape:** (a) expose whether startup maintenance took a `fast_path`, `full_scan_noop`, `partial_reapply`, or `mutating_refresh` route; (b) include compact machine-readable idempotence metadata in startup verdicts and maintenance reports; (c) separate “no changes needed” from “work rerun but produced no diffs” so downstream systems can reason about startup cost; (d) add regression coverage proving repeated launches report a stable idempotence mode rather than forcing consumers to infer it from counters. **Why this matters:** idempotence is part of startup truth — without it, claws cannot optimize repeated launches or explain why startup still feels heavy even when nothing changed on disk. Source: live dogfood session `clawcode-human` on 2026-04-19. | `ROADMAP.md:L6236` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0458-startup-prompts-do-not-preserve-answer-p` | **Startup prompts do not preserve answer provenance (`explicit user choice` vs `accepted default`), so later audit cannot tell who actually chose update/scope branches** — dogfooded 2026-04-19 from `clawcode-human`. The launch flow showed questionnaire-style prompts such as `Update now? [Y/n]` and `Scope [1-2] (default: 1):`, but the resulting transcript only reflected the chosen path (`Using setup scope: user`, updater executed) without clearly recording whether those outcomes came from explicit operator input, default acceptance, automation, or some other implicit branch. That is a real audit gap: even if startup decisions become policy-driven later, the current surface cannot reconstruct whether a risky branch was intentionally chosen or simply happened because Enter accepted the default. **Required fix shape:** (a) record answer provenance for startup decisions (`explicit_input`, `default_accepted`, `policy_auto`, `preconfigured`) in machine-readable form; (b) surface compact provenance tags for consequential branches like update/scope/force mode; (c) thread answer provenance into the final startup verdict and audit trail; (d) add regression coverage proving startup decisions remain attributable after transcript compaction and banner suppression. **Why this matters:** when a launch mutates the environment, it is not enough to know what branch happened — claws need to know whether a human actually chose it or whether the system silently fell through to a default. Source: live dogfood session `clawcode-human` on 2026-04-19. | `ROADMAP.md:L6238` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | none | — | | `CC2-RM-A0459-startup-transcript-has-no-severity-impor` | **Startup transcript has no severity/importance layering, so blockers, mutations, info, and tips all compete at the same visual priority** — dogfooded 2026-04-19 from `clawcode-human`. In the same startup surface, lines about restart-required state, updater actions, setup mutations, promo copy, onboarding guidance, tips, and installer bookkeeping all appeared as ordinary transcript entries with no stable severity cues. That means the operator has to manually decide which lines are blockers, which are side-effect audit facts, and which are safely ignorable. **Required fix shape:** (a) assign stable severity/importance classes to startup events (`blocker`, `mutation`, `readiness`, `info`, `hint`, etc.); (b) make the final startup verdict and compact transcript prioritize blocker/readiness signals above all other classes; (c) let downstream consumers filter or collapse lower-severity startup chatter without losing auditability; (d) add regression coverage proving startup surfaces preserve severity ordering even when verbose output is enabled. **Why this matters:** even perfect wording is not enough if every line has equal visual weight — claws need severity structure so the startup surface can be parsed by priority instead of by brute-force reading order. Source: live dogfood session `clawcode-human` on 2026-04-19. | `ROADMAP.md:L6240` / `roadmap_action` | `alpha_blocker` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0460-startup-mixes-persistent-mutations-and-e` | **Startup mixes persistent mutations and ephemeral observations in the same plain-text channel, so operators cannot quickly tell what changed on disk/config versus what was merely detected** — dogfooded 2026-04-19 from `clawcode-human`. The transcript interleaved observations like capability detection, version notices, and tips with persistent side effects like config refreshes, backups, hook setup, and possible global-scope mutation, but rendered them all as ordinary prose lines. That makes audit and recovery harder: a claw reading back later cannot immediately separate "this was observed" from "this changed machine state." **Required fix shape:** (a) classify startup events by persistence class (`observation`, `decision`, `mutation`, `audit_artifact`) in addition to severity; (b) provide a compact mutation-only view or structured ledger for the startup run; (c) keep ephemeral observations available without letting them obscure which events actually changed durable state; (d) add regression coverage proving startup surfaces preserve the distinction between detected facts and persisted side effects. **Why this matters:** when startup changes the machine, claws need a fast path to the durable side effects. Without a persistence distinction, every audit becomes transcript archaeology instead of a clean state-change review. Source: live dogfood session `clawcode-human` on 2026-04-19. | `ROADMAP.md:L6242` / `roadmap_action` | `alpha_blocker` | `open` | `install_matrix_or_cross_platform_smoke` | none | — | | `CC2-RM-A0461-startup-emits-many-lines-but-no-stable-s` | **Startup emits many lines but no stable startup-attempt/run id, so downstream claws cannot reliably group which prompts, mutations, and verdict belong to the same launch** — dogfooded 2026-04-19 from `clawcode-human`. The startup flow included update prompting, scope selection, setup steps, summaries, restart-required messaging, onboarding spillover, and then task execution, but none of those lines carried a shared startup correlation id. That makes analysis brittle once multiple launches or retries exist nearby: parsers have to infer grouping by proximity instead of knowing "these 23 lines belong to startup attempt X." **Required fix shape:** (a) assign a stable startup run id/correlation id at launch begin; (b) attach it to startup prompts, mutations, summaries, verdicts, and the startup→execution handoff; (c) preserve the id in compact transcript mode and structured lane/status events; (d) add regression coverage proving concurrent/retried launches remain separable without heuristic log scraping. **Why this matters:** without correlation identity, even improved startup events stay hard to stitch together across retries, compaction, and neighboring sessions. A canonical run id turns noisy startup text into a coherent attributable execution record. Source: live dogfood session `clawcode-human` on 2026-04-19. | `ROADMAP.md:L6244` / `roadmap_action` | `alpha_blocker` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-A0462-startup-events-have-no-stable-sequence-i` | **Startup events have no stable sequence index inside a run, so downstream claws cannot reconstruct exact event order without trusting transcript layout** — dogfooded 2026-04-19 from `clawcode-human`. Even within one startup attempt, the flow mixed prompts, setup phases, summaries, restart-required signals, onboarding spillover, and the execution handoff without any monotonic event numbering or ordered machine-readable sequence marker. This is adjacent to #241 but distinct: a run id can tell you *which* launch a line belongs to, but not the exact canonical order of steps once output is compacted, reflowed, partially hidden, or merged into other status surfaces. **Required fix shape:** (a) assign a monotonic startup event sequence index within each startup run; (b) carry that sequence through structured startup events, summaries, and the final verdict/handoff; (c) preserve sequence identity when rendering compact human transcripts so downstream consumers can recover true order without scraping visual layout; (d) add regression coverage proving startup ordering remains reconstructable across retries, compaction, and alternate renderers. **Why this matters:** grouping without ordering is only half the audit trail. Claws need canonical event order to tell whether a blocker preceded a mutation, whether a verdict came before or after restart-required, and whether setup really finished before execution began. Source: live dogfood session `clawcode-human` on 2026-04-19. | `ROADMAP.md:L6246` / `roadmap_action` | `alpha_blocker` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-A0463-startup-prompts-ask-for-consent-without` | **Startup prompts ask for consent without previewing the concrete mutation plan, so `yes/no` decisions are under-informed** — dogfooded 2026-04-19 from `clawcode-human`. The launch path asked questions like `Update now? [Y/n]` and then proceeded into global install, setup refresh, config rewrites/backups, notification/HUD changes, possible force-mode maintenance, and restart-required state — but the prompt itself did not preview that concrete mutation set before asking for consent. This is a distinct clawability gap from policy/source attribution: even if the decision source were known, the operator still was not shown a compact “what will change if you say yes” plan before choosing. **Required fix shape:** (a) provide a concise mutation preview before consequential startup prompts (`will update package`, `may rewrite config`, `may create backups`, `restart required`, scope target, etc.); (b) make the preview machine-readable so automation and logs can capture the intended mutation set before execution; (c) allow policy-driven noninteractive mode to log the same preview as a preflight plan instead of asking interactively; (d) add regression coverage proving startup consent points expose their concrete planned side effects before mutation begins. **Why this matters:** consent without a change preview is barely better than blind defaulting — claws need to know not just that a branch exists, but what durable consequences that branch will have before they approve or auto-resolve it. Source: live dogfood session `clawcode-human` on 2026-04-19. | `ROADMAP.md:L6248` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0468-non-interactive-prompt-mode-can-exceed-c` | **Non-interactive prompt mode can exceed caller timeouts with no in-band startup/API phase event or partial status artifact** — dogfooded 2026-04-29 from live tmux session `claw-code-issue-247-human-fresh-run` after the owner explicitly asked gaebal-gajae to make a fresh session and use `claw-code` directly. The actual `./rust/target/debug/claw` binary was launched via `clawhip tmux new` on current main. `claw doctor --output-format json` and `claw status --output-format json` both succeeded and reported auth/config/workspace ok, but minimal non-interactive prompt calls (`timeout 120 ./rust/target/debug/claw --output-format json --dangerously-skip-permissions "echo hello"` and `timeout 120 ./rust/target/debug/claw --output-format json prompt "Reply with just the word hello"`) both timed out from the outer harness after roughly 150s with only `Command exceeded timeout` visible. There was no machine-readable `api_request_started`, `waiting_for_first_token`, provider/model/base-url identity, retry count, or partial status file/event that would let clawhip distinguish slow provider, network stall, auth/OAuth drift, stream parser hang, or prompt-mode bug. **Required fix shape:** (a) emit structured non-interactive lifecycle events for `startup_ok`, `api_request_started`, `first_byte/first_token`, retry/backoff, and terminal `timeout_or_stall` states; (b) include provider/model/base URL source and auth source category without leaking secrets; (c) support a CLI/request timeout flag or env override that returns a typed JSON error before the outer orchestrator kills the process; (d) write/emit a final partial status artifact on timeout so lane monitors do not have to infer state from a dead process. **Why this matters:** non-interactive prompt mode is the automation path; if it can hang past the caller's timeout while doctor/status are green, claws lose the ability to tell whether startup, auth, transport, provider latency, or stream consumption failed. Source: live session `claw-code-issue-247-human-fresh-run` on 2026-04-29. | `ROADMAP.md:L6258` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0473-help-output-format-json-returns-valid-js` | **`help --output-format json` returns valid JSON but hides the actual help schema inside one prose `message` string** — dogfooded 2026-04-29 on current `origin/main` / workspace HEAD `d607ff36`. Running `./rust/target/debug/claw help --output-format json` produces parseable JSON, but the object only exposes top-level keys like `kind` and `message`; all command names, global flags, slash-command metadata, aliases, resume-safety, output-format support, auth/preflight notes, and descriptions are flattened into one human-oriented prose blob. That technically satisfies “valid JSON” while still forcing automation to scrape the same help text humans read, making `/issue`, `/help`, and resume-safety contracts opaque to claws. **Required fix shape:** (a) keep `message` as the compact human-rendered help summary, but add a documented structured schema with `schema` / `schema_version` fields; (b) expose first-class arrays/objects such as `commands[]`, `options[]`, and `slash_commands[]` with stable fields including `name`, `aliases`, `description`, `args`, `output_formats_supported`, `resume_safe`, `interactive_only`, and `creates_external_side_effects`; (c) include auth and creation preflight metadata where relevant, especially for GitHub/issue flows (`auth_preflight`, `creation_unavailable`, `gh_cli_authenticated`, `github_token_present`, or equivalent non-secret state); (d) make `/issue`, `/help`, aliases, and resume-dispatch safety machine-readable from the JSON payload instead of recoverable only by parsing prose markers; (e) add regression coverage proving `help --output-format json` is valid JSON and that `/issue`, `/help`, resume-safe vs interactive-only slash commands, aliases, descriptions, supported output formats, and side-effect/auth-preflight fields are present and internally consistent. **Why this matters:** help JSON is the discoverability surface automation uses before invoking commands. If it is just prose wrapped in JSON, claws cannot safely decide whether a command can run non-interactively, resume from a saved session, create external GitHub side effects, or requires auth/preflight without brittle text scraping. Source: gaebal-gajae dogfood follow-up from current main `d607ff36`; observed `./rust/target/debug/claw help --output-format json` returning valid JSON with only `{kind,message}` at the top level while the actionable command schema remained buried in `message`. | `ROADMAP.md:L6267` / `roadmap_action` | `beta_adoption` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-A0474-status-output-format-json-underreports-a` | **`status --output-format json` underreports active workspace pane inventory when one tmux session has multiple panes/processes in the same project** — dogfooded 2026-04-29 on current `origin/main` / workspace HEAD `b90875fa` while responding to the claw-code dogfood nudge. The active OMX session `claw-code-issue-326-dogfood-pinpoint` was running in `/mnt/offloading/Workspace/claw-code` with two panes: `%9384` (`cmd=node`, active pane) and `%9385` (`cmd=node`, inactive sidecar pane). `tmux list-panes -a -F '#{session_name}:#{window_index}.#{pane_index} #{pane_id} pid=#{pane_pid} cmd=#{pane_current_command} cwd=#{pane_current_path} active=#{pane_active}'` showed both panes in the same session/workspace, but `./rust/target/debug/claw status --output-format json` collapsed the workspace lifecycle to a single object: `session_lifecycle.kind = "running_process"`, `pane_id = "%9384"`, `pane_command = "node"`, with no `panes[]`, process count, sidecar/secondary-pane inventory, or ambiguity marker. A downstream claw reading only status JSON would believe there is exactly one live process for that workspace even though the control plane has multiple panes in the same task session. **Required fix shape:** (a) expose a structured active-session inventory in `status --output-format json`, including `panes[]` or `processes[]` with pane id, command, cwd, active flag, and session/window identity for all matching workspace panes; (b) keep the compact `session_lifecycle` summary, but add an explicit `pane_count` / `has_sidecar_panes` / `inventory_truncated` signal so summaries cannot masquerade as complete truth; (c) define how to classify primary vs sidecar/inactive panes without losing them, and make the chosen primary pane provenance visible; (d) add regression coverage for a tmux session with two panes in one workspace proving status JSON reports both panes or marks the inventory as partial. **Why this matters:** status JSON is the machine-readable lane truth surface. If it reports only the primary pane while hiding secondary panes, clawhip and other claws can miss sidecar workers, blocked helpers, stale subprocesses, or duplicated control-plane processes and make bad restart/cleanup/routing decisions from an undercounted session snapshot. Source: gaebal-gajae dogfood session `claw-code-issue-326-dogfood-pinpoint`; observed `claw status --output-format json` returning only `%9384` while `tmux list-panes` showed `%9384` and `%9385` in the same claw-code workspace. | `ROADMAP.md:L6269` / `roadmap_action` | `alpha_blocker` | `open` | `install_matrix_or_cross_platform_smoke` | none | — | | `CC2-RM-A0489-top-level-plugins-list-output-format-jso` | **Top-level `plugins list --output-format json` returns plugin inventory only as a prose `message` string instead of structured `plugins[]` entries** — dogfooded 2026-04-29 for the 21:00 nudge on current `origin/main` / rebuilt `./rust/target/debug/claw` with embedded `git_sha` `cca6f682`. Running `./rust/target/debug/claw plugins list --output-format json` repeatedly returned valid stdout JSON with `{"action":"list","kind":"plugin","message":"Plugins\n example-bundled v0.1.0 disabled\n sample-hooks v0.1.0 disabled","reload_runtime":false,"target":null}` and no stderr. The actual plugin names, versions, and enabled/disabled states are present only inside the human-formatted `message` table; there is no `plugins[]` array, no per-plugin `name`, `version`, `enabled`, `source`, `load_error`, or lifecycle/action metadata. This is distinct from #325's broad help JSON opacity and the config/MCP/agent items: the affected surface is plugin lifecycle inventory, where automation needs a structured list before enabling, disabling, updating, or uninstalling plugins. **Required fix shape:** (a) add `plugins[]` with stable per-plugin fields such as `name`, `version`, `enabled`, `source`, `configured`, `load_status`, and optional `error`; (b) keep `message` only as a human summary, not the sole inventory payload; (c) expose counts and truncation metadata if the list can be large; (d) add regression coverage proving `plugins list --output-format json` can be parsed without scraping the prose message and that disabled/enabled state survives as booleans/enums. **Why this matters:** plugin lifecycle management is a control-plane path. If the JSON inventory is just a text table, claws must scrape spacing-sensitive prose before deciding whether a plugin is installed, disabled, broken, or safe to mutate. Source: gaebal-gajae dogfood follow-up for the 21:00 nudge on rebuilt `./rust/target/debug/claw` `cca6f682`. | `ROADMAP.md:L6290` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0490-top-level-plugins-show-name-output-forma` | **Top-level `plugins show --output-format json` returns success-shaped JSON for an unsupported plugin action instead of a typed unsupported-action error** — dogfooded 2026-04-29 for the 21:30 nudge on current `origin/main` / rebuilt `./rust/target/debug/claw` with embedded `git_sha` `a2a38df9`. After rebuilding and verifying the binary provenance, repeated bounded runs of `./rust/target/debug/claw plugins show does-not-exist --output-format json` returned stdout JSON with `{"action":"show","kind":"plugin","message":"Unknown /plugins action 'show'. Use list, install, enable, disable, uninstall, or update.","reload_runtime":false,"target":"does-not-exist"}` and no stderr. The command therefore reports the requested unsupported action as the top-level `action:"show"` and exits successfully while hiding the failure class inside a human `message`; it does not provide `status:"unsupported_action"`, `code:"plugin_action_unsupported"`, or structured `supported_actions[]`. This is distinct from #348's prose-only plugin inventory schema: #348 covers `plugins list` payload shape, while this pinpoint covers unsupported plugin action classification and recovery metadata. **Required fix shape:** (a) return a typed stdout JSON error or explicit non-ok status for unsupported plugin actions, with `requested_action`, `supported_actions`, and `target` fields; (b) do not label the primary `action` as the unsupported requested verb unless a separate `status`/`code` makes the failure unambiguous; (c) keep the human message optional and avoid making it the only way to detect the unsupported action; (d) add regression coverage proving `plugins show foo --output-format json` is machine-classifiable as unsupported without scraping prose. **Why this matters:** plugin lifecycle automation follows action/status fields. If an unsupported mutation/inspection verb returns success-shaped JSON and only says "Unknown" in prose, claws can treat a failed preflight as a valid plugin show result and continue toward unsafe lifecycle actions. Source: gaebal-gajae dogfood follow-up for the 21:30 nudge on rebuilt `./rust/target/debug/claw` `a2a38df9`; invalid hang PR #2885 was closed after repeated bounded repros returned stdout JSON. | `ROADMAP.md:L6291` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0491-top-level-plugins-enable-missing-plugin` | **Top-level `plugins enable --output-format json` hangs with zero stdout/stderr instead of returning a typed plugin-not-found or unsupported-target response** — dogfooded 2026-04-29 for the 22:00 nudge on current `origin/main` / rebuilt `./rust/target/debug/claw` with embedded `git_sha` `ee44ff98`. After rebuilding and verifying the binary provenance, repeated bounded runs of `timeout 8 ./rust/target/debug/claw plugins enable does-not-exist --output-format json` exited `124` with `stdout=0` and `stderr=0`; a third sample was still stuck until killed. In the same rebuilt binary, `plugins list --output-format json` returned promptly with the known plugin inventory payload, proving the plugin top-level surface is reachable and narrowing the hang to missing-plugin lifecycle mutation. This is distinct from #348's prose-only list inventory and #349's unsupported `plugins show` success-shaped JSON: #350 covers a supported lifecycle verb (`enable`) against an absent target, where the CLI should be able to fail fast before any plugin runtime work. **Required fix shape:** (a) validate the target plugin against the discovered/configured inventory before invoking enable-side effects; (b) return bounded stdout JSON such as `kind:"plugin"`, `action:"enable"`, `status:"not_found"` or `kind:"error"`, `code:"plugin_not_found"`, `plugin`, and optional `available_plugins[]`; (c) add internal timeout/diagnostic metadata for plugin lifecycle operations so registry or hook stalls do not produce silent zero-byte hangs; (d) add regression coverage proving `plugins enable does-not-exist --output-format json` returns a typed JSON outcome within a deterministic budget and does not mutate plugin state. **Why this matters:** enable/disable/update/uninstall are destructive control-plane actions. A missing or stale plugin name must fail safely and machine-readably; otherwise claws cannot preflight plugin lifecycle operations, distinguish typo from loader deadlock, or recover without killing a hung process. Source: gaebal-gajae dogfood follow-up for the 22:00 nudge on rebuilt `./rust/target/debug/claw` `ee44ff98`. | `ROADMAP.md:L6292` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0492-top-level-plugins-disable-missing-plugin` | **Top-level `plugins disable --output-format json` sends the JSON error envelope to stderr only, leaving stdout empty** — dogfooded 2026-04-29 for the 22:30 nudge on current `origin/main` / rebuilt `./rust/target/debug/claw` with embedded `git_sha` `0f9e8915`. After rebuilding and verifying the binary provenance, repeated bounded runs of `timeout 8 ./rust/target/debug/claw plugins disable does-not-exist --output-format json` exited `1` with `stdout=0` and `stderr=113`; stderr contained JSON (`{"error":"plugin `does-not-exist` is not installed or discoverable","hint":null,"kind":"unknown","type":"error"}`), but stdout was empty. In the same rebuilt binary, `plugins list --output-format json` returned stdout JSON promptly with the known plugin inventory payload, proving the plugin command surface is reachable. This is distinct from #350's missing-target `plugins enable` zero-byte timeout: the disable path fails fast, but its JSON-mode error envelope is routed to stderr and uses generic `kind:"unknown"`/`type:"error"` instead of a plugin-specific stdout outcome. **Required fix shape:** (a) define and consistently document whether JSON mode emits machine-readable envelopes on stdout, stderr, or both for nonzero exits; (b) return a plugin-specific typed error with `kind:"plugin"` or `domain:"plugin"`, `action:"disable"`, `status:"not_found"` or `code:"plugin_not_found"`, `plugin`, and optional `available_plugins[]`; (c) keep stdout/stderr placement consistent across plugin lifecycle verbs so callers do not need per-action stream heuristics; (d) add regression coverage proving `plugins disable does-not-exist --output-format json` produces a typed plugin-not-found JSON contract on the documented stream. **Why this matters:** disable is a recovery/control-plane operation. A stale plugin name should be a structured, domain-specific not-found result on a predictable stream; otherwise claws that read stdout JSON for normal responses and stderr for human diagnostics must special-case this lifecycle failure. Source: gaebal-gajae dogfood follow-up for the 22:30 nudge on rebuilt `./rust/target/debug/claw` `0f9e8915`; invalid hang PR #2891 was closed after repeated bounded repros returned exit 1 with JSON on stderr. | `ROADMAP.md:L6293` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0493-top-level-plugins-update-missing-plugin` | **Top-level `plugins update --output-format json` sends a generic JSON error envelope to stderr only, leaving stdout empty** — dogfooded 2026-04-29 for the 23:00 nudge on current `origin/main` / rebuilt `./rust/target/debug/claw` with embedded `git_sha` `5eb1d7d8`. After rebuilding and verifying the binary provenance, repeated bounded runs of `timeout 8 ./rust/target/debug/claw plugins update does-not-exist --output-format json` exited `1` with `stdout=0` and `stderr=97`; stderr contained JSON (`{"error":"plugin `does-not-exist` is not installed","hint":null,"kind":"unknown","type":"error"}`), but stdout was empty. In the same rebuilt binary, `plugins list --output-format json` returned stdout JSON promptly with the known plugin inventory payload. This is distinct from #350's missing-target `plugins enable` zero-byte timeout and parallel to #351's `plugins disable` stderr-only JSON envelope: update fails fast, but the JSON-mode error lives on stderr only and uses generic `kind:"unknown"`/`type:"error"` instead of a plugin-specific not-found contract. **Required fix shape:** (a) define and consistently document stdout/stderr placement for JSON-mode lifecycle errors; (b) return a plugin-specific typed error with `kind:"plugin"` or `domain:"plugin"`, `action:"update"`, `status:"not_found"` or `code:"plugin_not_found"`, `plugin`, and optional `available_plugins[]`; (c) share missing-target error-envelope behavior across disable/update/uninstall and reconcile it with enable's timeout path; (d) add regression coverage proving `plugins update does-not-exist --output-format json` produces a typed plugin-not-found JSON contract on the documented stream. **Why this matters:** update is a maintenance/control-plane operation often run in automation. A stale plugin name should produce a predictable, domain-specific not-found result, not require callers to special-case stderr-only generic error envelopes after explicitly requesting JSON. Source: gaebal-gajae dogfood follow-up for the 23:00 nudge on rebuilt `./rust/target/debug/claw` `5eb1d7d8`; invalid hang PR #2894 was closed after repeated bounded repros returned exit 1 with JSON on stderr. | `ROADMAP.md:L6294` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0494-top-level-plugins-uninstall-missing-plug` | **Top-level `plugins uninstall --output-format json` sends a generic JSON error envelope to stderr only, leaving stdout empty** — dogfooded 2026-04-29 for the 23:30 nudge on current `origin/main` / rebuilt `./rust/target/debug/claw` with embedded `git_sha` `6f92e54d`. After rebuilding and verifying the binary provenance, repeated bounded runs of `timeout 8 ./rust/target/debug/claw plugins uninstall does-not-exist --output-format json` exited `1` with `stdout=0` and `stderr=97`; stderr contained JSON (`{"error":"plugin `does-not-exist` is not installed","hint":null,"kind":"unknown","type":"error"}`), but stdout was empty. In the same rebuilt binary, `plugins list --output-format json` returned stdout JSON promptly with the known plugin inventory payload. This is distinct from #350's missing-target `plugins enable` zero-byte timeout and parallel to #351/#352 for disable/update: uninstall fails fast, but the JSON-mode error lives on stderr only and uses generic `kind:"unknown"`/`type:"error"` instead of a plugin-specific not-found contract. **Required fix shape:** (a) define and consistently document stdout/stderr placement for JSON-mode lifecycle errors; (b) return a plugin-specific typed error with `kind:"plugin"` or `domain:"plugin"`, `action:"uninstall"`, `status:"not_found"` or `code:"plugin_not_found"`, `plugin`, and optional `available_plugins[]`; (c) share missing-target error-envelope behavior across disable/update/uninstall and reconcile it with enable's timeout path; (d) add regression coverage proving `plugins uninstall does-not-exist --output-format json` produces a typed plugin-not-found JSON contract on the documented stream. **Why this matters:** uninstall is the most destructive plugin lifecycle action. A stale plugin name should produce a predictable, domain-specific not-found result before cleanup hooks or loader work, not require callers to special-case stderr-only generic error envelopes after explicitly requesting JSON. Source: gaebal-gajae dogfood follow-up for the 23:30 nudge on rebuilt `./rust/target/debug/claw` `6f92e54d`; invalid hang PR #2897 was closed after repeated bounded repros returned exit 1 with JSON on stderr. | `ROADMAP.md:L6295` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0499-top-level-cost-help-output-format-json-h` | **Top-level `cost --help --output-format json` hangs with zero stdout/stderr instead of returning bounded command help JSON** — dogfooded 2026-04-30 for the 02:00 nudge on current `origin/main` / rebuilt `./rust/target/debug/claw` with embedded `git_sha` `d95b230c`. After rebuilding and verifying the binary provenance, repeated bounded runs of `timeout 8 ./rust/target/debug/claw cost --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 the JSON output path are reachable; the hang is specific to the cost help path, though other help surfaces have separate known JSON contract issues (#356/#357). **Required fix shape:** (a) make `cost --help --output-format json` return static/bounded stdout JSON with `kind:"help"` or `kind:"cost"`, `action:"help"`, usage, options, examples, supported output formats, and related slash/direct commands; (b) ensure help rendering does not initialize slow cost/session/accounting providers; (c) if any dynamic provider is accidentally consulted, return a typed JSON timeout/unavailable error instead of hanging; (d) add regression coverage proving cost help in JSON mode returns within a deterministic budget. **Why this matters:** cost/tokens surfaces are commonly consumed by automation for budgeting. If even cost help can hang silently, claws cannot discover cost command semantics or present safe budget diagnostics before running potentially slow accounting paths. Source: gaebal-gajae dogfood follow-up for the 02:00 nudge on rebuilt `./rust/target/debug/claw` `d95b230c`. | `ROADMAP.md:L6300` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0500-top-level-tokens-help-output-format-json` | **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`. | `ROADMAP.md:L6301` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0501-top-level-cache-help-output-format-json` | **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`. | `ROADMAP.md:L6302` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0511-plugins-list-output-format-json-returns` | **`plugins list --output-format json` returns the mutation response shape with a prose `message` table instead of a structured `plugins:[]` array — `name`, `version`, `status`, `source` are embedded in `message` prose only** — dogfooded 2026-04-30 by Jobdori on `e939777f`. Running `claw plugins list --output-format json` returns `{"action":"list","kind":"plugin","message":"Plugins\n example-bundled v0.1.0 disabled\n sample-hooks v0.1.0 disabled","reload_runtime":false,"target":null}`. This is the same four-key response envelope used by `plugins enable` and `plugins disable` mutation commands, not a list envelope. The `message` field contains the full rendered prose table (plugin name, version, and status as whitespace-aligned columns), but no `plugins` array with structured per-entry objects. `target` is `null` because no specific plugin was targeted. The `reload_runtime:false` field is meaningless for a read-only list operation. **This is distinct from ROADMAP #411** which covers the mutation commands' own missing `changed`/`previous_status`/`version`/`source` fields — #416 targets the list command's structural mismatch: it uses the mutation envelope entirely instead of emitting a dedicated list schema. **Required fix shape:** (a) emit a distinct `{kind:"plugin_list", plugins:[{name, version, status, source, path?, description?}], count}` envelope for the `list` action; (b) omit `action`, `reload_runtime`, and `target` from list responses (mutation-only fields); (c) the `message` field should be absent or optional and must not be the sole machine-readable inventory surface; (d) add regression coverage proving `plugins list --output-format json` populates a `plugins` array with at least `name`, `version`, and `status` fields for each installed plugin. **Why this matters:** automation that calls `plugins list --output-format json` to discover installed plugin inventory receives only a whitespace-aligned prose table in a string field, with `reload_runtime:false` and `target:null` as the only other machine-readable signals — identical noise to what a failed enable command returns. Source: Jobdori live dogfood, `e939777f`, 2026-04-30. | `ROADMAP.md:L6330` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0514-plugins-help-output-format-json-returns` | **`plugins help --output-format json` returns the mutation response shape (`message`, `reload_runtime`, `target`) instead of the help envelope (`action:"help"`, `kind`, `unexpected`, `usage`) that `mcp help`, `agents help`, and `skills help` all use — schema drift within the same command family** — dogfooded 2026-05-01 by Jobdori on `e939777f`. Running `claw plugins help --output-format json` returns `{"action":"help","kind":"plugin","message":"Unknown /plugins action 'help'. Use list, install, enable, disable, uninstall, or update.","reload_runtime":false,"target":null}`. By contrast, `claw mcp help --output-format json`, `claw agents help --output-format json`, and `claw skills help --output-format json` all return a help envelope: `{"action":"help","kind":"","unexpected":null,"usage":{"direct_cli":"...","slash_command":"...","sources":[...]}}`. The `plugins` subgroup has not adopted the help envelope schema used by all sibling subgroups. Instead it uses the mutation response shape (`message`, `reload_runtime`, `target`) with an error string in `message` that calls `help` an "unknown action." Automation that checks `usage.direct_cli` to discover plugin commands gets a `TypeError` (key not found) on the plugins help path while succeeding on all sibling subgroups. **Required fix shape:** (a) make `plugins help` return the same help envelope as `mcp help`/`agents help`/`skills help`: `{action:"help", kind:"plugin", unexpected:null, usage:{direct_cli:"claw plugins [list\|enable\|disable\|install\|uninstall\|update\|help]", slash_command:"/plugins [...]", sources:[...]}`; (b) drop `reload_runtime` and `target` from help responses for all plugin subcommands; (c) add regression coverage proving `plugins help --output-format json` contains a `usage.direct_cli` field matching the same envelope shape as `mcp help`/`agents help`/`skills help`; (d) audit all subgroup `help` handlers for the same mutation-envelope contamination. **Why this matters:** help discovery is the bootstrap surface for automation. If `plugins help --output-format json` returns a mutation envelope with an error message instead of a usage envelope, automated schema discovery fails silently for the entire plugins subgroup while working for every other subgroup. Source: Jobdori live dogfood, `e939777f`, 2026-05-01. | `ROADMAP.md:L6339` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0518-model-rejects-bare-canonical-anthropic-m` | **`--model` rejects bare canonical Anthropic model names (`claude-opus-4-7`, `claude-opus-4-6`, `claude-sonnet-4-6`) as `invalid_model_syntax` — only short aliases (`opus`, `sonnet`, `haiku`) and full prefixed form (`anthropic/claude-opus-4-7`) work; sibling: error message stale-suggests `claude-opus-4-6` not `4-7`** — dogfooded 2026-05-11 by Jobdori on `6c0c305a` in response to Clawhip pinpoint nudge at `1503230194889134103`. Reproduction: `claw --model claude-opus-4-7 status --output-format json` → `{"error":"invalid model syntax: 'claude-opus-4-7'. Expected provider/model (e.g., anthropic/claude-opus-4-6) or known alias (opus, sonnet, haiku)","kind":"invalid_model_syntax"}`. Same for `claude-opus-4-6`, `claude-sonnet-4-6`. Forcing `--model anthropic/claude-opus-4-7` works (`model:"anthropic/claude-opus-4-7"`, `model_source:"flag"`). Three problems compounded: (a) Anthropic-canonical model names without provider prefix are rejected even though the `claude-` prefix unambiguously identifies the provider; (b) the error suggests `anthropic/claude-opus-4-6` as the example — `4-7` shipped 2026-04-16 and is the current production Anthropic frontier model, the suggestion is one model behind; (c) the alias list `opus, sonnet, haiku` doesn't disambiguate version (which `opus` does the alias resolve to — `opus-4-6` or `opus-4-7`?). **Required fix shape:** (a) accept bare `claude-*` and `gpt-*` model names as canonical-named-without-prefix and route via name-prefix detection (already implemented for prefix-routed mode); (b) update the example in `invalid_model_syntax` error to current frontier (`anthropic/claude-opus-4-7`); (c) document or expose `opus` → exact-version mapping in the error message and in `claw doctor`/`status` output (`model_alias_resolved_to: "claude-opus-4-7"`); (d) regression test: `claw --model claude-opus-4-7 status --output-format json` returns `model_source:"flag"`, not `kind:"invalid_model_syntax"`. **Sibling bug observed in same probe:** `enabledPlugins` deprecation warning repeats 3 times in stderr for the same `~/.claw/settings.json` load — config file is being loaded/parsed 3 times during a single `status` invocation. **Why this matters:** every Anthropic doc, every CCAPI route, every internal tooling references models by their bare canonical name (`claude-opus-4-7`). Forcing the `anthropic/` prefix breaks copy-paste from Anthropic's own examples and adds a redundant token to every invocation. The stale `4-6` suggestion in the error message actively misdirects users away from the current model. Source: Jobdori live dogfood, `6c0c305a`, 2026-05-11. | `ROADMAP.md:L6351` / `roadmap_action` | `beta_adoption` | `stale_done` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | Marked done in roadmap but needs freshness re-verification before being used as release evidence. | | `CC2-RM-A0521-subcommand-help-paths-resume-session-com` | **Subcommand `--help` paths (`resume`, `session`, `compact`) hit the auth gate and trigger config validation before returning static help — `claw resume --help` with no credentials returns `missing_credentials` error instead of help text** — dogfooded 2026-05-11 by Jobdori on `1fecdf09` in response to Clawhip pinpoint nudge at `1503252843669491892`. Reproduction (no env vars, isolated `CLAW_CONFIG_HOME`): `claw resume --help` returns `{"error":"missing Anthropic credentials; export ANTHROPIC_AUTH_TOKEN or ANTHROPIC_API_KEY..."}` instead of usage text. Same for `claw session --help`, `claw compact --help`. By contrast, `claw prompt --help` and `claw --help` (top-level) return proper usage text without auth. Even worse: with a broken `.claw.json` discovered up the parent directory tree (e.g., `mcpServers.missing-command: missing string field command`), the subcommand `--help` paths fail with `[error-kind: unknown]` from config validation — config load is happening before `--help` is parsed. **Sibling exit-code bug:** `claw resume --help --output-format json` returns `kind:"missing_credentials"` but exits **0** (the exit-code parity bug from #422 reproduces on this path too — only `cli_parse` exits 1 consistently). **Sibling: `claw resume ` should be local-only** but also hits `missing_credentials` — `resume` of a session that doesn't exist on disk should return `kind:"session_not_found"` from a local lookup, not require API credentials. Same class as ROADMAP #357 (session list requires creds) and #369 (session help/fork require credentials) — now confirmed for `resume`. **Required fix shape:** (a) `--help` MUST short-circuit before any auth check, config load, or session resolution — emit static usage text from a compiled-in string table, no I/O; (b) `resume ` must check the local session store first; if the id is absent on disk, emit `kind:"session_not_found"` with `sessions_dir` field; only require auth when resuming a known-on-disk session that requires re-establishing API context; (c) ensure exit code 1 for all error envelopes including `missing_credentials` returned from a `--help` path that should never have reached the auth gate; (d) regression test: with empty `CLAW_CONFIG_HOME` and no env vars, every `claw --help` returns usage text on stdout, exit 0, no `kind:*_error` envelope. **Why this matters:** `--help` is the universal CLI discovery primitive. Failing `--help` because of missing API credentials or broken config files makes claw undiscoverable to users debugging an already-broken setup. Cross-references #357 (session list), #369 (session help/fork), #422 (exit code parity), #108 (subcommand fallthrough). Source: Jobdori live dogfood, `1fecdf09`, 2026-05-11. | `ROADMAP.md:L6360` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | none | — | | `CC2-RM-A0522-default-permission-mode-is-danger-full-a` | **Default `permission_mode` is `danger-full-access` — claw runs with FULL filesystem + network + tool access out of the box, with no opt-in flag and no warning from `doctor`** — dogfooded 2026-05-11 by Jobdori on `72048449` in response to Clawhip pinpoint nudge at `1503260393622212628`. Reproduction (no env vars, isolated `CLAW_CONFIG_HOME`, no config files, no CLI flags): `claw status --output-format json` returns `permission_mode:"danger-full-access"` as the default. The three supported modes per the validator error message are `read-only`, `workspace-write`, `danger-full-access` — and `danger-full-access` is chosen with zero user opt-in. `claw doctor --output-format json` produces a `sandbox` check with `status:"warn", summary:"sandbox was requested but is not currently active"` (because macOS lacks Linux `unshare`), but **emits no warning, info, or summary about the permission_mode itself being danger-full-access**. There is no `permissions` check in `doctor` output at all. **Required fix shape:** (a) change default `permission_mode` to `workspace-write` (safe-by-default: filesystem write limited to cwd, network limited to LLM endpoints, no arbitrary command exec); (b) require explicit `--permission-mode danger-full-access` or `--dangerously-skip-permissions` to opt into full access; (c) add a `permissions` check to `doctor --output-format json` that emits `status:"warn"` when `permission_mode == "danger-full-access"` without explicit source (flag/env/config), with details like `mode:"danger-full-access", source:"default", message:"running with full access without explicit opt-in"`; (d) document the three modes and the default in USAGE.md with one-paragraph descriptions of what each mode allows. **Sibling typed-error bug:** `claw --permission-mode bogus-mode status --output-format json` returns `kind:"unknown"` instead of `kind:"invalid_permission_mode"` — same catch-all problem as #424, #426. **Sibling flag-name asymmetry:** `--dangerously-skip-permissions` works but `--skip-permissions` (Claude Code's flag) returns `kind:"cli_parse"` `unknown option`. Users migrating from Claude Code lose the short flag name. **Why this matters:** every other security-conscious CLI (Docker, kubectl, terraform) requires explicit opt-in for dangerous modes. Defaulting to `danger-full-access` is a footgun for first-time users who pipe `curl install.sh \| sh` and immediately get a tool with full filesystem write and arbitrary command exec. The doctor surface is the only diagnostic users consult before trusting the tool, and it stays silent about the most permissive setting. Cross-references #50, #87, #91, #94, #97, #101, #106, #115, #123 (permission-audit sweep) — those all cover permission *rule* and *list* surfaces; #428 covers the *mode default* itself. Source: Jobdori live dogfood, `72048449`, 2026-05-11. | `ROADMAP.md:L6363` / `roadmap_action` | `alpha_blocker` | `open` | `targeted_regression_or_acceptance_test_required` | `adoption_overlay_triage` | — | | `CC2-RM-A0524-dump-manifests-is-documented-as-emit-eve` | **`dump-manifests` is documented as "emit every skill/agent/tool manifest the resolver would load for the current cwd" but actually requires the upstream Claude Code TypeScript source files (`src/commands.ts`, `src/tools.ts`, `src/entrypoints/cli.tsx`) — the command is unusable for any user who installed claw without cloning the original Claude Code repo** — dogfooded 2026-05-11 by Jobdori on `075c2144` in response to Clawhip pinpoint nudge at `1503275502046023690`. Reproduction: `claw dump-manifests --output-format json` returns `{"error":"Manifest source files are missing.","hint":"repo root: /private/tmp/claw-dog-0530\n missing: src/commands.ts, src/tools.ts, src/entrypoints/cli.tsx\n Hint: set CLAUDE_CODE_UPSTREAM=/path/to/upstream or pass \`claw dump-manifests --manifests-dir /path/to/upstream\`.","kind":"missing_manifests"}`. The fresh-main worktree at `/private/tmp/claw-dog-0530` does not contain these TypeScript files because the Rust port doesn't include the upstream TS source. The `--help` text says the command works against "the current cwd" but in practice it requires `CLAUDE_CODE_UPSTREAM=` pointing at an unshipped TS source tree. **Three sibling problems compounded:** (a) **derivative-work disclosure leak**: the error message exposes that `claw-code` is a port of Claude Code (`CLAUDE_CODE_UPSTREAM` env var name) — even if true, surfacing this in a casual diagnostic message couples user-facing behavior to upstream provenance details. (b) **kind drift**: `claw dump-manifests --manifests-dir /tmp/nonexistent --output-format json` returns `kind:"unknown"`, while `claw dump-manifests` (no override) returns `kind:"missing_manifests"`. Same root cause (no usable upstream), two different `kind` discriminators — automation cannot switch on a single error type. (c) **export-positional-arg silently dropped**: probed in the same run — `claw export ` ignores the path and returns `kind:"no_managed_sessions"` regardless of what positional arg was passed. The `--help` advertises `[PATH]` as the output-file destination but the path is discarded before validation, indistinguishable from invocation with no args. **Required fix shape:** (a) make `dump-manifests` emit the manifests claw-code itself ships with (Rust-resolver-discovered skills/agents/tools), independent of any upstream TS source — that matches the `--help` description; (b) if upstream-comparison is genuinely needed for parity work, move it to a separate command like `parity dump-upstream-manifests` and remove the upstream dependency from `dump-manifests`; (c) standardize on one error `kind` for the manifest-missing failure mode (`missing_manifests` is more descriptive than `unknown`); (d) `claw export ` must validate the path positional arg before the session-discovery check, so users see `kind:"invalid_output_path"` (or similar) when the path is malformed instead of always seeing `kind:"no_managed_sessions"`. **Why this matters:** `dump-manifests` is the inventory surface a downstream automation lane would call to learn what claw can do in the current workspace. If it's broken without upstream TS source, downstream lanes can't introspect — they have to fall back to `agents list`/`skills list`/`mcp list` separately and re-aggregate. Cross-references #422 (kind:unknown for unknown_subcommand), #423 (kind:unknown for missing_argument), #428 (kind:unknown for invalid_permission_mode) — `kind:"unknown"` keeps appearing as the catch-all for surfaces that should have typed kinds. Source: Jobdori live dogfood, `075c2144`, 2026-05-11. | `ROADMAP.md:L6369` / `roadmap_action` | `alpha_blocker` | `open` | `targeted_regression_or_acceptance_test_required` | `adoption_overlay_triage` | — | | `CC2-RM-A0525-skills-uninstall-name-requires-anthropic` | **`skills uninstall ` requires Anthropic credentials despite being a local filesystem operation — `claw skills uninstall nonexistent-skill-xyz --output-format json` returns `kind:"missing_credentials"` instead of resolving locally that the skill doesn't exist** — dogfooded 2026-05-11 by Jobdori on `328fd114` in response to Clawhip pinpoint nudge at `1503275502046023690` (sibling probe to #430). Reproduction (no creds, isolated `CLAW_CONFIG_HOME`): `claw skills uninstall nonexistent-skill-xyz --output-format json` returns `{"error":"missing Anthropic credentials; export ANTHROPIC_AUTH_TOKEN or ANTHROPIC_API_KEY...","kind":"missing_credentials"}`. Uninstalling a skill is a pure local filesystem operation: read the skills directory, find the named skill, remove its files. There is no semantic reason to require API credentials. Same class of bug as #357 (`session list` requires creds), #369 (`session help/fork` require creds), and #427 (`resume ` requires creds). **Three sibling findings in same probe:** (a) `claw skills install ` returns `{"error":"No such file or directory (os error 2)","kind":"unknown"}` — leaks raw OS error string with no hint about expected install source format (path vs name vs URL?), and the catch-all `kind:"unknown"` again instead of typed `kind:"skill_install_source_not_found"`. (b) `claw skills install` (no args) returns `action:"help"` with `unexpected:"install"` — but `install` IS a documented subcommand. The handler treats it as "unknown action" instead of "missing required argument". Should emit `kind:"missing_argument"` with `argument:"install_source"`. (c) `claw agents create my-agent` returns `action:"help"` with `unexpected:"create my-agent"` — there is no agent-creation surface at all. Users must hand-craft `.claw/agents/.md` files with no scaffolding command, while `claw init` only creates the top-level `.claw/` skeleton. **Required fix shape:** (a) `skills uninstall ` must be local-first: enumerate the local skills dir, return `kind:"skill_not_found"` (with `skills_dir:` and `available_names:[]` fields) for missing, or remove the files and return `kind:"skills"` with `action:"uninstall", removed:` for present skills; (b) `skills install ` must distinguish source forms (`path:`, `name:`, `url:`) and emit `kind:"invalid_install_source"` with the parsed-and-failed reason; (c) `skills install` (no args) emits `kind:"missing_argument"` with `argument:"install_source"`; (d) add `claw agents create ` (or `claw init agent `) that scaffolds `.claw/agents/.md` with a stub frontmatter; or document explicitly that agents are user-authored only. **Why this matters:** lifecycle commands (`uninstall`, `install`, `create`) are the primary surface for managing claw's extension surface area. If `uninstall` requires API creds, an offline user who fat-fingered an install can't undo it. If `install` returns a raw OS error, automation can't programmatically recover. If `agents create` doesn't exist, agent authoring is undocumented file-touching only. Cross-references #357, #369, #427 (auth-gate-on-local-ops cluster), and #422/#423/#428/#430 (`kind:"unknown"` catch-all cluster). Source: Jobdori live dogfood, `328fd114`, 2026-05-11. | `ROADMAP.md:L6372` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage` | — | | `CC2-RM-A0529-claw-resume-latest-on-a-fresh-workspace` | **`claw --resume latest` on a fresh workspace exit code is 0 in text mode but 1 in JSON mode (text mode lies about success); sibling: failed `--resume` creates the `.claw/sessions//` directory tree as a filesystem side effect of the failure** — dogfooded 2026-05-11 by Jobdori on `e29010ed` in response to Clawhip pinpoint nudge at `1503305692566655096`. Reproduction (fresh empty dir, no `.claw/`, no sessions): `claw --resume latest` (text mode) prints `failed to restore session: no managed sessions found in .claw/sessions/0ead448127a2de44/` and exits **0**. Same invocation with `--output-format json` correctly exits **1** with `kind:"session_load_failed"`. Exit-code parity broken on the same input depending on format flag. **Sibling filesystem-side-effect bug:** after the failed `--resume latest` on a fresh empty workspace, the directory `.claw/sessions/0ead448127a2de44/` (the workspace-fingerprint partition) is created on disk despite the operation failing. The user did not opt into creating workspace metadata — they asked to resume an existing session, the resume failed, and now there's a partition directory hanging around. The fingerprint directory ought to be created lazily on first successful session save, not as a side effect of every resume attempt. **Three sibling findings in the same probe:** (a) **`claw --compact` alone (no other args) drops into the interactive REPL with the ANSI welcome banner** — `--compact` is documented as a modifier that strips tool call details in text mode for piping (`--compact ... useful for piping`), not as a verb that activates the REPL. Running `claw --compact` with no positional should be a no-op or an error explaining the flag needs a subcommand or prompt; entering the REPL is the wrong default. (b) **`claw --compact "hello"` (shorthand prompt) returns `{"error":"unknown subcommand: hello.","hint":"Did you mean help","kind":"unknown"}` — `--compact` disables shorthand prompt mode entirely**, treating the positional as a subcommand instead of as prompt text. Users must use the explicit `prompt` verb (`claw --compact prompt "hello"`) which contradicts the `claw [flags] TEXT` usage line in `--help`. (c) `kind:"unknown"` again for the unknown-subcommand error in --compact path — same catch-all bucket bug appearing for the 11th time across pinpoints. **Required fix shape:** (a) exit code 1 for all `failed_to_restore` / `session_load_failed` text-mode failures; text mode should print to stderr and exit non-zero, not print to stdout and exit 0; (b) defer `.claw/sessions//` creation to first successful save; failed `--resume` must not leave filesystem droppings; (c) `claw --compact` alone (no positional, no subcommand, stdin is TTY) should emit `kind:"missing_argument"` with `argument:"prompt or subcommand"` rather than activating the REPL; (d) `--compact` must be transparent to shorthand prompt mode parsing — `claw --compact "hello"` is equivalent to `claw --compact prompt "hello"`, both should reach the prompt path; (e) emit typed `kind:"unknown_subcommand"` not `kind:"unknown"` for fallthrough cases. **Why this matters:** scripts that gate on `$?` after `claw --resume latest` see success on text mode and failure on JSON mode — the same operation, two outcomes. The filesystem side effect pollutes a user's worktree with workspace partitions they didn't ask for, and CI pipelines that snapshot `.claw/` size silently grow on every failed `--resume`. Cross-references #422 (exit-code parity across error envelopes), #423 (`kind:"unknown"` for `missing_argument`), #434 (shorthand prompt limitations). Source: Jobdori live dogfood, `e29010ed`, 2026-05-11. | `ROADMAP.md:L6384` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | none | — | | `CC2-RM-A0530-claw-init-shipped-claw-json-template-exp` | **`claw init` shipped `.claw.json` template explicitly sets `permissions.defaultMode:"dontAsk"` — every user who runs `claw init` gets a config file that disables permission prompts by default; sibling: `init` creates an empty `.claw/` directory with no settings.json template inside, and when `.claw/` already exists it skips the whole artifact (no settings template materialized)** — dogfooded 2026-05-11 by Jobdori on `b8f989b6` in response to Clawhip pinpoint nudge at `1503313241751949335`. Reproduction: `mkdir /tmp/probe && cd /tmp/probe && claw init --output-format json` returns `artifacts:[{name:".claw/",status:"created"},{name:".claw.json",status:"created"},...]`. Inspecting the created `.claw.json`: `{"permissions":{"defaultMode":"dontAsk"}}`. This is the polar opposite of safe-by-default: every user who follows the documented onboarding flow (`claw init` after `curl install.sh`) ships their workspace with permission prompts disabled. Compounds with **#428** (default runtime permission_mode is `danger-full-access`) — between the runtime default and the init template, a fresh claw setup has zero user-facing safety friction. **Sibling: `.claw/` artifact is an empty directory.** After `claw init`, `find .claw -type f` returns nothing. No `settings.json`, no template, no scaffolding — just `mkdir .claw`. The `--help` description implies init produces a usable workspace, but `.claw/settings.json` (the project-scope counterpart of `~/.claw/settings.json`) is never templated. **Sibling: `.claw/` skip-on-exists drops the entire artifact.** If `.claw/` already exists (e.g., from a partial setup, a `--resume` failure side effect per #435, or manual creation), `claw init` returns `.claw/: skipped` and does not materialize any expected sub-content. The other artifacts (`.claw.json`, `.gitignore`, `CLAUDE.md`) are still created, but a future `claw skills install` or `claw plugins enable` may expect `.claw/` to contain template files that are now missing. **Required fix shape:** (a) the shipped `.claw.json` template must default to `permissions.defaultMode:"acceptEdits"` or `"plan"` (safe-by-default modes per #428 spec) — `"dontAsk"` requires explicit opt-in; (b) `claw init` must materialize `.claw/settings.json` with documented schema defaults inside `.claw/` so the directory is useful on its own; (c) when `.claw/` already exists, `init` must report `partial` status (not `skipped`) and still try to create missing sub-files like `.claw/settings.json` without overwriting existing files; (d) emit per-sub-file artifact entries for `.claw/settings.json` and `.claw/sessions/` (skipped status if absent, deferred-to-first-save acceptable) so automation knows what's present; (e) regression test: `claw init` produces a `.claw.json` whose `permissions.defaultMode` is NOT `dontAsk`; `.claw/` contains at least one templated file. **Why this matters:** init is the primary onboarding surface. Every first-time user piping `curl install.sh \| sh && claw init` gets a workspace pre-configured to skip permission prompts — and that workspace gets committed to the user's repo via the `init`-added entry. The `.claw/` empty-directory bug means feature discovery (skills, plugins) lacks the scaffolding it implies. Cross-references #428 (runtime default permission_mode), #50/#87/#91/#94/#97/#101/#106/#115/#123 (permission-rule audit), #435 (filesystem side effects on failed resume). Source: Jobdori live dogfood, `b8f989b6`, 2026-05-11. | `ROADMAP.md:L6387` / `roadmap_action` | `post_2_0_research` | `deferred_with_rationale` | `targeted_regression_or_acceptance_test_required` | `adoption_overlay_triage`, `stable_alpha_contracts` | Deferred by roadmap/approved plan until prerequisite contracts or post-2.0 research admission gates are satisfied. | | `CC2-RM-A0531-version-output-format-json-omits-build-p` | **`version --output-format json` omits build provenance fields — no `is_dirty`, `branch`, `commit_date`, `commit_timestamp`, `rustc_version`; `git_sha` is truncated to 7 chars instead of full 40-char hash; sibling: `executable_path` leaks the build host's path (`/tmp/claw-dog-0530/...`) into runtime output** — dogfooded 2026-05-11 by Jobdori on `8cf628a5` in response to Clawhip pinpoint nudge at `1503320791582900344`. Reproduction: `claw version --output-format json` returns `{"build_date":"2026-05-11","executable_path":"/tmp/claw-dog-0530/rust/target/release/claw","git_sha":"b98b9a7","kind":"version","message":"Claw Code\n Version 0.1.0\n Git SHA b98b9a7\n Target aarch64-apple-darwin\n Build date 2026-05-11","target":"aarch64-apple-darwin","version":"0.1.0"}`. Critical provenance fields missing: (a) **`is_dirty`** — was the working tree clean at build time? Automation that pins on build provenance cannot tell if the binary was built from a clean commit or includes uncommitted changes; (b) **`branch`** — was this built from `main`, `dev/rust`, a release tag, or a feature branch? The `git_sha` alone doesn't reveal the integration point; (c) **`commit_date` / `commit_timestamp`** — only `build_date` (when the binary was compiled) is exposed; the commit itself might be days/weeks older if the build happened later. Reproducibility audits need both; (d) **`rustc_version`** — what Rust compiler version produced this binary? Critical for security advisories (e.g., known regressions in specific rustc versions); (e) **`git_sha` truncated to 7 chars** ("b98b9a7" instead of full "b98b9a71..."): 7-char shas have known collision rates in large repos and prevent unambiguous git rev-parse round-trip. **Sibling: `executable_path` leaks build-host path.** The `executable_path` field returns `/tmp/claw-dog-0530/rust/target/release/claw` — the directory where the binary was compiled, embedded into the binary metadata. For a binary copied/installed/symlinked to a different location, this field still reports the build path, not the actual invocation path. Either the field should reflect the runtime path via `std::env::current_exe()` at runtime (not compile-time), or it should be dropped to avoid leaking compile-host filesystem layout. **Sibling: prose `message` field duplicates structured data.** The `message` field still contains the entire text-mode prose version block (`"Claw Code\n Version 0.1.0\n Git SHA b98b9a7\n..."`) — every field present as structured JSON (`version`, `git_sha`, `target`, `build_date`) is also embedded in the prose. Same issue as #391 (`version json includes prose message field`) which was closed as "fixed" — the prose remains. **Required fix shape:** (a) add `is_dirty:bool`, `branch:string\|null`, `commit_date:string` (ISO-8601), `commit_timestamp:int` (Unix epoch), `rustc_version:string` to the JSON envelope; (b) preserve full 40-char `git_sha` and add `git_sha_short:string` as a derived field if 7-char form is needed for UX; (c) `executable_path` should be `std::env::current_exe()` at runtime, not the compile-time path; (d) drop the prose `message` field from JSON or rename it `human_readable:string` and make it explicitly secondary to the structured fields; (e) re-verify #391 closure — the prose `message` is still present, the fix didn't fully land. **Why this matters:** version surface is the canonical provenance probe for security audits, build reproducibility, and bug-report metadata. Missing `is_dirty` means automated triage cannot distinguish "issue against a clean main commit" from "issue against a developer's uncommitted hack". Truncated `git_sha` blocks unambiguous git lookup. Leaked `executable_path` exposes build-host layout. Cross-references #391 (version prose duplication — apparently not fully fixed), #334 (version json omits build_date — fixed, but partial scope), #100 (commit identity audit). Source: Jobdori live dogfood, `8cf628a5`, 2026-05-11. | `ROADMAP.md:L6390` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `adoption_overlay_triage` | — | | `CC2-RM-A0532-memory-file-discovery-only-recognizes-cl` | **Memory file discovery only recognizes `CLAUDE.md` — `AGENTS.md` (industry convention used by OpenCode/Codex/Aider/Cursor) and `CLAW.md` (project's own brand name) are silently ignored despite being present in the workspace** — dogfooded 2026-05-11 by Jobdori on `d3a982dd` in response to Clawhip pinpoint nudge at `1503328341422244012`. Reproduction (fresh empty dir, isolated `CLAW_CONFIG_HOME`): create three files in cwd — `CLAUDE.md` (marker `MARKER-FROM-CLAUDE-MD`), `AGENTS.md` (marker `MARKER-FROM-AGENTS-MD`), `CLAW.md` (marker `MARKER-FROM-CLAW-MD`). Run `claw status --output-format json` → `workspace.memory_file_count: 1`. Run `claw system-prompt --output-format json` and search the `message` field for each marker: only `MARKER-FROM-CLAUDE-MD` is found; `MARKER-FROM-AGENTS-MD` and `MARKER-FROM-CLAW-MD` are absent. `claw-code` exclusively recognizes the Claude-branded filename inherited from upstream Claude Code; the project's own `CLAW.md` brand name and the cross-tool industry convention `AGENTS.md` are both silently dropped. **Three sibling implications:** (a) **brand-consistency gap**: a project rebranded from Claude Code to Claw Code that introduces `CLAUDE.md` as its only memory file is internally inconsistent. Users naturally expect `claw ` to read `CLAW.md`. (b) **industry-convention gap**: `AGENTS.md` is the convergent convention for OpenCode (oh-my-opencode/sisyphus), OpenAI Codex CLI, Aider, Cursor, Continue.dev, and most ACP harnesses. Users with mixed-tool workflows maintain a shared `AGENTS.md` and expect every AI coding tool to honor it. (c) **silent failure mode**: there is no warning when `AGENTS.md` or `CLAW.md` exist but are not loaded. Users who copy-paste `AGENTS.md` from another tool's docs see `memory_file_count` stay at 0 or 1 and have to guess why their instructions aren't applied. **Required fix shape:** (a) discover and load **`CLAUDE.md`, `CLAW.md`, `AGENTS.md`** in that priority order (existing config-precedence pattern); (b) all three contribute to `memory_file_count` with `memory_files:[{path, source:"claude_md"\|"claw_md"\|"agents_md", chars}]` array exposed in `status --output-format json`; (c) when multiple files exist, merge or document the precedence: project-specific `CLAUDE.md`/`CLAW.md` overrides industry-shared `AGENTS.md`; (d) `claw doctor --output-format json` adds a `memory` check that warns when `AGENTS.md` exists but is not the loaded variant (alerting users that they may be relying on the wrong file); (e) regression test: workspace with all three files results in `memory_file_count >= 1` and the system prompt contains markers from at least the highest-precedence file. **Why this matters:** `AGENTS.md` is the lingua-franca instruction file for cross-tool AI coding workflows. A team using OpenCode for one project and Claw Code for another keeps their conventions in a shared `AGENTS.md`. Forcing them to also maintain a `CLAUDE.md` for claw-code (with identical content) is friction that breaks the value proposition of a fork. Cross-references #438 itself (the multi-file convention), and AGENTS.md ecosystem references in oh-my-opencode/sisyphus docs. Source: Jobdori live dogfood, `d3a982dd`, 2026-05-11. | `ROADMAP.md:L6393` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage`, `stable_alpha_contracts` | — | | `CC2-RM-A0535-hooks-config-schema-diverges-from-claude` | **`hooks` config schema diverges from Claude Code documented format — claw-code expects `{"hooks":{"PreToolUse":["command-string"]}}` (array of command strings) while Claude Code documentation specifies `{"hooks":{"PreToolUse":[{"matcher":"Read","hooks":[{"type":"command","command":"..."}]}]}}` (structured matcher objects); users copy-pasting from Claude Code docs see `field "hooks.PreToolUse" must be an array of strings`** — dogfooded 2026-05-11 by Jobdori on `86ff83c2` in response to Clawhip pinpoint nudge at `1503350990680887418`. Reproduction: write `.claw.json` with the Claude-Code-documented hook format `{"hooks":{"PreToolUse":[{"matcher":"Read","hooks":[{"type":"command","command":"/bin/echo pretool"}]}]}}`. Run `claw status --output-format json` → `config_load_error: "/private/tmp/claw-hook-probe/.claw.json: field \"hooks.PreToolUse\" must be an array of strings, got an array (line 3)"`, `status: "degraded"`. The error wording ("must be an array of strings, got an array") is confusingly tautological — the user did provide an array; the parser objects that the array contains objects instead of strings. Replacing with the claw-code-actual format `{"hooks":{"PreToolUse":["/bin/echo pretool"]}}` succeeds: `config_load_error: null, status: "ok"`. The two formats are fundamentally incompatible: claw-code drops the `matcher` field (no tool-specific filtering at the config layer), drops the `type:"command"` discriminator (no future expansion to other hook types), and treats each entry as a bare command string instead of a structured hook spec. **Sibling: PR #3000 (justcode049) was attempting to tolerate object-style hook entries** — that PR's title `fix: tolerate object-style hook entries in config parser` confirms this is a known user complaint, but the PR is still conflicting and unmerged. **Three sibling findings in same probe:** (a) **unknown event names reject entire hooks config**: `.claw.json` with `hooks.InvalidEvent` (not a real event name like `PreToolUse`/`PostToolUse`/`Stop`/`Notification`) triggers `config_load_error: "unknown key \"hooks.InvalidEvent\""` and rejects ALL hooks in the same file, even valid ones — same "one bad apple kills all" pattern as #440 (MCP servers). (b) **`kind:"unknown"` for the validation error** — should be `kind:"invalid_hooks_config"` or `kind:"unknown_hook_event"` (catch-all cluster #422/#423/#424/#428/#430/#431/#432/#433/#435 — 13th occurrence). (c) **first-error-only halting**: a `.claw.json` with `hooks.Stop:"not-an-array"` (type mismatch) AND `hooks.InvalidEvent` (unknown name) AND `hooks.Notification:[{}]` (empty entry) surfaces only the FIRST error in iteration order — user must fix one at a time across 3 iterations. **Required fix shape:** (a) **adopt Claude Code's structured hook format as the canonical**: support `{matcher, hooks:[{type, command}]}` natively, with `matcher` for tool-filtering, `type` for hook-type discriminator (future-proof for `inline`/`webhook`/etc beyond just `command`); (b) **keep backward compat for bare command strings**: legacy `["command-string"]` arrays still load, but emit a deprecation warning suggesting migration to the structured form; (c) **partial-success loading**: invalid hook entries surface in `invalid_hooks:[{event, index, reason}]` while valid ones load — same fix as #440 for MCP; (d) **typed `kind:"invalid_hooks_config"` envelope** instead of `kind:"unknown"`; (e) **rebase and merge PR #3000** which addresses this directly; (f) regression test: Claude-Code-documented hook config loads without error on claw-code. **Why this matters:** users migrating from Claude Code to Claw Code hit this on their first `.claw.json` write. The error message ("array of strings, got an array") is unhelpful; the documentation doesn't surface the schema divergence; and Claude Code's structured format is strictly more expressive (matchers, types) than claw-code's bare-string format. Cross-references #407 (config files no load_error), #410 (list-envelope schema drift), #428 (default permission mode), #440 (one invalid MCP entry blocks all), PR #3000 (justcode049's pending fix). Source: Jobdori live dogfood, `86ff83c2`, 2026-05-11. | `ROADMAP.md:L6402` / `roadmap_action` | `alpha_blocker` | `open` | `targeted_regression_or_acceptance_test_required` | `adoption_overlay_triage` | — | | `CC2-RM-A0536-agents-discovery-requires-toml-format-to` | **`agents` discovery requires TOML format (`.toml` files) while Claude Code documents agents as Markdown with YAML frontmatter (`.md`) — claw-code silently ignores `.md` files in `.claw/agents/` without any warning; the help text lists `.claw/agents, ~/.claw/agents, $CLAW_CONFIG_HOME/agents` as sources but does not mention the `.toml` file format requirement** — dogfooded 2026-05-11 by Jobdori on `8499599b` in response to Clawhip pinpoint nudge at `1503358540230692876`. Reproduction: write `.claw/agents/valid-agent.md` with Claude-Code-format YAML frontmatter `---\nname: valid-agent\ndescription: A simple test agent\ntools: [bash, read_file]\n---\nYou are a helpful agent.` Run `claw agents list --output-format json` → `{"agents":[], "count":0, "summary":{"active":0,"shadowed":0,"total":0}}`. The valid `.md` agent is silently dropped. Replace with `.claw/agents/toml-agent.toml` containing TOML format `name = "toml-agent"\ndescription = "..."` → loads correctly with `count:1`. Source code confirms (`rust/crates/commands/src/lib.rs:3378`): `if entry.path().extension().is_none_or(\|ext\| ext != "toml") { continue; }` — only `.toml` extension is recognized, all others (including `.md`) skipped without warning. The help text `claw agents --help` documents the source paths but **omits the file-format requirement**. **Five sibling problems compounded:** (a) **schema divergence from Claude Code**: Claude Code's `agents` are documented as `.md` files with YAML frontmatter (matching the `CLAUDE.md`/`.claude/agents/` convention upstream). claw-code chose TOML for no documented reason. Users migrating from Claude Code or copy-pasting community agent definitions hit silent failure. (b) **silent file drop**: invalid agent files (wrong extension, broken frontmatter, missing required fields, file-name vs frontmatter-name mismatch) are all silently ignored with `count:0`. No `invalid_agents:[]` array, no warning, no `kind:"agent_load_failed"` envelope. Same all-or-nothing pattern as #440 (MCP servers) and #441 (hooks). (c) **no documentation of the schema**: `claw agents --help --output-format json` (per #427, this hits the auth gate; without auth it doesn't return the schema either). The required TOML fields (`name`, `description`, `model`, `model_reasoning_effort` per source code) aren't documented in any user-facing surface. (d) **missing `.claude/agents/` discovery**: many existing projects have `.claude/agents/` from Claude Code installs. claw-code only looks at `.claw/agents/` — users have to copy/move their existing agents. (e) **no agent-scaffolding command**: cross-reference #431 — there's no `claw agents create ` to generate a valid `.toml` skeleton; users must hand-craft. **Required fix shape:** (a) accept BOTH `.md` (with YAML frontmatter) AND `.toml` formats in `.claw/agents/`; prefer YAML frontmatter for Claude Code parity, keep TOML for back-compat; (b) include `.claude/agents/` in the discovery sources alongside `.claw/agents/` with documented precedence; (c) expose `invalid_agents:[{path, reason}]` array in `agents list --output-format json` so users can see what was skipped and why; (d) document the agent schema (required + optional fields) in `claw agents --help` and in USAGE.md; (e) add `claw agents create ` scaffolding command per #431; (f) regression test: `.claw/agents/foo.md` with YAML frontmatter loads correctly. **Why this matters:** agents are the primary extension surface for custom workflows. A silent-drop on the wrong file format breaks the discoverability promise of CLI agents. Claude Code's `.md`-with-YAML convention is the lingua franca across AI coding tools; deviating to TOML breaks copy-paste compatibility. Cross-references #430 (dump-manifests needs upstream), #431 (skills/agents lifecycle), #440 (MCP all-or-nothing), #441 (hooks all-or-nothing), #438 (memory file discovery only CLAUDE.md). Source: Jobdori live dogfood, `8499599b`, 2026-05-11. | `ROADMAP.md:L6405` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `adoption_overlay_triage`, `stable_alpha_contracts` | — | | `CC2-RM-A0539-skill-name-vs-directory-mismatch-is-sile` | **Skill name-vs-directory mismatch is silently accepted — `.claw/skills/wrong-name/SKILL.md` with frontmatter `name: actually-different-name` loads as "actually-different-name" without any warning; users who reference the skill by directory name (`claw skills run wrong-name`) get `skill_not_found` while `skills list` shows it under the frontmatter name; sibling: loose `.md` files at the skills-dir root and subdirs without `SKILL.md` are silently dropped** — dogfooded 2026-05-11 by Jobdori on `9e1eafd0` in response to Clawhip pinpoint nudge at `1503381189539528897`. Reproduction: create `.claw/skills/wrong-name/SKILL.md` with frontmatter `---\nname: actually-different-name\ndescription: Skill where dir name and frontmatter name disagree\n---`. Run `claw skills list --output-format json` → the skill is listed with `name: "actually-different-name"` (the frontmatter value), no warning about the dir-vs-name mismatch. Users who type `claw skills run wrong-name` (the dirname they know from `ls`) get a `skill_not_found` error; `claw skills run actually-different-name` works. The two names are decoupled with no surfaced relationship. **Three sibling silent-drop bugs in same probe:** (a) **subdir without SKILL.md silently skipped**: `.claw/skills/no-skill-md/` containing only `README.md` (no `SKILL.md`) is silently skipped from `skills list`. No `invalid_skills:[{path, reason:"missing_SKILL.md"}]` array, no warning, just absent from output. (b) **Loose `.md` at skills dir root silently dropped**: `.claw/skills/loose-skill.md` (not inside a per-skill subdirectory) is silently ignored. Discovery only walks `.claw/skills/*/SKILL.md` — no support for flat `.claw/skills/.md`. (c) **Workspace + user skills merged without per-source filter**: `skills list` returns 74 entries including all `~/.claw/skills/*` user-home skills alongside the project skills. There's no `--scope workspace` flag to limit output to just project-local skills; automation has to filter by `source.id == "project_claw"` post-hoc. **Required fix shape:** (a) when SKILL.md frontmatter `name` differs from the parent directory name, emit a `skills_metadata_drift:[{dir_name, frontmatter_name, path}]` array OR enforce `name = dir_name` as a hard rule; if neither, at minimum a stderr warning on each invocation; (b) skill subdirectories without `SKILL.md` should surface as `invalid_skills:[{path, reason}]` in `skills list --output-format json` (same pattern as #440 MCP servers, #441 hooks, #442 agents); (c) support loose `.md` files at skills-dir root OR document explicitly that only subdirectories with `SKILL.md` are discovered; (d) add `--scope workspace\|user\|all` flag to `skills list` for filtering; (e) regression test: dir/frontmatter mismatch triggers a deterministic warning or error; subdirs without SKILL.md show in invalid array. **Why this matters:** skill discovery is a security-relevant surface — a user's `claw skills run X` could end up running a different skill than they thought if dir-name and frontmatter-name diverge. The silent drops mean users can't tell why their skill files aren't recognized, leading to "I copied the example and it doesn't work" forum questions. Cross-references #440 (MCP all-or-nothing), #441 (hooks all-or-nothing), #442 (agents need TOML, .md dropped), #431 (skills install raw OS error). Source: Jobdori live dogfood, `9e1eafd0`, 2026-05-11. | `ROADMAP.md:L6414` / `roadmap_action` | `alpha_blocker` | `open` | `targeted_regression_or_acceptance_test_required` | `adoption_overlay_triage`, `stable_alpha_contracts` | — | | `CC2-ISSUE-CLAW-OPEN-LATEST-3037` | docs: clarify Claw Code positioning as multi-provider Claude-Code-shaped runtime | `.omx/research/claw-open-latest.json#issue-3037` / `latest_open_issue` | `2.x_intake` | `open` | `issue_acceptance_repro_or_triage_decision` | `roadmap_board_triage` | Latest issue intake is admitted only when it matches freeze/admission rules; otherwise remains 2.x_intake. | | `CC2-ISSUE-CLAW-OPEN-LATEST-3036` | docs: add official Ollama/llama.cpp/vLLM local model examples | `.omx/research/claw-open-latest.json#issue-3036` / `latest_open_issue` | `2.x_intake` | `open` | `issue_acceptance_repro_or_triage_decision` | `roadmap_board_triage` | Latest issue intake is admitted only when it matches freeze/admission rules; otherwise remains 2.x_intake. | | `CC2-ISSUE-CLAW-OPEN-LATEST-3035` | fix: improve compacted session resume discoverability | `.omx/research/claw-open-latest.json#issue-3035` / `latest_open_issue` | `2.x_intake` | `open` | `issue_acceptance_repro_or_triage_decision` | `roadmap_board_triage` | Latest issue intake is admitted only when it matches freeze/admission rules; otherwise remains 2.x_intake. | | `CC2-ISSUE-CLAW-OPEN-LATEST-3034` | docs: define evidence-gated Hermes handoff loop for Claw Code execution | `.omx/research/claw-open-latest.json#issue-3034` / `latest_open_issue` | `2.x_intake` | `open` | `issue_acceptance_repro_or_triage_decision` | `roadmap_board_triage` | Latest issue intake is admitted only when it matches freeze/admission rules; otherwise remains 2.x_intake. | | `CC2-ISSUE-CLAW-OPEN-LATEST-3032` | docs: add OpenAI-compatible/local provider diagnostics playbook | `.omx/research/claw-open-latest.json#issue-3032` / `latest_open_issue` | `2.x_intake` | `open` | `issue_acceptance_repro_or_triage_decision` | `roadmap_board_triage` | Latest issue intake is admitted only when it matches freeze/admission rules; otherwise remains 2.x_intake. | | `CC2-ISSUE-CLAW-OPEN-LATEST-3031` | feat: auto-compact or clearly recover from context-window provider errors | `.omx/research/claw-open-latest.json#issue-3031` / `latest_open_issue` | `2.x_intake` | `open` | `issue_acceptance_repro_or_triage_decision` | `roadmap_board_triage` | Latest issue intake is admitted only when it matches freeze/admission rules; otherwise remains 2.x_intake. | | `CC2-ISSUE-CLAW-OPEN-LATEST-3030` | feat: make provider/model setup less env-var-driven | `.omx/research/claw-open-latest.json#issue-3030` / `latest_open_issue` | `2.x_intake` | `open` | `issue_acceptance_repro_or_triage_decision` | `roadmap_board_triage` | Latest issue intake is admitted only when it matches freeze/admission rules; otherwise remains 2.x_intake. | | `CC2-ISSUE-CLAW-OPEN-LATEST-3029` | build: add cross-platform installer path and release artifact quickstart | `.omx/research/claw-open-latest.json#issue-3029` / `latest_open_issue` | `2.x_intake` | `open` | `issue_acceptance_repro_or_triage_decision` | `roadmap_board_triage` | Latest issue intake is admitted only when it matches freeze/admission rules; otherwise remains 2.x_intake. | | `CC2-ISSUE-CLAW-OPEN-LATEST-3028` | docs: add navigation and file-context usage guide | `.omx/research/claw-open-latest.json#issue-3028` / `latest_open_issue` | `2.x_intake` | `open` | `issue_acceptance_repro_or_triage_decision` | `roadmap_board_triage` | Latest issue intake is admitted only when it matches freeze/admission rules; otherwise remains 2.x_intake. | | `CC2-ISSUE-CLAW-OPEN-LATEST-3006` | Not Working in windows | `.omx/research/claw-open-latest.json#issue-3006` / `latest_open_issue` | `2.x_intake` | `open` | `issue_acceptance_repro_or_triage_decision` | `roadmap_board_triage` | Latest issue intake is admitted only when it matches freeze/admission rules; otherwise remains 2.x_intake. | | `CC2-ISSUE-CLAW-OPEN-LATEST-2997` | License? | `.omx/research/claw-open-latest.json#issue-2997` / `latest_open_issue` | `2.x_intake` | `open` | `issue_acceptance_repro_or_triage_decision` | `roadmap_board_triage` | Latest issue intake is admitted only when it matches freeze/admission rules; otherwise remains 2.x_intake. | | `CC2-ISSUE-CLAW-OPEN-LATEST-2980` | docs: consider linking community Windows guide from README | `.omx/research/claw-open-latest.json#issue-2980` / `latest_open_issue` | `2.x_intake` | `open` | `issue_acceptance_repro_or_triage_decision` | `roadmap_board_triage` | Latest issue intake is admitted only when it matches freeze/admission rules; otherwise remains 2.x_intake. | | `CC2-ISSUE-CLAW-OPEN-LATEST-2979` | docs: add safe PowerShell provider switching example | `.omx/research/claw-open-latest.json#issue-2979` / `latest_open_issue` | `2.x_intake` | `open` | `issue_acceptance_repro_or_triage_decision` | `roadmap_board_triage` | Latest issue intake is admitted only when it matches freeze/admission rules; otherwise remains 2.x_intake. | | `CC2-ISSUE-CLAW-ISSUES-3012` | Installation Breaks Mid Download | `.omx/research/claw-issues.json#issue-3012` / `issue_theme` | `beta_adoption` | `done_verify` | `issue_acceptance_repro_or_triage_decision` | `roadmap_board_triage` | — | | `CC2-ISSUE-CLAW-ISSUES-3006` | Not Working in windows | `.omx/research/claw-issues.json#issue-3006` / `issue_theme` | `beta_adoption` | `open` | `issue_acceptance_repro_or_triage_decision` | `roadmap_board_triage` | — | | `CC2-ISSUE-CLAW-ISSUES-2997` | License? | `.omx/research/claw-issues.json#issue-2997` / `issue_theme` | `beta_adoption` | `open` | `issue_acceptance_repro_or_triage_decision` | `roadmap_board_triage` | — | | `CC2-ISSUE-CLAW-ISSUES-2980` | docs: consider linking community Windows guide from README | `.omx/research/claw-issues.json#issue-2980` / `issue_theme` | `beta_adoption` | `open` | `issue_acceptance_repro_or_triage_decision` | `roadmap_board_triage` | — | | `CC2-ISSUE-CLAW-ISSUES-2979` | docs: add safe PowerShell provider switching example | `.omx/research/claw-issues.json#issue-2979` / `issue_theme` | `beta_adoption` | `open` | `issue_acceptance_repro_or_triage_decision` | `roadmap_board_triage` | — | | `CC2-ISSUE-CLAW-ISSUES-2833` | main下最新版本Windows下编译运行不成功 | `.omx/research/claw-issues.json#issue-2833` / `issue_theme` | `beta_adoption` | `done_verify` | `issue_acceptance_repro_or_triage_decision` | `roadmap_board_triage` | — | | `CC2-ISSUE-CLAW-ISSUES-2822` | Non-Anthropic providers inherit hardcoded Claude identity in system prompt | `.omx/research/claw-issues.json#issue-2822` / `issue_theme` | `beta_adoption` | `done_verify` | `issue_acceptance_repro_or_triage_decision` | `roadmap_board_triage` | — | ### Parity overlay — opencode/codex comparison context | ID | Title | Source | Bucket | Lifecycle | Verification | Dependencies | Deferral | | --- | --- | --- | --- | --- | --- | --- | --- | | `CC2-RM-A0347-for-subcommands-that-return-a-structured` | For subcommands that return a structured help block (`status`, `sandbox`, `doctor`, `skills`, `agents`, `mcp`, `acp`): this is the model. Use the same pattern. | `ROADMAP.md:L5318` / `roadmap_action` | `alpha_blocker` | `open` | `targeted_regression_or_acceptance_test_required` | `stable_alpha_contracts` | — | | `CC2-RM-A0372-misleading-error-user-running-claw-plugi` | **Misleading error**: user running `claw plugins` sees an Anthropic credential error. No hint that `plugins` wasn't a recognized subcommand. | `ROADMAP.md:L5593` / `roadmap_action` | `beta_adoption` | `open` | `provider_routing_contract_test` | `stable_alpha_contracts` | — | | `CC2-RM-A0427-build-setup-failures-are-being-misclassi` | **Build/setup failures are being misclassified as generic missing-path shell errors in post-tool feedback** — dogfooded 2026-04-19 from `dogfood-1776184671`. When the lane attempted `node dist/cli/index.js extract --help` with no built artifact, the `PostToolUse` hook summarized it as ``Bash reported `command not found`, `permission denied`, or a missing file/path``, and later `npm run build` failed with actual TypeScript diagnostics (`TS2307: Cannot find module 'typescript'`, plus additional compile errors). Those are distinct failure classes — missing built artifact, missing dependency, and compile/typecheck red — but the feedback surface collapses them into the same mushy shell-triage bucket. That makes recovery slower because the operator has to reread raw pane output to learn whether the right next move is `npm ci`, fixing package deps, fixing TS errors, or checking file paths. **Required fix shape:** (a) classify post-tool failures with narrower machine-readable buckets such as `artifact_missing`, `dependency_missing`, `compile_error`, and reserve `missing_path` / `command_not_found` for the literal cases; (b) include the strongest observed diagnostic snippet (for example `TS2307 typescript missing`) in the structured feedback instead of only the broad shell rubric; (c) add regression coverage proving TypeScript/compiler failures are not surfaced as generic missing-path errors; (d) thread that typed classification into lane summaries so downstream claws can recommend the right recovery without pane archaeology. **Why this matters:** clawability depends on the fix suggestion matching the real failure class; broad shell-error mush turns easy recoveries into manual forensic work. Source: live dogfood session `dogfood-1776184671` on 2026-04-19. | `ROADMAP.md:L6176` / `roadmap_action` | `beta_adoption` | `open` | `targeted_regression_or_acceptance_test_required` | `stable_alpha_contracts` | — | | `CC2-RM-A0478-status-session-list-output-format-json-s` | **`status` / `/session list --output-format json` session lifecycle reports `workspace_dirty: true` and `abandoned: true` but omits dirty-file detail and abandonment cause, making automated GC unable to distinguish live work from crash leftovers** — restored from PR #2852 / Jobdori dogfood on current main (`0f7578c`). The evidence bundle listed 10 sessions and every listed session had `workspace_dirty: true` plus `abandoned: true`; each lifecycle object exposed `abandoned: true`, `kind: "saved_only"`, `pane_id: null`, and `workspace_dirty: true`, but did not include `dirty_file_count`, `dirty_file_paths` / summary, or `abandoned_reason`. That leaves cleanup policy with only a boolean dirty/abandoned pair: it cannot tell whether a saved-only session contains intentional uncommitted user work, a harmless stale pane artifact, or crash leftovers that are safe to collect. **Required fix shape:** (a) add `dirty_file_count: u32` to session lifecycle/status payloads whenever dirty state is evaluated; (b) add an `abandoned_reason` enum such as `pane_closed`, `process_killed`, `session_replaced`, `workspace_missing`, or `unknown` instead of a bare boolean-only abandonment signal; (c) optionally add summarized `dirty_file_paths` / `dirty_file_summary` with truncation metadata so automation can present useful evidence without leaking excessive path detail; (d) add regression coverage proving dirty abandoned saved-only sessions include file count, abandonment reason, and stable behavior when path summaries are omitted or truncated. **Why this matters:** session GC must not delete live user work, but it also cannot leave every crash leftover forever. A lifecycle object that says only `workspace_dirty: true` and `abandoned: true` forces cleanup tooling to guess instead of applying a safe policy from structured evidence. Source: PR #2852 / Jobdori dogfood; all 10 listed sessions shared the same dirty+abandoned shape, and the sample lifecycle object had `abandoned: true`, `kind: "saved_only"`, `pane_id: null`, `workspace_dirty: true`, with no dirty-file count, path summary, or abandonment reason. | `ROADMAP.md:L6275` / `roadmap_action` | `beta_adoption` | `stale_done` | `verify_existing_evidence_and_regression_guard` | `stable_alpha_contracts` | Marked done in roadmap but needs freshness re-verification before being used as release evidence. | | `CC2-RM-A0505-init-output-format-json-emits-redundant` | **`init --output-format json` emits redundant parallel artifact schemas — `artifacts[].status` and flat `created[]`/`skipped[]`/`updated[]` arrays carry identical state, and `artifacts[].status:"skipped"` omits `skip_reason`** — dogfooded 2026-04-30 by Jobdori on `e939777f`. Running `claw init --output-format json` on a fresh directory returns a JSON object with two parallel representations of the same artifact set: (1) `artifacts: [{name, status}]` — a structured per-artifact array; and (2) `created: [...]`, `skipped: [...]`, `updated: [...]` — flat string arrays partitioned by status. Both encode the same four artifact names and their outcomes with no additional information between them. On a subsequent run in an already-initialized directory, every artifact has `status:"skipped"`, but no `reason` field is present on any artifact entry — automation cannot distinguish `"already_exists"` (safe to ignore) from `"permission_denied"`, `"dry_run"`, or `"conflicting_contents"` (each requiring a different response). The `message` field also embeds `"skipped (already exists)"` prose that is absent from the structured payload. **Required fix shape:** (a) pick one canonical artifact representation — either `artifacts[{name, status, reason?, path?}]` or the flat status arrays — and deprecate the other; (b) add a `skip_reason` or `reason` field to `artifacts[]` entries with `status:"skipped"` and `status:"error"`, using an enum such as `already_exists`, `permission_denied`, `dry_run`, `conflict`, `unknown`; (c) add optional `path` (absolute) to each artifact entry so automation can act on the real on-disk location without re-joining with `project_path`; (d) add regression coverage proving `init --output-format json` on an existing directory includes machine-classifiable skip reasons for every skipped artifact and does not rely on the prose `message` field for structured state. **Why this matters:** init is the bootstrapping surface automation uses to ensure a project is claw-ready. If skip classification requires parsing human prose and the structured payload has two redundant formats, claws either over-provision re-inits or cannot distinguish safe skips from blocked writes without brittle message scraping. Source: Jobdori live dogfood, `e939777f`, 2026-04-30. | `ROADMAP.md:L6312` / `roadmap_action` | `beta_adoption` | `open` | `targeted_regression_or_acceptance_test_required` | `stable_alpha_contracts` | — | | `CC2-RM-A0509-acp-output-format-json-leaks-internal-ro` | **`acp --output-format json` leaks internal ROADMAP tracking numbers and implementation notes as top-level JSON fields — `discoverability_tracking:"ROADMAP #64a"` and `tracking:"ROADMAP #76"` are internal backlog references that should not appear in the public machine-readable contract** — dogfooded 2026-04-30 by Jobdori on `e939777f`. Running `claw acp --output-format json` returns a ten-key envelope: `aliases`, `discoverability_tracking`, `kind`, `launch_command`, `message`, `recommended_workflows`, `serve_alias_only`, `status`, `supported`, `tracking`. Two fields are verbatim internal backlog cross-references: `"discoverability_tracking":"ROADMAP #64a"` and `"tracking":"ROADMAP #76"`. These were presumably used during initial scaffolding to track which backlog items the stub relates to, but they are now part of the public JSON contract that automation consumes. The `message` field also contains implementation-note prose (`"ACP/Zed editor integration is not implemented in claw-code yet. \`claw acp serve\`..."`) that describes the build state rather than the command's machine-readable status. **Required fix shape:** (a) remove `discoverability_tracking` and `tracking` from the public JSON envelope or move them to an optional `_debug` or `_meta` sub-object gated on a debug flag; (b) replace `message` prose with a structured `reason` enum (`"not_implemented"`, `"discoverability_only"`, `"serve_only"`) plus optional `detail` string; (c) rename `supported:false` + `status:"discoverability_only"` to a single typed `availability` object with `status`, `reason`, and `target_command` fields; (d) add regression coverage proving the public `acp --output-format json` envelope contains no internal tracking/backlog fields and that `message` is not the sole machine-classifiable signal. **Why this matters:** public JSON APIs should not leak internal ticket references. Automation that snapshots or validates the ACP JSON schema will embed these internal identifiers into external contracts and need to change every time backlog numbering shifts. Source: Jobdori live dogfood, `e939777f`, 2026-04-30. | `ROADMAP.md:L6324` / `roadmap_action` | `ga_ecosystem` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `stable_alpha_contracts` | — | | `CC2-RM-A0513-mcp-unknown-subcommand-output-format-jso` | **`mcp --output-format json` returns `action:"help"` + `unexpected:` with exit 0 instead of an error envelope — unrecognized MCP subcommands silently succeed** — dogfooded 2026-05-01 by Jobdori on `e939777f`. Running `claw mcp add --output-format json` or `claw mcp remove --output-format json` (subcommands that do not exist) returns exit 0 with stdout JSON `{"action":"help","kind":"mcp","unexpected":"add","usage":{"direct_cli":"claw mcp [list\|show \|help]","slash_command":"/mcp [list\|show \|help]","sources":[...]}}`. Exit code is 0. The `action` field is `"help"` — not `"error"` — even though the caller issued a recognized token (`add`/`remove`) that maps to a real but unimplemented feature. The `unexpected` field correctly identifies the unrecognized arg, but automation that checks `exit == 0` or `action != "error"` will treat this as a successful invocation. This is distinct from ROADMAP #108 which covers *unrecognized CLI subcommands* falling through to the LLM prompt path — #419 targets MCP-specific *known-but-unimplemented* subcommands that return `action:"help"` with exit 0 instead of an explicit `action:"error"` envelope. **Required fix shape:** (a) return a non-zero exit code (exit 1 or exit 2) when an unrecognized or unimplemented MCP subcommand is provided; (b) emit `action:"error"` (or `kind:"error"`) with a `code:"unknown_subcommand"` and `unknown:"add"` field instead of `action:"help"`; (c) optionally include the help/usage payload as a sibling field `suggestion:{usage:{...}}` for context; (d) add regression coverage proving `mcp --output-format json` returns a non-zero exit code and a non-help action token. **Why this matters:** `add` and `remove` are common MCP lifecycle operations that users will attempt; returning `action:"help"` with exit 0 makes these look like successful no-ops to any automation that doesn't deep-inspect the `unexpected` field. A pipeline that runs `claw mcp add my-server ... && claw mcp show my-server` will silently proceed to the show step even though add silently no-oped. Source: Jobdori live dogfood, `e939777f`, 2026-05-01. | `ROADMAP.md:L6336` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `stable_alpha_contracts` | — | | `CC2-RM-A0515-status-mcp-list-doctor-json-output-leak` | **`status`, `mcp list`, `doctor` JSON output leak macOS `/private` symlink-canonicalized cwd instead of user-invocation cwd — automation that string-matches on cwd breaks across symlinked filesystems** — dogfooded 2026-05-11 by Jobdori on `b98b9a71` in response to Clawhip pinpoint nudge at `1503207549447573574`. Reproduction on macOS: invoke from `/tmp/claw-dog-cwd` (where `/tmp` symlinks to `/private/tmp`), then `claw status --output-format json` returns `workspace.cwd: "/private/tmp/claw-dog-cwd"`, `claw mcp list --output-format json` returns `working_directory: "/private/tmp/claw-dog-cwd"`. The user's invocation cwd (`$PWD`, `pwd`) is `/tmp/claw-dog-cwd`. Source: `session_control.rs:34` calls `fs::canonicalize(cwd)` for #151 cross-worktree session-bleed prevention, then leaks the canonicalized path through every JSON envelope that reports cwd. **Required fix shape:** (a) keep canonicalized cwd for session keying internally, but report user-input cwd (the value passed by `env::current_dir()` or `--cwd` flag) in JSON output as `cwd`; (b) optionally expose canonical path as a separate field `cwd_canonical` for diagnostic purposes; (c) audit every `--output-format json` surface that emits `cwd` / `working_directory` / `workspace.cwd` for the same leak (status, mcp list, doctor, session list, init, etc.); (d) add regression coverage proving JSON cwd matches `$PWD` on macOS where `/tmp -> /private/tmp` symlink exists. **Why this matters:** automation pipelines that route work to lanes by cwd, or that compare cwd against a registry, break across macOS hosts because the canonicalized form differs from the form the user/orchestrator passed. The leak is silent — no documentation indicates the path will be rewritten. Source: Jobdori live dogfood, `b98b9a71`, 2026-05-11. | `ROADMAP.md:L6342` / `roadmap_action` | `alpha_blocker` | `open` | `install_matrix_or_cross_platform_smoke` | `stable_alpha_contracts` | — | | `CC2-RM-A0516-unknown-top-level-subcommands-fall-throu` | **Unknown top-level subcommands fall through to chat prompt path instead of returning `unknown_subcommand` error — typos silently send the subcommand string as a chat message to the configured LLM** — dogfooded 2026-05-11 by Jobdori on `b98b9a71` in response to Clawhip pinpoint nudge at `1503215095088676956`. Reproduction: `unset ANTHROPIC_AUTH_TOKEN; export ANTHROPIC_API_KEY=fake-key-for-routing-test; claw completely-bogus-subcommand --output-format json` returns `{"error":"api returned 401 Unauthorized (authentication_error) [trace req_011...]: invalid x-api-key","kind":"api_http_error"}` — proving the unknown token reached the Anthropic API endpoint as a chat prompt. With valid credentials, the bogus subcommand string would be silently consumed as a chat message, billing the user for a typo and producing whatever continuation the LLM generates. **Pre-error path:** `claw --output-format json` with no creds returns `kind:"missing_credentials"` (the auth gate fires first), masking the routing bug. Only with creds present does the fallthrough manifest as the actual prompt being sent. **Sibling exit-code bug:** when the chat-path 401 returns, the JSON envelope is `kind:"api_http_error"` but exit code is **0**, while `cli_parse` errors (e.g. `--no-such-flag`) and `missing_credentials` errors correctly exit **1**. Exit-code parity between error envelopes is broken — automation that gates on `$?` will treat the 401-as-chat as success. **Required fix shape:** (a) reserve unknown top-level tokens that match no registered subcommand and emit `kind:"unknown_subcommand"` with `unknown:` field and exit code 1, BEFORE the chat fallback path; (b) when a token is intended as a chat prompt, require an explicit verb (`prompt`, `chat`, `ask`) or `--prompt` flag; (c) ensure exit codes are non-zero for all `kind:*_error` envelopes; (d) regression test: `claw --output-format json` with valid auth returns `kind:"unknown_subcommand"` exit 1, never reaches the API. **Why this matters:** automation that calls `claw ` with a programmatically constructed verb (typo, version drift, refactored command) silently bills tokens and produces hallucinated output instead of a typed error. Cross-cluster with #108 (CLI fallthrough discovered earlier) — #422 is the post-#108 audit confirming the routing bug still bites with valid credentials. Source: Jobdori live dogfood, `b98b9a71`, 2026-05-11. | `ROADMAP.md:L6345` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `stable_alpha_contracts` | — | | `CC2-RM-A0519-config-file-precedence-claw-settings-jso` | **Config file precedence (`.claw/settings.json` always wins over `.claw.json`) is undocumented in user-facing surfaces — `config --output-format json` reports both files as `loaded:true` with no `precedence_rank` or `wins_for_keys` attribution; sibling: deprecation warning fires 4× per status invocation (was 3× in #424, regression upward)** — dogfooded 2026-05-11 by Jobdori on `d7dbe951` in response to Clawhip pinpoint nudge at `1503237744451649537`. Reproduction: create `.claw.json` with `{"model":"anthropic/claude-sonnet-4-6"}` and `.claw/settings.json` with `{"model":"anthropic/claude-opus-4-7"}` in the same workspace. `claw status --output-format json` returns `model:"anthropic/claude-opus-4-7", model_source:"config"`. Reverse the files (.claw.json=opus, settings.json=sonnet) → `model:"anthropic/claude-sonnet-4-6"`. Confirmed: `.claw/settings.json` **always** wins over `.claw.json` for conflicting keys, regardless of file mtime or alphabetical order. `claw config --output-format json` reports both as `loaded:true` with no `precedence_rank`, `effective_for_keys`, or `shadowed_keys` attribution. The only signal of precedence is the final merged value in `status` — automation cannot programmatically discover which file contributed which key without re-implementing the merge logic. **Sibling bug (regression from #424):** the `enabledPlugins` deprecation warning now fires **4 times** in stderr per single `status` invocation (was 3× in #424's probe at HEAD `6c0c305a`; current HEAD `d7dbe951` shows 4×). Config load count went up by 1. **Sibling bug observed in config-section probe:** `claw config model --output-format json` with a `.claw.json` that contains a benign unknown key (e.g., `"alpha":"x"`) returns `{"error":"/path/.claw.json: unknown key \"alpha\" (line 1)","kind":"unknown"}` — the entire config command fails with a generic `unknown` kind instead of (a) tolerating unrecognized keys with a warning, or (b) emitting a typed `kind:"unknown_key"` error scoped to the offending file/key. **Required fix shape:** (a) document precedence order in `USAGE.md` (`.claw/settings.local.json > .claw/settings.json > .claw.json` for project scope; `user`/`system` scope at each layer); (b) add `precedence_rank:int` and optional `wins_for_keys:[string]` / `shadowed_keys:[string]` to each entry in `config --output-format json` `files[]`; (c) dedupe the deprecation warning to fire **once per discovered file** instead of N× per load pass; (d) make `config

--output-format json` tolerate unknown keys with warnings, OR emit `kind:"unknown_key"` with `path:` and `key:` fields scoped to the offending file. **Why this matters:** users mixing legacy `.claw.json` with new `.claw/settings.json` have no way to verify which file is actually controlling their runtime. The undocumented precedence + missing per-key attribution forces trial-and-error to debug config drift. Cross-references #407 (config files no load_error) and #415 (config section returns merged_keys count not values). Source: Jobdori live dogfood, `d7dbe951`, 2026-05-11. | `ROADMAP.md:L6354` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `stable_alpha_contracts` | — | | `CC2-RM-A0520-anthropic-model-env-var-bypasses-the-inv` | **`ANTHROPIC_MODEL` env var bypasses the `invalid_model_syntax` validator that `--model` enforces — bogus model strings are accepted with `status:"ok"`, deferred-failing only when the first API call is made** — dogfooded 2026-05-11 by Jobdori on `3730b459` in response to Clawhip pinpoint nudge at `1503245298800136296`. Reproduction (asymmetric validation): `claw --model bogus-model-xyz status --output-format json` returns `kind:"invalid_model_syntax"` exit 1; `ANTHROPIC_MODEL=bogus-model-xyz claw status --output-format json` returns `model:"bogus-model-xyz", model_raw:"bogus-model-xyz", model_source:"env", status:"ok"` — the doctor surface lies that the configured model is valid when it is not. The bogus model only manifests as a failure when the first prompt fires and the API rejects it with 404/400. Three sibling discoveries in the same probe: (a) **alias indirection invisible**: `ANTHROPIC_MODEL=opus claw status --output-format json` returns `model:"claude-opus-4-6", model_raw:"opus", model_source:"env"` — the `opus` alias resolves to `claude-opus-4-6` (the *previous* frontier, not the current `claude-opus-4-7` released 2026-04-16). Users typing `opus` get yesterday's model with no warning. (b) **`CLAW_MODEL` env var silently ignored**: `CLAW_MODEL=opus claw status` shows `model:"claude-opus-4-6" model_source:"default"` — the `CLAW_MODEL` env var (the project-namespaced equivalent that users expect) does not exist; only `ANTHROPIC_MODEL` is honored. No warning when a `CLAW_*` env var that looks like it should work is set. (c) **`ANTHROPIC_DEFAULT_MODEL` also silently ignored**: the longer-named env var that some Anthropic SDKs use is not recognized. **Required fix shape:** (a) symmetric validation: `ANTHROPIC_MODEL` env value must pass the same `invalid_model_syntax` check that `--model` does, and `claw status` must return `kind:"invalid_model"` / `status:"warn"` (not `status:"ok"`) when the resolved model is unrecognized; (b) expose alias resolution in `status`: add `model_alias_resolved_to:string\|null` field so automation can see `opus → claude-opus-4-6`; (c) bump the `opus` alias to `claude-opus-4-7` (current frontier) or document the alias-to-version mapping policy explicitly; (d) accept `CLAW_MODEL` and `ANTHROPIC_DEFAULT_MODEL` env vars with parity to `ANTHROPIC_MODEL`, OR emit a warning when those env vars are set but unrecognized. **Why this matters:** the most common automation pattern is `export ANTHROPIC_MODEL=...` in a shell rc file. Bogus values pass silently, alias indirection hides the actual model in use, and `CLAW_MODEL` looking like a working name but doing nothing is a footgun. Cross-references #424 (bare canonical names rejected at validator level) — together #424 + #426 make model selection inconsistent across CLI flag, env var, and alias paths. Source: Jobdori live dogfood, `3730b459`, 2026-05-11. | `ROADMAP.md:L6357` / `roadmap_action` | `beta_adoption` | `deferred_with_rationale` | `install_matrix_or_cross_platform_smoke` | `stable_alpha_contracts` | Deferred by roadmap/approved plan until prerequisite contracts or post-2.0 research admission gates are satisfied. | | `CC2-RM-A0523-no-global-cwd-c-directory-flag-claw-cann` | **No global `--cwd`/`-C`/`--directory` flag — `claw` cannot be invoked against an arbitrary working directory without first `cd`-ing into it; `--cwd` only exists as a subcommand option for `system-prompt`, and the `cli_parse` "Did you mean --acp?" suggestion is misleading (the `--acp` flag is unrelated to directory selection)** — dogfooded 2026-05-11 by Jobdori on `ec882f4c` in response to Clawhip pinpoint nudge at `1503267943285264394`. Reproduction: `claw --cwd /tmp/claw-dog-cwd status --output-format json` → `{"error":"unknown option: --cwd","hint":"Did you mean --acp?\nRun `claw --help` for usage.","kind":"cli_parse"}`. Same error for `--cwd `, `--cwd `, `--cwd `, `--cwd ""`. Inspecting `claw --help`: `--cwd PATH` appears ONLY in the usage line `claw system-prompt [--cwd PATH] [--date YYYY-MM-DD]` — it is not a global flag and is not accepted by `status`, `doctor`, `mcp list`, `init`, or any other subcommand. Users programmatically running claw against multiple workspaces must `cd` into each one before invoking, breaking the `subprocess.run(['claw', 'status', '--cwd', ws], cwd=other_dir)` pattern that every other major CLI (cargo `-C`, git `-C`, npm `--prefix`, gh `--repo` semantically, kubectl `--kubeconfig`+`--context`) supports. **Sibling misleading-suggestion bug:** the `cli_parse` error's `hint` field suggests `Did you mean --acp?` for `--cwd`. `--acp` is the alias for ACP/Zed editor integration (entirely unrelated to working directory). The Levenshtein-distance auto-complete is matching on first-character similarity without considering semantic relatedness. Users following the hint get a totally orthogonal feature. **Required fix shape:** (a) add a global `--cwd PATH` / `-C PATH` flag accepted before any subcommand, parsed in the global flag pre-pass; (b) validate the path exists and is a directory; emit `kind:"invalid_cwd"` with `path:` and `reason:` (`"not_found"`/`"not_a_directory"`/`"empty"`) when validation fails; (c) document the precedence: `--cwd` flag > `$PWD` > `env::current_dir()`; (d) fix the "Did you mean" hint algorithm to filter suggestions by semantic category (don't suggest `--acp` for `--cwd`; suggest `claw system-prompt --cwd PATH` if the user clearly wants `cwd` override but used the wrong scope); (e) regression test: `claw --cwd /tmp status --output-format json` from any `$PWD` returns `workspace.cwd:"/private/tmp"` (or `cwd:"/tmp"` after #421 fix). **Why this matters:** every claw automation orchestrator runs claw against multiple workspaces from a single parent process. Forcing `cd` before each invocation breaks parallelism (can't use shared cwd across concurrent invocations), breaks subprocess wrappers that want to pass cwd explicitly, and breaks `xargs`/`parallel`-style pipelines. Cross-references #421 (cwd canonicalization leak — fix should canonicalize but report user-input via `--cwd`). Source: Jobdori live dogfood, `ec882f4c`, 2026-05-11. | `ROADMAP.md:L6366` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `stable_alpha_contracts` | — | | `CC2-RM-A0526-allowedtools-validator-inconsistency-too` | **`--allowedTools` validator inconsistency: tool name list is half snake_case (`bash`, `read_file`, `write_file`, `edit_file`, `glob_search`, `grep_search`) and half PascalCase (`WebFetch`, `WebSearch`, `TodoWrite`, `Skill`, `Agent`, `Sleep`) with three UPPERCASE entries (`REPL`, `LSP`, `MCP`); accepts undocumented CamelCase aliases (`Read`, `Write`, `Edit`) and silently translates them to snake_case; argument parsing consumes the next positional when value is missing** — dogfooded 2026-05-11 by Jobdori on `fad53e2d` in response to Clawhip pinpoint nudge at `1503283046856655029`. Reproduction: `claw --allowedTools status --output-format json` → `{"error":"unsupported tool in --allowedTools: status (expected one of: bash, read_file, write_file, edit_file, glob_search, grep_search, WebFetch, WebSearch, TodoWrite, Skill, Agent, ToolSearch, NotebookEdit, Sleep, SendUserMessage, Config, EnterPlanMode, ExitPlanMode, StructuredOutput, REPL, PowerShell, AskUserQuestion, TaskCreate, RunTaskPacket, TaskGet, TaskList, TaskStop, TaskUpdate, TaskOutput, WorkerCreate, WorkerGet, WorkerObserve, WorkerResolveTrust, WorkerAwaitReady, WorkerSendPrompt, WorkerRestart, WorkerTerminate, WorkerObserveCompletion, TeamCreate, TeamDelete, CronCreate, CronDelete, CronList, LSP, ListMcpResources, ReadMcpResource, McpAuth, RemoteTrigger, MCP, TestingPermission)","kind":"unknown"}`. The `status` subcommand was consumed as the `--allowedTools` value because the flag parser doesn't distinguish missing-value from end-of-flag-args. The error reveals **the supported tool list mixes naming conventions inconsistently within a single error message**: snake_case (`bash`, `read_file`, `write_file`, `edit_file`, `glob_search`, `grep_search`), PascalCase (`WebFetch`, `WebSearch`, `TodoWrite`, `Skill`, `Agent`, `Sleep`, `Config`, `PowerShell`, `AskUserQuestion`, `TaskCreate`, `WorkerCreate`, `TeamCreate`, `CronCreate`), UPPERCASE (`REPL`, `LSP`, `MCP`), and CamelCase compounds (`McpAuth`, `RemoteTrigger`). **Hidden alias mapping**: `claw --allowedTools Read,Write,Edit status --output-format json` is accepted and returns `allowed_tools.entries:["edit_file","read_file","write_file"]` — proving the validator has an undocumented CamelCase→snake_case alias map (`Read`→`read_file`, `Write`→`write_file`, `Edit`→`edit_file`) that is not surfaced in the error message. Users who copy-paste tool names from Claude Code documentation work, users who copy from the validator error don't. **Sibling missing-value bug:** `claw --allowedTools status` with `status` as a positional subcommand is interpreted as `--allowedTools=status`, swallowing the subcommand. The flag parser must require a value for `--allowedTools` and emit `kind:"missing_argument"` when followed by a recognized subcommand or `--`-prefixed flag instead of silently treating the next arg as a tool name. **Sibling typed-kind bug:** both errors use `kind:"unknown"` instead of typed `kind:"invalid_tool_name"` / `kind:"missing_argument"` — the catch-all keeps appearing (#422/#423/#424/#428/#430/#431/#432). **Required fix shape:** (a) standardize the canonical tool-name registry on one casing convention (snake_case is most CLI-ergonomic) and update both the registry and all CamelCase aliases; (b) document and expose the alias map (`tool_aliases:{Read:"read_file",...}`) in `claw doctor`/`status` and in the validator error; (c) flag parser must require a value for `--allowedTools` and refuse to consume a recognized subcommand or `-`/`--`-prefixed token as the value, emit `kind:"missing_argument"` with `argument:"--allowedTools"`; (d) emit `kind:"invalid_tool_name"` with `tool_name:` and `available:[]` fields instead of `kind:"unknown"`; (e) regression test that `claw --allowedTools ` rejects with `missing_argument`, and that the canonical name list in errors uses the same casing as the alias map. **Why this matters:** `--allowedTools` is the primary surface for restricting claw's tool surface area (security-relevant). Inconsistent naming between the validator error and the alias map means users following the error message guidance pick names that work in some places and fail in others. The missing-value bug silently swallows a subcommand, leading to confusing "unsupported tool: status" errors when the user actually wanted to run `claw status`. Cross-references #94/#97/#101/#106/#115/#123 (permission-rule audit), #428 (default permission_mode), #422/#423/#424/#428/#430/#431 (`kind:"unknown"` catch-all). Source: Jobdori live dogfood, `fad53e2d`, 2026-05-11. | `ROADMAP.md:L6375` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `stable_alpha_contracts` | — | | `CC2-RM-A0528-posix-end-of-flags-separator-is-not-reco` | **POSIX `--` end-of-flags separator is not recognized — `claw -- "-prompt-with-dash"` returns `{"error":"unknown option: --","hint":"Did you mean -V?","kind":"cli_parse"}` instead of treating subsequent args as positional; shorthand prompt mode cannot accept dash-prefixed prompts at all** — dogfooded 2026-05-11 by Jobdori on `0e5f6958` in response to Clawhip pinpoint nudge at `1503298142286905484`. Reproduction: `claw -- "-prompt-with-dash" --output-format json` returns `{"error":"unknown option: --","hint":"Did you mean -V?\nRun \`claw --help\` for usage.","kind":"cli_parse"}`. The POSIX/GNU CLI convention — universally honored by cargo, git, npm, gh, kubectl, grep, ls, find, etc. — is that `--` terminates flag parsing and treats everything after it as positional arguments. claw rejects `--` itself as an unknown flag. **Sibling misleading-suggestion bug (recurring from #429):** the `cli_parse` hint suggests `Did you mean -V?` for `--`. `-V` is the version flag; `--` is the end-of-flags separator. They have no semantic relationship; the auto-complete is matching on prefix-character similarity only. **Sibling shorthand-prompt limitation:** `claw "-just a prompt" --output-format json` returns `{"error":"unknown option: -just a prompt","kind":"cli_parse"}` and `claw "--bogus-flag-like" --output-format json` returns the same. The shorthand non-interactive prompt mode (documented as `claw [--model MODEL] [--output-format text\|json] TEXT`) cannot accept any TEXT that starts with `-` or `--`, even when the entire string is shell-quoted as a single token. Users must use the explicit `prompt` verb (`claw prompt "-prompt-with-dash"` works) to escape this, but the explicit verb is documented as alternative not required. **Required fix shape:** (a) accept POSIX `--` as the end-of-flags marker globally — every arg after `--` is positional; (b) shorthand prompt mode must distinguish "this looks like a flag" from "this is a quoted positional that happens to start with `-`" by looking at whether the token matches any registered flag name (`-h`, `-V`, `--help`, `--version`, etc.) — strings that don't match any flag should be treated as prompt text; (c) fix the "Did you mean" hint algorithm to filter by semantic category (don't suggest `-V` for `--`, suggest "use \`--\` to terminate flag parsing" if the user types just `--`); (d) regression test: `claw -- "-foo"` reaches the runtime with prompt=`-foo`; `claw "-not-a-flag"` is treated as shorthand prompt when no registered flag matches; canonical `--` is recognized. **Why this matters:** POSIX `--` is the universal mechanism for passing arbitrary text (filenames starting with `-`, prompts containing flag-like syntax, log lines, etc.) to a CLI. Failing on `--` makes claw fundamentally unergonomic in shell pipelines (`echo "-q for quiet" \| xargs claw` fails). The shorthand-prompt limitation forces users to remember the `prompt` verb specifically when their prompt happens to start with `-`. Cross-references #422 (unknown subcommand fallthrough), #423 (stdin not consumed by prompt), #429 ("Did you mean --acp" misleading suggestion). Source: Jobdori live dogfood, `0e5f6958`, 2026-05-11. | `ROADMAP.md:L6381` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `stable_alpha_contracts` | — | | `CC2-RM-A0533-memory-file-discovery-walks-all-ancestor` | **Memory file discovery walks ALL ancestor directories up to `$HOME` boundary, silently loading any `CLAUDE.md` it finds — `/tmp/CLAUDE.md` left from a previous test silently bleeds into every project under `/tmp/*/`; no `--no-parent-memory` flag, no `.no-claude-md-boundary` marker file to limit discovery scope** — dogfooded 2026-05-11 by Jobdori on `f4a96740` in response to Clawhip pinpoint nudge at `1503335892461293675`. Reproduction: create three nested `CLAUDE.md` files with unique markers — `/tmp/claw-nested-probe/CLAUDE.md` (`PARENT_CLAUDE`), `subproj/CLAUDE.md` (`CHILD_CLAUDE`), `subproj/deep/CLAUDE.md` (`DEEP_CLAUDE`). Run `claw system-prompt --output-format json` from `subproj/deep/nest/` (note: `nest` has no `CLAUDE.md`). The `message` field contains **all three markers** (PARENT + CHILD + DEEP) and `status --output-format json` reports `memory_file_count: 3`. Boundary tests: (a) `$HOME/CLAUDE.md` is NOT picked up from `/tmp/no-claude-dir` (discovery stops at `$HOME` boundary, good); (b) From `/tmp/deep` (no nested CLAUDE.md), `/tmp/CLAUDE.md` IS picked up (count: 1); (c) git-root is NOT a discovery boundary — running from a git subdir still walks above the git root. **Ambient-context-bleed footgun:** any stale `/tmp/CLAUDE.md` (or `/home//projects/CLAUDE.md`, or any ancestor-path CLAUDE.md left over from a previous experiment, copy-paste, or AI-generated example) silently bleeds into every workspace nested below it. The user has no signal in `status --output-format json` indicating which ancestor file is contributing — only the aggregate `memory_file_count`. **Three required fixes:** (a) **expose discovery list**: `status --output-format json` and `system-prompt --output-format json` must include `memory_files:[{path, source:"workspace"\|"ancestor"\|"parent_dir"\|"home", chars, contributes:bool}]` so users can see what's leaking in; (b) **add `--no-parent-memory` flag** to limit discovery to cwd only (no ancestor walk), or add a boundary marker (`.claude-no-walk`, `.claw-root`, or honor `.git` as the boundary by default — most users expect repo-root scope); (c) **`doctor` warns** when ancestor `CLAUDE.md` files are loaded from outside the current git repo (suggests they may be unintentional). **Sibling discovery scope question:** discovery walks up to `$HOME` — but for a user with a project at `/Users/foo/work/proj`, that's `/Users/foo/work/CLAUDE.md` + `/Users/foo/CLAUDE.md` (if it exists) both load. The home boundary is exclusive, but the entire `/Users/foo` tree under home is in scope. **Why this matters:** test workspaces, scratch dirs, AI-generated example projects, and shared `/tmp` workdirs are full of stale `CLAUDE.md` files. The current discovery rule means every claw invocation can silently inherit context from arbitrary ancestor paths. Cross-references #438 (memory discovery only finds CLAUDE.md, not AGENTS.md or CLAW.md), #421 (cwd canonicalization leak — the canonicalized form determines which ancestor walk path is used). Source: Jobdori live dogfood, `f4a96740`, 2026-05-11. | `ROADMAP.md:L6396` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | `stable_alpha_contracts` | — | | `CC2-RM-A0537-claw-acp-serve-exits-0-with-status-disco` | **`claw acp serve` exits 0 with `status:"discoverability_only", supported:false` instead of failing — automation pipelines see "success" from a command that explicitly says "not implemented"; ROADMAP #413's internal-tracking leak (`discoverability_tracking:"ROADMAP #64a"`, `tracking:"ROADMAP #76"`) still present despite being filed 2026-04-30** — dogfooded 2026-05-11 by Jobdori on `19aaf9d0` in response to Clawhip pinpoint nudge at `1503366101533200435`. Reproduction: `claw acp serve --output-format json` returns exit code **0** with envelope `{aliases:["acp","--acp","-acp"], discoverability_tracking:"ROADMAP #64a", kind:"acp", launch_command:null, message:"ACP/Zed editor integration is not implemented in claw-code yet. \`claw acp serve\` is only a discoverability alias today; it does not launch a daemon or Zed-specific protocol endpoint. Use the normal terminal surfaces for now and track ROADMAP #76 for real ACP support.", recommended_workflows:["claw prompt TEXT","claw","claw doctor"], serve_alias_only:true, status:"discoverability_only", supported:false, tracking:"ROADMAP #76"}`. The exit code is 0 (success) but the command explicitly states it is not implemented. Pipeline like `claw acp serve && zed --connect localhost:12345` will proceed to the zed connect step despite `acp serve` being a no-op. The only signal of no-op is `supported:false` in the JSON body — easy to miss for automation gating on `$?`. **ROADMAP #413 reproduction confirmed unfixed:** #413 (filed 2026-04-30) called out `discoverability_tracking:"ROADMAP #64a"` and `tracking:"ROADMAP #76"` as internal ticket references leaked into public JSON. **11 days later, both fields are still present in the envelope.** The fix was prescribed but never landed. Also `recommended_workflows:["claw prompt TEXT","claw","claw doctor"]` is internal scaffolding (curated suggestion list) exposed as a top-level public field — not normally part of an "ACP status" public contract. **Sibling unknown-subcommand bug:** `claw acp status --output-format json` (a reasonable next-thing-to-try) returns `{"error":"unsupported ACP invocation. Use \`claw acp\`, \`claw acp serve\`, \`claw --acp\`, or \`claw -acp\`.","kind":"unknown"}` exit 0 — the `kind:"unknown"` catch-all yet again (#422/#423/#424/#428/#430/#431/#432/#433/#435/#440/#441/#442 — **14th occurrence**), should be `kind:"unsupported_acp_invocation"`. **Required fix shape:** (a) `claw acp serve` exits **non-zero** (exit code 2 = "not implemented" is conventional) so automation `$?`-gating detects the no-op; (b) deliver #413's fix: remove `discoverability_tracking` and `tracking` top-level fields, OR move them under an optional `_meta` sub-object gated on a debug flag; (c) replace `message` prose with a typed `reason:"not_implemented"` enum + optional `detail` string for downstream pipelines that need a stable signal; (d) drop `recommended_workflows` from the ACP envelope OR move it under `_meta`; (e) the `status:"discoverability_only"` value is non-standard — replace with `status:"not_implemented"` (matching the `supported:false` boolean); (f) typed `kind:"unsupported_acp_invocation"` for the bad-arg path. **Why this matters:** ACP/Zed integration is the integration point for IDE-based AI workflows. A "success" exit code on a "not implemented" stub breaks the contract for any wrapper script that tries to detect ACP availability via `claw acp serve && ...`. The internal-tracking-ID leak (#413) being unfixed for 11 days suggests the JSON envelope audit isn't being executed against the ROADMAP backlog. Cross-references #413 (internal tracking leak — unfixed), #422 (exit-code parity), `kind:"unknown"` catch-all cluster. Source: Jobdori live dogfood, `19aaf9d0`, 2026-05-11. | `ROADMAP.md:L6408` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | `stable_alpha_contracts` | — | | `CC2-ISSUE-CLAW-OPEN-LATEST-3004` | When can we adapt to zed? I'm tired of the memory usage of vscode+claude code | `.omx/research/claw-open-latest.json#issue-3004` / `latest_open_issue` | `2.x_intake` | `open` | `issue_acceptance_repro_or_triage_decision` | `roadmap_board_triage` | Latest issue intake is admitted only when it matches freeze/admission rules; otherwise remains 2.x_intake. | | `CC2-ISSUE-CLAW-ISSUES-3004` | When can we adapt to zed? I'm tired of the memory usage of vscode+claude code | `.omx/research/claw-issues.json#issue-3004` / `issue_theme` | `beta_adoption` | `open` | `issue_acceptance_repro_or_triage_decision` | `roadmap_board_triage` | — | | `CC2-PARITY-OPENCODE-REPO-CONTEXT` | Parity source metadata: anomalyco/opencode | `.omx/research/opencode-repo.json` / `parity_repo_context` | `context` | `context` | `none_context_only` | none | — | | `CC2-PARITY-CODEX-REPO-CONTEXT` | Parity source metadata: openai/codex | `.omx/research/codex-repo.json` / `parity_repo_context` | `context` | `context` | `none_context_only` | none | — | ### Stream 0 — Governance, intake, and cross-cutting roadmap triage | ID | Title | Source | Bucket | Lifecycle | Verification | Dependencies | Deferral | | --- | --- | --- | --- | --- | --- | --- | --- | | `CC2-RM-H0001-clawable-coding-harness-roadmap` | Clawable Coding Harness Roadmap | `ROADMAP.md:L1` / `roadmap_heading` | `context` | `context` | `none_context_only` | none | — | | `CC2-RM-H0002-goal` | Goal | `ROADMAP.md:L3` / `roadmap_heading` | `context` | `context` | `none_context_only` | none | — | | `CC2-RM-H0003-definition-of-clawable` | Definition of "clawable" | `ROADMAP.md:L14` / `roadmap_heading` | `context` | `context` | `none_context_only` | none | — | | `CC2-RM-H0004-current-pain-points` | Current Pain Points | `ROADMAP.md:L25` / `roadmap_heading` | `context` | `context` | `none_context_only` | none | — | | `CC2-RM-H0005-1-session-boot-is-fragile` | 1. Session boot is fragile | `ROADMAP.md:L27` / `roadmap_heading` | `beta_adoption` | `active` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-H0006-2-truth-is-split-across-layers` | 2. Truth is split across layers | `ROADMAP.md:L32` / `roadmap_heading` | `beta_adoption` | `active` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-H0011-7-human-ux-still-leaks-into-claw-workflo` | 7. Human UX still leaks into claw workflows | `ROADMAP.md:L58` / `roadmap_heading` | `beta_adoption` | `active` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-H0012-product-principles` | Product Principles | `ROADMAP.md:L61` / `roadmap_heading` | `context` | `context` | `none_context_only` | none | — | | `CC2-RM-H0013-roadmap` | Roadmap | `ROADMAP.md:L71` / `roadmap_heading` | `context` | `context` | `none_context_only` | none | — | | `CC2-RM-H0083-immediate-backlog-from-current-real-pain` | Immediate Backlog (from current real pain) | `ROADMAP.md:L1062` / `roadmap_heading` | `context` | `context` | `none_context_only` | none | — | | `CC2-RM-H0084-deployment-architecture-gap-filed-from-d` | Deployment Architecture Gap (filed from dogfood 2026-04-08) | `ROADMAP.md:L1131` / `roadmap_heading` | `beta_adoption` | `active` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-H0086-startup-friction-gap-no-default-trusted` | Startup Friction Gap: No Default trusted_roots in Settings (filed 2026-04-08) | `ROADMAP.md:L1150` / `roadmap_heading` | `alpha_blocker` | `active` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-H0087-every-lane-starts-with-manual-trust-baby` | Every lane starts with manual trust babysitting unless caller explicitly passes roots | `ROADMAP.md:L1152` / `roadmap_heading` | `alpha_blocker` | `active` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-H0088-observability-transport-decision-filed-2` | Observability Transport Decision (filed 2026-04-08) | `ROADMAP.md:L1168` / `roadmap_heading` | `context` | `context` | `none_context_only` | none | — | | `CC2-RM-H0089-canonical-state-surface-cli-file-based-h` | Canonical state surface: CLI/file-based. HTTP endpoint deferred. | `ROADMAP.md:L1170` / `roadmap_heading` | `beta_adoption` | `deferred_with_rationale` | `targeted_regression_or_acceptance_test_required` | none | Deferred by roadmap/approved plan until prerequisite contracts or post-2.0 research admission gates are satisfied. | | `CC2-RM-H0092-pinpoint-122-doctor-invocation-does-not` | Pinpoint #122. `doctor` invocation does not check stale-base condition; `run_stale_base_preflight()` is only invoked in Prompt + REPL paths | `ROADMAP.md:L5061` / `roadmap_heading` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | none | — | | `CC2-RM-H0093-pinpoint-135-claw-status-json-missing-ac` | Pinpoint #135. `claw status --json` missing `active_session` boolean and `session.id` cross-reference — two surfaces that should be unified are inconsistent | `ROADMAP.md:L5088` / `roadmap_heading` | `beta_adoption` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-H0094-pinpoint-134-no-run-correlation-id-at-se` | Pinpoint #134. No run/correlation ID at session boundary — every observer must infer session identity from timing or prompt content | `ROADMAP.md:L5109` / `roadmap_heading` | `beta_adoption` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-H0097-evidence-for-138-feat-134-135-session-id` | Evidence for #138 — feat/134-135-session-identity branch is pushed but no PR was opened (2026-04-21 15:05) | `ROADMAP.md:L5191` / `roadmap_heading` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | none | — | | `CC2-RM-H0098-pinpoint-139-claw-state-error-message-re` | Pinpoint #139. `claw state` error message refers to "worker" concept that is not discoverable via `--help` or any documented command — error is unactionable for claws and CI | `ROADMAP.md:L5226` / `roadmap_heading` | `alpha_blocker` | `open` | `docs_snapshot_or_help_output_check` | none | — | | `CC2-RM-H0099-pinpoint-141-claw-subcommand-help-has-5` | Pinpoint #141. `claw --help` has 5 different behaviors — inconsistent help surface breaks discoverability | `ROADMAP.md:L5278` / `roadmap_heading` | `beta_adoption` | `open` | `docs_snapshot_or_help_output_check` | none | — | | `CC2-RM-H0100-pinpoint-142-claw-init-output-format-jso` | Pinpoint #142. `claw init --output-format json` dumps human text into `message` — no structured fields for created/skipped files | `ROADMAP.md:L5333` / `roadmap_heading` | `alpha_blocker` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-H0103-pinpoint-145-claw-plugins-subcommand-not` | Pinpoint #145. `claw plugins` subcommand not wired to CLI parser — word gets treated as a prompt, hits Anthropic API | `ROADMAP.md:L5551` / `roadmap_heading` | `beta_adoption` | `open` | `provider_routing_contract_test` | none | — | | `CC2-RM-H0104-pinpoint-146-claw-config-and-claw-diff-a` | Pinpoint #146. `claw config` and `claw diff` are pure-local introspection commands but require `--resume SESSION.jsonl` wrapping | `ROADMAP.md:L5609` / `roadmap_heading` | `beta_adoption` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-H0105-pinpoint-147-claw-claw-silently-fall-thr` | Pinpoint #147. `claw ""` / `claw " "` silently fall through to prompt-execution path; empty-prompt guard is subcommand-only | `ROADMAP.md:L5650` / `roadmap_heading` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | none | — | | `CC2-RM-H0106-pinpoint-148-claw-status-json-shows-reso` | Pinpoint #148. `claw status` JSON shows resolved model but not raw input or source — post-hoc "why did my --model flag behave this way?" requires re-reading argv | `ROADMAP.md:L5696` / `roadmap_heading` | `beta_adoption` | `open` | `provider_routing_contract_test` | none | — | | `CC2-RM-H0107-same-resolved-value-can-come-from-three` | Same resolved value can come from three different sources; | `ROADMAP.md:L5709` / `roadmap_heading` | `context` | `context` | `none_context_only` | none | — | | `CC2-RM-H0108-json-envelope-gives-no-way-to-distinguis` | JSON envelope gives no way to distinguish. | `ROADMAP.md:L5710` / `roadmap_heading` | `context` | `context` | `none_context_only` | none | — | | `CC2-RM-H0110-pinpoint-150-resume-latest-restores-the` | Pinpoint #150. `resume_latest_restores_the_most_recent_managed_session` flakes due to symlink/canonicalization mismatch | `ROADMAP.md:L5797` / `roadmap_heading` | `beta_adoption` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-H0111-pinpoint-246-reminder-cron-outcome-ambig` | Pinpoint #246. Reminder cron outcome ambiguity — no structured feedback on nudge delivery/skip/timeout | `ROADMAP.md:L5824` / `roadmap_heading` | `alpha_blocker` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-H0112-pinpoint-151-workspace-fingerprint-path` | Pinpoint #151. `workspace_fingerprint` path-equivalence contract gap (product, not just test) | `ROADMAP.md:L5851` / `roadmap_heading` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | none | — | | `CC2-RM-H0113-pinpoint-152-diagnostic-verb-suffixes-al` | Pinpoint #152. Diagnostic verb suffixes allow arbitrary positional args, emit double "error:" prefix | `ROADMAP.md:L5904` / `roadmap_heading` | `alpha_blocker` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-H0115-pinpoint-154-model-syntax-error-doesn-t` | Pinpoint #154. Model syntax error doesn't hint at env var when multiple credentials present | `ROADMAP.md:L5953` / `roadmap_heading` | `beta_adoption` | `open` | `provider_routing_contract_test` | none | — | | `CC2-RM-H0120-pinpoint-159-run-turn-loop-hardcodes-emp` | Pinpoint #159. `run_turn_loop` hardcodes empty denied_tools — permission denials silently absent from multi-turn sessions | `ROADMAP.md:L6094` / `roadmap_heading` | `alpha_blocker` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-H0121-pinpoint-160-session-store-has-no-list-s` | Pinpoint #160. `session_store` has no `list_sessions`, `delete_session`, or `session_exists` — claw cannot enumerate or clean up sessions without filesystem hacks | `ROADMAP.md:L6123` / `roadmap_heading` | `beta_adoption` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-H0122-asdict-dataclass-load-session-save-sessi` | ['asdict', 'dataclass', 'load_session', 'save_session'] | `ROADMAP.md:L6133` / `roadmap_heading` | `context` | `context` | `none_context_only` | none | — | | `CC2-RM-H0123-list-sessions-delete-session-session-exi` | list_sessions, delete_session, session_exists — all absent | `ROADMAP.md:L6134` / `roadmap_heading` | `context` | `context` | `none_context_only` | none | — | | `CC2-RM-H0124-works-today-breaks-if-the-dir-layout-eve` | Works today, breaks if the dir layout ever changes — no abstraction layer | `ROADMAP.md:L6141` / `roadmap_heading` | `context` | `context` | `none_context_only` | none | — | | `CC2-RM-A0003-recovery-before-escalation-known-failure` | **Recovery before escalation** — known failure modes should auto-heal once before asking for help. | `ROADMAP.md:L65` / `roadmap_action` | `beta_adoption` | `open` | `docs_snapshot_or_help_output_check` | none | — | | `CC2-RM-A0006-terminal-is-transport-not-truth-tmux-tui` | **Terminal is transport, not truth** — tmux/TUI may remain implementation details, but orchestration state must live above them. | `ROADMAP.md:L68` / `roadmap_action` | `ga_ecosystem` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-A0014-expand-github-ci-from-single-crate-cover` | Expand GitHub CI from single-crate coverage to workspace-grade verification — **done**: `.github/workflows/rust-ci.yml` now runs `cargo test --workspace` plus fmt/clippy at the workspace level | `ROADMAP.md:L1068` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | none | — | | `CC2-RM-A0015-add-release-grade-binary-workflow-done-g` | Add release-grade binary workflow — **done**: `.github/workflows/release.yml` now builds tagged Rust release artifacts for the CLI | `ROADMAP.md:L1069` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | none | — | | `CC2-RM-A0019-eliminate-warning-spam-from-first-run-he` | Eliminate warning spam from first-run help/build path — **done**: current `cargo run -q -p rusty-claude-cli -- --help` renders clean help output without a warning wall before the product surface | `ROADMAP.md:L1073` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | none | — | | `CC2-RM-A0020-promote-doctor-from-slash-only-to-top-le` | Promote `doctor` from slash-only to top-level CLI entrypoint — **done**: `claw doctor` is now a local shell entrypoint with regression coverage for direct help and health-report output | `ROADMAP.md:L1074` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | none | — | | `CC2-RM-A0021-make-machine-readable-status-commands-ac` | Make machine-readable status commands actually machine-readable — **done**: `claw --output-format json status` and `claw --output-format json sandbox` now emit structured JSON snapshots instead of prose tables | `ROADMAP.md:L1075` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | none | — | | `CC2-RM-A0022-unify-legacy-config-skill-namespaces-in` | Unify legacy config/skill namespaces in user-facing output — **done**: skills/help JSON/text output now present `.claw` as the canonical namespace and collapse legacy roots behind `.claw`-shaped source ids/labels | `ROADMAP.md:L1076` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | none | — | | `CC2-RM-A0024-audit-output-format-contract-across-the` | Audit `--output-format` contract across the whole CLI surface — **done**: direct CLI commands now honor deterministic JSON/text handling across help/version/status/sandbox/agents/mcp/skills/bootstrap-plan/system-prompt/init/doctor, with regression coverage in `output_format_contract.rs` and resumed `/status` JSON coverage | `ROADMAP.md:L1078` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | none | — | | `CC2-RM-A0025-worker-readiness-handshake-trust-resolut` | Worker readiness handshake + trust resolution — **done**: `WorkerStatus` state machine with `Spawning` → `TrustRequired` → `ReadyForPrompt` → `PromptAccepted` → `Running` lifecycle, `trust_auto_resolve` + `trust_gate_cleared` gating | `ROADMAP.md:L1081` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | none | — | | `CC2-RM-A0027-wire-lane-completion-emitter-done-lane-c` | Wire lane-completion emitter — **done**: `lane_completion` module with `detect_lane_completion()` auto-sets `LaneContext::completed` from session-finished + tests-green + push-complete → policy closeout | `ROADMAP.md:L1083` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | none | — | | `CC2-RM-A0029-worker-readiness-handshake-trust-resolut` | Worker readiness handshake + trust resolution — **done**: `WorkerStatus` state machine with `Spawning` → `TrustRequired` → `ReadyForPrompt` → `PromptAccepted` → `Running` lifecycle, `trust_auto_resolve` + `trust_gate_cleared` gating | `ROADMAP.md:L1087` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | none | — | | `CC2-RM-A0038-config-merge-validation-gap-done-config` | **Config merge validation gap** — **done**: `config.rs` hook validation before deep-merge (+56 lines), malformed entries fail with source-path context instead of merged parse errors | `ROADMAP.md:L1096` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | none | — | | `CC2-RM-A0040-commit-provenance-worktree-aware-push-ev` | **Commit provenance / worktree-aware push events** — **done**: `LaneCommitProvenance` now carries branch/worktree/canonical-commit/supersession metadata in lane events, and `dedupe_superseded_commit_events()` is applied before agent manifests are written so superseded commit events collapse to the latest canonical lineage | `ROADMAP.md:L1099` / `roadmap_action` | `alpha_blocker` | `superseded` | `targeted_regression_or_acceptance_test_required` | none | Superseded by a newer roadmap entry or canonical Rust/control-plane contract; keep only for audit traceability. | | `CC2-RM-A0041-orphaned-module-integration-audit-done-r` | **Orphaned module integration audit** — **done**: `runtime` now keeps `session_control` and `trust_resolver` behind `#[cfg(test)]` until they are wired into a real non-test execution path, so normal builds no longer advertise dead clawability surface area. | `ROADMAP.md:L1100` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | none | — | | `CC2-RM-A0044-session-state-classification-gap-working` | **Session state classification gap (working vs blocked vs finished vs truly stale)** — **done**: agent manifests now derive machine states such as `working`, `blocked_background_job`, `blocked_merge_conflict`, `degraded_mcp`, `interrupted_transport`, `finished_pending_report`, and `finished_cleanable`, and terminal-state persistence records commit provenance plus derived state so downstream monitoring can distinguish quiet progress from truly idle sessions. | `ROADMAP.md:L1103` / `roadmap_action` | `beta_adoption` | `stale_done` | `verify_existing_evidence_and_regression_guard` | none | Marked done in roadmap but needs freshness re-verification before being used as release evidence. | | `CC2-RM-A0045-resumed-status-json-parity-gap-done-reso` | **Resumed `/status` JSON parity gap** — **done**: resolved by the broader "Resumed local-command JSON parity gap" work tracked as #26 below. Re-verified on `main` HEAD `8dc6580` — `cargo test --release -p rusty-claude-cli resumed_status_command_emits_structured_json_when_requested` passes cleanly (1 passed, 0 failed), so resumed `/status --output-format json` now goes through the same structured renderer as the fresh CLI path. The original failure (`expected value at line 1 column 1` because resumed dispatch fell back to prose) no longer reproduces. | `ROADMAP.md:L1104` / `roadmap_action` | `beta_adoption` | `stale_done` | `verify_existing_evidence_and_regression_guard` | none | Marked done in roadmap but needs freshness re-verification before being used as release evidence. | | `CC2-RM-A0047-doctor-output-format-json-check-level-st` | **`doctor --output-format json` check-level structure gap** — **done**: `claw doctor --output-format json` now keeps the human-readable `message`/`report` while also emitting structured per-check diagnostics (`name`, `status`, `summary`, `details`, plus typed fields like workspace paths and sandbox fallback data), with regression coverage in `output_format_contract.rs`. | `ROADMAP.md:L1106` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | none | — | | `CC2-RM-A0048-plugin-lifecycle-init-shutdown-test-flak` | **Plugin lifecycle init/shutdown test flakes under workspace-parallel execution** — dogfooding surfaced that `build_runtime_runs_plugin_lifecycle_init_and_shutdown` could fail under `cargo test --workspace` while passing in isolation because sibling tests raced on tempdir-backed shell init script paths. **Done (re-verified 2026-04-11):** the current mainline helpers now isolate plugin lifecycle temp resources robustly enough that both `cargo test -p rusty-claude-cli build_runtime_runs_plugin_lifecycle_init_and_shutdown -- --nocapture` and `cargo test -p plugins plugin_registry_runs_initialize_and_shutdown_for_enabled_plugins -- --nocapture` pass, and the current `cargo test --workspace` run includes both tests as green. Treat the old filing as stale unless a new parallel-execution repro appears. | `ROADMAP.md:L1107` / `roadmap_action` | `beta_adoption` | `stale_done` | `verify_existing_evidence_and_regression_guard` | none | Marked done in roadmap but needs freshness re-verification before being used as release evidence. | | `CC2-RM-A0049-plugins-hooks-collects-and-runs-hooks-fr` | **`plugins::hooks::collects_and_runs_hooks_from_enabled_plugins` flaked on Linux CI, root cause was a stdin-write race not missing exec bit** — **done at `172a2ad` on 2026-04-08**. Dogfooding reproduced this four times on `main` (CI runs [24120271422](https://github.com/ultraworkers/claw-code/actions/runs/24120271422), [24120538408](https://github.com/ultraworkers/claw-code/actions/runs/24120538408), [24121392171](https://github.com/ultraworkers/claw-code/actions/runs/24121392171), [24121776826](https://github.com/ultraworkers/claw-code/actions/runs/24121776826)), escalating from first-attempt-flake to deterministic-red on the third push. Failure mode was `PostToolUse hook .../hooks/post.sh failed to start for "Read": Broken pipe (os error 32)` surfacing from `HookRunResult`. **Initial diagnosis was wrong.** The first theory (documented in earlier revisions of this entry and in the root-cause note on commit `79da4b8`) was that `write_hook_plugin` in `rust/crates/plugins/src/hooks.rs` was writing the generated `.sh` files without the execute bit and `Command::new(path).spawn()` was racing on fork/exec. An initial chmod-only fix at `4f7b674` was shipped against that theory and **still failed CI on run `24121776826`** with the same `Broken pipe` symptom, falsifying the chmod-only hypothesis. **Actual root cause.** `CommandWithStdin::output_with_stdin` in `rust/crates/plugins/src/hooks.rs` was unconditionally propagating `write_all` errors on the child's stdin pipe, including `std::io::ErrorKind::BrokenPipe`. The test hook scripts run in microseconds (`#!/bin/sh` + a single `printf`), so the child exits and closes its stdin before the parent finishes writing the ~200-byte JSON hook payload. On Linux the pipe raises `EPIPE` immediately; on macOS the pipe happens to buffer the small payload before the child exits, which is why the race only surfaced on ubuntu CI runners. The parent's `write_all` returned `Err(BrokenPipe)`, `output_with_stdin` returned that as a hook failure, and `run_command` classified the hook as "failed to start" even though the child had already run to completion and printed the expected message to stdout. **Fix (commit `172a2ad`, force-pushed over `4f7b674`).** Three parts: (1) **actual fix** — `output_with_stdin` now matches the `write_all` result and swallows `BrokenPipe` specifically, while propagating all other write errors unchanged; after a `BrokenPipe` swallow the code still calls `wait_with_output()` so stdout/stderr/exit code are still captured from the cleanly-exited child. (2) **hygiene hardening** — a new `make_executable` helper sets mode `0o755` on each generated `.sh` via `std::os::unix::fs::PermissionsExt` under `#[cfg(unix)]`. This is defense-in-depth for future non-sh hook runners, not the bug that was biting CI. (3) **regression guard** — new `generated_hook_scripts_are_executable` test under `#[cfg(unix)]` asserts each generated `.sh` file has at least one execute bit set (`mode & 0o111 != 0`) so future tweaks cannot silently regress the hygiene change. **Verification.** `cargo test --release -p plugins` 35 passing, fmt clean, clippy `-D warnings` clean; CI run [24121999385](https://github.com/ultraworkers/claw-code/actions/runs/24121999385) went green on first attempt on `main` for the hotfix commit. **Meta-lesson.** `Broken pipe (os error 32)` from a child-process spawn path is ambiguous between "could not exec" and "exec'd and exited before the parent finished writing stdin." The first theory cargo-culted the "could not exec" reading because the ROADMAP scaffolding anchored on the exec-bit guess; falsification came from empirical CI, not from code inspection. Record the pattern: when a pipe error surfaces on fork/exec, instrument what `wait_with_output()` actually reports on the child before attributing the failure to a permissions or issue. | `ROADMAP.md:L1108` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | none | — | | `CC2-RM-A0050-resumed-local-command-json-parity-gap-do` | **Resumed local-command JSON parity gap** — **done**: direct `claw --output-format json` already had structured renderers for `sandbox`, `mcp`, `skills`, `version`, and `init`, but resumed `claw --output-format json --resume /…` paths still fell back to prose because resumed slash dispatch only emitted JSON for `/status`. Resumed `/sandbox`, `/mcp`, `/skills`, `/version`, and `/init` now reuse the same JSON envelopes as their direct CLI counterparts, with regression coverage in `rust/crates/rusty-claude-cli/tests/resume_slash_commands.rs` and `rust/crates/rusty-claude-cli/tests/output_format_contract.rs`. | `ROADMAP.md:L1109` / `roadmap_action` | `alpha_blocker` | `done_verify` | `verify_existing_evidence_and_regression_guard` | none | — | | `CC2-RM-A0055-phantom-completions-root-cause-global-se` | **Phantom completions root cause: global session store has no per-worktree isolation** — | `ROADMAP.md:L1115` / `roadmap_action` | `beta_adoption` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-A0058-writing-workerstatus-to-a-well-known-fil` | Writing `WorkerStatus` to a well-known file path (`.claw/worker-state.json`) that an external observer can poll. | `ROADMAP.md:L1142` / `roadmap_action` | `alpha_blocker` | `open` | `install_matrix_or_cross_platform_smoke` | none | — | | `CC2-RM-A0059-add-a-trusted-roots-field-to-runtimeconf` | Add a `trusted_roots` field to `RuntimeConfig` (or a nested `[trust]` table), loaded via `ConfigLoader`. | `ROADMAP.md:L1161` / `roadmap_action` | `alpha_blocker` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-A0060-in-workerregistry-spawn-worker-merge-con` | In `WorkerRegistry::spawn_worker()`, merge config-level `trusted_roots` with any per-call overrides. | `ROADMAP.md:L1162` / `roadmap_action` | `alpha_blocker` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-A0061-default-empty-list-safest-users-opt-in-b` | Default: empty list (safest). Users opt in by adding their repo paths to settings. | `ROADMAP.md:L1163` / `roadmap_action` | `alpha_blocker` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-A0062-update-config-validate-schema-with-the-n` | Update `config_validate` schema with the new field. | `ROADMAP.md:L1164` / `roadmap_action` | `alpha_blocker` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-A0064-trust-seconds-since-update-60-in-trust-r` | Trust `seconds_since_update > 60` in `trust_required` status as the stall signal. | `ROADMAP.md:L1183` / `roadmap_action` | `alpha_blocker` | `deferred_with_rationale` | `targeted_regression_or_acceptance_test_required` | none | Deferred by roadmap/approved plan until prerequisite contracts or post-2.0 research admission gates are satisfied. | | `CC2-RM-A0065-call-workerresolvetrust-tool-to-unblock` | Call `WorkerResolveTrust` tool to unblock, or `WorkerRestart` to reset. | `ROADMAP.md:L1184` / `roadmap_action` | `alpha_blocker` | `deferred_with_rationale` | `targeted_regression_or_acceptance_test_required` | none | Deferred by roadmap/approved plan until prerequisite contracts or post-2.0 research admission gates are satisfied. | | `CC2-RM-A0306-add-stale-base-check-to-doctor-output-in` | *Add stale-base check to `doctor` output.* In `render_doctor_report()`, collect the same `stale_base::BaseCommitState` that `run_stale_base_preflight()` computes (by calling `check_base_commit(&cwd, resolve_expected_base(None, &cwd).as_ref())` — note: `doctor` never receives `--base-commit` flag value, so expected base comes from `.claw-base` file only). Convert the `BaseCommitState` into a doctor `DiagnosticCheck` (parallel to existing `auth`, `config`, `git_state`, etc.). If `Diverged`, emit `DiagnosticLevel::Warn` with expected and actual commit hashes. If `NotAGitRepo` or `NoExpectedBase`, emit `DiagnosticLevel::Ok`. ~20 lines. | `ROADMAP.md:L5073` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | none | — | | `CC2-RM-A0307-surface-base-commit-source-in-status-jso` | *Surface base_commit source in `status --json` output.* Alongside the existing JSON fields, add `base_commit_expected: \| null` and `base_commit_actual: `. If no `.claw-base` file exists, `base_commit_expected: null`. If diverged, `status` JSON includes both fields so downstream claws can see the mismatch in machine-readable form. ~15 lines. | `ROADMAP.md:L5074` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | none | — | | `CC2-RM-A0308-regression-tests` | *Regression tests.* | `ROADMAP.md:L5075` / `roadmap_action` | `beta_adoption` | `open` | `install_matrix_or_cross_platform_smoke` | none | — | | `CC2-RM-A0309-add-session-id-option-string-and-active` | Add `session_id: Option` and `active_session: bool` to `StatusReport` struct. Both `null`/`false` when no session is active. When a session is running, `session_id` is the same UUID emitted in the startup lane event (#134). | `ROADMAP.md:L5098` / `roadmap_action` | `alpha_blocker` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-A0310-thread-the-session-state-into-the-status` | Thread the session state into the `status` handler via a shared `Arc>` or equivalent (same mechanism #134 uses for startup event emission). | `ROADMAP.md:L5099` / `roadmap_action` | `alpha_blocker` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-A0311-text-mode-claw-status-surfaces-the-value` | Text-mode `claw status` surfaces the value: `Session: active (id: abc123)` or `Session: idle`. | `ROADMAP.md:L5100` / `roadmap_action` | `beta_adoption` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-A0312-regression-tests-a-claw-status-json-befo` | Regression tests: (a) `claw status --json` before any prompt → `active_session: false, session_id: null`. (b) `claw status --json` during a prompt session → `active_session: true, session_id: `. (c) UUID matches the `session.id` in the first lane event of the same run. | `ROADMAP.md:L5101` / `roadmap_action` | `alpha_blocker` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-A0318-only-pre-existing-flake-remains-no-new-r` | `only pre-existing flake remains, no new regressions` (e.g., `resume_latest...` test failure on main that also fails on feature branch) | `ROADMAP.md:L5156` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | none | — | | `CC2-RM-A0326-pushed-branch-exists-on-origin-but-no-pr` | `pushed` — branch exists on origin but no PR (current state for feat/134-135) | `ROADMAP.md:L5210` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | none | — | | `CC2-RM-A0327-in-pr-pr-open-review-pending` | `in-PR` — PR open, review pending | `ROADMAP.md:L5211` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | none | — | | `CC2-RM-A0328-approved-pr-approved-awaiting-merge` | `approved` — PR approved, awaiting merge | `ROADMAP.md:L5212` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | none | — | | `CC2-RM-A0329-merged-in-main` | `merged` — in main | `ROADMAP.md:L5213` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | none | — | | `CC2-RM-A0330-deployed-if-applicable` | `deployed` — if applicable | `ROADMAP.md:L5214` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | none | — | | `CC2-RM-A0331-abandoned-pr-closed-without-merge` | `abandoned` — PR closed without merge | `ROADMAP.md:L5215` / `roadmap_action` | `beta_adoption` | `done_verify` | `verify_existing_evidence_and_regression_guard` | none | — | | `CC2-RM-A0332-claw-help-has-no-mention-of-workers-claw` | `claw --help` has no mention of workers, `claw worker`, or worker state | `ROADMAP.md:L5234` / `roadmap_action` | `alpha_blocker` | `open` | `docs_snapshot_or_help_output_check` | none | — | | `CC2-RM-A0333-there-is-no-claw-worker-subcommand-not-l` | There is no `claw worker` subcommand (not listed in help, not in the 16 known subcommands) | `ROADMAP.md:L5235` / `roadmap_action` | `alpha_blocker` | `open` | `docs_snapshot_or_help_output_check` | none | — | | `CC2-RM-A0334-no-hint-in-the-error-itself-about-what-c` | No hint in the error itself about what command triggers worker state creation | `ROADMAP.md:L5236` / `roadmap_action` | `alpha_blocker` | `open` | `docs_snapshot_or_help_output_check` | none | — | | `CC2-RM-A0335-a-claw-ci-pipeline-or-first-time-user-hi` | A claw, CI pipeline, or first-time user hitting this error has no actionable next step | `ROADMAP.md:L5237` / `roadmap_action` | `alpha_blocker` | `open` | `docs_snapshot_or_help_output_check` | none | — | | `CC2-RM-A0336-error-references-concept-that-is-not-dis` | **Error references concept that is not discoverable.** Product Principle violation: "Errors must be actionable." Current error is descriptive but unactionable. | `ROADMAP.md:L5251` / `roadmap_action` | `alpha_blocker` | `open` | `docs_snapshot_or_help_output_check` | none | — | | `CC2-RM-A0337-claws-can-t-self-heal-a-claw-orchestrato` | **Claws can't self-heal.** A claw orchestrator that gets this error cannot construct a follow-up command because the remediation is not in the error or in `--help`. | `ROADMAP.md:L5252` / `roadmap_action` | `alpha_blocker` | `open` | `docs_snapshot_or_help_output_check` | none | — | | `CC2-RM-A0338-dogfood-blocker-automated-test-setups-th` | **Dogfood blocker.** Automated test setups that include `claw state` as a health check will fail silently for users who haven't triggered the worker path. | `ROADMAP.md:L5253` / `roadmap_action` | `alpha_blocker` | `open` | `install_matrix_or_cross_platform_smoke` | none | — | | `CC2-RM-A0339-internal-architecture-leaks-into-user-su` | **Internal architecture leaks into user surface.** The `worker` / `daemon` / `background session` distinction is internal runtime nomenclature, not user-facing workflow. | `ROADMAP.md:L5254` / `roadmap_action` | `alpha_blocker` | `open` | `targeted_regression_or_acceptance_test_required` | none | — | | `CC2-RM-A0340-error-message-should-include-remediation` | **Error message should include remediation.** Change error to: | `ROADMAP.md:L5257` / `roadmap_action` | `alpha_blocker` | `open` | `docs_snapshot_or_help_output_check` | none | — | | `CC2-RM-A0341-add-claw-help-reference-document-under-f` | **Add `claw --help` reference.** Document under `Flags` or `Subcommand overview` that `claw state` requires prior execution. | `ROADMAP.md:L5266` / `roadmap_action` | `alpha_blocker` | `open` | `docs_snapshot_or_help_output_check` | none | — | | `CC2-RM-A0342-consistency-with-typed-error-envelope-ro` | **Consistency with typed-error envelope** (ROADMAP §4.44): include `operation: "state-read"`, `target: ""`, `retryable: false` fields for machine consumers. | `ROADMAP.md:L5267` / `roadmap_action` | `alpha_blocker` | `open` | `install_matrix_or_cross_platform_smoke` | none | — | | `CC2-RM-A0343-product-principle-violation-every-cli-su` | **Product principle violation**: every CLI subcommand should have a consistent ` --help` contract that returns subcommand-specific help. | `ROADMAP.md:L5312` / `roadmap_action` | `beta_adoption` | `open` | `docs_snapshot_or_help_output_check` | none | — | | `CC2-RM-A0344-ci-orchestration-hazard-a-claw-script-th` | **CI/orchestration hazard**: a claw script that tries ` --help \| grep