231 Commits

Include renames

Author	SHA1	Message	Date
Omar SobhandClaude Opus 5	f26de3ba76	feat(world): the agent page can answer what an agent DID, not only what it is doing ... The command centre's metric band reads a live feed: tokens in the last minute, credits in the last hour, active routines, pending approvals. Every one of those is correctly zero once a mission ends — so an operator opening an agent that ran `JEPA Research` was shown six zeros, with nothing saying the page had understood a different question than the one they asked. The data was never missing. `usage_events` carries a row per turn and `mission_events` carries every attributed tool call. Verified against production before any of this was written: Tomasz 21,697 tokens 22.00 credits 96 tool calls Seong-min 18,125 19.00 49 Adrian 13,855 14.00 32 Yara 9,686 11.00 11 Wei 7,228 8.00 18 Osei 4,304 5.00 5 The tool counts sum to 211, which is exactly what `mission_events` holds. The page simply never asked. `agent.last_run` is a SEPARATE taxonomy event, not a fallback folded into `telemetry`, and that is the whole design. `agent.task.update` already refuses to emit for a finished mission so that "idle" stays truthful; quietly substituting a two-day-old number into a tile the UI promises is live would undo exactly that. The two travel apart and the card says which it is showing: SPEND last-run credits, unit becomes `cr total`, tagged LAST RUN THROUGHPUT last-run tokens, unit becomes `tokens · last run`, and the sparkline is SUPPRESSED — a flat line drawn from one repeated number reads as "measured and steady" when nothing was measured WORKING ON idle stays idle, but names the mission, tool calls, tokens, NOW status and how long ago, instead of one line of nothing LOOPS/DOORS left live; zero is the correct answer there Live always wins. History appears only where the live value is genuinely nothing, so an agent mid-turn can never see a stale figure. Two details that would have been silent bugs: - `stateKey` keys the retained value per AGENT. One shared key would let the last agent in the roster overwrite every other agent's summary, and a late subscriber would paint one agent's last run onto all of them — plausible numbers belonging to someone else. - `usage_events` carries no mission id, so its rows are attributed by the mission's time window. `mission_events` needs no such guess, which is why the tool count is the trustworthy half of the row and the token figure is the approximate one. Said so in the doc comment rather than implying both are equally solid. Refreshed on the seed and then once a minute, not on the 2s poll: historical by definition, but not seed-only either, or a mission finishing mid-session leaves the card reading whatever it read before. Suite: 108 binaries, 842 Rust tests, 92 frontend tests, tsc clean. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01WZb5A2kfVfjpdwSochkuHz	2026-08-28 20:55:32 -05:00
Omar SobhandClaude Opus 5	ceec0423ad	feat(teams): staff research phases with a research team ... `research_only` is repo-less, one research phase, "produce a markdown artifact" — and it defaulted to `rust_sdlc`. So it was staffed with a planner, a coder, a tester, a reviewer and a committer, four of whom had nothing to do, each carrying the code-and-commit skills its role is bound to. Measured 2026-08-21: 9 distinct skills across 5 role prompts, ~50KB, one applicable. That is what "most skills score not_applicable" in the Skill-Use baseline has been measuring all along — the skills were correctly bound to their roles; the roles were wrong for the workflow. None of the three existing research templates fit, so this adds `topic_research`: frame the brief into answerable questions, gather evidence with the URL and the quoted passage, check every claim against its source, write the report. Three roles, four skills, each checked against its own `when_to_use` before binding — and two obvious candidates deliberately NOT bound, because `executive-summary-writing` tells the writer to discard any item not tied to a named project and `signal-to-noise-ranking` scores relevance the same way. On a standalone topic report that discards the deliverable. `default_phase_teams` lets a recipe staff each phase PURPOSE separately, resolved into `config.phase_teams` at create. A multi-phase recipe does not have one job: `research_and_code`'s research phase spends a paragraph of `task` telling its team not to change source files, because `rust_sdlc` gave that phase a coder and a committer and they did what coders do — mission 01a00c57 shipped both INT items during RESEARCH and the coding phase then delivered +0/-0. Prose was the only lever available; staffing is the actual one. Also fixed in the three existing research templates, all verified rather than inferred: - `papers_research` bound `arxiv-daily` to its DOMAIN SCOUT. That skill's entire content is "Do not search arXiv yourself — the harvest already ran", and its `when_to_use` names Continuous Research missions, which are the only ones the platform writes a harvest manifest for. The role whose job is searching was bound a skill forbidding it. - Its PAPER READER was told to "fetch the PDF, extract text". The runtime image has no pdftotext, no mutool and no pypdf — checked in the container. Every paper would have hit the `[read: abstract only]` fallback, which reads identically to the fallback working as designed. - `insight_research` cross-referenced "our repos'" history. A mission binds ONE repo (`missions.repo_id`). - `codebase_research` wrote to "the Obsidian vault"; no vault is mounted, and both it and `papers_research` were committing in "PRs", which the platform does not open. And `research_only` itself had neither `task` nor `done_when` — the same defect `benchmark`, `security_hardening` and `research_and_code` were each fixed for, and it was left out. A phase with no `done_when` is never judged. It also still asked for `pdf`, a format nothing generates. Two new guards, both negative-controlled: every team a recipe names must exist (a typo currently only logs, and the mission is staffed by the fallback crew looking deliberate), and every `default_phase_teams` key must be a purpose `purposes_for` actually emits. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_018i9Ten1LU4jUr5d7TAWda9	2026-08-21 09:35:33 -07:00
Omar SobhandClaude Opus 5	8cb38d1320	feat(missions): keep the tool's arguments, not just its name ... The container tier's first measured mission recorded `Bash × 6` and not one of them said what it ran. Every behavioural question about the phase — did it run the tests, did it commit, did it call an API a skill forbids — was unanswerable from a record that looked complete. `vm_tool_tap::parse` already read `tool_input` to pull the path out of it, then dropped the rest on the floor. It now keeps it, bounded: file bodies (`content`, `new_string`, `old_string`, `edits`) become a byte count, and any other over-long string is truncated with a marker saying so. Bounded rather than whitelisted, because a whitelist silently loses the one argument that matters the first time a tool grows a field. `file.touch` keeps the absolute path in `detail.abs` alongside the repo-relative `target`. Normalising is what the map needs and exactly what destroys "did this write land outside the checkout". `tool.call` also gains `detail.path`, which the World's SSE has been reading and getting a null from on every container-tier call. `mission_events::tool_evidence_for_mission` is the reader — the counterpart to `narrative_for_mission`, and the reason it exists: the narrative is what an agent SAID it did. Host-side only. No image rebuild: the arguments were always in the tap file, the first parse threw them away. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_018i9Ten1LU4jUr5d7TAWda9	2026-08-21 08:23:42 -07:00
Omar SobhandClaude Opus 5	5c2c63f8e8	feat(missions): a human can finally reach the plan/roster review gate ... Phase 4 of the plan, plus the PLAN_COMPLETE decision and the gitea_forge cleanup from Phase 5. THE REVIEW UI mission_plan and mission_roster have been complete and reachable by curl since they shipped, with zero frontend. That matters more than a missing screen usually would: the decide step is not a convenience, it IS the safety mechanism. Approving a plan replaces the mission's phases; approving a roster flips it to the composed engine. A gate nobody can reach is a gate that is always open or always shut. MissionProposalDrawer, modelled on LevelUpDrawer which already does load → review → decide. Reached from a mission's SETUP tab. Verified end to end against the live backend, not just compiled: a model proposed a roster, approval flipped the mission to `composed`, and approval on a non-draft mission was refused. The plan view shows each phase's done_when, and says plainly when one is absent — a phase without a completion condition is never judged and reports completed whatever it did, so its absence is the thing worth seeing. AND THE DEFECT BUILDING IT FOUND Every refusal path computed a precise reason — "the mission is running, not a draft", "no node can boot that backend any more" — logged it to stderr, and returned a bare {"error":"bad request"}. The person who needed the sentence was the one clicking Approve; they got two words, and the reason went to a server log they cannot read. ApiError::Refused(String) carries it now. Same argument ApiError::Unavailable was added for ("a 500 with 'internal error' sent them looking for a bug that was not there"), one status code down. Live: the 400 now reads "this mission is completed — a roster can only be approved while it is a draft, because approving one rewrites how the mission will run". PLAN_COMPLETE, decided The Skill-Use measurement found that int-xx-marker-protocol documents PLAN_COMPLETE and task_card_parser never implemented it, so an agent following the skill exactly was silently ignored. Implemented rather than removed from the skill: the planner needs a way to say it is done specifying, and agents already emit it. Marker ids are now strictly INT-<digits>. `starts_with("INT-")` accepted the range form `INT-01..02` — observed live — which parsed into an id matching no real item, so a task card appeared for something that did not exist while the two items it covered stayed open. Rejecting is right: an ignored marker is visible, a plausible row is not. GITEA_FORGE, REMOVED Named in nine places, defined in none. Harmless while provision_claw ignored the bundle list; once the list was honoured, an undefined name became a capability an agent is told it has and does not. Removed from seven team templates, a workflow recipe, the auto-provision path, and a dropdown a user could pick it from. A new test asserts every bundle a template names is defined in the runtime config — and it immediately found `web_fetch` in two templates I had missed removing by hand. Same shape as the skill-binding test, one layer up. Agents reach the forge through git over HTTPS with the ambient GITEA_TOKEN, which is why nothing ever broke. Full workspace suite green (106 binaries); frontend builds clean. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-19 11:56:54 -07:00
Omar SobhandClaude Opus 5	91a6b4e304	feat(skills): the first Skill-Use measurement, and the three defects it found ... Scored on the paper's three axes against two real missions on the local stack. docs/SKILL-USE-BASELINE.md has the numbers, the method, and the limits. Trigger is reported as NOT OBSERVABLE, never zero The paper measures progressive disclosure: the agent sees a name and description and must retrieve the body, and that retrieval is the Trigger event. We inline full bodies, because mission claws run on claude_cli which cannot surface a tool call — there is nothing to retrieve with. So the agent never reaches for a skill, it simply holds one. Scoring that zero would report a delivery-model property as an agent failure, which is the same confusion that kept 55 empty bindings invisible for months. The verdict type carries NotObservable(reason) as a distinct case from Fail for exactly this. Compliance is checked by running the REAL task_card_parser rather than a copy of its rules — a second implementation would drift, and then the score would pass while the mission loop still stalled. Skills without a machine-checkable consequence score not_applicable rather than a guess. WHAT THE MEASUREMENT FOUND 1. The prompt format made its own record unparseable. Skills were introduced with `## <name>` and skill bodies are markdown full of `##` headings, so run 1 scored "Sizing heuristic" and "The output shape" — subheadings inside decompose-int-items — as skills with no catalogue row. Now an unambiguous `--- SKILL: <name> ---` marker, with both writers sharing one renderer so the reader cannot drift from the writer. 2. A prompt was recorded that was never sent. My own Phase 1 work recorded the phase prompt at the dispatch fork, before the tier was chosen — and the container tier does not send that text, it sends the bare task and appends skills per turn. Every container mission logged a `solo` prompt that reached no agent. A provenance record of something that did not happen is worse than no record: it is the wrong answer, delivered confidently. Recording now happens inside each tier, with a test that every launcher records the prompt it actually sends. 3. int-xx-marker-protocol documents a marker the platform never implemented. PLAN_COMPLETE is in the skill's ladder and task_card_parser has no such kind and never has, so an agent following the skill exactly emits a marker that is silently ignored. Observed live: run 2's planner emitted `PLAN_COMPLETE: INT-01..02`, which is also the range form — on the kinds that ARE parsed that yields the id `INT-01..02`, a task card for an item that does not exist while the two real items stay open. This is a skill/implementation mismatch, not an agent failure, and it is exactly what the measurement exists to find: the agent did what it was told and what it was told was wrong. Both shapes now score as failures. The reconciliation — implement PLAN_COMPLETE or drop it from the skill — is left as a decision rather than guessed at. The boot log now shows what the plan asked for: 53 skills, 11 templates, every one `N role skills bound` with NO unresolved clause. Live missions confirm per-role delivery — the planner receives decompose-int-items, the coder receives write-rust-current-edition. GET /api/missions/{id}/skill-use exposes the scores, and says in its payload whether an empty result means "nothing delivered" or "the evidence was reaped" — those have very different causes and must not look the same. n = 2. No spread is reported because two runs cannot establish one, and the document says so rather than letting the number be quoted as a baseline it is not. Full workspace suite green: 106 binaries. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-19 10:54:58 -07:00
Omar SobhandClaude Opus 5	e4942ce985	fix(missions): skills can now reach a mission agent at all ... Repairing the 55 broken skill bindings made the catalogue correct. This makes it reachable, which it was not — for any skill, on any mission, since the catalogue was built. The skills had exactly ONE delivery channel: the `clawmates_skills` MCP server. A mission claw could not reach it for three independent reasons: 1. `provision_claw` wrote the constant `["clawmates_door"]` and ignored the template's mcp_bundles — which mission_orchestrator had already resolved and stored on the team row. 2. The runtime config defines no `clawmates_skills` bundle. The live local config defines no bundles at all, not even the door. 3. Mission claws run on `claude_cli`, which the runtime's own config comments document as text-only: it cannot surface a tool call, so no MCP server is reachable from a mission turn regardless of bundles. And a mission turn's whole system context is two sentences synthesised from the role slot in topology_exec::build_prompt. The template's role prose is not used either — mission_orchestrator documents this, and it means the role prompts describing which procedures to follow were never read. Two doc comments in cm-runtime describe the mission path as already having the summary-and-fetch contract. It never did. The belief was written down twice and checked zero times, which is why nobody looked — and it is why the Skill-Use measurement this review planned could only ever have returned a trigger rate of zero. That would have read as a finding about the agents. - provision_claw takes the bundles, with clawmates_door always added: a template that forgets to list it must not get an ungated agent - all 11 templates now request clawmates_skills; web_fetch removed, since a list that is honoured must not name a bundle that does not exist - the re-provision sweep re-asserts the team's own stored bundles rather than a constant, which would have silently stripped a capability mid-mission - pinned skill BODIES are injected into the mission prompt, bounded and with truncation stated. Bodies, not an index: there is no `skills.read` tool on this path, so an index would advertise a capability that does not exist — the exact failure this whole change is about Three tests: the body reaches the prompt, an agent with no skills adds no heading (an empty "Your skills" section announces skills the agent does not have), and the composition is exercised separately from the lookup, because `pinned_skills_text` working and `run_turn` calling it are different claims and the second is the one that was false. Also adds the three review documents: CAPABILITY-REVIEW (inventory, what was repaired, what is deferred and why), PROVENANCE-ASSESSMENT (assess only, per decision — what each store answers and the two candidate paths), and RESEARCH-SWEEP (the fortnight's papers and what we did about each, including the ones we deliberately did nothing about). Full workspace suite green. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-19 08:24:02 -07:00
Omar SobhandClaude Opus 5	18dc0b964b	fix(missions): the security scan phase now scans, and task upserts work ... Four defects, found by checking the audit's claims instead of trusting them. Two of the audit's own findings turned out to be wrong, and the registry that exists to record which config keys are read was itself inaccurate — so the corrections are part of the change. upsert_task raised 42P10 on every call, for every caller `mission_tasks_external_uniq` is a PARTIAL unique index (WHERE external_id IS NOT NULL). Postgres will not match a partial index to an ON CONFLICT target unless the statement repeats the predicate, so the upsert failed on its first row. Both callers — the task-card parser that turns INT markers into tasks, and the security scanner — map the error to a string their caller logs. Two features were broken and nothing was red. Regression test in cm-db with a negative control: reverting the WHERE reproduces 42P10 exactly. the security scan never ran `security_scan::run` was reachable only from an operator button, so security_hardening.toml — a workflow whose entire first phase is a scan — ran an agent that was never told to scan and never fired the scanner either. phase_runner now sweeps finished security_scan phases, mirroring the benchmark baseline sweep that was added for the identical defect. Guarded on a new completion marker rather than on findings: a clean scan writes no findings, so a findings-guard would rescan forever. The marker also answers the question an operator actually asks, which is not "how many findings" but "was this looked at, by what, and when". two recipes could not fail security_hardening.toml and benchmark.toml carried no `task` and no `done_when` on any phase. A phase without done_when never enters evaluating, is never judged, and reports completed whatever it did — so a security mission could scan nothing and go green, and a benchmark mission could record no baseline that the next refactor would then compare against. Both now state the work and the condition, with inert keys annotated inline rather than deleted, so the gap between what a recipe asks for and what a phase receives stays visible. the config registry was wrong in both directions `harness` was listed NOT IMPLEMENTED while benchmark_runner reads it and phase_runner runs a baseline through it. `tools` was listed NOT IMPLEMENTED while security_scan::run reads it. A registry that exists so an operator can trust what a recipe does is worse than useless when it is inaccurate. Both corrected, `bench_name` and `cmd` added, and `test_command` deleted — it had neither a reader nor a writer, so it described a situation that could not arise. Also: CLAWMATES_JUDGE_MODEL had two different defaults (opus-4-8 in routes/topology.rs vs opus-5 in cm_runtime::judge_model) and a doc comment naming a third; topology now calls the one function. GITEA_TOKEN's absence in mission_plan is stated rather than degrading to the same "could not be read" string a private repo produces. BRAINHUB_API_KEY needed no change — hub::push already rejects an unset key with a named error. That half of the finding was overstated. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-19 08:08:27 -07:00
Omar SobhandClaude Opus 5	ba98c29481	fix(podcast): the left rail showed the workforce, not the episodes ... The PODCAST tier had no branch in the left column, so it fell through to the default — the org/company/team roster. Opening the podcast page showed a list of agents, which is the one thing on that screen that has nothing to do with it. `PodcastList` now fills the rail with one card per episode (date, title, duration, size), the same shape `MissionsList` and `RepoList` give their tiers: objects in the rail, the selected one in the canvas. It selects the newest on first load so the canvas is never blank, and refreshes on the render sweep's own two-minute cadence so a new episode appears without a reload. `PodcastPanel` loses the duplicated list and becomes what a canvas should be: how to subscribe, and the selected episode with a player. The empty state points at the Continuous Research mission that produces one rather than just saying there is nothing. Verified on the served page: PODCAST renders between AGENT and REPOS. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-18 12:15:17 -07:00
Omar SobhandClaude Opus 5	fe45f72f09	feat(podcast): a PODCAST tier, a topics field, and a feed a phone can actually reach ... Three gaps between "the pipeline works" and "you can use it". **1. Topics could not be set.** The wizard never sent `config.topics`, so every mission created through the UI silently fell back to `library::default_topics()` — a hardcoded list that is somebody else's research interests. The card now takes one arXiv search per line, and the description field says plainly that for this template it IS the brief the agents judge relevance against. **2. There was nowhere to see or subscribe.** New PODCAST tier in the left rail, between AGENT and REPOS: the feed URL with a copy button, the episode list, and an inline player for checking one at a desk. `GET /api/podcast/episodes` and `/subscription` back it. The panel also reports how many missions produced no audio, so a missing day reads as a known gap rather than silence. **3. The feed 404'd for the only client that will ever request it.** Three layers each assumed a browser: - `resolveBearer` is server-only (`next/headers`), so a client component that imported it broke the build outright. The panel now goes through the same-origin proxy like every other panel, and the backend mints the feed URL because the session lives in an httpOnly cookie JavaScript cannot read. - The `/api` proxy demanded a session COOKIE. A podcast app has none and carries `?token=` instead — the same shape as the existing `hooks/` prefix, which is already exempt for exactly this reason. - The local autologin middleware 307'd it to `/auth/autologin`. A podcast app follows redirects blindly and would have stored an HTML page as the episode. Neither exemption weakens auth: the backend still validates the token and answers 401 to a bad one, verified. `episode_audio` accepts the token from either the query string or an Authorization header, because the app fetches it one way and the browser player the other, and refusing either breaks one of the two ways this is listened to. `CLAWMATES_PUBLIC_URL` matters and was wrong first: the tailnet root proxies to a different service on :18789, and this frontend is on :8443. A feed advertising an unreachable origin syncs silently forever, so `/subscription` returns a `reachable` flag and the panel warns when it is still localhost. Verified from a phone's point of view: feed 200 application/rss+xml over the tailnet, enclosure 200 with 6,739,582 bytes of audio at 421s, bad token 401. 367 tests pass. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-18 11:55:19 -07:00
Omar SobhandClaude Opus 5	1f39f642a3	feat(podcast): render finished missions into episodes, and serve them as a feed ... The renderer existed but nothing called it. This wires it to the missions and puts the result somewhere a phone can reach. **A sweep, not a phase step.** Rendering is not the agents' work and must not be able to fail a phase that succeeded; a transient API error simply retries next tick, and a mission already rendered is skipped because its episode row exists. `podcast_episodes` is that record — without it the sweep would re-render on every pass and re-bill for it, the same lesson `corpus_items` taught for papers. **It is racing a reaper.** script.md lives in the mission checkout, and `mission_runtime`'s sweeper deletes that tree 30 minutes after the mission reaches a terminal state. So the sweep runs every 2 minutes, leaving ~15 attempts inside the window. When it does lose — as it did for three missions that had completed hours before this shipped — it now SAYS so and records a marker rather than skipping in silence, which is how a feed ends up quietly missing a day. The feed filters those markers out: a zero-byte enclosure shows a broken episode in a podcast app, where showing nothing is honest. **Duration is read from the audio, not estimated from the script.** The feed advertises a length and that length should be the real one — and it is the check that catches a 6 MB file playing for six seconds. **The feed authenticates by query-string token**, because no podcast app can set headers. That is a real trade: the token lands in the app's database and any proxy log. It reuses `AuthService::authenticate`, so revoking the session revokes the feed with it rather than creating a second secret to forget to rotate. Titles are XML-escaped — one raw ampersand makes a client reject the WHOLE feed, not one episode. 363 tests pass. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-18 10:25:24 -07:00
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	e20b321055	feat(missions): Continuous Research is a mission type, not just a team checkbox ... `templates/teams/continuous_research.toml` has existed with three well-written roles since it was authored, but no workflow recipe pointed at it — every recipe in templates/workflows/ defaults `default_team_template = "rust_sdlc"`. So the only way to reach it was as a checkbox under Advanced. It is now a Step-1 card: the registry loads it at boot and `GET /api/workflows` serves it, with no frontend change (MissionWizard renders whatever the endpoint returns). Both phases are kind `research`, deliberately, rather than new `read`/`script` kinds. An unrecognised kind falls through `purposes_for`'s `_ => ["mission"]` and is absent from `PRODUCING_KINDS`, so it would get the generic directive AND be exempt from the empty-delivery rule — a phase that produces nothing and still passes. That is the shape this codebase keeps paying for; two `research` phases differentiated by `task` keep both guards. `commit_policy = "always"`, not `on_green_tests`: the vault is prose with no suite, so a test gate would find nothing to run and land every branch `-wip`. The harvest is NOT an agent phase. `continuous_research.rs` calls the existing `library::run_to_vault` — arXiv search, seen-set check, PDF shelf, vault note, attributed by `mission_id` — because that path is deterministic, takes seconds, and owns the `corpus_items` seen-set that is the whole reason a recurring mission knows what it already covered. An agent redoing it would be slower and would lose that. The manifest path is not invented either: the team template has told `signal_harvester` to write `ContinuousResearch/<date>/harvest.jsonl` all along. This makes the code produce what the prompt already promised, and a test pins the path and every documented key so the two cannot drift into an agent reading a file nothing writes. DEFAULT_CORPUS / DEFAULT_VAULT_URL exported rather than duplicated, so the route and the launch hook cannot disagree about which vault. 344 tests pass. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-17 14:18:35 -07:00
Omar SobhandClaude Opus 5	10341cf7fe	fix(missions): a retry's work is no longer silently destroyed ... Two independent bugs, either of which loses everything a retried phase produced, and neither of which reports a failure. 1. Capture is suppressed forever on a retry. Both `capture_finished_coding_phases` and the sweeper's last-chance `capture_outstanding_phases` skip any phase that already has a `code_diff` artifact. That guard is right for a phase that ran once and catastrophic for a retried one: the artifact from the FAILED attempt suppresses capture of the new attempt, the container is reaped on its normal grace, and everything the agents committed inside it is gone. The UI keeps showing the old diff, so the mission reads as delivered. `retry_phase` now clears the reopened phases' captures in the same transaction that reopens them, which is what makes its own doc comment ("the phase card starts fresh on the retry") true of the artifacts too. 2. `git add` exits non-zero over a gitignored path while staging correctly. Measured: with a populated `target/`, `git add -- . :(exclude)target` exits 1 and stages the right files; `-c advice.addIgnoredFile=false`, `--ignore-errors`, `-A` and `:/` all behave identically. Propagating that with `?` aborted the commit AFTER a successful staging — no branch, no commit, no push — for every Rust repo an agent has built in. `capture_phase_diff_at` already treats the same command as advisory; the commit path now does too, and the staged index decides. Mission 01a00538 hit both: it completed research and coding on the retry, 11 agent commits and all, delivered a patch dated the previous day, and lost the commits when the container was reaped. The remote was never touched — its HEAD still equalled the mission's own base_sha. Covered by a test that drives real git and asserts the files are staged regardless of the exit code. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-16 09:41:36 -07:00
Omar SobhandClaude Opus 5	43436d7181	feat(telemetry): push bus for live agent frames ... /api/world/live is a 2s database poll, which is right for queryable state and wrong for a token stream: reasoning only became visible after a step finished and its row was written. This adds a process-wide broadcast bus that topology_exec publishes to as the runtime's WebSocket delivers frames, and the SSE handler forwards without waiting for the next tick. Measured: the pushed frame arrived ~2.2s before the polled copy of the same text. Design notes worth keeping: - A global (OnceLock), not an AppState field. The publisher is reached through phase_runner -> topology_worker -> MissionTap, none of which hold AppState; threading a handle through all of them would put a UI concern into four layers that have no other reason to know about one. - Lossy by design. A slow subscriber lags and skips rather than applying backpressure to the agent producing. mission_events remains the durable record; this bus is the fast path, never the source of truth. - Only `claw_<uuid>` aliases are attributed. The governor, door and evaluator drive real turns under other names, and attributing their output to an agent would put words in someone's mouth. Asserted in a test. - The poll no longer emits `reasoning`: with both paths live, every turn arrived TWICE — once pushed, once polled ~2s later. The row is still written; this feed just is not its second mouth. CEILING, measured rather than assumed: turns are not token-level because the runtime is not streaming. zeroclaw's claude_cli provider runs `claude -p --output-format json`, which returns ONE result object when the turn completes — there are no incremental tokens to forward. Making this genuinely token-by-token needs `--output-format stream-json` and incremental parsing in the zeroclaw fork, not here. The bus is in place and will carry them the day it does. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-15 16:29:12 -07:00
Omar SobhandClaude Opus 5	ba9d7aa185	feat(telemetry): WORKING ON NOW shows the mission an agent is on ... The last of the three declared-but-never-emitted event types. `agent.task.update` had no producer anywhere in the backend, so the card read "idle — no active task" for an agent that was mid-turn. Derived rather than newly instrumented: an agent is working on its crew's RUNNING mission, and that mission's phases are the steps (completed/skipped → done, running/evaluating → active, else pending). Nothing is emitted for an agent with no running mission, so "idle" stays truthful rather than freezing on a stale last-known task. Verified on a live mission: 116 agent.task.update events observed on /api/world/live, carrying the mission title and phase steps, with the state advancing pending → active as the phase started. That closes the set. Of the seven cards in the command centre, five were dark: three had no emitter at all and two read a table the mission path never wrote. DOORS and LOOPS were correctly wired the whole time and were reporting an honest zero. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-15 16:03:42 -07:00
Omar SobhandClaude Opus 5	bf40d10064	feat(telemetry): the reasoning stream actually streams ... `agent.reasoning.delta` and `agent.tool.call` have been declared in the taxonomy and listened for by the command centre since it shipped — and NOTHING ever emitted them. The world feed emitted five types; neither was among them, so REASONING STREAM could not populate no matter what an agent did. The feed is a database poll, not a push bus, so a live card can only show what was persisted. The worker already holds each step's output text and the claw that produced it, so it records a `reasoning` mission_event (truncated — the card renders a tail, not a transcript, and mission_events is capped per phase), and the feed emits it forward from a cursor that starts at the current max so a page load streams rather than replaying history. `tool.call` is emitted from the same place. On the container tier it will stay empty, and that is correct rather than broken: those agents are tool-free behind the §15 door. Tool lines appear where agents actually hold tools. Verified on a live mission: agent.reasoning.delta observed on /api/world/live carrying the agent's own text, keyed by agentId. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-15 15:58:56 -07:00
Omar SobhandClaude Opus 5	8ef7067467	fix(repos): a scoped connection can name a user, not just an org ... Scoping a Gitea connection to `osobh` — the personal namespace clawmates itself lives in — failed with "org 'osobh' not found or PAT lacks access". The sync only ever called /orgs/{owner}/repos, and Gitea serves user namespaces from /users/{owner}/repos. The error pointed at permissions for what was really a wrong endpoint, which is the kind of message that sends you to rotate a token that was fine. Retry as a user on 404 before giving up, and say what was actually checked. Verified: owner=osobh now syncs 7 repos, owner=redclaw 22 — 29 instead of the 182 an unscoped connection pulls. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-14 21:00:17 -07:00
Omar SobhandClaude Opus 5	b290025fc4	feat(agents): make delete permanent, and expose the census ... A soft delete marked the row and left it. The agent stayed in the table forever, kept appearing on any surface that forgot `deleted_at IS NULL`, and deleting it again did nothing — the decision was recorded and never honoured. Two agents on this deployment had been in that state since June. `deleted` is now a fifth lifecycle state, collected with NO grace window: a human already decided, months ago. It takes usage_events with it, which is the explicit trade — the alternative is rows that outlive the decision to delete them. Two endpoints, because this was previously only answerable by reading the database by hand: GET /api/claws/lifecycle the census: who is active, completed, orphaned, deleted — and what is reapable POST /api/claws/lifecycle/sweep run the reap now, rather than waiting out the hourly timer for a decision already made Verified end to end: census reported both as `deleted`/`reapable`, the sweep returned {"reaped":2,"failed":0}, and agents and usage_events both went to 0. The safety property is unchanged and re-asserted by a new test: adding `deleted` did not make `owned` or `active` reapable. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-14 18:04:43 -07:00
Omar SobhandClaude Opus 5	ccbc387f4b	fix(agents): stop listing soft-deleted agents ... Deleting an agent looked like a no-op: it disappeared from the workforce but stayed on the Team board, and deleting it again did nothing because the row was already marked. Two queries selected from `agents` without `deleted_at IS NULL`: routes/team.rs the leaderboard — the surface still showing them routes/world.rs the "working" set — a deleted agent holding a stale agent_containers row rendered as live Observed on this deployment: /api/workforce correctly returned nothing while /api/team/leaderboard returned two agents soft-deleted back in June. NOT changed: those rows still exist. Making delete permanent means hard_purge, which also deletes usage_events — billing history, 6 credits on one of these two. Discarding that as a side effect of tidying a roster is an explicit decision, not something a display fix should smuggle in. .sqlx regenerated: team.rs uses the compile-time-checked query! macro, so the cached entry no longer matched. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-14 12:20:00 -07:00
Omar SobhandClaude Opus 5	a494634f81	feat(agents): classify agents by lifecycle and reap the finished and orphaned ... A mission mints a crew, and the only thing that reaped one was DELETING the mission. A mission that merely completed left its agents in the roster forever, and a crew whose reap was skipped or failed left agents bound to nothing — indistinguishable in the UI from the operator's own staff. Four states, from one query: owned no agent_template_link row → hand-created. NEVER reaped. active on a running/draft mission → working right now. Kept. completed every mission terminal → reaped after a 24h grace. orphaned minted, bound to nothing → reaped. The discriminator is `agent_template_link`, which mission_orchestrator writes per minted claw. This matters more than it looks: verified on live data, a hand-created agent and an orphaned crew member both have ZERO team links and are structurally identical by binding alone. Judging orphanhood by "no team" would delete the user's workforce. Provenance is the only honest signal. The grace window exists because the results view, the World's 24h replay and "who did this work?" all read the crew AFTER the run ends; reaping on the terminal transition deletes the answer exactly when the question gets asked. A completed crew with no usable timestamp is KEPT — a missing date must never read as "old enough to delete". Also fixes the delete summary, which reported how many claws were FOUND rather than purged: "reaped 4 claw(s)" was printed by a delete that purged none, which is precisely the log you would read while wondering why the agents are still there. It now reports purged / kept / FAILED, and failed > 0 is the orphan case. Verified against live data — all four states observed, including the two that look alike. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-14 10:55:56 -07:00
Omar SobhandClaude Opus 5	f8438c32ea	feat(viz): kind-specific choreography and a finished mission you can read ... Security: the pawns already orbited their destination, so homing them at the security station gave circling for free. This adds the radial press-and-retreat — an agent closing on the target and backing off reads as probing it, where a fixed radius reads as waiting — and holds the stochastic target release while probing, or the circling breaks up into stray trips that look like distraction rather than a scan. Findings are `mission_tasks` rows, one orb each, popped once. There is deliberately no severity anywhere in the path: the scanner keeps severity, file and line as substrings inside `title`, so a severity parsed out of prose and rendered as an orb's RADIUS would be the picture asserting a measurement the data never contained. Count only. Benchmarks annotate the station, as text. `delta` has no schema — compute_delta emits `{kind:"opaque"}` whenever the before/after metrics were not structurally comparable, which is most drivers. The server formats the shape it can parse and COUNTS the rest; an unparseable driver reports "3 sample(s)" rather than an invented improvement, and an opaque delta says nothing at all. The finished map: the live label rule gates service/event nodes on `heat > 0.12`, which is exactly backwards once everything has cooled — a static map would be unlabelled dots. Frozen, the 25 most-touched nodes label regardless of heat, phase stations carry a second line counting what they produced, and the camera is released ONCE so it frames the result even if the user panned during the run. Every count in a caption is read off the drawn scene rather than a parallel tally, so the words and the picture cannot disagree. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-11 09:22:16 -07:00
Omar SobhandClaude Opus 5	9e61e3ba35	feat(viz): what the agents actually did, as structured events ... The World could draw a mission's shape but nothing about the work. The detail existed only as prose in checkpoint.log and model output, where a tool name is indistinguishable from an agent *talking about* a tool — so it was never parsed, deliberately. `mission_events` is the structured channel that replaces it. Three taps, one table: - Container tier: the `_ => {}` at the end of topology_exec's typed frame stream now matches `tool_call` and reads the tool's JSON ARGUMENTS for a path. Never the prose summary — a path scraped from a sentence would put files on the map that no agent opened, and the test proves a Grep whose summary says "src/main.rs" produces no file touch. The frame name itself is unverified, so the same commit ships an unmatched-frame-type histogram: a tap that matches nothing looks exactly like a mission that used no tools, and this is how one gw-04 run names the real frame. - microVM tier: a `PostToolUse` hook, the seam vm_stop_gate already proved fires under `claude -p`. It copies stdin to /root/tap and exits 0 unconditionally — a non-zero PostToolUse hook talks back to the model, which would turn the observer into a participant. Drained before collect, since the VM is destroyed moments later. - Phase transitions: five identical copies of the pending→running UPDATE became one `mark_phase_running`, and `close_finished_phases` grew RETURNING. Its CASE decides each phase's status inside SQL from rows the statement does not change, so it cannot be re-derived afterwards without writing that CASE twice — without RETURNING it emits zero phase.completed and reports success. The settings.json hazard the plan called out: the stop gate wrote the WHOLE document, so a second hook writer would have silently erased it and a coding phase would then complete having written nothing — the exact failure the gate exists to catch. There is now one composer, `vm_tool_tap::guest_settings`, one writer, and a source-walk test that fails if anything else writes a settings document. `mission_events.run_id` carries no FK on purpose: phase_runner DELETEs topology_runs on retry, and a cascade would erase a phase's whole history the moment it retried — silently, since a cascade is not an error. world.rs streams it with a cursor that separates backfill from motion. Everything already in the table when a subscriber arrives is drawn as settled history; only what lands afterwards animates. Otherwise opening a finished mission replays an hour of tool calls as a burst storm. Bounded twice: 400 events per phase (enforced inside the INSERT, since two concurrent taps would each read a count below the cap) and a 7-day retention sweep in mission_gc. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-11 09:16:50 -07:00
Omar SobhandClaude Opus 5	c2fa8067e1	feat(viz): the coding station fractures into the files it worked on ... The engine already turned `file:src/lib/a.ts` into a real dir chain, but both copies of that loop rooted it at the origin — so a mission's files floated beside the map instead of belonging to the work that produced them. One `fileParent` helper now serves both call sites; splitting them was how half the files could end up nesting correctly and half not, decided by whichever code path saw the file first. Files hang under the coding station when there is exactly one, else the single running phase, else the origin. `world.touch` carries no phase id, so with two coding phases any attribution is invented — the fallback is the honest answer. Two ordering hazards, both silent: - the server emitted files BEFORE phases, so on the first pass a file arrived with no station to hang under and first-write-wins pinned its tree at the origin. Loops reordered, with a source-walk guard. - `setFileHome` re-parents trees rooted before the plan landed, for the reconnect case the ordering alone cannot cover. `mission.file` with `source: "tool"` is treated as motion (burst, pawn beams); `"diff"` is end-of-phase truth and only marks the file present and warm — bursting every file of a captured diff would set the whole map alight at once on reconnect. Directories taper in radius and opacity by path depth, so `src` and `src/lib/live` no longer render as identical dots. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-11 08:29:55 -07:00
Omar SobhandClaude Opus 5	006432c2dc	feat(viz): the mission becomes a map — centre, stations, and agents at theirs ... The clump was structural, not cosmetic. Four causes, each fixed here. `homes` (an agent's resting node) was written only by `seed()`, so every agent homed to the mission centre and orbited the same dot regardless of which phase it was on. `setHome` points each agent at its CURRENT phase, and the existing physics does the rest for free: the pawn rests at its station, the pawn→home line tethers it there, and a touch becomes a visible departure and return. No new motion code. The mission node was seeded as `level: "team"` (my own bug from the focus work). `seed()` casts that straight to a Tier and `ensureNode` is first-write-wins, so it was created as a small teal team dot that the later `node.activity` could never upgrade. That dot at the centre of the scene was one line. `mission`/`phase` replace the retired `repo`/`loop` tiers rather than adding a parallel set. The backend stopped emitting repo:/loop: ids, which left their whole landmark treatment — bigger radius, distinct colour, always-labelled, 60s fade instead of 22s — orphaned on prefixes nothing sends. Missions and phases need exactly that treatment. The two separately-written prefix→tier ternaries in onTouch and onNodeActivity are now one `tierFor`: they agreed only by luck, and whichever path saw a node first fixed its tier forever. Phase stations spring out at 190 rather than the shared 64, or they pack into a rosette around the centre and the point — agents moving BETWEEN stations — is invisible. Idle roam is off under a mission scope: wandering to a random node keeps an idle workspace alive, but inside one mission it sends agents to files nobody opened, which reads as work and isn't. Palette is injected at construction and keyed on template_kind, so a benchmark run and a security sweep no longer render identically to a research mission. It also collapses two uncoordinated kind→colour maps that had drifted: LEVEL_COLOR by tier, and the fireColor if-chain by id prefix. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-10 18:17:12 -07:00
Omar SobhandClaude Opus 5	5f85dbb718	fix(world): missions were never really on the wire ... Three bugs in one query, each hiding the next, plus one that made the whole rich layer dead code. `active_missions` joined `team_members` on `missions.team_id` — the LEGACY pointer at the first minted team, superseded by the `mission_teams` junction in 0056. It was an INNER JOIN, and `mission_orchestrator::on_launch` deliberately mints no team for a microVM mission, so the platform's primary execution tier was dropped by a join and the World has been showing nothing at all for it. And it selected only `status='running'`, while missions finish in minutes, so the scene was empty almost always. Now: join `mission_teams`, LEFT so teamless missions survive (their `agent_id` is NULL and no pawn beams at them, which is the truth — nothing on this platform ran that phase except a VM), and include missions finished in the last 24h carrying `status`/`template_kind` so the client can draw a finished map instead of animating a corpse. `?mission=` scopes the feed server-side. The whole phase plan now ships as `mission.phase`, including phases that have not started: a phase list that appeared only as phases began made a five-phase mission look like a one-phase mission until it was nearly over. Attribution reuses `phase_runner::purposes_for` rather than copying it — two copies would let the picture disagree with the machine about who is working on what, which presents as a rendering bug and is really a lie. Deleted the checkpoint tail. It read `topology_runs` keyed by an `agent_runs` id; mission phases live in `topology_runs` under independently generated ids, so it ran every poll and matched nothing, for every mission, forever. That is why no mission has ever shown tool or file activity. Not repointed at `topology_runs`: its only per-step content is the agent's own prose, and a tool name in prose cannot be told from an agent talking about a tool. The a2a `run_events` tail is kept — it genuinely works for the path that writes it. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-10 17:58:38 -07:00
Omar SobhandClaude Opus 5	c85027c83a	fix(workforce): team_members.role, not role_slot ... The roster query named tm.role_slot. That column is on agent_template_link; team_members calls it plain `role`. These queries use untyped sqlx::query(), so nothing caught it at compile time and the endpoint 500'd on its first real request — the 401 an unauthed probe returns looks identical whether the SQL is valid or not, which is why the payload had to be fetched with a real session before believing the route worked. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-10 14:32:22 -07:00
Omar SobhandClaude Opus 5	0ad53da49c	feat(workforce): missions group the roster, and agents get human names ... Three things, all visible on the agents page. **The roster looked like it was multiplying.** The sidebar flattened orgs → companies → teams → agents, which renders a claw once per TEAM it belongs to. Claws are reused across missions now, so a crew of five that had run five missions appeared as twenty-five rows of the same five people. The data was right and the view was lying. `GET /api/workforce` returns the roster grouped by mission, and the tree renders each mission as a collapsible group, so the repetition means something: the same colleague under each mission they staffed. Claws on no mission come back under "Not on a mission" rather than vanishing. The root now counts DISTINCT people, not rows. **Agents were named after their jobs.** A team came back as planner, coder, tester, reviewer, committer — the UI showed the same word twice (name on top, role beneath) and the roster read as a stack of job tickets. New claws get a given name from a deliberately wide pool (Amara, Vijay, Tomasz, Meredith…), unique against the workspace roster AND within the team being minted. The role is untouched in `job_title`, which is what the mission machinery binds on: team_members.role_slot and the topology node carry the slot, so nothing downstream keys off the display name. A reused claw keeps the name it had. **Two latent reap bugs found while investigating a leak that was not one.** Containers of completed missions are removed by `spawn_sweeper` after a 30-minute grace, and it works — an earlier report of leaking containers was me reading that deliberate grace as a bug. But: - the sweeper cleared the runtime binding even when teardown FAILED, and it selects on `runtime_endpoint IS NOT NULL`. One transient docker error would therefore hide a surviving container from the only thing that would retry it, permanently. It now asks docker whether the container actually survived: gone means clear, still there means keep the binding and retry — which closes the orphan path without reintroducing the infinite retry the original comment was guarding against. - `set_runtime_binding` discarded rows_affected, so a mismatched workspace updated nothing and returned Ok. The binding is how the sweeper finds a container; a silent no-op there leaks one with no record of anything wrong. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-10 14:26:42 -07:00
Omar SobhandClaude Opus 5	fe2451fd60	feat(workforce): missions hire the agents you already have, and name them by role ... Every zeroclaw mission minted a fresh team of claws. They are created `lifecycle = 'permanent'` and nothing reaps them until the MISSION is deleted, so the roster grew by a whole team per mission while each member worked exactly once — "My Workforce" was a list of strangers, and upskilling had nothing durable to act on. A mission now hires the claw that already does the job, matched on `agent_template_link (template_id, role_slot)`, minting only what is missing. Oldest first, so reuse concentrates on the same few claws and their brains actually accumulate rather than spreading thinly across a growing pool. A claw on a RUNNING mission is not offered. Two missions driving the same ZeroClaw agent and the same `.brain` at once is a data race with a model on the other end of it, and minting a second claw is much cheaper than reasoning about that. A reused claw is NOT re-seeded from the template's brain_seed — that would overwrite what it learned with its starting point, which is precisely the accumulation this exists for. Names are the role now (`planner`), not `"{mission} · {purpose} · {template} · {slot}"`. That produced "verify: a repo-less research mission keeps its output · mission · Rust SDLC · planner" — unreadable in the roster, the API and every log line at once. Which mission a claw is on is context a caller can join to; it is not its name. And the half that makes reuse safe rather than destructive: deleting a mission now purges only claws no OTHER mission still employs. Without it, tidying up one mission deletes staff another one holds — presenting as the roster quietly shrinking rather than as an error. A test asserts the guard exists inside the reaper AND runs before the purge, because a check after it is decoration. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-10 07:18:12 -07:00
Omar SobhandClaude Opus 5	25f075a8be	feat(api): polish a description before the mission exists, and download an artifact ... Two endpoints the wizard redesign needs. `POST /api/missions/refine-draft` — the polish button fires while the user is still typing, before anything is created, so it has no id to route on. `refine` deliberately requires a saved draft because its Accept writes back; this one has nothing to write back to and returns the text. Same system prompt, same model chain. The phase list comes from the workflow recipe rather than the caller, for the same reason `phases_for_create` prefers it: a client that guessed would have the model write acceptance criteria for phases the mission will not run. `GET /api/missions/{id}/artifacts/{artifact_id}/download` — the file itself. `artifact_content` caps at 2 MiB and reads as UTF-8, so a large or binary artifact is unreachable by any means today; this streams the bytes with a filename attached and no ceiling. Both artifact routes now resolve through ONE containment check. Two copies of "is this path under _outputs" is two chances for one of them to be the lenient one, and the lenient one is an arbitrary read of the gateway's filesystem — so a test asserts there is a single resolver and that both routes call it. The download filename was chosen by an AGENT and lands in a header every browser parses, so quotes, backslashes and control characters are stripped rather than escaped; the test covers a header-injection attempt. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-09 18:45:46 -07:00
Omar SobhandClaude Opus 5	f27d2605eb	fix(agents): a soft-deleted agent could never be purged ... Clearing the fleet's four leftover agents returned 404 on every one. They had been soft-deleted back in June — correctly invisible in the UI ever since — and `agents::get` filters `deleted_at IS NULL`, so `workspace_agent` could not find them. Every route uses it, including `batch-delete`, the one that exists to HARD-purge. So a soft-deleted agent was unreachable from the application entirely and its row stayed forever. `get_any` sees them, and only the purge path uses it: hiding soft-deleted rows is right for every read, and wrong for the one operation whose whole job is removing them. Written with `query_as` rather than the checked macro so it does not force an offline-cache regeneration on every machine that builds this. `fleet-reset.sh` now uses `batch-delete` for agents rather than `DELETE /api/claws/{id}`. The latter is a SOFT delete, so pointing a reset script at it would have quietly added to the pile it was meant to clear. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-09 18:15:56 -07:00
Omar SobhandClaude Opus 5	16cfc29074	fix(ui): the backend picker showed two options meaning the same thing ... `default` is the generic `rootfs.ext4` and `claude` is the named one, and `microvm_credential_for` gives them the identical contract — so the list came back with both under the same label, and whichever a user picked they got the same thing. Collapsed to the named one where it exists; the generic keeps a label of its own for a fleet that only has that. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-09 15:52:30 -07:00
Omar SobhandClaude Opus 5	529497febb	fix(placement): a composed graph needs every backend its nodes name ... The full harness found it — 12 of 13 scenarios green, `roster` red: roster: the planner sized this mission at 2 member(s) PASS roster: the approved roster is on the mission (2 nodes, composed) PASS roster: this run added 1 line(s) for a 2-member roster FAIL topology_runs.error: turn executor failed: node n1 in a microVM: vm_create failed: no rootfs for backend "canary-claude" on this node The roster proposed `verifier@canary-claude`. Placement asked `online_for_backend` about the MISSION's backend — `claude` — and architect answered, holding `claude` and `local-ornith`. The graph's first node ran and delivered, the second could not boot, and the mission finished half-done. The question placement asked was true and insufficient. A composed graph runs on ONE node, so that node needs every image its nodes ask for. `required_backends` collects the mission's plus each `config.roster.nodes[].attrs.backend`, and `online_for_backends` passes the whole set to the same jsonb `@>` — containment already means "contains ALL of these", so the query shape did not have to change, only what it was asked. This is the failure mode the roster feature creates by existing: its entire purpose is putting a verifier on a different provider, which is exactly what makes one node insufficient. Nothing before the full suite had a reason to exercise it — the composed scenario uses one backend for all five nodes. `NoCapableNode` now names the set and says why one node must hold all of them. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-09 15:36:40 -07:00
Omar SobhandClaude Opus 5	c66c3c6377	feat(ui): the microVM path is reachable from the mission wizard ... Everything built today — Firecracker missions, the four backends, the local GPU one — was unreachable from the dashboard. The wizard offered `zeroclaw` and `local_herdr` and nothing else, so a mission created in the UI could not be a microVM mission at all, and `local-ornith`/`glm`/`kimi` were API-only. Testing "our workflows in the UI" would have exercised none of it. Adds the runtime option and a backend picker, fed by a new `GET /api/fleet/backends` that returns `mission_roster::available_backends` verbatim — the SAME list the roster planner is handed, not a second one. Its two rules are both load-bearing and neither is visible from a node's capabilities alone: the image must be built on an online node, and the backend must have a credential contract. `agent-terminal` passes the first and fails the second — bootable, with nothing for the agent inside to authenticate with — so offering it would produce a mission that validates, launches, and dies at the agent turn. Ids are deployment vocabulary, so the picker labels them: a user choosing between `local-ornith` and `canary-claude` should not have to know which company each one bills. An empty list says why (no rootfs built) instead of showing an empty dropdown, and no node is chosen for a microVM mission because `vm_placement` picks it per phase. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-09 15:09:07 -07:00
Omar SobhandClaude Opus 5	dc0443de34	feat(fleet): GET /api/fleet/capacity returns the scheduler's own survey ... Pulled forward from the observability phase because the capacity harness scenario needs it. A test that recomputed the slot arithmetic in bash would drift from `vm_placement` and then agree with itself while the scheduler did something else — the same shape as every silent-success bug in this codebase. Returns `survey()` + `rank()` unmodified, and keeps `unfit` as its own list: "the fleet is full" and "we could not read the fleet" send an operator to different places, so they must not be summed into one number. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-09 05:11:21 -07:00
Omar SobhandClaude Opus 5	d48bdbc9a7	fix(llm): two modules were posting to Anthropic behind the providers' back ... The research scenario passed 4/4 and the log underneath it said: phase_summarizer: ... failed: anthropic 400 Bad Request: "Your credit balance is too low to access the Anthropic API" `phase_summarizer` and `mission_refiner` each built their own reqwest POST to the Messages API with `x-api-key: $ANTHROPIC_API_KEY`. No audit of `.complete(` call sites could have found them — they never touched a provider — so every phase summary and every mission-brief refinement on this deployment had been failing against an empty account while the phases themselves ran fine. The summarizer even persisted an error row per phase, which is why nothing ever retried loudly enough to notice. Both now go through `subscription::complete_with_fallback`, so they inherit the subscription-first credential choice, the 429 backoff, and the opus -> haiku -> glm chain. The summarizer records the model that ANSWERED in mission_phase_summaries.model rather than the one it asked for. The guard is a source WALK, not a file list: any .rs under cm-api/src that mentions the Messages API host or `x-api-key` fails the test. A hand-listed set of files is exactly what let these two hide. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-08 23:11:38 -07:00
Omar SobhandClaude Opus 5	9c9439a271	feat(llm): the subscription is the default provider, with a recorded fallback chain ... Two changes so an empty metered account stops being a platform outage. 1. `build_provider` prefers the subscription token over ANTHROPIC_API_KEY. A bare model name resolves to whatever this returns, so making it the subscription means no server-side call can reach the metered key by construction — rather than by a source-grep test that already missed four call sites once. The metered key remains a fallback and now warns loudly when it is the one in use; boot no longer requires it at all. 2. `complete_with_fallback` walks a declared chain when a model has no capacity: opus -> haiku -> glm:glm-4.7 by default, overridable via CLAWMATES_MODEL_FALLBACK, empty to disable. Measured on gw-04 today: opus and sonnet return 429 on the subscription while haiku, GLM and Kimi all return 200, so a capped window no longer means "the planner is gone". The chain returns the model that ANSWERED, and every caller persists it — mission_plan_proposals.author_model, mission_team_proposals.author_model, and the swarm's step role. A plan drafted by the third link and filed as an opus plan is a silent quality change, which is the failure shape this project keeps paying for. Two negative controls hold the design: the chain never retries the model that just failed as its own fallback, and it steps down ONLY for a capacity failure — walking it on a malformed prompt would ask three models the same bad question and report the third one's confusion. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-08 22:56:01 -07:00
Omar SobhandClaude Opus 5	ee5a939ce6	fix(planner): the other four server-side calls were still on the metered key ... The test that was supposed to prevent this grepped for the literal `runtime.complete(` and passed while the phase planner (`mission_plan.rs`), both swarm calls, and a second enhance path in `claws.rs` still billed the pay-as-you-go account. They spell the receiver `state.runtime` or wrap the call across lines, so the receiver name was never the thing to match. The test now matches the METHOD, and covers all five files. `complete_or` gains the rule that makes it safe to apply everywhere: a `name:model` spec is an operator's explicit provider choice — the swarm worker model is configured exactly that way — and is passed straight to `Runtime::resolve_provider` untouched. Only a bare name is ambiguous, and a bare name is precisely what resolves to the default provider. Hijacking a chosen Kimi or GLM model onto Anthropic would be the same silent-substitution bug pointed the other way. `validator_preflight` and the evaluator judge keep calling the runtime directly, on purpose: both exist to exercise the CONFIGURED spec. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-08 15:55:52 -07:00
Omar SobhandClaude Opus 5	deed591da6	fix(roster): a rate-limited subscription is a 503 with a reason, not a 500 ... The retry landed and still failed: all four attempts returned 429. A bare 16-token probe with the same token, straight from gw-04, also returned 429 with `x-should-retry: true` — the Claude Code subscription itself is limited right now, and no amount of backoff inside one HTTP request will outlast it. So stop pretending it is a server bug. New `ApiError::Unavailable` → 503, carrying the one sentence the operator can act on ("clears on its own; try again shortly"), instead of an opaque `internal error` that sends them into the logs. The harness now prints the response body rather than the generic "the planner produced no usable proposal", which is what hid both walls — first the credit balance, now this. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-08 15:50:29 -07:00
Omar Sobh	72046e7985	fix(planner): server-side model calls run on the subscription, not the metered key ... The roster planner died with `400 — "Your credit balance is too low to access the Anthropic API"` while every mission on the same machine kept running. Two Anthropic credentials reach this server and they bill differently: `ANTHROPIC_API_KEY` (sk-ant-api, metered, runs out) and the Claude Code subscription token (sk-ant-oat) that every VM already uses. `Runtime::complete` with a BARE model name — "claude-opus-4-8" — resolves to the default provider, which is the metered key. Three server-side callers did that: the roster planner, the Master Planner, and the claw enhancer. Missions were never affected because `mission_runtime` deliberately sends only the subscription token into a guest; the server had no equivalent rule. `subscription::complete_or` is now that rule, and it is the ONE place a subscription token becomes a provider — `evaluator::subscription_judge` had its own copy, and two of them is how one ends up with a prefix check the other lacks. The `sk-ant-oat` prefix is checked rather than the variable name trusted: an API key pasted into the OAuth slot would authenticate, work, and bill the metered account — the same failure again, discovered weeks later. `web_search` is carried explicitly rather than defaulted. The Master Planner and the claw enhancer both pass `true`, and a helper that quietly dropped it would have taken web search away from two features while every test still passed. `validator_preflight` deliberately keeps `Runtime::complete`: it probes whatever validator spec is configured (today `glm:glm-4.7`), and forcing it onto Anthropic would make it prove the wrong thing. A test pins both halves — no other server-side caller may regress to the metered key, and preflight must keep probing the configured spec. 258 lib tests.	2026-08-08 09:34:19 -07:00
Omar Sobh	5b49d5a1a8	feat(merge): gate publication on the merged tree's own tests ... The other half of the merge button. Merging told you the branch went in; nothing checked that what came out still worked. Verified BEFORE publishing, not reverted after. `merge_locally` and `push_merged` are separate functions so the caller can run the project's tests between them, which means a merge that breaks the base is simply never pushed — `main` is not broken for however long it takes someone to notice. A test asserts `merge_locally` contains no push, because the moment it does, verification becomes after-the-fact and the guarantee is gone. Outcomes, all reported to the operator rather than swallowed: Passed -> published NoSuite -> published, and SAID so; a repo with no tests is a fact about the repo, not a pass Failed -> not published, exit code reported, branch untouched so it can be fixed and merged again CouldNotRun -> not published. Fail closed: a suite that could not run has not passed, and publishing on "we could not check" is how a green main stops meaning anything. `verify_tests` runs `cargo test` as ROOT in a container, so the merge workdir ends up holding a root-owned `target/` the server (uid 65532) cannot delete — the same leak found three times today. Purged through the container before the ordinary cleanup. 248 lib tests.	2026-08-07 22:51:14 -07:00
Omar Sobh	0b89b8316c	feat(observability): stream a microVM turn's stdout/stderr to the platform live ... The Live tab showed nothing while a turn ran, and the agent's own account of it went to stderr on the node and nowhere a user could reach. This is the path that carries it. The blocker was the guest agent. `fcagent` handled one connection at a time, inline, so during an hour-long turn the VM accepted nothing — which is why every existing probe (subagents, stop-gate blocks, cap) runs AFTER the turn rather than during it. It now spawns a thread per connection, wrapped in `catch_unwind` because this process is pid 1: a panic used to take the accept loop with it, and an unbootable VM is a far worse outcome than a missing log. A failed spawn logs and keeps accepting rather than dropping the listener. PROVED against a live VM before building on it, since "sound reasoning about this system" and "measurement" have diverged repeatedly today. Patched rootfs, booted under Firecracker, ran an 8s exec and a concurrent tail: exec took 8.0s ok=True +0.0s 'line1\nline2\n' +1.2s 'line4\n' +3.2s 'line6\n' +6.0s 'DONE\n' VERDICT: CONCURRENT — tail returned data before exec finished The rest is the pattern the terminal already uses. New `tail` op streams a file by OFFSET (so a dropped link resumes instead of replaying, and the tail always terminates — one that never returns pins a thread for the life of the VM). The node follows the log alongside the turn and pushes `Uplink::VmOut { run_id, at, data }` over the WebSocket it already holds, mirroring `PtyOut`. The server does what `PtyOut` deliberately does not: it APPENDS to the run's checkpoint as well as fanning out, because a terminal has no history worth keeping and a mission log is the record of what the agent did. `run_events_sse` emits the new bytes as `step` events, which the live pane already renders — no frontend change. The turn is `tee`d, not redirected: the file feeds the live stream and stdout still becomes `VmOutcome::summary`. A redirect would have produced a live view and an empty summary, which is the same green-and-empty shape as the bug this fixes. Tested, along with the log living outside the collected tree so it never lands in a user's delivered diff. 246 lib tests, 20 binaries; node and fcagent build clean.	2026-08-07 21:07:12 -07:00
Omar Sobh	3616bc4733	feat(missions): an operator button to merge a mission's branch into main ... `MergePolicy::Never` — the default for anything touching code — has always meant "do not merge on your own", deferring to a human. There was no way for that human to say yes: `auto_merge` was reachable only from the paper-harvest path, no workflow template declares `merge_policy`, and every mission ended at a branch. `POST /api/missions/{id}/merge` is that yes, with a button on the artifacts tab. The additive-only gate does NOT apply here, deliberately: an operator reading a code change is exactly the judgement the policy was holding out for. What is not waived: - the branch comes from the artifact delivery RECORDED, not rebuilt from the mission id, and must have `pushed: true`. A phase that never pushed shows no button instead of one that cannot work. - an empty branch is refused. A button reporting success for merging nothing is worse than no button. - a conflict refuses, aborts, and leaves the repo clean rather than forcing. It works in a FRESH CLONE under `_merge/<mission>`, never the mission checkout: that directory is reaped on a timer after a mission ends, so a merge using it would succeed right after a run and fail inexplicably an hour later. The clone is made by the server process, so nothing runs as root and ordinary cleanup works — unlike the copies in `root_copy`. `merge_and_push` is split out so the operator path and the automatic path run the SAME git commands; only the gates differ. A test asserts both call it, that the operator path does not re-apply the additive gate it exists to bypass, and that it still refuses an empty branch. Harness 43/43 across all five recipes before this change, with `_gate`, `_bench` and `_verify` all at zero. 246 lib tests, 20 binaries, 89 frontend tests, clean build.	2026-08-07 18:53:38 -07:00
Omar Sobh	0d8db7ff0b	fix: close the three remaining gaps, and repair a test I silently disabled ... FIRST, the self-inflicted one. My edit in a20702d inserted a test between an existing `#[test]` and the function it belonged to. The result compiled and looked fine: `every_anthropic_spelling_is_one_family` lost its attribute and STOPPED BEING A TEST, its doc comment ended up describing my test instead, and my test carried two `#[test]`s. It has not run since — in already-deployed code. Nothing failed, which is the point: a test that does not run is indistinguishable from one that passes. Found via a compiler warning I had not read. The commit message on a20702d said "241 lib tests pass". 240 ran. Then the three gaps. 1. A security scan could not read history. `ensure_checkout` clones with `--filter=blob:none` — full commits, blobs on demand — and the agent environment has NO network route to the forge. Measured: gitleaks on a 4-commit repo reported "1 commits scanned" and "could not fetch <sha> from promisor remote". A credential committed and later deleted is exactly what a scanner looks for and exactly what a lazy blob withholds. Missions with a `security_scan` phase now clone fully; everything else keeps the cheap path. (I first blamed `--depth 1`, from a stale module doc comment. The code has said `--filter=blob:none` since it was written, and the comment at `clone` explains why NOT shallow — a shallow clone cannot push a branch back. Both the comment and my claim are fixed.) 2. `benchmark_runner` never ran as part of a benchmark phase. It was reachable only from an operator button, so the `author_and_baseline` recipe authored benchmarks and measured nothing — `benchmark_snapshots` stayed empty. Now baselined from the sweep, SPAWNED not awaited: BENCH_TIMEOUT is 30 minutes and that loop also starts, closes, evaluates and captures every phase on the platform. A `NOT EXISTS` guard on iteration 0 makes per-tick firing safe. A repo with no bench harness logs and does NOT fail the phase — but it logs, because "no baseline" must not read like "not attempted". 3. The World's rich layer was empty for every mission. `run_events::append` is called only from the a2a path, and `world.rs` tailed only that table — while mission per-step detail has always lived in `topology_runs.checkpoint.records`, which `topology::run_events_sse` streams. The data was never missing; the viz read the one source missions never write. Now both are tailed, mapped through the existing `step_started` vocabulary so no new event types are needed. 242 lib tests, 20 test binaries, zero warnings.	2026-08-07 16:09:49 -07:00
Omar Sobh	87f188ae73	refactor: strip Gemini from the platform, and level up the architecture_mapper ... Two things. 1. The architecture_mapper proposal, applied AND made durable. The GLM proposal (019fddd9) was accepted in full: the agent's system_prompt now carries the Mermaid-first constraint and its brain was rewritten. Both verified against the live row and the .h5 file. But `apply_identity` writes `UPDATE agents SET system_prompt` and `apply_brain_consolidation` writes that agent's brain — neither touches the team TEMPLATE. That agent is mission-scoped, so the improvement would have died with the mission. The model's actual insight was sharp and worth keeping: "Mermaid diagrams beat prose" lived in the brain SEED and not in the system PROMPT, so it only applied when the agent happened to consult its brain. That constraint is now in templates/teams/codebase_research.toml, where every future Codebase Research team inherits it. (The proposal's second item mostly restated anti-patterns the seed already lists, so the seed is unchanged. Applying an LLM's suggestion is not the same as agreeing with all of it.) 2. Gemini is gone. Removed: the `gemini.default` provider alias and its `is_exact_provider_match` prefix, GEMINI_API_KEY forwarding to agent containers, the evaluator's gemini->gemini family row, the model selectors in claws/teams/planner and in TeamWizard + AgentComputer, and the commented provider block in the runtime config example (whose ZEROCLAW_AGENT_MAP example still mapped a worker_gemini that no longer existed). `provider_alias_for("gemini")` now returns claude_cli.default via the unrecognised-model branch, which LOGS. A stray gemini binding degrades visibly rather than resolving to a provider row we no longer ship. A test pins that, and another pins that GEMINI_API_KEY is forwarded in NEITHER auth mode, so adding it back to the list is a visible change rather than an accident. Avatar generation is DELETED, not disabled — it called Gemini's image model, and there is no alternative: Claude and Kimi are text-only, and z.ai answers "Unknown Model" for cogview-3-flash and cogview-4 on our plan (measured, not assumed). AvatarModal keeps UPLOAD, which never needed a provider; only the prompt-generation half is gone. 240 backend lib tests, 89 frontend tests, clean tsc + eslint, build succeeds.	2026-08-07 14:15:53 -07:00
Omar Sobh	f6c3ddbf81	refactor: no feature depends on Gemini any more ... Depleted Gemini prepayment credits took out PDF rendering. The same key was the only thing standing between level-up proposals and the same fate, so both are off it. - `pdf_renderer` is DELETED, not disabled. Nothing sets `render_pdf: true` since markdown became the deliverable (821cbb8), so the worker polled forever for rows that can no longer exist. It was also the only caller of the Gemini MD->HTML conversion. A worker that cannot do anything is worse than absent: it reads as a feature. - `level_up` now resolves its proposer through the provider REGISTRY (`Runtime::resolve_provider`), the same path the evaluator uses, defaulting to `glm:glm-4.7` — the validator this project measured and chose in scripts/judge-eval.sh. `CLAWMATES_LEVEL_UP_MODEL` takes a registry spec (`glm:glm-4.7`, `kimi:k2`, `claude-sonnet-5`), so every provider the platform can already reach works and no single vendor's billing can take it down. The non-obvious part of that swap: Gemini was asked for `response_mime_type: application/json` and obliged, so the old code parsed the raw reply. Anthropic-format models are under no such obligation and wrap objects in prose or a ```json fence. `extract_json_object` brace-counts to the matching close — string-aware, so a `}` inside a value does not end it, and nested (these proposals nest by design). Tested against bare, fenced, nested, brace-in-string and absent. Parsing raw text would have worked in review and failed on the first real proposal. What deliberately still MENTIONS Gemini: `mission_runtime` forwards GEMINI_API_KEY to agent containers alongside GROQ/OPENAI/ZAI/KIMI, and the claw model selector offers it. Those are user options, not platform requirements — the ask was to remove the NEED. Also corrected a comment in mission_delivery that cited `pdf_renderer` as the authority on artifact path resolution. It never was: it joined the mission id first and produced a doubled path that never resolved. 238 lib tests, 20 test binaries.	2026-08-07 13:01:57 -07:00
Omar Sobh	821cbb8622	feat(missions): hold every producing phase to delivering, and read markdown instead of PDFs ... Two changes the portal review asked for. 1. `benchmark` and `security_hardening` had no delivery guarantee. `empty_delivery_is_a_failure` tested `kind == "coding"`, on the reasoning that "research phases legitimately write nothing to the tree" — which the research directive three modules over contradicts, since it tells the agent to save findings under /mission/repo/research/. The cost: a `benchmark` mission is ONE benchmark phase, and with that phase exempt nothing in the platform could fail it. Same for `security_hardening`, whose first two phases are security_scan and research. Now keyed on PRODUCING_KINDS = coding, research, benchmark, security_scan. `review` stays exempt — a reviewing phase that changes nothing has done its job, the same distinction `vm_stop_gate::per_node` makes. The test that encoded the old rule is rewritten rather than deleted, with the reasoning that replaced it. All 8 harness fixtures are coding phases, so harness behaviour is unchanged. 2. PDFs are dropped; markdown is the deliverable. Rendering a PDF meant asking an LLM to convert markdown to HTML — a paid API call per document, on the critical path of "let me read my research", which failed on depleted Gemini credits and left every artifact unreadable. Styling at render time is free, offline, instant and cannot 429. - `mission_outputs` no longer requests a render. - New `GET /api/missions/{id}/artifacts/{artifact_id}/content`. The frontend had no way to READ an artifact at all: it listed paths and offered a PDF preview that never rendered (and whose `rendered_pdf_path` had no route serving it). Two containment rules, both enforced: the artifact must belong to a mission in the caller's workspace, and the CANONICALISED path must stay under `_outputs` — canonicalise first, because checking the string before resolving `..` is the classic hole. - `MarkdownBlock` now uses react-markdown + remark-gfm + rehype-slug. It was a deliberate zero-dep renderer for "the subset the refiner emits", and that subset stopped matching reality: agent briefs are largely GFM pipe tables, which it showed as literal pipes. MissionOutputReader and RefineDiffModal use the same component and gain tables for free. - Heading ids come from rehype-slug and `outlineOf` slugs with the same GithubSlugger, so the outline rail's anchors still resolve. A test pins that invariant, including duplicate headings. Styles live in globals.css under `.md-view`: the markup is generated so there are no class hooks, and this project has no styled-jsx registry — the app-router requirement is documented in next/dist/docs/01-app/02-guides/css-in-js.md, which frontend/AGENTS.md exists to make me read. The artifacts tab moved to `MissionArtifacts.tsx`. MissionCanvas was 1341 lines against a 1250 limit BEFORE this change — already failing lint; it is now 1248. 238 backend lib tests, 20 backend test binaries, 89 frontend tests, clean tsc, clean eslint on every file touched, production build succeeds.	2026-08-07 12:19:06 -07:00
Omar SobhandClaude Opus 5	d24823b6f3	fix(missions): a failed phase stranded its mission at running forever ... Found by counting containers during a cleanup, not by a test. gw-04 was holding a per-mission runtime container for a mission whose only topology run had failed three days earlier — phases `pending,failed`, mission still `running`. The interaction, which lived entirely between two queries' predicates: `start_pending_phases` launches a phase only when EVERY lower-order phase is `completed`, so once one fails the phases after it can never run. They stayed `pending`. `close_finished_missions` closes a mission only when NO phase is outside ('completed','failed','skipped') — so a `pending` phase that would never run kept the mission `running` indefinitely. And `mission_runtime`'s sweeper fires N minutes after a TERMINAL state, so the container was never reaped. One leaked container per failed multi-phase mission, accumulating silently, with nothing in any log saying so. Neither query is wrong alone; the bug is that nothing marked the phases the failure had made unreachable. `skip_unreachable_phases` says it: a `pending` phase with a `failed` phase at a LOWER order_idx becomes `skipped` — strictly earlier, because order is what makes a phase unreachable, and a failure later in the list says nothing about one still queued ahead of it. `skipped` is not a new concept: `close_finished_missions` already treats it as terminal, and it is the honest word for a phase that was never run, as distinct from one that failed. RETRY HAD TO MOVE WITH IT, or this trades one bug for another. `retry_phase` required the mission to be `running`, so closing failed missions would have made the one outcome you would actually want to retry the one you could not. It now accepts `failed` too, and in one transaction: resets the phase, REOPENS the phases its failure had skipped (without that, a retry runs the phase and stops, because everything after it is terminal-by-skip), and puts the mission back to `running` — every launcher and closer keys off that status. `completed` and `cancelled` stay refused; reopening those is a different decision. 557 tests pass, clippy clean. Three DB tests against real SQL, including that a phase queued BEFORE the failure is untouched and that a draft's phases are never swept. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-07 06:58:26 -07:00
Omar SobhandClaude Opus 5	08dd227a45	feat(missions): give the planner the repository's contents, not just its names ... The root listing was not enough. Given names alone the planner wrote "optimise the hot path" for a crate whose hot path is `add(a: i64, b: i64) -> i64` — a mission that was unachievable from the moment it was written, and that nothing discovered until an agent had built a benchmark harness in a VM to measure an integer addition, honestly reported no improvement was possible, and the judge correctly failed the phase. `repo_digest` fetches the whole tree (so "does this have benches/" is a fact, not an inference) and then file CONTENTS in priority order: manifests first — they say what the project is — then the README, then source ascending by size, since a planner learns more from twenty small files than from one large one. Lockfiles and build output are dropped: enormous, and they say nothing a manifest does not. THE RULE THIS ENFORCES, and the reason the rendering is its own tested module: a digest of any repository worth planning against is partial, and a model shown a partial view without being told it is partial plans as though it saw everything. So every omission is stated — how many files exist, how many were shown, what was cut from each, and "anything not shown you have NOT seen". Same distinction as `Option<u32>` for the subagent probe: "we did not look" and "there is nothing there" are different facts. Failures degrade to a stated absence rather than an empty string, and the three cases stay distinguishable: no repository, a tree that could not be read, and a tree read but no contents fetched. An unreadable tree is never rendered as an empty repository. Two more things the prompt now says, both learned from that run: plan for the repository as it IS rather than as the description implies (and if the description asks for something the code cannot support, say so in the task and plan the phase that establishes the truth, rather than a phase that must fail); and a mission agent has NO package-registry access. The agent discovered the second one mid-run and wrote a dependency-free `std::time::Instant` harness after Criterion could not be added — good adaptation, but nothing had warned it. 549 tests pass, clippy clean. The budget/priority/truncation logic is pure and tested; only the fetching touches the network. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-07 05:01:02 -07:00
Omar SobhandClaude Opus 5	0aeae07db2	fix(missions): the planner was planning blind — show it the repository ... The first real plan opened with "Identify the crate's hottest code path and run its benchmark harness". This crate has no benchmark harness. The phase ran, found nothing to baseline, delivered zero files, and the plan's second phase was left with nothing to optimise against. The planner saw the mission title, the description, and a boolean for whether a repository was bound. It never saw the repository. A plan about a codebase written without looking at the codebase is a guess that reads like a plan — and the failure surfaces two phases and one VM boot later, as an agent reporting that the thing it was told to run does not exist. The prompt now carries the repository's root listing, read from the FORGE rather than a checkout: at proposal time the mission is still a draft and `ensure_checkout` has not run, so there is nothing on disk to list. It also says outright that a phase needing something absent must CREATE it and say so in its task — the failure was not only ignorance of the tree but the assumption that missing tooling is someone else's problem. A listing that cannot be fetched degrades to "(the repository listing could not be read)" in the prompt rather than to an empty string. A model told the listing is unavailable can hedge; a model told nothing assumes — which is the same distinction as `Option<u32>` for the subagent probe, in a prompt instead of a struct. Found by running the thing end to end rather than by testing it: every unit test here passes with a planner that has never seen a repository. 543 tests pass, clippy clean. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-06 23:23:34 -07:00
Omar SobhandClaude Opus 5	a33dbdcdc3	feat(missions): W1/#13 — let a model author the mission's phases ... The last unstarted item from the missions-as-workflows plan, and the other half of Slice 5: that one lets a model size the TEAM, this lets it decide what the work IS. Every mission's phases come from one of five hand-written recipes in `templates/workflows/*.toml`, chosen by `template_kind` before anyone saw the mission. That is the "do it this way: 1, 2, 3" over-specification that makes a capable model follow a worse plan than it would have chosen. The recipes stay — they are still the default for a mission nobody proposes a plan for, and the fallback when a proposal is refused. Same three verbs and the same review gate as the roster, deliberately: propose and decide are separate because only the second changes a mission, and a second shape would be a second thing to get right. Approving REPLACES the phases (a plan is an answer to "what is this mission", not an addition to one), draft-only. GROUNDED IN WHAT THE PLATFORM ACTUALLY READS, which is the part that makes this more than a copy. `phase_config::KNOWN_KEYS` already names every phase-config key and the code that reads it — the registry built after `task` sat unread through every mission. A plan is validated against it, so a model cannot propose a phase whose settings nothing will act on: the failure that registry exists to EXPOSE is one this path cannot create. Phase kinds are checked the same way, because an unknown kind does not error — it falls through to the catch-all purpose and runs as a generic phase that looks like it worked. TWO THINGS THE WORK ITSELF FOUND, both the same shape: - `done_when_check` — the stop-gate key added earlier today — was never registered in `phase_config`, so every mission that set it has been logging it as an unknown key. Found by a test written for a different purpose, which is the registry doing exactly its job. Now registered with its reader. - `done_when` and `max_iterations` are COLUMNS promoted out of config by `missions::create`; the evaluator sweep filters on the column in SQL every tick. My first insert wrote the config blob alone, which would have stored a plan's completion condition where nothing judges it. NEGATIVE CONTROL run: binding NULL instead of the promoted value fails `an_approved_plan_replaces_the_missions_phases`. `order_idx` comes from the array's own order rather than a field the model sets: two sources for one fact is how a plan ends up with two phase 0s, and order_idx is what `start_pending_phases` sequences on. MAX_PHASES is 4 and the prompt argues for one. Each phase is a full agent run in sequence, and splitting one change into plan → implement → test is the documented anti-pattern — a single agent doing all three keeps the context that makes the later steps good. 543 tests pass, clippy clean. Migration 0072. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-06 20:05:28 -07:00