8 Commits

Include renames

Author	SHA1	Message	Date
Claude Opus 5	853f09320c	docs: probed 0pt.app — Vercel answers with HTTP 402 DEPLOYMENT_DISABLED ... 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>	2026-09-06 10:01:17 +02:00
Claude Opus 5	d7a1c4d5e1	docs: the Coolify deploy hook is LIVE — six docs still say it is a placeholder ... 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>	2026-09-06 09:56:53 +02:00
admin	8db56f1b4c	docs: FAS 9 - README/SECURITY updates, CONTRIBUTING, AGENTS, runbooks (deploy/incident/backup-restore/oncall), SLO, prompts	2026-08-10 04:16:30 +02:00
adminandClaude Sonnet 5	ad042d825f	fix(deploy): declare Coolify as the deploy target, not Vercel ... 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>	2026-08-09 12:36:24 +02:00
Claude (SIAX platform session)	bb58617540	docs(standard): add code-verified ARCHITECTURE.md + siax.config.json (S1-S7) ... 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.	2026-08-07 21:48:35 +02:00
Claude (SIAX platform session)	1c1e2cb649	fix(auth): make the AUTH_ENFORCE default fail-closed on /api/0pt/* ... 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.	2026-07-27 13:28:24 +02:00
adminandClaude Opus 4.8	862c2e2651	feat: production tracker loads real order (markets/volume) + proper repo README ... Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-24 23:26:20 +02:00
v0agent	5e53a6d71c	Add README.md	2026-06-24 14:51:57 +00:00