@chllming/wave-orchestration 0.9.7 → 0.9.9

package/CHANGELOG.md

@@ -1,52 +1,71 @@
 # Changelog
 
-## Unreleased
+## 0.9.9 - 2026-04-07
+
+### Fixed
+- Helper assignment barrier is now advisory (non-blocking) in bootstrap gate mode. Previously, open helper assignments blocked wave closure even when the assigned agent completed successfully with exit 0, causing unnecessary retries. In bootstrap mode, assigned-but-open helper requests are downgraded to advisory warnings with statusCode `helper-assignment-open-advisory`. Unresolved assignments (no assignee) remain blocking in all gate modes.
+
+
+## 0.9.8 - 2026-04-06
+
+### Added
+- `wave self-update` command for in-place package upgrades with release notes display.
+- Upgrade history tracking in `.wave/upgrade-history/` with per-upgrade reports including workspace impact analysis and follow-up actions.
+- Bootstrap advisory gates: in bootstrap mode (waves 0–3), doc-closure, cont-QA, integration, and component gates are advisory (non-blocking) while implementation gates remain required. Advisory failures are tracked in the gate snapshot for visibility.
+- `docs/guides/recommendations-0.9.8.md` recommendations guide.
+
+### Fixed
+- Integration barrier now short-circuits when no A8 steward is declared (`agentId: null`), fixing `missing-integration-summary` failures on waves without an integration agent.
+- Default `claude.permissionMode` to `bypassPermissions` (fixes Docker container environments where interactive permission prompts hang).
+- Removed `--search` flag from codex exec invocations (unsupported by `codex exec`).
+- Relaxed release-surface test version checks while keeping changelog checks strict (#64).
+- Updated executor test — `--search` not supported in codex exec (#63).
+
+### Changed
+- `wave upgrade` now records install-state transitions and generates upgrade reports.
 
 ## 0.9.7 - 2026-04-06
 
 ### Fixed
-- Closure engine now skips missing-closure-run failures in bootstrap gate mode.
-- `gateModeThresholds` is now exposed on the `lanePaths` object for downstream consumers.
+- Closure engine now skips missing-closure-run failures when the resolved gate mode is `bootstrap`, allowing waves to pass when agents complete but tmux status reconciliation fails.
+- `gateModeThresholds` is now exposed on the `lanePaths` object so downstream consumers (closure engine, derived state) can resolve the active gate mode.
 
 ## 0.9.6 - 2026-04-05
 
 ### Fixed
-- Closure engine now respects `requireIntegrationStewardFromWave` and `requireDocumentationStewardFromWave` thresholds instead of unconditionally requiring integration/documentation closure runs.
+- Closure engine now respects `requireIntegrationStewardFromWave` and `requireDocumentationStewardFromWave` thresholds instead of unconditionally requiring integration/documentation steward runs for waves that don't declare them. When set to `null`, the stage is only required if the wave declares the corresponding agent.
 
 ## 0.9.5 - 2026-04-05
 
 ### Fixed
-- Pass `lanePaths` to `reconcileFailuresAgainstSharedComponentState` to fix `ReferenceError` crash on repos without Integration Steward (A8).
+- Pass `lanePaths` to `reconcileFailuresAgainstSharedComponentState`, fixing `ReferenceError` crash on repos without Integration Steward (A8).
 
 ## 0.9.4 - 2026-04-05
 
-- Laddered gate modes: bootstrap/standard/strict per wave number
-- Bootstrap pass: exit 0 + deliverables exist = advance (no QA signals needed)
-- Fix: requireDocumentationStewardFromWave threshold strictly respected
-- New config: gateModeThresholds, bootstrapPassConditions, testCommand
-- evaluateBootstrapGate() and resolveGateMode() functions
+### Added
+- Laddered gate modes: `bootstrap` (waves 0–3), `standard` (waves 4–9), `strict` (waves 10+) per wave number via `gateModeThresholds` config.
+- Bootstrap pass conditions: `exit 0 + deliverables exist = advance` — no QA signals required in early waves.
+- New config fields: `gateModeThresholds`, `bootstrapPassConditions`, `testCommand`.
+- `evaluateBootstrapGate()` and `resolveGateMode()` functions for gate-mode resolution.
+- `docs/guides/recommendations-0.9.4.md` recommendations guide.
+
+### Fixed
+- `requireDocumentationStewardFromWave` threshold now strictly respected during validation. Was previously OR'd with `componentPromotionRuleActive`, ignoring the threshold.
 
 ## 0.9.3 - 2026-03-30
 
 ### Fixed And Hardened
-
-- WAVE_GATE_REGEX now accepts gap alongside pass|concerns|blocked for all five gate dimensions (architecture, integration, durability, live, docs). Previously, agents that reported a documented gap (e.g. live=gap for an infrastructure topology constraint) had their marker rejected entirely, causing missing-wave-gate failures that prevented wave closure.
-- validateContQaSummary now treats gap dimension values as a conditional pass (ok: true, statusCode: conditional-pass) instead of a hard blocker, with detail text listing which dimensions have documented gaps.
-- The cont-QA coordination prompt now documents gap as a valid dimension value alongside pass|concerns|blocked.
+- `WAVE_GATE_REGEX` now accepts `gap` alongside `pass|concerns|blocked` for all five gate dimensions (architecture, integration, durability, live, docs). Previously, agents that reported a documented gap (e.g. `live=gap` for an infrastructure topology constraint) had their marker rejected entirely, causing missing-wave-gate failures that prevented wave closure.
+- `validateContQaSummary` now treats gap dimension values as a conditional pass (`ok: true`, `statusCode: conditional-pass`) instead of a hard blocker, with detail text listing which dimensions have documented gaps.
+- The cont-QA coordination prompt now documents `gap` as a valid dimension value alongside `pass|concerns|blocked`.
+- Migration sections aligned and install seeding updated to target 0.9.3 correctly.
+- Planner-agentic note added to 0.9.3 manifest entry.
 
 ### Added
-
-- First-time wave launch now auto-triggers wave project setup when no project profile exists, matching existing wave draft behavior. (Contributed by @justanothernate in #54)
-- wave project setup now shows descriptive help text before each prompt, explains all template and posture options inline, and adds whitespace between question groups for readability. (Contributed by @justanothernate in #54)
-- PromptSession gains a describe(text) method for writing contextual help to stderr during interactive setup flows.
-- parseArgs now passes the loaded config object through to runLauncherCli, avoiding a redundant loadWaveConfig() call.
-
-### Testing And Validation
-
-- `pnpm exec vitest run --config vitest.config.ts`
-- `node scripts/wave.mjs doctor --json`
-- `node scripts/wave.mjs launch --lane main --dry-run --no-dashboard`
-- `pnpm test -- test/wave-orchestrator/release-surface.test.ts`
+- First-time wave launch now auto-triggers `wave project setup` when no project profile exists, matching existing `wave draft` behavior.
+- `wave project setup` now shows descriptive help text before each prompt, explains all template and posture options inline, and adds whitespace between question groups for readability.
+- `PromptSession` gains a `describe(text)` method for writing contextual help to stderr during interactive setup flows.
+- `parseArgs` now passes the loaded config object through to `runLauncherCli`, avoiding a redundant `loadWaveConfig()` call.
 
 ## 0.9.2 - 2026-03-29
 
@@ -552,3 +571,12 @@
 
 - Initial generic wave orchestrator runtime.
 - Added Context7 bundle resolution and multi-executor support for Codex, Claude Code, and OpenCode.
+
+## 0.9.8 - 2026-04-06
+
+### Fixed
+- Gate engine: bootstrap mode treats doc-closure, cont-QA, integration, and component gates as advisory (non-blocking) while impl gates remain required
+- Gate engine: integration barrier short-circuits when no steward declared
+- Claude executor defaults permissionMode to bypassPermissions (fixes Docker containers)
+- Removed --search from codex exec invocations (unsupported by codex exec)
+- Advisory failures tracked in gate snapshot for operator visibility

package/docs/README.md

@@ -54,7 +54,11 @@ The useful path is journey-first:
 - Publishing the package:
   Read [reference/package-publishing-flow.md](./reference/package-publishing-flow.md) for the end-to-end release path, the GitHub publish workflows, the lifecycle scripts, and the verification or repair flow.
 - Want the practical `0.9.3` operating stance:
-  Read [guides/recommendations-0.9.7.md](./guides/recommendations-0.9.7.md) for the recommended default around relaxed blocker states, advisory turn budgets, and targeted recovery.
+  Read [guides/recommendations-0.9.7
+- [0.9.8 Operating Recommendations](guides/recommendations-0.9.8.md
+- [0.9.9 Recommendations](guides/recommendations-0.9.9.md)).md](./guides/recommendations-0.9.7
+- [0.9.8 Operating Recommendations](guides/recommendations-0.9.8.md
+- [0.9.9 Recommendations](guides/recommendations-0.9.9.md)).md) for the recommended default around relaxed blocker states, advisory turn budgets, and targeted recovery.
 - Want the concrete runtime module map:
   Read [plans/end-state-architecture.md](./plans/end-state-architecture.md) for the engine-by-engine architecture and artifact ownership model.
 - Want the CLI surface map:

package/docs/guides/recommendations-0.9.8.md

@@ -0,0 +1,137 @@
+---
+title: "0.9.8 Recommendations"
+summary: "How to use 0.9.8's softer blocker states, advisory turn budgets, and targeted recovery without weakening proof and closure."
+---
+
+# 0.9.8 Recommendations
+
+Use this guide when you are adopting `0.9.8` and want one practical operating stance for the softer blocker states, advisory turn-budget behavior, and targeted recovery flow that the current package line ships.
+
+## Recommended Default
+
+For most repos, the safest `0.9.8` default is:
+
+- bound work with `budget.minutes`
+- leave generic `budget.turns` as advisory metadata
+- author non-proof follow-up as `soft`, `stale`, or `advisory` instead of silently treating every open record as a hard blocker
+- use `resolve-policy` when the answer already exists in repo policy or shipped docs
+- prefer targeted rerun or resume after timeout, max-turn, rate-limit, or missing-status outcomes instead of relaunching the whole wave
+- in short-lived sandboxes, prefer `wave submit`, `wave supervise`, `wave status`, and `wave wait` instead of binding the full run to one client shell
+- when a wave-gate dimension has a documented gap that is not an actionable blocker, use `gap` instead of `pass` or `blocked` — the runtime treats it as a conditional pass
+
+That recommendation matches the runtime:
+
+- executor launch metadata only emits hard turn-limit flags from `claude.maxTurns` or `opencode.steps`
+- open `stale` and `advisory` coordination records stay visible without reopening the active blocking edge
+- recoverable launcher failures queue targeted retry state instead of immediately escalating to broad terminal wave failure
+
+## 1. Budgets
+
+Treat the two budget knobs differently:
+
+- `budget.minutes` is the primary attempt budget
+- generic `budget.turns` is only a planning hint
+- `claude.maxTurns` or `opencode.steps` are the hard runtime ceilings when you actually want deterministic turn stopping
+
+Recommended pattern for synthesis-heavy implementation or closure work:
+
+```json
+{
+  "executors": {
+    "profiles": {
+      "implementation-default": {
+        "id": "claude",
+        "model": "claude-sonnet-4-6",
+        "budget": {
+          "minutes": 35,
+          "turns": 12
+        }
+      }
+    }
+  }
+}
+```
+
+In that pattern, `35` minutes is real policy. `12` turns is only guidance for planning and preview metadata.
+
+Only set a hard runtime ceiling when you deliberately want the runtime itself to stop:
+
+```json
+{
+  "executors": {
+    "profiles": {
+      "bounded-closure": {
+        "id": "claude",
+        "model": "claude-sonnet-4-6",
+        "budget": {
+          "minutes": 20
+        },
+        "claude": {
+          "maxTurns": 6
+        }
+      }
+    }
+  }
+}
+```
+
+## 2. Softer Coordination States
+
+`0.9.2` keeps “still visible” separate from “still blocking”.
+
+Use these states intentionally:
+
+| State | Use it for | What the runtime does |
+| --- | --- | --- |
+| `soft` | follow-up that still matters but should not be treated like proof failure | remains visible and may still drive repair or retry targeting |
+| `stale` | outdated clarification or blocker context kept for history | visible in control state, but does not reopen blocking by itself |
+| `advisory` | known issue, note, or human context that should stay visible without blocking closure | visible in control state, but does not own the active blocking edge |
+
+Practical command paths:
+
+```bash
+pnpm exec wave control task act defer --lane main --wave 10 --id blocker-doc-follow-up
+pnpm exec wave control task act mark-stale --lane main --wave 10 --id clarify-a7-rollout
+pnpm exec wave control task act mark-advisory --lane main --wave 10 --id request-clarify-a7-rollout
+pnpm exec wave control task act resolve-policy --lane main --wave 10 --id clarify-a7-rollout --detail "Policy already covered in the rollout guide."
+```
+
+Use them when the repo already knows the answer, the remaining item is informational, or the follow-up should stay visible for the next wave without holding the current wave hostage.
+
+## 3. What Should Stay Hard
+
+Do not relax everything.
+
+Keep these hard or closure-critical unless you are intentionally changing wave policy:
+
+- missing proof or required deliverables
+- failed integration, documentation, or cont-QA closure gates
+- real human-feedback or escalation requirements that block safe continuation
+- requests or clarifications that still represent unresolved ownership or policy ambiguity for the current wave
+
+Use `gap` in wave-gate markers when a dimension has a documented gap that is not actionable in the current wave. For example, `live=gap` is appropriate when an infrastructure topology constraint prevents full live validation but the constraint is known, documented, and does not represent a regression. Do not use `gap` to hide actual failures or unreviewed work.
+
+If the current wave cannot truthfully close without the answer, keep it blocking.
+
+## 4. Recovery Recommendation
+
+My recommendation after reviewing the current `0.9.8` code path is:
+
+- let timeout, max-turn, rate-limit, and missing-status failures go through the built-in targeted recovery path first
+- inspect the queued rerun or resume request before manually relaunching the whole wave
+- preserve reusable proof from successful sibling owners whenever the reducer already identified it as reusable
+
+That is the shape the launcher now prefers. It only broadens failure when the remaining blockers are still proof-critical or otherwise non-recoverable.
+
+## 5. Suggested Operator Policy
+
+For most repo-owned runbooks:
+
+- teach authors to use `budget.minutes` first
+- teach operators to downgrade only non-proof follow-up
+- treat `resolve-policy` as the preferred path when the answer already exists in docs or repo policy
+- escalate to a full-wave rerun only after targeted recovery proves insufficient
+
+If you want a single sentence policy:
+
+> Keep proof and closure strict, keep generic turns advisory, and keep non-proof context visible without letting it accidentally own wave closure.

package/docs/guides/recommendations-0.9.9.md

@@ -0,0 +1,137 @@
+---
+title: "0.9.9 Recommendations"
+summary: "How to use 0.9.9's softer blocker states, advisory turn budgets, and targeted recovery without weakening proof and closure."
+---
+
+# 0.9.9 Recommendations
+
+Use this guide when you are adopting `0.9.9` and want one practical operating stance for the softer blocker states, advisory turn-budget behavior, and targeted recovery flow that the current package line ships.
+
+## Recommended Default
+
+For most repos, the safest `0.9.9` default is:
+
+- bound work with `budget.minutes`
+- leave generic `budget.turns` as advisory metadata
+- author non-proof follow-up as `soft`, `stale`, or `advisory` instead of silently treating every open record as a hard blocker
+- use `resolve-policy` when the answer already exists in repo policy or shipped docs
+- prefer targeted rerun or resume after timeout, max-turn, rate-limit, or missing-status outcomes instead of relaunching the whole wave
+- in short-lived sandboxes, prefer `wave submit`, `wave supervise`, `wave status`, and `wave wait` instead of binding the full run to one client shell
+- when a wave-gate dimension has a documented gap that is not an actionable blocker, use `gap` instead of `pass` or `blocked` — the runtime treats it as a conditional pass
+
+That recommendation matches the runtime:
+
+- executor launch metadata only emits hard turn-limit flags from `claude.maxTurns` or `opencode.steps`
+- open `stale` and `advisory` coordination records stay visible without reopening the active blocking edge
+- recoverable launcher failures queue targeted retry state instead of immediately escalating to broad terminal wave failure
+
+## 1. Budgets
+
+Treat the two budget knobs differently:
+
+- `budget.minutes` is the primary attempt budget
+- generic `budget.turns` is only a planning hint
+- `claude.maxTurns` or `opencode.steps` are the hard runtime ceilings when you actually want deterministic turn stopping
+
+Recommended pattern for synthesis-heavy implementation or closure work:
+
+```json
+{
+  "executors": {
+    "profiles": {
+      "implementation-default": {
+        "id": "claude",
+        "model": "claude-sonnet-4-6",
+        "budget": {
+          "minutes": 35,
+          "turns": 12
+        }
+      }
+    }
+  }
+}
+```
+
+In that pattern, `35` minutes is real policy. `12` turns is only guidance for planning and preview metadata.
+
+Only set a hard runtime ceiling when you deliberately want the runtime itself to stop:
+
+```json
+{
+  "executors": {
+    "profiles": {
+      "bounded-closure": {
+        "id": "claude",
+        "model": "claude-sonnet-4-6",
+        "budget": {
+          "minutes": 20
+        },
+        "claude": {
+          "maxTurns": 6
+        }
+      }
+    }
+  }
+}
+```
+
+## 2. Softer Coordination States
+
+`0.9.2` keeps “still visible” separate from “still blocking”.
+
+Use these states intentionally:
+
+| State | Use it for | What the runtime does |
+| --- | --- | --- |
+| `soft` | follow-up that still matters but should not be treated like proof failure | remains visible and may still drive repair or retry targeting |
+| `stale` | outdated clarification or blocker context kept for history | visible in control state, but does not reopen blocking by itself |
+| `advisory` | known issue, note, or human context that should stay visible without blocking closure | visible in control state, but does not own the active blocking edge |
+
+Practical command paths:
+
+```bash
+pnpm exec wave control task act defer --lane main --wave 10 --id blocker-doc-follow-up
+pnpm exec wave control task act mark-stale --lane main --wave 10 --id clarify-a7-rollout
+pnpm exec wave control task act mark-advisory --lane main --wave 10 --id request-clarify-a7-rollout
+pnpm exec wave control task act resolve-policy --lane main --wave 10 --id clarify-a7-rollout --detail "Policy already covered in the rollout guide."
+```
+
+Use them when the repo already knows the answer, the remaining item is informational, or the follow-up should stay visible for the next wave without holding the current wave hostage.
+
+## 3. What Should Stay Hard
+
+Do not relax everything.
+
+Keep these hard or closure-critical unless you are intentionally changing wave policy:
+
+- missing proof or required deliverables
+- failed integration, documentation, or cont-QA closure gates
+- real human-feedback or escalation requirements that block safe continuation
+- requests or clarifications that still represent unresolved ownership or policy ambiguity for the current wave
+
+Use `gap` in wave-gate markers when a dimension has a documented gap that is not actionable in the current wave. For example, `live=gap` is appropriate when an infrastructure topology constraint prevents full live validation but the constraint is known, documented, and does not represent a regression. Do not use `gap` to hide actual failures or unreviewed work.
+
+If the current wave cannot truthfully close without the answer, keep it blocking.
+
+## 4. Recovery Recommendation
+
+My recommendation after reviewing the current `0.9.9` code path is:
+
+- let timeout, max-turn, rate-limit, and missing-status failures go through the built-in targeted recovery path first
+- inspect the queued rerun or resume request before manually relaunching the whole wave
+- preserve reusable proof from successful sibling owners whenever the reducer already identified it as reusable
+
+That is the shape the launcher now prefers. It only broadens failure when the remaining blockers are still proof-critical or otherwise non-recoverable.
+
+## 5. Suggested Operator Policy
+
+For most repo-owned runbooks:
+
+- teach authors to use `budget.minutes` first
+- teach operators to downgrade only non-proof follow-up
+- treat `resolve-policy` as the preferred path when the answer already exists in docs or repo policy
+- escalate to a full-wave rerun only after targeted recovery proves insufficient
+
+If you want a single sentence policy:
+
+> Keep proof and closure strict, keep generic turns advisory, and keep non-proof context visible without letting it accidentally own wave closure.

package/docs/plans/migration.md

@@ -1,6 +1,6 @@
 # Migration
 
-This page is the practical repo-upgrade guide for the current `0.9.7` surface.
+This page is the practical repo-upgrade guide for the current `0.9.9` surface.
 
 Use it when you are:
 
@@ -24,7 +24,7 @@ The `0.9.4` surface adds laddered gate modes and fixes the steward threshold enf
 
 ## What `0.9.4` Changes
 
-The current `0.9.7` surface keeps everything from `0.9.2` and adds two focused improvements with no breaking changes.
+The current `0.9.9` surface keeps everything from `0.9.2` and adds two focused improvements with no breaking changes.
 
 The practical changes are:
 
@@ -182,7 +182,7 @@ Use `pnpm exec wave dashboard --lane <lane> --attach current` or `--attach globa
 
 ## `0.9.4` Release Model
 
-The current `0.9.7` surface combines these strands:
+The current `0.9.9` surface combines these strands:
 
 - the gap-value wave-gate fix and first-time setup UX improvements released in `0.9.4`
 - the detached process-runner and sandbox supervisor hardening released in `0.9.2`
@@ -367,7 +367,11 @@ If your repo copied starter config defaults, also sync the `designRolePromptPath
 - hybrid design stewards rejoin implementation when they explicitly own code
 - long-running prompts receive signal-state and ack paths when the repo uses the new waiting model
 
-## Upgrading From `0.8.3` To `0.9.7`
+## Upgrading From `0.9.8` To `0.9.9`
+
+Helper assignment barriers are now advisory in bootstrap gate mode. No config changes needed.
+
+## Upgrading From `0.8.3` To `0.9.9`
 
 Treat this as one move to the current `0.9.2` surface.
 
@@ -402,7 +406,7 @@ If your repo copied starter docs or skills, sync:
 - dry-run one design-steward wave if the repo wants the new authored surface
 - if the repo uses long-running watcher agents or shell automation, validate `scripts/wave-status.sh` and `scripts/wave-watch.sh` against a live or staged lane
 
-## Upgrading From `0.6.x` Or `0.7.x` To `0.9.7`
+## Upgrading From `0.6.x` Or `0.7.x` To `0.9.9`
 
 This is the main migration path for older adopted repos.
 
@@ -553,4 +557,4 @@ For repos that depend on replay parity, replay at least:
 
 ## Summary
 
-The current `0.9.7` surface keeps the same authority-set and phase-engine architecture, ships both the design-role starter surface and the signal-driven long-running-agent starter surface, keeps the `0.8.7` policy and routing hardening, and now also packages the practical operator recommendations guide inside the release line. For most repos already on `0.8.x`, the upgrade is package bump plus validation. For older adopted repos, the real work is syncing repo-owned prompts, skills, planner corpus, wrapper scripts, and runbooks so they describe the runtime the package now ships.
+The current `0.9.9` surface keeps the same authority-set and phase-engine architecture, ships both the design-role starter surface and the signal-driven long-running-agent starter surface, keeps the `0.8.7` policy and routing hardening, and now also packages the practical operator recommendations guide inside the release line. For most repos already on `0.8.x`, the upgrade is package bump plus validation. For older adopted repos, the real work is syncing repo-owned prompts, skills, planner corpus, wrapper scripts, and runbooks so they describe the runtime the package now ships.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chllming/wave-orchestration",
-  "version": "0.9.7",
+  "version": "0.9.9",
   "license": "MIT",
   "description": "Generic wave-based multi-agent orchestration for repository work.",
   "repository": {

package/releases/manifest.json

@@ -2,6 +2,17 @@
   "schemaVersion": 1,
   "packageName": "@chllming/wave-orchestration",
   "releases": [
+    {
+      "version": "0.9.9",
+      "date": "2026-04-07",
+      "summary": "Helper assignment barrier is advisory in bootstrap gate mode; planner-agentic bundle remains available.",
+      "features": [
+        "Helper assignment barrier is now advisory (non-blocking) in bootstrap gate mode, preventing unnecessary retries when assigned agents complete successfully.",
+        "planner-agentic bundle placeholder remains available for adopted repos."
+      ],
+      "manualSteps": [],
+      "breaking": false
+    },
     {
       "version": "0.9.7",
       "date": "2026-04-06",
@@ -590,4 +601,4 @@
       "breaking": false
     }
   ]
-}
+}

package/scripts/wave-orchestrator/config.mjs

@@ -1080,7 +1080,7 @@ function normalizeExecutors(rawExecutors = {}) {
       appendSystemPromptMode: normalizeClaudePromptMode(
         executors.claude?.appendSystemPromptMode,
       ),
-      permissionMode: normalizeOptionalString(executors.claude?.permissionMode, null),
+      permissionMode: normalizeOptionalString(executors.claude?.permissionMode, "bypassPermissions"),
       permissionPromptTool: normalizeOptionalString(
         executors.claude?.permissionPromptTool,
         null,

package/scripts/wave-orchestrator/executors.mjs

@@ -193,7 +193,6 @@ export function buildCodexExecInvocation(
   appendSingleValueFlag(tokens, "--model", options.model);
   appendSingleValueFlag(tokens, "--profile", options.profileName);
   appendRepeatedFlag(tokens, "-c", options.config);
-  appendBooleanFlag(tokens, "--search", options.search);
   appendRepeatedFlag(tokens, "--image", options.images);
   appendRepeatedFlag(tokens, "--add-dir", options.addDirs);
   appendBooleanFlag(tokens, "--json", options.json);

package/scripts/wave-orchestrator/gate-engine.mjs

@@ -1138,7 +1138,8 @@ export function readClarificationBarrier(derivedState) {
   };
 }
 
-export function readWaveAssignmentBarrier(derivedState) {
+export function readWaveAssignmentBarrier(derivedState, options) {
+  const gateMode = options?.gateMode || null;
   const blockingAssignments = (derivedState?.capabilityAssignments || []).filter(
     (assignment) => assignment.blocking,
   );
@@ -1157,6 +1158,13 @@ export function readWaveAssignmentBarrier(derivedState) {
       detail: `Helper assignments remain unresolved (${unresolvedAssignments.map((assignment) => assignment.requestId).join(", ")}).`,
     };
   }
+  if (gateMode === "bootstrap") {
+    return {
+      ok: true,
+      statusCode: "helper-assignment-open-advisory",
+      detail: `Helper assignments remain open but are advisory in bootstrap gate mode (${blockingAssignments.map((assignment) => assignment.requestId).join(", ")}).`,
+    };
+  }
   return {
     ok: false,
     statusCode: "helper-assignment-open",
@@ -1552,6 +1560,8 @@ export function buildGateSnapshotPure({ wave, agentResults, derivedState, valida
   });
   const integrationBarrier = (() => {
     if (!integrationMarkerGate.ok) { return integrationMarkerGate; }
+    // Short-circuit: no integration steward declared and not required
+    if (!integrationMarkerGate.agentId) { return integrationMarkerGate; }
     const integrationSummary = derivedState?.integrationSummary || null;
     if (!integrationSummary) {
       return { ok: false, agentId: integrationMarkerGate.agentId,
@@ -1602,16 +1612,33 @@ export function buildGateSnapshotPure({ wave, agentResults, derivedState, valida
     ["componentMatrixGate", componentMatrixGate], ["contQaGate", contQaGate],
     ["infraGate", infraGate], ["clarificationBarrier", clarificationBarrier],
   ];
-  const firstFailure = orderedGates.find(([, gate]) => gate?.ok === false);
+  const gateMode = laneConfig.gateMode || "strict";
+  // In bootstrap mode, these gates are advisory (non-blocking)
+  const bootstrapAdvisoryGates = new Set([
+    "documentationGate", "contQaGate", "integrationBarrier",
+    "componentMatrixGate", "componentGate",
+  ]);
+  const firstFailure = orderedGates.find(([name, gate]) => {
+    if (!gate || gate.ok !== false) return false;
+    if (gateMode === "bootstrap" && bootstrapAdvisoryGates.has(name)) return false;
+    return true;
+  });
+  const advisoryFailures = gateMode === "bootstrap"
+    ? orderedGates.filter(([name, gate]) => gate?.ok === false && bootstrapAdvisoryGates.has(name))
+    : [];
   return {
     designGate, implementationGate, componentGate, integrationGate: integrationMarkerGate,
     integrationBarrier, documentationGate, componentMatrixGate,
     contEvalGate, securityGate, contQaGate, infraGate,
     clarificationBarrier, helperAssignmentBarrier, dependencyBarrier,
+    gateMode,
+    advisoryFailures: advisoryFailures.map(([name, gate]) => ({ gate: name, ...gate })),
     overall: firstFailure
       ? { ok: false, gate: firstFailure[0], statusCode: firstFailure[1].statusCode,
           detail: firstFailure[1].detail, agentId: firstFailure[1].agentId || null }
       : { ok: true, gate: "pass", statusCode: "pass",
-          detail: "All replayed wave gates passed.", agentId: null },
+          detail: gateMode === "bootstrap"
+            ? `Bootstrap pass: impl gates passed (${advisoryFailures.length} advisory).`
+            : "All replayed wave gates passed.", agentId: null },
   };
 }

package/scripts/wave-orchestrator/wave-state-reducer.mjs

@@ -19,6 +19,7 @@ import {
   buildGateSnapshotPure,
   readClarificationBarrier,
   readWaveAssignmentBarrier,
+  resolveGateMode,
 } from "./gate-engine.mjs";
 import { buildHumanInputRequests } from "./human-input-workflow.mjs";
 import { projectLegacySummaryFromEnvelope } from "./result-envelope.mjs";
@@ -713,7 +714,9 @@ export function reduceWaveState({
     Array.isArray(waveDefinition?.agents) ? waveDefinition.agents : [],
     laneConfig.capabilityRouting || {},
   );
-  const helperAssignmentBarrier = readWaveAssignmentBarrier({ capabilityAssignments });
+  const _reducerGateThresholds = laneConfig?.gateModeThresholds || laneConfig?.validation?.gateModeThresholds || null;
+  const _reducerGateMode = resolveGateMode(waveDefinition?.wave || 0, _reducerGateThresholds);
+  const helperAssignmentBarrier = readWaveAssignmentBarrier({ capabilityAssignments }, { gateMode: _reducerGateMode });
   const dependencyBarrier = (() => {
     if (!dependencyTickets) {
       return { ok: true, statusCode: "pass", detail: "" };