- 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.
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.
Replace all 6 task tool stubs (TaskCreate/Get/List/Stop/Update/Output)
with real TaskRegistry-backed implementations:
- TaskCreate: creates task in global registry, returns real task_id
- TaskGet: retrieves full task state (status, messages, timestamps)
- TaskList: lists all tasks with metadata
- TaskStop: transitions task to stopped state with validation
- TaskUpdate: appends user messages to task message history
- TaskOutput: returns accumulated task output
Global registry uses OnceLock<TaskRegistry> singleton per process.
All existing tests pass (37 tools, 149 runtime, 102 CLI).
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)
The landed mock Anthropic harness now covers multi-tool turns, bash flows,
permission prompt approve/deny paths, and an external plugin tool path.
A machine-readable scenario manifest plus a diff/checklist runner keep the
new scenarios tied back to PARITY.md so future additions stay honest.
Constraint: Must build on the deterministic mock service and clean-environment CLI harness
Rejected: Add an MCP tool scenario now | current MCP tool surface is still stubbed, so plugin coverage is the real executable path
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: Keep rust/mock_parity_scenarios.json, mock_parity_harness.rs, and PARITY.md refs in lockstep
Tested: cargo fmt --all
Tested: cargo clippy --workspace --all-targets -- -D warnings
Tested: cargo test --workspace
Tested: python3 rust/scripts/run_mock_parity_diff.py
Not-tested: Real MCP lifecycle handshakes; remote plugin marketplace install flows
This adds a deterministic mock Anthropic-compatible /v1/messages service,
a clean-environment CLI harness, and repo docs so the first parity
milestone can be validated without live network dependencies.
Constraint: First milestone must prove Rust claw can connect from a clean environment and cover streaming, tool assembly, and permission/tool flow
Constraint: No new third-party dependencies; reuse the existing Rust workspace stack
Rejected: Record/replay live Anthropic traffic | nondeterministic and unsuitable for repeatable CI coverage
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: Keep scenario markers and expected tool payload shapes synchronized between the mock service and the harness tests
Tested: cargo fmt --all
Tested: cargo clippy --workspace --all-targets -- -D warnings
Tested: cargo test --workspace
Tested: ./scripts/run_mock_parity_harness.sh
Not-tested: Live Anthropic responses beyond the five scripted harness scenarios
Catalog all 40 tools as real-impl vs stub, with specific behavioral
gap notes per tool. Identify missing bash submodules (18 upstream
vs 1 Rust), file validation gaps, MCP/plugin flow gaps, and runtime
behavioral gaps.
This replaces surface-count bragging with actionable gap tracking.
Port 7 missing tool definitions from upstream parity audit:
- AskUserQuestionTool: ask user a question with optional choices
- TaskCreate: create background sub-agent task
- TaskGet: get task status by ID
- TaskList: list all background tasks
- TaskStop: stop a running task
- TaskUpdate: send message to a running task
- TaskOutput: retrieve task output
All tools have full ToolSpec schemas registered in mvp_tool_specs()
and stub execute functions wired into execute_tool(). Stubs return
structured JSON responses; real sub-agent runtime integration is the
next step.
Closes parity gap: 21 -> 28 tools (upstream has 40).
fmt/clippy/tests all green.
Remove the #[ignore] gate from startup_banner_mentions_workflow_completions
by injecting a dummy ANTHROPIC_API_KEY. The test exercises LiveCli banner
rendering, not API calls. Cleanup env var after test.
Test suite now 102/102 in CLI crate (was 101 + 1 ignored).
Inject a dummy ANTHROPIC_API_KEY for
build_runtime_runs_plugin_lifecycle_init_and_shutdown so the test
exercises plugin init/shutdown without requiring real credentials.
The API client is constructed but never used for streaming.
Clean up the env var after the test to avoid polluting parallel tests.
PARITY.md is stale relative to the current Rust plugin pipeline: plugin manifests, tool loading, and lifecycle primitives already exist, but runtime construction only consumed plugin tools. This change routes enabled plugin hooks into the runtime feature config, initializes plugin lifecycle commands when a runtime is built, and shuts plugins down when runtimes are replaced or dropped.\n\nThe test coverage exercises the new runtime plugin-state builder and verifies init/shutdown execution without relying on global cwd or config-home mutation, so the existing CLI suite stays stable under parallel execution.\n\nConstraint: Keep the change inside the current worktree and avoid touching unrelated pre-existing edits\nRejected: Add plugin hook execution inside the tools crate directly | runtime feature merging is the existing execution boundary\nRejected: Use process-global CLAW_CONFIG_HOME/current_dir in tests | races with the existing parallel CLI test suite\nConfidence: high\nScope-risk: moderate\nReversibility: clean\nDirective: Preserve plugin runtime shutdown when rebuilding LiveCli runtimes or temporary turn runtimes\nTested: cargo test -p rusty-claude-cli build_runtime_\nTested: cargo test -p rusty-claude-cli\nNot-tested: End-to-end live REPL session with a real plugin outside the test harness
