Commit History
-
[NOTICKET] fix: F-9 — redact PII in the two persisted artifacts
Rifqi Hafizuddin +1: Claude Opus 4.8`pii_flag` was an ingestion-time control only. It nulls `sample_values` going into the planner prompt, and REPO_STATUS §8 claims "real values never enter prompts" — true of samples, false of results. Nothing stops the planner SELECTing a flagged column, and it should not: "list our top 20 customers by revenue" legitimately selects `customer_name` and `email`. Those real values then reached two places that KEEP them: 1. `message_traceability.data` — persisted, and served by a GET with no auth (F-3 was declined, so the service secret is the only control there). 2. Report evidence tables — rendered into `reports.content`, permanently, versioned. `retrieve_data` now reports `meta.pii_columns`, resolved through the IR select list so aliases are honoured, and both sinks redact those cells to "[redacted]". Per the lead's 2026-07-23 decision the ASSEMBLER still receives the real rows, so the answer prose is unchanged and the question stays answerable. Verified end-to-end through th…60887f6
-
[NOTICKET] revert: drop F-3 user_id scoping on /charts + /traceability (lead decision)
Rifqi Hafizuddin +1: Claude Opus 4.8Reverts the F-3 half of 0cb7d53. Rifqi restated the standing decision: traceability does not take user_id, and by the same logic neither does charts. The message_id-only lookup for /charts (lead decision 2026-07-13) and (analysis_id, message_id) for /traceability stand as they were. Reverted in full so nothing half-applied is left behind: - both endpoints back to their pre-F-3 signatures, no optional query param, no scoped=false logging - PostgresChartStore.list_for_message / turn_exists back to message_id-only; the ChartStore Protocol and NullChartStore likewise - the contract's two FE-facing "becoming required" notes removed — no FE change is being requested, and none should be Deliberately KEPT (not part of F-3): - degraded_seam="chart_persist" + repr(exc) on the chart-persist seam (#42) - PostgresTraceabilityStore.get's optional user_id parameter, which predates this work (shipped in fd4865b). Its docstring now records that the endpoint will NOT pass…d998370 -
[NOTICKET] feat: bound catalog render + blob read; scope charts/traceability; mark degraded seams
Rifqi Hafizuddin +1: Claude Opus 4.8DEV_PLAN #40, #41, #42. #41 F-13 — TabularExecutor buffered an entire Parquet blob and read_parquet'd it with no size check. Filtering and the 10k row cap both happen after the frame exists, so they bound the RESULT, never the working set. An OOM here is the one failure in this service that escapes every never-throw seam: the process dies, taking every concurrent request with it. Neither storage backend could report an object size, so `object_size()` is added to both (S3 head_object -> ContentLength, Azure get_blob_properties().size), each returning None rather than raising. The executor now refuses >500 MB BEFORE downloading, with a post-download byte check as the fallback when the probe is unavailable — that one cannot prevent the download, but it does stop read_parquet from multiplying the bytes into a frame several times larger. #41 F-12 — CatalogSummary.render() had no truncation at all; 400 tables x 30 cols measured ~241k tokens per planner call, x3 retries. Two ceilings now, w…0cb7d53 -
[NOTICKET] fix: split report floor from report body; scope analysis reads by user_id
Rifqi Hafizuddin +1: Claude Opus 4.8Two defects with one root cause, plus the security pair from the 2026-07-23 review. Report correctness. Planner recipes R2/R2b make the analyze_* step optional (R2 is "ONE grouped retrieve_data IR (+/- analyze_aggregate)"; R2b, added yesterday, is explicitly "NO analyze_* step"), so an aggregate answered entirely inside one retrieve_data IR is a correct, complete analysis that uses no analyze_* tool. One predicate gated both "is this session worth a report" and "should this run appear in it", so those runs were classed non-substantive, dropped from the report body, and their business question rendered "Unanswered" while the chat had answered it correctly (analysis 966224d4, two of six runs, both threshold questions, real findings). - has_reportable_result (BODY): plan HAS an analysis step -> it must have succeeded; plan has NO analysis step -> a successful non-check_* task is enough. A run whose analysis step FAILED still stays in `unresolved`. - has_successful_analysis (FLOOR) a…fd4865b
-
fix/ check and new chart tool (#16)
- check: table-level column drill + drop misleading "name a table" hint (ef0c7b1c5aa49a244b02f1b5eea15cc77dcf2bcb) - [KM-715] charts: render_chart tool + message_charts store + GET /api/v1/charts + planner viz slice (87cfcf884d923ee4bcd722e0e4ef4d90d7eaedca) - [KM-715] checkpoint: S1a deterministic quality checkpoint between runner and assembler (f3c8de34dc19a573031b67fd4f48dcfbadcdfed8) - [KM-715] docs: sync REPO_STATUS/DEV_PLAN + land SPINE_V2_PLAN (W1/W2 done) (434eacbf2ac8324188ebe5e32775dbc9d2a3f49a) - planner: value-handoff (${tN.col} → list) for tabular lookup/anti-join (54070ac1407b751000e49dfe7f102a2be5ab1ff8) - [KM-715] charts: GET /charts by message_id only + tri-state status marker (b8d15761addf4d499c9631df64e7693aa1d61fa2) - [KM-715] report: embed charts as plotly EDA fences; render_chart counts toward the floor (89db8be6b6f11e86ad0776d2ee07f2306e3b6079) - [KM-715] docs: contract + status deltas for the charts lead-review round (96347ee7c55a4eb39a906409ec214463e25c5e35) - …5a60e93
-
/fix traceability (#15)
- [KM-691] Traceability: add resolved data_used layer for the FE (a646735e33f6ac725d0756a88956b0aec15fe495) - check: don't leak user-scope catalog when analysis catalog missing (c0ba82938383169b41059c4125765db5275885e7) Co-authored-by: Sofhia Az-Zahra <sofhiaazzhr@users.noreply.huggingface.co>32abc41
-
/fix planner and report (#13)
- [KM-644] planner: infeasible plan outcome + entity-ranking few-shots (089b69d9b6111e813307c6afbd3e7613bb823f9d) - [KM-644] harden query path: grouped-select rule, int-date trends, sample decode, trace guard (74ad5261736bda0bd72bccdb41565ea67313993a) - [KM-703] add analyze_merge tool: two-table combine (analytics.combine) (8abf635532366d670367557a3ffa03d42371d831) - [KM-567] planner support for analyze_merge: data_right guard + two-retrieve merge few-shot (a029a843247e6ea4d3c79a4e2c1b7571ba4cda69) - [KM-644] report v2: BQ answers, unresolved/excluded sections, evidence tables + curation/readiness endpoints (4ceb058d85c5a2a289443b9411d2b345027fa226) - [NOTICKET] refactor: mint message_id as UUID to mirror analyses_messages id shape (4253733b6b8db0449a82442a915c732ddd55f528) - [KM-644] report: drop Notes/Unresolved/Method sections from rendered markdown (compact report) (eef6de811a139402c79fd74ad4adfc00cf7aff01) - /edit md file (8198cc188ff05a2798ae2056b90b6e56e1bea87b) Co-authored-by…49b0848
-
/feat traceability (#11)
- [NOTICKET] Fix check skill: reply language + tabular inventory routing (1367f41269cf9ef42fd91f311b24d4edf5885c7b) - [KM-691] Develop traceability (23cc2079989fef931a6e146980fe6bf528ee6e92) - [NOTICKET] Humanize check output: hide UUIDs, add lead-in, list format (2bdda8fc3fc4b4e17b4df7fb53aee5abede45add) - [NOTICKET] check: schema-detail view for column/type questions (9e248d9cc5688d6ee622be523a6bedddf5010995) - [KM-691] Make sources trace-authoritative; drop stream sources (b43ecc77f26c1537cbbfddb6800ec4ff62d16441) - [KM-691] Bound traceability payload + reject contradictory IR filter ranges (db6db73d6ab0c2175447946742038443d67b2f78) - /fix planner can now plan quarter comparison (839e32c8d6d5895029072074ab7aba8bb4fcdb6e) Co-authored-by: Sofhia Az-Zahra <sofhiaazzhr@users.noreply.huggingface.co>f873f92