docs(roadmap): add #343 — session subcommand resume-safety inconsistently enforced

ROADMAP.md

@@ -6278,8 +6278,4 @@ Original filing (2026-04-18): the session emitted `SessionStart hook (completed)
 
 339. **`/session delete` is not resume-safe while `/session list` is, making session GC impossible from `--resume` mode automation** — dogfooded 2026-04-30 by Jobdori on `24ccb59`. Running `claw --output-format json --resume latest /session list` succeeds and returns the full session list (10 sessions, all `workspace_dirty: true, abandoned: true`). Running `claw --output-format json --resume latest /session delete <id>` returns `{"command":"...","error":"unsupported resumed slash command","type":"error"}` — again using `"type"` not `"kind"` (#336 vocab violation). An automation lane that discovers abandoned sessions via `--resume` cannot delete any of them via the same path; it must spawn an interactive REPL session just to issue delete, breaking the machine-readable JSON surface contract. **Required fix shape:** (a) mark `/session delete` as resume-safe; (b) return `{"kind":"session_deleted","session_id":"<id>","path":"<deleted_path>"}` on success; (c) require `--force` only for dirty/active sessions; (d) add regression coverage. Source: Jobdori live dogfood, mengmotaHost, `24ccb59`, 2026-04-30.
 
-340. **Resume-safe `/session help --output-format json` writes its primary JSON error envelope to stderr and uses `type` instead of the session JSON `kind` vocabulary** — dogfooded 2026-04-29 on current `origin/main` / rebuilt `./rust/target/debug/claw` with embedded `git_sha` `dc47482e`. Running `./rust/target/debug/claw --resume latest /session help --output-format json` wrote no stdout bytes, but wrote a JSON error object to stderr: `{"command":"/session help","error":"Unknown /session action ...","type":"error"}`. Meanwhile `/session list --output-format json` wrote valid stdout JSON with `kind=session_list`. The JSON output contract is therefore split across stderr for an error/help-ish action and switches vocabulary from `kind` to `type`; automation that reads stdout sees empty/non-JSON output and cannot handle errors consistently with successful session JSON responses. **Required fix shape:** (a) all `--output-format json` command responses, including resumed slash errors, should emit the primary JSON envelope on stdout; (b) use `kind:"error"` or a documented error schema consistently instead of an ad hoc `type` field; (c) reserve stderr prose for text mode or optional non-primary diagnostics, not the machine-readable envelope; (d) add a regression for `/session help` or an unsupported `/session` action under `--resume` proving stdout contains the structured JSON error envelope and stderr does not carry the only parseable payload. **Why this matters:** claws need one stdout JSON contract for both success and failure. If a help-ish session error is silently moved to stderr and shaped differently from `session_list`, orchestration lanes cannot distinguish an unsupported action from transport corruption or an empty response without bespoke stderr parsing. Source: gaebal-gajae dogfood follow-up for the 15:30 nudge on rebuilt `./rust/target/debug/claw` `dc47482e`.
-
-341. **Resume-safe `/tasks --output-format json` emits an unsupported-command JSON error only on stderr and mixes `kind` with `type` classification vocabularies** — dogfooded 2026-04-29 for the 16:00 nudge on current `origin/main` / rebuilt `./rust/target/debug/claw` with embedded `git_sha` `58569131`. Running `./rust/target/debug/claw --resume latest /tasks --output-format json` wrote no stdout bytes, but wrote a JSON error object to stderr: `{"command":"/tasks","error":"/tasks is not yet implemented in this build","kind":"unsupported_command","type":"error"}`. The unsupported command envelope therefore has two separate top-level classification vocabularies (`kind=unsupported_command` and `type=error`) and places the only parseable payload on stderr, while successful JSON commands use stdout and a `kind`-only classification. This is distinct from #340 because it is not session help; it shows implemented-but-unsupported command stubs can emit a dual-vocabulary error envelope. **Required fix shape:** (a) in `--output-format json` mode, emit the primary JSON envelope on stdout for unsupported resumed slash commands such as `/tasks`; (b) document and use one error discriminator, preferably `kind:"error"` plus `code:"unsupported_command"`, or `kind:"unsupported_command"` plus `status:"error"`, but not `type`; (c) reserve stderr for non-primary diagnostics or text-mode prose, never as the sole JSON payload; (d) add regression coverage for `/tasks` under `--resume` with JSON output proving stdout contains the structured error envelope, stderr is not the only parseable stream, and the envelope uses the documented single-vocabulary discriminator. **Why this matters:** claws need the same stdout JSON contract for implemented successes and implemented-but-unsupported stubs. If `/tasks` errors can silently move to stderr and advertise both `kind` and `type`, automation must special-case command stubs instead of applying one JSON error parser. Source: gaebal-gajae dogfood follow-up for the 16:00 nudge on rebuilt `./rust/target/debug/claw` `58569131`.
-
-350. **`doctor --output-format json` auth check reports `status: "warn"` with `"no supported auth env vars were found"` even when a valid CLI session token or browser-based OAuth token is present in the claw config directory** — dogfooded 2026-04-30 by Jobdori on `f65b2b4`. Running `/doctor --output-format json` returns `{"name":"auth","status":"warn","summary":"no supported auth env vars were found","api_key_present":false,"auth_token_present":false,"legacy_refresh_token_present":false,...}`. In the same environment, `claw --resume latest` successfully resumes a session (meaning a valid auth token exists in `~/.claw/` or the session store) — but `doctor` does not check that path and reports a false-positive warning. The auth check appears to only probe environment variables (`ANTHROPIC_API_KEY`, `CLAW_AUTH_TOKEN`, etc.) and legacy OAuth refresh token fields, but does not probe: (a) the CLI session token stored in `~/.claw/auth.json` or equivalent; (b) the OAuth access token in `~/.claw/settings.json`; (c) valid unexpired session credentials that the runtime uses to authenticate actual API calls. A claw running `doctor` before starting work gets a false `auth` warning and cannot distinguish "genuinely no auth" from "auth exists but not in env vars". **Required fix shape:** (a) expand auth check to probe all credential paths the runtime actually uses in priority order, including CLI session tokens, OAuth tokens in config files, and environment variables; (b) report which credential source passed (e.g. `"auth_source": "settings_oauth"` or `"auth_source": "env_api_key"`); (c) report `status: "ok"` when any working credential path exists, even if env vars are absent; (d) add regression coverage proving that a machine with a valid `~/.claw/` session token reports `auth.status: "ok"` in doctor output. **Why this matters:** `doctor` is the bootstrap health check surface — if it false-positives on auth, every claw health-check pipeline will flag the system as unhealthy and may abort legitimate work. Source: Jobdori live dogfood, mengmotaHost, `f65b2b4`, 2026-04-30.
+343. **`/session` subcommand resume-safety is inconsistently enforced: `list` works, `switch`/`delete` reach argument parsing (resume-safe), but `fork` is hard-blocked at the resume gate** — dogfooded 2026-04-30 by Jobdori on `dc47482`. Tested all four documented subcommands from `claw --output-format json --resume latest /session <subcmd>`: (a) `/session list` → success ✅; (b) `/session switch <missing-arg>` → `{"error":"Usage: /session switch <session-id>...","type":"error"}` — argument error, meaning resume gate passed and the subcommand executed up to argument validation; (c) `/session delete <missing-arg>` → same pattern, resume gate passed; (d) `/session fork` → `{"error":"unsupported resumed slash command","type":"error"}` — hard-blocked before argument parsing. The slash command resume-safe allowlist therefore has an inconsistency: `switch` and `delete` can be called from `--resume` mode if given valid args (they parse and would execute), but `fork` is categorically blocked even though it only needs an optional `[branch-name]` argument. A claw that discovers this inconsistency by probing will get contradictory signals about what the session lifecycle commands support. **Required fix shape:** (a) audit the resume-safe allowlist and either: (i) mark `fork` as resume-safe (consistent with `switch`/`delete`), or (ii) explicitly block `switch` and `delete` at the resume gate the same way `fork` is blocked; (b) document the resume-safety policy for all session subcommands in `/help --output-format json`; (c) make all blocked subcommands use the same error vocabulary (`"kind"` not `"type"`, per #336); (d) add regression coverage that probes all four session subcommands from `--resume` mode and asserts consistent gate behavior. **Why this matters:** automation that needs to fork a session from `--resume` context cannot do so while `switch` and `delete` with valid args would succeed — the allowlist boundary is not at the subcommand level and operators cannot reason about what is safe without probing each variant. Source: Jobdori live dogfood, mengmotaHost, `dc47482`, 2026-04-30.