The guard grepped vitest's HUMAN output:
grep -qE "skipped" && ! grep -qE "Tests [0-9]+ passed"
vitest colours that summary. The real line emitted on these runners is
ESC[2m Tests ESC[22m ESC[1mESC[32m97 passedESC[39m | ...
so ANSI escapes sit between "Tests " and the digits and the
two-spaces-then-digits pattern can never match. The first grep still
matched "skipped", so the condition was true whenever a single test
skipped -- no matter how many passed.
Measured on run 13911 job 31183 (this branch, 2026-09-08): 13 files /
97 tests PASSED, 1 file / 2 tests skipped, and the step still printed
"FATAL: integration suites skipped instead of running" and exited 1.
That message was false; the suites ran.
It survived review because it is correct locally -- redirecting vitest
to a file disables its colour, so the pattern matches on a developer
machine and misfires only under CI.
Replaced with vitest's JSON reporter: structured, colourless, and
fail-closed if the report is missing. A/B measured on real reports in
BOTH directions, so the replacement is not merely green:
all skipped (0 passed / 99 pending) -> exit 1 (protection kept)
945 passed + 184 skipped -> exit 0 (false red gone)
report file absent -> exit 1 (fail closed)
The anti-skip guarantee the original guard was written for is preserved:
a run where every suite skips still fails.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Branch protection on `main` requires exactly two status contexts:
CI (SIAX Cloud) / security (push)
CI (SIAX Cloud) / quality (push)
The `security` half could not fail. All three Trivy invocations in this
repo ran with `--exit-code 0`, so the scanner reported findings to stdout
and then exited 0 regardless.
Measured on main @4514d97, 2026-09-08, same scanner (Trivy 0.73.0), same
target, only the flag differing:
A --exit-code 0, clean tree -> exit 0
B --exit-code 0, planted AWS secret access key -> exit 0 (DETECTED
as CRITICAL in the report, gate still green)
C --exit-code 1, same planted secret -> exit 1
D --exit-code 1, probe removed -> exit 0
B is the defect: the required context reported success while the scanner
had a CRITICAL secret in hand. D is why this is safe to land now -- the
tree is clean today, so flipping the flag does not open the gate red.
(PR #19 measured 19 HIGH findings on 2026-08-11; those dependencies have
since been updated on main, 142 commits later.)
The other required context, `quality`, was verified real and left alone:
a planted type error fails `pnpm run typecheck` (exit 2) and a planted
failing assertion fails `pnpm run test` (exit 1, 945 passed baseline).
nightly.yml carried the same flag. A nightly scan exists to catch CVEs
published against code that did not change; with `--exit-code 0` it could
never raise that alarm.
Not fixed here, needs an owner decision: services/scrapers/requirements.txt
uses `>=` ranges only. Trivy's pip scanner cannot resolve unpinned
specifiers, so it omits the file from the scan entirely -- it never appears
as a target. Pinning those same floors with `==` surfaces 3 HIGH findings
(aiohttp CVE-2025-69223, aiohttp CVE-2026-69244, lxml CVE-2026-41066).
Deliberately NOT suppressed with `--skip-dirs`, which would turn a
measurable blind spot into declared policy.
Job names are unchanged, so both required context strings are preserved.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ny blockerande pytest-gate + Postgres/OpenSearch/ClickHouse-härdningen i
ci.yml ur PR #10 berör .gitea/workflows/ (estate-skydd). De nya real-infra-
testerna är exekverade lokalt (Postgres 5/5; OpenSearch/CH-gate behåller
main:s konfig tills beslut) — hålls utanför merge så koden landar.
_apply_matches ignorerar medvetet decided_by=score (defence in depth:
score/fuzzy får aldrig skapa canonical identity-länkar) — testernas
stub-bridge returnerade score-pairs och förväntade ändå merge → CI-fail var
implementationen som hade rätt. Pairs är nu decided_by=stable-identifiers.v3.
Verifierat: pytest services/api/tests 6+14 pass, full unit 945/945,
typecheck EXIT 0, real-Postgres 5/5.
CI-härdningen ur PR #10 (Trivy HIGH/CRITICAL blocking, Postgres-service i
integration, python-engine pytest-gate) berör .gitea/workflows/ och kräver
estate-policy-beslut — dokumenterad separat, hålls UTANFÖR denna merge så
koden kanoniseras utan blockering. Härdningens nya tester är exekverade
lokalt: real-Postgres 5/5 (DATABASE_URL-aktiverad outbox).
Both public 0PT hosts are dead as of 2026-09-07:
$ curl -sSI https://0pt.app/
HTTP/2 402 ... server: Vercel ... x-vercel-error: DEPLOYMENT_DISABLED
(identical on /api/health and /api/ready)
$ curl -sSI https://api.0pt.app/health
HTTP/2 404 ... server: Vercel ... x-vercel-error: DEPLOYMENT_NOT_FOUND
siax.repo.json claimed operationalState "running"; siax.repo.v3.json
claimed "degraded" on the strength of a 2026-09-04 probe where
/api/health still answered 200. Neither holds now, so both files move to
"down" and both domain entries record the probe that motivated it.
Also recorded: both names resolve into Vercel address space
(216.150.16.193 / 216.150.1.1 and 216.150.1.129 / 216.150.16.65), not
the Hetzner fleet.
No DNS, deploy or provider setting was touched.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
0pt.app svarar i dag HTTP 402 DEPLOYMENT_DISABLED (Vercels betalningsspärr) och
har ingen självhostad ersättare igång. Det här gör appen faktiskt byggbar och
körbar på Coolify. Referens: sax3l/siax-io, som redan kör självhostat på flottan
— dess Dockerfile återanvänds i form i stället för att uppfinna ett eget mönster.
next.config.mjs:
* output: "standalone" — runtime-imagen kör `node server.js` i stället för att
släpa med pnpm, corepack och hela node_modules-trädet.
* images.unoptimized: true BORTTAGET. Det var v0-generatorns standardvärde, inte
ett val: next.config.mjs var orörd sedan "Initial commit from v0". Självhostat
är rätt lösning att låta Next optimera själv.
* poweredByHeader: false.
Dockerfile (fyra steg, samma form som siax-io):
* node:24-alpine -> node:22-alpine. Båda CI-workflowsen bygger på node 22;
att bygga och köra på samma major som grinden testar tar bort en version-skew.
* libc6-compat (sharp), icke-root `node`, HEALTHCHECK mot /api/health,
npm/npx strippat ur runtime-imagen (SIO-019-mönstret).
* --ignore-workspace borttaget: motiveringen i kommentaren var inaktuell sedan
P1-21 (pnpm-workspace.yaml har ett giltigt packages:-fält och
packages/schemas är en riktig medlem). Containerinstallationen blir därmed
bit för bit samma kommando som CI kör.
* --prod=false: Coolify injicerar NODE_ENV=production vid byggtid, och pnpm
hoppar då över devDependencies som next build kräver.
Sharp levereras i ett eget npm-steg, och det är inte godtyckligt:
next build spårar INTE sharp in i .next/standalone (verifierat: standalone-
utdatans node_modules innehöll bara next/, react/, react-dom/). Den uppenbara
lösningen outputFileTracingIncludes fungerar bevisligen inte — globben
"./node_modules/@img/**/*" får Turbopack att panika på pnpms katalogsymlänkar
("Is a directory (os error 21)") och bygget faller med exit 1. Reproducerat, inte
antaget. npm-steget lägger ett platt, symlänkfritt träd som runtime-steget kan
kopiera rakt av, pinnat till versionen i pnpm-lock.yaml, och faller hårt om
versionen inte går att läsa ut i stället för att tyst skeppa trasig optimering.
BEVISAT, inte påstått (fullständiga exitkoder i PR-beskrivningen):
* pnpm install --frozen-lockfile -> 0; next build med HELT TOM env -> 0
* docker build --no-cache -> 0; container startar, /api/health -> HTTP 200
* /api/ready utan DATABASE_URL -> HTTP 503 (faller stängt, som avsett)
* /api/0pt/* utan Bearer -> HTTP 401 (middleware kör självhostat)
* /_next/image -> HTTP 200 image/avif, 1 488 706 B PNG -> 51 161 B (29x)
* sharp laddar i runtime-imagen (libvips 8.18.6, musl-binärer)
* icke-root uid=1000, HEALTHCHECK "healthy", image 1,33 GB -> 423 MB
* typecheck 0, test 0 (930 passerade). lint/prettier faller identiskt på ren
main => pre-existerande, inte infört här. Ingen grind har rörts.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
admin
Renovate