@its-not-rocket-science/ananke 0.1.69 → 0.5.4

package/docs/plugins/security-model.md

@@ -0,0 +1,273 @@
+# Plugin Security Threat Model
+
+This document defines the production threat model for loading Ananke plugins and maps risks to concrete controls.
+
+> **Security posture summary:** `loadPlugin(...)` is a capability-loading API, not a turnkey sandbox.
+> For trusted/internal plugins, the default runtime may be acceptable with guardrails.
+> For untrusted/third-party plugins, production deployments should use stronger isolation and policy controls than the defaults.
+
+## Scope and assumptions
+
+### In scope
+
+- Plugin loading and execution through `loadPlugin(...)` in `src/plugins/loader.ts`.
+- Manifest-declared permissions from `plugin.json`.
+- Runtime API capabilities exposed to plugin code (`readWorldState`, `mutateWorld`, `emitTelemetry`, `writeArtifact`).
+- Host-side operational controls (timeouts, quotas, process isolation, filesystem layout, incident response).
+
+### Out of scope
+
+- Formal verification of sandbox correctness.
+- Side-channel resistance (timing/cache/CPU microarchitectural channels).
+- Supply-chain compromise of host dependencies outside the plugin subsystem.
+
+### Security assumptions
+
+- Plugin authors can be buggy, negligent, or malicious.
+- Plugin source may come from public registries.
+- Host application owns final policy decisions (what to load, where to execute, and with what privileges).
+
+---
+
+## Assets and security objectives
+
+### Assets to protect
+
+- **Simulation integrity:** world-state correctness and expected game/runtime behavior.
+- **Host availability:** CPU, memory, I/O capacity, and event-loop responsiveness.
+- **Confidentiality of runtime data:** world state, event streams, secrets accidentally present in context, and generated artifacts.
+- **Artifact integrity:** downstream consumers should not be misled or compromised by plugin outputs.
+- **Operational trust:** telemetry quality, audit trail accuracy, and incident recovery capability.
+
+### Objectives
+
+- Prevent unauthorized access to privileged host capabilities.
+- Limit blast radius of malicious/buggy plugin code.
+- Detect and contain abuse quickly.
+- Preserve ability to disable/revoke problematic plugins without full service outage.
+
+---
+
+## Trust boundaries
+
+1. **Plugin source boundary**
+   - Boundary between host-controlled codebase and external plugin package (`plugin.json`, `index.js`).
+   - Threat: malicious payloads, deceptive manifests, dependency confusion, tampering in transit.
+
+2. **Manifest-to-policy boundary**
+   - Plugin declares permissions; host decides whether to honor them.
+   - Threat: over-broad permissions granted without review.
+
+3. **Evaluator boundary**
+   - Default evaluator uses `node:vm` minimal CommonJS sandbox.
+   - Threat: evaluator escape, context confusion, unsafe API exposure.
+
+4. **Runtime capability boundary**
+   - Only methods on `PluginRuntimeApi` should be reachable.
+   - Threat: capability abuse once permission is granted.
+
+5. **Hook execution boundary**
+   - Plugin handlers execute inside host lifecycle (`runHook`).
+   - Threat: unbounded runtime, blocking, starvation, exception abuse.
+
+6. **Artifact storage boundary**
+   - Plugin writes data into artifact filesystem namespace.
+   - Threat: disk exhaustion, path manipulation, poisoned outputs for downstream tools.
+
+7. **Telemetry boundary**
+   - Plugin can emit host-collected telemetry (if permitted).
+   - Threat: exfiltration channel, log/metric poisoning, operational blind spots.
+
+---
+
+## Attacker model and capabilities
+
+Assume an attacker can publish and convince operators to load a plugin. Once loaded, attacker-controlled code can:
+
+- Execute arbitrary JavaScript **within the evaluator constraints**.
+- Run hook handlers repeatedly at lifecycle trigger points.
+- Use all granted runtime capabilities and intentionally stress their edge cases.
+- Craft high-entropy payloads, large objects, and malformed outputs.
+- Attempt to trigger evaluator/runtime bugs for sandbox escape.
+- Abuse expected channels (telemetry/artifacts) for covert exfiltration.
+
+Assume attacker **cannot** directly modify host binaries/config unless another vulnerability exists.
+
+---
+
+## Threat analysis by category
+
+## 1) Sandbox escape
+
+### Risk
+
+The default Node path uses in-process `node:vm` with minimal bindings. This reduces accidental access to host globals but should not be treated as a complete hostile-code isolation boundary.
+
+### Consequences
+
+- Access to host process memory or APIs.
+- Filesystem/network/process execution beyond intended plugin API.
+- Full compromise of host trust domain.
+
+### Controls
+
+- **Recommended for untrusted plugins:** out-of-process isolation (worker/process/container/VM) with explicit IPC protocol.
+- Restrict host OS/container privileges (filesystem, network egress, Linux capabilities, syscall surface where possible).
+- Keep evaluator/runtime patched and regression-tested with adversarial test corpus.
+
+## 2) Host capability abuse
+
+### Risk
+
+Even without sandbox escape, allowed API methods can be abused:
+
+- `write:worldState`: integrity compromise and subtle gameplay manipulation.
+- `write:telemetry`: spam, poisoning, or covert leakage of sensitive context.
+- `write:artifacts`: disk abuse, misleading reports, malicious payload staging.
+
+### Controls
+
+- Permission minimization and explicit approval workflow per plugin.
+- Host policy overlays (allow-list metrics, artifact path patterns, hook-level gates).
+- Auditing that binds action to plugin ID + hook + timestamp.
+
+## 3) Denial of service (DoS)
+
+### Risk
+
+- Expensive synchronous loops in hooks.
+- High-frequency hook abuse causing event-loop starvation.
+- Memory blowups via oversized payloads/artifacts.
+- Flooding telemetry/artifact outputs.
+
+### Controls
+
+- Per-hook timeout and cancellation policy.
+- CPU/memory quotas and isolation boundaries.
+- Per-plugin rate/size quotas for telemetry and artifacts.
+- Circuit breakers / kill switches for misbehaving plugins.
+
+## 4) Artifact exfiltration and poisoning
+
+### Risk
+
+Artifacts can become a data-exfiltration and downstream-attack channel.
+
+- Sensitive context serialized to files and exported by external systems.
+- Filename/content tricks that confuse parsers or operators.
+- Excess artifact churn masking malicious outputs.
+
+### Controls
+
+- Canonical path verification under approved root.
+- File extension/content-type policy for machine-consumed artifacts.
+- Quotas + retention windows + malware/content scanning where appropriate.
+- Segregated storage and reduced read access for consumers.
+
+## 5) Telemetry exfiltration and poisoning
+
+### Risk
+
+Telemetry is an intentional output channel and can be abused for covert transfer or operational deception.
+
+### Controls
+
+- Schema validation, size limits, namespace allow-listing.
+- Per-plugin event-rate quotas and anomaly detection.
+- Separate internal-only metrics from plugin-controlled streams.
+
+---
+
+## Browser vs Node threat differences
+
+## Node hosts
+
+- Default implementation path is in-process `node:vm` evaluation.
+- Primary risk: single-process compromise blast radius if evaluator boundary fails.
+- Strong recommendation for untrusted code: separate process/container with restricted OS permissions and explicit IPC API.
+
+## Browser hosts
+
+- Preferred model is dedicated Web Worker execution with message-passed runtime API.
+- Strength: better separation from UI thread by default.
+- Residual risks: message validation bugs, resource exhaustion in worker, data leakage through postMessage channels.
+
+## Shared principle
+
+In both environments, plugin security is primarily achieved by **defense in depth**: strict capability policy + isolation + quotas + monitoring + incident response.
+
+---
+
+## Trusted vs untrusted plugin deployment recommendations
+
+## Trusted/internal plugins (same organization, reviewed source)
+
+Minimum recommended controls:
+
+- Enforce least-privilege permissions.
+- CI validation and pinned versions.
+- Audit logs for mutations, telemetry, and artifact writes.
+- Operational kill switch.
+
+## Untrusted/third-party plugins (public/community source)
+
+Production recommended controls:
+
+- Do not rely on default in-process evaluator alone.
+- Run in isolated trust domain (process/container/worker with hardened IPC).
+- Apply strict runtime budgets (time, memory, output volume).
+- Require policy review before enablement.
+- Continuous monitoring + fast revocation/rollback path.
+
+---
+
+## Guaranteed today vs deployment hardening vs future work
+
+## Guaranteed today (based on current implementation)
+
+The following are implemented in `src/plugins/loader.ts` / `src/plugins/types.ts`:
+
+- Plugin evaluation uses minimal CommonJS sandbox with `node:vm` by default.
+- Initial module evaluation is constrained with a 100 ms VM timeout.
+- Runtime permission checks enforce:
+  - `mutateWorld` requires `write:worldState`
+  - `emitTelemetry` requires `write:telemetry`
+  - `writeArtifact` requires `write:artifacts`
+- `readWorldState` returns deep-frozen `structuredClone` data.
+- Artifacts are written under `<artifactsRoot>/<pluginId>/<path>`.
+- Host can provide custom `evaluator` option.
+
+## Recommended deployment hardening (not guaranteed by default)
+
+- Isolate untrusted plugins out of process.
+- Enforce per-hook timeout/cancellation and runtime budgets.
+- Enforce memory, telemetry, and artifact quotas.
+- Canonicalize and verify artifact paths remain under approved root.
+- Restrict telemetry schemas/namespaces.
+- Run with least-privilege OS/container identity.
+- Implement deny-list/revocation and one-click disable.
+
+## Future work (explicitly not complete today)
+
+- First-class built-in hook timeout/cancellation in core runtime.
+- Built-in quota manager for telemetry/artifacts and payload sizes.
+- Stronger default path canonicalization and artifact policy controls.
+- Optional signed plugin manifests/modules and provenance verification.
+- Security event stream spec for standardized audit integrations.
+
+---
+
+## Deployment checklist
+
+A standalone checklist is maintained in:
+
+- `docs/plugins/deployment-checklist.md`
+
+Use that checklist during production readiness and change reviews.
+
+---
+
+## Implementation evidence
+
+- `src/plugins/loader.ts`
+- `src/plugins/types.ts`

package/docs/project-overview.md

@@ -21,8 +21,8 @@ built on top of that foundation and can be adopted independently.
 npm install @its-not-rocket-science/ananke
 ```
 
-```typescript
-import { stepWorld, mkWorld, q, SCALE } from "@its-not-rocket-science/ananke";
+```typescript pseudocode
+import { stepWorld, createWorld, q, SCALE } from "@its-not-rocket-science/ananke";
 ```
 
 Requires **Node ≥ 18**. TypeScript declarations are included — no `@types/` package needed.
@@ -49,14 +49,14 @@ Choose the path that matches your immediate need.  Ignore the rest until you nee
 
 **Install:** `npm install @its-not-rocket-science/ananke`
 
-**Minimal imports:** `stepWorld`, `mkWorld`, `q`, `SCALE`, `generateIndividual`
+**Minimal imports:** `createWorld`, `stepWorld`, `q`, `SCALE`
 
 **30-minute quickstart:** Run `tools/vertical-slice.ts` (`npm run run:vertical-slice`).
 A Knight fights a Brawler across three seeds, producing a physics-grounded combat log.
 Read `docs/host-contract.md` for the stable integration surface, then
 `docs/integration-primer.md` for data-flow diagrams and type glossary.
 
-**Key entry points:** `stepWorld()`, `resolveHit()`, `generateIndividual()`, `mkKnight()`
+**Key entry points:** `createWorld()`, `stepWorld()` (+ Tier 2/3 subpaths as needed)
 
 **What to ignore for now:** Phases 56–67 (campaign-scale systems), all `tools/` except `vertical-slice.ts`
 
@@ -171,7 +171,7 @@ variance distributions, producing a unique entity with realistic physical spread
 
 ## Current implementation status
 
-**Phases 1–60 complete** (including Phase 6 Formation System, 2ext, 3ext, 8B, 8C, 10B, 10C, 11C, 12B, 31–60). Melee combat,
+**Phases 1–60 are implemented and integrated in-repo** (including Phase 6 Formation System, 2ext, 3ext, 8B, 8C, 10B, 10C, 11C, 12B, 31–60). Maturity labels and validation status are tracked separately in `docs/maturity-matrix.md`. Melee combat,
 grappling, stamina and exhaustion, weapon dynamics (including swing momentum carry), ranged
 and projectile combat (including aiming time, moving target penalty, suppression→AI behaviour,
 and ammo type overrides), injury, entity environmental hazards, movement physics, formation
@@ -655,7 +655,7 @@ an entity, each operating on a different time scale and requiring different inte
 
 ## Quick start
 
-```typescript
+```typescript no-check-example
 import { stepWorld, TICK_HZ } from "./src/sim/kernel.js";
 import { STARTER_WEAPONS } from "./src/equipment.js";
 import { HUMAN_BASE } from "./src/archetypes.js";
@@ -1028,7 +1028,7 @@ Effects activate when concentration exceeds `effectThreshold`:
 
 `TechContext` gates which items are usable in a scenario without locking them to a specific era.
 
-```typescript
+```typescript no-check-example
 import { TechEra, defaultTechContext, isCapabilityAvailable } from "./src/sim/tech.js";
 import { validateLoadout, STARTER_EXOSKELETONS } from "./src/equipment.js";
 
@@ -1083,7 +1083,7 @@ Attached to `entity.capabilitySources?: CapabilitySource[]`. Each source is an e
 
 ### ActivateCommand
 
-```typescript
+```typescript no-check-example
 { kind: "activate", sourceId: string, effectId: string, targetId?: number, targetPos?: Vec3 }
 ```
 
@@ -1130,7 +1130,7 @@ Attached to `entity.capabilitySources?: CapabilitySource[]`. Each source is an e
 `src/model3d.ts` provides pure data-extraction functions for driving 3D character rigs from
 simulation state. No kernel changes, no state mutations. Call once per tick after `stepWorld`.
 
-```typescript
+```typescript no-check-example
 import { extractRigSnapshots } from "./src/model3d.js";
 
 const snapshots = extractRigSnapshots(world);
@@ -1233,7 +1233,7 @@ Each entity carries an optional `skills?: SkillMap` (`Map<SkillId, SkillLevel>`)
 When a skill is absent, `getSkill()` returns neutral defaults (no effect on simulation output),
 making all existing entities fully backward-compatible.
 
-```typescript
+```typescript no-check-example
 import { buildSkillMap } from "./src/sim/skills.js";
 
 entity.skills = buildSkillMap({
@@ -1263,7 +1263,7 @@ entity.skills = buildSkillMap({
 `combineSkillLevels(a, b)` multiplies Q fields and adds time offsets, letting the host express
 synergy bonuses or composite experience modifiers before building the SkillMap:
 
-```typescript
+```typescript no-check-example
 import { combineSkillLevels, defaultSkillLevel } from "./src/sim/skills.js";
 
 // Melee expert with an athleticism timing synergy (−0.25 s total)
@@ -1284,7 +1284,7 @@ Every simulation is reproducible from initial state + command log. `ReplayRecord
 the world before the first tick and records command maps per tick. `replayTo` reconstructs
 any past tick by restoring the snapshot and re-applying frames.
 
-```typescript
+```typescript no-check-example
 import { ReplayRecorder, replayTo, serializeReplay, deserializeReplay } from "./src/replay.js";
 
 const recorder = new ReplayRecorder(world);
@@ -1310,7 +1310,7 @@ const worldAt50Again = replayTo(restored, 50, ctx);
 `CollectingTrace` implements `TraceSink` and accumulates all trace events for offline
 analysis. Pass it to `stepWorld` via `ctx.trace`, then extract metrics.
 
-```typescript
+```typescript no-check-example
 import { CollectingTrace, collectMetrics, survivalRate, meanTimeToIncapacitation }
   from "./src/metrics.js";
 
@@ -1332,7 +1332,7 @@ pass over any flat `TraceEvent[]` — ordering and tick mixing are fine.
 `extractMotionVectors`, `extractHitTraces`, and `extractConditionSamples` in `src/debug.ts`
 transform world state and trace events into renderer-friendly snapshots:
 
-```typescript
+```typescript no-check-example
 import { extractMotionVectors, extractHitTraces, extractConditionSamples } from "./src/debug.js";
 import { CollectingTrace } from "./src/metrics.js";
 
@@ -1360,7 +1360,7 @@ const pastHeatmap = extractConditionSamples(past);
 `src/describe.ts` translates raw SI fixed-point attributes into human-readable summaries.
 No simulation dependencies — safe to import from any host application.
 
-```typescript
+```typescript no-check-example
 import { describeCharacter, formatCharacterSheet, formatOneLine } from "./src/describe.js";
 import { generateIndividual } from "./src/generate.js";
 import { PRO_BOXER } from "./src/archetypes.js";
@@ -1403,7 +1403,7 @@ Reaction time and decision latency use an **inverted** scale (lower value = high
 
 ### API
 
-```typescript
+```typescript no-check-example
 describeCharacter(attrs: IndividualAttributes): CharacterDescription
 // Returns a structured object with tier, label, comparison string, and formatted value
 // for every attribute. Vision and hearing are formatted strings (e.g. "200 m, 120° arc").
@@ -1422,7 +1422,7 @@ formatOneLine(desc: CharacterDescription): string
 `src/narrative.ts` converts raw `TraceEvent` streams into human-readable text. Like
 `src/describe.ts`, it has no simulation dependencies — safe to import from UI code or CLI tools.
 
-```typescript
+```typescript no-check-example
 import { narrateEvent, buildCombatLog, describeInjuries, describeCombatOutcome }
   from "./src/narrative.js";
 import { CollectingTrace } from "./src/metrics.js";
@@ -1501,7 +1501,7 @@ Set an entity's name to `"you"` in `nameMap` for second-person verb conjugation
 It runs a compressed 1 Hz loop applying the same healing physics as the kernel, suitable
 for computing wound outcomes, resource consumption, and recovery timelines between sessions.
 
-```typescript
+```typescript no-check-example
 import { stepDowntime, MEDICAL_RESOURCES } from "./src/downtime.js";
 
 const reports = stepDowntime(world, 3600, {
@@ -1532,7 +1532,7 @@ for (const r of reports) {
 
 `src/arena.ts` provides a declarative scenario DSL for batch-running combat trials with statistical expectations. Use it to validate simulation realism, balance archetypes, and author calibration tests.
 
-```typescript
+```typescript no-check-example
 import { runArena, expectWinRate, expectSurvivalRate, formatArenaReport }
   from "./src/arena.js";
 import { mkKnight, mkBoxer } from "./src/presets.js";
@@ -1567,7 +1567,7 @@ console.log(formatArenaReport(result));
 
 `src/progression.ts` adds the temporal axis: how entities improve through training and experience, decline through ageing, and carry permanent marks from injury. No simulation dependencies — safe to use in save-game serialisation and UI layers.
 
-```typescript
+```typescript no-check-example
 import {
   createProgressionState, awardXP, advanceSkill,
   applyTrainingSession, stepAgeing, applyAgeingDelta,
@@ -1617,7 +1617,7 @@ const json = serialiseProgression(prog);  // Map-aware JSON
 entity state, location, and item stockpiles between encounters, and delegates wound recovery
 to `stepDowntime`.
 
-```typescript
+```typescript no-check-example
 import {
   createCampaign, addLocation, travel,
   creditInventory, debitInventory, getInventoryCount,
@@ -1683,7 +1683,7 @@ entityInventories, entity skills, armourState, and location travelCost all survi
 strength comes from `peakForce_N`, persuasion from cognitive depth, deception is beaten by
 sharp minds. Fully deterministic when given a seed.
 
-```typescript
+```typescript no-check-example
 import {
   resolveDialogue, applyDialogueOutcome, narrateDialogue, dialogueProbability,
   type DialogueContext,
@@ -1741,7 +1741,7 @@ without rolling RNG. Useful for UI previews, AI decision-making, and testing.
 behaviour based on inter-faction relationships. Fully deterministic — no RNG, standing
 changes are pure arithmetic.
 
-```typescript
+```typescript no-check-example
 import {
   createFactionState, adjustStanding, getStanding,
   extractWitnessEvents, applyReputationDelta,
@@ -1764,7 +1764,7 @@ mode; the `factionGuard` preset additionally suppresses attack below standing `q
 `src/economy.ts` provides item valuation, equipment wear, loot drop resolution, and
 trade evaluation. No kernel dependency — pure data management.
 
-```typescript
+```typescript no-check-example
 import {
   computeItemValue, armourConditionQ, applyWear,
   resolveDrops, evaluateTradeOffer, totalInventoryValue,
@@ -1789,7 +1789,7 @@ impact now imparts a velocity delta to the target. Calibrated to real physics
 5.56 mm rifle round produces negligible knockback (≈ 0.05 m/s on 75 kg), while a
 large-creature kick can knock humans prone.
 
-```typescript
+```typescript no-check-example
 import {
   computeKnockback, applyKnockback,
   STAGGER_THRESHOLD_mps, PRONE_THRESHOLD_mps, STAGGER_TICKS,
@@ -1823,7 +1823,7 @@ projectiles. Above 600 m/s a temporary stretch wave radiates outward through
 inelastic tissue; above 900 m/s momentary vacuum cavitation further boosts
 haemorrhage in fluid-saturated organs.
 
-```typescript
+```typescript no-check-example
 import {
   computeTemporaryCavityMul, computeCavitationBleed,
   HYDROSTATIC_THRESHOLD_mps, CAVITATION_THRESHOLD_mps,
@@ -1857,7 +1857,7 @@ automatically in the finalImpacts loop — no changes to call sites required.
 `src/sim/cone.ts` adds directional cone geometry to the capability system, enabling
 breath weapons, flamethrowers, gas dispensers, and sonic disorientation blasts.
 
-```typescript
+```typescript no-check-example
 import { entityInCone, buildEntityFacingCone } from "./src/sim/cone.js";
 import type { CapabilityEffect, CapabilitySource } from "./src/sim/capability.js";
 import { q, SCALE } from "./src/units.js";
@@ -1908,7 +1908,7 @@ surface-heavy/internal-pass-through split or acid's structural bias.
 system. Unlike abstract "cold resistance" stats, temperature is tracked in real °C (encoded
 as Q) and driven by genuine thermophysics.
 
-```typescript
+```typescript no-check-example
 import { stepCoreTemp, deriveTempModifiers, cToQ, CORE_TEMP_NORMAL_Q } from "./src/sim/thermoregulation.js";
 import type { KernelContext } from "./src/sim/context.js";
 
@@ -1954,7 +1954,7 @@ final state.
 weeks. Hunger states impose escalating combat penalties and eventually cause mass loss —
 fat catabolism first, then muscle tissue.
 
-```typescript
+```typescript no-check-example
 import {
   computeBMR, stepNutrition, consumeFood, deriveHungerModifiers,
   FOOD_ITEMS, type HungerState,
@@ -2213,4 +2213,4 @@ ROADMAP items PH-1 through PH-8 are complete as of 2026-03-19:
 | PH-7 | Benchmark operational guide — tick-rate and entity-cap recommendations | **Complete** |
 | PH-8 | Emergent validation as flagship trust artifact — versioned, CI-enforced | **Complete** |
 
-See `ROADMAP.md` → `## Platform Hardening` for the full scope of each item.
+See `ROADMAP.md` → `## Platform Hardening` for the full scope of each item.

package/docs/release-dashboard.md

@@ -0,0 +1,47 @@
+# Release Dashboard
+
+> This file is generated by `npm run generate-release-dashboard`.
+> Do not edit manually. Update `CHANGELOG.md` and `package.json`, then regenerate.
+
+## Source of truth
+
+- `CHANGELOG.md` for release history and latest tagged release details.
+- `package.json` for the published package version.
+
+## Consistency status
+
+- Overall: **PASS**
+- Latest changelog version: **0.5.0** (2026-04-23)
+- Package version: **0.5.0**
+
+### Current inconsistencies
+
+- None detected.
+
+## Latest releases (from CHANGELOG)
+
+| Version | Date |
+| --- | --- |
+| 0.5.0 | 2026-04-23 |
+| 0.4.1 | 2026-04-23 |
+| 0.4.0 | 2026-04-22 |
+| 0.3.0 | 2026-04-04 |
+| 0.2.11 | 2026-04-04 |
+| 0.2.10 | 2026-04-03 |
+| 0.2.9 | 2026-04-02 |
+| 0.2.8 | 2026-04-02 |
+| 0.2.7 | 2026-04-02 |
+| 0.2.6 | 2026-04-02 |
+
+## Automation design
+
+- Generate this dashboard from source data using `tools/generate-release-dashboard.mjs`.
+- Treat `CHANGELOG.md` and `package.json` as canonical inputs.
+- Regenerate dashboard in release-prep flows and whenever either input changes.
+
+## CI stale-file rule
+
+- CI runs `npm run check-release-dashboard`.
+- The check re-renders dashboard content in-memory and compares it with committed `docs/release-dashboard.md`.
+- If they differ, CI fails with a non-zero exit and asks contributors to run:
+  - `npm run generate-release-dashboard`