2 Commits

Include renames

Author	SHA1	Message	Date
Omar SobhandClaude Opus 5	a02e0cba69	feat(missions): Continuous Research harvests at launch, and cards launch by clicking ... The card shipped in e20b321 could not actually be used. Three things were missing, each of which failed at a different distance from its cause. **1. `default_team_template` was parsed and never read.** Every recipe declares one; `WorkflowRecipe` carries the field; nothing consumed it. A mission created from a card with no explicitly chosen team was rejected at LAUNCH with "no team_id, no team_template_id, no config.phase_teams" — one step removed from the real cause, which is that creation ignored the recipe. Create now resolves it via `team_templates::get_by_key`, only when the caller named no team of any kind, so an explicit choice still wins. A test asserts every shipped recipe names a template that has a `templates/teams/<key>.toml`, because a mismatch there produces an unlaunchable card. **2. The harvest ran nowhere.** `harvest_for_mission` existed and nothing called it. `on_launch` now runs it for `continuous_research` missions, before the phases start, and threads the blob store through from `main` (the route already had it on `AppState`; the scheduler needed it). Deliberately non-fatal: a harvest that fails still starts the phases, because the phase is what reports whether today was quiet or broken and those must stay distinguishable — but never silent, so both outcomes log their counts. **3. Nothing wrote the manifest.** `templates/teams/continuous_research.toml` has pointed its reader role at `ContinuousResearch/<date>/harvest.jsonl` since it was authored, and the file did not exist — agents aimed at a path nothing produced. `run_to_vault` now writes it beside the notes and stages it, but only for a mission-attributed run. `Harvest` carries the shelved `Paper`s to build it; re-parsing the notes we had just written would have been a parse of our own output and one more place for the two to drift. Also: the blob root. `storage.data_dir` defaults to "./data" and the container's cwd is `/`, so the server tried to create `/data` as uid 65532 and EVERY shelve failed with "storage io: Permission denied". The image now creates /var/lib/clawmates-blobs owned by 65532 so a mounted volume inherits it rather than arriving root:root. Kept off /var/lib/clawmates-missions on purpose: that tree is swept, and a paper shelved there would be deleted out from under its own catalogue note. Proven end to end on a real mission: 15 candidates, 2 already held, 13 shelved, 0 failed; branch auto-merged as additive-only; manifest on vault `main` with every documented key. The "already held" counts are the seen-set deduping across topics within a single run, which is the behaviour the whole design exists for. The project brief now comes from the mission description — `phase_task_text` already places it under BRIEF verbatim, so no new field was needed. 346 tests pass. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-17 15:05:37 -07:00
Omar SobhandClaude Opus 5	f87853ecf9	fix(missions): scheduled missions never fired — nothing read missions.schedule ... The wizard has collected a cron since `0047_missions.sql` ("schedule JSONB carries the trigger config (cron | one_shot | on_event)"), the frontend posts `{kind:"cron", cron}`, and the API persists it faithfully. Nothing has ever read it back: the only due-work enumerator in the codebase was `routines::claim_due`. So every scheduled mission ever created sat in `draft` forever while the UI reported it was on a schedule. Proven before fixing, on the shipped build: a mission with `* * * * *` sat in `draft` for 4m34s and started ZERO topology runs. After this change the same mission launched on its next occurrence and recorded one `fired` row. Two pieces were missing, and they are the two `routines` already had: - `missions.next_run_at` — schedule STATE. `schedule` is user intent and stays untouched; without somewhere to record which occurrence is owed there is nothing to put a `<= now()` predicate on, which is why no enumerator could be written against the JSONB alone. - `mission_fires` — one row per (mission, occurrence). 0063_routine_fires.sql called this exact case: "For a scheduled *mission* it costs a container, a repo checkout, and real money — which is why this lands before mission scheduling does." `mission_schedule.rs` deliberately mirrors `cm-scheduler`'s shape rather than inventing a second one: atomic `FOR UPDATE SKIP LOCKED` claim, reschedule BEFORE dispatch so a failing launch cannot stall the clock, claim the slot before launching so a crash mid-launch is retried rather than dropped, and a fan-out cap. The cap is 5, not the scheduler's 25, because a mission firing is a container and a checkout where a routine firing may be one turn. The claim skips `status = 'running'`: a daily cron on a mission that takes longer than a day must skip the occurrence, not stack a second crew on the same workspace. Launch goes through `mission_orchestrator::on_launch` + `missions::set_status`, the same path as the draft→running transition, so one code path mints a crew. An unattended launch acts as the workspace owner (`users::owner_of_workspace`) since missions carry no creator column; a workspace without one settles the occurrence `failed` with the reason rather than dropping it silently. Backfill blast radius was MEASURED, not assumed: prod has zero missions with a cron, this workstation had exactly one — the control created to prove the bug. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-17 14:10:39 -07:00