Commit History
-
[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
-
/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
