17 Commits

Include renames

Author	SHA1	Message	Date
admin	8f7a064177	fix(doctor-tests): GOV-06-tester uppdaterade till running-truth (0pt#96:s prod-truth-fix; down+402/404 var den föråldrade paret; ok:false-next-to-200 är nu negativa-fallet)	2026-09-22 21:11:33 +02:00
admin	f6a29da7e5	fix(deploy): corepack-retry-loop 8×15s i båda build-stegen (server6-EGONNRESET-flaken) + GOV-06 live-evidens 2026-09-22 (0pt.app=200)	2026-09-22 20:49:01 +02:00
admin	31671beb46	docs(evidence): färska prober 2026-09-15 — runtime healthy i SIAX Cloud (health ok/ready 200/headers live, edge-DB 60 tabeller), 0pt.app fortfarande Vercel 402 (DNS-cutover = Simon-punkt); operationalState förblir ärligt 'down'	2026-09-15 03:13:28 +02:00
Simon AxelssonandClaude Opus 5	8ebc90ffa3	fix(security,repo-honesty): real security headers + a doctor that checks truth, not presence ... Two defects of the same kind: the repo asserted things about itself that were not true, and nothing in it could tell. A. CHANGELOG.md claimed CSP/HSTS/X-Frame-Options since 2026-08. `main` contained none of it -- a repo-wide grep for `content-security-policy|strict-transport-security|x-frame-options` matched exactly one file, CHANGELOG.md itself. The only header on 0pt.app was Vercel's own HSTS default, which does not survive the move to Coolify/Traefik that siax.config.json and .gitea/workflows/cd.yml are already pointed at. - next.config.mjs: `headers()` on `/(.*)` with CSP (frame-ancestors 'none', base-uri 'self', object-src 'none', form-action 'self'), HSTS, X-Frame-Options DENY, X-Content-Type-Options, Referrer-Policy, Permissions-Policy; plus poweredByHeader: false. Same idiom as sax3l/siax-io's next.config.mjs. - Carve-outs re-derived against THIS tree, not inherited: the stale `ci/security-headers-and-scanning` branch (8d2ff73, 142 commits behind) carried a `form-action https://checkout.stripe.com` allowance justified by a redirect that is actually `window.location.href`, which form-action does not govern -- dropped rather than kept as decorative permission. frame-src is derived from NOCODB_BASE_URL/METABASE_SITE_URL, the same env the components/embed.tsx iframe is configured from, so wiring that component up cannot be silently blanked by this header (the failure sax3l/siax-io recorded as SIO-013). 'unsafe-eval' is dev-only. - tests/security/security-headers.test.ts: blocking regression gate inside `pnpm run test`, i.e. the required "CI (SIAX Cloud) / quality" context. Asserts against expectations written out in the test, not imported from the config. Proven to fail: removing X-Frame-Options -> `pnpm run test` exits 1; weakening frame-ancestors to 'self' -> exits 1. B. scripts/siax-doctor.mjs validated that siax.repo.json fields were PRESENT, never what they said. Measured on this tree: operationalState "running" (false) and "down" (true) both gave 40/40, exit 0, byte-identical output. - Value checks (enums, git.siax.io const, fleet node pattern, bare-hostname form), cross-file consistency (declared prod hostnames must appear in this repo's own siax.config.json / contracts/openapi.yaml, and vice versa), and GOV-06 substantiation: operationalState must be backed by a dated probe record in evidence/operational-state.json that agrees with it. Liveness is not knowable offline; whether a liveness CLAIM is backed is. Offline, deterministic, no network -- CI can never go red for want of an internet connection. - `--live` (opt-in) probes the declared hosts for real and checks the headers on the wire; `--write-evidence` refreshes the record. Not wired into CI on purpose. - tests/repo/siax-doctor.test.ts runs the doctor inside `pnpm run test` and asserts the negative cases against fixture trees (SIAX_DOCTOR_ROOT), so the "cannot fail" defect cannot come back. C. CHANGELOG.md is now true. The header claim stands; the four claims it was bundled with (Trivy --exit-code 1, gitleaks, SHA-pinned actions, SBOM + license artifacts) are still false on main and are listed as not implemented instead of left asserted. All four live in .gitea/workflows/**, a protected path on this repo, so they need an authorised workflow change. Nothing under .gitea/workflows/** or .gitignore is touched. Verified: pnpm run typecheck exit 0; pnpm run test exit 0 (74 files / 965 tests passed, up from 72/945); pnpm run build exit 0 and the built .next/routes-manifest.json carries all six headers; node scripts/siax-doctor.mjs 55/55 exit 0; --live 57/57 exit 0. eslint on the new files exit 0 (repo lint is advisory and its 17 pre-existing problems are unchanged). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-15 02:43:32 +02:00
Claude Opus 5	7441de5429	BI-P103: the cited evidence/bi-p103 did not exist — measure it ... Same shape as the BI-P029 finding in the previous commit. `bi-slo.ts` said "evidence/bi-p103 records the first baselines". There was no evidence/bi-p103. The catalogue and the evaluator were both real and both well covered — against SYNTHETIC events. A synthetic event carries whatever duration the test author typed, so that suite proves the arithmetic and nothing about the system: it cannot tell you whether a dashboard query takes 8 ms or 8 s. BI-P103's DoD is one sentence, "measured baselines exist", and it was the part not done. tests/integration/bi-p103-slo-baseline.integration.test.ts runs 460 real queries against a live ClickHouse over a 400 000-row fact table -- 120 cold dashboard queries (each a different bucket so the BI-P020 cache genuinely misses), the same 120 again through the same shipped cache now hitting, and 220 exploration queries, that last number chosen so explore.p99's min_samples of 200 is MET rather than reported low-confidence. Every duration is wall-clock around the real call, and the telemetry goes through the shipped producer and the shipped evaluator, so the evidence is written by the code under test. Measured: 7 of 11 objectives produced a number, `fully_measured` false, measured_fraction 0.64. The four that did not each say why -- dashboard freshness is a property of the dataset, the exploration timeout is a configured ceiling, report completion has no producer in 0pt at all, and report delivery is N0TIFY's receipt. A baseline table listing only the rows that worked is how an estate comes to believe it measures more than it does. The evidence also records what is NARROWER than production, because these numbers will be quoted: the cached path is the in-process reference cache and not Valkey, every latency is the engine round trip with no HTTP or authorization layer, and there is no concurrency. The suite is adversarial about its own inputs: a "cold" sample that came from the cache fails, a cache "hit" that missed fails, a cached p95 that is not faster than the cold p95 fails, and dropping the exploration sample to 60 fails on explore.p99 being low-confidence rather than quietly recording a p99 over 60 requests. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 08:27:37 +02:00
Claude Opus 5	468a87c00c	BI-P029: the cited parity test did not exist, and it caught a real bug ... `semantic-provider.ts` cited tests/integration/semantic-parity.integration.test.ts as the proof of the one BI-P029 DoD surface it claimed was closed, and `providerReadiness().proven` asserted the comparison had been made against live ClickHouse. The file did not exist. The citation was the evidence. Writing it exposed a divergence that had been shipping: `compileRequestToClickHouse` had no notion of a metric's OWN filters (BI-P028 `MetricSpec.filters`). `ResolvedMetric` did not carry them and the compiler never asked, so a metric defined as "invoiced revenue EXCLUDING internal transfers" executed as "invoiced revenue". On the committed fixture that is 11 249 instead of 1 250 for one country -- a plausible-looking number, 9x too large, under the correct canonical metric id. The registry, the governance checks and the MetricFlow manifest all carried the filter; only the thing that actually ran did not. * `ResolvedMetric` gains `definition_filters`, already resolved onto the physical dim_names key so the compilers stay dumb. * The ClickHouse compiler folds them into THAT metric's conditional aggregate, never into the shared WHERE -- two metrics in one request may exclude different rows, and a shared predicate would apply one metric's meaning to the other. `renderFilter`'s uniquifier becomes a string so request filter `0` and metric filter `0_0m` cannot collide in the parameter map. * `compileRequestToSemantic` carries them through, and `MetricFlowProvider.compile` emits them per metric. The test runs both compile paths against one live ClickHouse: 0pt's `sumIf` compiler, and a renderer driven only by the provider's structured query that shares no SQL-generation code and emits `sum(if(...))` with inlined literals. It asserts the two SQL strings differ, so parity is not vacuous. Backing the fix out reproduces the pre-fix numbers, and the suite records them itself rather than quoting a console: evidence/bi-p029/semantic-parity.json. Three of BI-P029's four DoD surfaces stay OPEN and still say so: MetricFlow itself is not executed (no Python runtime is provisioned here), Superset is not implemented, and the AI Analyst path has not been compared. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 08:23:43 +02:00
Claude Opus 5	f33cc8d32f	feat(analytics): BI-P104 — a benchmark harness that refuses to quote one number ... Six dataset profiles (small SaaS, medium business, VehIQ market, large event, wide table, geospatial), one representative question each, run on ClickHouse 26.3.10.60 and DuckDB 1.5.5 with 2 warmups discarded and 9 timed repetitions. evidence/bi-p104/benchmark.json. The harness's job is to stop the benchmark from lying: - overlapping ranges are INDISTINGUISHABLE whatever the medians say. Three of the six real comparisons came out that way, one of them with a 1.6x median gap — which is exactly the headline a noisy host manufactures. - every sentence carries the range, the sample size and the stability, so it cannot be trimmed to "4.4x faster" without visibly deleting the caveats. - under 5 samples nothing is comparable at all. A three-run benchmark is an anecdote. - every engine BI-P104 names appears in the evidence, and the five nothing measured carry a reason each. The running Trino belongs to another lane, so benchmarking through it would have measured their configuration. Measured shape, warm cache, one idle host, these query shapes only: DuckDB faster on small_saas (1.6-8.2x) and vehiq_market (2.4-13.3x), SLOWER on large_event (0.2-0.9x, count DISTINCT over 5M rows), indistinguishable on medium_business, wide_table and geospatial. One finding from the harness's own tests: an engine declared available that produced no run came out of buildEvidence() with no reason — the dangerous case, since it reads as "we could have and chose not to say". It now gets a generated reason. A second from the runs: DuckDB's progress bar writes to STDOUT and corrupted the first transcript; it is disabled explicitly and the JSON is read from a sentinel. 10 unit tests + 4 against real engines. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 04:06:43 +02:00
Claude Opus 5	96ff601248	feat(analytics): BI-P105 — a pre-aggregate serves only while it is provably undrifted ... A slow query is a complaint; a drifted pre-aggregate answers instantly, with confidence, and is wrong. So the router is fail-closed on eight named reasons, and the one people leave out — drift_never_verified — is the one that matters on launch day: a brand-new aggregate is exactly as unproven as a drifted one. Proved against ClickHouse 26.3.10.60, 2M rows, a real materialized view (evidence/bi-p105/materialization-drift.json): after backfill match, 48 buckets, 801 571 002 both sides GDPR erasure ALTER TABLE ... DELETE on the source. An MV is an INSERT trigger and never sees a mutation, so the aggregate kept the deleted revenue: it would have reported 801 571 002 against a true 761 580 554 — 39 990 448 overstated, 5.251%, with NOTHING stale. Staleness at the moment of the decision: 1 second. guarded router base_table (state_not_serving) counterfactual a staleness-only router SERVES it — measured, not assumed after rebuild match, and routing returns to the materialization Drift detection treats a MISSING bucket as drift even when every value present is correct (late-arriving rows are the sneakiest failure), and an empty comparison as insufficient_data rather than match — the same false green BI-P025 found in a quality check over an empty table. The measured speed-up is reported as a distribution, not a figure: p50 3.4x, but the run-to-run range spans 0.6x-7.5x on one idle host, so quoting "3.4x" as a property of the system would be misleading (BI-P104 doctrine). 19 unit tests + 4 against live ClickHouse. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 03:56:32 +02:00
Claude Opus 5	1a12e8a882	feat(analytics): BI-P061 — dashboard releases, with the publish race measured both ways ... DRAFT -> PUBLISHED -> SUPERSEDED as a ledger (sql/010) rather than a column on the frozen version: sql/008 already makes DashboardVersion immutable at the database, and a lifecycle column there would have meant weakening that. Rollback mints a NEW version carrying the old document and publishes it, so "we went back to v3" is a timestamped fact (v5 = rollback_of_version 3) rather than a hole where v4 used to be. It is verified by BI-P060 canonical hash, and documentOf() refuses to serve a stored document whose hash no longer matches the release — a dashboard that renders an unapproved definition is worse than one that will not open. The claim worth attacking is "only one release can be live". The application check is read-then-write, so it is NOT the guarantee, and the evidence says so in both directions against Postgres 16.15: guard_absent partial unique index dropped -> BOTH concurrent publishes commit, dashboard ends with TWO live versions guard_present index in place -> loser fails 23505 on opt_analytics_dashboard_release_one_published, one live evidence/bi-p061/dashboard-release-race.json, reproducible with scripts/bi-p061-release-race.mjs. Two findings while writing the tests, both fixed here rather than papered over: the one-draft-per-dashboard index makes the two-draft race impossible to even construct (so the race is run as two create-and-publish transactions, which is what a "save and publish" button does), and an UPDATE matching zero rows raises nothing — which reads as "refused" to a careless test, so the immutability test asserts the row exists first. 23 tests: 8 unit + 15 against live Postgres. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 03:51:04 +02:00
Claude Opus 5	c864c8c417	fix(analytics): revert 18 files reformatted by mistake, and actually apply the Iceberg fix a previous message claimed ... Two corrections, both of my own errors. 1. SCOPE CREEP, NOW REVERTED. Running `prettier --write` on whole directories reformatted 18 files this branch had no business touching — the entire merged BI-P002..P012 core (arrow/, domain/, engine/, repositories/, five analytics integration suites) and, absurdly, search-opensearch.integration.test.ts, which has nothing to do with this work. The changes were purely stylistic quote churn, but they added ~1,400 lines of noise to the diff, made the PR harder to review honestly, and invited conflicts with the four other lanes working in this estate. All 18 are now byte-identical to origin/main again (verified with `git diff origin/main --name-only`, which reports nothing for them). Formatting is now applied only to the files this branch actually owns. 2. A COMMIT MESSAGE THAT DESCRIBED A FIX THAT WAS NOT IN THE CODE. Commit 3ee0230 said the "does NOT ship the Iceberg table" assertion had been moved from a filesystem check to `git ls-files`. It had not. The patch anchor used double quotes, prettier had already converted that file to single quotes, so the replacement silently matched nothing and the script printed its success line anyway. The suite then passed — but only because I had just deleted the fixture directory, so the OLD filesystem assertion happened to be true. That is precisely the failure mode this branch keeps writing tests against: a green run that means something different from what it appears to mean. The fix is now genuinely applied and verified the way it should have been the first time — by running the suite WITH the Iceberg fixture present on disk, which is the case that previously failed. It passes, and it now also asserts that the parquet/csv fixtures ARE tracked, so a version shipping no fixture at all would fail rather than pass vacuously. 957 tests pass with ClickHouse, Postgres and DuckDB live. typecheck, eslint and prettier clean on the files this branch owns. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 03:16:30 +02:00
Claude Opus 5	3ee023017b	fix(analytics): move the DuckDB live suite out of tests/integration, and add the BI docs ... CI's integration job failed, and it failed CORRECTLY. That job provides a live OpenSearch and a live ClickHouse and then asserts that nothing in tests/integration/ skipped, on the stated principle that "a skipped suite must never masquerade as a green integration gate". The DuckDB suite needs a Python interpreter that job does not provide, so it skipped, and the guard fired — the first suite in that directory ever to skip there. Moving the file to tests/duckdb/ respects the guard rather than weakening it. Loosening it to tolerate skips would have traded a real gate for one green job, which is the trade this estate keeps regretting. The suite still runs, still fails rather than skipping when DUCKDB_PYTHON is set and DuckDB is broken, and is still pinned by the committed evidence. Also fixed: "does NOT ship the Iceberg table" asserted against the FILESYSTEM when the claim is about what is COMMITTED. The live suite rebuilds that table locally, so the assertion failed whenever both suites ran in one pass — it was testing the wrong thing rather than catching a real problem. It now asserts against `git ls-files`, and also asserts the parquet/csv fixtures ARE tracked, so a version that stopped shipping any fixture would fail too. docs/analytics/BI_QUERY_METRIC_QUALITY.md is organised around what is PROVEN and what is NOT, because the second list is the one that gets dropped. It records the five findings and the six open items, including that BI-P029's MetricFlow was never executed and that BI-P021's budget is a bound rather than a hard cap (measured 130x overshoot at a 100ms poll). It also reports, without changing it, a latent flaw in .gitea/workflows/ci.yml (a protected file this branch does not touch): the integration guard's second pattern `Tests [0-9]+ passed` never matches, because vitest writes that summary with ANSI colour codes between the words. The guard is therefore STRICTER than it reads — "any skip fails" rather than "skipped and nothing passed" — so nothing is currently unguarded, but the escape hatch does not work and someone will eventually be puzzled by it. 957 tests pass with ClickHouse, Postgres and DuckDB all live. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 03:08:11 +02:00
Claude Opus 5	a9ae7f25a4	feat(analytics): BI-P014 — DuckDB provider, and the measured finding that its sandbox does not work the way it looks ... BI-P014's security requirement is the whole prompt: DuckDB is a local engine with `read_csv('/etc/passwd')` built in. Two layers. LAYER 1, the mount registry: a caller names ARTIFACT IDS, never paths. The registry resolves an id, checks the artifact belongs to the caller's tenant, and realpath()s the result to confirm it is still inside the mount root once symlinks are followed. A symlink to /etc/passwd, a traversing relative path, an absolute path, and a sibling directory sharing the root's prefix (/mnt/artifacts-evil for root /mnt/artifacts) are each refused. A cross-tenant read is AUTHORIZATION_DENIED, deliberately not NOT_FOUND — an operator reading the audit trail needs to see an attempted cross-tenant read as one. LAYER 2, THE FINDING: `SET allowed_directories=[...]` ALONE IS A NO-OP. Measured on DuckDB 1.5.5. With allowed_directories set to a single mount directory and nothing else, `read_csv('/etc/passwd')` RETURNED THE FILE and an https:// URL was fetched over the network. Only when `enable_external_access = false` is ALSO set does the allow-list bind; the same reads then fail with "Permission Error: Cannot access file". `lock_configuration=true` afterwards stops a query re-opening either. So the obvious spelling of this control — set the allow-list and move on — yields a setting that appears in duckdb_settings(), looks like a sandbox, and permits everything. That is `trivy --exit-code 0` in a different costume. The bootstrap is therefore emitted as ONE unit, `assertSessionSandboxed` refuses a session missing any part of it, and the measurement itself is PINNED by a test that never skips: if someone simplifies the bootstrap, the pinned evidence (`read_etc_passwd_succeeded: true` for the naive spelling) keeps the finding attached to the build rather than to a comment that would rot. Twelve bypass attempts run against a real DuckDB with LAYER 1 REMOVED — sent straight to the engine, registry not in the picture. Zero succeeded. The counterfactual runs in the same session and is asserted: the mounted file IS readable, so "nothing succeeded" is not a sandbox that blocks everything, which would be an outage rather than a control. A locked session is then shown unable to re-open its own sandbox, all three ways. DoD, against real fixtures: Parquet aggregates correctly (SE 394.5, NO 105.5), CSV round-trips a value containing a quote, and an ICEBERG SNAPSHOT reads via iceberg_scan on an exact metadata JSON — which is not a workaround: DuckDB refuses to glob for the latest version because globbing can read uncommitted data, and an exact metadata file is what "snapshot" means. Arrow is reported UNPROVEN by `readiness()` with the reason: DuckDB's arrow extension is a network install the offline environment could not download. THREE DEFECTS IN MY OWN TESTS, found and fixed rather than tidied away: * a bypass-corpus entry was `SELECT 1 FROM (SELECT 1) t` — not an attack at all. It succeeded and was reported as a leak. A corpus entry that cannot fail is as useless as a check that cannot. Replaced with real ATTACH and COPY attempts. * the harness ran the session bootstrap outside its try block, so a statement that correctly REFUSED to re-open a locked sandbox killed the subprocess and surfaced as an unreadable "Command failed" instead of as the meaningful refusal it was. * the Iceberg fallback was `expect(evidence.iceberg ?? "unbuilt").toBeDefined()` — a check that can never fail. It let a run without the fixture ERASE the recorded Iceberg result from the evidence file while both suites stayed green. It now rebuilds the fixture when pyiceberg is available and, when it is not, asserts against the previously recorded result and marks it as carried forward. The Iceberg fixture is deliberately NOT committed: pyiceberg writes absolute paths into its metadata and Avro manifests, so a committed table resolves only on the machine that built it, and a fixture that silently fails everywhere else is worse than none. tests/fixtures/duckdb/README.md says so and gives the rebuild command; the recorded result is the artefact instead. Heavy artifacts are refused with CAPABILITY_UNAVAILABLE and pointed at N0D, per BI-P014 — silently running a 40 GB scan in the API process is how a preview engine takes down a control plane. 35 unit tests, 12 live tests. Evidence: evidence/bi-p014/duckdb-sandbox.json. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 02:54:53 +02:00
Claude Opus 5	6cb00add57	feat(analytics): BI-P025/BI-P026 — quality providers that fail on empty, freshness that refuses to be silent ... Both prompts are about a FALSE GREEN, so both are tested by constructing the false green and requiring a failure. BI-P025. Three provider kinds, and the interface makes the difference visible instead of implying parity: `providerKind` is "executing" or "ingesting". The native provider runs checks; the dbt and Great Expectations adapters INGEST results produced elsewhere (n0d#38 owns dbt execution against BI-P022, and GE is Python — nothing here runs it). Calling all three "providers" while only one executes is how "we have Great Expectations coverage" ends up in a status report. THE FALSE GREEN, proven against a live ClickHouse 24.8.14.39: a `not_null` check over an EMPTY table returns violations=0, evaluated=0. The raw counts are asserted first — the engine really does say zero-over-zero — and then the provider is required to call it a FAILURE, not a pass. Every rule compiles to a VIOLATION expression rather than a "rows that are fine" count, so the distinction cannot be lost at the runner layer. Same treatment for the ingesting providers: a MISSING dbt result is a failure, and dbt's `error`, `warn` and `skipped` are each asserted not to be passes. `skipped` in particular is the exact shape of l0re's 28 silently-skipped Postgres tests. The gate: zero verdicts QUARANTINES. "No rules ran" and "everything passed" produce the same green in most implementations, which is how a quality gate stops gating without anyone noticing — api0's `trivy --exit-code 0` in another costume. A later passing run does not auto-release either; release takes a principal and a reason, or a flapping rule would quarantine and un-quarantine a dataset between two reads of the same dashboard. BI-P025's DoD is the READ side: a quarantined projection is REFUSED, not annotated. An annotation on a dashboard nobody reads is not a quarantine. Live counts, all exact, from evidence/bi-p025/native-quality-live.json: not_null 5/118, range 3, distribution 4, unique 11. The unique figure is 11 rather than the 6 the first version of the test asserted — the five empty-string customers are duplicates of each other, so not_null and unique overlap on the same defect. The engine was right and the fixture arithmetic was wrong; the breakdown is written into the test rather than the number quietly adjusted. Tenant isolation re-proven on this path specifically, because a quality run uses an ADMINISTRATIVE credential: with 618 rows in the base table, t_alpha evaluates 118 and t_beta 500, and t_beta's blocking failure quarantines t_beta alone. Without the forced predicate one tenant's dirty rows would quarantine another tenant's projection. BI-P026. Five states, and the DoD's operative word is "silently". So the gate sits at the boundary every result crosses: a result with NO freshness envelope is unreleasable — not defaulted to FRESH, not defaulted to UNKNOWN — because "we forgot to attach it" and "the data is current" are indistinguishable to a reader, and any default makes forgetting the silent path. A non-current state without an explicit acknowledgement is refused, so a consumer that ignores the envelope cannot render stale numbers as current. FAILED outranks age: a pipeline that just failed may still hold recently-timestamped data from the previous run, and reporting that as FRESH is how a broken pipeline stays invisible for a day. UNKNOWN is never collapsed into FRESH. 54 unit tests, 11 live tests. typecheck + eslint clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 02:40:35 +02:00
Claude Opus 5	8f6357044f	feat(analytics): BI-P018/BI-P019/BI-P021 — execution model, verified cancellation, a budget that stops queries ... BI-P018 — every field the prompt names, plus the one it names by its absence. The record carries `compiled_query_hash` and never the statement, and that is ENFORCED: `assertNoRawSql` runs before any record is emitted and refuses one whose `error` field looks like SQL. The realistic leak is ClickHouse's own error text, which echoes the query — the test uses exactly that string. The recorder writes at EVERY transition, because a recorder that only writes at the end loses precisely the executions worth investigating. Illegal state transitions throw rather than overwrite a terminal row. The one place raw SQL is retained stays BI-P017's analyst statement history, where a privileged human ran unreviewed SQL and "who ran what" must survive. Different record, different retention posture, stated in both files. BI-P019 — "stops" is VERIFIED, not requested. Aborting the client stops US waiting, not the server; KILL QUERY without SYNC tells you nothing; even SYNC can return while the query unwinds. So cancelAndVerify aborts, kills, then POLLS the process list until the query is GONE or the deadline passes — and if the deadline passes it returns `verified_stopped: false` rather than a cheerful `true`. The return type is an outcome object, not a boolean, so a caller cannot mistake "we asked" for "it stopped". An unreachable engine is read as "still running" (fail closed), so the kill is still attempted at the moment an operator most needs it to be. Proven live against ClickHouse 24.8.14.39, with the counterfactual first: * an identical bomb left alone IS still running after 2s — so "gone after we cancelled" is not just "the query was short"; * the cancelled query had read 6,559,476,156 rows, and was verified gone 57ms after the request; * system.query_log records ExceptionWhileProcessing with code 394, QUERY_WAS_CANCELLED — ClickHouse's verdict, not ours. BI-P021 — the honest version. A budget checked once before execution bounds nothing, and the module says so in its first paragraph. ClickHouse's max_rows_to_read bounds ONE query; it cannot express "this tenant may scan X per hour", which is what a budget is for. So enforcement polls the engine's live read_rows/read_bytes counters and CANCELS the running query, through BI-P019 with verification, when window spend would be exceeded. Measured live: a 1,000,000-row window cancelled the query at 130,883,409 rows, 92ms in, verified stopped, code 394. THE OVERSHOOT IS DOCUMENTED, in the module and in the evidence: enforcement is granular to the poll interval, so this is a bound of the form "within roughly one poll interval of engine throughput", not a hard cap. Quoting it as a hard cap would be wrong. Two more things stated rather than implied: * `enforceInFlight: false` is reported by describeEnforcement() as "NOT ENFORCED — this budget is advisory", and the constructor REFUSES to accept enforceInFlight without a process control; * an unshared window store is reported as non-binding across replicas ("with N replicas a tenant can spend up to N times this budget"). * a query the budget killed is still charged for the work it burned. Not charging is how a tenant learns the cheapest query is a cancelled one. Evidence: evidence/bi-p019-p021/cancellation-and-budget.json 268 unit tests, 7 live tests. typecheck + eslint clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 02:26:05 +02:00
Claude Opus 5	adc7a9be31	fix(analytics): replace the control-character class with a code-point scan (no-control-regex) ... The ASCII-only check used a regex character class of control characters. It tripped eslint's no-control-regex, which the repo's quality gate enforces — and the rule has a point: such a class is unreadable and is exactly the kind of expression a reviewer nods at without checking. Same behaviour, written as an explicit scan naming the permitted set. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 02:19:10 +02:00
Claude Opus 5	d9c8f7190b	feat(analytics): BI-P017 — analyst SQL contract, proven against live ClickHouse with the guard removed ... AnalyticsSQLSession is a SEPARATE class, not a method on SiaxAnalyticsEngine. executeMetric has no raw-SQL surface at all; on the same object the closed DSL would be one refactor away from growing one. ClickHouseAnalyticsEngine .executeQuery stays a documented refusal. FOUR LAYERS, and the guard is deliberately called the weakest: 1 role — the CL0UD analyst role is checked when the SESSION IS OPENED, so a caller without it never obtains an object that can run SQL. 2 guard — statement admission. Comments and literals removed with ClickHouse's own lexical rules, ASCII-only outside literals, one statement, SELECT/WITH only, and every table reference POSITIVELY resolved against the tenant's catalog. Deny-lists are a second opinion, never the mechanism. 3 grants — a per-tenant ClickHouse user with SELECT on that tenant's catalog alone, plus a restrictive row policy on the base tables. 4 views — the tenant catalog holds only VIEWS, each baking `WHERE tenant_id = '<tenant>'`, and tenant_id is not projected. 61 bypass attempts, in one shared corpus, run TWICE: against the guard, and against a live ClickHouse 24.8.14.39 with LAYER 2 REMOVED. The live assertion is not "the engine errored" — it is "no canary came back", with BETA_CANARY seeded into the other tenant's rows and SECRET_CANARY into an ungranted table. The counterfactual runs first: as admin the same base table returns 100 rows and BETA_CANARY IS readable, so the isolation numbers mean something. Result: 0 of 61 leaked. Evidence: evidence/bi-p017/analyst-sql-live-bypass.json. FOUR DEFECTS FOUND BY WRITING TESTS THAT CAN FAIL — three of them mine: * `CREATE ROW POLICY IF NOT EXISTS` is a SILENT NO-OP on re-provisioning. Dropping the user empties the policy's apply-to list; the next run skips re-creation, so the policy survives with `apply_to_list = []`, applying to nobody, while `system.row_policies` still shows the correct select_filter. The restricted user read 100 of 100 rows — BOTH TENANTS — from the base table. Fixed with OR REPLACE + `rowPolicyVerificationSql`, which turns "the policy is applied" from an assumption into a query, and a test that asserts applied_to_user = 1 per object. * `CREATE SETTINGS PROFILE IF NOT EXISTS` has the identical shape: a changed budget never lands. A stale 60-row ceiling survived re-provisioning and starved every legitimate statement, with the DDL reporting success throughout. Also OR REPLACE now. * `describe.skipIf(!reachable)` where `reachable` is set in `beforeAll` skips ALWAYS — vitest evaluates skipIf at collection time. Ten tests reported green while skipping against a live, reachable server. Replaced with the repo's existing env-var gate, which FAILS when CLICKHOUSE_URL is set and the server is down rather than degrading to a skip. * MEASURED, and it changes the design: a ClickHouse user whose profile carries `readonly = 1` cannot have ANY setting changed from the request (Code: 164). The BI-P012 ceilings therefore cannot travel with an analyst statement; they are baked into the user's SETTINGS PROFILE at provisioning. Proven both ways: over-budget scan fails with code 158 from the profile with no setting sent, and an attempt to raise it from the request fails with code 164. Honest about what the guard does NOT catch: `SELECT tenant_id FROM t_alpha_sql.sales` is structurally legitimate and IS admitted. It fails at the engine because the view does not project the column. Recorded in its own GUARD_ADMITS_ENGINE_REFUSES list and asserted live, rather than deleted from the corpus. evidence/bi-p017 is pinned by tests/analytics/analyst-sql-evidence.test.ts, which never skips: adding an attack without re-running the live suite breaks the build, and the pin also checks the counterfactual numbers so the evidence cannot be a recording of an empty database. 246 tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-07 02:17:07 +02:00
Claude Opus 5	84bb9faa4f	feat(analytics): BI-P002..BI-P012 analytics core — domain model, tiers, contracts, Arrow, ClickHouse engine, isolation, governance ... Implements the eight BI program prompts that make 0pt the canonical SIAX analytics capability. Every file is NEW: not one existing file is modified, and src/analytics/clickhouse-analytics.ts is byte-identical to main. BI-P002 — the nineteen canonical entities, verbatim, with tenant_id + project_id on every tenant-owned record. sql/008 gives each one a table. The four version entities BI-P002 names as immutable are enforced by BEFORE UPDATE/DELETE triggers, not by a TypeScript `readonly` — proven by direct SQL against a live Postgres. BI-P003 — RAW/NORMALIZED/CURATED/SERVING with the read rule enforced: assertReadableByBiSurface refuses a RAW dataset to a dashboard unless a recorded exception exists. All eight required declarations are NOT NULL. BI-P004 — DatasetContract and a fail-closed compatibility gate. Fifteen breaking-change classes are each tested twice: refused under a minor bump, accepted under a major one. BI-P005 — Arrow IPC alongside JSON, with a hand-written FlatBuffers writer so no npm dependency (or CVE surface) is added. Conformance comes from three independent implementations, not from self-agreement: pyarrow 25.0.1 and DuckDB 1.5.5 read identical values from both ClickHouse's Arrow and ours, and ClickHouse's own Arrow C++ ingests our 20,000-row batch with exact aggregates. BI-P009 — SiaxAnalyticsEngine with all eight capabilities. The existing ClickHouseAnalytics is COMPOSED, never replaced. executeQuery (analyst SQL) is declared and deliberately refused with CAPABILITY_UNAVAILABLE until BI-P017 and BI-P033 land, rather than opening the raw-SQL hole BI-P011 enumerates. BI-P010 — four purpose-built tables, not one giant one, and the difference is measured against the counterfactual: 48.8ms/40,960 rows vs 174.4ms/5,400,000 rows for the same question; 5/660 granules vs 660/1149. BI-P011 — layered isolation, each layer proven with the layer above removed. Without the forced predicate the same statement returns 50,050 (both tenants); with it, t_alpha gets 50. Without a row policy an unrestricted user sees 2 tenants; the restricted user running the IDENTICAL statement sees 1. BI-P012 — every named limit, fired individually and identified by ClickHouse error code, plus the half usually skipped: an unrelated tenant is timed while a real CPU bomb is in flight and must still return the CORRECT answer. Three defects found by writing tests that can fail: * `CHECK (array_length(purposes,1) >= 1)` can NEVER fail — array_length is NULL for '{}' and a NULL CHECK passes. Fixed with coalesce(); the test that caught it is pinned. * EXPLAIN ESTIMATE run under the caller's own max_rows_to_read fails with code 158 exactly when the estimate would be over budget. Planner calls now use a narrower envelope. * result_overflow_mode=break returns HTTP 200 with 65,409 of 100,000 rows and no indication it is short. Every SELECT ships `throw`. Verified rather than assumed: server7's ClickHouse holds `opt_scraped` (51 tables, 407,793,471 rows, `persons`/`cz_owners` included) — the b0ts plane this module is prohibited from touching — has no `opt_analytics` database, zero tenant_id columns and zero row policies. Nothing there was modified; every proof ran against disposable containers. Evidence: evidence/bi-p002-p012/{test-transcript.txt,bi-p010-benchmark.json, bi-p005-arrow-roundtrip.json,server7-clickhouse-probe.md} Docs: docs/analytics/BI_ANALYTICS_CORE.md Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-06 23:01:27 +02:00