fix(bridge): mission_* tools accept name; resolves #2583

[ilblackdragon]

Summary

• Fixes [Bug Bash 4/17] Routine creation fails with "5 consecutive code errors" #2583 — routine creation hitting 5 consecutive code errors. The actual root cause was much smaller than the linked Cost-based budgeting: replace iteration/time caps with USD budgets cascading user → project → mission → thread #2843 epic suggested: every mission_* handler in the bridge required an id UUID, but the LLM and the routine_* alias path naturally pass name. Each call collapsed to invalid mission id: invalid length 0, retried 4–5×, and tripped the orchestrator's consecutive-error guard.
• Mission/routine tools now accept name (preferred) with id UUID retained as a legacy fallback; UUIDs stay internal.
• Adds a live regression test that drives the exact bug-bash prompt through engine v2 and verifies the fix end-to-end.

What changed

File	Change
src/bridge/effect_adapter.rs	New resolve_mission_id helper. Handlers mission_get, mission_fire, mission_pause, mission_resume, mission_complete, mission_update migrated. mission_update renames via new_name; legacy name-as-rename-target preserved only when a UUID id is also passed. Four new unit tests.
src/bridge/engine_actions.rs	Mission tool schemas advertise name as primary, id as legacy alternative. Neither field is required. mission_update documents new_name for renames.
tests/support/test_rig.rs	Adds channel_handle() accessor and send_exec_approval for the live test's approval responder.
tests/e2e_live_routine.rs	New live regression. Drives the issue's exact prompt; asserts no invalid mission id or consecutive code errors; verifies **[name]** notifications on both fire and refire.
tests/fixtures/llm_traces/live/routine_btc_create_test_and_refire.json	Recorded trace for deterministic replay (live run scrub-checked — no PII).

How the fix was found

Driving the issue's verbatim prompt through engine v2 with a real LLM (the new test) reproduced the failure on first run. The trace showed:

tool 'routine_fire(bitcoin_price_checker)' failed: effect execution error:
  invalid mission id: invalid length: expected length 32 for simple format, found 0
  ... (× 4)

routine_fire translates to mission_fire via routine_to_mission_alias, which passes params.clone() unchanged. The mission_fire handler then tried to parse the routine name as a UUID and failed. Five errors in a row → orchestrator killed the thread → "5 consecutive code errors" symptom.

Verification

• cargo test --features libsql --lib bridge::effect_adapter — all 113 effect-adapter tests pass, including 4 new ones for the helper / handler / alias paths.
• cargo test --features libsql --test e2e_live_routine -- --skip routine_btc — heuristic + structural unit tests pass.
• IRONCLAW_LIVE_TEST=1 cargo test --features libsql --test e2e_live_routine -- --ignored routine_btc_create_test_and_refire --nocapture — passes in 49s. Tools observed: [\"routine_create(*/5 * * * *)\", \"routine_fire(bitcoin-price-check)\", \"routine_history(bitcoin-price-check)\", \"job_status(...)\"]. No invalid mission id. No consecutive code errors. Notifications delivered on both the initial fire and the second-turn refire.
• Replay mode (no IRONCLAW_LIVE_TEST) loads the committed fixture and runs deterministically.

Out of scope (parked for separate follow-ups)

The live test surfaced two further observations that are independent of this fix and not test-failing:

1. Administrative-tool approval gates not surfacing. Even with auto_approve_tools=false, mission_create / routine_create / mission_fire / routine_fire (all classified Administrative per crates/ironclaw_engine/src/gate/tool_tier.rs) ran without firing a single StatusUpdate::ApprovalNeeded. Logged as a warning in the test.
2. Mission-fire child thread sometimes returns narration instead of data. build_meta_prompt (crates/ironclaw_engine/src/runtime/mission.rs:2132–2139) instructs the child to FINAL() with "1. What you accomplished / 2. Next focus / 3. Goal achieved" — meta-prose. For "fetch X and surface it" routines the user actually wants the data. Logged as a warning in the test.

Both warrant their own issues; flagging here so they're not lost.

Test plan

• CI green on the new unit tests
• CI green on the live test in replay mode (uses committed fixture)
• Manual: bug-bash redo of the original report on staging — confirm no "5 consecutive code errors" surface

[gemini-code-assist]

Code Review

This pull request implements a name-based resolution system for missions and routines, enabling identification via human-readable names in addition to UUIDs. A centralized resolve_mission_id helper is introduced and integrated into various mission actions, while action definitions are updated to prioritize name as the primary identifier. The PR also adds comprehensive regression tests and a live end-to-end test for routine workflows. Feedback indicates that the mission_update logic fails to preserve legacy behavior for renames when a UUID is provided, and notes a discrepancy between the implementation and documentation regarding the resolution priority of identifiers.

[gemini-code-assist]

The implementation of mission_update does not preserve the legacy behavior where name acts as the rename target when a UUID id is also provided, despite the PR description claiming this preservation. The current code only checks new_name for renames, which breaks backward compatibility for existing callers or recorded traces using the (id=UUID, name=NewName) pattern.

                        // Renames use new_name. The legacy name field is
                        // now the lookup key (consumed by resolve_mission_id),
                        // not the rename target — unless a UUID id is also
                        // passed, preserving legacy behavior.
                        if let Some(new_name) = params.get("new_name").and_then(|v| v.as_str()) {
                            updates.name = Some(new_name.to_string());
                        } else if let Some(id_val) = params.get("id").and_then(|v| v.as_str()) {
                            if uuid::Uuid::parse_str(id_val).is_ok() {
                                if let Some(name) = params.get("name").and_then(|v| v.as_str()) {
                                    updates.name = Some(name.to_string());
                                }
                            }
                        }

References

1. When intercepting and forwarding a tool call to a backend implementation, ensure all relevant parameters from the original call are passed through, including legacy fields required for backward compatibility.

[ilblackdragon]

Fixed in 0bd586d (preserves the legacy shape) + b74c42e (handler strips name from the resolver-view params for the legacy shape so the new conflict guard doesn't reject it). Two regression tests guard it.

[gemini-code-assist]

The docstring's resolution order does not match the actual implementation. Specifically, params._args[0] as a valid UUID (checked at line 2200) has higher priority than params.name as a name (checked during the mission list iteration at line 2218), but the docstring lists it as a fallback (#3).

Suggested change

	/// Resolution order (first match wins):
	/// 1. `params.id` — if present and a valid UUID, use directly.
	/// 2. `params.name` — look up `(project_id, user_id, name)` via
	/// `MissionManager::list_missions`. The same identifier used in
	/// `mission_create` is what we resolve back here.
	/// 3. `params._args[0]` — positional fallback used by some Tier-0
	/// tool-call shapes; tried as UUID first, then as name.
	/// Resolution order (first match wins):
	/// 1. params.id — if present and a valid UUID, use directly.
	/// 2. params._args[0] — if present and a valid UUID, use directly.
	/// 3. params.name — look up (project_id, user_id, name) via
	/// MissionManager::list_missions.
	/// 4. params.id — look up by name (legacy fallback).
	/// 5. params._args[0] — look up by name (positional fallback).

References

1. When resolving identifiers from stored tool data or parameters, implement and document a clear fallback chain to check multiple possible field names or positions.

[ilblackdragon]

Fixed in b74c42e. The docstring on resolve_mission_id now matches the new four-step resolution order including the conflict guard. _args[0] no longer short-circuits ahead of explicit name (it's now a name candidate only — see serrrfirat's related comment).

[Copilot]

Pull request overview

This PR fixes routine/mission tool calls in the bridge by allowing mission_* handlers (and their routine_* aliases) to resolve missions by name instead of requiring a UUID id, preventing retry loops that previously tripped the orchestrator’s “consecutive code errors” guard (issue #2583).

Changes:

• Add resolve_mission_id and migrate mission_get/fire/pause/resume/complete/update to accept name (preferred) with legacy id fallback.
• Update mission tool schemas to advertise name as primary and introduce new_name for renames in mission_update.
• Add a new live/replayable end-to-end regression test plus fixture, and extend the test rig with approval helpers.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
src/bridge/effect_adapter.rs	Adds resolve_mission_id and switches mission handlers to name-first resolution.
src/bridge/engine_actions.rs	Updates mission tool schemas and guidance to prefer name and use new_name for rename.
tests/support/test_rig.rs	Adds channel_handle() and send_exec_approval() for background helpers in tests.
tests/e2e_live_routine.rs	Adds a live/replayable E2E regression test for #2583.
tests/fixtures/llm_traces/live/routine_btc_create_test_and_refire.json	Adds recorded trace fixture for deterministic replay.

Comments suppressed due to low confidence (1)

src/bridge/effect_adapter.rs:1027

• mission_complete resolves an explicit UUID via resolve_mission_id and then calls MissionManager::complete_mission(id) without any ownership/shared-access check. Since complete_mission itself does not enforce tenant isolation, a caller who knows/guesses another user's mission UUID could complete it. Add an authorization check here (e.g., load the mission and verify mission.is_owned_by(context.user_id) or mission.owner_id().is_shared() before completing), or change the engine API to require user_id like fire_mission/pause_mission/resume_mission/update_mission do.

            "mission_complete" => {
                let id =
                    resolve_mission_id(mgr.as_ref(), context.project_id, &context.user_id, params)
                        .await;
                match id {
                    Ok(id) => match mgr.complete_mission(id).await {
                        Ok(()) => Ok(serde_json::json!({"status": "completed"})),
                        Err(e) => Err(e),

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ilblackdragon]

Fixed in 720a0db. Discovery summary now matches the actual handler tolerance: "Identify the mission with name (preferred) or id (UUID). If both are provided they must identify the same mission, or use the legacy {id, name} rename shape (where name is the new name) — otherwise the resolver errors with 'identify different missions'."

[ilblackdragon]

Fixed in b74c42e. ApprovalAutoResponder now implements Drop that aborts the handle. shutdown() is kept for explicitness; abort() is idempotent so the double-abort path is safe.

[ilblackdragon]

Fixed in b74c42e. The comment now correctly notes that Ok(None) is reachable when the caller passed an explicit UUID for a deleted/unknown mission — names that didn't match are caught earlier by resolve_mission_id with a more useful error.

[ilblackdragon]

Fixed in b74c42e. user_id is no longer included in the mission not found error. Same fix on mission_get's "belongs to another user" arm — the foreign mission's UUID is now scrubbed from the LLM-visible reason and preserved only via tracing::debug!.

[ilblackdragon]

Fixed in 0bd586d (initial preservation) + b74c42e (mission_update handler now strips name from the resolver-view params when the legacy shape is detected, so the new conflict guard doesn't reject it). Two regression tests pin it: mission_update_preserves_legacy_id_plus_name_rename and mission_update_renames_via_new_name_and_uses_name_as_lookup.

[serrrfirat]

Performance regression on hot path (High): every name-keyed mission_* call now loads the user's full mission list. A cron routine firing every 5 min on an account with hundreds of historical missions (including completed/archived) pays an O(N) DB read per fire — the previous UUID-only path was O(1).

Suggest adding MissionManager::find_by_name(project_id, user_id, name) so the bridge does a targeted lookup. Even a small per-(project_id, user_id) name→id cache inside MissionManager (invalidated on create/rename/complete) would pay for itself fast — the same mission name is hit on every fire/get/pause cycle.

[ilblackdragon]

Addressed in b74c42e. Added MissionManager::find_by_name(project_id, user_id, name) -> Result<Option<Mission>, EngineError> typed API; bridge resolver switched off list_missions onto it. Today find_by_name still scans the user's missions in-memory; the doc-comment names the future store-level index drop-in (Store::find_mission_by_name) explicitly. Adding it later is non-breaking — every caller goes through this method now, so the optimization plugs in without churn at the call sites.

[serrrfirat]

Foot-gun (High): if a caller passes mission_update({id: <real_uuid_A>, name: "mission-B", new_name: "renamed"}), resolve_mission_id resolves id first (UUID fast-path), so mission A is renamed even though name says "mission-B". The schema text in engine_actions.rs says name is the lookup key — the helper logic contradicts that whenever id is also present.

Defense-in-depth: when both id (UUID) and name are provided and resolve to different missions, error out with "both id and name provided but they identify different missions" instead of silently preferring one. The doc comment on resolve_mission_id should also call out this precedence trap explicitly so the next caller doesn't trip it.

[ilblackdragon]

Fixed in b74c42e. Added the conflict guard you suggested. New regression test mission_resolver_errors_when_id_and_name_disagree pins it. Error reads: "both id and name provided but they identify different missions: id=X vs name=[Y] → Z. Provide only one — or fix the name to match the id." The resolver docstring also explicitly calls out the conflict-guard contract.

[serrrfirat]

Test coverage gap (High): all six mission_* handlers (get, fire, pause, resume, complete, update) now route through resolve_mission_id, but only mission_fire got new by-name regression tests. The most foot-gun-prone handler — mission_update (see related comment on the new_name rename) — has no by-name test at all, and the existing mission_update_string_guardrails_rejected_via_execute_action still passes id directly so doesn't exercise the new path.

Per CLAUDE.md "Test Through the Caller, Not Just the Helper", each migrated handler needs a caller-level test. Suggest three more symmetric to this one: mission_get_resolves_by_name, mission_complete_resolves_by_name, and mission_update_renames_via_new_name_when_name_is_lookup_key (the last one is the regression guard for the id+name foot-gun).

[ilblackdragon]

Fixed in b74c42e. Added by-name caller-level tests for every migrated handler: mission_get_resolves_by_name, mission_complete_resolves_by_name, mission_pause_and_resume_resolve_by_name, plus the conflict-guard regression mission_resolver_errors_when_id_and_name_disagree and the legacy-rename regression mission_update_preserves_legacy_id_plus_name_rename.

[serrrfirat]

Edge case (Medium): if a caller passes {name: "actual-mission", _args: ["<uuid-of-other>"]}, this _args[0] UUID parse short-circuits with return Ok(MissionId(uuid)) — the explicit name field is silently ignored. This contradicts the docstring's stated principle that name is preferred and _args[0] is a "positional fallback used by some Tier-0 tool-call shapes".

Two ways out:

• (a) Preserve preference: move the _args[0] UUID parse to after name_candidates lookup falls through, so explicit name wins.
• (b) Treat positional as always-a-name: drop the _args[0] UUID-parse branch and only push to name_candidates. UUID-shaped strings would still match if any mission happens to be named with a UUID — vanishingly rare and an explicit caller decision.

Either is fine; the current ordering is the worst of both.

[ilblackdragon]

Fixed in b74c42e — went with option (b). _args[0] is now treated as a name candidate only, never honoured as a UUID. UUID-shaped strings would only match if a mission happens to be named with one (vanishingly rare and the explicit caller decision you noted).

[serrrfirat]

Information disclosure (Medium): echoing user_id into the error reason leaks server-side identity into the LLM context, conversation history, and any tool-error telemetry. The previous error ("mission not found: {id_str}") only echoed user input.

EngineError::Effect::reason flows back to the LLM and is persisted — depending on the channel, user_id is a UUID (low value), but for some flows it's an external identity (chat id, session-derived token). Suggest dropping the for user '{user_id}' segment entirely. The LLM can't act on it anyway (it can't list a different user's missions).

Same goes for the mission {} belongs to another user reason a few lines above (mission_get arm at the new resolve site) — there's no LLM-actionable info in the foreign mission's UUID, and emitting it confirms the existence of a mission the caller has no claim to.

[ilblackdragon]

Fixed in b74c42e. Both error reasons are scrubbed: user_id is gone from the "mission not found" error, and mission_get's "belongs to another user" reason no longer echoes the foreign mission's UUID (preserved only via tracing::debug!).

[serrrfirat]

Architecture (Medium): name-or-id resolution is conceptually a MissionManager concern, not a bridge-adapter concern. Keeping this 60-line policy here means any future caller — CLI mission commands, the WS handler, a WASM channel that wants a mission lookup, integration tests outside the bridge — duplicates the resolution rules.

Suggest moving to a typed API on MissionManager:

enum MissionRef<'a> {
    Id(MissionId),
    Name(&'a str),
}

impl MissionManager {
    pub async fn resolve(&self, project_id: ProjectId, user_id: &str, r: MissionRef<'_>)
        -> Result<MissionId, EngineError> { ... }
}

The bridge then becomes a one-liner that picks the right variant from params. The two ambiguity rules (id+name simultaneous; _args[0]) collapse into one well-scoped place that has a unit test suite of its own.

[ilblackdragon]

Partially addressed in b74c42e. The typed engine API (MissionManager::find_by_name) is in place — that's the part future callers (CLI, WS, WASM channels, integration tests) will actually need. The 60-line param-parsing in the bridge stayed put because it deals in JSON and Tier-0 calling conventions (_args[0] etc.) that aren't a MissionManager concern. Happy to lift the param-shape policy onto a MissionRef enum + MissionManager::resolve in a follow-up if you'd prefer the typed-API form — should I file that?

[serrrfirat]

Trace fixture noise (Medium): the recorded CoinGecko response carries every header from the real Cloudflare/Coingecko response — cf-ray, x-request-id, etag, age, date, cf-cache-status, strict-transport-security, content-security-policy-report-only, etc. They aren't secrets, but they:

• bloat the diff (~941 lines for one e2e test, most of it duplicated headers across three identical price requests),
• pin the fixture to one Cloudflare datacenter (-FUK) and a 2026-05-01 timestamp,
• risk replay surprises if any HTTP cache layer in the stack decides to honor etag/age.

Suggest a fixture-redaction helper in tests/support/ (e.g. redact_response_headers(allow=["content-type", "content-length"])) applied at fixture-write time. Net result is a smaller, more reproducible fixture and one less drift source for replay-mode tests.

[ilblackdragon]

Deferred — agreed on the diagnosis. The fixture is committed to enable replay-mode CI runs, and a redaction helper that's careful to keep replay deterministic is its own small piece of work. Will file a follow-up issue today if you want; otherwise happy to tackle in a tiny PR right after this one merges.

[ilblackdragon]

Half 2 follow-up filed as #3166: 'Mission auto-resume after auth/approval gate resolution'. That issue covers persisting Mission.paused_gate, hooking the credential-write and gate-resolve paths to auto-resume matching paused missions, and the immediate-fire-on-resume behaviour. Out of scope for this PR.

[ilblackdragon]

Pushed b74c42e addressing the review feedback. Summary by reviewer:

serrrfirat:

• ✅ Perf regression — MissionManager::find_by_name typed API; bridge resolver stops scanning list_missions. Doc-comment names the future Store-level index drop-in.
• ✅ id+name foot-gun — new conflict guard errors loudly with both ids surfaced. Regression test mission_resolver_errors_when_id_and_name_disagree.
• ✅ _args[0] UUID precedence inversion — positional UUIDs no longer short-circuit ahead of explicit name.
• ✅ user_id info disclosure — dropped from EngineError reason strings on both mission not found and mission_get ownership arms; preserved in tracing::debug!.
• ✅ Test gap on migrated handlers — added by-name caller-level tests for mission_get, mission_complete, mission_pause+mission_resume.

Gemini:

• ✅ Legacy {id, name} rename preservation — landed earlier in commit 0bd586d with two regression tests; the new mission_update handler strips name from the resolver-view params when it detects the legacy shape, so the conflict guard doesn't reject it.
• ✅ Docstring/behaviour drift on resolve_mission_id — the docstring is rewritten to match the new four-step resolution order including the conflict guard.

Copilot:

• ✅ ApprovalAutoResponder task leak — Drop impl aborts the handle on panic.
• ✅ Stale "unreachable Ok(None)" comment in mission_get — corrected to call out the UUID-with-no-mission case.

Deferred:

• Trace fixture noise (Cloudflare headers) — filed for a small followup; the fixture is committed to enable replay-mode CI runs and stripping requires care to keep replay deterministic.
• Move resolver to MissionManager (architecture) — the typed API is now there (find_by_name); the param-parsing stays bridge-side because it deals with JSON/Tier-0 conventions.

Test results on b74c42e: 448 bridge tests + 89 engine mission tests, all green. fmt + clippy -D warnings clean.

[Copilot]

Pull request overview

This PR updates the engine-v2 bridge so mission_* (and routine_* aliases) can target missions by name (preferred) with UUID id as a legacy fallback, addressing the retry loop behind issue #2583. It also adds mission gate metadata/notification surfacing and introduces live/replay E2E regression coverage.

Changes:

• Add name→id resolution (resolve_mission_id) and migrate mission_get/fire/pause/resume/complete/update handlers to accept name (with legacy id fallback).
• Update mission tool schemas to advertise name as primary and introduce new_name for mission_update renames.
• Add live/replay E2E tests + shared helpers and fixtures; extend mission notifications with gate metadata and bridge-side status emission.

Reviewed changes

Copilot reviewed 12 out of 12 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/bridge/effect_adapter.rs	Adds resolve_mission_id and migrates mission handlers to name-first resolution; adds unit tests around the new behavior.
src/bridge/engine_actions.rs	Updates tool schemas/descriptions to prefer name, keeps id as optional legacy, adds new_name for renames.
src/bridge/router.rs	Extends mission-notification handling to surface gate state via StatusUpdate::{AuthRequired,ApprovalNeeded}.
crates/ironclaw_engine/src/runtime/mission.rs	Adds MissionGateInfo and emits it on ThreadOutcome::GatePaused; pauses missions on gate outcomes.
crates/ironclaw_engine/src/lib.rs	Re-exports MissionGateInfo.
src/channels/web/tests/no_silent_drop.rs	Adapts test notifications to include the new gate field and updated handler signature.
tests/support/test_rig.rs	Adds channel_handle() and a helper to send structured exec approvals.
tests/support/mod.rs	Registers shared live-mission helper module behind libsql.
tests/support/live_mission_helpers.rs	Adds shared live-test helpers (notification heuristic, approval auto-responder, waiters).
tests/e2e_live_routine.rs	Adds live/replay E2E regression test for #2583 prompt flow and notification assertions.
tests/e2e_live_mission_gmail.rs	Adds live/replay E2E test scenario around Gmail mission behavior and gate-related regression markers.
tests/fixtures/llm_traces/live/routine_btc_create_test_and_refire.json	Adds recorded trace fixture for deterministic replay of the live routine test.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ilblackdragon]

Fixed in 720a0db. MissionGateInfo.request_id renamed to call_id (matches what it actually carries — the engine LLM tool-call id). New MissionGateInfo.gate_request_id: Uuid is freshly generated at gate-emit time, and the bridge now forwards it (not call_id) into StatusUpdate::AuthRequired.request_id / ApprovalNeeded.request_id. The gateway resolve POST (features/chat/mod.rs:183/274/303 + platform/ws.rs:236) now sees a UUID-shaped string and won't 400. Mapping the gateway-issued UUID back to the engine call_id for actual auto-resume is half-2 (#3166).

[ilblackdragon]

Fixed in 720a0db — see reply on the sibling comment. Field renamed to call_id; new gate_request_id: Uuid is the user-facing identity. Doc-comment on the struct now explicitly contrasts the two fields and points at #3166.

[ilblackdragon]

Pushed 720a0db closing the last review-feedback items. Full status:

Just landed (720a0db):

• Copilot's UUID/call_id mismatch (high) — MissionGateInfo.request_id renamed to call_id; new gate_request_id: Uuid is generated at gate-emit time and forwarded to StatusUpdate.request_id. Gateway resolve POST (Uuid::parse_str at features/chat/mod.rs:183/platform/ws.rs:236) now accepts the auth-tray entries instead of 400-ing.
• Schema wording vs handler tolerance — mission_update discovery summary rewritten to match the conflict-guard contract.

Already landed earlier on this branch:

• b74c42e: find_by_name typed API + bridge perf fix; id+name conflict guard; _args[0] precedence flip; user_id info-disclosure scrub on two error paths; Drop on ApprovalAutoResponder; stale Ok(None) comment; by-name regression tests for mission_get/complete/pause/resume + conflict-guard regression.
• 0bd586d: legacy {id, name} rename preservation + two regression tests.

Deferred (each individually replied on the inline thread):

• Trace fixture noise (Cloudflare headers) — happy to file a follow-up issue or land in a tiny PR right after this merges; awaiting your preference.
• Full MissionRef enum + MissionManager::resolve typed API — typed engine surface is now in place via find_by_name; lifting the bridge's JSON-param parsing into a typed enum is a clean follow-up if you want it.

Test results on 720a0db: 19/19 mission tests in bridge::effect_adapter, 89/89 runtime::mission, fmt + clippy clean across both crates.