[EthanThatOneKid]

What this does

Removes every Deno.* global from src/ so JSR's npm-compatibility package
runs on Node, not just installs there.

npx jsr add @wazoo/workspace already required no Deno, and Node 24 already
loaded the entire module graph (transpiled .js beside the .ts, @/x.ts
rewritten to correct relative paths, jsr:@std/cli rewritten to
@jsr/std__cli, import.meta.main honoured). It then died at
ReferenceError: Deno is not defined. JSR transpiles but does not shim Deno
globals — that was the whole barrier.

Closes #160. Also closes #159: the version moves to 0.8.0, which is what makes
the already-merged sweep/purge reachable at all (JSR is immutable, so they
could never ship from 0.7.0).

Two commits, because the first attempt was not enough

a6d4191 ports src/ off Deno.*. 0ab53ef fixes what that missed, and it is
the more interesting half: the engine still could not run on Node, because
@std/fs is Deno-only. Its exists and walk call the Deno global
directly, in the TypeScript source and in the JavaScript JSR ships to npm.
Seven modules imported exists and one imported walk, so the CLI died at
ReferenceError: Deno is not defined during manifest discovery, before any
command could run.

deno test could not catch this and did not: Deno defines the Deno global, so
193 tests were green with the dependency in place. It appeared only when the
module graph was executed on Node — which is the entire point of the change, and
the reason the verification below is not "the suite passes".

Shape of the change

• One runtime edge. src/runtime.ts is the only module allowed to import
  node:* (child_process, fs/promises, os, process). Deno implements
  those specifiers natively, so a single implementation serves both runtimes.
• That edge also owns traversal, because @std/fs cannot. pathExists and
  walkDirectoryTree replace exists and walk. walkDirectoryTree keeps
  @std/fs/walk's observable semantics on purpose, since wspace path ranks
  what it is handed: the root is returned first, maxDepth counts the root as
  depth 0, skip patterns match the whole path rather than the basename, a
  skipped directory is neither returned nor descended into, and symlinks are
  never followed. pathExists documents its one divergence: a path that cannot
  be stat'd reads as absent, where exists reports it as present.
• Subprocess semantics preserved. runProcess resolves for every exit code
  including non-zero, and rejects only when the binary cannot be spawned. That
  rejection is load-bearing: it is how createGitHubRepoWithFallback recognises
  "gh CLI is not available". Stdin is detached so git cannot hang on a
  credential prompt.
• Host differences normalised in exactly one place each. isWindows() for
  "windows" vs "win32"; cliArgs() for process.argv.slice(2); exit via
  process.exitCode rather than process.exit so piped --json output is not
  truncated.
• @types/node is the only new dependency — type-only, resolved through
  Deno's global cache, so no node_modules/ directory appears in the repo.
• Bonus fix: deno task build allowed only --allow-run=git, but the code
  also spawns gh and robocopy/rmdir/rm. Since deno compile bakes
  permissions in, those paths would have thrown PermissionDenied.
• docs/adr/0007-runtime-neutral-engine.md records the decision, the sandbox
  regression, and the @std/fs finding; AGENTS.md amends the "@std only"
  convention; the README documents the no-Deno install.

Verification

Gate	Result
deno task ci	199 passed / 0 failed / 1 ignored (the ignored test creates a symlink, which needs Developer Mode on Windows)
cold-cache deno check src/ tests/ (fresh DENO_DIR, the CI path)	green, no node_modules
runtime edge under Node (direct)	non-zero exit resolves (128), missing binary rejects, cwd/fs/cliArgs/exit-code all correct
check --json on Node vs the published 0.7.0 binary	identical across all 39 entries
path worlds-api on Node vs the binary	identical stdout
path wiki (ambiguous) on Node vs the binary	identical stderr, identical exit 1
sweep --dry-run --json on Node	exits 0
@jsr/std__fs in the staged graph	unreachable; @std/path and @std/cli are runtime-neutral (std__path guards with global.process?.cwd ?? global.Deno?.cwd, std__cli with "Deno" in globalThis)

The Node rows come from reproducing JSR's specifier rewrites locally (the @/
alias, and jsr:@std/* → @jsr/std__*) and executing the resulting graph with
node --experimental-transform-types. The pre-existing Deno tests are untouched
and remain the behaviour-parity gate.

What I could not verify

Only JSR's server-side packaging. It builds the npm-compat tarball at publish
time, and deno transpile output is not directly Node-loadable (it leaves
jsr: specifiers), so the final link is a real
npx jsr add @wazoo/workspace@0.8.0 followed by
node node_modules/@wazoo/workspace/src/cli.js check --json on the published
artifact. The rewrites that publish applies were reproduced by hand for every
row above; the packaging step itself is the one part not exercised.

The merge that would prove it also publishes 0.8.0, and so is approval-gated.

Known and accepted

• Node consumers lose the Deno permission sandbox: the same code runs with the
  user's ambient authority. Documented in ADR-0007 rather than discovered later.
• JSR forwards exports, not bin (README install command 'deno install -g jsr:@wazoo/workspace' produces a no-op; bin not honored for JSR packages #135), so this yields a runnable
  entrypoint, not a wspace command on PATH.
• This is the alternative to Distribute prebuilt wspace binaries (deno compile / scriptc) so no Deno install is required #29 (prebuilt binaries); the binary route stays
  open and this does not preclude it.