3 Commits

Include renames

Author	SHA1	Message	Date
Omar SobhandClaude Opus 4.8	3eca4ed70c	Recursive deploy ladder: Company + Org tiers, mesh mark, two-tier rail ... Completes the scale ladder (single → team → company → org). Every tier is a topology whose nodes are the tier below; running a parent recursively runs each child's sub-topology down to the leaf claws. Backend: - migration 0011: companies/company_teams, orgs/org_companies, topology_runs.tier - cm-db repos for companies + orgs (mirror teams) - TurnRequest.attrs (forwarded from node.attrs) for child-id binding - SubTopologyExecutor (recursive_exec.rs): a parent "turn" runs the child's sub-topology; durability via parent updated_at keepalive + cancel propagation + depth cap; boxed future breaks the org→company recursion - topology_worker selects executor by job.tier - routes: /api/companies, /api/orgs (create/list/get/run) + unified /api/structure/{level}/{id} for the zoom canvas Frontend: - MeshMark: node-mesh brand glyph (replaces the claw PNG), tier variants - TopologyGraphView: optional onNodeClick/nodeMeta + dark-token theming - StructureCanvas + Breadcrumb: one recursive zoom view for every tier (drill down on node click, breadcrumb up); TeamRunPanel extracted + shared - two-tier Discord-style rail: StructureRail (mesh mark + org/company/team glyphs + tools popover + deploy + user) | RosterColumn (selected group's children, or your claws); SecondaryNav for cross-cutting tools - ComposeWizard (company/org) wired into DeployWizard; /companies + /orgs pages Co-Authored-By: Claude Opus 4.8 <[email protected]>	2026-06-18 14:25:06 -07:00
Omar SobhandClaude Opus 4.8	e93a3cfb53	feat(topology): executors for all 12 kinds (mesh + debate; mappings) ... Every TopologyKind now runs, mapped to five execution patterns: - hierarchical ← hub_spoke, star_moe, market - pipeline ← ring - swarm ← flat, holacratic - mesh (new) ← blackboard (two peer-exchange rounds + aggregate) - debate (new) (propose → critique → revise → judge) execute()'s match is now exhaustive (adding a kind upstream forces an executor), so the Unsupported error is gone. Benchmark spans all five distinct patterns. 14 tests with --features provider; clippy clean. Doc updated. Co-Authored-By: Claude Opus 4.8 <[email protected]>	2026-06-15 20:54:12 -07:00
Omar SobhandClaude Opus 4.8	e93fb24b79	feat(topology): cm-orchestrator topology runtime engine (Phase 2) ... A pure async control-flow engine that executes a task across a TopologyGraph by sequencing safe agent turns. Safety by construction: the engine can only invoke turns via a generic TurnExecutor — it performs no side effects itself, so §15 gating (inside each turn) is inherited and switching topology cannot escalate authority. - TurnExecutor trait + TurnRequest/TurnOutcome (real impl will wrap cm-runtime::Runtime; tests use a scripted Echo executor). - Pure planners (plan.rs): hierarchical (delegate down / synthesize up), pipeline (topo-ordered threading), swarm (parallel attempts + aggregate). - RunRecord journal (per-step + RunMetrics: tokens, gated actions, approvals granted/blocked, turns) — feeds the Phase 4 comparison harness/paper. - Unsupported kinds return an error (no panic). 5 tests, clippy clean. Next (Phase 2b): a real TurnExecutor adapter over cm-runtime::send_message. Co-Authored-By: Claude Opus 4.8 <[email protected]>	2026-06-15 20:14:12 -07:00