Dentolize · Watchtower Foundation Walkthrough
On this pageScope of what's testableWhat to checkEdges worth noting for later (WT-1, not this PR)

For Quality

Scope of what's testable

This PR has no business logic — it's two static routes and a static HTML page. There is nothing to functionally test in the traditional sense (no forms, no data, no auth). QA effort here should focus on confirming the sandbox pipeline behaves as claimed, not on the Watchtower product (which doesn't exist yet).

What to check

  • GET /health on the watchtower-api host returns HTTP 200,

content-type: text/plain, body exactly ok (packages/watchtower-server/index.js:10-14). This is what the container healthcheck depends on — if it regresses, the sandbox will report the service as down.

  • Any other path on the watchtower-api host returns HTTP 200,

content-type: application/json, with the fixed payload shown in Sandbox Smoke-Test Scaffold (packages/watchtower-server/index.js:16-22). There's no 404 handling — every unmatched path falls through to this same catch-all, which is worth flagging if a real router is expected later.

  • The web landing page renders with no console errors and no broken

asset references — verified visually in Walkthrough. Since it's static HTML with inline CSS and no JS, there isn't much surface for bugs, but confirm the page still loads if the sandbox host changes how it serves static files.

  • Deploy-comment row: confirm the PR's deploy comment includes a

Watchtower row linking to a reachable URL, per the PR description (this validates the sandbox detect → build → route → comment path this PR exists to prove out).

Edges worth noting for later (WT-1, not this PR)

  • Neither package has a package.json, so no lint/test/build tooling runs

against them yet — don't expect CI coverage here beyond "does the sandbox boot it."

  • PORT is read from an env var with a hardcoded fallback of 4010

(packages/watchtower-server/index.js:7); if the real WT-1 service keeps this pattern, confirm the sandbox always sets PORT explicitly rather than relying on the fallback in shared infrastructure.

  • There is no authentication anywhere in this branch — the "same shared

credentials + 2FA as Dashboard/Admin" claim on the landing page is aspirational, not implemented. Don't test it as if it exists yet.