@chllming/wave-orchestration 0.6.3 → 0.7.0

package/CHANGELOG.md

@@ -2,6 +2,62 @@
 
 ## Unreleased
 
+## 0.7.0 - 2026-03-23
+
+### Added
+
+- Added a unified `wave control` operator CLI that replaces `wave coord`, `wave retry`, and `wave proof` as the preferred command surface:
+  - `wave control status` materializes a single control-plane view with blocking edges, logical agent state, tasks, dependencies, rerun intent, active proof bundles, and next-timer projections.
+  - `wave control task create|get|list|act` is the operator task surface for blocking requests, blockers, clarification chains, human-input tickets, escalations, and informative handoffs, evidence, claims, and decisions.
+  - `wave control rerun request|get|clear` manages targeted rerun intent with selected agents, explicit reuse selectors, invalidated components, clear-or-preserve reuse lists, and resume cursors.
+  - `wave control proof register|get|supersede|revoke` manages authoritative proof bundles with full lifecycle state (active, superseded, revoked).
+  - `wave control telemetry status|flush` inspects and delivers the local Wave Control event queue.
+- Added a canonical control-plane event log under `.tmp/<lane>-wave-launcher/control-plane/` as append-only JSONL with event-sourced materialization. Proof registries and retry overrides under `proof/` and `control/` are now projections from this log rather than independent state files.
+- Added Wave Control telemetry, a local-first event system that queues typed events under `control-plane/telemetry/` and delivers them in best-effort batches to a Railway-hosted analysis endpoint:
+  - Configurable report modes: `disabled`, `metadata-only`, `metadata-plus-selected`, `full-artifact-upload`.
+  - Selective artifact upload by kind via `uploadArtifactKinds`.
+  - New `waveControl` config section in `wave.config.json` with global and per-lane overrides for endpoint, workspace, auth, report mode, batch size, and per-category capture toggles.
+  - New `--no-telemetry` launcher flag to disable event publication for a single run.
+  - Telemetry capture across coordination records, control-plane events, trace bundles, feedback requests, and benchmark runs.
+- Added native benchmark telemetry publishing so `wave benchmark run` emits `benchmark_run`, `benchmark_item`, `verification`, and `review` events with deterministic run IDs and config attestation hashes.
+- Added external benchmark telemetry with failure-review validity classification (`comparison-valid`, `review-only`, `benchmark-invalid`, `harness-setup-failure`, `proof-blocked`, `trustworthy-model-failure`) and artifact descriptors for patches, summaries, and verification output.
+- Added `docs/reference/wave-control.md` documenting the Wave Control telemetry contract, entity types, artifact upload policies, and local-first delivery model.
+- Added `docs/reference/proof-metrics.md` mapping README failure cases to concrete telemetry signals and success criteria.
+- Added `docs/evals/wave-benchmark-program.md` enhancements for native benchmarking mode with deterministic coordination-substrate tests.
+- Added a showcase-first `repo-landed` rollout-fidelity sample wave plus refreshed sample-wave docs so `0.7.0` includes both a dense proof-first example and a narrower closure-ready authoring reference.
+- Added resident orchestrator support via `--resident-orchestrator`, with a standing role prompt at `docs/agents/wave-orchestrator-role.md` and explicit non-owning session boundaries.
+- Added live-wave orchestration refresh that keeps shared summaries, inboxes, clarification triage, and dashboard coordination metrics current while agents are still running, including overdue acknowledgement tracking and stale clarification rerouting.
+- Added `docs/reference/runtime-config/README.md` section for `waveControl` configuration with defaults and artifact-kind filtering.
+
+### Changed
+
+- `wave coord`, `wave retry`, and `wave proof` remain available as compatibility surfaces, but new operator docs and runbooks now prefer `wave control`.
+- Proof registries and retry overrides are now projections from the canonical control-plane event log rather than independently managed state files. Legacy file paths are maintained for compatibility.
+- Trace bundles now copy `control-plane.raw.jsonl`, `capability-assignments.json`, and `dependency-snapshot.json` alongside the existing coordination, ledger, and proof artifacts.
+- `wave control task` supports informational coordination kinds (handoff, evidence, claim, decision) without falsely treating them as blocking edges in status views.
+- Proof bundles now carry lifecycle state so revoked or superseded operator evidence cannot keep satisfying closure gates.
+- Rerun requests now support explicit reuse selectors, component invalidation, resume cursors, and clear-or-preserve reuse lists alongside the existing agent selection.
+- Coordination store, feedback, clarification triage, traces, and benchmark modules now publish telemetry events when Wave Control capture is enabled.
+- Wave Control storage and queries now support durable Postgres-backed filtering by `workspaceId`, `projectId`, `orchestratorId`, and `runtimeVersion`.
+- Skill resolution description and documentation now accurately reflects the merge-then-resolve code path (base → role → runtime → deploy-kind → explicit).
+- Updated all documentation to reflect `0.7.0` release surface, including the operational runbook, coordination reference, sample waves, and live-proof examples.
+
+### Fixed And Hardened
+
+- Fixed executor-profile inheritance so a Claude profile that only overrides `claude.effort` or other scalar runtime fields now keeps the inherited global Claude command and runtime settings instead of nulling them out.
+- Fixed shared promoted-component retries so landed owners stay reusable, stale relaunch plans are invalidated against current sibling ownership, and continuation can advance to the remaining owners without burning another retry on the already-clean agent.
+- Fixed clarification triage so routed follow-up work supersedes stale human escalations, keeps the routed chain blocking through the linked request, and only opens human escalation after orchestrator-side routing is actually exhausted.
+- Hardened proof registry projections from the control-plane so revoked and superseded bundles are excluded from closure evaluation.
+- Hardened the "What The Launcher Writes" path reference to correctly place `run-state.json` at the state root (not under `status/`), and added `control-plane/`, `proof/`, and `control/` directories.
+- Closed 11 documentation-to-code gaps identified by end-to-end audit, including trace contract completeness, skill pack enumeration, benchmark CLI surface, and steward coordination kinds.
+
+### Testing And Validation
+
+- Added new test suites for `wave-control-schema`, `wave-control-client`, and `control-cli` covering event envelope normalization, telemetry queueing, delivery state tracking, and unified control-plane operations.
+- Expanded config tests for `waveControl` normalization and lane-level overrides.
+- Added regression coverage for Claude scalar inheritance, sibling-owner shared-component continuation, stale relaunch-plan invalidation, and launcher-generated routed-clarification trace replay.
+- Added regression coverage for proof-cli, proof-registry, retry-cli, and retry-control modules.
+
 ## 0.6.3 - 2026-03-22
 
 - Added a best-effort npmjs update notice on `wave launch`, `wave autonomous`, and `wave adhoc run`, with cached lookup state under `.wave/package-update-check.json` and opt-out via `WAVE_SKIP_UPDATE_CHECK=1`.
@@ -15,7 +71,7 @@
 - Clarified operator runtime visibility with additive `launch-preview.json` `limits` metadata, including explicit known turn ceilings for Claude/OpenCode and explicit Codex opacity when Wave does not emit a turn-limit flag.
 - Clarified dashboard and terminal UX: global wave counts now distinguish done, active, pending, and failed agents; the current-wave dashboard keeps a stable terminal name; and TTY dashboards use simple color cues for faster scanning.
 - Pruned stale dry-run executor preview directories when wave agent sets shrink, so manual inspection of `.tmp/.../dry-run/executors/` matches the current manifest.
-- Preserved already-landed implementation slices for shared promoted components by retrying only the sibling owners that still owe closure proof instead of blindly replaying the landed owner.
+- Improved shared promoted-component retry selection so common sibling-owned closure cases avoid immediately replaying the already-landed owner.
 - Added release-surface alignment regression coverage and updated the shipped docs so README, runtime-config references, changelog, and release metadata match the `0.6.2` package surface.
 
 ## 0.6.1 - 2026-03-22

package/README.md

@@ -20,6 +20,8 @@ The framework does three things:
   Wave builds runtime context from repo state, project memory, skills, Context7, and generated overlays.
 - `The system is inspectable and replayable.`
   Dry-run previews, logs, dashboards, ledgers, traces, and replay make the system debuggable instead of mysterious.
+- `Telemetry is local-first and proof-oriented.`
+  Wave Control records typed run, proof, and benchmark events without making remote delivery part of the scheduler's critical path.
 
 ## How The Architecture Works
 
@@ -43,6 +45,8 @@ The framework does three things:
   Exit contracts, proof artifacts, eval markers, and closure stewards stop waves from closing on narrative-only PASS.
 - `Replay and audit`
   Traces capture the attempt so failures can be inspected and replayed instead of guessed from screenshots.
+- `Telemetry and control plane`
+  Local-first event spools plus the Railway-hosted Wave Control service keep proof, benchmark validity, and selected artifacts queryable across runs.
 
 ## Example Output
 
@@ -69,22 +73,24 @@ Recent multi-agent research keeps returning to the same failure modes:
 - `Premature closure`
   Agents say they are done before proof, evals, or integrated state actually support PASS.
 
-Wave is built to mitigate those failures with canonical shared state, generated blackboard projections, explicit ownership, goal-driven, proof-bounded closure, and replayable traces. For the research framing and the current gaps, see [docs/research/coordination-failure-review.md](./docs/research/coordination-failure-review.md).
+Wave is built to mitigate those failures with canonical shared state, generated blackboard projections, explicit ownership, goal-driven, proof-bounded closure, replayable traces, and local-first telemetry. For the research framing and the current gaps, see [docs/research/coordination-failure-review.md](./docs/research/coordination-failure-review.md). For the concrete signal map, see [docs/reference/proof-metrics.md](./docs/reference/proof-metrics.md).
 
 ## Quick Start
 
 Current release:
 
-- `@chllming/wave-orchestration@0.6.3`
-- Release tag: [`v0.6.3`](https://github.com/chllming/wave-orchestration/releases/tag/v0.6.3)
+- `@chllming/wave-orchestration@0.7.0`
+- Release tag: [`v0.7.0`](https://github.com/chllming/agent-wave-orchestrator/releases/tag/v0.7.0)
 - Public install path: npmjs
 - Authenticated fallback: GitHub Packages
 
-Highlights in `0.6.3`:
+Highlights in `0.7.0`:
 
-- Runtime launch entrypoints now check npmjs for a newer published package in the background, cache the result under `.wave/package-update-check.json`, and warn on stderr when the workspace is behind.
-- `wave self-update` now gives downstream repos a one-command update path that detects the workspace package manager, updates the dependency, shows the changelog delta, and records the workspace upgrade report.
-- Autonomous and ad-hoc flows suppress nested notices so operators see at most one update banner per top-level run, and structured stdout remains clean for JSON consumers.
+- Unified `wave control` operator CLI with `status`, `task`, `rerun`, `proof`, and `telemetry` surfaces, replacing the separate `wave coord`/`wave retry`/`wave proof` commands (which remain as compatibility surfaces).
+- Canonical control-plane event log under `.tmp/<lane>-wave-launcher/control-plane/` with event-sourced materialization for proof bundles, rerun requests, operator tasks, and attempt lifecycle.
+- Wave Control telemetry: local-first event queueing with best-effort batch delivery to a Railway-hosted analysis endpoint, configurable report modes, selective artifact upload, and durable Postgres-backed querying by workspace, project, orchestrator, and runtime version.
+- Live-wave orchestration refresh that keeps coordination surfaces current during execution, including overdue acknowledgement tracking and stale clarification rerouting.
+- Resident orchestrator support via `--resident-orchestrator` for long-running non-owning monitoring sessions.
 
 Requirements:
 
@@ -93,6 +99,7 @@ Requirements:
 - `tmux` on `PATH` for dashboarded runs
 - at least one executor on `PATH`: `codex`, `claude`, or `opencode`
 - optional: `CONTEXT7_API_KEY` for launcher-side prefetch
+- optional: `WAVE_CONTROL_AUTH_TOKEN` for remote Wave Control reporting
 
 Install into another repo:
 
@@ -124,6 +131,9 @@ pnpm exec wave draft --wave 1 --template implementation
 # Run one wave with a real executor
 pnpm exec wave launch --lane main --start-wave 0 --end-wave 0 --executor codex --codex-sandbox danger-full-access
 
+# Disable Wave Control reporting for a single launcher run
+pnpm exec wave launch --lane main --no-telemetry
+
 # Inspect operator surfaces
 pnpm exec wave feedback list --lane main --pending
 pnpm exec wave dep show --lane main --wave 0 --json
@@ -143,6 +153,24 @@ pnpm test
 node scripts/wave.mjs launch --lane main --dry-run --no-dashboard
 ```
 
+## Railway MCP
+
+This repo includes a repo-local Railway MCP launcher so Codex, Claude, and Cursor can all talk to the same Railway project from the same checkout.
+
+- launcher: `.codex-tools/railway-mcp/start.sh`
+- project MCP config: `.mcp.json`
+- Cursor MCP config: `.cursor/.mcp.json`
+- Claude project settings: `.claude/settings.json`
+- Railway project id: `b2427e79-3de9-49c3-aa5a-c86db83123c0`
+
+One-time local checks:
+
+```bash
+railway whoami
+railway link --project b2427e79-3de9-49c3-aa5a-c86db83123c0
+codex mcp list
+```
+
 ## Learn More
 
 - [docs/README.md](./docs/README.md): docs map and suggested structure
@@ -151,9 +179,13 @@ node scripts/wave.mjs launch --lane main --dry-run --no-dashboard
 - [docs/concepts/context7-vs-skills.md](./docs/concepts/context7-vs-skills.md): compiled context, external truth, and repo-owned operating knowledge
 - [docs/guides/planner.md](./docs/guides/planner.md): `wave project` and `wave draft` workflow
 - [docs/guides/terminal-surfaces.md](./docs/guides/terminal-surfaces.md): tmux, VS Code terminal registry, and dry-run surfaces
+- [docs/reference/sample-waves.md](./docs/reference/sample-waves.md): showcase-first authored waves, including a high-fidelity repo-landed rollout example
+- [docs/plans/examples/wave-example-rollout-fidelity.md](./docs/plans/examples/wave-example-rollout-fidelity.md): concrete example of what good wave fidelity looks like for a narrow, closure-ready outcome
 - [docs/plans/wave-orchestrator.md](./docs/plans/wave-orchestrator.md): operator runbook
 - [docs/plans/context7-wave-orchestrator.md](./docs/plans/context7-wave-orchestrator.md): Context7 setup and bundle authoring
 - [docs/reference/runtime-config/README.md](./docs/reference/runtime-config/README.md): executor, runtime, and skill-projection configuration
+- [docs/reference/wave-control.md](./docs/reference/wave-control.md): local-first telemetry contract and Railway control-plane model
+- [docs/reference/proof-metrics.md](./docs/reference/proof-metrics.md): README failure cases mapped to concrete telemetry and benchmark evidence
 - [docs/reference/skills.md](./docs/reference/skills.md): skill bundle format, resolution order, and runtime projection
 - [docs/research/coordination-failure-review.md](./docs/research/coordination-failure-review.md): MAS failure modes from the research and how Wave responds
 - [CHANGELOG.md](./CHANGELOG.md): release history

package/docs/agents/wave-orchestrator-role.md

@@ -0,0 +1,50 @@
+---
+title: "Wave Orchestrator Role"
+summary: "Standing prompt for a resident orchestrator session that monitors a live wave and intervenes through coordination state."
+---
+
+# Wave Orchestrator Role
+
+Use this prompt for an optional resident orchestrator session that stays alive during a live wave.
+
+## Standing prompt
+
+```text
+You are the resident Wave orchestrator.
+
+Your job is to monitor the live wave for its full duration and intervene through the control plane instead of through product-code ownership.
+
+You do not own implementation files, proof markers, or closure verdicts.
+The launcher remains the scheduler truth and final authority for retries, barriers, and completion.
+
+Operate through durable state:
+- coordination log
+- shared summary
+- per-wave dashboard
+- clarification triage artifacts
+- human feedback queue
+
+Primary duties:
+1. Inspect open clarifications, routed follow-up requests, and human-feedback state.
+2. Watch for overdue acknowledgements and stale clarification chains.
+3. Resolve from repo state, prior decisions, ownership, or targeted rerouting before escalating to a human.
+4. Post durable coordination records that explain the intervention and the exact unblock condition.
+5. Stay available. If nothing needs action, keep monitoring instead of exiting early.
+
+Hard limits:
+- do not edit product code, tests, or implementation-owned docs
+- do not satisfy another agent's deliverables or proof obligations
+- do not emit implementation, integration, documentation, or cont-QA closure markers
+- do not override launcher gate results with narrative claims
+
+Good interventions:
+- route or reroute a clarification to the current owner
+- resolve a clarification from existing repo policy or published artifacts
+- open or summarize a human escalation only after orchestrator-first routing is exhausted
+- post concise board or coordination notes when timing or routing policy changed
+
+Bad interventions:
+- taking over code ownership because an owner is slow
+- calling the wave complete based on chat alone
+- escalating to human while a routed follow-up is still within policy
+```

package/docs/agents/wave-planner-role.md

@@ -0,0 +1,39 @@
+---
+title: "Wave Planner Role"
+summary: "Standing prompt for the read-only planner that turns a simple request into a high-fidelity, reviewable wave roadmap."
+---
+
+# Wave Planner Role
+
+Use this prompt when an agent should act as the planner for a future wave or set of waves.
+
+## Standing prompt
+
+```text
+You are the wave planner for the current repository.
+
+Your job is to turn a simple task request into a narrow, executable, reviewable wave plan that matches the repository's real architecture and closure model. You are read-only during planning. Do not propose work that depends on improvised runtime behavior or undocumented proof.
+
+Operating rules:
+- Read repository truth first: AGENTS.md, wave.config.json, planner docs, current-state, master-plan, component matrix, sample waves, and the planning-lessons document.
+- Treat repo-local lessons and docs as higher priority than generic external research when they conflict.
+- Prefer narrow, layered waves. Split broad or fuzzy work instead of overloading one wave.
+- Match the maturity claim, owned slices, runtime setup, deliverables, proof artifacts, and closure docs to the same truth level.
+- Treat live-proof waves as a different class of wave, not as repo-landed waves with extra prose.
+
+What you must do:
+- choose an honest target maturity level for each promoted component
+- keep each component promotion to one honest maturity jump per wave unless the request explicitly says otherwise
+- map each promoted component to one or more complementary implementation owners
+- require exact Deliverables for implementation owners
+- require exact Proof artifacts for proof-centric owners
+- require an explicit live-proof owner, `.tmp/` proof bundle, rollback or restart evidence, and an operations runbook under `docs/plans/operations/` for `pilot-live` and above
+- keep A8, A9, and A0 as real closure gates
+- pin runtime choices, budgets, and Context7 deliberately enough to avoid preventable execution failures
+- surface open questions explicitly when repo truth is missing instead of inventing policy
+
+Output contract:
+- Return structured JSON only.
+- The JSON must be decision-ready for verifier checks and markdown rendering.
+- Do not return a vague narrative summary in place of the structured plan.
+```

package/docs/context7/bundles.json

@@ -22,6 +22,15 @@
         }
       ]
     },
+    "planner-agentic": {
+      "description": "Repo-curated planning research published as a custom Context7 library for the agentic planner.",
+      "libraries": [
+        {
+          "libraryName": "wave-planner-agentic",
+          "queryHint": "wave planning best practices, maturity alignment, closure gates, proof surfaces, rollout evidence, and coordination failure prevention"
+        }
+      ]
+    },
     "react-web": {
       "description": "React and Next.js docs for frontend work.",
       "libraries": [

package/docs/context7/planner-agent/README.md

@@ -0,0 +1,25 @@
+# Planner Agent Context7 Corpus
+
+This folder contains the tracked planner corpus that can be published as a
+custom Context7 library for the agentic planner.
+
+Why it exists:
+
+- the original planning research cache lives under `docs/research/agent-context-cache/`
+- that cache is intentionally ignored in repository workspaces
+- the planner feature needs a shippable, reviewable, repo-local copy of the
+  exact subset we want to publish and consume
+
+Publish target:
+
+- bundle id: `planner-agentic`
+- library name: `wave-planner-agentic`
+
+Refresh the copied corpus after updating the agent-context cache:
+
+```bash
+pnpm research:sync-planner-context7
+```
+
+The generated `manifest.json` records the copied files, their source paths, and
+their hashes so drift is reviewable in git.

package/docs/context7/planner-agent/manifest.json

@@ -0,0 +1,83 @@
+{
+  "version": 1,
+  "generatedAt": "2026-03-22T21:14:01.636Z",
+  "bundleId": "planner-agentic",
+  "libraryName": "wave-planner-agentic",
+  "defaultQuery": "Wave planning best practices, maturity alignment, closure gates, proof surfaces, rollout evidence, and coordination failure prevention",
+  "sourceRoot": "docs/research/agent-context-cache",
+  "targetRoot": "docs/context7/planner-agent",
+  "files": [
+    {
+      "kind": "paper",
+      "sourcePath": "docs/research/agent-context-cache/papers/verified-multi-agent-orchestration-a-plan-execute-verify-replan-framework-for-complex-query-resolution.md",
+      "targetPath": "docs/context7/planner-agent/papers/verified-multi-agent-orchestration-a-plan-execute-verify-replan-framework-for-complex-query-resolution.md",
+      "title": "Verified Multi-Agent Orchestration: A Plan-Execute-Verify-Replan Framework for Complex Query Resolution",
+      "bytes": 35443,
+      "sha256": "7fecced650f5268e25ef10c10c46bc9b53ea334a39e7b04315c7d72cf663870b"
+    },
+    {
+      "kind": "paper",
+      "sourcePath": "docs/research/agent-context-cache/papers/todoevolve-learning-to-architect-agent-planning-systems.md",
+      "targetPath": "docs/context7/planner-agent/papers/todoevolve-learning-to-architect-agent-planning-systems.md",
+      "title": "TodoEvolve: Learning to Architect Agent Planning Systems",
+      "bytes": 67584,
+      "sha256": "e2e18bd732105115d3cb3eb226e8033f421634c790b2c3bbc576cefaeff92165"
+    },
+    {
+      "kind": "paper",
+      "sourcePath": "docs/research/agent-context-cache/papers/dova-deliberation-first-multi-agent-orchestration-for-autonomous-research-automation.md",
+      "targetPath": "docs/context7/planner-agent/papers/dova-deliberation-first-multi-agent-orchestration-for-autonomous-research-automation.md",
+      "title": "DOVA: Deliberation-First Multi-Agent Orchestration for Autonomous Research Automation",
+      "bytes": 36202,
+      "sha256": "d54ad0d331942cd62bd6e5cf2ed44edc577eceee6c5dadbfb88e072a96df06c0"
+    },
+    {
+      "kind": "paper",
+      "sourcePath": "docs/research/agent-context-cache/papers/why-do-multi-agent-llm-systems-fail.md",
+      "targetPath": "docs/context7/planner-agent/papers/why-do-multi-agent-llm-systems-fail.md",
+      "title": "Why Do Multi-Agent LLM Systems Fail?",
+      "bytes": 141179,
+      "sha256": "faaf6dd51ab9eb612b58bd00c9b0d13595daabd4b34078a24ed135e28b12868d"
+    },
+    {
+      "kind": "paper",
+      "sourcePath": "docs/research/agent-context-cache/papers/silo-bench-a-scalable-environment-for-evaluating-distributed-coordination-in-multi-agent-llm-systems.md",
+      "targetPath": "docs/context7/planner-agent/papers/silo-bench-a-scalable-environment-for-evaluating-distributed-coordination-in-multi-agent-llm-systems.md",
+      "title": "Silo-Bench: A Scalable Environment for Evaluating Distributed Coordination in Multi-Agent LLM Systems",
+      "bytes": 76435,
+      "sha256": "e28334cd0891773f7044c7e29bbcc6c3ae79b701838a6b8526fffdf2c5e4c41d"
+    },
+    {
+      "kind": "paper",
+      "sourcePath": "docs/research/agent-context-cache/papers/dpbench-large-language-models-struggle-with-simultaneous-coordination.md",
+      "targetPath": "docs/context7/planner-agent/papers/dpbench-large-language-models-struggle-with-simultaneous-coordination.md",
+      "title": "DPBench: Large Language Models Struggle with Simultaneous Coordination",
+      "bytes": 54309,
+      "sha256": "22a37fd0fbcf5e21b89d9dba9e7d51298c93ad8baefd17dc3373373105f01f07"
+    },
+    {
+      "kind": "paper",
+      "sourcePath": "docs/research/agent-context-cache/papers/cooperbench-why-coding-agents-cannot-be-your-teammates-yet.md",
+      "targetPath": "docs/context7/planner-agent/papers/cooperbench-why-coding-agents-cannot-be-your-teammates-yet.md",
+      "title": "CooperBench: Why Coding Agents Cannot be Your Teammates Yet",
+      "bytes": 104926,
+      "sha256": "463a2f7129ad2869a80f2a697682fa57407a76d3d5cadf7a94234bfd55ef1992"
+    },
+    {
+      "kind": "paper",
+      "sourcePath": "docs/research/agent-context-cache/papers/incremental-planning-to-control-a-blackboard-based-problem-solver.md",
+      "targetPath": "docs/context7/planner-agent/papers/incremental-planning-to-control-a-blackboard-based-problem-solver.md",
+      "title": "Incremental Planning to Control a Blackboard-Based Problem Solver",
+      "bytes": 44369,
+      "sha256": "568fe7236b214fe0a24e0530513776ee5579e0366b9f277e8c0ebd49daea7b67"
+    },
+    {
+      "kind": "topic",
+      "sourcePath": "docs/research/agent-context-cache/topics/planning-and-orchestration.md",
+      "targetPath": "docs/context7/planner-agent/topics/planning-and-orchestration.md",
+      "title": "Planner Agentic Context7 Corpus",
+      "bytes": 1858,
+      "sha256": "5c8c00bc2c4b72330267ca8cce2889b2eaa3bbf02db49e90a1fb7b0eb9d0ef44"
+    }
+  ]
+}