continuum/wesley targets a removed JS-era Wesley; real Wesley is a Rust workspace

[flyingrobots]

Summary

continuum/wesley/ (the "Continuum-owned Wesley module") and several artifacts
that depend on it are built against a JS-era Wesley that no longer exists.
The real Wesley (github.com/flyingrobots/wesley) is a Rust Cargo workspace
(crates/wesley-core, wesley-emit-*, wesley-holmes, crates/wesley-cli =
"Wesley native CLI", docs.rs/wesley-cli). It has not been a JS project for some
time.

Evidence (paths the Continuum side assumes, all now MISSING in real Wesley)

• wesley/support/wesley-deps.mjs imports @wesley/core with fallback
  ../wesley/packages/wesley-core/src/index.mjs → missing.
• demo manifest docs/releases/demo/continuum-stack-release.json pins Wesley as
  @wesley/host-node, runner: node-entrypoint, commandSet: legacy-node,
  install path ../wesley/packages/wesley-host-node/bin/wesley.mjs → missing.
• wesley/README.md says the host CLI is normally
  ../wesley/packages/wesley-host-node/bin/wesley.mjs → missing.
• Real ~/git/wesley/packages/ contains only wesley-host-{browser,bun,deno}
  and wesley-holmes — no wesley-core, no wesley-cli, no wesley-host-node.

Impact

• A Rust wesley-cli cannot load a JS WesleyModule (continuum/wesley/ is a
  JS module surface). The whole bridge is orphaned against current Wesley.
• wesley/test/*.test.mjs fail to load (@wesley/core unresolvable); the bats
  skip because the .mjs host CLI path is gone.
• The contract-family-registry's fixture-witnessed evidence for the receipt
  and settlement families is therefore not runnable against current Wesley.
• qw init real generation (non---skip-generate) targets the dead
  wesley-host-node entrypoint; warp tests pass only because Wesley invocation
  is mocked.

Notes / open questions

• The demo manifest pins Wesley at commit a80e47a, which predates the Rust
  migration — so this is migration drift, not a typo.
• apps/warp/README.md already says "new Wesley work should target the Rust
  runner," so the Rust direction is known; the module + manifest + docs never
  followed.

Decision needed

What is continuum/wesley/ supposed to be now? Options: (a) delete it and have
qw invoke the real wesley-cli Rust binary; (b) keep a thin Continuum module
but retarget it at the Rust CLI's interface; (c) something else. The right fix is
an architecture call, not a doc edit — filing this so it is tracked before any
of the dependent docs/manifests are "corrected" to a layout that is itself dead.

[flyingrobots]

Correction after comparing the repos directly: continuum/wesley/ is not obsolete duplication. Per Rust Wesley's own docs (~/git/wesley/docs/features/ttd-protocol-compiler.md), the TTD protocol compiler was deliberately extracted out of generic Wesley into continuum/wesley/ttd/ — that tree is its authoritative home (AST, directives, hasher, manifest, the invariants expression-language/VM, and the IR JSON-Schema + directive SDL). Rust Wesley has no TTD impl and no zod emitter; the echo / warp-ttd targets and the receipt/settlement witness logic are Continuum-specific too.

The drift is narrower than 'orphaned module': the JS module lost its base platform. It imports @wesley/core and packages/wesley-core/src/ports/{clock,crypto}.mjs, and the demo manifest invokes packages/wesley-host-node/bin/wesley.mjs — but Wesley migrated its base platform to Rust and dropped the Node host (only wesley-host-{bun,deno,browser} survive).

So the decision is how the TTD/Continuum JS module gets a base platform now (port TTD to Rust; run it on a surviving JS host like bun/deno; or vendor the few wesley-core ports it needs) — not whether to delete it. Do not 'fix' the dependent docs/manifest toward the dead Node layout.

[flyingrobots]

Read the Wesley repo properly (not grep). Authoritative facts from ~/git/wesley/docs/LEGACY_NODE_MIGRATION.md + the crates:

• Wesley is a crates.io binary now: cargo install wesley-cli installs the wesley binary (commands: wesley schema lower/diff, wesley emit rust|typescript, wesley doctor). Distribution is crates.io via GitHub Actions (docs/CRATES_IO_RELEASE.md).
• The legacy Node surface is deleted: the retirement ledger marks packages/wesley-core, packages/wesley-cli, and packages/wesley-host-node as Deleted. Those are exactly the paths continuum/wesley/wesley-deps.mjs and the demo manifest point at. Only wesley-host-{bun,deno,browser} survive, and they explicitly carry no dependency on the deleted JS core — so 'run continuum/wesley on a surviving JS host' is NOT viable.
• zod and compile/domain-target dispatch were deleted on purpose and reassigned to 'an external target module' — i.e. Continuum's job, not Wesley's. Wesley is domain-empty: 'Wesley owns the GraphQL-to-IR transformation. Extensions own meaning.'
• The Rust extension landing spot already exists: crates/wesley-core/src/domain/capability.rs + crates/wesley-core/tests/module_capability_registry.rs — a module capability registry. The migration doc names the replacement for JS module-loading as 'a Rust target registry plus an explicit WASM or external-process capability protocol.'

Revised conclusion: the capabilities in continuum/wesley/ (TTD compiler, zod/registry codegen, echo/warp-ttd targets, receipt/settlement witness) are legitimately Continuum-owned and absent from Wesley by design — but the implementation (a Node-hosted JS WESLEY_MODULE on @wesley/core) is fully obsolete. The path is to re-express those targets against the Rust module-capability-registry (or an external-process/WASM target) and have qw invoke the crates.io wesley binary — not clone a sibling Node checkout. continuum/wesley/ is the reference to port FROM.

[flyingrobots]

Resolved the module question per maintainer call: continuum/wesley/ deleted (64 files; nothing in the repo imported it) and wesley-cli 0.1.0 installed from crates.io (wesley binary). Registry receipt/settlement families honestly downgraded fixture-witnessed → authored since the witness suite went with the module. Commit 53cccd8.

Remaining (keeping this issue open, re-scoped to the re-platform):

• Re-point the demo manifest (docs/releases/demo/continuum-stack-release.json) and apps/warp references off the dead wesley-host-node Node path to the crates.io wesley binary.
• Re-express the Continuum targets that lived in the JS module — TTD compiler, zod/registry codegen, echo + warp-ttd targets, receipt/settlement witness — against the Rust Wesley module-capability-registry (crates/wesley-core/src/domain/capability.rs) or an external-process/WASM target, then restore the registry's fixture-witnessed evidence.

[flyingrobots]

Concrete re-platform plan (grounded in apps/warp/src/init.mjs)

Blocker found: no install source for the crates.io binary

init.mjs resolves Wesley from exactly three toolchain.wesley.install.source
values (apps/warp/src/init.mjs#523,571,618, error list at #666):

1. local-sibling-entrypoint → node-entrypoint runner, legacy-node command
   set; requires install.path to a .mjs. This is what the demo manifest
   uses, pointing at the deleted ../wesley/packages/wesley-host-node/bin/wesley.mjs.
2. local-sibling-binary → native-binary runner, native-rust command set;
   requires install.path to a built binary. (Supported + tested.)
3. package-source → staged from a declared package source site.

None resolves a binary already on PATH (e.g. cargo install wesley-cli →
~/.cargo/bin/wesley). So step one is a code change, not a manifest edit.

Step 1 — add an installed-binary (PATH/crate) install source

• New install.source: "installed-binary" with bin: "wesley" (+ optional
  crate: "wesley-cli", version): resolve the binary from PATH, skip staging
  under .warpspace/packages/wesley/, set runner: native-binary /
  commandSet: native-rust, and record a resolution receipt (resolved path +
  wesley --version) instead of an install receipt.
• Test-first (warp suite is in CI): a test that init with an installed-binary
  Wesley resolves wesley from PATH and invokes it natively (mock the binary).
• Then switch the demo manifest's toolchain.wesley to
  { package: "wesley-cli", source: "installed-binary", bin: "wesley", runner: "native-binary", commandSet: "native-rust" } and drop the dead
  wesley-host-node entry. Update apps/warp/README.md / GETTING_STARTED.md
  to describe cargo install wesley-cli instead of the sibling .mjs.

Step 2 — re-express the deleted Continuum targets on the Rust Wesley

The capabilities that lived in continuum/wesley/ need a home. Disposition:

Capability	Disposition
TTD protocol compiler (IR + invariants DSL)	Port to a Rust target registered via crates/wesley-core/src/domain/capability.rs, or an external-process target that shells wesley and post-processes IR.
zod + registry TS codegen	External target module consuming Wesley TS/IR (Wesley emits interfaces only; zod stays external per its retirement ledger).
echo bundle target	Rust target or external-process target.
warp-ttd target	Same.
receipt/settlement witness	Re-establish as a check that runs against wesley output; this is what restores the registry's fixture-witnessed status (currently downgraded to authored).

Step 3 — restore evidence

Once a witness check runs against the crates.io wesley, re-upgrade the
receipt/settlement registry rows and wire the check into CI (now feasible:
cargo install wesley-cli is a real, installable dependency).

[flyingrobots]

Step 1 done (commit 21528b7): qw init now resolves the crates.io wesley binary instead of the dead sibling-Node .mjs.

• New toolchain.wesley.install.source: "crate" in apps/warp/src/init.mjs: resolves wesley from PATH (cargo install wesley-cli), errors with cargo guidance if absent, invokes it natively (wesley emit …), records a resolution receipt (no .warpspace staging), and reports native-binary so no Node is required.
• Demo manifest flipped to it (wesley-cli 0.1.0, native-rust); dropped @wesley/host-node. Demo projections trimmed to typescript.
• Test-first: two new warp-init tests. Warp suite 30/0, docs gate 0/0.
• Docs updated (demo README, apps/warp README/VISION, GETTING_STARTED) to describe cargo install wesley-cli.

Still open on this issue:

• The zod / echo-ir / warp-ttd projections (compilers lived in the deleted continuum/wesley) are dropped from the demo — re-express them as Rust targets on the Wesley module-capability-registry (or external-process targets) and restore them to the demo projections.
• Restore the registry's fixture-witnessed evidence for receipt/settlement once a witness check runs against the crates.io wesley.
• Optional: an opt-in autoInstall that runs cargo install when the binary is missing (currently resolve-only with guidance), and a pinned/prebuilt managed install so the user doesn't need an ambient cargo install.