wp-durable · Stage 1 handover (2026-10-10)

Deployment

Deployments (UTC): f9c98150 01:50 first deploy · 82deaa46 06:19 adds /auth · 25be23c3 06:32 redeploy (T0 step 3) · 6719f8fe 06:34 redeploy requested by piinchrome-48.

T0 results

1. /healthz → ok: true, storage: "ok" after the first deploy; credential: "present" after sign-in.
2. POST /v1/submit {"content":"Reply with the single word pong.","requestId":"t0-1"} → submission 8, done after about 4 s, answer pong. Usage of that call: input 39, output 5, total 44 tokens, cost $0.000128.
3. Redeploy 25be23c3: new container healthy within 30 s, credential: "present", submission 8 still readable. Second redeploy 6719f8fe (requested): healthy at 06:35:10 UTC, credential present.
4. Re-POST of t0-1 after the redeploy → same submissionId 8, same answer pong, no new generation task. Verified in the database: generation tasks 9, 14, 18 map one-to-one to submissions 8 (t0-1), 13 (acc-20261010-1), 17 (acc-20261010-2). The usage increase observed at that moment (44 → 106 total tokens) came from piinchrome-48's acceptance submission 13, not from a duplicate run.

Sign-in history: the device-code request was accepted on the first attempt (no fallback). Two codes expired unapproved before Steven used the /auth page; the third was approved and stored at 06:31:07 UTC.

Deviations from the brief

• Container runs as root (node image default) so the volume is writable without a chown step.
• GET /auth (public static sign-in page) and GET / → 302 /auth were added at Steven's request. All /v1/* routes remain bearer-protected; only /healthz and /auth are public.
• Responses carry extra fields: /healthz adds provider, model, rootConversationId, uptimeSeconds; /v1/submissions/:id adds requestId, conversationId; /v1/conversations/:id adds entries; /v1/auth/codex/status adds userCode, verificationUri, expiresAt, intervalSeconds, finishedAt, credential.
• POST /v1/submit answers 202 and includes status next to submissionId and conversationId.
• Sign-in state is in memory: after a redeploy /v1/auth/codex/status reports none while the credential stays present.
• Storage-failure handling: pi-durable 1.1.0 does not export harness.closed / SessionFailed (the README on main is newer). A failed storage read in /healthz returns 503 and exits the process so Railway restarts it; onReport only logs.
• credential: "expired" compares the stored access-token expiry with the clock. pi-ai refreshes on use, so "expired" is informational, not a failure.
• IDs share one global sequence across records, so the first submission is id 8, not 1.
• Railway CLI warns that railway.json config-as-code is deprecated in favour of .railway/railway.ts; it stays honoured until 2026-12-01. Not migrated in Stage 1.
• Node prints one ExperimentalWarning: SQLite is an experimental feature line at startup.
• Acceptance is run by piinchrome-48; my T0 run was a pre-check. I used railway ssh once for a read-only node:sqlite dump of /data/agent.sqlite to verify the task/submission mapping.
• The openai "Sign in with ChatGPT" flow was not used, per the brief change; the legacy openai-codex provider is the only provider registered.

Not done / out of scope

Tools, Apify, datavault, timers, Woodpecker registration, multiple conversations, non-root user, log shipping, IaC migration.