fix: use production entrypoint for P1 manual serve

This commit is contained in:
2026-08-09 22:33:18 +02:00
parent e9755c6feb
commit bd1f4083e9
3 changed files with 188 additions and 51 deletions
+26 -14
View File
@@ -9,8 +9,8 @@ result. Automation never creates `VERDICT.md`, never records PASS, and never con
From a clean repository checkout, Task 8 must already be implemented. Install Node/npm and Git,
`curl`, `unzip`/`zipinfo`, `lsof`, and the harness development environment so `harness/.venv/bin/tht` is executable.
Port `127.0.0.1:8791` must be free. The helper builds and serves only the production backend; it
does not start Docker or the frontend.
Ports `127.0.0.1:8791` and `127.0.0.1:8792` must be free. The helper builds and serves only the
production backend; it does not start Docker or the frontend.
## Lifecycle
@@ -24,19 +24,31 @@ Run these commands from the repository root:
```
`prepare` exclusively creates `.artifacts/manual-acceptance/p1/`, with fresh Git history, fixtures,
secret files, concrete request/inspection commands, and `GUIDE.md`. It leaves status `PENDING` and
the server stopped. It refuses an existing root; use the guarded `stop` and `cleanup` actions rather
than deleting or reusing state manually.
secret files, concrete request/inspection commands, and `GUIDE.md`. It also creates the single regular
`logs/backend.log` with mode `0600` and records its exact path/device/inode ownership. It creates no
supervisor or readiness-status program/file, leaves status `PENDING` and the server stopped, and
refuses an existing root; use the guarded `stop` and `cleanup` actions rather than deleting or reusing
state manually.
`serve` exclusively reserves the lifecycle and PID records before checking the fixed port, then
starts an owned Node supervisor that imports the production backend configuration and app in the same
process and binds it to `127.0.0.1:8791`. Readiness and `backend.pid` bind that exact process to a
random nonce and an ephemeral loopback control endpoint. `stop` revalidates the exact executable,
arguments, repository cwd/root, and process start identity, then requests shutdown over the
nonce-authenticated cooperative channel and requires the exact acknowledgement. It never sends a
numeric terminating signal. `serve`, `stop`, and `cleanup` are serialized; ambiguous, stale, or
starting records remain for operator inspection. `cleanup` removes only the exact stopped owned fixed
root. Foreign siblings and automated integration artifacts are outside its cleanup boundary.
`serve` holds the external lifecycle lock, validates the canonical production
`backend/dist/server.js`, every owned root/runtime/log ancestor, the absence of a legacy supervisor,
and the original log identity before spawning. The log is opened with no-follow semantics and its
file descriptor is passed directly to the child. The child is the production Node entrypoint itself:
`node --import data:text/javascript;base64,<immutable-preload> backend/dist/server.js` followed by the
three ownership/control arguments. The immutable preload owns only an authenticated fixed
`127.0.0.1:8792` control channel and a bounded startup watchdog; the application binds
`127.0.0.1:8791` normally. Before writing the `RUNNING` PID record, the parent requires an exact
nonce-bound control STATUS and a 2xx `GET /health`, then sends READY to disarm the watchdog. A startup
or non-2xx failure requests nonce-authenticated STOP (or lets the watchdog self-exit) and leaves no
listener or PID record.
`stop` revalidates the exact executable, immutable preload, production script, arguments, repository
cwd/root, and process start identity, then requests STOP over the nonce-authenticated cooperative
channel and requires the exact acknowledgement. The controlled process acknowledges and exits itself;
the production tool never sends a numeric terminating signal. `serve`, `stop`, and `cleanup` are
serialized; ambiguous, stale, or starting records remain for operator inspection. `cleanup` removes
only the exact stopped owned fixed root. Foreign siblings and automated integration artifacts are
outside its cleanup boundary.
After `prepare`, follow the 14 ordered steps in the generated absolute-path `GUIDE.md`. Personally run each generated `http-01` through `http-14` curl script in numeric order; they save the exact status, three validation, three sequential publication, pull, three read responses, and three ZIP exports. Each publication derives its current base commit with a bounded parser from the preceding saved API response, with no placeholder base. Run the five numbered negative validation scripts separately at checklist step 10. The render commands validate the bounded saved read response,
its commit-addressed owned snapshot path, the saved publish commit, and the installed Git HEAD before