Sandbox Smoke-Test Scaffold

Business view

Before two engineers start building a brand-new internal tool (Watchtower, Dentolize's future account/subscription control plane), the team wanted to make sure the deployment machinery — the sandbox that spins up a preview environment for every PR — could actually detect, build, and expose a new kind of app. Rather than debug the deploy pipeline and the new product at the same time, this PR adds two intentionally throwaway files: a backend that says "I'm alive" and a web page that says "I'm a placeholder." If the sandbox can stand these up and put a working link in the PR comment, the pipeline is proven, and the real Watchtower code can be built on top of it with confidence that deployment isn't the risk.

Nothing here is a feature a clinic, patient, or clinic-staff user will ever see. It's internal tooling for the Dentolize engineering team.

Technical view

packages/watchtower-server

A single file, packages/watchtower-server/index.js:1-27, implements a dependency-free HTTP server using Node's built-in http module — no Express, no package.json, nothing to yarn install:

• Listens on process.env.PORT, defaulting to 4010

(packages/watchtower-server/index.js:7).

• GET /health → 200, content-type: text/plain, body ok

(packages/watchtower-server/index.js:10-14). This is what the sandbox container healthcheck polls.

• Every other path → 200, content-type: application/json, a fixed

payload identifying the app, its status ("foundation scaffold"), and a note pointing at WT-1 as the real replacement (packages/watchtower-server/index.js:16-22).

There's no routing table, no request parsing beyond req.url === '/health', and no state. The header comment (packages/watchtower-server/index.js:1-4) documents that WT-1 replaces this with a standalone Apollo + Express service exposing GraphQL plus a thin REST edge.

packages/watchtower-web

A single static file, packages/watchtower-web/public/index.html:1-27 — a plain HTML document with inlined CSS in a <style> block, no framework, no build step, no JavaScript at all. It renders the heading, tagline, and explanatory copy shown in the Walkthrough, including the note that sign-in will eventually reuse the Dashboard/Admin shared credentials and 2FA. That claim is descriptive of the plan for WT-1; there is no sign-in form or auth code anywhere in this diff.

Not a yarn workspace member (yet)

The repo's root package.json workspaces glob is packages/*, which would normally pick up any directory under packages/. However, yarn workspaces requires a package.json in each member directory to register it, and neither packages/watchtower-server nor packages/watchtower-web has one. So although both directories live under packages/, they are not yarn workspace packages — yarn install and root-level workspace commands don't touch them. The sandbox host runs them directly (node index.js for the server, serving public/ as static files for the web app), not via a workspace script.

Sandbox wiring (outside this repo's diff)

The PR description states that the sandbox host CLI runs the Watchtower apps only when packages/watchtower-* directories are present, guarded the same way as the existing pharmacy package — so branches that don't touch Watchtower are unaffected. It also states the PR-comment deploy row for Watchtower (the WATCHTOWER_URL row visible in the sandbox info) landed via a separate, already-merged PR (#397) to .github/workflows/sandbox.yml, not in this diff. Both of these are sandbox/CI infrastructure changes outside /work/repo's application code — this PR only supplies the two app directories that infrastructure detects and runs.

What WT-1 is expected to replace this with

Per the PR description: a standalone Apollo + Express backend with GraphQL and a REST edge, RBAC, 2FA, and audit logging, plus a real web client behind it. None of that exists in this diff — it's the scope of the follow-on epic (WT-1 / XLZ-556) that branches off this foundation.