@chllming/wave-orchestration 0.5.4 → 0.6.0

package/docs/research/coordination-failure-review.md

@@ -0,0 +1,266 @@
+---
+title: "Coordination Failure Review"
+summary: "Assessment of whether the Wave orchestrator constructively addresses coordination and blackboard failure modes highlighted by recent multi-agent papers."
+---
+
+# Coordination Failure Review
+
+## Bottom Line
+
+The Wave orchestrator addresses several coordination failure modes constructively in code, not just in prose. In particular, it has:
+
+- a canonical machine-readable coordination log
+- compiled shared summaries plus per-agent inboxes
+- explicit clarification, helper-assignment, dependency, integration, documentation, and cont-QA barriers
+- structured proof and verdict validation
+- replayable trace bundles with coordination-quality metrics
+
+That is materially stronger than the common "agents talk in a shared channel and we hope that was enough" pattern criticized by recent multi-agent papers.
+
+The main weakness is empirical, not architectural. The repo does not yet contain a benchmark family that proves the blackboard actually helps agents reconstruct distributed state under HiddenBench or Silo-Bench style pressure, or that it handles DPBench-style simultaneous coordination reliably.
+
+## What The Papers Warn About
+
+### `Why Do Multi-Agent LLM Systems Fail?`
+
+This paper is the broadest warning. Its failure taxonomy groups problems into:
+
+- system design issues
+- inter-agent misalignment
+- task verification failures
+
+Those categories are useful here because they distinguish "we gave agents a shared workspace" from "the workspace is actually enforceable and auditable."
+
+### `HiddenBench` / `Systematic Failures in Collective Reasoning under Distributed Information in Multi-Agent LLMs`
+
+This is the clearest warning for blackboard-style systems. The central result is that multi-agent groups often fail not because they never communicated, but because they do not notice latent information asymmetry and do not actively surface unshared evidence. They converge on shared evidence too early.
+
+For this repo, the key question is therefore not "do agents have a board?" but "does the shared state force enough evidence pooling to avoid premature convergence?"
+
+### `Silo-Bench`
+
+Silo-Bench sharpens the same point. Agents can exchange information and even form reasonable communication topologies, yet still fail at the reasoning-integration step. Communication volume is not the same thing as distributed-state synthesis.
+
+For this repo, the corresponding question is whether summaries, inboxes, and integration passes merely move information around, or actually make the final decision depend on the integrated state.
+
+### `DPBench`
+
+DPBench shows that LLM teams can look coordinated in serial settings and still collapse in simultaneous coordination settings, with communication often failing to save them. Its practical lesson is that explicit external coordination mechanisms matter when concurrent access or simultaneous action is involved.
+
+For this repo, the relevant question is whether coordination is only conversational or whether there are explicit external barriers and tickets that serialize or block unsafe progress.
+
+### `Multi-Agent Teams Hold Experts Back`
+
+This paper argues that unconstrained teams underuse expertise. Even when the best agent is identifiable, teams often drift toward integrative compromise instead of properly weighting expert judgment.
+
+For this repo, the key question is whether the design relies on self-organizing consensus or on explicit role ownership, routing, and gating.
+
+## What This Repo Already Does Constructively
+
+### Implemented In Code And Tests
+
+#### 1. It uses a real canonical shared state, not a cosmetic board
+
+The strongest blackboard-like mechanism is the canonical JSONL coordination log plus materialized state in [scripts/wave-orchestrator/coordination-store.mjs](../../scripts/wave-orchestrator/coordination-store.mjs). The markdown board is explicitly a projection for humans, not the scheduler's source of truth, as stated in [docs/plans/wave-orchestrator.md](../plans/wave-orchestrator.md).
+
+That state is then compiled into:
+
+- a wave-level shared summary via `compileSharedSummary()`
+- targeted per-agent inboxes via `compileAgentInbox()`
+
+This is a real mitigation against information silos because agents are not expected to reconstruct the whole wave by rereading raw logs. The inbox compiler also pulls in relevant open coordination through `artifactRefs`, ownership, components, docs items, helper assignments, and dependencies. That behavior is exercised in [test/wave-orchestrator/coordination-store.test.ts](../../test/wave-orchestrator/coordination-store.test.ts).
+
+Assessment against the papers:
+
+- `HiddenBench`: partially addressed in design
+- `Silo-Bench`: partially addressed in design
+- proof that this works under benchmarked distributed-information pressure: missing
+
+#### 2. It makes completion depend on integrated state, not on agent self-report
+
+The launcher's gate stack in [scripts/wave-orchestrator/launcher.mjs](../../scripts/wave-orchestrator/launcher.mjs) is the clearest constructive safeguard in the repo. Closure is blocked by:
+
+- open clarifications
+- unresolved clarification-linked follow-up requests
+- pending human input
+- unresolved helper assignments
+- open required dependencies
+- integration failures
+- documentation closure failures
+- cont-EVAL failures
+- cont-QA failures
+
+This matters because several paper failure modes are really verification failures: agents say they are done, but the system has no hard check that the distributed state was reconciled. Here, the final decision is made by barrier logic rather than informal consensus.
+
+Tests in [test/wave-orchestrator/clarification-triage.test.ts](../../test/wave-orchestrator/clarification-triage.test.ts) and [test/wave-orchestrator/launcher.test.ts](../../test/wave-orchestrator/launcher.test.ts) confirm that routed clarification work remains blocking until the linked follow-up is resolved and that integration evidence is derived from coordination, docs, validation, and runtime signals.
+
+Assessment against the papers:
+
+- `Why Do Multi-Agent LLM Systems Fail?`: strong mitigation of task-verification failures
+- `Silo-Bench`: helps because integrated state has operational consequences
+- `DPBench`: helps by using external barriers instead of relying on emergent coordination alone
+
+#### 3. It validates structured evidence instead of trusting narrative summaries
+
+[scripts/wave-orchestrator/agent-state.mjs](../../scripts/wave-orchestrator/agent-state.mjs) validates structured markers for implementation proof, integration, cont-EVAL, documentation closure, and cont-QA verdicts. That means the orchestrator can reject:
+
+- missing proof markers
+- weaker completion or durability than promised
+- missing doc-delta markers
+- missing component evidence
+- missing deliverables
+- non-ready integration summaries
+- non-satisfied cont-EVAL outcomes
+- non-pass cont-QA gates
+
+This directly addresses the "don't kid yourself" critique behind the failure-taxonomy paper. A system that validates explicit proof contracts is much less vulnerable to premature closure than a system that trusts free-form role reports.
+
+Assessment against the papers:
+
+- `Why Do Multi-Agent LLM Systems Fail?`: strong mitigation for verification and termination failures
+- `Multi-Agent Teams Hold Experts Back`: indirect mitigation, because expert or steward judgment must still be grounded in evidence
+
+#### 4. It reduces naive self-organizing compromise through explicit ownership and routing
+
+The repo does not rely on free-form team consensus in the way criticized by `Multi-Agent Teams Hold Experts Back`. Instead it uses:
+
+- named stewardship roles such as integration and cont-QA in [docs/agents/wave-integration-role.md](../agents/wave-integration-role.md) and [docs/agents/wave-cont-qa-role.md](../agents/wave-cont-qa-role.md)
+- capability-targeted request routing in [scripts/wave-orchestrator/routing-state.mjs](../../scripts/wave-orchestrator/routing-state.mjs)
+- deterministic assignment based on explicit target, preferred agent, or least-busy capability owner
+- staged closure order documented in [docs/plans/current-state.md](../plans/current-state.md) and enforced in the launcher
+
+This is a constructive response to the paper's warning about teams averaging expert and non-expert views. The repo favors explicit owner selection and role-specific closure authority over emergent compromise.
+
+Assessment against the papers:
+
+- `Multi-Agent Teams Hold Experts Back`: partially addressed and better than unconstrained collaboration
+- not fully solved, because routing is based mostly on declared capability and load, not demonstrated expertise quality
+
+#### 5. It is unusually observable and replayable
+
+[scripts/wave-orchestrator/traces.mjs](../../scripts/wave-orchestrator/traces.mjs) and [scripts/wave-orchestrator/replay.mjs](../../scripts/wave-orchestrator/replay.mjs) give the system an unusually strong postmortem surface. A trace bundle includes:
+
+- raw coordination log
+- materialized coordination state
+- ledger
+- docs queue
+- integration summary
+- shared summary
+- copied prompts, logs, status, and inbox artifacts
+- structured signals
+- `quality.json`
+- replay metadata and outcome baseline
+
+The quality metrics include unresolved clarifications, contradiction count, capability-assignment timing, dependency-resolution timing, blocker-resolution timing, and fallback counts. Tests in [test/wave-orchestrator/traces.test.ts](../../test/wave-orchestrator/traces.test.ts) verify replay integrity and hash validation.
+
+This does not by itself solve coordination failure, but it is a serious safeguard against hidden failure modes because it makes them inspectable and replayable.
+
+Assessment against the papers:
+
+- `Why Do Multi-Agent LLM Systems Fail?`: strong support for diagnosis and failure analysis
+- `Silo-Bench` and `HiddenBench`: useful observability layer, but not yet a direct capability benchmark
+
+### Stated In Docs And Also Reflected In The Software
+
+The docs are not purely aspirational here. The main claims in [docs/plans/current-state.md](../plans/current-state.md) and [docs/plans/wave-orchestrator.md](../plans/wave-orchestrator.md) are broadly backed by the code:
+
+- canonical coordination log plus generated board
+- compiled shared summaries and per-agent inboxes
+- orchestrator-first clarification triage
+- blocking helper assignments and cross-lane dependencies
+- staged closure order
+- trace bundles and replay validation
+
+That alignment matters. In many MAS projects the docs promise a blackboard, but the runtime still reduces to prompt-only coordination. Here the repo's architectural claims are mostly real.
+
+## What Is Still Missing To Make The Claim Credible
+
+### 1. No distributed-information benchmark family yet
+
+The biggest gap is in [docs/evals/benchmark-catalog.json](../evals/benchmark-catalog.json). The current families are:
+
+- `service-output`
+- `latency`
+- `quality-regression`
+
+There is nothing yet for:
+
+- hidden-profile reconstruction
+- silo escape under partial information
+- blackboard consistency across raw log, summary, inboxes, ledger, and integration state
+- contradiction injection and recovery
+- simultaneous coordination under contention
+
+So the repo can reasonably claim "we built mechanisms intended to mitigate these failures," but it cannot yet claim "we demonstrated that these mechanisms overcome the failures highlighted by HiddenBench, Silo-Bench, or DPBench."
+
+### 2. Information integration is supported, but not measured directly
+
+The shared summary, inboxes, and integration pass are all constructive. But there is still no metric that asks:
+
+- Did the team reconstruct the globally correct hidden state?
+- Did the summary preserve the critical fact that was originally siloed?
+- Did a wave converge too early on shared evidence while missing private evidence?
+
+This is the central failure highlighted by `HiddenBench` and `Silo-Bench`, and the repo does not yet score it directly.
+
+### 3. Expertise routing is explicit, but shallow
+
+[scripts/wave-orchestrator/routing-state.mjs](../../scripts/wave-orchestrator/routing-state.mjs) is better than unconstrained self-organization, but it still routes mostly by:
+
+- explicit target
+- configured preferred agents
+- declared capability ownership
+- least-busy fallback
+
+It does not yet weight:
+
+- historical success on a capability
+- evidence quality by agent
+- confidence calibration
+- expert-leverage metrics
+
+So the repo partially addresses the concern from `Multi-Agent Teams Hold Experts Back`, but it does not yet prove that the best agent's expertise is actually being exploited rather than merely named.
+
+### 4. Clarification and contradiction handling are still somewhat heuristic
+
+Clarification triage and integration evidence aggregation are real safeguards, but they still lean heavily on:
+
+- ownership mappings
+- artifact references
+- structured markers
+- text-level summaries and conflict extraction
+
+That is enough to make the runtime operationally safer, but it is not yet a richer semantic evidence-integration layer. Subtle contradictions or latent information asymmetries may still be missed.
+
+### 5. DPBench-style simultaneous coordination is only indirectly addressed
+
+The repo already uses external coordination mechanisms such as blocking assignments, dependency tickets, and closure barriers. That is directionally aligned with DPBench's lesson that explicit external coordination beats naive emergent coordination.
+
+But there is still no direct stress harness for:
+
+- simultaneous resource contention
+- many-way concurrent dependencies
+- lock-step coordination failures
+- deadlock-like patterns caused by convergent reasoning
+
+So the design points in the right direction, but the claim is not yet validated.
+
+## Gap Matrix
+
+| Paper | Main warning | Repo response | Assessment |
+| --- | --- | --- | --- |
+| [Why Do Multi-Agent LLM Systems Fail?](https://arxiv.org/abs/2503.13657) | MAS fail through bad system design, misalignment, and weak verification | Canonical coordination state, barrier-based closure, structured evidence validation, replayable traces | Addressed materially in architecture and software |
+| [Systematic Failures in Collective Reasoning under Distributed Information in Multi-Agent LLMs](https://arxiv.org/abs/2505.11556) | Teams miss latent information asymmetry and converge too early on shared evidence | Shared summaries, per-agent inboxes, integration steward, clarification flow | Partially addressed in design, not validated empirically |
+| [Silo-Bench](https://arxiv.org/abs/2603.01045) | Communication is not enough; reasoning integration is the bottleneck | Integration evidence aggregation and barrier-driven closure | Partially addressed in design, but no direct integration-quality benchmark |
+| [DPBench](https://arxiv.org/abs/2602.13255) | Simultaneous coordination can fail badly even with communication | External helper assignments, dependency barriers, explicit blocking workflow | Directionally addressed, but not benchmarked under simultaneous contention |
+| [Multi-Agent Teams Hold Experts Back](https://arxiv.org/abs/2602.01011) | Self-organizing teams underuse experts and drift toward compromise | Named stewards, explicit role authority, capability routing, proof gates | Better than naive teams, but expertise leverage is not measured or optimized deeply |
+
+## Final Assessment
+
+If the standard is "does this repo merely claim multi-agent coordination," the answer is no. It has real machinery for blackboard-like state sharing, evidence-based closure, clarification handling, and coordination diagnostics.
+
+If the standard is "has this repo already demonstrated that its design beats the core failure modes isolated by HiddenBench, Silo-Bench, DPBench, and related work," the answer is also no. The design is substantially more credible than most MAS stacks, but the empirical proof is still missing.
+
+The most accurate claim today is:
+
+> Wave already implements several constructive anti-failure mechanisms for coordination and blackboard-style orchestration, especially around shared state, gating, and observability. What it still lacks is a benchmark suite that proves those mechanisms actually overcome distributed-information and simultaneous-coordination failures rather than simply organizing them better.

package/docs/roadmap.md

@@ -12,7 +12,7 @@ The repository already has the right runtime substrate:
 
 - lane-scoped state under `.tmp/`
 - wave parsing and validation
-- role-based execution with evaluator, integration, and documentation stewards
+- role-based execution with cont-qa, integration, and documentation stewards
 - executor profiles and lane runtime policy
 - compiled inboxes, ledgers, docs queues, dependency snapshots, and trace bundles
 - orchestrator-first clarification handling and human feedback workflows
@@ -76,14 +76,17 @@ CLI target:
 - `wave adhoc run --task "..." [--task "..."]`
 - `wave adhoc list`
 - `wave adhoc show --run <id>`
+- `wave adhoc promote --run <id> --wave <n>`
 
 Behavior:
 
 - accept one or more free-form task requests
 - normalize them into a single transient plan or spec
-- synthesize the worker roles needed for the request while still preserving evaluator, integration, and documentation closure when relevant
+- synthesize the worker roles needed for the request while still preserving cont-qa, integration, and documentation closure when relevant
 - run that transient plan through the existing launcher, coordination, inbox, ledger, docs queue, integration, and trace machinery
 - keep ad-hoc runs logged, inspectable, and replayable with the same basic operator surfaces as roadmap waves
+- route shared-plan documentation deltas into the canonical shared docs queue, plus an ad-hoc closure report for the run
+- treat only repo-local paths as ownership hints and ignore external references such as URLs
 
 Storage model:
 
@@ -98,6 +101,7 @@ Design constraints:
 - treat ad-hoc as a transient single-run execution unit, not a fake roadmap wave
 - do not let ad-hoc completion mutate normal `completedWaves` lane state
 - give `wave coord`, `wave feedback`, and future replay or reporting flows a way to target `--run <id>`
+- promote numbered roadmap artifacts from the stored ad-hoc spec instead of recomputing them from the current project profile
 
 Why this matters:
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chllming/wave-orchestration",
-  "version": "0.5.4",
+  "version": "0.6.0",
   "license": "MIT",
   "description": "Generic wave-based multi-agent orchestration for repository work.",
   "repository": {
@@ -39,7 +39,7 @@
   },
   "scripts": {
     "context7:api-check": "bash scripts/context7-export-env.sh run bash scripts/context7-api-check.sh",
-    "research:import-agent-context": "node scripts/research/import-agent-context-archive.mjs scripts/research/manifests/harness-and-blackboard-2026-03-21.mjs",
+    "research:import-agent-context": "node scripts/research/import-agent-context-archive.mjs scripts/research/manifests/agent-context-expanded-2026-03-22.mjs",
     "research:index-agent-context": "node scripts/research/generate-agent-context-indexes.mjs",
     "research:refresh-agent-context": "pnpm research:import-agent-context && pnpm research:index-agent-context",
     "test": "vitest run --config vitest.config.ts",

package/releases/manifest.json

@@ -2,6 +2,24 @@
   "schemaVersion": 1,
   "packageName": "@chllming/wave-orchestration",
   "releases": [
+    {
+      "version": "0.6.0",
+      "date": "2026-03-22",
+      "summary": "Closure-role split, benchmark-governed cont-EVAL, security review, ad-hoc runs, and expanded skills and docs.",
+      "features": [
+        "The closure model now treats `cont-EVAL` (`E0`) as an optional first-class eval stage before integration and keeps `cont-QA` (`A0`) as the final release verdict owner, with dedicated validation and report requirements for each role.",
+        "Wave authoring now includes a benchmark catalog under `docs/evals/benchmark-catalog.json`, wave-level `## Eval targets`, and planner, launcher, and validation support for delegated versus pinned eval contracts.",
+        "Optional report-only security review now has its own role prompt, validation path, `[wave-security]` marker, security summaries, and closure-stage sequencing.",
+        "Operators can now run transient ad-hoc work through `wave adhoc plan|run|show|promote`, with generated specs, launcher-compatible markdown, isolated runtime state, and promotion back into numbered roadmap artifacts.",
+        "The starter docs and skills surface now ship richer role, runtime, deploy-kind, provider, and proof-first guidance across the package-owned `docs/` and `skills/` trees."
+      ],
+      "manualSteps": [
+        "After upgrading, update any repo-owned `evaluator` role references to the new `cont-QA` plus optional `cont-EVAL` split before running live waves.",
+        "If a wave uses `cont-EVAL`, declare `## Eval targets` at the wave level and keep benchmark ids inside `docs/evals/benchmark-catalog.json`.",
+        "Run `pnpm exec wave doctor` and `pnpm exec wave launch --lane main --dry-run --no-dashboard` after upgrading so the stricter closure, skill, and security validation paths can fail fast before live execution."
+      ],
+      "breaking": false
+    },
     {
       "version": "0.5.4",
       "date": "2026-03-22",
@@ -24,7 +42,7 @@
       "date": "2026-03-22",
       "summary": "Closure-sweep launch ordering fix for implementation-first wave execution.",
       "features": [
-        "The launcher now starts only implementation agents in the initial wave pass when implementation work remains, deferring integration, documentation, and evaluator roles until closure sweep order.",
+        "The launcher now starts only implementation agents in the initial wave pass when implementation work remains, deferring integration, documentation, and cont-qa roles until closure sweep order.",
         "Wave waiting, dashboard progress refresh, and human-feedback monitoring now scope to the runs launched in the current pass so deferred closure agents no longer create false pending or missing-status failures.",
         "Regression coverage now exercises both mixed implementation/closure waves and closure-only retry waves directly."
       ],
@@ -136,7 +154,7 @@
       "features": [
         "Canonical coordination log materialization, generated board projection, compiled shared summary, per-agent inboxes, and a durable wave ledger.",
         "Planning-time executor profiles, lane runtime policy, hard runtime-mix enforcement, and retry fallback reassignment recorded into ledger, integration, and traces.",
-        "Orchestrator-first clarification triage, explicit integration summaries, and staged closure that runs integration before documentation and evaluator closure."
+        "Orchestrator-first clarification triage, explicit integration summaries, and staged closure that runs integration before documentation and cont-qa closure."
       ],
       "manualSteps": [
         "Run `pnpm exec wave init --adopt-existing` in older repos if they do not yet have the newer role prompts and docs surfaces.",

package/scripts/research/agent-context-archive.mjs

@@ -8,12 +8,24 @@ export const TOPIC_DEFINITIONS = [
     description:
       "Current guidance and recent papers on agent harness design, reviewer loops, terminal-native execution, and practical coding-agent workflows.",
   },
+  {
+    id: "planning-and-orchestration",
+    title: "Planning and Orchestration",
+    description:
+      "Planning topology, verifier and replanner loops, protocol-driven coordination, and blackboard-aware orchestration patterns for multi-agent systems.",
+  },
   {
     id: "long-running-agents-and-compaction",
     title: "Long-Running Agents and Compaction",
     description:
       "Long-horizon execution, resumability, memory systems, compaction, and evolving-task evaluation for agents that span many sessions.",
   },
+  {
+    id: "skills-and-procedural-memory",
+    title: "Skills and Procedural Memory",
+    description:
+      "Reusable skills, procedural memory, workflow induction, skill libraries, and evaluation patterns for agents that improve through reusable procedures.",
+  },
   {
     id: "blackboard-and-shared-workspaces",
     title: "Blackboard and Shared Workspaces",
@@ -26,6 +38,12 @@ export const TOPIC_DEFINITIONS = [
     description:
       "Repository-level context files, harness evaluation methods, and evidence on what improves or harms coding-agent performance.",
   },
+  {
+    id: "security-and-secure-code-generation",
+    title: "Security and Secure Code Generation",
+    description:
+      "Secure code generation, repair and analyzer loops, repository-grounded security benchmarks, and security/privacy risks in multi-agent systems.",
+  },
 ];
 
 export const PAPER_SECTION_ORDER = [
@@ -47,6 +65,44 @@ const TOPIC_OVERRIDE_MAP = {
     ["repo-context-and-evaluation"],
 };
 
+const PLANNING_TOPIC_OVERRIDE_SLUGS = new Set([
+  "building-effective-ai-coding-agents-for-the-terminal-scaffolding-harness-context-engineering-and-lessons-learned",
+  "vero-an-evaluation-harness-for-agents-to-optimize-agents",
+  "evoclaw-evaluating-ai-agents-on-continuous-software-evolution",
+  "exploring-advanced-llm-multi-agent-systems-based-on-blackboard-architecture",
+  "llm-based-multi-agent-blackboard-system-for-information-discovery-in-data-science",
+  "dova-deliberation-first-multi-agent-orchestration-for-autonomous-research-automation",
+  "symphony-synergistic-multi-agent-planning-with-heterogeneous-language-model-assembly",
+  "silo-bench-a-scalable-environment-for-evaluating-distributed-coordination-in-multi-agent-llm-systems",
+  "terrarium-revisiting-the-blackboard-for-multi-agent-safety-privacy-and-security-studies",
+  "macc-multi-agent-collaborative-competition-for-scientific-exploration",
+  "the-orchestration-of-multi-agent-systems-architectures-protocols-and-enterprise-adoption",
+  "describing-agentic-ai-systems-with-c4-lessons-from-industry-projects",
+  "verified-multi-agent-orchestration-a-plan-execute-verify-replan-framework-for-complex-query-resolution",
+  "todoevolve-learning-to-architect-agent-planning-systems",
+  "parallelized-planning-acting-for-efficient-llm-based-multi-agent-systems-in-minecraft",
+  "orchmas-orchestrated-reasoning-with-multi-collaborative-heterogeneous-scientific-expert-structured-agents",
+  "towards-engineering-multi-agent-llms-a-protocol-driven-approach",
+  "advancing-multi-agent-systems-through-model-context-protocol-architecture-implementation-and-applications",
+  "enhancing-model-context-protocol-mcp-with-context-aware-server-collaboration",
+  "why-do-multi-agent-llm-systems-fail",
+  "systematic-failures-in-collective-reasoning-under-distributed-information-in-multi-agent-llms",
+  "dpbench-large-language-models-struggle-with-simultaneous-coordination",
+  "multi-agent-teams-hold-experts-back",
+  "a-survey-on-llm-based-multi-agent-systems-workflow-infrastructure-and-challenges",
+  "llm-based-multi-agent-systems-for-software-engineering-literature-review-vision-and-the-road-ahead",
+  "a-taxonomy-of-hierarchical-multi-agent-systems-design-patterns-coordination-mechanisms-and-industrial-applications",
+  "blackboard-systems-part-one-the-blackboard-model-of-problem-solving-and-the-evolution-of-blackboard-architectures",
+  "a-blackboard-architecture-for-control",
+  "incremental-planning-to-control-a-blackboard-based-problem-solver",
+  "blackboard-systems",
+]);
+
+const SKILLS_TOPIC_OVERRIDE_SLUGS = new Set([
+  "memory-for-autonomous-llm-agents-mechanisms-evaluation-and-emerging-frontiers",
+  "meta-context-engineering-via-agentic-skill-evolution",
+]);
+
 function escapeInlinePipes(value) {
   return String(value ?? "").replaceAll("|", "\\|");
 }
@@ -189,8 +245,15 @@ export function inferTopics(entry, section = null) {
   if (override) {
     topics.push(...override);
   }
+  const hasDeclaredTopics = topics.length > 0;
+  if (PLANNING_TOPIC_OVERRIDE_SLUGS.has(entry.slug)) {
+    topics.push("planning-and-orchestration");
+  }
+  if (SKILLS_TOPIC_OVERRIDE_SLUGS.has(entry.slug)) {
+    topics.push("skills-and-procedural-memory");
+  }
 
-  if (topics.length > 0) {
+  if (hasDeclaredTopics) {
     return unique(topics);
   }
 
@@ -220,12 +283,28 @@ export function inferTopics(entry, section = null) {
     topics.push("long-running-agents-and-compaction");
   }
 
+  if (
+    /skill|procedural memory|workflow memory|skill library|voyager|toolformer|tool makers|synapse|expel|reuseit|skillweaver|procmem|memskill|memento-skills|metaclaw/.test(
+      haystack,
+    )
+  ) {
+    topics.push("skills-and-procedural-memory");
+  }
+
   if (
     entry.kind === "article" || /harness|codex|terminal|engineering|reviewer|agent-first/.test(haystack)
   ) {
     topics.push("harnesses-and-practice");
   }
 
+  if (
+    /security|secure code|secure coding|vulnerability|vulnerabilities|cve|static analyzer|codeql|secureagentbench|secrepobench|secodeplt|tosss|privacy/.test(
+      haystack,
+    )
+  ) {
+    topics.push("security-and-secure-code-generation");
+  }
+
   if (topics.length === 0) {
     topics.push(entry.kind === "article" ? "harnesses-and-practice" : "long-running-agents-and-compaction");
   }
@@ -346,9 +425,12 @@ of the repository docs.
 ## Coverage
 
 - Harnesses and practice
+- Planning and orchestration
 - Long-running agents and compaction
+- Skills and procedural memory
 - Blackboard and shared workspaces
 - Repo context and evaluation
+- Security and secure code generation
 
 ${sections.join("\n\n")}
 `;