Validate the stack-release manifest (catch dead toolchain paths / contradictory projections)

[flyingrobots]

The stack-release manifest (docs/releases/demo/continuum-stack-release.json) is hand-maintained JSON that pins toolchain/runtime versions, commits, install sources, and paths. This session it was found pointing at a deleted Wesley path (../wesley/packages/wesley-host-node/bin/wesley.mjs) — drift that went undetected because nothing validates the manifest.

Idea: add a manifest-validation check (a qw subcommand like qw manifest verify, or a gate script) that:

• resolves toolchain.*.install sources/paths against the authority root and flags dead references,
• confirms each families[].sourcePath (and materializeTo target shape) is real,
• checks declared defaultProjections are supported by the declared Wesley command set (e.g. native-rust supports only typescript/rust, so zod/echo-ir/warp-ttd in a native-rust manifest is a contradiction the validator should catch),
• optionally re-verifies the family sha256 against the source file.

This is the "generate/validate what machines already know" principle (DOCUMENTATION_POLICY §3) applied to the release manifest, and would have caught the dead wesley-host-node path immediately.

[coderabbitai]

🔗 Related PRs

#20 - Rewrite README around witnessed causal history [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!