server

26 modules

• server/backend_action_types.gen.ts

• server/backend_action_types.ts

• server/backend_actions_api.ts

• server/backend_provider_chatgpt.ts

• server/backend_provider_claude.ts

• server/backend_provider_gemini.ts

• server/backend_provider_ollama.ts

• server/backend_provider.ts

• server/backend_pty_manager.ts

• server/backend.ts

• server/constants.ts

  Server-side constants (Deno-compile-safe).

  Mirror of src/lib/constants.ts for modules in the Deno compile chain. Must not import $env/static/public or any SvelteKit build-time module — those don't exist in Deno and crash gro build / deno compile.

• server/create_zzz_app.ts

  Runtime-agnostic zzz app factory.

  Creates the full application by combining fuz_app's create_app_backend and create_app_server with zzz's domain Backend, AI providers, and WebSocket endpoint. Called by the server entry point (server/server.ts).

• server/db/zzz_schema.ts

  Database schema initialization for zzz.

  Runs fuz_app auth migrations. No zzz-specific DDL yet (all domain state is in-memory via Cells).

• server/helpers.ts

• server/pty_ffi.ts

• server/register_websocket_actions.ts

  WebSocket endpoint wiring — thin wrapper over fuz_app's register_ws_endpoint.

  zzz supplies the action tuples (spec + handler) and the per-request DB handle; fuz_app owns the upgrade middleware stack (origin check, auth, authorization phase that builds RequestContext), dispatch, validation, and transport bookkeeping. Domain deps flow through create_zzz_action_handlers(backend) — the factory closes over the Backend, so handlers receive the unified ActionContext directly.

  The shared protocol_actions bundle (heartbeat + cancel pre-paired with their handlers) is spread first so disconnect detection and per-request cancellation are identical across every fuz_app consumer.

• server/scoped_fs.ts

• server/security.ts

  Host header validation middleware for DNS rebinding defense-in-depth.

  Validates that the Host header matches expected local hostnames. Requests without a Host header are allowed (HTTP/1.0, CLI tools).

• server/server_env.ts

  Server environment configuration.

  Extends BaseServerEnv from fuz_app with zzz-specific fields. Uses load_env from fuz_app for schema-validated loading.

• server/server.ts

  Deno server entry point for zzz.

  Single entry point for both dev mode (gro dev via gro_plugin_deno_server) and production (zzz daemon start). Uses the shared create_zzz_app factory for the Hono app with fuz_app auth stack, then binds with Deno.serve and handles daemon lifecycle.

• server/testing_server_core.ts

  Runtime-agnostic test-binary core for the TS canonical zzz server.

  Shared by the Deno (testing_server_deno.ts) and Node (testing_server_node.ts) test-binary adapters: same create_zzz_app factory, same _testing_reset registration, same reset_state closure, same daemon-info + shutdown discipline. The two runtime adapters only supply the boundary primitives that diverge between Deno and Node (HTTP serve, WS upgrade construction, signal registration, pid, exit).

  Production stays on Deno (server.ts). Both test entries register _testing_reset from fuz_app's create_testing_actions factory with a zzz reset_state closure that closes all workspaces, kills terminals via PtyManager.kill_all, and wipes the optional ZZZ_TESTING_SCRATCH_DIR tree.

  NEVER ship in a release. The module reaches into fuz_app's testing/cross_backend/ modules which throw at production-bundle load via assert_dev_env. The testing_ filename prefix mirrors the Rust testing_zzz_server convention and is enforced for the Rust side by cargo xtask check-release's dep-graph audit.

• server/testing_server_deno.ts

  Deno test-binary adapter for the TS canonical zzz server.

  Thin adapter over testing_server_core.ts: binds Deno.serve and hono/deno's module-level upgradeWebSocket for the WS upgrade path. The shared core owns env loading, _testing_reset registration, daemon-info lifecycle, and shutdown coordination.

  Counterpart to testing_server_node.ts — both spawn the same create_zzz_app factory and register _testing_reset against it. The split exists so cross-process integration suites can compare runtime-level behavior on identical TS canonical surfaces:

  - Deno vs Node JS-runtime perf (V8 in both, but distinct I/O loops, fetch impls, HTTP servers). - Wire-shape parity between the two TS runtimes (a divergence here would mean fuz_app's runtime-agnosticism slipped).

  The Rust testing_zzz_server covers the cross-language axis (TS vs Rust); these two cover the cross-runtime axis on the same TS surface.

  NEVER ship this in a release. See testing_server_core.ts for the production-safety contract.

  Run with: deno run --allow-net --allow-read --allow-env --allow-write --allow-sys src/lib/server/testing_server_deno.ts

  Or via the npm script (recommended — bundles the permissions flags): npm run test:server:deno

  Env vars: see testing_server_core.ts.

• server/testing_server_node.ts

  Node/bun-runnable test-binary adapter for the TS canonical zzz server.

  Thin adapter over testing_server_core.ts: binds Deno.serve's counterpart @hono/node-server's serve() and @hono/node-ws's createNodeWebSocket(app) for the WS upgrade path. The shared core owns env loading, _testing_reset registration, daemon-info lifecycle, and shutdown coordination.

  NEVER ship this in a release. See testing_server_core.ts for the production-safety contract.

  Run with: gro run src/lib/server/testing_server_node.ts bun src/lib/server/testing_server_node.ts

  Env vars: see testing_server_core.ts.

• server/zzz_action_handlers.ts

  Unified action handler factory for zzz.

  create_zzz_action_handlers(backend) is the single source of truth for all 23 request_response handlers. Both HTTP RPC and WebSocket dispatch call into the same map. The Backend is closed over at construction time — handlers receive fuz_app's unified ActionContext (auth, db, request_id, notify, signal) without any context extension.

• server/zzz_route_specs.ts

  Shared zzz route spec factory.

  Used by the production server, integration tests, and attack surface helpers. Does NOT include bootstrap routes (factory-managed by create_app_server).

• server/zzz_rpc_actions.ts

  RPC actions for zzz — thin adapter from unified handlers to fuz_app's RpcAction format.

  Binds create_zzz_action_handlers(backend) once and pairs each handler with its spec for create_rpc_endpoint. All business logic lives in server/zzz_action_handlers.ts.