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