@cleocode/skills 2026.10.21 → 2026.10.22

package/skills/ct-lead/references/aggregation-protocol.md

@@ -1,57 +1,51 @@
-# Aggregation Protocol — Conduit + Manifest Drain Semantics
+# Aggregation Protocol — AgentMBX + Manifest Drain Semantics
 
 The Phase Lead converges on wave completion via TWO complementary channels:
 
-1. **Conduit topic** (`epic-<TID>.wave-<n>`) — low-latency event stream
-   carrying terminal-status signals (`complete` / `partial` / `blocked` /
-   `failed` / `timeout`) from each worker as it returns.
+1. **AgentMBX** (the Lead's mailbox) — one completion message per worker
+   carrying its terminal status (`complete` / `partial` / `blocked` /
+   `failed` / `timeout`) and task id. Agent messages travel over AgentMBX,
+   not CONDUIT (D11172).
 2. **pipeline_manifest** (SQLite, ADR-027) — durable source of truth for
    each worker's structured output (key_findings, files, gates).
 
-Conduit drives **timing**; manifest drives **content**. `rollupWaveStatus`
-(T9082) reads BOTH and produces the authoritative wave verdict.
+Messages drive **timing**; the manifest drives **content**. `rollupWaveStatus`
+(T9082) reads the manifest and produces the authoritative wave verdict.
 
 ---
 
-## 1. Subscription timing
+## 1. Mailbox before spawn
 
-The Lead MUST subscribe to the conduit topic BEFORE issuing `delegate_task`.
-Subscription is idempotent and cheap; late subscription races against
-fast-finishing workers and silently loses early `complete` signals.
+Before issuing `delegate_task`, build each worker's prompt with `cleo
+orchestrate spawn <taskId> --lead-mbx <you>` so its completion message reaches
+you (`fanout` cannot carry the name yet, T13966: put it in the task notes). A mailbox keeps messages until
+they are read, so a worker that finishes first is never lost; a worker that
+does not know your name cannot report at all.
 
 ```bash
-# CORRECT — subscribe, then spawn
-cleo conduit subscribe --topic "epic-T9080.wave-2"
-cleo orchestrate fanout T9080 --tasks T9301,T9302,T9303
-
-# WRONG — fanout, then subscribe (race window)
-cleo orchestrate fanout T9080 --tasks T9301,T9302,T9303
-cleo conduit subscribe --topic "epic-T9080.wave-2"   # may miss T9301 done
+# CORRECT — each worker prompt names the Lead mailbox
+cleo orchestrate spawn T9301 --lead-mbx lead-t9080-w2
 ```
 
-The conduit retains buffered signals for `conduit.replay_window` (default 30s)
-to defend against tiny races, but relying on the buffer is brittle.
-
 ---
 
 ## 2. Drain loop
 
-There is no blocking await. The Lead polls the wave topic with
-`cleo conduit listen --topic <topic> --since <last-seen>` until the expected number of
-terminal signals has arrived OR its wall-clock budget elapses.
+There is no blocking await. Between waits the Lead reads its inbox
+(`mbx_inbox` / `mbx_read`, or `agentmbx inbox --as <you>` inside the provider session that holds the
+MCP lease) until every
+worker's completion message has arrived OR its wall-clock budget elapses,
+and acks each message it acted on.
 
 ```bash
-cleo conduit listen --topic "epic-T9080.wave-2" --since "${SPAWNED_AT}" \
-  > /tmp/conduit-drain.json
-
-# Then read authoritative state from manifest — same wave number as the topic.
+# Then read authoritative state from the manifest, by the wave number
+# `cleo orchestrate waves` prints.
 cleo orchestrate roll-up T9080 --wave 2 --json > /tmp/rollup.json
 ```
 
 > **Wave contract (T12682).** One wave number `n` names everything: it is
-> the 1-based number `cleo orchestrate waves <epic>` prints, spawned workers
-> publish on `epic-<epicId>.wave-<n>`, and `cleo orchestrate roll-up <epic>
-> --wave <n>` takes the same `n` (`--wave 0` is refused with
+> the 1-based number `cleo orchestrate waves <epic>` prints, and `cleo
+> orchestrate roll-up <epic> --wave <n>` takes the same `n` (`--wave 0` is refused with
 > `E_CLEO_VALIDATION`, pointing at `cleo orchestrate waves`).
 >
 > **What a wave number guarantees (T12683).** A task's wave is its
@@ -64,8 +58,8 @@ cleo orchestrate roll-up T9080 --wave 2 --json > /tmp/rollup.json
 >   finished waves without renumbering the rest.
 > - **Not stable** when a dependency edge is added or removed anywhere
 >   upstream, including in another epic: downstream waves shift. If you
->   subscribed ahead to `epic-<epicId>.wave-<n>`, re-read `cleo orchestrate
->   waves` after any dependency change.
+>   noted a wave number ahead of time, re-read `cleo orchestrate waves`
+>   after any dependency change.
 > - **Numbers can skip, and an epic's first wave can be above 1** (a task
 >   whose external prerequisite sits at depth 3 is in wave 4). Always take
 >   `n` from `cleo orchestrate waves`; never assume the first wave is 1.
@@ -118,13 +112,11 @@ Local retry shape:
 # After first drain, identify retriable failures
 RETRIABLE=$(jq -r '.workers[] | select(.status=="failed" and (.reason|test("testsPassed|qaPassed|INFRASTRUCTURE"))) | .taskId' /tmp/rollup.json)
 
-# Re-spawn ONLY those (NEW conduit topic suffix to avoid replay collision)
-cleo conduit subscribe --topic "epic-T9080.wave-2.retry-1"
+# Re-spawn ONLY those; their briefs name the Lead mailbox and say "retry 1"
 cleo orchestrate fanout T9080 --tasks "$(echo $RETRIABLE | tr ' ' ,)"
 
-# Re-drain on the retry topic, then roll up again (the manifest holds the
-# latest status of every worker, retries included)
-cleo conduit listen --topic "epic-T9080.wave-2.retry-1" --since "${RETRY_AT}"
+# Read the retry completion messages, then roll up again (the manifest holds
+# the latest status of every worker, retries included)
 cleo orchestrate roll-up T9080 --wave 2 --json > /tmp/rollup-final.json
 ```
 
@@ -138,16 +130,16 @@ verdict — no second retry pass.
 Every leaf worker is bounded by a 600s wall-clock timeout (configurable via
 `subagentTimeoutSeconds`). The Lead's drain timeout MUST be at least equal
 to the worker timeout — typically equal, since workers report terminally
-on timeout via the conduit.
+on timeout over AgentMBX.
 
 Behaviour matrix:
 
-| Worker outcome at 600s | Conduit signal | Manifest entry | Lead action |
+| Worker outcome at 600s | AgentMBX message | Manifest entry | Lead action |
 |------------------------|----------------|----------------|-------------|
 | Worker returned a contract string in time | `complete`/`partial`/`blocked` | Present, full | Aggregate normally |
 | Worker exited cleanly past 600s (race) | None | Present | `rollupWaveStatus` reconciles via manifest |
 | Worker hung; runtime killed it | `timeout` | Stub entry with `status:timeout` | Treat as `failed` non-retriable; return `partial` |
-| Network partition between worker and conduit | None | None | Drain times out; `rollup` flags `missing` workers; return `partial` |
+| Worker could not reach AgentMBX | None | None | Drain times out; `rollup` flags `missing` workers; return `partial` |
 
 The Lead's own wall-clock budget should be `subagentTimeoutSeconds + 60s`
 of slack to allow the rollup query and manifest append to complete.
@@ -167,7 +159,7 @@ rollupWaveStatus() →
 Escalate to parent Orchestrator (return `partial` or `blocked`) when:
 - ANY worker requires HITL input (architectural decision, scope expansion)
 - Same worker fails after the single local retry
-- Conduit drain times out with `missing` workers
+- The inbox drain times out with `missing` workers
 - A worker reports `E_DEP_UNSATISFIED` (wave was mis-planned)
 - Cumulative wave wall-clock exceeds `subagentTimeoutSeconds + 60s`
 

package/skills/ct-lead/references/spawn-pattern.md

@@ -2,26 +2,26 @@
 
 The Phase Lead fans out all workers in a single `delegate_task` batch.
 Width is bounded by `maxConcurrent` (default 10; a convention the Lead enforces — no runtime check exists).
-Each child carries `role=leaf` and inherits the wave's conduit topic.
+Each child carries `role=leaf`, and its brief names the Lead's AgentMBX
+mailbox so its completion message reaches the Lead.
 
 All examples assume:
 - Lead's own task ID: `T9080-lead-w2`
 - Epic: `T9080`
 - Wave: `wave-2`
-- Conduit topic: `epic-T9080.wave-2`
+- Lead mailbox (AgentMBX): `lead-t9080-w2`
 
 ---
 
 ## Example 1 — 3-worker fanout (small wave)
 
-Typical for narrowly-scoped IVTR waves where deps fan in tightly.
+Typical for narrowly-scoped waves where deps fan in tightly.
 
 ```json
 {
   "tool": "delegate_task",
   "args": {
     "parent": { "taskId": "T9080-lead-w2", "role": "orchestrator" },
-    "conduitTopic": "epic-T9080.wave-2",
     "timeoutSeconds": 600,
     "tasks": [
       { "taskId": "T9101", "role": "leaf", "subagent_type": "cleo-subagent", "model": "sonnet" },
@@ -34,11 +34,9 @@ Typical for narrowly-scoped IVTR waves where deps fan in tightly.
 
 CLI equivalent (one shell call, NOT a loop). `fanout` takes the epic and the
 task list only; role, model and timeout come from each task's spawn prompt
-(`cleo orchestrate spawn <taskId>`), and the Lead subscribes to the wave topic
-before it runs:
+(`cleo orchestrate spawn <taskId>`):
 
 ```bash
-cleo conduit subscribe --topic epic-T9080.wave-2
 cleo orchestrate fanout T9080 --tasks T9101,T9102,T9103
 ```
 
@@ -51,7 +49,6 @@ cleo orchestrate fanout T9080 --tasks T9101,T9102,T9103
   "tool": "delegate_task",
   "args": {
     "parent": { "taskId": "T9080-lead-w2", "role": "orchestrator" },
-    "conduitTopic": "epic-T9080.wave-2",
     "timeoutSeconds": 600,
     "tasks": [
       { "taskId": "T9201", "role": "leaf", "subagent_type": "cleo-subagent", "model": "sonnet" },
@@ -76,7 +73,6 @@ For wider waves, the parent Orchestrator MUST split into multiple Leads.
   "tool": "delegate_task",
   "args": {
     "parent": { "taskId": "T9080-lead-w2", "role": "orchestrator" },
-    "conduitTopic": "epic-T9080.wave-2",
     "timeoutSeconds": 600,
     "tasks": [
       { "taskId": "T9301", "role": "leaf", "subagent_type": "cleo-subagent", "model": "sonnet" },
@@ -128,6 +124,6 @@ DO NOT spawn workers with `role=orchestrator`:
 | Worker count | When to use | Notes |
 |--------------|-------------|-------|
 | 1–3 | Narrow waves; single-package changes | Minimal overhead, fast convergence |
-| 4–6 | Typical IVTR implementation waves | Sweet spot for sonnet workers |
-| 7–10 | Max-width parallel waves | Watch conduit signal volume; close to convergence-limit |
+| 4–6 | Typical implementation waves | Sweet spot for sonnet workers |
+| 7–10 | Max-width parallel waves | Watch inbox volume; close to convergence-limit |
 | >10  | Split across multiple Leads | Top Orchestrator spawns N Leads, each ≤10 workers |

package/skills/ct-lean/SKILL.md

@@ -10,7 +10,7 @@ description: >-
   gates, package boundaries, validation, data safety or anything the task asked for.
 license: MIT
 metadata:
-  version: 1.4.0
+  version: 1.6.0
   tier: core
   install: harness
   covers:
@@ -18,6 +18,7 @@ metadata:
     - packages/cleo/src/cli/commands/lean.ts
     - packages/core/src/orchestration/lean-debt.ts
     - packages/core/src/orchestration/lean-gain.ts
+    - packages/core/src/nexus/brief-map.ts
   lastReviewed: 2026-10-13
   stability: stable
   attribution: Adapted from Ponytail 5.1.0 by DietrichGebert (MIT) — https://github.com/DietrichGebert/ponytail
@@ -44,6 +45,9 @@ config key, then `full`. When the owner asks for a level ("go ultra", "lean off"
 `--global` for every project. `cleo lean level` alone shows the level and its source.
 `cleo lean gain --card` shows the measured benchmark scoreboard: averages, never a number
 for this repo.
+Subagents get the same level: CLEO-spawned ones through the spawn prompt, Claude Code
+Agent-tool ones through the SubagentStart hook (`cleo hook subagent-start`, installed with the
+heavy-command hook; scope it with `CLEO_LEAN_SUBAGENT_MATCHER`, a regex over the agent type).
 
 ## Before you write
 
@@ -58,7 +62,8 @@ callers that stop working, stores it would migrate. That is scope. Extra feature
 1. **Does it need to exist?** Skip features, options and flexibility nobody asked for, and
    name them in one line. A vague request gets the smallest version that does the core job.
 2. **Already in this codebase?** A helper, accessor, contract or pattern: use it the way the
-   surrounding code does. Search `packages/core/src` and `packages/contracts/src` first.
+   surrounding code does. Search `packages/core/src` and `packages/contracts/src` first;
+   `cleo map --brief` lists what exists per folder (set `lean.map` to get it in `cleo briefing`).
 3. **Standard library or platform feature?** Use it, unless the repo has its own (a house
    chokepoint such as `openDualScopeDb` or `cleo run` beats a raw primitive).
 4. **An installed dependency?** Use it. Never add a dependency for a few lines.

package/skills/ct-orchestrator/SKILL.md

@@ -2,13 +2,13 @@
 name: ct-orchestrator
 description: "Pipeline-aware orchestration skill for managing complex workflows through subagent delegation. Use when the user asks to \"orchestrate\", \"orchestrator mode\", \"run as orchestrator\", \"delegate to subagents\", \"coordinate agents\", \"spawn subagents\", \"multi-agent workflow\", \"context-protected workflow\", \"agent farm\", \"HITL orchestration\", \"pipeline management\", or needs to manage complex workflows by delegating work to subagents while protecting the main context window. Enforces ORC-001 through ORC-009 constraints. Provider-neutral — works with any AI agent runtime."
 metadata:
-  version: 4.0.15
+  version: 4.1.2
   tier: core
   install: harness
   covers:
     - packages/cleo/src/cli/commands/orchestrate.ts
     - packages/core/src/orchestration/spawn-prompt.ts
-  lastReviewed: 2026-10-13
+  lastReviewed: 2026-10-23
   stability: stable
 ---
 
@@ -51,7 +51,7 @@ You are the **Orchestrator** — a conductor, never a musician. You coordinate c
 | ORC-005 | Context budget: 10K tokens | Use `cleo orchestrate context` to monitor; delegate at 80% |
 | ORC-006 | Max 3 files per subagent | Cross-file reasoning degrades beyond this scope |
 | ORC-007 | All work traced to epic | No orphaned tasks — every task has a parent epic |
-| ORC-008 | Zero architectural decisions | Architecture MUST be pre-decided via RCASD consensus or HITL |
+| ORC-008 | Zero architectural decisions | Architecture MUST be pre-decided in the plan document or by an owner decision (HITL) |
 | ORC-009 | Manifest-mediated handoffs | Read only `key_findings` from pipeline_manifest; subagents read full files |
 | ORC-010 | Continuous dispatch | While ready tasks exist, orchestrator MUST be spawning — never idle while work remains |
 | ORC-011 | Pre-release verification gate | NEVER `git push --tags` without full pipeline green: biome ci packages/, build, test, changelog, version |
@@ -70,7 +70,7 @@ discriminates; prefixes (`SG-`, `E-`, `T-`) are display + import-mapping only.
 | Subtask | (none) | One commit; ≤2 files; rolls up to Task's PR     | Worker (leaf)        |
 
 **I8 (load-bearing for decomposition):** A Task ships as exactly ONE PR. Subtasks contribute
-commits to that single PR — they NEVER own a PR. When decomposing under RCASD, if a unit needs
+commits to that single PR — they NEVER own a PR. When decomposing, if a unit needs
 its own PR it MUST be a Task, not a Subtask.
 
 **Tier-promotion triggers (see ADR-073 §1.3 for full decision table):**
@@ -81,46 +81,51 @@ its own PR it MUST be a Task, not a Subtask.
 Full charter (8 invariants I1–I8 + prefix registry) lives in
 `.cleo/adrs/ADR-073-above-epic-naming.md` §1–§2.
 
-## LOOM — The Core Lifecycle
+## The Work Loop
 
-**LOOM** (Logical Order of Operations Methodology) is the systematic lifecycle for ALL work. Every incoming issue, feature, bug, or idea flows through LOOM's two phases:
+Every issue, feature or bug runs the same loop: plan, execute, verify. RCASD stage
+records and the IVTR loop are retired from agent instructions (epic T13932).
+`pipeline_stage` is a label on tasks; it gates work only where a project turns on
+the stage gate (see Plan).
 
-### RCASD Phase (Planning)
+### Plan
 
-Runs **autonomously on every incoming issue**. Decomposes ideas into executable CLEO task scaffolding.
+- **One plan document per epic** in the CleoDocs store (`--type plan`), with sections
+  for findings, the decision, the spec (acceptance criteria) and the decomposition.
+- **Decisions** go to the BRAIN decision store
+  (`cleo memory decision-store --decision "..." --rationale "..." --linked-task <epicId>`);
+  owner decisions go through the ask tool first.
+- **Tasks**: atomic children under the epic, each with `--acceptance` and `--depends`.
+  Spawn protocols (research, consensus, specification, decomposition, ...) only pick
+  the spawn prompt's stage guidance; they are labels, not gates.
+- **Stage gate** (`lifecycle.stageGate`, off by default, T13970): when a project sets it
+  to `strict`, a child cannot complete (exit 80) while its parent epic sits in a planning
+  stage (research to decomposition), and the epic cannot advance once children sit at its
+  stage; `advisory` only warns. An epic inherits its saga's stage, or starts at research
+  when it has no parent. With the gate on, run `cleo update <epicId> --pipeline-stage
+  implementation` once the plan is written and BEFORE adding children; if children
+  already sit at its stage, report the epic to the lead or owner. The setting is their
+  choice: never change `lifecycle.stageGate` yourself. Evidence strictness stays on
+  `lifecycle.mode` either way.
 
-| Stage | Purpose | Subagent Role |
-|-------|---------|---------------|
-| **Research** | Investigate codebase, gather context, explore options | Explorer (lightweight) |
-| **Consensus** | Validate approach, identify risks, get HITL alignment | Lead (reasoning) |
-| **Architecture** | Choose patterns, integration points, store decisions in BRAIN decision-store | Lead (reasoning) |
-| **Specification** | Write formal spec with RFC 2119 language, acceptance criteria | Lead (reasoning) |
-| **Decomposition** | Break into atomic tasks with deps under epic(s) | Lead (reasoning) |
+### Execute
 
-**RCASD output**: Epic(s) with child tasks, spec documents attached, dependency graph defined, acceptance criteria on every task. Architecture decisions stored in BRAIN decision-store via `cleo memory decision-store --decision "..." --rationale "..."`, not in adrs markdown blobs.
+- Waves from `cleo orchestrate waves <epicId>`, admission from `cleo orchestrate ready
+  <epicId>`, prompts from `cleo orchestrate spawn <taskId> --lead-mbx <you>`.
+- Agents coordinate over AgentMBX; task state and evidence stay in CLEO.
+- Autonomous runs go through CLEO Goal (ADR-097), not a CLEO-driven loop.
 
-### IVTR Phase (Execution)
+### Verify
 
-Runs the build-verify loop until ALL acceptance criteria pass. No partial completions.
+- Evidence gates (ADR-051): `cleo done <id> --plan`, then `cleo verify` per gate, then
+  `cleo complete`. A worker that fails its criteria is re-spawned with the feedback.
+- An independent review of each PR head before merge; the implementer never reviews
+  its own work.
 
-| Stage | Purpose | Subagent Role |
-|-------|---------|---------------|
-| **Implement** | Write code per task spec and acceptance criteria | Worker (focused) |
-| **Validate** | Check implementation against spec, ADRs, and contracts | Lead (reasoning) |
-| **Test** | Run tests, verify acceptance criteria pass | Worker (focused) |
-| **Release** | Version, deploy, verify, mark complete | Lead (reasoning) |
+### Contribution (cross-cutting)
 
-IVTR **loops** per task: if Validate or Test fails, re-Implement with feedback. Loop until ALL acceptance criteria pass.
-
-### Contribution Protocol (Cross-cutting)
-
-Runs alongside BOTH phases. Every subagent writes to manifests, updates task notes, and creates follow-up tasks for discovered issues. Nothing falls through the cracks.
-
-### Pipeline Gate Enforcement
-
-Before spawning ANY task, gates verify RCASD stages completed in order. Default mode is **strict** (blocks spawn if prerequisites missing). Advisory and off modes available for prototyping/emergencies.
-
-> Full decision tree, enforcement modes, and emergency bypass: `references/lifecycle-gates.md`
+Every subagent writes to the manifest, updates task notes and files follow-up tasks for
+what it discovers. Nothing falls through the cracks.
 
 ## Model Assignment (Preferred, Not Required)
 
@@ -203,51 +208,55 @@ blocker: none when complete; required when partial/blocked. `manifest:none` only
 cleo session status              # Resume existing?
 cleo dash                        # Project overview
 cleo current                     # Active task?
-cleo orchestrate start T1575  # Full state: session, pipeline, next task
+cleo orchestrate ready T1575  # Parallel-safe tasks in the current wave
 ```
 
-### 2. RCASD — Plan the Work
+### 2. Plan the Work
 
 ```
 1. Create epic: cleo add "Title" --type epic --size large --priority critical \
      --acceptance "AC1|AC2|AC3" --description "What and why"
-2. Spawn Team Lead (sonnet) to run RCASD stages:
-   - Research → explore codebase, reference apps, gather context
-   - Consensus → validate approach with HITL
-   - Architecture → ADR decisions, pattern selection
-   - Specification → formal spec with RFC 2119 language
-   - Decomposition → atomic tasks under epic with deps + acceptance criteria
+2. Spawn a Team Lead (sonnet) to write the plan document:
+   - Findings → explore codebase, reference apps, gather context
+   - Decision → approach and patterns; owner choices via the ask tool
+   - Spec → acceptance criteria every task can prove
+   - Decomposition → atomic tasks under the epic with deps + acceptance criteria
 3. Review decomposition — verify tasks are atomic, deps correct, criteria testable
 4. Present plan to human for approval
 ```
 
-**Stage output documents go to the store (T13363 AC2).** When a stage finishes its
-output document (research findings, consensus record, spec), keep the working copy at
-`.cleo/rcasd/<epic>/<stage>/` AND push the finished document into the CleoDocs store
-so its `##` sections land as versioned, collaboratively-mergeable sections:
+**Planning documents go to the store (T13363 AC2, T13943).** Draft the document
+(research findings, consensus record, spec, plan) in your worktree or scratch space,
+never under `.cleo/rcasd/`, and push it into the CleoDocs store so its `##` sections
+land as versioned, collaboratively-mergeable sections:
 
 ```bash
-# First time — owner is the epic task, kind matches the stage
-cleo docs add T1575 .cleo/rcasd/T1575/research/T1575-research.md \
-  --type research --slug t1575-research
+# First time — owner is the epic task, kind matches the document
+cleo docs add T1575 ./T1575-research.md --type research --slug t1575-research
 
 # Re-runs / refreshes update the same doc (noop when bytes are unchanged)
-cleo docs update t1575-research --file .cleo/rcasd/T1575/research/T1575-research.md \
-  --message "research stage refresh"
+cleo docs update t1575-research --file ./T1575-research.md \
+  --message "research refresh"
 ```
 
-Retrieve with `cleo docs fetch t1575-research`. The raw stage file stays the working
-copy and gate input; the store doc is the durable sectioned record. Skipping the store
-write is not fatal — but a stage is not "published" until the store doc exists.
+Retrieve with `cleo docs fetch t1575-research`. A document is not "published" until
+the store doc exists.
+
+**Agents talk over AgentMBX (D11172).** Spawned agents coordinate with their lead and
+peers through AgentMBX (`mbx_*` tools; the `agentmbx` CLI can only send without the
+session's MCP lease). Spawn prompts carry an `## Agent Coordination (AgentMBX)` section and
+no CONDUIT subscription; `cleo orchestrate spawn <taskId> --lead-mbx <you>` names your
+mailbox in it. `cleo conduit` and the `conduit-*` sub-commands of `cleo orchestrate` are
+deprecated (T13982) and leave in the next release; do not build on them.
 
-### 3. IVTR — Execute the Work
+### 3. Execute the Work
 
 ```
 1. Read the waves: cleo orchestrate waves T1575 (take each wave n from here;
    numbers can skip and the first need not be 1), then cleo orchestrate ready T1575
 2. Spawn Workers in parallel for each ready task in the first incomplete wave
 3. On completion: read manifest, check acceptance criteria
-4. If criteria NOT met → re-spawn worker with feedback (IVTR loop)
+4. If criteria NOT met → re-spawn worker with feedback
 5. Advance to the next wave cleo orchestrate waves lists (its deps are now done)
 6. Repeat until all tasks complete
 7. Final validation with Lead across the full epic
@@ -267,7 +276,7 @@ write is not fatal — but a stage is not "published" until the store doc exists
   previously-deferred tasks promote into `admitted`. This is pull-based; never
   fail or skip a deferred task, just retry it on the next pull.
 - If a `cleo orchestrate spawn` returns `E_RESOURCE_DEFERRED` (the hard gate
-  denied an `agent-session` slot under pressure), treat it like a lifecycle gate:
+  denied an `agent-session` slot under pressure), treat it as a retryable deferral:
   wait `details.retryAfterMs` and re-spawn. No worktree/process was provisioned,
   so there is nothing to clean up.
 
@@ -319,7 +328,7 @@ Agent B reads the full file directly if details needed
 
 When operating without continuous HITL oversight, additional constraints apply: single coordination point, manifest-only reads, verify before next spawn, wave-order spawning, followup task creation for partial/blocked, auto-handoff at 80% context.
 
-**Autonomous scope**: task execution, dependency resolution, manifest writes, wave-order spawning, pipeline stage advancement.
+**Autonomous scope**: task execution, dependency resolution, manifest writes, wave-order spawning, advancing a new epic to implementation before its children exist (when the stage gate is on).
 
 **Requires HITL**: architectural decisions, scope expansion, destructive operations, cross-epic work, git push to main.
 
@@ -329,15 +338,11 @@ When operating without continuous HITL oversight, additional constraints apply:
 
 | Command | Purpose |
 |---------|---------|
-| `cleo orchestrate start T1575` | Full startup: session + pipeline + next task |
 | `cleo orchestrate ready T1575` | Parallel-safe tasks in current wave |
 | `cleo orchestrate spawn T1586 --json` | Generate resolved spawn prompt |
 | `cleo orchestrate next T1575` | Suggest next task |
 | `cleo saga rollup <sagaId>` | Cross-Epic status aggregation when orchestrating a multi-Epic Saga (ADR-073) |
 | `cleo saga members <sagaId>` | Member Epics of a Saga (parent_id containment — NOT `task_relations.groups`) |
-| `cleo pipeline stage.status --epic T1575` | Current pipeline stage |
-| `cleo pipeline stage.validate T1575 implementation` | Check gate before spawn |
-| `cleo pipeline stage.gate.pass T1575 research` | Advance pipeline stage |
 | `cleo find "query"` | Search tasks |
 | `cleo show T1234` | Full task details |
 | `cleo add "Task" --parent T1575` | Create child task |
@@ -404,7 +409,6 @@ before the verify call — audited to `.cleo/audit/force-bypass.jsonl`.
 | Token injection system | `references/orchestrator-tokens.md` |
 | Error recovery & context budget | `references/orchestrator-recovery.md` |
 | Autonomous operation | `references/autonomous-operation.md` |
-| Lifecycle gate enforcement | `references/lifecycle-gates.md` |
 | Common HITL patterns | `references/orchestrator-patterns.md` |
 | Handoff chain protocol | `references/orchestrator-handoffs.md` |
 | Subagent protocol block | `references/SUBAGENT-PROTOCOL-BLOCK.md` |

package/skills/ct-orchestrator/orchestrator-prompt.txt

@@ -1,16 +1,17 @@
 You are an orchestrator. You MUST NOT implement code directly.
 
-LOOM (RCASD → IVTR) is the core lifecycle for ALL work:
-- RCASD: Research → Consensus → Architecture → Specification → Decomposition
-- IVTR: Implement → Validate → Test → Release (loops until acceptance criteria pass)
-- Contribution: cross-cutting protocol throughout both phases
+Every piece of work runs one loop: plan, execute, verify.
+- Plan: one plan document per epic (cleo docs, --type plan), decisions in BRAIN,
+  atomic tasks with acceptance criteria and dependencies
+- Execute: waves and ready tasks from cleo orchestrate, agents coordinate over AgentMBX
+- Verify: evidence gates per task, an independent review per PR head
 
 Delegate ALL work to subagents. Spawning is two steps:
 1. `cleo orchestrate spawn T####` generates a fully-resolved prompt
 2. Pass that prompt to the provider's agent mechanism (Agent tool, subprocess, etc.)
 
-Before spawning, check pipeline gates via `cleo pipeline stage.validate`.
-Do not spawn implementation work until RCASD stages are complete.
+Before spawning, check `cleo orchestrate ready <epicId>`.
+Do not spawn implementation work until the plan document and tasks exist.
 
 CLEO CLI is the first-class project management layer — primary regardless
 of LLM provider or harness. Model assignment (opus/sonnet/haiku) is

package/skills/ct-orchestrator/references/orchestrator-patterns.md

@@ -28,8 +28,9 @@ cleo orchestrate next T1575
 
 ```bash
 # 1. Check state on conversation start
-cleo orchestrate start T1575
-# Shows: session active, current T1586, next task T1589
+cleo session status
+cleo orchestrate status --epic T1575
+# Shows: session active, epic progress, ready tasks
 
 # 2. Check for incomplete subagent work
 cleo research pending
@@ -141,14 +142,12 @@ cleo release reconcile v0.85.0
 
 See `src/protocols/release.md` for the full release protocol specification.
 
-## Full RCASD-IVTR+C Lifecycle
+## Full Epic Loop
 
 ```bash
-# RCASD-IVTR+C PIPELINE (setup phase)
-cleo orchestrate spawn T100  # research protocol
-cleo orchestrate spawn T101  # consensus protocol
-cleo orchestrate spawn T102  # specification protocol
-cleo orchestrate spawn T103  # decomposition protocol
+# PLAN (one plan document, decisions in BRAIN, tasks with AC)
+cleo orchestrate spawn T100  # research protocol: findings section
+cleo orchestrate spawn T103  # decomposition protocol: tasks with deps + AC
 
 # EXECUTION (core phase)
 cleo orchestrate spawn T104  # implementation protocol

package/skills/ct-orchestrator/references/orchestrator-spawning.md

@@ -39,7 +39,7 @@ Agent({
 })
 ```
 
-**Team Lead spawn** (for RCASD planning, validation):
+**Team Lead spawn** (for planning, validation):
 ```
 Agent({
   description: "Team Lead: Auth system architecture (T1575)",

package/skills/ct-task-executor/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: ct-task-executor
 description: General implementation task execution for completing assigned CLEO tasks by following instructions and producing concrete deliverables. Handles coding, configuration, documentation work with quality verification against acceptance criteria and progress reporting. Use when executing implementation tasks, completing assigned work, or producing task deliverables. Triggers on implementation tasks, general execution needs, or task completion work.
-version: 2.8.5
+version: 2.8.6
 protocol: implementation
 adrRefs:
   - ADR-070
@@ -17,7 +17,7 @@ compatibility:
   - gemini-cli
 license: MIT
 metadata:
-  version: 2.8.5
+  version: 2.8.6
   tier: core
   install: harness
   covers:
@@ -29,7 +29,7 @@ metadata:
     - packages/core/src/validation/protocols/cant/implementation.cant
     - packages/core/src/validation/protocols/protocols-markdown/implementation.md
   loomStage: implementation
-  lastReviewed: 2026-10-12
+  lastReviewed: 2026-10-24
   stability: stable
 ---
 
@@ -213,7 +213,7 @@ Record it with `cleo docs add {{TASK_ID}} --content - --type note --slug {{TOPIC
 
 ## Acceptance Criteria Verification
 
-Record each criterion's changed artifacts and actual verification results. A merged PR with green CI provides provenance; it cannot automatically satisfy implementation, testing and review. Use `pr:<number>;files:<changed-path>` for implementation (`pr:<component>@<integration>` when your PR merged into an integration branch) and actual result atoms for test/review gates, with explicit `satisfies:T1234#AC1` links for canonical criteria. The PR must relate to the task; documentation-only changes cannot prove a code fix. Research and documentation tasks may use appropriately scoped documentary evidence. Fetch the merge commit before claiming its artifact bytes were inspected. Criterion edits require fresh evidence. A completed child does not establish that its parent's independent criteria were met. `cleo verify <id> --all` sets every required gate at once and still requires `--evidence`; bare `--all` is rejected with `E_EVIDENCE_MISSING`. A failing `tool:<name>` reason names the resolved command and its source, so check that command before retrying. To adopt a native typecheck or lint run for `qaPassed` without re-running it, record one `qa-run:<receipt.json>` per check (`cleo verify --help` lists the receipt shape).
+Record each criterion's changed artifacts and actual verification results. A merged PR with green CI provides provenance; it cannot automatically satisfy implementation, testing and review. Use `pr:<number>;files:<changed-path>` for implementation (`pr:<component>@<integration>` when your PR merged into an integration branch) and actual result atoms for test/review gates, with explicit `satisfies:T1234#AC1` links for canonical criteria. The PR must relate to the task; documentation-only changes cannot prove a code fix. Research and documentation tasks may use appropriately scoped documentary evidence: they owe `verification.requiredGatesByKind` (default: the required gates without `testsPassed`/`qaPassed`), but once their work touches any non-document path they owe the full code gates, whatever their kind or labels. Fetch the merge commit before claiming its artifact bytes were inspected. Criterion edits require fresh evidence. A completed child does not establish that its parent's independent criteria were met. `cleo verify <id> --all` sets every required gate at once and still requires `--evidence`; bare `--all` is rejected with `E_EVIDENCE_MISSING`. A failing `tool:<name>` reason names the resolved command and its source, so check that command before retrying. To adopt a native typecheck or lint run for `qaPassed` without re-running it, record one `qa-run:<receipt.json>` per check (`cleo verify --help` lists the receipt shape).
 
 
 | Criterion | Status | Notes |