Found by drb-correlation-review while reviewing #102.
drb-c2-core/app/internal/summarizer.py:70-71 reads doc["transcript"] (whole-call) when building an incident summary, and ignores transcript_corrected entirely. Same defect class as #87 (coords), #80/#95 (embedding/severity), #102 (LLM correlation prompt): a multi-scene call contributes text from its other scenes to an incident it was only partially part of, and the summary is built on raw rather than corrected transcription.
This one is user-visible — it lands in the incident summary shown on the incident page.
Fix shape: the summarizer already iterates an incident's linked calls; for each, use that call's scene-relevant text. The per-scene transcript field added to intelligence.py's processed[] in #102 is written to the call doc only as the primary scene's — so either (a) persist per-scene text on the call doc (schema change, overlaps #96's per-scene debug record), or (b) at minimum switch to transcript_corrected or transcript so summaries stop being built on raw transcription. (b) is a one-liner and worth doing now; (a) is the real fix and should ride with #96.
Blocked-by / relates-to: #96 (per-scene call-doc record), #102 (the correlation half of this leak).
Found by drb-correlation-review while reviewing #102.
`drb-c2-core/app/internal/summarizer.py:70-71` reads `doc["transcript"]` (whole-call) when building an incident summary, and ignores `transcript_corrected` entirely. Same defect class as #87 (coords), #80/#95 (embedding/severity), #102 (LLM correlation prompt): a multi-scene call contributes text from its *other* scenes to an incident it was only partially part of, and the summary is built on raw rather than corrected transcription.
This one is **user-visible** — it lands in the incident summary shown on the incident page.
**Fix shape:** the summarizer already iterates an incident's linked calls; for each, use that call's scene-relevant text. The per-scene `transcript` field added to `intelligence.py`'s `processed[]` in #102 is written to the call doc only as the primary scene's — so either (a) persist per-scene text on the call doc (schema change, overlaps #96's per-scene debug record), or (b) at minimum switch to `transcript_corrected or transcript` so summaries stop being built on raw transcription. (b) is a one-liner and worth doing now; (a) is the real fix and should ride with #96.
Blocked-by / relates-to: #96 (per-scene call-doc record), #102 (the correlation half of this leak).
Fixed in #132 (fix/96-114-per-scene-call-doc), option (a) from the issue's fix shape (the real fix, riding with #96 as predicted).
Each scene's own text is now persisted on the call doc under scenes.<scene_index>.transcript (server-26#96's new map), alongside which incident_id that scene resolved to. summarizer.py's new _scene_text_for_incident reads a linked call's scenes map and picks only the scene(s) whose incident_id matches the incident being summarized, joining more than one if several scenes landed in the same incident.
Also did the one-liner half (b) regardless, for calls with no scenes field (predates this change): falls back to transcript_corrected or transcript instead of raw transcript.
14 new tests (including an end-to-end _summarize_incident test proving a 2-scene call only contributes its incident-relevant scene's text, not the whole-call blend), full suite 364 -> 378 passed.
Fixed in #132 (fix/96-114-per-scene-call-doc), option (a) from the issue's fix shape (the real fix, riding with #96 as predicted).
Each scene's own text is now persisted on the call doc under `scenes.<scene_index>.transcript` (server-26#96's new map), alongside which `incident_id` that scene resolved to. `summarizer.py`'s new `_scene_text_for_incident` reads a linked call's `scenes` map and picks only the scene(s) whose `incident_id` matches the incident being summarized, joining more than one if several scenes landed in the same incident.
Also did the one-liner half (b) regardless, for calls with no `scenes` field (predates this change): falls back to `transcript_corrected or transcript` instead of raw `transcript`.
14 new tests (including an end-to-end `_summarize_incident` test proving a 2-scene call only contributes its incident-relevant scene's text, not the whole-call blend), full suite 364 -> 378 passed.
Review found and fixed one blocker (commit 0fe6d3b):
Blocker — stale scenes entries survived re-extraction.PATCH /calls/{id}/transcript wipes tags/severity/location/units/embedding before re-running extraction, but not scenes, and doc_set(merge=True) can only add/overwrite nested map keys, never remove one. A call corrected from 3 scenes down to 1 kept scenes.1/scenes.2 with pre-correction transcripts and incident_ids forever — corrupting the exact per-scene tally #96 exists to make trustworthy, and able to re-feed stale text into #114's summarizer fix if a stale scene's incident_id still named a real incident. Fixed with fstore.doc_update(..., {"scenes": fstore.DELETE_FIELD}) — a real delete, not a merge over {}. Added fstore.DELETE_FIELD (re-exports the real sentinel) and a matching stub entry in tests/conftest.py, which didn't have one. New test: tests/test_reprocess_clears_stale_scenes.py.
Also softened an overclaiming docstring — the Firestore nested-merge behavior is verified against the doc_set wrapper's pass-through code and Firestore's documented contract, not against a live Firestore instance (no SDK available in any sandbox this landed from).
Sandboxed pytest: 378 → 380, all green.
Not fixed, noted instead (non-blocking, safe by construction): the manual-attach endpoint and any future #131 relink both skip writing a scenes entry. summarizer._scene_text_for_incident falls back to whole-call transcript_corrected or transcript when no scene matches — the old #114 behavior, not an error, no data loss, just not the full per-scene fix on those two paths. Worth a follow-up if #131's relink bug turns out to be common.
Review found and fixed one blocker (commit `0fe6d3b`):
**Blocker — stale `scenes` entries survived re-extraction.** `PATCH /calls/{id}/transcript` wipes `tags`/`severity`/`location`/`units`/`embedding` before re-running extraction, but not `scenes`, and `doc_set(merge=True)` can only add/overwrite nested map keys, never remove one. A call corrected from 3 scenes down to 1 kept `scenes.1`/`scenes.2` with pre-correction transcripts and `incident_id`s forever — corrupting the exact per-scene tally #96 exists to make trustworthy, and able to re-feed stale text into #114's summarizer fix if a stale scene's `incident_id` still named a real incident. Fixed with `fstore.doc_update(..., {"scenes": fstore.DELETE_FIELD})` — a real delete, not a merge over `{}`. Added `fstore.DELETE_FIELD` (re-exports the real sentinel) and a matching stub entry in `tests/conftest.py`, which didn't have one. New test: `tests/test_reprocess_clears_stale_scenes.py`.
Also softened an overclaiming docstring — the Firestore nested-merge behavior is verified against the `doc_set` wrapper's pass-through code and Firestore's documented contract, not against a live Firestore instance (no SDK available in any sandbox this landed from).
Sandboxed pytest: 378 → 380, all green.
**Not fixed, noted instead (non-blocking, safe by construction):** the manual-attach endpoint and any future #131 relink both skip writing a `scenes` entry. `summarizer._scene_text_for_incident` falls back to whole-call `transcript_corrected or transcript` when no scene matches — the old #114 behavior, not an error, no data loss, just not the full per-scene fix on those two paths. Worth a follow-up if #131's relink bug turns out to be common.
Fixed and merged (PR #132, commits fae84a4 + 0fe6d3b) — confirmed live on main: summarizer.py has _scene_text_for_incident, reads per-scene text keyed by which incident that scene resolved to. This was already done, just never closed. Closing now.
Fixed and merged (PR #132, commits fae84a4 + 0fe6d3b) — confirmed live on main: `summarizer.py` has `_scene_text_for_incident`, reads per-scene text keyed by which incident that scene resolved to. This was already done, just never closed. Closing now.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Found by drb-correlation-review while reviewing #102.
drb-c2-core/app/internal/summarizer.py:70-71readsdoc["transcript"](whole-call) when building an incident summary, and ignorestranscript_correctedentirely. Same defect class as #87 (coords), #80/#95 (embedding/severity), #102 (LLM correlation prompt): a multi-scene call contributes text from its other scenes to an incident it was only partially part of, and the summary is built on raw rather than corrected transcription.This one is user-visible — it lands in the incident summary shown on the incident page.
Fix shape: the summarizer already iterates an incident's linked calls; for each, use that call's scene-relevant text. The per-scene
transcriptfield added tointelligence.py'sprocessed[]in #102 is written to the call doc only as the primary scene's — so either (a) persist per-scene text on the call doc (schema change, overlaps #96's per-scene debug record), or (b) at minimum switch totranscript_corrected or transcriptso summaries stop being built on raw transcription. (b) is a one-liner and worth doing now; (a) is the real fix and should ride with #96.Blocked-by / relates-to: #96 (per-scene call-doc record), #102 (the correlation half of this leak).
Fixed in #132 (fix/96-114-per-scene-call-doc), option (a) from the issue's fix shape (the real fix, riding with #96 as predicted).
Each scene's own text is now persisted on the call doc under
scenes.<scene_index>.transcript(server-26#96's new map), alongside whichincident_idthat scene resolved to.summarizer.py's new_scene_text_for_incidentreads a linked call'sscenesmap and picks only the scene(s) whoseincident_idmatches the incident being summarized, joining more than one if several scenes landed in the same incident.Also did the one-liner half (b) regardless, for calls with no
scenesfield (predates this change): falls back totranscript_corrected or transcriptinstead of rawtranscript.14 new tests (including an end-to-end
_summarize_incidenttest proving a 2-scene call only contributes its incident-relevant scene's text, not the whole-call blend), full suite 364 -> 378 passed.Review found and fixed one blocker (commit
0fe6d3b):Blocker — stale
scenesentries survived re-extraction.PATCH /calls/{id}/transcriptwipestags/severity/location/units/embeddingbefore re-running extraction, but notscenes, anddoc_set(merge=True)can only add/overwrite nested map keys, never remove one. A call corrected from 3 scenes down to 1 keptscenes.1/scenes.2with pre-correction transcripts andincident_ids forever — corrupting the exact per-scene tally #96 exists to make trustworthy, and able to re-feed stale text into #114's summarizer fix if a stale scene'sincident_idstill named a real incident. Fixed withfstore.doc_update(..., {"scenes": fstore.DELETE_FIELD})— a real delete, not a merge over{}. Addedfstore.DELETE_FIELD(re-exports the real sentinel) and a matching stub entry intests/conftest.py, which didn't have one. New test:tests/test_reprocess_clears_stale_scenes.py.Also softened an overclaiming docstring — the Firestore nested-merge behavior is verified against the
doc_setwrapper's pass-through code and Firestore's documented contract, not against a live Firestore instance (no SDK available in any sandbox this landed from).Sandboxed pytest: 378 → 380, all green.
Not fixed, noted instead (non-blocking, safe by construction): the manual-attach endpoint and any future #131 relink both skip writing a
scenesentry.summarizer._scene_text_for_incidentfalls back to whole-calltranscript_corrected or transcriptwhen no scene matches — the old #114 behavior, not an error, no data loss, just not the full per-scene fix on those two paths. Worth a follow-up if #131's relink bug turns out to be common.Fixed and merged (PR #132, commits
fae84a4+0fe6d3b) — confirmed live on main:summarizer.pyhas_scene_text_for_incident, reads per-scene text keyed by which incident that scene resolved to. This was already done, just never closed. Closing now.