runtime

6 modules

• runtime/deno.ts

  Deno implementation of RuntimeDeps.

  Provides create_deno_runtime(args) — a factory returning a RuntimeDeps backed by Deno APIs. Only imported by Deno entry points (compiled binaries for tx, zzz, etc.).

• runtime/deps.ts

  Shared dependency interfaces for runtime operations.

  Small composable interfaces that functions accept for only the capabilities they need. Both Deno and Node implementations satisfy all these interfaces via RuntimeDeps.

• runtime/fs.ts

  File system utilities.

• runtime/mock.ts

  Mock RuntimeDeps for testing.

  Provides a fully controllable runtime implementation for unit tests. Consumer projects can extend MockRuntime with project-specific helpers (e.g. setup_mock_zap_config) that stay local.

• runtime/node.ts

  Node.js implementation of RuntimeDeps.

  Provides the same interface as runtime/deno.ts but backed by Node.js APIs. Used for running servers in Node.js and for tests (vitest runs in Node).

• runtime/secure_file.ts

  Hardened secret-file read — the TS twin of the Rust spine's fuz_sys::secure_file::load_secure_file.

  The file this guards is typically the highest-value credential on the host (the bootstrap token mints the keeper account), so the read fails loud rather than degrading: a symlink, a group/other-accessible mode, or an oversized file is refused, never returned. The deploy recipe places the token at 0600, so the check ratifies the shape zap produces; a hand-placed 0644 file fails at boot instead of being read.

  The Node implementation lives here (load_secure_file_node, wired as create_node_runtime().read_secure_file); the Deno runtime implements the same contract over Deno.open in runtime/deno.ts, and the mock honors the mode/size checks over its in-memory map. All three refuse through the shared assert_secure_mode / assert_secure_size / read_secure_bounded helpers so the checks — and their operator-facing messages — can't drift between runtimes.