Add a foundational worker_boot control plane and tool surface for
reliable startup. The new registry tracks trust gates, ready-for-prompt
handshakes, prompt delivery attempts, and shell misdelivery recovery so
callers can coordinate worker boot above raw terminal transport.
Constraint: Current main has no tmux-backed worker control API to extend directly
Constraint: First slice must stay deterministic and fully testable in-process
Rejected: Wire the first implementation straight to tmux panes | would couple transport details to unfinished state semantics
Rejected: Ship parser helpers without control tools | would not enforce the ready-before-prompt contract end to end
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: Treat WorkerObserve heuristics as a temporary transport adapter and replace them with typed runtime events before widening automation policy
Tested: cargo test -p runtime worker_boot
Tested: cargo test -p tools worker_tools
Tested: cargo check -p runtime -p tools
Not-tested: Real tmux/TTY trust prompts and live worker boot on an actual coding session
Not-tested: Full cargo clippy -p runtime -p tools --all-targets -- -D warnings (fails on pre-existing warnings outside this slice)
This resolves the stale-branch merge against origin/main, keeps the MCP runtime wiring, and preserves prompt-approved CLI tool execution after the mock parity harness additions landed upstream.
Constraint: Branch had to absorb origin/main changes through a contentful merge before more MCP work
Constraint: Prompt-approved runtime tool execution must continue working with new CLI/mock parity coverage
Rejected: Keep permission enforcer attached inside CliToolExecutor for conversation turns | caused prompt-approved bash parity flow to fail as a tool error
Rejected: Defer the merge and continue on stale history | would leave the lane red against current main
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: Runtime permission policy and executor-side permission enforcement are separate layers; do not reapply executor enforcement to conversation turns without revalidating mock parity harness approval flows
Tested: cargo test -p rusty-claude-cli --test mock_parity_harness -- --nocapture; cargo test -p rusty-claude-cli -- --nocapture; cargo test --workspace -- --nocapture
Not-tested: Additional live remote/provider scenarios beyond the existing workspace suite
This wires configured MCP servers into the CLI/runtime path so discovered
MCP tools, resource wrappers, search visibility, shutdown handling, and
best-effort discovery all work together instead of living as isolated
runtime primitives.
Constraint: Keep non-MCP startup flows working without new required config
Constraint: Preserve partial availability when one configured MCP server fails discovery
Rejected: Fail runtime startup on any MCP discovery error | too brittle for mixed healthy/broken server configs
Rejected: Keep MCP support runtime-only without registry wiring | left discovery and invocation unreachable from the CLI tool lane
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: Runtime MCP tools are registry-backed but executed through CliToolExecutor state; keep future tool-registry changes aligned with that split
Tested: cargo test -p runtime mcp -- --nocapture; cargo test -p tools -- --nocapture; cargo test -p rusty-claude-cli -- --nocapture; cargo test --workspace -- --nocapture
Not-tested: Live remote MCP transports (http/sse/ws/sdk) remain unsupported in the CLI execution path
The PermissionEnforcer was hard-denying tool calls that needed user
approval because it passes no prompter to authorize(). When the
active permission mode is Prompt, the enforcer now returns Allowed
and defers to the CLI's interactive approval flow.
Fixes: mock_parity_harness bash_permission_prompt_approved scenario
Add LspRegistry in crates/runtime/src/lsp_client.rs and wire it into
run_lsp() tool handler in crates/tools/src/lib.rs.
Runtime additions:
- LspRegistry: register/get servers by language, find server by file
extension, manage diagnostics, dispatch LSP actions
- LspAction enum (Diagnostics/Hover/Definition/References/Completion/Symbols/Format)
- LspServerStatus enum (Connected/Disconnected/Starting/Error)
- Diagnostic/Location/Hover/CompletionItem/Symbol types for structured responses
- Action dispatch validates server status and path requirements
Tool wiring:
- run_lsp() maps LspInput to LspRegistry.dispatch()
- Supports dynamic server lookup by file extension (rust/ts/js/py/go/java/c/cpp/rb/lua)
- Caches diagnostics across servers
8 new tests covering registration, lookup, diagnostics, and dispatch paths.
Bridges to existing LSP process manager for actual JSON-RPC execution.
Add McpToolRegistry in crates/runtime/src/mcp_tool_bridge.rs and wire
it into all 4 MCP tool handlers in crates/tools/src/lib.rs.
Runtime additions:
- McpToolRegistry: register/get/list servers, list/read resources,
call tools, set auth status, disconnect
- McpConnectionStatus enum (Disconnected/Connecting/Connected/AuthRequired/Error)
- Connection-state validation (reject ops on disconnected servers)
- Resource URI lookup, tool name validation before dispatch
Tool wiring:
- ListMcpResources: queries registry for server resources
- ReadMcpResource: looks up specific resource by URI
- McpAuth: returns server auth/connection status
- MCP (tool proxy): validates + dispatches tool calls through registry
8 new tests covering all lifecycle paths + error cases.
Bridges to existing McpServerManager for actual JSON-RPC execution.
Add TeamRegistry and CronRegistry in crates/runtime/src/team_cron_registry.rs
and wire them into the 5 team+cron tool handlers in crates/tools/src/lib.rs.
Runtime additions:
- TeamRegistry: create/get/list/delete(soft)/remove(hard), task_ids tracking,
TeamStatus (Created/Running/Completed/Deleted)
- CronRegistry: create/get/list(enabled_only)/delete/disable/record_run,
CronEntry with run_count and last_run_at tracking
Tool wiring:
- TeamCreate: creates team in registry, assigns team_id to tasks via TaskRegistry
- TeamDelete: soft-deletes team with status transition
- CronCreate: creates cron entry with real cron_id
- CronDelete: removes entry, returns deleted schedule info
- CronList: returns full entry list with run history
8 new tests (team + cron) — all passing.
Implements the runtime backbone for TaskCreate/TaskGet/TaskList/TaskStop/
TaskUpdate/TaskOutput tool surface parity. Thread-safe (Arc<Mutex>) registry
supporting:
- Create tasks with prompt/description
- Status transitions (Created → Running → Completed/Failed/Stopped)
- Message passing (update with user messages)
- Output accumulation (append_output for subprocess capture)
- Team assignment (for TeamCreate orchestration)
- List with optional status filter
- Remove/cleanup
7 new unit tests covering all CRUD + error paths.
Next: wire registry into tool dispatch to replace current stubs.
On GitHub Actions runners, `unshare` binary exists at /usr/bin/unshare
but user namespaces (CLONE_NEWUSER) are restricted, causing `unshare
--user --map-root-user` to silently fail. This produced empty stdout
in the bash_stdout_roundtrip parity test (mock_parity_harness.rs:533).
Replace the simple `command_exists("unshare")` check with
`unshare_user_namespace_works()` that actually probes whether
`unshare --user --map-root-user true` succeeds. Result is cached
via OnceLock so the probe runs at most once per process.
Fixes: CI red on main@85c5b0e (Rust CI run 23933274144)
Add a focused GitHub Actions workflow for pull requests into main plus
manual dispatch. The workflow checks workspace formatting and runs the
rusty-claude-cli crate tests so we get a real signal on the active Rust
surface without widening scope into a full matrix.
Because the workspace was not rustfmt-clean, include the formatting-only
updates needed for the new fmt gate to pass immediately.
Constraint: Keep scope to a fast, low-noise Rust PR gate
Constraint: CI should validate formatting and rusty-claude-cli without expanding to full workspace coverage
Rejected: Full workspace test or clippy matrix | too broad for the one-hour shipping window
Rejected: Add fmt CI without reformatting the workspace | the new gate would fail on arrival
Confidence: high
Scope-risk: narrow
Directive: Keep this workflow focused unless release requirements justify broader coverage
Tested: cargo fmt --all -- --check
Tested: cargo test -p rusty-claude-cli
Tested: YAML parse of .github/workflows/rust-ci.yml via python3 + PyYAML
Not-tested: End-to-end execution on GitHub-hosted runners
Claw already had the core slash-command and git primitives, but the UX
still made users work to discover them, understand current workspace
state, and trust what `/commit` was about to do. This change tightens
that flow in the same places Codex-style CLIs do: command discovery,
live status, typo recovery, and commit preflight/output.
The REPL banner and `/help` now surface a clearer starter path, unknown
slash commands suggest likely matches, `/status` includes actionable git
state, and `/commit` explains what it is staging and committing before
and after the model writes the Lore message. I also cleared the
workspace's existing clippy blockers so the verification lane can stay
fully green.
Constraint: Improve UX inside the existing Rust CLI surfaces without adding new dependencies
Rejected: Add more slash commands first | discoverability and feedback were the bigger friction points
Rejected: Split verification lint fixes into a second commit | user requested one solid commit
Confidence: high
Scope-risk: moderate
Directive: Keep slash discoverability, status reporting, and commit reporting aligned so `/help`, `/status`, and `/commit` tell the same workflow story
Tested: cargo fmt --all; cargo clippy --workspace --all-targets -- -D warnings; cargo test --workspace
Not-tested: Manual interactive REPL session against live Anthropic/xAI endpoints
