@chllming/wave-orchestration 0.9.0 → 0.9.2

package/docs/reference/npmjs-token-publishing.md

@@ -0,0 +1,53 @@
+# npmjs Token Publishing
+
+This repo now includes a dedicated npmjs publish workflow at [publish-npm.yml](../../.github/workflows/publish-npm.yml).
+
+The current `0.9.2` release procedure publishes through a repository Actions secret named `NPM_TOKEN`.
+
+## What This Repo Already Does
+
+- `package.json` no longer hardcodes GitHub Packages as the publish registry.
+- `publish-npm.yml` publishes tagged releases to `https://registry.npmjs.org`.
+- `publish-package.yml` still publishes to GitHub Packages explicitly, so both registries can coexist.
+- `publish-npm.yml` expects `NPM_TOKEN` in GitHub Actions secrets.
+- The public install path is already npmjs; GitHub Packages remains the authenticated fallback path.
+
+## One-Time npm Setup
+
+1. Create an npm granular access token with:
+   - package or scope access for `@chllming/wave-orchestration`
+   - `Read and write` permission
+   - `Bypass 2FA` enabled
+2. In the GitHub repo `chllming/agent-wave-orchestrator`, add that token as an Actions secret named `NPM_TOKEN`.
+3. Rotate or revoke the token when no longer needed.
+
+## GitHub Workflow Behavior
+
+The npmjs workflow:
+
+- runs on GitHub-hosted runners
+- requires `contents: read`
+- installs dependencies with `pnpm install --frozen-lockfile`
+- runs `pnpm test`
+- publishes with `pnpm publish --access public --no-git-checks`
+- authenticates with `NODE_AUTH_TOKEN=${{ secrets.NPM_TOKEN }}`
+
+## Security Follow-Up
+
+After a successful npm publish:
+
+1. Keep the token scoped only to this package or scope.
+2. Rotate the token periodically.
+3. Revoke emergency or temporary tokens once they are no longer needed.
+
+If this repo later needs private npm dependencies during CI, consider a separate read-only install token rather than reusing the publish token.
+
+## Release Checklist
+
+1. Confirm [publish-npm.yml](../../.github/workflows/publish-npm.yml) is on the default branch.
+2. Confirm `NPM_TOKEN` exists in the GitHub repo secrets.
+3. Confirm the package version has been bumped and committed.
+4. Confirm `README.md`, `CHANGELOG.md`, `releases/manifest.json`, and `docs/plans/migration.md` all describe the same release surface.
+5. Push the release commit and release tag, for example `v0.9.2`.
+6. Verify both `publish-npm.yml` and `publish-package.yml` start from the tag push.
+7. Verify the npmjs publish completes successfully for the tagged source.

package/docs/reference/npmjs-trusted-publishing.md

@@ -1,53 +1,7 @@
-# npmjs Publishing
+# npmjs Trusted Publishing
 
-This repo now includes a dedicated npmjs publish workflow at [publish-npm.yml](../../.github/workflows/publish-npm.yml).
+This repo does not currently use npm trusted publishing or OIDC-based publish credentials.
 
-The current `0.9.0` release procedure publishes through a repository Actions secret named `NPM_TOKEN`.
+The live npmjs workflow is token-based and documented in [npmjs-token-publishing.md](./npmjs-token-publishing.md).
 
-## What This Repo Already Does
-
-- `package.json` no longer hardcodes GitHub Packages as the publish registry.
-- `publish-npm.yml` publishes tagged releases to `https://registry.npmjs.org`.
-- `publish-package.yml` still publishes to GitHub Packages explicitly, so both registries can coexist.
-- `publish-npm.yml` expects `NPM_TOKEN` in GitHub Actions secrets.
-- The public install path is already npmjs; GitHub Packages remains the authenticated fallback path.
-
-## One-Time npm Setup
-
-1. Create an npm granular access token with:
-   - package or scope access for `@chllming/wave-orchestration`
-   - `Read and write` permission
-   - `Bypass 2FA` enabled
-2. In the GitHub repo `chllming/agent-wave-orchestrator`, add that token as an Actions secret named `NPM_TOKEN`.
-3. Rotate or revoke the token when no longer needed.
-
-## GitHub Workflow Behavior
-
-The npmjs workflow:
-
-- runs on GitHub-hosted runners
-- requires `contents: read`
-- installs dependencies with `pnpm install --frozen-lockfile`
-- runs `pnpm test`
-- publishes with `pnpm publish --access public --no-git-checks`
-- authenticates with `NODE_AUTH_TOKEN=${{ secrets.NPM_TOKEN }}`
-
-## Security Follow-Up
-
-After a successful npm publish:
-
-1. Keep the token scoped only to this package or scope.
-2. Rotate the token periodically.
-3. Revoke emergency or temporary tokens once they are no longer needed.
-
-If this repo later needs private npm dependencies during CI, consider a separate read-only install token rather than reusing the publish token.
-
-## Release Checklist
-
-1. Confirm [publish-npm.yml](../../.github/workflows/publish-npm.yml) is on the default branch.
-2. Confirm `NPM_TOKEN` exists in the GitHub repo secrets.
-3. Confirm the package version has been bumped and committed.
-4. Confirm `README.md`, `CHANGELOG.md`, `releases/manifest.json`, and `docs/plans/migration.md` all describe the same release surface.
-5. Push the release commit and release tag, for example `v0.9.0`.
-6. Verify both `publish-npm.yml` and `publish-package.yml` start from the tag push.
-7. Verify the npmjs publish completes successfully for the tagged source.
+If this repo later migrates to trusted publishing, replace this compatibility stub with the real OIDC procedure in the same change as the workflow update.

package/docs/reference/package-publishing-flow.md

@@ -0,0 +1,272 @@
+# Package Publishing Flow
+
+This document describes how this repo publishes `@chllming/wave-orchestration` end to end, including the scripts, workflows, release artifacts, and verification steps involved.
+
+## Overview
+
+The package publish flow has two layers:
+
+1. repo-owned release preparation
+2. tag-triggered registry publishing
+
+Release preparation happens in the repository itself:
+
+- bump `package.json`
+- update release-surface docs and fixtures
+- validate the repo
+- merge the release changes to `main`
+- push a version tag such as `v0.9.2`
+
+Registry publishing happens in GitHub Actions after the tag push:
+
+- [publish-npm.yml](../../.github/workflows/publish-npm.yml) publishes to npmjs
+- [publish-package.yml](../../.github/workflows/publish-package.yml) publishes to GitHub Packages
+- [npmjs-token-publishing.md](./npmjs-token-publishing.md) documents the npm token setup used by `publish-npm.yml`
+
+Both workflows run on tag pushes matching `v*`, and each workflow now fails fast unless `github.ref_name` exactly matches `v${package.json.version}`.
+
+## Release Artifacts That Move Together
+
+These files are part of the release surface and should be updated in the same change when the package version changes:
+
+- `package.json`
+- `README.md`
+- `CHANGELOG.md`
+- `docs/README.md`
+- `docs/plans/current-state.md`
+- `docs/plans/migration.md`
+- `docs/guides/sandboxed-environments.md`
+- `docs/reference/coordination-and-closure.md`
+- `docs/reference/runtime-config/README.md`
+- `releases/manifest.json`
+- `.wave/install-state.json`
+- tracked `.wave/upgrade-history/*`
+- versioned docs such as `docs/guides/recommendations-<version>.md`
+- `AGENTS.md`
+
+This repo treats those files as part of the package-facing release contract, not just internal documentation.
+
+## Scripts And Commands Involved
+
+### Main CLI entrypoint
+
+- `scripts/wave.mjs`
+  Routes install and lifecycle commands into `scripts/wave-orchestrator/install.mjs`.
+
+The lifecycle commands relevant to publishing are:
+
+- `wave doctor`
+- `wave changelog`
+- `wave upgrade`
+- `wave self-update`
+
+### Install and release-state module
+
+- `scripts/wave-orchestrator/install.mjs`
+
+This module owns the local package-lifecycle surfaces:
+
+- `wave init`
+  Seeds or adopts starter workspace files.
+- `wave doctor`
+  Validates that the current workspace matches the installed package expectations.
+- `wave changelog`
+  Reads `releases/manifest.json` and prints release notes.
+- `wave upgrade`
+  Writes `.wave/install-state.json` and a markdown/json report into `.wave/upgrade-history/`.
+- `wave self-update`
+  Updates the dependency in the target workspace, prints changelog deltas, and then runs `wave upgrade`.
+
+### Release-validation commands
+
+These are the normal validation commands before tagging:
+
+```bash
+pnpm test
+pnpm test -- test/wave-orchestrator/release-surface.test.ts
+node scripts/wave.mjs doctor --json
+node scripts/wave.mjs launch --lane main --dry-run --no-dashboard
+```
+
+### Registry verification commands
+
+After publish:
+
+```bash
+npm view @chllming/wave-orchestration version dist-tags --json
+gh run list --limit 10
+```
+
+## End-to-End Flow
+
+### 1. Prepare the release change
+
+Update the release artifacts together, then validate locally.
+
+Typical local flow:
+
+```bash
+pnpm test -- test/wave-orchestrator/release-surface.test.ts
+node scripts/wave.mjs doctor --json
+node scripts/wave.mjs launch --lane main --dry-run --no-dashboard
+```
+
+If the version changed, also refresh the tracked workspace lifecycle state:
+
+```bash
+pnpm exec wave upgrade
+pnpm exec wave changelog --since-installed
+```
+
+In this source repo, `.wave/install-state.json` and tracked `.wave/upgrade-history/` records are intentionally part of the release surface.
+
+### 2. Merge the release change to `main`
+
+This repository protects `main`, so release changes must land through a pull request rather than a direct push.
+
+Typical git flow:
+
+```bash
+git checkout -b release/0.9.2
+git push -u origin release/0.9.2
+gh pr create --base main --head release/0.9.2
+gh pr merge <pr-number> --merge --delete-branch
+```
+
+### 3. Push the release tag
+
+After the release commit is on `main`, push the version tag:
+
+```bash
+git tag v0.9.2
+git push origin v0.9.2
+```
+
+That tag push is the event that starts both publishing workflows.
+
+The tag must match the checked-in package version exactly. Example: if `package.json.version` is `0.9.2`, the pushed tag must be `v0.9.2`.
+
+## GitHub Actions Workflows
+
+### npmjs publish
+
+- workflow: [publish-npm.yml](../../.github/workflows/publish-npm.yml)
+- trigger: push tags matching `v*`
+- runtime: Node 22
+- auth secret: `NPM_TOKEN`
+- publish command:
+
+```bash
+pnpm publish --access public --no-git-checks
+```
+
+The workflow does:
+
+1. `actions/checkout`
+2. `pnpm/action-setup`
+3. `actions/setup-node` with `registry-url: https://registry.npmjs.org`
+4. verify `github.ref_name === "v" + package.json.version`
+5. `pnpm install --frozen-lockfile`
+6. `pnpm test`
+7. `pnpm publish --access public --no-git-checks`
+
+### GitHub Packages publish
+
+- workflow: [publish-package.yml](../../.github/workflows/publish-package.yml)
+- trigger: push tags matching `v*`
+- runtime: Node 22
+- auth token: `GITHUB_TOKEN`
+- publish command:
+
+```bash
+pnpm publish --registry=https://npm.pkg.github.com --no-git-checks
+```
+
+The workflow does:
+
+1. `actions/checkout`
+2. `pnpm/action-setup`
+3. `actions/setup-node` with `registry-url: https://npm.pkg.github.com`
+4. verify `github.ref_name === "v" + package.json.version`
+5. `pnpm install --frozen-lockfile`
+6. `pnpm test`
+7. `pnpm publish --registry=https://npm.pkg.github.com --no-git-checks`
+
+## Verification After Tag Push
+
+Use GitHub Actions first:
+
+```bash
+gh run list --limit 10 --json workflowName,headBranch,headSha,status,conclusion,url
+gh run watch <run-id> --exit-status
+gh run view <run-id> --log-failed
+```
+
+Then verify the public registry:
+
+```bash
+npm view @chllming/wave-orchestration version dist-tags --json
+```
+
+Expected result after a successful publish:
+
+```json
+{
+  "version": "0.9.2",
+  "dist-tags": {
+    "latest": "0.9.2"
+  }
+}
+```
+
+## Repair Flow When Publish Fails
+
+If a tag-triggered publish fails before the package is actually published, the fastest repair path is:
+
+1. fix the repo issue in a new commit
+2. move the tag to the fixed commit
+3. force-push the tag
+4. watch the rerun
+
+Example:
+
+```bash
+git tag -f v0.9.2 <fixed-commit>
+git push origin refs/tags/v0.9.2 --force
+```
+
+Use that only before the package is live on npmjs. Once npmjs has accepted a version, do not try to republish the same version; cut a new version instead.
+
+Common failure classes:
+
+- release-surface drift
+  A versioned doc or fixture did not move with `package.json`.
+- workflow-environment drift
+  The CI runtime differs from the runtime that was locally validated.
+- missing secrets
+  `NPM_TOKEN` is missing or invalid for npmjs.
+- test assumptions on ignored files
+  CI cannot see local-only workstation files such as `.vscode/terminals.json`.
+
+## Security And Secrets
+
+For npmjs publishing:
+
+- keep `NPM_TOKEN` scoped as narrowly as possible
+- use `Read and write` only for the target package or scope
+- rotate the token periodically
+- revoke temporary or emergency tokens after use
+
+GitHub Packages publishing uses the workflow `GITHUB_TOKEN`, so it does not require a separate package-publish secret.
+
+## What This Flow Does Not Do
+
+There is no dedicated local `release` shell script in this repo that bumps versions, tags commits, and publishes in one command.
+
+The flow today is intentionally split:
+
+- repo release preparation is explicit and reviewable
+- package lifecycle state is recorded by `wave upgrade`
+- actual registry publishing is delegated to tag-triggered GitHub Actions
+
+That split keeps release metadata, workspace upgrade history, and package publication visible and auditable.

package/docs/reference/runtime-config/README.md

@@ -8,6 +8,7 @@ Use it when you need the full supported surface for:
 - `defaultProject` and `projects.<projectId>`
 - `lanes.<lane>.executors`
 - `waveControl`
+- `externalProviders`
 - `executors.profiles.<profile>`
 - per-agent `### Executor` blocks inside a wave file
 
@@ -190,7 +191,7 @@ Practical guidance:
 - prefer `budget.minutes` for normal synthesis, integration, and closure work
 - use generic `budget.turns` as a planning hint, not a hard failure trigger
 - only set `claude.maxTurns` or `opencode.steps` when you deliberately want a hard ceiling for that runtime
-- see [../../guides/recommendations-0.9.0.md](../../guides/recommendations-0.9.0.md) for the recommended `0.9.0` operating stance that combines advisory turn budgets with softer non-proof coordination states
+- see [../../guides/recommendations-0.9.2.md](../../guides/recommendations-0.9.2.md) for the recommended `0.9.2` operating stance that combines advisory turn budgets with softer non-proof coordination states
 
 ## Runtime Pages
 
@@ -202,7 +203,7 @@ Practical guidance:
 
 `wave.config.json` may also declare a `waveControl` block for local-first telemetry delivery.
 
-Packaged defaults in `@chllming/wave-orchestration@0.9.0`:
+Packaged defaults in `@chllming/wave-orchestration@0.9.2`:
 
 - `endpoint`: `https://wave-control.up.railway.app/api/v1`
 - `reportMode`: `metadata-only`
@@ -219,7 +220,10 @@ Supported top-level fields:
 | `endpoint` | string | `https://wave-control.up.railway.app/api/v1` | Base URL for the Railway-hosted `services/wave-control` API |
 | `workspaceId` | string | derived from repo path | Stable workspace identity used across runs |
 | `projectId` | string | resolved project id | Stable project identity used for cross-workspace reporting and filtering |
-| `authTokenEnvVar` | string | `WAVE_CONTROL_AUTH_TOKEN` | Environment variable name holding the bearer token |
+| `authTokenEnvVar` | string | `WAVE_API_TOKEN` | Primary environment variable name holding the bearer token |
+| `authTokenEnvVars` | string[] | `["WAVE_API_TOKEN", "WAVE_CONTROL_AUTH_TOKEN"]` | Ordered fallback env var list consulted when Wave resolves a bearer token for owned Wave Control routes |
+| `credentialProviders` | string[] | `[]` | Allowlisted runtime credential leases requested from an owned Wave Control deployment before executor launch. Supported values: `openai`, `anthropic` |
+| `credentials` | `{ id, envVar }[]` | `[]` | Arbitrary per-user credential leases requested from an owned Wave Control deployment before executor launch |
 | `reportMode` | string | `metadata-only` | `disabled`, `metadata-only`, `metadata-plus-selected`, or `full-artifact-upload` |
 | `uploadArtifactKinds` | string[] | selected proof/trace/benchmark kinds | Artifact classes eligible for body upload when an artifact's upload policy requests a body |
 | `requestTimeoutMs` | integer | `5000` | Per-batch network timeout |
@@ -232,6 +236,8 @@ Supported top-level fields:
 
 Lane overrides may refine the same keys under `lanes.<lane>.waveControl` or `projects.<projectId>.lanes.<lane>.waveControl`.
 
+Wave resolves the Wave Control bearer token from `authTokenEnvVars` when that list is present. Otherwise it resolves `authTokenEnvVar` first and keeps `WAVE_CONTROL_AUTH_TOKEN` as a compatibility fallback.
+
 One-run override:
 
 - `wave launch --no-telemetry` disables Wave Control queueing and remote delivery for that launcher invocation without changing the repo config.
@@ -246,6 +252,8 @@ Example:
     "endpoint": "https://wave-control.up.railway.app/api/v1",
     "workspaceId": "wave-main",
     "projectId": "app",
+    "credentialProviders": ["openai"],
+    "credentials": [{ "id": "github_pat", "envVar": "GITHUB_TOKEN" }],
     "reportMode": "metadata-only",
     "uploadArtifactKinds": [
       "trace-run-metadata",
@@ -261,6 +269,56 @@ Runtime-emitted Wave Control events also attach:
 - `orchestratorId` from the active launcher or resident orchestrator
 - `runtimeVersion` from the installed Wave package metadata
 
+## External Providers
+
+Wave can resolve third-party auth directly in the repo runtime or through an owned Wave Control broker.
+
+```json
+{
+  "externalProviders": {
+    "context7": {
+      "mode": "direct",
+      "apiKeyEnvVar": "CONTEXT7_API_KEY"
+    },
+    "corridor": {
+      "enabled": false,
+      "mode": "direct",
+      "baseUrl": "https://app.corridor.dev/api",
+      "apiTokenEnvVar": "CORRIDOR_API_TOKEN",
+      "apiKeyFallbackEnvVar": "CORRIDOR_API_KEY",
+      "teamId": "team-id-for-direct-mode",
+      "projectId": "project-id-for-direct-mode",
+      "severityThreshold": "critical",
+      "findingStates": ["open", "potential"],
+      "requiredAtClosure": true
+    }
+  }
+}
+```
+
+- `direct`: use repo/runtime env vars directly
+- `broker`: use the owned Wave Control endpoint with `WAVE_API_TOKEN`
+- `hybrid`: try the broker first, then fall back to direct auth if broker setup fails or a broker request fails at runtime
+- direct Corridor mode requires both `teamId` and `projectId` in config; broker mode instead requires a matching `WAVE_BROKER_CORRIDOR_PROJECT_MAP` entry on the owned Wave Control deployment
+- Wave auto-loads an allowlisted repo-root `.env.local` for `CONTEXT7_API_KEY`, `CORRIDOR_API_TOKEN`, `CORRIDOR_API_KEY`, `WAVE_API_TOKEN`, and `WAVE_CONTROL_AUTH_TOKEN`
+- `wave doctor` now warns or fails early when brokered providers target the packaged default endpoint or no Wave Control auth token is available
+- Context7 remains fail-open
+- Corridor writes `.tmp/<lane>-wave-launcher/security/wave-<n>-corridor.json`, filters findings down to the wave's implementation-owned non-doc, non-`.tmp/`, non-markdown paths, and can fail closure when the fetch fails or matched findings meet the configured threshold
+- Broker mode is intended for self-hosted or team-owned Wave Control only; the packaged default endpoint is rejected as a provider-secret proxy
+- if `findingStates` is omitted or set to `[]`, Wave does not apply a state filter and the provider may return all states
+- for the full Corridor lifecycle, including broker mapping, generated artifact shape, and gate semantics, see [../corridor.md](../corridor.md)
+
+`waveControl.credentialProviders` is related but separate from `externalProviders`:
+
+- use `externalProviders.context7` and `externalProviders.corridor` for brokered or direct API access during planning / closure flows
+- use `waveControl.credentialProviders` only when an executor needs env vars leased into its runtime
+- use `waveControl.credentials` when an executor needs arbitrary user-owned secrets leased into env vars such as `GITHUB_TOKEN` or `NPM_TOKEN`
+- only `openai` and `anthropic` are valid leased providers today
+- `context7` and `corridor` remain broker-only and are never returned as raw env secrets
+- `waveControl.credentials[*].id` must match `/^[a-z0-9][a-z0-9._-]*$/`
+- `waveControl.credentials[*].envVar` must match `/^[A-Z_][A-Z0-9_]*$/`
+- when provider or arbitrary credentials are leased, Wave injects them into the live executor environment and redacts those keys in `launch-preview.json`
+
 Those fields are queryable in the `wave-control` service alongside `workspaceId`,
 `projectId`, `runKind`, `runId`, `lane`, and benchmark ids.
 

package/docs/reference/sample-waves.md

@@ -1,11 +1,11 @@
 ---
 title: "Sample Waves"
-summary: "Showcase-first sample waves that demonstrate the shipped 0.9.0 authored surface, including the optional design-role path."
+summary: "Showcase-first sample waves that demonstrate the shipped 0.9.2 authored surface, including the optional design-role path."
 ---
 
 # Sample Waves
 
-This guide points to showcase-first sample waves that demonstrate the shipped `0.9.0` authored Wave surface.
+This guide points to showcase-first sample waves that demonstrate the shipped `0.9.2` authored Wave surface.
 
 The examples are intentionally denser than typical production waves. Their job is to teach the current authoring and runtime surface quickly, not to be the smallest possible launch-ready files.
 
@@ -17,7 +17,7 @@ All example `.tmp/main-wave-launcher/...` paths assume the implicit default proj
   Shows what a good `repo-landed` outcome looks like when one promoted component only closes honestly if desired-state records, reconcile-loop substrate, and cluster-view surfaces land together. It emphasizes maturity discipline, explicit deliverables, and shared-plan closure without drifting into `pilot-live` claims.
 
 - [Full modern sample wave](../plans/examples/wave-example-live-proof.md)
-  Shows the combined `0.9.0` authored surface in one file: closure roles, `E0`, optional security review, delegated and pinned benchmark targets, richer executor config, `### Skills`, `### Capabilities`, `### Deliverables`, `### Exit contract`, `### Proof artifacts`, sticky retry, deploy environments, and proof-first live-wave structure.
+  Shows the combined `0.9.2` authored surface in one file: closure roles, `E0`, optional security review, delegated and pinned benchmark targets, richer executor config, `### Skills`, `### Capabilities`, `### Deliverables`, `### Exit contract`, `### Proof artifacts`, sticky retry, deploy environments, and proof-first live-wave structure.
 
 - [Optional design-steward handoff wave](../plans/examples/wave-example-design-handoff.md)
   Shows the shipped design-role surface: one pre-implementation design steward publishes a design packet, downstream implementation owners read that packet before coding, and normal closure roles still decide final completion. For terminal or operator-surface work, pair that shape with explicit `tui-design` in the design steward's `### Skills`. For the hybrid variant, explicitly give that same design agent implementation-owned paths and the normal implementation contract sections.
@@ -46,7 +46,7 @@ All example `.tmp/main-wave-launcher/...` paths assume the implicit default proj
 
 ## Feature Coverage Map
 
-Together these samples cover the main surfaces added or hardened through `0.9.0`:
+Together these samples cover the main surfaces added or hardened through `0.9.2`:
 
 - repo-landed maturity discipline and anti-overclaim framing
 - explicit shared-plan closure for future-wave safety
@@ -184,7 +184,7 @@ Adapt more aggressively when:
 ## Suggested Reading Order
 
 1. Start with [High-fidelity repo-landed rollout wave](../plans/examples/wave-example-rollout-fidelity.md) if you want the clearest example of good closure-ready wave fidelity for a repo-only outcome.
-2. Read [Full modern sample wave](../plans/examples/wave-example-live-proof.md) if you want the denser proof-first and eval-heavy `0.9.0` surface.
+2. Read [Full modern sample wave](../plans/examples/wave-example-live-proof.md) if you want the denser proof-first and eval-heavy `0.9.2` surface.
 3. Read [Optional design-steward handoff wave](../plans/examples/wave-example-design-handoff.md) if the task needs a design packet before implementation fan-out.
 4. Read [docs/evals/README.md](../evals/README.md) if you want more background on benchmark target selection.
 5. Read [docs/reference/live-proof-waves.md](./live-proof-waves.md) if you want more detail on proof-first `pilot-live` authoring.

package/docs/reference/skills.md

@@ -124,7 +124,7 @@ Top-level and lane-local skill attachment use the same shape:
 
 Lane-local `lanes.<lane>.skills` extends the global config instead of replacing it.
 
-Optional design workers in the shipped `0.9.0` surface normally attach `role-design`. That bundle is intended for docs/spec-first design packets and explicit implementation handoff work before implementation starts. When the design packet covers terminal UX, dashboards, or other operator surfaces, add `tui-design` explicitly in the wave's `### Skills`.
+Optional design workers in the shipped `0.9.2` surface normally attach `role-design`. That bundle is intended for docs/spec-first design packets and explicit implementation handoff work before implementation starts. When the design packet covers terminal UX, dashboards, or other operator surfaces, add `tui-design` explicitly in the wave's `### Skills`.
 
 Long-running agents that should stay resident and react only to orchestrator signal changes can add `signal-hygiene` explicitly in `### Skills`. That bundle is not auto-attached and is not meant for normal one-shot implementation agents.