valent-pipeline 0.2.26 → 0.3.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "valent-pipeline",
-  "version": "0.2.26",
+  "version": "0.3.0",
   "description": "v3 multi-agent AI pipeline for software development lifecycle",
   "type": "module",
   "bin": {

package/pipeline/docs/design/provider-adapter-guide.md

@@ -0,0 +1,173 @@
+# Provider Adapter Guide
+
+> How the multi-provider pattern works, how to keep providers in sync, and how to add provider-specific behavior.
+
+---
+
+## Architecture Overview
+
+**Shared logic in shared files. Runtime-specific operations in provider-specific files.**
+
+The pipeline logic (what agents do, in what order, with what quality gates) is provider-agnostic. The runtime mechanics (how agents are spawned, how signals are delivered, how tasks are tracked) are provider-specific.
+
+```
+pipeline/
+  prompts/lead.md                  ← SHARED — orchestration logic (WHEN/WHY)
+  steps/orchestration/*.md         ← SHARED — kickoff, monitoring, teardown logic
+  prompts/*.md                     ← SHARED — agent expertise (WHAT to do)
+  steps/**/*.md                    ← SHARED — domain procedures (HOW to do it)
+  agents-manifest.yaml             ← SHARED — agent roster, dependencies, models
+  templates/*.md                   ← SHARED — handoff document formats
+  docs/communication-standard.md   ← SHARED — message formats (runtime-agnostic)
+  spawn-templates/                 ← SHARED — runtime-agnostic context template
+  providers/
+    claude-code/
+      runtime.md                   ← PROVIDER — Claude Code runtime operations
+      spawn.template.md            ← PROVIDER — Claude Code spawn template
+      knowledge-spawn.template.md  ← PROVIDER — Claude Code knowledge spawn
+    codex/
+      runtime.md                   ← PROVIDER — Codex runtime operations
+      spawn.template.md            ← PROVIDER — Codex spawn template
+      knowledge-spawn.template.md  ← PROVIDER — Codex knowledge spawn
+      AGENTS.md                    ← PROVIDER — Codex repo-level instructions
+      cloud-task-protocol.md       ← PROVIDER — Codex cloud execution protocol
+      cloud-task-prompts/          ← PROVIDER — Codex cloud task templates
+      codex-project-files/         ← PROVIDER — Files deployed to target project
+```
+
+---
+
+## How Delegation Works
+
+1. **At init:** `pipeline-config.yaml` sets `runtime.provider` to `claude-code` or `codex`
+2. **At kick-off:** Lead reads its provider's runtime adapter: `.valent-pipeline/providers/{provider}/runtime.md`
+3. **During execution:** Lead follows the runtime adapter for all runtime-specific operations (spawn, signal, monitor, teardown)
+4. **Agent awareness:** Each agent reads `signal_delivery` and `execution_mode` from `pipeline-context.md` to know how to communicate
+
+Lead's prompt (`lead.md`) defines WHEN and WHY. The runtime adapter defines HOW.
+
+---
+
+## Provider File Inventory
+
+### Required for Every Provider
+
+| File | Purpose |
+|------|---------|
+| `runtime.md` | All runtime operations: initialization, task registry, agent spawning, signal delivery, monitoring, teardown |
+| `spawn.template.md` | Agent spawn prompt template — what each agent instance receives at startup |
+| `knowledge-spawn.template.md` | Knowledge agent spawn template — knowledge-specific initialization |
+
+### Codex-Only Files
+
+| File | Purpose |
+|------|---------|
+| `AGENTS.md` | Codex repo-level instructions (equivalent to CLAUDE.md) — deployed to project root |
+| `cloud-task-protocol.md` | Commit/push protocol for cloud execution |
+| `cloud-task-prompts/*.md` | Per-phase prompt templates for multi-task cloud mode |
+| `codex-project-files/.codex/` | Codex CLI configuration files deployed to target project |
+| `codex-project-files/.github/` | GitHub Action workflow for cloud orchestration |
+
+---
+
+## Classification Rule
+
+Every file in the pipeline falls into exactly one category:
+
+| Category | Location | Change Protocol |
+|----------|----------|----------------|
+| **Shared** | `prompts/`, `steps/` (non-orchestration), `templates/`, `agents-manifest.yaml`, `docs/` | Change once. Both providers get it automatically. |
+| **Provider-specific** | `providers/{provider}/` | Change in one provider. Manually add equivalent to the other. |
+| **Orchestration** | `steps/orchestration/`, `lead.md` | Shared logic stays. Runtime calls delegate to provider adapter. |
+
+---
+
+## Adding a New Agent
+
+Follow the [Refactor Checklist](refactor-checklist.md) for all locations. The provider-specific additions are:
+
+| Step | Shared | Claude Code | Codex |
+|------|--------|-------------|-------|
+| Define agent | `agents-manifest.yaml` | — | — |
+| Write prompt | `prompts/{agent}.md` | — | — |
+| Write steps | `steps/{agent}/*.md` | — | — |
+| Write template | `templates/{agent}-*.md` | — | — |
+| Add to spawn wave | — | `providers/claude-code/runtime.md` | `providers/codex/runtime.md` |
+| Update model map | — | `pipeline-config.yaml` (models) | `pipeline-config.yaml` (codex.model_map) |
+
+Additionally if the agent has special communication patterns:
+- `steps/common/agent-protocol.md` — update inbox protocol if new message types
+- `docs/communication-standard.md` — document new message types
+- `providers/codex/AGENTS.md` — update if agent introduces new repo-level conventions
+- `providers/codex/codex-project-files/.codex/agents/` — assign agent to a TOML type or create new one
+
+5 shared changes, 2-4 provider-specific changes. The provider-specific changes are mechanical.
+
+---
+
+## Adding a New Communication Pattern
+
+| Step | Shared | Claude Code | Codex |
+|------|--------|-------------|-------|
+| Define format | `docs/communication-standard.md` | — | — |
+| Add to lead inbox protocol | `lead.md` (when/why) | `providers/claude-code/runtime.md` (how) | `providers/codex/runtime.md` (how) |
+| Add to agent prompts | `prompts/*.md` (reference protocol) | — | — |
+
+The pattern in agent prompts is:
+```markdown
+If signal_delivery is sendmessage: send [NEW-SIGNAL] to {target} via SendMessage.
+```
+
+For Codex, the agent writes output to disk. Lead reads it and steers the target thread.
+
+---
+
+## Adding a New Quality Gate
+
+Entirely shared. Quality gates are orchestration logic (when to reject, where to route), not runtime operations. No provider-specific changes needed.
+
+---
+
+## Adding a Third Provider
+
+1. Create `providers/{new-provider}/` with:
+   - `runtime.md` — all runtime operations for the new provider
+   - `spawn.template.md` — spawn template adapted for the provider's agent model
+   - `knowledge-spawn.template.md` — knowledge spawn adapted
+
+2. Update `src/lib/config-schema.js`:
+   - Add new provider to `validProviders` array
+   - Add validation for provider-specific config fields
+
+3. Update `src/commands/init.js`:
+   - Add new provider to wizard choices
+   - Add deployment step for provider-specific project files (if any)
+   - Add config generation for provider-specific YAML section
+
+4. Update agent prompts if the new provider has a different signal delivery model:
+   - Add new `signal_delivery` value
+   - Add conditional blocks in agent prompts: `If signal_delivery is {new_mode}:`
+
+5. Update `scripts/validate-provider-sync.js` to include the new provider.
+
+6. Update this guide and the refactor checklist.
+
+---
+
+## CI Validation
+
+The `scripts/validate-provider-sync.js` script runs in CI before every publish. It checks:
+
+1. **Template parity** — `spawn.template.md` and `knowledge-spawn.template.md` exist in both provider directories
+2. **Agent coverage** — Both runtime.md files reference the same set of agents from `agents-manifest.yaml`
+3. **Structural consistency** — Both runtime.md files have the same major sections (Initialization, Task Registry, Agent Spawning, Signal Delivery, Monitoring, Teardown)
+
+If any check fails, the publish is blocked. Fix the discrepancy, then re-push.
+
+---
+
+## Further Reading
+
+- [Codex Provider Support](codex-provider-support.md) — detailed Codex design, thread model, cloud execution
+- [Refactor Checklist](refactor-checklist.md) — full list of locations to update for any pipeline change
+- [Communication Standard](../communication-standard.md) — message formats and handoff protocol

package/pipeline/docs/design/refactor-checklist.md

@@ -93,6 +93,22 @@ When making design changes to the pipeline (new agents, renamed agents, new conf
 
 ---
 
+## Provider Sync
+
+After any pipeline change, verify:
+- [ ] `providers/claude-code/runtime.md` — does the change affect runtime operations?
+- [ ] `providers/codex/runtime.md` — does the change affect runtime operations?
+- [ ] If a new agent was added: both provider spawn lists updated
+- [ ] If a new signal type was added: both provider signal delivery sections updated
+- [ ] If task tracking changed: both provider task registry sections updated
+- [ ] `pipeline-config.yaml` schema — new provider-specific settings documented
+- [ ] If spawn template changed: both `providers/{provider}/spawn.template.md` updated
+- [ ] If knowledge spawn changed: both `providers/{provider}/knowledge-spawn.template.md` updated
+- [ ] `providers/codex/AGENTS.md` — does it need new conventions for this change?
+- [ ] `providers/codex/codex-project-files/.codex/agents/` — does this change require a new agent type TOML?
+
+---
+
 ## Verification
 
 After all changes, run these greps to catch stragglers:

package/pipeline/docs/index.md

@@ -35,6 +35,7 @@ Design documents for pipeline extensions and architectural decisions.
 |---|---|
 | [Refactor Checklist](design/refactor-checklist.md) | Every location to update when changing agents, config, tables, statuses, or phases |
 | [Codex Provider Support](design/codex-provider-support.md) | Multi-provider architecture: Codex runtime adapter, sync strategy, phased implementation plan |
+| [Provider Adapter Guide](design/provider-adapter-guide.md) | How the provider adapter pattern works, how to add provider-specific behavior, sync protocol |
 
 ## Quick Navigation
 
@@ -43,6 +44,7 @@ Design documents for pipeline extensions and architectural decisions.
 - **New to the pipeline?** Start with [Pipeline Overview](pipeline-overview.md), then [Agent Reference](agent-reference.md)
 - **Configuring a project?** See the [README](../../README.md) configuration section, then [NPX Packaging](npx-packaging.md)
 - **Adding or changing agents?** Read [Refactor Checklist](design/refactor-checklist.md) first, then [Agent Reference](agent-reference.md) and [Task Graph Specification](task-graph.md)
+- **Adding provider support?** Read [Provider Adapter Guide](design/provider-adapter-guide.md), then [Codex Provider Support](design/codex-provider-support.md)
 - **Debugging a stuck pipeline?** Check [Lead Lifecycle](lead-lifecycle.md) sections on stall detection, rejection loops, and crash recovery
 - **Understanding the knowledge system?** Read [Knowledge System](knowledge-system.md) for correction directives, curation, and RAG assessment
 - **Writing or modifying templates?** Consult [Template Skeleton](template-skeleton.md) for the universal structure
@@ -59,3 +61,4 @@ Design documents for pipeline extensions and architectural decisions.
 | `task-graphs/*.yaml` | [Task Graph Specification](task-graph.md) |
 | `steps/**/*.md` | Individual agent prompts reference their step files |
 | `knowledge/` | [Knowledge System](knowledge-system.md) |
+| `providers/**/*` | [Provider Adapter Guide](design/provider-adapter-guide.md) |

package/pipeline/docs/pipeline-state-schema.md

@@ -37,7 +37,23 @@ Defines the JSON schema for `pipeline-state.json`, the Lead agent's persistent s
   ],
   "stories_completed_since_retro": 3,
   "last_retrospective_batch": 2,
-  "total_stories_completed": 12
+  "total_stories_completed": 12,
+  "execution_mode": "cli",
+  "cloud_task": null
+}
+```
+
+When `execution_mode` is `cloud-single` or `cloud-multi`, the `cloud_task` field tracks cloud-specific state:
+
+```json
+{
+  "cloud_task": {
+    "task_name": "implementation",
+    "task_sequence": 2,
+    "task_total": 5,
+    "started_at": "2026-04-06T14:30:00Z",
+    "last_checkpoint_commit": "abc1234"
+  }
 }
 ```
 
@@ -56,6 +72,8 @@ Defines the JSON schema for `pipeline-state.json`, the Lead agent's persistent s
 | `last_retrospective_batch` | integer | Batch number of the most recent retrospective run | Lead (to compute next retro trigger) | Retrospective Agent (on completion) |
 | `total_stories_completed` | integer | Lifetime counter of all stories completed in this pipeline | Lead (for reporting) | Lead (incremented on story completion) |
 | `blocked_stories` | array | Stories blocked during this pipeline run, with escalation metadata. Used for crash recovery (quickly reconstruct blocked set without scanning backlog) and resume protocol. | Lead (on startup, resume) | Lead (when escalation occurs) |
+| `execution_mode` | enum | `cli` (default), `cloud-single`, or `cloud-multi`. Determines commit/push behavior and cloud task protocol. | Lead (on startup, teardown) | Lead (on init, set from pipeline context) |
+| `cloud_task` | object\|null | Cloud task metadata. `null` for CLI mode. Tracks task name, sequence position, and last checkpoint commit for recovery. | Lead (on startup in cloud mode) | Lead (on cloud task start, after each checkpoint commit) |
 
 ### `blocked_stories[]` Entry Fields
 

package/pipeline/prompts/bend.md

@@ -10,10 +10,10 @@ Read `.valent-pipeline/steps/common/agent-protocol.md` for Communication Standar
 You are spawned at story kick-off but do NOT begin work immediately.
 
 - **Wait for:** `[READINESS-APPROVAL]` (Pass 1) from READINESS
-- **On completion:** Send `[HANDOFF]` to CRITIC. CC Lead. If FEND is active, CRITIC waits for both -- send your handoff; CRITIC starts when it has both.
-- **On rejection received (from CRITIC):** Read rejection at critic-review.md. Fix code. Re-send `[HANDOFF]` to CRITIC.
-- **On bug received (from QA-B):** Fix bug. Notify QA-B when fixed.
-- **Escalate to:** Lead -- for `[BLOCKER]`, `[ESCALATION]`, or any issue you cannot resolve peer-to-peer.
+- **On completion:** Write handoff file with verdict. If signal_delivery is sendmessage: also send `[HANDOFF]` to CRITIC and CC Lead via inbox. If FEND is active, CRITIC waits for both -- send your handoff; CRITIC starts when it has both.
+- **On rejection (from CRITIC, via inbox or Lead steering):** Read rejection at critic-review.md. Fix code. Write updated handoff. If signal_delivery is sendmessage: re-send `[HANDOFF]` to CRITIC via inbox.
+- **On bug (from QA-B, via inbox or Lead steering):** Fix bug. If signal_delivery is sendmessage: notify QA-B via inbox when fixed.
+- **Escalate to:** Lead. If signal_delivery is sendmessage: send `[BLOCKER]` or `[ESCALATION]` via inbox. If thread: write status: blocked to output frontmatter.
 
 ## Context
 
@@ -46,9 +46,9 @@ Additional BEND-specific standards:
 
 ## Coordination with FEND
 
-You and FEND work on the same branch. When touching shared files (types, constants, config, shared utilities), coordinate via inbox: `[SHARED-FILE] I'm modifying {file}. Changes: {brief description}.`
+You and FEND work on the same branch. When touching shared files (types, constants, config, shared utilities), coordinate: if `signal_delivery` is `sendmessage`: send `[SHARED-FILE] I'm modifying {file}. Changes: {brief description}.` via inbox. If `signal_delivery` is `thread`: write shared file details to your handoff frontmatter. Lead relays via steering.
 
-FEND may ask what you named an endpoint or what shape a response takes. Answer promptly via inbox with a pointer to `bend-handoff.md#api-endpoints-implemented`.
+FEND may ask what you named an endpoint or what shape a response takes. If `signal_delivery` is `sendmessage`: answer promptly via inbox with a pointer to `bend-handoff.md#api-endpoints-implemented`. If `signal_delivery` is `thread`: write API details to your handoff file; Lead relays.
 
 ## Step Sequence
 

package/pipeline/prompts/critic.md

@@ -12,9 +12,9 @@ Additional frontmatter field: `review_depth`.
 You are spawned at story kick-off but do NOT begin work immediately.
 
 - **Wait for:** `[HANDOFF]` from BEND (and FEND if active). If both are active, wait for BOTH before starting review.
-- **On approval:** Send `[CRITIC-APPROVED]` to QA-B. Send `[DONE]` to Lead. Mark your task completed. This unblocks QA-B.
-- **On rejection:** Send `[CRITIC-REJECTION]` to BEND or FEND (whichever owns the finding) AND to Lead. Do NOT send `[DONE]`. Do NOT mark your task completed. Your task stays `in_progress` — this keeps QA-B blocked. After dev fixes and re-sends `[HANDOFF]`, perform delta review (only changed files). Re-evaluate verdict.
-- **Escalate to:** Lead -- for `[BLOCKER]`, `[ESCALATION]`, or any issue you cannot resolve peer-to-peer.
+- **On approval:** Write critic-review.md with verdict: APPROVED. If signal_delivery is sendmessage: also send `[CRITIC-APPROVED]` to QA-B and `[DONE]` to Lead via inbox. Mark your task completed. This unblocks QA-B.
+- **On rejection:** Write critic-review.md with verdict and rejection_target in frontmatter. If signal_delivery is sendmessage: also send `[CRITIC-REJECTION]` to BEND or FEND (whichever owns the finding) AND to Lead via inbox. Do NOT send `[DONE]`. Do NOT mark your task completed. Your task stays in_progress — this keeps QA-B blocked. After dev fixes and re-sends `[HANDOFF]` (via inbox or Lead steering), perform delta review (only changed files). Re-evaluate verdict.
+- **Escalate to:** Lead. If signal_delivery is sendmessage: send `[BLOCKER]` or `[ESCALATION]` via inbox. If thread: write status: blocked to output frontmatter.
 
 ## Context Variables
 
@@ -63,7 +63,10 @@ After triage-depth, execute only the passes indicated by your selected depth lev
 Read ALL changed files. Categorize into production code vs test code. Note file count and line count for the Review Scope section.
 
 ### Step 2b: Query Knowledge Agent (Conditional)
-If a Knowledge Agent is available, send: `[KNOWLEDGE-QUERY] What recurring code quality issues, known anti-patterns, and correction directives should I apply during review? Context: I am CRITIC reviewing code for {story_id}.` If no response within a reasonable time, proceed without.
+If a Knowledge Agent is available:
+- If signal_delivery is sendmessage: send `[KNOWLEDGE-QUERY] What recurring code quality issues, known anti-patterns, and correction directives should I apply during review? Context: I am CRITIC reviewing code for {story_id}.` to Knowledge via inbox.
+- If signal_delivery is thread: write query to `{story_output_dir}/knowledge-queries/critic-1.md`. Continue without waiting.
+- If no response within a reasonable time or no Knowledge Agent is spawned, proceed without.
 
 ### Step 3b: Load Profile Steps for Edge Case Hunt (Conditional)
 For edge-case-hunt, also read profile-specific step files based on `{testing_profiles}`: `.valent-pipeline/steps/critic/api.md`, `ui.md`, `data-pipeline.md`, `mcp-server.md`, `library.md`, `document-generation.md`, `iac.md`. If a profile step file does not exist, note it and proceed. Apply domain-specific focus areas alongside the generic ones.

package/pipeline/prompts/data.md

@@ -10,10 +10,10 @@ Read `.valent-pipeline/steps/common/agent-protocol.md` for Communication Standar
 You are spawned at story kick-off but do NOT begin work immediately.
 
 - **Wait for:** `[READINESS-APPROVAL]` (Pass 1) from READINESS
-- **On completion:** Send `[HANDOFF]` to CRITIC. CC Lead.
-- **On rejection received (from CRITIC):** Read rejection at critic-review.md. Fix code. Re-send `[HANDOFF]` to CRITIC.
-- **On bug received (from QA-B):** Fix bug. Notify QA-B when fixed.
-- **Escalate to:** Lead -- for `[BLOCKER]`, `[ESCALATION]`, or any issue you cannot resolve peer-to-peer.
+- **On completion:** Write handoff file with verdict. If signal_delivery is sendmessage: also send `[HANDOFF]` to CRITIC and CC Lead via inbox.
+- **On rejection (from CRITIC, via inbox or Lead steering):** Read rejection at critic-review.md. Fix code. Write updated handoff. If signal_delivery is sendmessage: re-send `[HANDOFF]` to CRITIC via inbox.
+- **On bug (from QA-B, via inbox or Lead steering):** Fix bug. If signal_delivery is sendmessage: notify QA-B via inbox when fixed.
+- **Escalate to:** Lead. If signal_delivery is sendmessage: send `[BLOCKER]` or `[ESCALATION]` via inbox. If thread: write status: blocked to output frontmatter.
 
 ## Context
 

package/pipeline/prompts/docgen.md

@@ -10,10 +10,10 @@ Read `.valent-pipeline/steps/common/agent-protocol.md` for Communication Standar
 You are spawned at story kick-off but do NOT begin work immediately.
 
 - **Wait for:** `[READINESS-APPROVAL]` (Pass 1) from READINESS
-- **On completion:** Send `[HANDOFF]` to CRITIC. CC Lead.
-- **On rejection received (from CRITIC):** Read rejection at critic-review.md. Fix code. Re-send `[HANDOFF]` to CRITIC.
-- **On bug received (from QA-B):** Fix bug. Notify QA-B when fixed.
-- **Escalate to:** Lead -- for `[BLOCKER]`, `[ESCALATION]`, or any issue you cannot resolve peer-to-peer.
+- **On completion:** Write handoff file with verdict. If signal_delivery is sendmessage: also send `[HANDOFF]` to CRITIC and CC Lead via inbox.
+- **On rejection (from CRITIC, via inbox or Lead steering):** Read rejection at critic-review.md. Fix code. Write updated handoff. If signal_delivery is sendmessage: re-send `[HANDOFF]` to CRITIC via inbox.
+- **On bug (from QA-B, via inbox or Lead steering):** Fix bug. If signal_delivery is sendmessage: notify QA-B via inbox when fixed.
+- **Escalate to:** Lead. If signal_delivery is sendmessage: send `[BLOCKER]` or `[ESCALATION]` via inbox. If thread: write status: blocked to output frontmatter.
 
 ## Context
 

package/pipeline/prompts/embed.md

@@ -23,7 +23,7 @@ Read `.valent-pipeline/steps/common/agent-protocol.md` for Communication Standar
 ## Execution Steps
 
 ### Step 1: Validate Inputs
-Verify `{story_output_dir}/embed-instructions.md` exists. If missing, send `[BLOCKER]` to lead and terminate.
+Verify `{story_output_dir}/embed-instructions.md` exists. If missing: If signal_delivery is sendmessage: send `[BLOCKER]` to lead. If thread: write status: blocked to output frontmatter. Terminate.
 
 ### Step 2: Run Embed Script
 
@@ -50,7 +50,7 @@ npx tsx .valent-pipeline/scripts/embed.ts {story_output_dir}/embed-instructions.
 ### Step 3: Verify and Report
 Check the script's exit code: Exit 0 = success, Exit 1 = errors (details in stderr).
 
-Send inbox message to lead: `[EMBED-COMPLETE] Indexed {count} items.` (or `[EMBED-PARTIAL]` if errors occurred). Agent terminates.
+If signal_delivery is sendmessage: Send inbox message to lead: `[EMBED-COMPLETE] Indexed {count} items.` (or `[EMBED-PARTIAL]` if errors occurred). Agent terminates.
 
 ## Boundaries
 
@@ -61,7 +61,7 @@ Send inbox message to lead: `[EMBED-COMPLETE] Indexed {count} items.` (or `[EMBE
 
 ## Error Handling
 
-- If embed-instructions.md is missing: send `[BLOCKER]` to lead, terminate.
+- If embed-instructions.md is missing: If signal_delivery is sendmessage: send `[BLOCKER]` to lead. If thread: write status: blocked to output frontmatter. Terminate.
 - If SQLite database is missing: it will be auto-created on first write. If the DB file cannot be created, skip DB instructions and index curated files only.
 - If ChromaDB connection fails (legacy mode): skip ChromaDB instructions, index curated files only, report partial completion.
 - If a curated file write fails: log the failure, continue to next instruction, report in completion message.

package/pipeline/prompts/fend.md

@@ -10,10 +10,10 @@ Read `.valent-pipeline/steps/common/agent-protocol.md` for Communication Standar
 You are spawned at story kick-off but do NOT begin work immediately.
 
 - **Wait for:** `[READINESS-APPROVAL]` (Pass 1) from READINESS
-- **On completion:** Send `[HANDOFF]` to CRITIC. CC Lead. CRITIC waits for both BEND and FEND -- send your handoff; CRITIC starts when it has both.
-- **On rejection received (from CRITIC):** Read rejection at critic-review.md. Fix code. Re-send `[HANDOFF]` to CRITIC.
-- **On bug received (from QA-B):** Fix bug. Notify QA-B when fixed.
-- **Escalate to:** Lead -- for `[BLOCKER]`, `[ESCALATION]`, or any issue you cannot resolve peer-to-peer.
+- **On completion:** Write handoff file with verdict. If signal_delivery is sendmessage: also send `[HANDOFF]` to CRITIC and CC Lead via inbox. CRITIC waits for both BEND and FEND -- send your handoff; CRITIC starts when it has both.
+- **On rejection (from CRITIC, via inbox or Lead steering):** Read rejection at critic-review.md. Fix code. Write updated handoff. If signal_delivery is sendmessage: re-send `[HANDOFF]` to CRITIC via inbox.
+- **On bug (from QA-B, via inbox or Lead steering):** Fix bug. If signal_delivery is sendmessage: notify QA-B via inbox when fixed.
+- **Escalate to:** Lead. If signal_delivery is sendmessage: send `[BLOCKER]` or `[ESCALATION]` via inbox. If thread: write status: blocked to output frontmatter.
 
 ## Context
 
@@ -64,9 +64,9 @@ Component names must match uxa-spec.md component specifications exactly. Do not
 
 ## Coordination with BEND
 
-You and BEND work on the same branch. When touching shared files, coordinate via inbox: `[SHARED-FILE] I'm modifying {file}. Changes: {brief description}.`
+You and BEND work on the same branch. When touching shared files, coordinate: if `signal_delivery` is `sendmessage`: send `[SHARED-FILE] I'm modifying {file}. Changes: {brief description}.` via inbox. If `signal_delivery` is `thread`: write shared file details to your handoff frontmatter. Lead relays via steering.
 
-If you need endpoint or response shape info, ask BEND via inbox. Use `bend-handoff.md#integration-notes-for-fend` as your primary reference for API contracts once BEND has published it.
+If you need endpoint or response shape info: if `signal_delivery` is `sendmessage`: ask BEND via inbox. If `signal_delivery` is `thread`: read `bend-handoff.md#integration-notes-for-fend` directly. Use that file as your primary reference for API contracts once BEND has published it.
 
 ## Step Sequence
 

package/pipeline/prompts/iac.md

@@ -10,10 +10,10 @@ Read `.valent-pipeline/steps/common/agent-protocol.md` for Communication Standar
 You are spawned at story kick-off but do NOT begin work immediately.
 
 - **Wait for:** `[READINESS-APPROVAL]` (Pass 1) from READINESS
-- **On completion:** Send `[HANDOFF]` to CRITIC. CC Lead. CRITIC waits for all active dev agents -- send your handoff; CRITIC starts when it has all.
-- **On rejection received (from CRITIC):** Read rejection at critic-review.md. Fix code. Re-send `[HANDOFF]` to CRITIC.
-- **On bug received (from QA-B):** Fix bug. Notify QA-B when fixed.
-- **Escalate to:** Lead -- for `[BLOCKER]`, `[ESCALATION]`, or any issue you cannot resolve peer-to-peer.
+- **On completion:** Write handoff file with verdict. If signal_delivery is sendmessage: also send `[HANDOFF]` to CRITIC and CC Lead via inbox. CRITIC waits for all active dev agents -- send your handoff; CRITIC starts when it has all.
+- **On rejection (from CRITIC, via inbox or Lead steering):** Read rejection at critic-review.md. Fix code. Write updated handoff. If signal_delivery is sendmessage: re-send `[HANDOFF]` to CRITIC via inbox.
+- **On bug (from QA-B, via inbox or Lead steering):** Fix bug. If signal_delivery is sendmessage: notify QA-B via inbox when fixed.
+- **Escalate to:** Lead. If signal_delivery is sendmessage: send `[BLOCKER]` or `[ESCALATION]` via inbox. If thread: write status: blocked to output frontmatter.
 
 ## Context
 
@@ -52,9 +52,9 @@ Additional IAC-specific standards:
 
 ## Coordination with Other Dev Agents
 
-You and BEND/FEND/DATA/etc work on the same branch. When touching shared config (env vars, secrets, connection strings), coordinate via inbox: `[SHARED-FILE] I'm modifying {file}. Changes: {brief description}.`
+You and BEND/FEND/DATA/etc work on the same branch. When touching shared config (env vars, secrets, connection strings), coordinate: if `signal_delivery` is `sendmessage`: send `[SHARED-FILE] I'm modifying {file}. Changes: {brief description}.` via inbox. If `signal_delivery` is `thread`: write shared config details to your handoff frontmatter. Lead relays via steering.
 
-Other dev agents may ask what environment variables or connection strings you provisioned. Answer promptly via inbox with a pointer to `iac-handoff.md#environment-configuration`.
+Other dev agents may ask what environment variables or connection strings you provisioned. If `signal_delivery` is `sendmessage`: answer promptly via inbox with a pointer to `iac-handoff.md#environment-configuration`. If `signal_delivery` is `thread`: write details to your handoff file; other agents read directly.
 
 ## Step Sequence
 

package/pipeline/prompts/judge.md

@@ -14,10 +14,10 @@ You are spawned when CRITIC starts reviewing (wave 3) but do NOT begin work imme
 
 - **Wait for:** `[HANDOFF]` from QA-B. Do NOT begin if CRITIC task is still `in_progress` (rejection/bug cycle ongoing).
 - **On bug review approval (no reclassifications to P1-P3):** Proceed directly to evidence review. No external message needed — this is an internal transition.
-- **On bug reclassification (P4 escalated to P1-P3):** Send `[JUDGE-RECLASS]` to the responsible dev (BEND or FEND per root cause) AND to Lead. Do NOT proceed to evidence review until bugs are fixed and QA-B re-runs.
-- **On SHIP verdict:** Send `[JUDGE-SHIP]` to Lead. Mark task completed. Lead owns ship/teardown.
-- **On REJECT verdict:** Send `[JUDGE-REJECT]` to Lead. Mark task completed. Lead owns JUDGE rejection routing — this is non-routine.
-- **Escalate to:** Lead — for `[BLOCKER]` or any issue you cannot resolve.
+- **On bug reclassification (P4 escalated to P1-P3):** Write reclassification to judge-review.md. If signal_delivery is sendmessage: also send `[JUDGE-RECLASS]` to the responsible dev AND to Lead via inbox. Do NOT proceed to evidence review until bugs are fixed and QA-B re-runs.
+- **On SHIP verdict:** Write judge-decision.md with verdict: SHIP. If signal_delivery is sendmessage: also send `[JUDGE-SHIP]` to Lead via inbox. Mark task completed.
+- **On REJECT verdict:** Write judge-decision.md with verdict: REJECT. If signal_delivery is sendmessage: also send `[JUDGE-REJECT]` to Lead via inbox. Mark task completed.
+- **Escalate to:** Lead. If signal_delivery is sendmessage: send `[BLOCKER]` or `[ESCALATION]` via inbox. If thread: write status: blocked to output frontmatter.
 
 ## Output
 

package/pipeline/prompts/knowledge.md

@@ -2,16 +2,22 @@
 
 <!-- Prompt version: 1.1 | Model: Haiku | Lifecycle: per-story -->
 
-You are **KNOWLEDGE**, the knowledge retrieval agent. You answer queries from teammates by searching persistent data sources: correction directives, curated knowledge files, and the knowledge database (SQLite or ChromaDB). You produce no file output -- all responses go via inbox.
+You are **KNOWLEDGE**, the knowledge retrieval agent. You answer queries from teammates by searching persistent data sources: correction directives, curated knowledge files, and the knowledge database (SQLite or ChromaDB). When `signal_delivery` is `sendmessage`: respond via inbox only, no file output. When `signal_delivery` is `thread`: write responses to `{story_output_dir}/knowledge-responses/` only.
 
 Read `.valent-pipeline/steps/common/agent-protocol.md` for Communication Standard and Inbox Protocol.
 
-**Inbox specifics for KNOWLEDGE:**
-- Incoming: `[KNOWLEDGE-QUERY] {question}`
-- Response: `[KNOWLEDGE-RESPONSE] {answer}. Source: {source reference}.`
-- No match: `[KNOWLEDGE-RESPONSE] No relevant knowledge found for: {query summary}`
+**When `signal_delivery` is `sendmessage` (Claude Code):**
+- Incoming: `[KNOWLEDGE-QUERY] {question}` via inbox
+- Response: `[KNOWLEDGE-RESPONSE] {answer}. Source: {source reference}.` via inbox
+- No match: `[KNOWLEDGE-RESPONSE] No relevant knowledge found for: {query summary}` via inbox
 
-**Context Discipline:** Message budget applies (under 500 tokens). No unsolicited messages -- only respond to `[KNOWLEDGE-QUERY]` messages.
+**When `signal_delivery` is `thread` (Codex):**
+- Incoming: Lead steers you with a query file path in `{story_output_dir}/knowledge-queries/`
+- Response: Write to `{story_output_dir}/knowledge-responses/{agent}-{n}.md`
+- No match: Write "No relevant knowledge found for: {query summary}" to response file
+- Do NOT use SendMessage or inbox messaging.
+
+**Context Discipline:** Message budget applies (under 500 tokens for inbox, or equivalent file size). No unsolicited messages or files -- only respond to queries.
 
 ## Context Variables
 
@@ -69,12 +75,12 @@ Cross-reference BOTH correction directives and curated files for convention/patt
 
 ## Story Reset Protocol (Epic Mode)
 
-On `[STORY-RESET] story_id={new_story_id}, pipeline_context={new_pipeline_context_path}`:
+On story reset (via `[STORY-RESET]` inbox message or Lead steering):
 1. Update `{story_id}` to new value
 2. Read new `pipeline-context.md`
 3. Re-read `{correction_directives}` and `{curated_files_path}`
 4. Refresh database connection if connected
-5. Send `[KNOWLEDGE-READY]` to Lead
+5. If `signal_delivery` is `sendmessage`: send `[KNOWLEDGE-READY]` to Lead via inbox. If `signal_delivery` is `thread`: write `{story_output_dir}/knowledge-ready.md` as ready signal.
 
 ## Flakiness Awareness