2 Commits

Include renames

Author	SHA1	Message	Date
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