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

ROADMAP.md

@@ -6277,3 +6277,5 @@ Original filing (2026-04-18): the session emitted `SessionStart hook (completed)
 338. **Top-level `help --output-format json` and resume-safe `/help --output-format json` use different payload fields for the same help surface (`message` vs `text`)** — dogfooded 2026-04-29 on current `origin/main` / workspace HEAD `24ccb59b` after rebuilding the actual debug binary with `cargo run --manifest-path rust/Cargo.toml --bin claw -- version --output-format json`; `./rust/target/debug/claw version --output-format json` reported embedded `git_sha` `24ccb59b`, matching the workspace. Running `./rust/target/debug/claw help --output-format json` returned a valid JSON object with keys `kind,message`, while `./rust/target/debug/claw --resume latest /help --output-format json` returned the same conceptual help surface with keys `kind,text`. Both are prose-only help payloads, but automation now has to special-case whether help was reached through the top-level command dispatcher or the resume-safe slash dispatcher before it can even locate the rendered help body. This is distinct from #325's broader structured-schema absence: the pinpoint here is a concrete JSON field-name contract drift between two help entrypoints that should be equivalent or explicitly versioned. **Required fix shape:** (a) define one canonical help JSON body field such as `message` or `text` and use it consistently across top-level `help`, slash `/help`, and resume-safe `/help`; (b) if backward compatibility requires both fields temporarily, emit both with identical contents plus a `schema_version` and deprecation metadata; (c) add regression coverage proving `claw help --output-format json` and `claw --resume latest /help --output-format json` expose the same top-level field contract and `kind=help`; (d) document whether slash-command JSON is intended to share schemas with top-level command JSON or carry its own explicit schema namespace. **Why this matters:** help JSON is the bootstrap discoverability surface for claws. If the same help concept moves its body between `message` and `text` depending on invocation path, every orchestrator needs brittle per-entrypoint parsers before it can inspect commands, flags, or resume safety. Source: gaebal-gajae dogfood in `/home/bellman/Workspace/claw-code` on 2026-04-29 using rebuilt `./rust/target/debug/claw`; proof commands showed top-level help JSON keys `kind,message` and resume-safe slash help JSON keys `kind,text` on the same rebuilt binary.
 
 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.
+
+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.