@chllming/wave-orchestration 0.8.3 → 0.8.5

package/docs/reference/cli-reference.md

@@ -7,6 +7,19 @@ summary: "Complete syntax reference for all wave CLI commands, flags, and operat
 
 Complete syntax for every `wave` command. All commands use `pnpm exec wave` as the entry point.
 
+## Command Families
+
+- Runtime:
+  `wave launch`, `wave autonomous`, and `wave local` cover dry-run validation, live execution, and executor-specific prompt transport.
+- Operator control:
+  `wave control` is the preferred surface for live status, tasks, reruns, proof bundles, and telemetry.
+- Compatibility and inspection:
+  `wave coord`, `wave retry`, and `wave proof` remain available where older runbooks still depend on them.
+- Planning and transient work:
+  `wave project`, `wave draft`, and `wave adhoc` cover defaults, authored waves, and operator-driven one-off runs.
+- Setup and lifecycle:
+  `wave init`, `wave doctor`, `wave upgrade`, and `wave self-update` cover workspace adoption, validation, and package upgrades.
+
 ## wave launch
 
 Launch waves for execution.
@@ -15,6 +28,10 @@ Launch waves for execution.
 wave launch [options]
 ```
 
+Defaults below reflect the starter workspace surface in this repo. Lane config can override executor, timeout, retry, and terminal defaults.
+
+Closure-role bindings do not have a CLI override surface. When a wave file declares custom integration, documentation, `cont-QA`, `cont-EVAL`, or security-review role ids, launch, retry, reducer, and closure flows honor those wave-level bindings end to end.
+
 | Flag | Default | Description |
 |------|---------|-------------|
 | `--lane <name>` | `main` | Lane name |
@@ -22,20 +39,23 @@ wave launch [options]
 | `--end-wave <n>` | last available | Last wave to launch |
 | `--auto-next` | off | Start from next unfinished wave and continue |
 | `--resume-control-state` | off | Preserve the prior auto-generated relaunch plan instead of treating the launch as a fresh wave start |
-| `--executor <id>` | lane config | Default executor: `codex`, `claude`, `opencode`, `local` |
+| `--executor <id>` | `codex` | Default executor: `codex`, `claude`, `opencode`, `local` |
 | `--codex-sandbox <mode>` | `danger-full-access` | Codex sandbox isolation level |
-| `--timeout-minutes <n>` | `60` | Max minutes to wait per wave |
-| `--max-retries-per-wave <n>` | `3` | Relaunch failed agents per wave |
-| `--agent-rate-limit-retries <n>` | `3` | Per-agent retries for 429 errors |
-| `--agent-rate-limit-base-delay-seconds <n>` | `1` | Base exponential backoff for 429 |
-| `--agent-rate-limit-max-delay-seconds <n>` | `60` | Max backoff delay for 429 |
-| `--agent-launch-stagger-ms <n>` | `250` | Delay between agent launches |
-| `--terminal-surface <mode>` | configured | `tmux`, `vscode`, or `none` |
+| `--timeout-minutes <n>` | `240` | Max minutes to wait per wave |
+| `--max-retries-per-wave <n>` | `1` | Relaunch failed agents per wave |
+| `--agent-rate-limit-retries <n>` | `2` | Per-agent retries for 429 errors |
+| `--agent-rate-limit-base-delay-seconds <n>` | `20` | Base exponential backoff for 429 |
+| `--agent-rate-limit-max-delay-seconds <n>` | `180` | Max backoff delay for 429 |
+| `--agent-launch-stagger-ms <n>` | `1200` | Delay between agent launches |
+| `--terminal-surface <mode>` | `vscode` | `tmux`, `vscode`, or `none` |
 | `--no-dashboard` | off | Disable per-wave tmux dashboard |
 | `--cleanup-sessions` | on | Kill lane tmux sessions after each wave |
 | `--keep-sessions` | off | Keep lane tmux sessions |
 | `--keep-terminals` | off | Keep temporary terminal entries |
 | `--orchestrator-id <id>` | generated | Stable orchestrator identity |
+| `--orchestrator-board <path>` | default board path | Write coordination-board updates to a specific shared board |
+| `--no-orchestrator-board` | off | Disable shared orchestrator-board writes for this run |
+| `--coordination-note <text>` | empty | Append a startup intent note to orchestrator-board updates |
 | `--resident-orchestrator` | off | Launch long-running non-owning orchestrator session |
 | `--no-telemetry` | off | Disable Wave Control event publication |
 | `--no-context7` | off | Disable Context7 prefetch |
@@ -57,13 +77,13 @@ wave autonomous [options]
 | `--lane <name>` | `main` | Lane name |
 | `--executor <id>` | lane config | `codex`, `claude`, or `opencode` (not `local`) |
 | `--codex-sandbox <mode>` | `danger-full-access` | Codex sandbox mode |
-| `--timeout-minutes <n>` | `60` | Per-wave timeout passed to launcher |
-| `--max-retries-per-wave <n>` | `3` | Per-wave relaunches inside launcher |
+| `--timeout-minutes <n>` | `240` | Per-wave timeout passed to launcher |
+| `--max-retries-per-wave <n>` | `1` | Per-wave relaunches inside launcher |
 | `--max-attempts-per-wave <n>` | `1` | External attempts per wave |
-| `--agent-rate-limit-retries <n>` | `3` | Per-agent 429 retries |
-| `--agent-rate-limit-base-delay-seconds <n>` | `1` | Base 429 backoff |
-| `--agent-rate-limit-max-delay-seconds <n>` | `60` | Max 429 backoff |
-| `--agent-launch-stagger-ms <n>` | `250` | Delay between agent launches |
+| `--agent-rate-limit-retries <n>` | `2` | Per-agent 429 retries |
+| `--agent-rate-limit-base-delay-seconds <n>` | `20` | Base 429 backoff |
+| `--agent-rate-limit-max-delay-seconds <n>` | `180` | Max 429 backoff |
+| `--agent-launch-stagger-ms <n>` | `1200` | Delay between agent launches |
 | `--orchestrator-id <id>` | `<lane>-autonomous` | Orchestrator identity |
 | `--resident-orchestrator` | off | Launch resident orchestrator for each wave |
 | `--dashboard` | off | Enable dashboards |
@@ -514,6 +534,18 @@ wave draft --show-run <run-id>
 wave draft --apply-run <run-id>
 ```
 
+Interactive draft currently offers worker role kinds:
+
+- `design`
+- `implementation`
+- `qa`
+- `infra`
+- `deploy`
+- `research`
+- `security`
+
+Agentic planner payloads also accept `workerAgents[].roleKind = "design"`. The shipped `0.8.5` surface uses `design-pass` as the default executor profile for that role and typically assigns a packet path like `docs/plans/waves/design/wave-<n>-<agentId>.md`. Interactive draft scaffolds the docs-first default; hybrid design stewards are authored by explicitly adding implementation-owned paths and the normal implementation contract sections.
+
 ## Ad-Hoc Task Commands
 
 **Plan and run ad-hoc tasks:**

package/docs/reference/coordination-and-closure.md

@@ -25,6 +25,17 @@ Those are related, but they are not the same.
 
 An implementation agent can be locally complete and still leave the wave blocked if it created open helper work, unresolved clarification chains, or required dependencies.
 
+At runtime, those distinctions map onto separate modules:
+
+- `implementation-engine.mjs` selects implementation work
+- `derived-state-engine.mjs` rebuilds the blackboard projections
+- `gate-engine.mjs` evaluates closure and barrier state from envelopes plus canonical logs
+- `retry-engine.mjs` decides what can safely resume
+- `closure-engine.mjs` sequences the staged closeout
+- `session-supervisor.mjs` only launches sessions and records observed facts
+
+Closure roles are resolved from the wave definition first, then from starter defaults. In other words, integration, documentation, `cont-QA`, `cont-EVAL`, and security review keep the same semantics even when a wave overrides the default role ids such as `A8`, `A9`, `A0`, `E0`, or `A7`.
+
 ## Durable State Surfaces
 
 The runtime writes several different artifacts, but they do different jobs:
@@ -52,6 +63,8 @@ The runtime writes several different artifacts, but they do different jobs:
 
 The important rule is that decisions come from the canonical authority set: wave definitions, the coordination log, the control-plane log, and immutable result envelopes. The markdown board is a projection for humans. See [wave-orchestrator.md](../plans/wave-orchestrator.md).
 
+That control-plane log also carries observed `wave_run`, `attempt`, and `agent_run` lifecycle facts from `session-supervisor.mjs`. When human feedback or escalation remains open, the reducer materializes the wave as `clarifying` with blocked `waveState` instead of flattening it into generic progress.
+
 Live waves now keep refreshing that derived state while agents are still running. Shared summaries, inboxes, dashboard coordination metrics, and clarification routing are not only recomputed at attempt boundaries; they are also refreshed during active wave execution so stale clarification and acknowledgement timing is machine-visible before the attempt ends.
 
 ## What Agents Should Use
@@ -61,7 +74,7 @@ Use the coordination log for conversational or workflow state:
 - `request`
   Use this when you need another agent or capability owner to do work. Target it explicitly. This is the kind that becomes a helper assignment.
 - `blocker`
-  Use this when the wave is blocked, but not because the launcher needs to route work to a specific assignee.
+  Use this when the wave is blocked, but not because the runtime needs to route work to a specific assignee.
 - `handoff`
   Use this for continuity and context transfer. This is informative by itself; it is not the same as a blocking helper assignment.
 - `evidence`
@@ -164,7 +177,7 @@ pnpm exec wave control task create \
 What happens next:
 
 - the request lands in the canonical coordination log
-- the launcher derives a helper assignment for `agent:A8`
+- the runtime derives a helper assignment for `agent:A8`
 - that assignment is written into the assignment snapshot
 - the shared summary and A8 inbox now show the open helper work
 
@@ -230,9 +243,9 @@ pnpm exec wave coord post \
 
 What happens next:
 
-1. the launcher triages the clarification from repo policy, ownership, prior decisions, and routing context
+1. the orchestrator triages the clarification from repo policy, ownership, prior decisions, and routing context
 2. if it can answer inside the wave, it writes the resolution back into coordination state
-3. if another owner can answer it, the launcher opens a targeted follow-up request and keeps the clarification chain blocking
+3. if another owner can answer it, the runtime opens a targeted follow-up request and keeps the clarification chain blocking
 4. only after policy and routed follow-up paths are exhausted does it create human feedback or escalation artifacts
 5. until that chain is resolved, clarification remains a closure barrier and any routed follow-up also remains blocking helper work
 
@@ -406,7 +419,7 @@ That gives Wave two useful properties:
 
 ## Targeted Retry Behavior
 
-When closure fails, the launcher does not always relaunch the entire wave.
+When closure fails, the runtime does not always relaunch the entire wave.
 
 It tries to relaunch only the implicated owners:
 
@@ -425,7 +438,7 @@ pnpm exec wave control rerun get --lane main --wave 10 --json
 pnpm exec wave control rerun request --lane main --wave 10 --agent A2 --agent A7 --clear-reuse A2 --reason "Resume sibling-owned component closure"
 ```
 
-The canonical rerun request is written under `.tmp/<lane>-wave-launcher/control-plane/`, projected to `.tmp/<lane>-wave-launcher/control/` for compatibility, consumed by the launcher on the next retry decision, and then cleared by default after one application. This is the supported path for:
+The canonical rerun request is written under `.tmp/<lane>-wave-launcher/control-plane/`, projected to `.tmp/<lane>-wave-launcher/control/` for compatibility, consumed by the retry engine on the next retry decision, and then cleared by default after one application. This is the supported path for:
 
 - rerunning only specific owners
 - preserving explicit reuse selectors such as attempt ids, proof bundle ids, derived-summary reuse, and invalidated component ids through the compatibility projection

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

@@ -2,7 +2,7 @@
 
 This repo now includes a dedicated npmjs publish workflow at [publish-npm.yml](../../.github/workflows/publish-npm.yml).
 
-The current `0.8.3` release procedure publishes through a repository Actions secret named `NPM_TOKEN`.
+The current `0.8.5` release procedure publishes through a repository Actions secret named `NPM_TOKEN`.
 
 ## What This Repo Already Does
 
@@ -47,6 +47,7 @@ If this repo later needs private npm dependencies during CI, consider a separate
 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. Push the release commit and release tag, for example `v0.8.3`.
-5. Verify both `publish-npm.yml` and `publish-package.yml` start from the tag push.
-6. Verify the npmjs publish completes successfully for the tagged source.
+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.8.5`.
+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/sample-waves.md

@@ -1,11 +1,11 @@
 ---
 title: "Sample Waves"
-summary: "Showcase-first sample waves that demonstrate the current 0.8.3 Wave surface."
+summary: "Showcase-first sample waves that demonstrate the shipped 0.8.5 authored surface, including the optional design-role path."
 ---
 
 # Sample Waves
 
-This guide points to showcase-first sample waves that demonstrate the current `0.8.3` authored Wave surface.
+This guide points to showcase-first sample waves that demonstrate the shipped `0.8.5` 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.
 
@@ -15,7 +15,10 @@ The examples are intentionally denser than typical production waves. Their job i
   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.8.3` 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.8.5` 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.
 
 ## What These Examples Teach
 
@@ -35,10 +38,11 @@ The examples are intentionally denser than typical production waves. Their job i
 - sticky retry for proof-bearing owners
 - deploy environments and provider-skill examples
 - infra and deploy-verifier specialist slices
+- optional pre-implementation design packets and design-to-implementation handoff
 
 ## Feature Coverage Map
 
-Together these samples cover the main surfaces added or hardened for `0.8.3`:
+Together these samples cover the main surfaces added or hardened through `0.8.5`:
 
 - repo-landed maturity discipline and anti-overclaim framing
 - explicit shared-plan closure for future-wave safety
@@ -56,6 +60,7 @@ Together these samples cover the main surfaces added or hardened for `0.8.3`:
 - proof-first live-wave prompts
 - deploy environments and deploy-kind-aware skills
 - integration, documentation, and cont-QA closure-role structure
+- optional `design` worker role and `design-pass` executor profile
 
 ## When To Copy Literally Vs Adapt
 
@@ -76,6 +81,7 @@ Adapt more aggressively when:
 ## How This Example Maps To Other Docs
 
 - Use [docs/guides/planner.md](../guides/planner.md) for the planner-generated baseline, then use these samples to see how a human would enrich the generated draft for either repo-landed or proof-first work.
+- Use [Optional design-steward handoff wave](../plans/examples/wave-example-design-handoff.md) when the wave should start with a reusable design packet before implementation begins.
 - Use [docs/evals/README.md](../evals/README.md) with the full modern sample when you need to see delegated and pinned benchmark targets in a real wave.
 - Use [docs/reference/live-proof-waves.md](./live-proof-waves.md) with the full modern sample when you need proof-first authoring for `pilot-live` and above.
 - Use [docs/plans/wave-orchestrator.md](../plans/wave-orchestrator.md) for the operational runbook that explains how the launcher interprets these sections.
@@ -83,9 +89,10 @@ 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 surface.
-3. Read [docs/evals/README.md](../evals/README.md) if you want more background on benchmark target selection.
-4. Read [docs/reference/live-proof-waves.md](./live-proof-waves.md) if you want more detail on proof-first `pilot-live` authoring.
+2. Read [Full modern sample wave](../plans/examples/wave-example-live-proof.md) if you want the denser proof-first and eval-heavy `0.8.5` 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.
 
 ## Why These Examples Live In `docs/plans/examples/`
 

package/docs/reference/skills.md

@@ -109,6 +109,7 @@ Top-level and lane-local skill attachment use the same shape:
     "dir": "skills",
     "base": ["wave-core", "repo-coding-rules"],
     "byRole": {
+      "design": ["role-design"],
       "deploy": ["role-deploy"]
     },
     "byRuntime": {
@@ -123,6 +124,8 @@ 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.8.5` 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`.
+
 ## Resolution Order
 
 Resolved skills are gathered in this order:
@@ -195,6 +198,12 @@ Runtime delivery:
 
 These runtime projections are guidance surfaces. They should stay aligned with the canonical authority model, but they are not replay inputs or decision state on their own.
 
+For the optional `design` worker role, the default pattern is:
+
+- `role-design` for the design packet contract
+- `tui-design` only when the packet covers terminal UX, dashboards, or other operator surfaces
+- no runtime-specific coding bundle unless the wave explicitly gives the design steward code ownership and makes it a hybrid design steward
+
 ## Generated Artifacts
 
 Executor overlay directories can contain:
@@ -225,3 +234,4 @@ Missing or malformed bundles are configuration errors, not silent no-ops.
 - Use explicit per-agent `### Skills` for true exceptions, not as a substitute for missing activation metadata.
 - Keep provider skills role-scoped unless every role genuinely needs the provider context.
 - Keep bundle ids stable so traces and prompt fingerprints remain intelligible across runs.
+- Keep `role-design` docs/spec-first by default; add `tui-design` when terminal or operator-surface work is in scope, and only attach broader coding bundles when the wave explicitly assigns code ownership and expects the same design steward to return for implementation.

package/package.json

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

package/releases/manifest.json

@@ -2,6 +2,45 @@
   "schemaVersion": 1,
   "packageName": "@chllming/wave-orchestration",
   "releases": [
+    {
+      "version": "0.8.5",
+      "date": "2026-03-25",
+      "summary": "Shipped design-role support, hybrid design-steward execution, release-surface alignment, and a practical migration guide.",
+      "features": [
+        "The optional `design` worker role is now part of the published release surface, including the standing design prompt, `role-design`, and `tui-design` starter bundles.",
+        "Design stewards are docs-first by default, but waves can now explicitly give them implementation ownership so the same agent runs a design pass first and then rejoins implementation with normal proof obligations.",
+        "Design-aware validation, prompts, gates, retry or resume planning, reducer state, local-executor smoke behavior, and result-envelope projection now all agree on the same hybrid-design contract.",
+        "The migration guide now covers fresh adoption plus upgrades from `0.8.4`, `0.8.0`-`0.8.4`, `0.6.x`-`0.7.x`, and `0.5.x` or earlier, including repo-owned starter-surface sync guidance and `planner-agentic` corpus notes.",
+        "Shipped package metadata, README, current-state notes, sample-wave docs, and publishing guidance now point at the `0.8.5` release surface."
+      ],
+      "manualSteps": [
+        "Run `pnpm exec wave doctor` and `pnpm exec wave launch --lane main --dry-run --no-dashboard` after upgrading so the repo validates against the `0.8.5` design-role and hybrid-design behavior.",
+        "If your repo copied starter prompts, skills, or authoring docs, sync `docs/agents/wave-design-role.md`, `skills/role-design/`, `skills/tui-design/`, `wave.config.json` design-role keys, and any local planner or runbook pages that should describe the new design-steward model.",
+        "If a repo uses hybrid design stewards, make sure each one still owns a design packet path and that any explicit implementation ownership also carries the expected exit contract, deliverables, proof artifacts, and component declarations where your lane validation requires them.",
+        "If your repo uses planner workflows and copied the planner starter corpus, keep `docs/agents/wave-planner-role.md`, `skills/role-planner/`, `docs/context7/planner-agent/`, `docs/reference/wave-planning-lessons.md`, and the `planner-agentic` bundle entry in sync before relying on local planner docs."
+      ],
+      "breaking": false
+    },
+    {
+      "version": "0.8.4",
+      "date": "2026-03-25",
+      "summary": "Contradiction replay repair, consistent component-promotion thresholds, projection-writer persistence centralization, and 0.8.4 release-surface alignment.",
+      "features": [
+        "Hermetic contradiction replay no longer depends on component-matrix parsing when the trace does not declare promoted components.",
+        "`requireComponentPromotionsFromWave` now gates both component-promotion proof validation and component-matrix current-level validation consistently across live and replay paths.",
+        "Projection persistence is now centralized under `projection-writer.mjs`, while `derived-state-engine.mjs` computes projection payloads without writing them directly.",
+        "The operator migration guide now covers fresh adoption plus upgrades from `0.8.3`, `0.8.0`-`0.8.2`, `0.6.x`-`0.7.x`, and `0.5.x` or earlier with explicit repo-owned surface sync guidance.",
+        "Shipped package metadata, README, migration guidance, current-state notes, sample-wave docs, and npm publishing instructions now point at the `0.8.4` release surface."
+      ],
+      "manualSteps": [
+        "Run `pnpm exec wave doctor` and `pnpm exec wave launch --lane main --dry-run --no-dashboard` after upgrading so the repo validates against the `0.8.4` replay, projection, and component-threshold behavior.",
+        "If your adopted repo uses planner workflows and copied the starter planner corpus, sync `docs/agents/wave-planner-role.md`, `skills/role-planner/`, `docs/context7/planner-agent/`, `docs/reference/wave-planning-lessons.md`, and the `planner-agentic` bundle entry in `docs/context7/bundles.json`.",
+        "If your repo copied the shipped starter docs or skills, sync the current operator runbook, architecture docs, launcher or orchestrator prompts, planner corpus, and relevant runtime or closure-role starter skills before relying on local runbooks.",
+        "If your repo keeps historical replay fixtures, replay at least one contradiction-blocked trace and one promoted-component trace after the upgrade so both code paths stay covered.",
+        "If an older adopted repo still carries legacy evaluator wording or pre-control-plane operator docs, complete the repo-owned prompt and runbook migration described in `docs/plans/migration.md` before cutting live waves on `0.8.4`."
+      ],
+      "breaking": false
+    },
     {
       "version": "0.8.3",
       "date": "2026-03-24",