55 Commits

Include renames

Author	SHA1	Message	Date
Omar Sobh	82966a8004	missions: topology_worker dials per-mission runtime endpoint (C3 slice 3) ... When a topology_run is bound to a mission whose runtime_endpoint is set, the worker constructs ZeroClawDriveExecutor against that URL instead of the env-derived shared gateway. Falls back to shared for non-mission runs and pre-C3 missions. With slices 1-3 combined, a mission launched after this deploy will: 1. get its per-mission container spawned during on_launch 2. have its checkout dropped into /var/lib/clawmates-missions/<id> which is bind-mounted to /mission inside that container 3. run its agents against ZEROCLAW_WORKSPACE=/mission/repo — so they can see and edit only this missions repo, no bleed-over.	2026-07-21 22:31:42 -07:00
Omar Sobh	7649b213ad	missions: wire per-mission runtime container into launch + retry (C3 slice 2) ... - mission_orchestrator::on_launch now calls ensure_container after the repo checkout, persists the container_name + endpoint on the missions row. Non-fatal — logs and continues on docker errors so dev-mode + tests keep working. - phase_runner::launch_phase does the same as a fallback for any mission whose runtime_endpoint is null (pre-C3 or torn down). Nothing reads the endpoint yet; slice 3 swaps topology_worker over.	2026-07-21 22:30:22 -07:00
Omar Sobh	e5c0e5ec1a	phase_runner: ensure repo checkout on every phase launch ... Moves ensure_checkout into launch_phase so retries + new phase launches all trigger the clone/fetch. mission_orchestrator still does its own checkout at initial launch time, so first-launch timing is unchanged; this covers the retry + additional-phase paths.	2026-07-21 20:34:35 -07:00
Omar Sobh	94fecb526c	missions: retry failed phases + auto-purge on re-launch ... Every re-attempted phase now starts with a clean slate: - phase_runner::launch_phase DELETEs prior status IN ('failed', 'cancelled') topology_runs for the phase before enqueuing the new ones. Completed runs are kept for audit; only the failure noise from earlier attempts goes. - POST /api/missions/{id}/phases/{phase_id}/retry — resets a failed/cancelled phase to 'pending' (auth-scoped to the calling workspace + guarded on mission.status='running'). phase_runner picks it up on the next 10s tick. - MissionCanvas phase card grows a coral 'Retry' button, visible only when phase.status='failed' and mission.status='running'. Click → resets + refreshes; the prior failed run rows disappear from the card as soon as phase_runner enqueues the new attempt. Design: auto-purge in phase_runner rather than a separate 'clear failed runs' endpoint. Users don't have to manually clean up before retrying; the runner does it as part of the natural work of firing a fresh attempt. Verified: cargo check + tsc + eslint --quiet all green.	2026-07-21 13:14:39 -07:00
Omar Sobh	277189ea9b	missions: phase_runner — actually execute mission phases ... Root-cause fix for "we hit launch, waited overnight, nothing ran." mission_orchestrator materialized teams + agents fine, but nothing enqueued the actual work — mission_phases stayed 'pending' forever and topology_runs count for the mission was 0. New crates/cm-api/src/phase_runner.rs — background worker on 10s poll that does three things: 1. start_pending_phases — for every mission_phase with status='pending' AND parent mission.status='running' AND all lower-order phases already 'completed', enqueue one topology_runs row per team whose (mission_id, purpose) matches the phase kind: phase=research → teams with purpose='research' phase=coding → teams with purpose='coding' phase=benchmark → teams with purpose='coding' (fallback) phase=security_scan → teams with purpose 'security' | 'coding' Each run gets a phase-kind-specific task text combining the mission title/description + a directive for that phase. Flips phase to 'running' after enqueue. 2. close_finished_phases — SQL sweep that flips phases whose topology_runs are all terminal to 'completed' (or 'failed' if any run failed). 3. close_finished_missions — same shape for missions whose phases are all terminal. Spawned alongside task_card_worker in clawmates-server main.rs. Ordering enforced by mission_phases.order_idx — a coding phase doesn't fire until its research phase completes. Idempotent: every state transition is guarded so double-firing on a race is safe. When a mission has no matching teams for a phase (bad wizard state), the phase stays pending and the runner logs a skip rather than getting stuck in a fail loop. Existing topology_worker picks up the queued runs and drives them through the ZeroClaw executor as usual.	2026-07-21 09:17:18 -07:00