@stravica-ai/digital-operator-pa 0.1.0

package/dist/engineering-pa-types-engineering/roles/product-engineer/templates/build-spec.md

@@ -0,0 +1,82 @@
+# Build Spec — {Build Name}
+
+**Build id:** `{build-id}` (slug; matches `projects/{build-id}/`)
+**Operator:** {operator-name}
+**PA instance:** {pa-name}
+**Spec author:** {operator | PA-name-and-role} — {date}
+**Status:** `{draft | ready-for-preflight | approved | building | done}`
+
+> **How to use this template.** This is the single entry-point document for a product-engineer build. It may link to other docs (research, mockups, related projects) but this file is the canonical source of truth for what's being built. Either the operator writes this directly, or the PA produces it from a discussion with the operator. Either way, it lands here before the Product Engineer is invoked.
+>
+> Delete these blockquote instructions before saving.
+
+---
+
+## Summary
+
+> One to two paragraphs. What is being built, for whom, why now. Written so someone with no prior context can decide in ninety seconds whether they care.
+
+## Functional requirements
+
+> Numbered, testable, un-ambiguous. Each is a checkable claim — "the user can X," "the system Y's when Z." Not design decisions, not implementation hints — just what the thing does.
+
+1. ...
+2. ...
+3. ...
+
+## Non-functional requirements
+
+> Performance, security, accessibility, durability, observability — whichever apply. Leave sections out that genuinely don't apply; don't fill with boilerplate.
+
+- **Performance:** ...
+- **Security:** ...
+- **Accessibility:** ...
+- **Observability:** ...
+- **Reliability:** ...
+
+## Success criteria
+
+> How we know it works. Restate the important functional + non-functional requirements as *measurable* checks. Each criterion is a test the Product Engineer's Stage 5 review walks through.
+
+- [ ] ...
+- [ ] ...
+- [ ] ...
+
+## Out of scope
+
+> Anything the operator has considered and deliberately left for later. Naming the exclusion here is how the Product Engineer avoids scope creep without a second approval round.
+
+- ...
+- ...
+
+## Constraints
+
+> Hard limits the build must respect. Budget, deadline, infrastructure, approved third-party services, banned dependencies, data residency, etc.
+
+- ...
+- ...
+
+## Stack note (optional)
+
+> If the operator has a strong preference away from the default stack (Node / Fastify / SvelteKit / SQLite-or-Postgres / node:test + Playwright / Docker / GitHub Actions), note it here with a one-line reason. Absent this section, the Product Engineer uses the default stack.
+
+- ...
+
+## Deployment note
+
+> Where the finished build goes beyond local Docker. This is *out of the Product Engineer's scope*, but flagging it here helps the PA plan the handoff. "Local only, for operator's personal use" is a valid answer.
+
+- ...
+
+## Related documents
+
+> Links to related projects, research notes, prior discussions, mockups. Each link has a one-line description so the reader knows whether to follow it.
+
+- [...](path) — ...
+
+## Operator preferences relevant to this build
+
+> The PA extracts and pastes the operator-profile/memory items that actually bear on this build. **Not** the full operator profile. Just what's relevant. This is where the Product Engineer learns "this operator prefers minimalistic UI" or "this operator's firm rule is never mock databases."
+
+- ...
+- ...

package/dist/engineering-pa-types-engineering/roles/product-engineer/templates/preflight-checklist.md

@@ -0,0 +1,158 @@
+# Preflight Checklist — {Build Name}
+
+**Build id:** `{build-id}`
+**Build spec:** [`projects/{build-id}/build-spec.md`](./build-spec.md)
+**Design doc:** [`projects/{build-id}/design-doc.md`](./design-doc.md)
+**Product Engineer:** {agent-name-or-id}
+**Issued:** {date}
+**Status:** `{pending-approval | approved | changes-requested | rejected}`
+
+> **Operator, this is the last point of contact until demo.** Review every section below. If every item accurately reflects what you want built, approve. If anything is wrong, reject or request changes. Once you approve, the Product Engineer proceeds to build, test, and demo without further interaction unless something locked here proves wrong in practice.
+>
+> The Product Engineer has done the thinking; your job here is to confirm (or course-correct).
+
+---
+
+## 1. What we're building
+
+> One paragraph, in plain operator-facing language. Restated from the build-spec summary — not reinterpreted.
+
+...
+
+## 2. Stack decisions
+
+> Default stack is Node.js + Fastify + SvelteKit + SQLite-then-Postgres + node:test + Playwright + Docker + GitHub Actions. Any deviation is listed below with a one-line reason.
+
+**Using default:** _yes | no (see deviations)_
+
+**Deviations:**
+
+| Layer | Default | Chosen | Reason |
+|---|---|---|---|
+| ... | ... | ... | ... |
+
+## 3. Architecture sketch
+
+> Services, data flow, integration points. ASCII diagram or bullet list — whichever reads clearer. Should fit on one screen.
+
+...
+
+## 4. Data model
+
+> Entities, key fields, relationships. Just enough to show the shape.
+
+...
+
+## 5. API surface
+
+> Endpoints the build will expose. Routes, methods, purpose. Not full OpenAPI — just the surface.
+
+| Method | Path | Purpose |
+|---|---|---|
+| ... | ... | ... |
+
+## 6. UX sketch (if UI)
+
+> Screens, main flows, styling approach. Can reference external mockups.
+>
+> **Minimum content (when there is a UI):** list each screen by name + one-line purpose; text-wireframe the main form/layout of each; show the flow arrows between screens; name the styling approach (e.g. "plain CSS, system font stack, one accent colour"). Don't go beyond text-wireframes unless the build-spec specifically asks for design mockups — full UI mocks are a different artefact and belong outside the preflight if used.
+>
+> **When there is no UI** (API-only, CLI, scheduled task): delete this whole section — don't leave it empty.
+
+...
+
+## 7. Test plan
+
+- **Unit tests:** _what kinds of tests at what depth_
+- **Integration tests:** _real DB — no mocks; what flows are covered_
+- **E2E tests (Playwright, if UI):** _what user journeys_
+- **Security scan:** _npm audit + any deeper scans_
+- **CI coverage:** _what runs in GitHub Actions_
+
+## 8. Repository plan
+
+- **Organisation / account:** `{org-or-account}` ← **operator confirms at invocation**
+- **Repository name:** `{repo-name}`
+- **Visibility:** `{private | public}` (default private)
+- **Default branch:** `main`
+- **Branching strategy:** `{feature-branch-PR | direct-to-main-for-scaffold}`
+
+## 9. Deployment plan (local scope only)
+
+> **These three bullets are boilerplate you keep verbatim in most builds.** The "local Docker only" scope ceiling is a role-level rule (not a build choice), so the third bullet should appear unchanged in almost every preflight. Don't delete or soften it unless there's a genuinely new scope decision you're making.
+
+- **Container:** Docker multi-stage, distroless runtime (distroless-nonroot when writing to a volume — see role spec Stage 3 Dockerfile snippet)
+- **Local run command:** `docker compose up` or `docker run ...` (exact command in build summary at Stage 6)
+- **Production deployment:** **OUT OF SCOPE** — handed back to PA for per-instance deployment routing
+
+## 10. Secrets plan
+
+- **What the app needs:** _list of env vars_
+- **Local sourcing:** `.env` (in `.gitignore` from commit one)
+- **CI sourcing:** GitHub Actions repo secrets
+- **Production sourcing:** operator's PA instance (out of scope here — flagged for PA)
+
+## 11. Success criteria
+
+> Restated from the build-spec as measurable checks the Product Engineer will self-verify at Stage 5 Review before declaring done.
+
+- [ ] ...
+- [ ] ...
+- [ ] ...
+
+## 12. Risks and trade-offs
+
+> Anything the Product Engineer wants the operator to knowingly accept before building.
+
+- **Risk:** ... → **Mitigation:** ...
+- **Trade-off:** ...
+
+## 13. What we're explicitly NOT doing in this build
+
+> Called out so the operator doesn't expect it at demo.
+
+- ...
+- ...
+
+---
+
+## Operator approval
+
+> **Iteration protocol.** This section reflects the **current iteration only** — rewrite it in place each time the preflight cycles. The full audit trail (who decided what, when, with what words) is preserved in the Approval log table below. This keeps the top-of-section unambiguous while still guaranteeing a complete history.
+
+**Operator:** _{operator-name}_
+
+> **Stand-in approvers** are valid for pilot protocol or operator-absent cases. Use the form: `{operator-name} (via operator-stand-in: {pa-name}, {role} — {reason})`. The approval is still binding on the operator; the stand-in is acting under delegated authority.
+
+- [ ] Stack decisions correct
+- [ ] Architecture matches intent
+- [ ] API surface correct
+- [ ] Test plan sufficient
+- [ ] Repository plan correct (org, name, visibility)
+- [ ] Success criteria accurately reflect "done"
+- [ ] Out-of-scope list is accurate
+- [ ] Risks are acceptable
+
+**Decision:** _approve | request-changes | reject_
+
+**Approval phrase (verbatim from operator):** _"..."_
+
+**Timestamp:** _{date}T{time}Z_
+
+---
+
+## Changes requested (if any)
+
+> **On the first issue of the preflight, leave this section at `_(none yet)_`** — the Operator either approves outright, or populates this section with a numbered list and sets Decision to `request-changes`. The Product Engineer then updates the design-doc and this checklist per the list, resets Status to `pending-approval`, and re-presents. Cycle until aligned.
+
+- _(none yet)_
+
+---
+
+## Approval log
+
+> Every approval cycle (initial, re-approval after changes) gets a line here. This table is append-only and preserves the full history across iterations — whereas the Operator-approval block above is rewritten per iteration.
+
+| Iteration | Date | Decision | Approval phrase |
+|---|---|---|---|
+| 1 | ... | ... | ... |

package/dist/engineering-pa-types-engineering/roles/product-engineer/templates/worker-brief.md

@@ -0,0 +1,130 @@
+# Worker Brief — {task-name}
+
+> **Specialised briefing contract for Product Engineer → Worker dispatches during a build.** Extends the 8-section briefing contract at [`core/knowledge/standards/briefing-contract.md`](../../../knowledge/standards/briefing-contract.md) with product-engineer-specific sections. Every field is mandatory — if you can't fill one, do not dispatch. Fall back to in-thread execution instead.
+
+**Build id:** `{build-id}`
+**Build repository:** `{owner}/{repo}`
+**Branch:** `{branch-name}`
+**Dispatched by:** {product-engineer-agent-id}
+**Worker id (for spawn-log):** `{d-YYYY-MM-DD-NNN}`
+**Isolation:** `{none | worktree}`
+**Parallel or sequential:** `{single | part-of-task-group-{group-id}}`
+
+---
+
+## Goal
+
+> One sentence. Outcome-shaped. What success looks like.
+
+...
+
+## Trace — why we're doing this
+
+> **Mandatory. Three to six sentences.** Explain why this slice exists, what decisions have already been made, what alternatives have been ruled out. The worker reads this before doing anything else. If this field is shallow, the integration step will be painful.
+
+> If part of a task group, this trace summarises the *worker-specific* reasoning; the broader trace lives in `projects/{build-id}/group-context/trace.md` and is read by every worker.
+
+...
+
+## Context
+
+> The "what" — paths, files, decisions already made. Extracted and tailored for this worker, never the full operator profile or full build-spec.
+
+**Build spec:** `projects/{build-id}/build-spec.md` — **read before starting**
+**Design doc:** `projects/{build-id}/design-doc.md` — **read before starting**
+**Preflight (approved):** `projects/{build-id}/preflight-checklist.md`
+**Shared context store (if task group):** `projects/{build-id}/group-context/`
+
+**Files the worker touches:**
+- `...`
+- `...`
+
+**Files the worker may READ but NOT WRITE:**
+- `...`
+
+**Decisions already locked (do not re-open):**
+- ...
+
+## Tools and sources
+
+> Which tools to use, which to avoid, where to find information.
+
+**Tools:** `{Read, Write, Edit, Bash, Playwright, etc. — be explicit}`
+
+**Standards to read (not paraphrase):**
+- `core/knowledge/standards/briefing-contract.md` — the brief contract this dispatch uses
+- `core/knowledge/standards/tooling.md` — if the worker writes any internal tooling
+- `core/roles/product-engineer/definition.md` — the role this dispatch operates under
+- _Additional standards specific to this slice: ..._
+
+**Operator memories relevant to this slice** (PA extracts from `operator/memory/`):
+- ...
+- ...
+
+**Must NOT touch:**
+- Any file outside the build's repository
+- The PA instance's `operator/`, `agents/`, `work/`, `projects/` (except this build's own project folder where explicitly authorised)
+
+## Boundaries
+
+**In scope for this worker:**
+- ...
+
+**Out of scope for this worker:**
+- ...
+
+**Decision authority:**
+- **Decide alone:** implementation details inside the scoped files, naming, test layout
+- **Decide and log:** any deviation from the design-doc for this slice
+- **Must escalate to orchestrator (Product Engineer):** anything outside scope, anything affecting other workers, any spec change
+
+## Output format
+
+> Exactly what the worker returns to the orchestrator.
+
+**Files to create / modify:**
+- `...`
+
+**Tests to pass:**
+- `...`
+
+**Artefacts:**
+- _A short return summary in the agent response_
+- _A commit (or commits) on the named branch with conventional-commit messages_
+- _If part of a task group, a decision log entry at `projects/{build-id}/group-context/decisions.md`_
+
+**Length cap on return summary:** under 200 words unless something specific requires more.
+
+## Done when
+
+> Concrete, self-checkable acceptance criteria. "Tests pass" alone is not enough — name the tests, the invocation, the expected output.
+
+- [ ] Files listed above exist and implement the goal
+- [ ] `npm test` (or equivalent) passes on the branch
+- [ ] `npm run build` (if applicable) passes
+- [ ] Linter / typechecker (`npm run check` or equivalent) passes
+- [ ] Commit(s) pushed to `{branch-name}`
+- [ ] Spawn-log entry for this worker recorded by orchestrator at dispatch time (orchestrator's responsibility, noted here for audit)
+- [ ] Return summary submitted
+
+## Escalation rule
+
+> Default: **if any field in this brief is unclear or you encounter a constraint not covered here, stop and report the question rather than guessing.**
+
+**This dispatch's specific escalation rules:**
+- If the build-spec, design-doc, or preflight conflict with this brief, stop — the orchestrator made a mistake. Report it.
+- If the design-doc is missing information you need to implement the slice, stop. Do not guess the design.
+- If an external resource (dependency, API, service) is unavailable, stop. Do not synthesise a workaround without telling the orchestrator.
+- If your slice touches files another worker in this task group is writing, stop. Coordination flows through the orchestrator, not between workers.
+
+**Do not communicate with other workers directly.** If coordination is needed, append to the shared context store at `projects/{build-id}/group-context/coordination.md` and return control to the orchestrator.
+
+---
+
+## Worktree notes (if isolation: worktree)
+
+> When this brief sets `isolation: worktree`, the following MUST be honoured verbatim by the worker:
+
+**Phase 0 — cwd verification:** Before ANY file-write or git op, run `pwd` and verify the output is inside `.claude/worktrees/agent-<id>/`. If not, `cd` to the worktree root before proceeding.
+
+**Worktree absolute-path rule:** Every absolute path passed to Write, Edit, MultiEdit, or Bash (for writes) MUST begin with the worktree root. Writing to main-worktree absolute paths is forbidden.

package/dist/engineering-pa-workspace/README.md

@@ -0,0 +1,197 @@
+# Workspace Server CLI (`ws.mjs`)
+
+Manages the workspace dev server (`server.mjs`) as a background process. Cross-platform (macOS, Linux, Windows), zero npm dependencies.
+
+For installing the server as an always-on supervised daemon (launchd / systemd), see [`DAEMON.md`](./DAEMON.md).
+
+## Usage
+
+```bash
+node ws.mjs start [--port N] [--no-open]   # Start server as background daemon
+node ws.mjs stop                            # Stop the running server
+node ws.mjs restart [--port N] [--no-open]  # Stop then start
+node ws.mjs status                          # Show server status (PID, port, uptime, health)
+node ws.mjs open                            # Open browser to server URL
+```
+
+## Port resolution
+
+The port is resolved in this order (last wins):
+
+1. Default: `4200`
+2. `operator/config/preferences.json` key `workspacePort`
+3. `--port` CLI flag
+
+## Files
+
+| File | Purpose |
+|---|---|
+| `.ws.pid` | PID + port tracking (repo root). JSON: `{ "pid": N, "port": N }` |
+| `.ws.log` | Server stdout/stderr (repo root). Overwritten on each `start`. |
+
+Both files are gitignored artifacts. They live in the repo root for easy discovery.
+
+## Commands
+
+### `start`
+
+1. Checks if the server is already running (PID file + process check + port check). If so, prints the URL and exits.
+2. Recovers from bad states (see table below) or reports them with a one-line fix.
+3. Spawns `server.mjs` detached with `--no-timeout` (background servers should not auto-shutdown) and `--no-open` (the CLI handles browser opening).
+4. Writes `.ws.pid`.
+5. Waits up to 3 seconds for the port to become available, then prints the URL.
+6. Opens the browser unless `--no-open` is passed.
+
+#### Bad-state matrix (on `start`)
+
+| PID file | Port | Behaviour |
+|---|---|---|
+| exists, PID alive, port up | — | Already running — print URL, exit 0. |
+| exists, PID alive, port down | — | Stale process. Kill it, clean up, then spawn. |
+| exists, PID dead, port free | — | Clean up pidfile, spawn fresh. |
+| exists, PID dead, port busy | — | Unverifiable port holder. Print diagnostic with the holder's PID/command and a recovery one-liner, exit 1. Never kills a process we cannot prove we started. |
+| missing, port free | — | Spawn fresh. |
+| missing, port busy | — | Print diagnostic with holder PID, exit 1. |
+
+On platforms where `lsof` (macOS/Linux) or `netstat` (Windows) is unavailable the holder lookup is skipped and the diagnostic falls back to suggesting manual investigation.
+
+### `stop`
+
+1. Reads `.ws.pid`. If missing or process dead, prints "not running" and exits 0.
+2. Sends SIGTERM (or `taskkill` on Windows). Waits up to 5 seconds.
+3. If still alive, sends SIGKILL (or `taskkill /F`).
+4. Cleans up `.ws.pid`.
+
+### `restart`
+
+When a supervisor (launchd / systemd) is installed, asks the supervisor to bounce the service:
+
+- **launchd:** `launchctl kickstart -k gui/$UID/com.dave.workspace`
+- **systemd:** `systemctl --user restart dave-workspace.service`
+
+This is the **safe way to pick up an in-place version change** (e.g. after `pnpm update`). `stop` then `start` would race the supervisor's KeepAlive / Restart=always and fail with "Port already in use".
+
+Without a supervisor, falls back to `stop` then `start`.
+
+### `status`
+
+Prints supervisor-aware status:
+
+- **Without supervisor** — running/stopped, PID, port, uptime (from PID file mtime), URL, HTTP health.
+- **With supervisor** — supervisor kind (launchd / systemd), unit/plist path, supervisor state (`running` / `loaded` / `inactive`), supervised PID, port, port listener PID (via `lsof` / `ss` / `netstat`), URL, HTTP health.
+
+The supervisor-aware path bypasses the pidfile entirely — a launchd / systemd-managed process is invisible to the legacy pidfile check.
+
+## Supervisor awareness
+
+If a launchd plist at `~/Library/LaunchAgents/com.dave.workspace.plist` (macOS) or a systemd unit at `~/.config/systemd/user/dave-workspace.service` (Linux) is present, ws.mjs switches into supervisor-aware mode:
+
+| Verb | Supervisor present | Behaviour |
+|---|---|---|
+| `start` | yes, running | "Already running (supervised by X, PID N)" — exit 0. Does NOT spawn a detached process. |
+| `start` | yes, not running | Refuses to spawn; tells the operator how to bring the service up via the supervisor. |
+| `stop` | yes | Refuses with a helpful message — `kill <pid>` triggers KeepAlive instant respawn. Exit 1. |
+| `restart` | yes | Delegates to `launchctl kickstart -k` / `systemctl --user restart`. |
+| `status` | yes | Reports supervisor state + port-listener PID, ignoring the pidfile. |
+| `open` | yes | Resolves the port via prefs and opens the URL; no pidfile lookup. |
+
+Detection is purely file-existence: a unit file alone activates the supervisor path. Whether the unit is loaded is reported as `state`. Cross-platform parity is guarded by tests — a launchd plist on Linux (or a systemd unit on macOS) is ignored.
+
+**Test-only env var:** `WORKSPACE_SUPERVISOR_PLATFORM_OVERRIDE` forces `ws.mjs` to treat the host as the named platform (`darwin` / `linux` / `win32`) when probing for a supervisor. This is how the e2e suite exercises both supervisor branches from any host — launchd behaviour can be asserted on Linux CI and systemd behaviour on macOS dev boxes. Unset in production; honoured only by `detectSupervisor`'s existing dependency-injection contract.
+
+### `open`
+
+Opens the server URL in the default browser. Errors if the server is not running.
+
+## Extension mechanism
+
+Operator forks can layer pages and API routes over the core app without forking `server.mjs`.
+
+### Static page overlay
+
+Place HTML files in `operator/extensions/workspace/`. The server checks that directory before `core/tools/workspace/app/`, so any same-named file there takes precedence. No config required — the directory's presence activates the overlay.
+
+```
+operator/extensions/workspace/home.html   → overrides core home.html
+operator/extensions/workspace/mypage.html → served at /mypage.html
+```
+
+### Additional API routes
+
+If `operator/extensions/workspace/api.mjs` exists, the server imports it at startup and calls its `register(addRoute)` export. Use `addRoute(method, pathname, handler)` to register routes. Routes registered here shadow same-method+pathname core routes (logged at startup).
+
+```js
+// operator/extensions/workspace/api.mjs
+export function register(addRoute) {
+  addRoute('GET', '/__api/my-data', (req, res, url, repoRoot) => {
+    res.writeHead(200, { 'Content-Type': 'application/json' });
+    res.end(JSON.stringify({ ok: true }));
+  });
+}
+```
+
+### Nav registration
+
+The main sidebar is driven by a declarative manifest rather than hard-coded markup. This lets extensions surface new pages in the nav without shadowing `index.html`.
+
+**Core manifest:** `core/tools/workspace/app/nav.json` defines the built-in entries.
+
+**Extension manifest (optional):** `operator/extensions/workspace/nav.json`. Same shape, merged after core. Missing file is not an error.
+
+**Shape:**
+
+```json
+[
+  {
+    "id": "mypage",
+    "label": "My Page",
+    "href": "/mypage.html",
+    "section": "Extensions"
+  }
+]
+```
+
+| Field | Required | Purpose |
+|---|---|---|
+| `id` | yes | Drives the sidebar DOM id `nav-<id>` and the internal NAV_MAP key. Must be unique within the merged manifest — extension items with a core id replace the core entry in place (warning logged). |
+| `label` | yes | Sidebar text and breadcrumb label. |
+| `href` | yes | Navigation target. Extension pages typically use `/<name>.html`; core pages use `/core/tools/workspace/app/<name>.html`. |
+| `section` | no | Section header. Defaults to `Navigation`. Any other string creates a new section appended after the core sections (in manifest order). |
+| `aliases` | no | Additional paths that should highlight this nav item when loaded (e.g. `project-detail.html` highlights `Projects`). |
+
+**Endpoint:** `GET /__api/nav` returns `{ "items": [...] }` — the merged manifest in final order. The shell fetches this on load and renders the sidebar dynamically. Read-through cached with mtime invalidation; no restart needed after editing a manifest. If the endpoint fails, the shell falls back to a minimal Home-only nav rather than rendering a white page.
+
+**Missing pages:** if an `href` doesn't resolve to a real page (neither a core page nor an extension overlay), a warning is logged at startup but the item stays in the list — useful while building.
+
+**Example:** copy `core/tools/workspace/nav.json.example` to `operator/extensions/workspace/nav.json` and adjust for your pages. A worked demo:
+
+```bash
+# Create a new extension page
+cat > operator/extensions/workspace/mypage.html <<'EOF'
+<!DOCTYPE html><html><body><h1>My Page</h1></body></html>
+EOF
+
+# Register it in the nav
+cat > operator/extensions/workspace/nav.json <<'EOF'
+[{ "id": "mypage", "label": "My Page", "href": "/mypage.html", "section": "Extensions" }]
+EOF
+
+# Reload the browser — "My Page" appears in a new "Extensions" section.
+```
+
+### Live reload
+
+Live reload was temporarily removed pending a workspace rebuild. Refresh the browser manually (Cmd+R / Ctrl+R) after editing core pages or extension overlays. See the PR "Remove live-reload SSE mechanism (temporary — pending workspace rebuild)" for context.
+
+## Tests
+
+```bash
+node --test core/tools/workspace/test.mjs
+```
+
+Pass the explicit test file. `node --test <dir>` does not work on Node 24 — the runner expects a CommonJS entry in the directory and will error out without one.
+
+## Requirements
+
+- Node.js 24+
+- No npm dependencies (node built-ins only)