The previous commit said "nobody has probed the running site". I then probed it,
so the docs should not keep hedging.
curl -sI https://0pt.app/
HTTP/2 402
server: Vercel
x-vercel-error: DEPLOYMENT_DISABLED
strict-transport-security: max-age=63072000
https://0pt.app/api/health -> HTTP 402, body "Payment required / DEPLOYMENT_DISABLED"
Two facts hold simultaneously and the docs now state both: the Coolify deploy hook
fires for real on every push to main, AND the public product domain is dark behind a
disabled Vercel deployment with DNS never cut over. Neither cancels the other.
Still not established, and still marked as such: whether the Coolify app builds and
starts. A deploy endpoint returning 200 means the request was accepted, not that a
container came up healthy.
Side note worth recording for PR #19: the HSTS header on that 402 response is
Vercel's platform default, which is exactly the disappearing-on-cutover risk
next.config.mjs in PR #19 was written to remove.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Six documents on main assert that no Coolify app has been provisioned for 0pt and
that cd.yml's COOLIFY_APP_ID is a literal placeholder whose guard fails the job on
purpose. That is no longer true, and the gap is not cosmetic: it means a merge to
main silently ships to production while the repo's own docs promise it cannot.
Measured, not assumed:
* repo Actions secret COOLIFY_TOKEN exists, created 2026-08-31T11:34:34Z
(GET /api/v1/repos/sax3l/0pt/actions/secrets)
* repo Actions variable COOLIFY_APP_ID exists with a real 24-character value,
not the "TODO-no-coolify-app-provisioned-yet" literal
(GET /api/v1/repos/sax3l/0pt/actions/variables)
* both guards in .gitea/workflows/cd.yml therefore pass; on the push to main at
1ff34410 (2026-09-06) the job "Deploy to Coolify / deploy" (run 11695, job
26295) finished SUCCESS with "coolify deploy HTTP 200" in its log
Deliberately NOT claimed: that the Coolify app builds, starts or serves, or that
0pt.app DNS points at it rather than Vercel. Nobody probed the running site, and
every corrected passage says so explicitly rather than replacing one unverified
claim with another.
Corrected: README.md "Deploy", docs/02-architecture.md hosting callout,
docs/architecture/decisions/0001 (consequence annotated, decision untouched --
an ADR is a historical record), docs/runbook/incident.md (the symptom row is now
inverted: the risk is an unintended deploy, not a red job),
docs/compliance/GOLDEN-STANDARD-REPORT.md D4 (❌ -> ⚠️, not ✅, because "webhook
accepted" is not "app serves"), docs/compliance/INVENTORY.md CI row.
Falsifiable check over all six files (stale claim present without a correction
marker = red):
origin/main -> FAIL (12 findings)
this branch -> PASS
mutation: drop only the README bullet -> FAIL
mutation: drop only the runbook correction -> FAIL
The check initially passed vacuously on docs/02-architecture.md because PR #32 had
already put the string "CORRECTED 2026-09-06" in that file for an unrelated reason;
the marker was made specific so the check could actually fail there too.
Docs only. No workflow files, no .gitignore, no source.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
siax.config.json declared deploy.target: "vercel", which conflicts with
the SIAX Cloud platform pattern every sibling OS repo (n0d, st0re, aud0)
follows: a Dockerfile "for Coolify" (already present in this repo) plus a
.gitea/workflows/deploy.yml that POSTs a restart to a Coolify app UUID.
Investigated before changing anything:
- 0pt.app is confirmed live on Vercel (Server: Vercel, 200 OK) but its own
/api/health reports db/queue "not_configured", and POSTing to /api/orders
creates an order that is not durably persisted (in-memory store only, per
this repo's own docs/08-infrastructure.md and docs/architecture/
ARCHITECTURE.md, both independently verified live 2026-07-19 / 2026-08-07,
and reconfirmed live again today). It's a fully-built marketing/demo
surface with no real backend behind it -- not a live product serving real
customer data. Safe to change deploy config without a cutover plan.
- Dockerfile already exists and is already written "for Coolify" (node:24-
alpine multistage, non-root, /api/health healthcheck) -- no changes needed
there.
- No .gitea/workflows/deploy.yml existed. Added one following the exact
pattern used by n0d and st0re (POST /api/v1/deploy?uuid=...&force=false
with COOLIFY_TOKEN). No Coolify app has been provisioned for 0pt yet, so
the app UUID is a literal placeholder and the workflow fails loudly by
design until a real app + token are in place -- this does not silently
ship a broken deploy config.
This changes only this repo's declared *intent*. It does NOT touch the live
Vercel deployment, delete the Vercel project, or move any traffic --
that cutover (provision Coolify app -> verify -> DNS -> decommission
Vercel) is a separate, larger decision. README and ARCHITECTURE.md updated
to state this plainly rather than let them contradict the new config.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Brings 0pt to the SIAX repo standard. README, LICENSE (proprietary, correct
for this repo), Dockerfile and .gitea/workflows/ci.yml already existed and are
left untouched; no .github/workflows exists.
The architecture document was written by reading the code (entrypoints,
routes, services, migrations, Dockerfile, env, tests) and by probing the live
0pt.app instance -- not from the templates. It therefore contradicts the
existing docs in several places, deliberately:
* /api/0pt/* answers ANONYMOUSLY in production (live-verified 2026-08-07):
GET https://0pt.app/api/0pt returns 200 with no token, and 200 with a
deliberately invalid one. The deployment is current (the newer lakehouse
routes are present), so middleware.ts is simply not running. README lines
49-52 and merge 6531384 claim the opposite. Root cause UNKNOWN -- flagged,
not guessed.
* No handler reads x-0pt-verified-tenant. middleware.ts sets it; nothing else
in the repo reads it. Every /api/0pt/* handler takes tenant_id from the
request body/query instead, so tenant isolation is not implemented.
* Everything outside /api/0pt/* has no auth at all (matcher scope), including
GET /api/admin/metrics and GET /api/orders (both live-verified 200 anon) and
POST /api/payments/{id}/release, which flips an order to "delivered"
regardless of payment.
* CL0UD policy client is fail-open and AUD0 audit is a silent no-op when their
URLs are unset, with no production guard -- unlike AUTH_ENFORCE, which has one.
* connections/db-grant documents AES-GCM encryption it does not implement.
* The FastAPI engine (services/api) has zero authentication despite
lib/engine.ts sending X-Internal-Token.
* services/scrapers/waf_bypass.py (FlareSolverr, Tor, cloudscraper, proxy pool,
undetected browser, fake identities) plus flaresolverr/tor-proxy in
services/infra/docker-compose.data-stack.yml directly contradict CLAUDE.md
§1 and the README's compliance claim. Left in place -- deletion is a Simon
decision, recorded as open question 2.
* Production has NO database (live /api/health reports db:not_configured) and
the whole /api/0pt/* capability layer is per-module in-memory Maps, so state
does not survive a cold start and is not even shared between route modules.
siax.config.json deviates from the template on two fields, on purpose:
deploy.target is "vercel" (live-verified Server: Vercel header), not "coolify",
and designSystem is null because @siax/ui is not a dependency here. Both
deviations are documented in ARCHITECTURE.md §5 and §8.
Docs-only change. No code, CI, LICENSE or workflow files were modified.
The auth seam read `process.env.AUTH_ENFORCE === 'true'`, so an absent env
var meant NO authentication: any fresh container, local run, DR restore or
redeploy that dropped the variable served /api/0pt/* anonymously, taking the
tenant from the caller-supplied X-Tenant-Id header. 0pt.app is deployed and
was answering anonymously (verified: an invalid Bearer token plus an
arbitrary X-Tenant-Id returned 200), so this was a live hole, not latent.
* authEnforced() now returns true unless AUTH_ENFORCE is explicitly "false"
(trimmed, case-insensitive). Unset/empty/misspelled => ENFORCED.
* assertAuthConfigSafe() throws AuthMisconfigurationError when
NODE_ENV=production and enforcement resolved off, naming AUTH_ENFORCE. It
runs at middleware module load (startup) and on the env-driven request
path, so a production instance can neither boot nor serve a single
unauthenticated request with auth switched off.
* .env.example no longer teaches AUTH_ENFORCE=false; README's Deploy section
states the fail-closed posture (no DEPLOY.md in this repo).
* 7 new tests, incl. the regression case: with AUTH_ENFORCE unset and no
`enforce` option, an unauthenticated request is rejected with 401. No test
was inverted or deleted -- none asserted the open default; the three
enforce:false cases now describe the explicit local-dev escape hatch.
Tests: 121 passed / 1 skipped before, 128 passed / 1 skipped after.
Typecheck and build clean; advisory lint unchanged (16 pre-existing problems).
Scope: auth default only. The matcher still covers /api/0pt/* alone, and the
handlers still take tenant_id from the query/body rather than the verified
principal -- both described in the PR body, neither fixed here.
admin
Claude Opus 5