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)
The background Agent tool already persisted lane-adjacent state via a JSON manifest and a markdown transcript, making it the smallest viable vertical slice for the ROADMAP lane-event work. This change adds canonical typed lane events to the manifest and normalizes terminal blockers into the shared failure taxonomy so downstream clawhip-style consumers can branch on structured state instead of scraping prose alone.
The slice is intentionally narrow: it covers agent start, finish, blocked, and failed transitions plus blocker classification, while leaving broader lane orchestration and external consumers for later phases. Tests lock the manifest schema and taxonomy mapping so future extensions can add events without regressing the typed baseline.
Constraint: Land a fresh-main vertical slice without inventing a larger lane framework first
Rejected: Add a brand-new lane subsystem across crates | too broad for one verified slice
Rejected: Only add markdown log annotations | still log-shaped and not machine-first
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Extend the same event names and failure classes before adding any alternate manifest schema for lane reporting
Tested: cargo test -p tools agent_persists_handoff_metadata -- --nocapture
Tested: cargo test -p tools agent_fake_runner_can_persist_completion_and_failure -- --nocapture
Tested: cargo test -p tools lane_failure_taxonomy_normalizes_common_blockers -- --nocapture
Not-tested: Full clawhip consumer integration or multi-crate event plumbing
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
Tests relying on PermissionMode::DangerFullAccess as default were
flaky under --workspace runs because other tests set
RUSTY_CLAUDE_PERMISSION_MODE without cleanup. Added env_lock() and
explicit env var removal to 7 affected tests.
Fixes: workspace-level cargo test flake (1 random test fails per run)
- All 9 lanes now merged on main
- Output truncation complete (16KB)
- AskUserQuestion + RemoteTrigger real implementations
- Updated still-open items with accurate remaining gaps
- Updated migration readiness checklist
- Mark bash validation as merged (1cfd78a)
- Mark output truncation as complete
- Update lane table with correct merge commits
- Add follow-up parity items section
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
The review correctly identified that enforce_permission_check() was defined
but never called. This commit:
- Adds enforcer: Option<PermissionEnforcer> field to GlobalToolRegistry
and SubagentToolExecutor
- Adds set_enforcer() method for runtime configuration
- Gates both execute() paths through enforce_permission_check() when
an enforcer is configured
- Default: None (Allow-all, matching existing behavior)
Resolves the dead-code finding from ultraclaw review sessions 3 and 8.
