feat(pi-workflow): add lifecycle slash commands

docs/pi-workflow/README.md

@@ -4,7 +4,15 @@
 
 ## Start a feature
 
-Ask the assistant to use `pi_workflow` with:
+Start with:
+
+```text
+/workflow start <message>
+```
+
+The command sends the message through the assistant, which chooses the descriptive feature name and idempotency key before invoking `pi_workflow` through the normal tool path. In interactive TUI mode, `/workflow start` without a message asks what you want to start working on. Non-interactive modes require the message in the command.
+
+You can also ask the assistant to use `pi_workflow` with:
 
 - `action: "start"`
 - `workflow: { mode: "feature" }` (or omit `workflow`)
@@ -31,13 +39,24 @@ The assistant must inspect the current run before each state-changing call and o
 
 Use `/workflow` for the focused-card dashboard. It lists runs attached to the current session and shows persisted status, progress, Gate, plan, report, branch, and worktree information.
 
-Use:
+Use `/workflow continue` to select a run with a pending fresh-session handoff or normal-compaction continuation. `/workflow resume` is an alias. A run ID may be supplied directly:
 
 ```text
 /workflow continue <run-id>
+/workflow resume <run-id>
 ```
 
-only when the dashboard or `pi_workflow` reports a pending fresh-session handoff or normal-compaction continuation.
+Selection requires interactive TUI mode. In non-interactive modes, provide the run ID.
+
+## Stop active work
+
+Use `/workflow stop` to abort an active (`running` or `waiting`) Workflow Run owned by the current parent session. If more than one is active, interactive TUI mode presents a selection list. A run can also be named directly, including in non-interactive modes:
+
+```text
+/workflow stop <run-id>
+```
+
+Terminal runs and runs owned by historical parent sessions are not offered. The misspelled `/worlflow` alias is not supported.
 
 ## Script modes
 

docs/pi-workflow/design.md

@@ -149,7 +149,9 @@ type GateDecision =
 
 Feature and feature-script starts require `featureName` as a concise lowercase kebab-case name that describes what the feature does, such as `searchable-workflow-dashboard`. Analysis starts omit it. The host validates the name before persisting launch intent.
 
-The `pi_workflow` tool calls a single internal `execute(command)` interface. `/workflow` opens the dashboard and may accept a run ID for direct inspection. `/workflow continue <run-id>` performs a pending fresh-session handoff or normal-compaction fallback after the run is safely waiting; it cannot approve plans, select prototypes, or make other Decisions.
+The `pi_workflow` tool calls a single internal `execute(command)` interface. `/workflow` opens the dashboard and may accept a run ID for direct inspection. `/workflow start <message>` sends the initial request through the assistant so the normal `pi_workflow` tool path owns feature naming and idempotency; in interactive TUI mode, omitting the message opens an input prompt. `/workflow continue` presents eligible pending context transitions for selection, while `/workflow continue <run-id>` continues one directly; `/workflow resume` is an alias for both forms. `/workflow stop [run-id]` aborts a non-terminal run owned by the active parent session and presents a selector when multiple owned runs are active. The misspelled `/worlflow` alias is intentionally unsupported. Continue and stop selectors require interactive TUI mode and provide direct-run-ID guidance otherwise.
+
+Continuation performs only a pending fresh-session handoff or normal-compaction fallback after the run is safely waiting; it cannot approve plans, select prototypes, or make other Decisions. Stop treats `running` and `waiting` runs as active and excludes terminal runs and runs owned only by historical parent sessions.
 
 When a run reaches a Gate, the tool returns a structured waiting view. The parent agent asks the user through its normal interaction tools, then calls `pi_workflow` with `action: "decide"`. Child agents never receive `ask_user`.
 
@@ -614,7 +616,7 @@ Extend the Phase 2 worktree scaffold with the Implementation Context Gate, `/wor
 - Workspace creation intent is persisted first; creation failure rolls back safely or remains reconcilable after restart.
 - Every feature run receives a distinct leased worktree and worktrees are retained until explicitly removed.
 - A versioned `plan.md` is persisted before the Implementation Context Gate and revised with an accepted prototype when applicable.
-- Phase 4 registers `/workflow continue`; its `ExtensionCommandContext` performs both fresh-session replacement and approved normal-compaction fallback rather than deferring either path to dashboard integration.
+- Phase 4 registers `/workflow start`, `/workflow stop`, `/workflow continue`, and its `/workflow resume` alias. Start routes through the assistant's normal `pi_workflow` tool path, stop is scoped to active runs owned by the current parent session, and continuation without a run ID selects from valid candidates. Its `ExtensionCommandContext` performs both fresh-session replacement and approved normal-compaction fallback rather than deferring either path to dashboard integration.
 - `fresh-session` persists a Gate-, revision-, plan-, preparation-, and source-session-bound handoff intent before `newSession`; only the replacement `withSession` callback consumes it, attaches the new active parent session, seeds the bounded plan handoff, and resumes.
 - `smart-compact` uses a Gate-bound `report-context-preparation` transition with distinct `unavailable`, `succeeded`, `no-op`, and `failed` outcomes; `failed` requires a non-empty actionable error. The host validates `unavailable` against `pi.getActiveTools()`; only that outcome permits plan-focused `ctx.compact({ onComplete, onError })`, whose intent-bound callback persists success or failure.
 - An available-but-failed `smart_compact` call does not silently fall back and keeps the Implementation Context Gate waiting with an actionable error; `current-session` preserves context unchanged.