@beyondwork/docx-react-component 1.0.0

package/docs/concepts/runtime-agnostic-orchestration.md

@@ -0,0 +1,111 @@
+# Runtime-Agnostic Orchestration
+
+In short: one orchestrator, many runtimes.
+
+Wave is runtime agnostic at the orchestration layer.
+
+That means planning, skills, evaluation, proof, coordination, closure, and traces do not depend on whether the selected executor is Codex, Claude Code, OpenCode, or the local smoke executor.
+
+Wave abstracts the runtime away without flattening everything to the lowest common denominator. The wave contract stays stable while the executor adapter preserves the useful runtime-native features.
+
+## What Stays The Same Across Runtimes
+
+These layers are runtime-neutral:
+
+- wave parsing and validation
+- planner-produced wave specs and authored wave markdown
+- reducer state and phase-engine decisions
+- eval targets, deliverables, and proof artifacts
+- component and closure gates
+- skill resolution and attachment policy
+- compiled shared summaries and per-agent inboxes
+- canonical authority-set state plus rendered projections
+- helper assignments and dependency handling
+- integration summaries, docs queues, and ledgers
+- dry-run previews
+- trace bundles and replay metadata
+
+The runtime only changes at the last step, when the session supervisor and executor adapter translate the resolved assignment into an executor-specific invocation.
+
+## Where Runtime-Specific Logic Lives
+
+Runtime-specific behavior is isolated to the executor adapter layer:
+
+- Codex
+  `codex exec` invocation, sandbox flags, `--add-dir`, JSON mode, search, images, and other `exec` flags.
+- Claude
+  `claude -p` plus system-prompt overlay, settings merge, hooks, and permission surface.
+- OpenCode
+  `opencode run` plus generated `opencode.json`, attached files, and runtime instruction overlays.
+- Local
+  A smoke executor used for prompt and closure verification without a real hosted runtime.
+
+The orchestration substrate above those adapters does not need to know how the runtime transports prompts.
+
+This is the important distinction:
+
+- the orchestration layer owns goals, ownership, proof, and shared state
+- the executor adapter owns prompt transport, runtime-native flags, files, and settings
+
+That split is what lets Wave stay portable without giving up runtime-specific leverage.
+
+## Why This Matters
+
+Runtime agnosticism gives you:
+
+- the same plan, skill, and closure model across vendors
+- the same eval and proof model across vendors
+- replay and audit surfaces that do not care which runtime produced the work
+- per-role runtime choice without rewriting authoring conventions
+- retry-time fallback without inventing a second planning model
+
+## Runtime Resolution
+
+Executor choice resolves in a fixed order:
+
+1. explicit agent `### Executor` id
+2. executor profile id
+3. lane role default
+4. CLI `--executor`
+5. global default
+
+After that choice is final, the orchestrator resolves runtime-specific overlays and any runtime-attached skill packs.
+
+## Fallback And Mix Policy
+
+Wave is not runtime blind. It is runtime agnostic, but still runtime aware.
+
+- runtime mix targets can cap how many agents use a given executor
+- executor profiles can declare fallbacks
+- lane policy can supply default executor choices by role
+- retries can reassign an agent to a policy-safe fallback runtime
+
+The important part is that fallback does not change the higher-level wave contract. The runtime changes, but the ownership, closure, and trace model remain the same.
+
+## Skills Across Runtimes
+
+The skill system follows the same pattern:
+
+- `skills/` is the canonical repo-owned source
+- the orchestrator resolves skill ids without caring which runtime will consume them
+- the executor adapter projects those skills into the surface each runtime understands
+
+Examples:
+
+- Codex receives skill bundle directories through `--add-dir`
+- Claude receives merged skill text through the generated system prompt overlay
+- OpenCode receives skill instructions and attached files through `opencode.json` and `--file`
+- Local receives prompt-only projections
+
+The bundle is shared. The projection is runtime specific.
+
+## Best Practice
+
+Keep planning, ownership, and proof requirements runtime neutral whenever possible. Use runtime-specific settings only for:
+
+- transport details
+- model or budget selection
+- safety and permission settings
+- runtime-native adapter instructions
+
+That separation is what keeps the orchestrator portable instead of turning it into a Codex-only or Claude-only harness.

package/docs/concepts/what-is-a-wave.md

@@ -0,0 +1,217 @@
+# What Is A Wave?
+
+A wave is the main planning and execution unit in Wave Orchestration.
+
+It turns free-form agent runs into a bounded blackboard-style work package with shared state, explicit ownership, dynamic context, goal-driven execution, and proof-bounded closure.
+
+It is not just a prompt file. A wave is a bounded slice of repository work with:
+
+- explicit scope
+- named owners
+- runtime and context requirements
+- proof and closure rules
+- durable coordination state
+- replayable execution artifacts
+
+## Core Terms
+
+- Lane
+  An ordered sequence of waves. The default lane in this repo is `main`.
+- Wave
+  One numbered work package inside a lane, usually stored as `docs/plans/waves/wave-<n>.md`.
+- Agent
+  One role inside the wave, such as design, implementation, `cont-EVAL`, security review, integration, documentation, cont-QA, infra, or deploy.
+- Attempt
+  One execution pass of a wave. A wave can have multiple attempts due to retries or fallback.
+- Closure
+  The final proof pass that decides whether the wave is actually done, not just partially implemented.
+
+## Why Waves Exist
+
+Waves force a higher planning bar than ad hoc prompts. A good wave answers:
+
+- What is changing now, and why now?
+- Which components or docs are in scope?
+- Which agent owns each slice?
+- What evidence closes the wave?
+- Which dependencies, helper requests, or escalations can still block completion?
+
+## Why This Is A Blackboard-Style Model
+
+Wave is blackboard-style because agents work against shared canonical state instead of treating chat output as the system of record.
+
+- wave definitions, the coordination log, and the control-plane log form the canonical authority set
+- attempt-scoped result envelopes are the immutable structured outcome surface for completed agent work
+- the rolling board is a human projection over that state, not a decision input
+- shared summaries and per-agent inboxes are compiled views over the same authority set
+- helper assignments, clarification flow, dependencies, and integration all operate on that shared state
+- closure depends on the integrated state, not on whether an agent says "done"
+
+## Wave Anatomy
+
+Wave markdown is one authored declaration surface today. A typical wave can include:
+
+- title and commit message
+- project profile details such as oversight mode and lane
+- sequencing note
+- reference rule
+- deploy environments
+- component promotions
+- eval targets
+- Context7 defaults
+- one `## Agent ...` block per role
+
+Inside each agent block, the important sections are:
+
+- `### Role prompts`
+  Standing role identity imported from `docs/agents/*.md`.
+- `### Executor`
+  Runtime selection, profile, model, fallbacks, and budgets.
+- `## Eval targets`
+  Optional wave-level contract for `cont-EVAL`, including benchmark family or pinned benchmarks, objective, and stop condition.
+  See [docs/evals/README.md](../evals/README.md) for guidance on delegated versus pinned targets and the coordination benchmark families.
+- `### Proof artifacts`
+  Optional machine-visible local evidence required for proof-centric waves, especially `pilot-live` and above.
+- `### Context7`
+  External library truth to prefetch and inject.
+- `### Skills`
+  Reusable repo-owned environment or workflow guidance resolved after runtime selection.
+- `### Components`
+  The components that agent is responsible for proving or promoting.
+- `### Capabilities`
+  Optional routing hints for follow-up work.
+- `### Deliverables`
+  Exact repo-relative outputs that must exist before closure can pass.
+- `### Prompt`
+  The specific task, file ownership, requirements, and validation instructions.
+- `### Exit contract`
+  The completion, durability, proof, and documentation expectations that gate closure.
+
+## Standard Roles
+
+The starter runtime ships with three default closure roles plus optional specialists. A wave may override the role ids, but the closure semantics stay the same:
+
+- `A8`
+  Integration steward
+- `A9`
+  Documentation steward
+- `A0`
+  cont-QA
+- `E0`
+  Optional `cont-EVAL` for iterative benchmark or output tuning; report-only by default, implementation-owning only when explicitly assigned non-report files
+- `A7`
+  Optional security reviewer; report-only by default and used to publish a threat-model-first security review before integration closure
+- `D1` or another custom id
+  Optional design steward; report-first and docs/spec-owned by default, used to publish a design packet before code-owning implementation fans out. If the wave explicitly gives that same agent source-code ownership, it becomes a hybrid design steward that rejoins the later implementation fan-out.
+
+Implementation or specialist agents own the actual work slices. Closure roles do not replace implementation ownership; they decide whether the combined result is closure-ready. `cont-EVAL` is the one hybrid role: most waves keep it report-only, but human-authored waves may assign explicit tuning files to `E0`, in which case it must satisfy both implementation proof and eval proof.
+
+## Lifecycle Of A Wave
+
+1. Author or draft the wave.
+2. Run `wave launch --dry-run --no-dashboard`.
+3. The launcher parses the wave, resolves executors and skills, rebuilds reducer state, and materializes operator surfaces.
+4. A live run launches design agents first when the wave declares them.
+5. Code-owning implementation agents start only after every design packet is `ready-for-implementation`; hybrid design stewards rejoin that implementation fan-out once the design gate clears.
+6. Agents write structured coordination events instead of relying on ad hoc terminal output.
+7. The reducer, gate engine, and retry or closure engines evaluate design readiness, implementation contracts, promoted-component proof, helper assignments, dependencies, contradictions, and clarification state.
+8. If implementation is ready, closure runs in order: optional `cont-EVAL`, optional security review, integration, documentation, then cont-QA.
+9. The attempt is captured in per-wave traces, ledgers, inboxes, summaries, and copied artifacts.
+
+## Runtime And Operating Posture
+
+Wave is runtime agnostic at the orchestration layer.
+
+Planning, ownership, closure, durable state, and traces do not depend on whether an agent runs on Codex, Claude Code, OpenCode, or the local smoke executor. Runtime-specific behavior is isolated to executor adapters and overlays.
+
+That means a wave should usually be authored in runtime-neutral terms:
+
+- ownership and deliverables
+- proof and validation
+- closure order
+- dependencies and helper flow
+- promoted component expectations
+
+The runtime choice resolves later, from the agent executor block, profile defaults, lane defaults, CLI overrides, and fallback policy.
+
+Wave also has an execution posture:
+
+- `oversight`
+  Human review or intervention is expected for risky or ambiguous work.
+- `dark-factory`
+  The wave is authored for routine execution without normal human intervention.
+
+Today these postures are planning vocabulary and saved project defaults, not two separate execution engines. Human feedback is still an escalation mechanism inside the orchestration loop, not the definition of the operating mode itself.
+
+If you need the narrower supporting pages, see [runtime-agnostic-orchestration.md](./runtime-agnostic-orchestration.md) and [operating-modes.md](./operating-modes.md).
+
+Current live waves are strict about closure artifacts:
+
+- `cont-EVAL` must emit a structured `[wave-eval]` marker whose `target_ids` matches the declared eval targets and whose `benchmark_ids` enumerates the executed benchmark set.
+- Security reviewers must leave a security review report and emit a final `[wave-security]` marker with `state=<clear|concerns|blocked>`, finding count, and approval count.
+- `cont-QA` must emit both a final `Verdict:` line and a final `[wave-gate]` marker.
+- Replay keeps read-only compatibility with older traces and older evaluator-era artifacts, but live waves do not pass on verdict-only or underspecified closure markers.
+
+## Context Is Compiled At Runtime
+
+Wave also treats context as something to compile for the current task, not something humans should hand-maintain separately for each runtime.
+
+The active context for an agent is assembled from:
+
+- repository source and owned files
+- wave markdown and shared plan docs
+- saved project defaults such as `.wave/project-profile.json`
+- the generated shared summary and the agent's inbox
+- resolved skills and runtime-specific skill projections
+- selected Context7 snippets for external library truth
+- generated executor overlays and launch artifacts
+
+That is why switching an agent between Codex, Claude, or OpenCode does not require maintaining separate parallel context files. The orchestrator recomputes the context package for the selected runtime and the current wave state.
+
+## What Makes A Wave "Done"
+
+A wave is not done because an agent said so. It is done only when the runtime surfaces agree:
+
+- implementation exit contracts pass
+- if present, design packets are complete and every design worker reports `ready-for-implementation`
+- required deliverables exist and stay within ownership boundaries
+- required proof artifacts exist when the wave declares proof-first live evidence
+- required component proof and promotions pass
+- helper assignments are resolved
+- required dependency tickets are resolved
+- clarification follow-ups or escalations are resolved
+- if present, `cont-EVAL` satisfies its declared eval targets
+- if present, the security reviewer publishes a report plus a final `[wave-security]` marker; `blocked` stops closure while `concerns` stays advisory
+- integration recommends closure
+- documentation and cont-QA closure pass
+
+For proof-first live-wave examples, see [docs/reference/live-proof-waves.md](../reference/live-proof-waves.md).
+
+## Where The State Lives
+
+The wave file is only part of the story. The runtime writes durable state under `.tmp/<lane>-wave-launcher/`, including:
+
+- prompts and logs
+- result envelopes
+- status summaries
+- coordination logs
+- rendered message boards
+- compiled inboxes
+- ledger and docs queue
+- security summaries
+- integration summaries
+- dependency snapshots
+- executor overlays
+- trace bundles
+
+That is why a wave is better understood as a bounded execution record, not just a markdown file.
+
+## Planner Specs vs Markdown
+
+The planner foundation adds a JSON draft spec at `docs/plans/waves/specs/wave-<n>.json`.
+
+- The JSON spec is the canonical planner artifact.
+- The rendered markdown stays compatible with the current parser and operator workflow.
+- Live execution decisions come from parsed wave definitions plus canonical state, not from treating markdown as the only execution authority.
+
+This split keeps authoring structured while preserving the established declaration surface.

package/docs/context7/bundles.json

@@ -0,0 +1,222 @@
+{
+  "version": 1,
+  "defaultBundle": "none",
+  "laneDefaults": {
+    "main": "none"
+  },
+  "bundles": {
+    "none": {
+      "description": "Disable Context7 prefetch for this run.",
+      "libraries": []
+    },
+    "node-typescript": {
+      "description": "Node.js and TypeScript runtime docs for JavaScript service and tooling work.",
+      "libraries": [
+        {
+          "libraryId": "/nodejs/node",
+          "queryHint": "runtime APIs, child processes, streams, filesystem behavior, and process lifecycle"
+        },
+        {
+          "libraryId": "/microsoft/typescript",
+          "queryHint": "types, declarations, module resolution, tsconfig, and compiler behavior"
+        }
+      ]
+    },
+    "planner-agentic": {
+      "description": "Placeholder bundle for the repo-local planner corpus. Keep this empty until the corpus is published to Context7 and an exact libraryId is known.",
+      "libraries": []
+    },
+    "word-editor-contracts": {
+      "description": "Precise docs for canonical schema, ProseMirror transaction semantics, and React host contracts.",
+      "libraries": [
+        {
+          "libraryId": "/prosemirror/website",
+          "queryHint": "schema design, positions, mappings, transactions, marks, and node contracts"
+        },
+        {
+          "libraryId": "/microsoft/typescript",
+          "queryHint": "discriminated unions, declaration files, strict typing, and module boundaries"
+        },
+        {
+          "libraryId": "/reactjs/react.dev",
+          "queryHint": "imperative handles, uncontrolled components, refs, and host integration boundaries"
+        }
+      ]
+    },
+    "word-editor-runtime": {
+      "description": "Runtime docs for ProseMirror-driven editor state, Node-based processing, and TypeScript contracts.",
+      "libraries": [
+        {
+          "libraryId": "/prosemirror/website",
+          "queryHint": "editor state, transaction application, decorations, plugin state, and mapping"
+        },
+        {
+          "libraryId": "/nodejs/node",
+          "queryHint": "buffers, streams, filesystem, child processes, and process behavior"
+        },
+        {
+          "libraryId": "/microsoft/typescript",
+          "queryHint": "type narrowing, generics, module resolution, and compiler behavior"
+        }
+      ]
+    },
+    "word-editor-ooxml": {
+      "description": "Precise OOXML and Open XML SDK docs for package handling, relationships, and validation behavior.",
+      "libraries": [
+        {
+          "libraryId": "/dotnet/open-xml-sdk",
+          "queryHint": "OpenXmlValidator, package parts, relationships, comments, revisions, and WordprocessingML"
+        },
+        {
+          "libraryId": "/websites/officeopenxml",
+          "queryHint": "OOXML packaging, markup compatibility, AlternateContent, and WordprocessingML structure"
+        },
+        {
+          "libraryId": "/nodejs/node",
+          "queryHint": "zip handling, buffers, streams, and filesystem operations for document processing"
+        }
+      ]
+    },
+    "word-editor-ui": {
+      "description": "UI-shell docs for React, Next.js, and TypeScript around host embedding and interaction surfaces.",
+      "libraries": [
+        {
+          "libraryId": "/reactjs/react.dev",
+          "queryHint": "refs, transitions, event handling, rendering, and component composition"
+        },
+        {
+          "libraryId": "/websites/nextjs",
+          "queryHint": "app router, server and client components, routing, and build behavior"
+        },
+        {
+          "libraryId": "/microsoft/typescript",
+          "queryHint": "JSX typing, declarations, and strict component prop contracts"
+        }
+      ]
+    },
+    "word-editor-testing": {
+      "description": "Precise testing docs for unit, integration, and browser-proof flows.",
+      "libraries": [
+        {
+          "libraryId": "/vitest-dev/vitest",
+          "queryHint": "unit tests, snapshots, mocking, coverage, and configuration"
+        },
+        {
+          "libraryId": "/microsoft/playwright",
+          "queryHint": "browser automation, fixtures, test isolation, and assertions"
+        },
+        {
+          "libraryId": "/reactjs/react.dev",
+          "queryHint": "testing interaction assumptions, forms, refs, and rendering expectations"
+        }
+      ]
+    },
+    "railway-harness": {
+      "description": "Precise docs for the internal Railway harness and its local persistence/runtime setup.",
+      "libraries": [
+        {
+          "libraryId": "/websites/nextjs",
+          "queryHint": "app router, route handlers, metadata, and production build behavior"
+        },
+        {
+          "libraryId": "/websites/railway",
+          "queryHint": "private networking, Dockerfile deploys, service variables, and volumes"
+        },
+        {
+          "libraryId": "/docker/docs",
+          "queryHint": "Dockerfile builds, multi-stage images, runtime env vars, and container networking"
+        },
+        {
+          "libraryId": "/websites/sqlite_docs",
+          "queryHint": "lightweight persistence, file-backed databases, schema basics, and transactions"
+        }
+      ]
+    },
+    "validator-dotnet": {
+      "description": "Precise docs for the .NET-based Open XML validator service.",
+      "libraries": [
+        {
+          "libraryId": "/dotnet/aspnetcore.docs",
+          "queryHint": "ASP.NET Core minimal APIs, multipart uploads, JSON responses, and hosting"
+        },
+        {
+          "libraryId": "/dotnet/open-xml-sdk",
+          "queryHint": "OpenXmlValidator, WordprocessingDocument, package inspection, and validation errors"
+        },
+        {
+          "libraryId": "/docker/docs",
+          "queryHint": "multi-stage .NET container builds, ports, and runtime images"
+        }
+      ]
+    },
+    "react-web": {
+      "description": "React and Next.js docs for frontend work.",
+      "libraries": [
+        {
+          "libraryId": "/reactjs/react.dev",
+          "queryHint": "components, hooks, rendering, forms, and data flow"
+        },
+        {
+          "libraryId": "/websites/nextjs",
+          "queryHint": "routing, server components, data fetching, and app router behavior"
+        }
+      ]
+    },
+    "python-services": {
+      "description": "Python backend docs for API and worker services.",
+      "libraries": [
+        {
+          "libraryId": "/websites/python_3",
+          "queryHint": "language features, packaging, typing, and standard library behavior"
+        },
+        {
+          "libraryId": "/fastapi/fastapi",
+          "queryHint": "routing, request validation, dependency injection, and OpenAPI behavior"
+        }
+      ]
+    },
+    "go-services": {
+      "description": "Go service and workflow docs for backend work.",
+      "libraries": [
+        {
+          "libraryId": "/websites/go_dev_ref_spec",
+          "queryHint": "language syntax, testing, concurrency, errors, and module semantics"
+        },
+        {
+          "libraryId": "/websites/pkg_go_dev",
+          "queryHint": "standard packages, modules, package layout, and reference behavior"
+        },
+        {
+          "libraryId": "/temporalio/documentation",
+          "queryHint": "workflow setup, activities, schedules, retries, and worker bootstrap"
+        }
+      ]
+    },
+    "persistence": {
+      "description": "Database and storage docs for persistence work.",
+      "libraries": [
+        {
+          "libraryId": "/websites/postgresql_current",
+          "queryHint": "schema changes, indexes, transactions, constraints, and query behavior"
+        },
+        {
+          "libraryId": "/websites/sqlite_docs",
+          "queryHint": "local persistence, fts, schema migration, and durability patterns"
+        }
+      ]
+    },
+    "infra-ops": {
+      "description": "Infrastructure and service-manager docs for deployment and operations work.",
+      "libraries": [
+        {
+          "libraryId": "/docker/docs",
+          "queryHint": "images, builds, volumes, networking, and runtime configuration"
+        },
+        {
+          "libraryId": "/websites/systemd_io",
+          "queryHint": "units, dependencies, restart policies, readiness, and service management"
+        }
+      ]
+    }
+  }
+}

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

@@ -0,0 +1,28 @@
+# 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`
+- committed repo config should stay empty until the planner corpus is published
+  and Context7 returns an exact `libraryId`
+- once published, record that returned `libraryId` in
+  `docs/context7/bundles.json` instead of committing a guessed library name
+
+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"
+    }
+  ]
+}