4 Commits

Include renames

Author	SHA1	Message	Date
Omar SobhandClaude Opus 5	4a3f1cc2f9	docs(recipes): annotate the keys that do nothing ... phase_config::DECLARED_BUT_UNREAD lists four keys the recipes set and nothing reads. security_hardening.toml already carried a "what is real here and what is decoration" section and annotated its own dead keys inline; the other five did not, so `produces = ["md"]` and `loop = "until_no_more_int_items"` read like settings. The risk was never the dead keys themselves — it is a reader taking `loop = "until_no_more_int_items"` for a loop. Each now says it is inert and points at the registry. They stay because they state the intent. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01WZb5A2kfVfjpdwSochkuHz	2026-09-22 15:00:24 -05:00
Omar SobhandClaude Opus 5	49bcf53b84	feat(missions): wire the workflow registry so phase config reaches the database ... workflow_registry.rs had zero call sites -- lib.rs declared the module and nothing ever called load() or get(). So templates/workflows/*.toml was never read, and because the client's TEMPLATE_PRESETS carries only {kind, order_idx} with no config, PhaseSpec.config defaulted to Value::Null and every wizard-created mission stored a null mission_phases.config. Every per-phase setting was therefore inert. `loop = "until_no_more_int_items"` and `commit_policy = "on_green_tests"` described a scheduler that does not exist AND had no path to the database. benchmark_runner and security_scan already read phase_config(); they were reading from null. - Mission create derives phases from the recipe when none are sent, and backfills config per phase (matched on kind+order_idx, then kind) when the caller sends shape without config. An explicit config always wins. - phases_for_create takes Option<&WorkflowRecipe> rather than reaching for the global, because the registry resolves its directory relative to the process cwd -- which under cargo test is the crate root, not the repo root. - GET /api/workflows serves the catalog; the wizard fetches it and falls back to TEMPLATE_PRESETS. Adding a TOML now adds a template with no FE change. - load() runs at boot so a malformed recipe appears in the boot log instead of silently producing a mission with no phase config. Also fixes a latent bug in all five recipes: `default_team_template` was written below the first [[phases]] block, and TOML scopes a bare key after a table header INTO that table -- so it parsed as phases[last].config.default_team_template and the real field was always None. Invisible while the registry was dead code. Moved above the phases, with a test asserting it neither returns None nor leaks into a phase config. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>	2026-07-30 12:43:32 -07:00
Omar SobhandClaude Opus 5	285d0c82f2	chore: delete dead scaffolding and stop fabricating claw capability cards ... Tier 0 of the prompt-ablation pass -- subtraction only, none of this reached a model. - cm-brain: drop ClawBrain::export_markdown (zero callers). - workflows: drop the `task_preamble` keys. No Rust code ever read them -- WorkflowPhase.config is an opaque serde_json::Value -- so the comment calling the preamble "the belt, the skill the suspenders" described a belt that was never implemented. (`commit_policy` is unread for the same reason; left in place as documentation pending a decision.) - mcp_door: derive the unknown-tool error from EXPOSED_TOOLS. The literal had drifted to naming one of the three tools the door exposes. - Dashboard.tsx: drop TEAM_TEMPLATES/COMPANY_TEMPLATES, defined and never referenced, and disconnected from the real templates/teams/*.toml. The substantive one: GET /api/claws/{id}/compartments returned hardcoded strings for tools/capabilities/safety, identical for every claw. Every card read "Network: none" and "Shell . blocked" regardless of the claw's real risk_profile -- which is the actual capability boundary, so the card was most wrong exactly where it mattered, on a coding_readwrite claw that does have shell. Now derived from the claw's effective risk_profile (its team's setting, else the same role-derived default the provisioner applies), with the allowlists mirroring [risk_profiles.*] in the runtime config. Note: cm-topology/src/heuristics.rs was slated for deletion here as unused. It is not -- routes/topology.rs:43 serves it and p0_endpoints.rs:302 asserts it. Left alone. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>	2026-07-30 10:44:33 -07:00
Omar SobhandClaude Opus 4.7	565f6cae65	slice 4: 5 workflow templates as TOML recipes + mission-launch orchestrator ... Two things land together: 1. Ships the 5 workflow recipes as TOML files under templates/workflows/*.toml: - research_only (hub_spoke research → MD + PDF) - research_and_code (research → coding loop until INT-XX drained) - security_hardening (scan → research patches → coding with reviewer approval + full MCP bundle) - refactor (single-pass coding with dep audit preamble + before/after benchmarks) - benchmark (author + baseline benchmarks per stack) Each declares phases[], per-phase config, default_team_template. Loaded read-only into an in-memory registry (workflow_registry) via OnceLock — no DB row per recipe. 2. Ships the mission-launch orchestrator that closes the loop from Slice 3.5d's mechanics. When a mission transitions draft→running, `mission_orchestrator::on_launch`: - Reads mission.team_template_id (skips if unset) - Loads the team template detail (roles + skills bindings) - Builds a topology graph from role slots via cm_topology::build - Inserts the teams row + stamps template_id/version/risk_profile/mcp_bundles - For each role: agent insert, model binding, runtime provision (opt-in via RuntimeProvisioner::from_env), brain_seed::ingest (Slice 3.5d), agent_template_link::upsert (Slice 3.5d), team_members bind, audit trail - UPDATE missions SET team_id = ... Wired into routes::missions::set_status when prior.status='draft' and new='running'. Failures log + are non-fatal (mission still flips to running so the user can inspect + retry). With this, Slice 3.5d's brain-seed + link machinery actually gets populated, and the MCP skills server's template-defaults-merge path (Slice 3.5b/d) starts serving real bindings to real agents. Follow-ups (Slice 5-8): - Task-card parser watches run events for TASK/COMPLETED markers → mission_tasks rows - PDF renderer worker turns MD artifacts into PDFs - Before/after benchmark runner honors phases[].config.benchmark - Security scan MCP bundle exposes cargo-audit/gitleaks/trivy/semgrep - Level-up endpoints diff learned-vs-seeded via agent_template_link Co-Authored-By: Claude Opus 4.7 <[email protected]>	2026-07-19 14:34:26 -07:00