rbrooks/Quest-Board

Watch

Fork 0

[Backend] Mark sessions recorded before the timeline fix as unreliable #328

New issue

Closed

opened 2026-08-25 20:38:47 +00:00 by claude-bot · 1 comment

claude-bot commented

2026-08-25 20:38:47 +00:00

Contributor

Severity: MEDIUM. Found in the August 2026 session lifecycle review (#319).

Why

Nine sessions were recorded and processed under the broken capture clock. Their audio has already been reaped, so they cannot be repaired — a re-merge would need per-track data that no longer exists, and re-processing has nothing correct to re-process.

Leaving them unannotated is the problem. Their summaries have already fed the lore pipeline into campaign canon, so a GM reading back through the wiki has no way to know which entries came from a scrambled source. This is a data-provenance issue, not a cosmetic one.

Proposed fix

Add a nullable marker to the session record — a transcript_reliability enum, or simply a boolean pre_timeline_fix set by a one-shot migration for every session whose transcript_updated_at predates the capture fix deploy.

Surface it as a small, non-alarming badge on SessionDetail next to the summary and transcript, with hover text explaining that this session was recorded before a known timeline defect was fixed and that its event ordering and speaker attribution may be unreliable. Carry the same marker onto any wiki entry whose originating session is flagged, so provenance survives into the lore layer.

Do not hide or delete the content. The summaries are still substantially useful — the events happened, only the order and some attributions are wrong — and the GM has already hand-corrected at least one of them.

Acceptance criteria

A session-level marker exists and is set by migration for all pre-fix recorded sessions
The marker is exposed on the session read schema
SessionDetail shows an explained badge on affected sessions
Wiki entries derived from a flagged session carry the provenance forward
The marker is set automatically for any future session that trips the duration guards, rather than being purely historical

**Severity: MEDIUM.** Found in the August 2026 session lifecycle review (#319). ## Why Nine sessions were recorded and processed under the broken capture clock. Their audio has already been reaped, so **they cannot be repaired** — a re-merge would need per-track data that no longer exists, and re-processing has nothing correct to re-process. Leaving them unannotated is the problem. Their summaries have already fed the lore pipeline into campaign canon, so a GM reading back through the wiki has no way to know which entries came from a scrambled source. This is a data-provenance issue, not a cosmetic one. ## Proposed fix Add a nullable marker to the session record — a `transcript_reliability` enum, or simply a boolean `pre_timeline_fix` set by a one-shot migration for every session whose `transcript_updated_at` predates the capture fix deploy. Surface it as a small, non-alarming badge on `SessionDetail` next to the summary and transcript, with hover text explaining that this session was recorded before a known timeline defect was fixed and that its event ordering and speaker attribution may be unreliable. Carry the same marker onto any wiki entry whose originating session is flagged, so provenance survives into the lore layer. Do **not** hide or delete the content. The summaries are still substantially useful — the events happened, only the order and some attributions are wrong — and the GM has already hand-corrected at least one of them. ## Acceptance criteria - [ ] A session-level marker exists and is set by migration for all pre-fix recorded sessions - [ ] The marker is exposed on the session read schema - [ ] `SessionDetail` shows an explained badge on affected sessions - [ ] Wiki entries derived from a flagged session carry the provenance forward - [ ] The marker is set automatically for any future session that trips the duration guards, rather than being purely historical

claude-bot added this to the v3.11.5 - Recording Clock Hotfix milestone

2026-08-25 20:38:47 +00:00

claude-bot added the

enhancement

backend

frontend

labels

2026-08-25 20:38:47 +00:00

claude-bot referenced this issue

2026-08-25 21:46:48 +00:00

[Backend] GET /api/sessions/{id} silently drops five declared response fields #417

claude-bot referenced this issue

2026-08-25 22:13:56 +00:00

[Backend] GET /api/sessions/{id} silently drops five declared response fields #417

rbrooks referenced this issue from a commit

2026-08-25 22:24:18 +00:00

feat(backend): mark sessions recorded before the timeline fix (#328)

rbrooks referenced this issue from a commit

2026-08-25 22:24:18 +00:00

fix(backend): populate the session response fields the builder silently dropped (#417)

claude-bot referenced this issue

2026-08-25 22:29:56 +00:00

v3.11.5 — per-speaker recordings never shared a session clock (#320) #418

claude-bot referenced this issue from a commit

2026-08-25 23:11:52 +00:00

Merge PR #418: v3.11.5 — per-speaker recordings never shared a session clock (#320)

claude-bot referenced this issue

2026-08-26 05:48:51 +00:00

[Backend] The audio retry endpoint disarms both duration guards #421

claude-bot referenced this issue

2026-08-28 19:15:06 +00:00

[Backend] Persist transcript segment rows and render the text format as a view #335

claude-bot commented

2026-08-29 07:57:38 +00:00

Author

Contributor

Shipped — closing as part of a v3.11.5 bookkeeping sweep.

Migration f1a2b3c4d5e7 ("session pre_timeline_fix marker (#328)") adds a boolean NOT NULL DEFAULT false on sessions, backfilled true for every session that already had a transcript. Surfaced through app/models/session.py:179 and app/schemas/session.py:161, both explaining that such a session's event ordering and speaker attribution are unreliable.

The migration's own note is the part worth preserving: those recordings cannot be repaired — the source audio is gone — so the marker is provenance, not a to-do. And the backfill needs no date comparison because the fix ships in the same release.

That framing turned out to matter more than expected. When v4.0.0 rewrote transcription, extraction, validation and composition, this marker is what distinguishes a session whose attribution can be trusted from one whose cannot, without anyone having to remember which release a recording predates.

Shipped — closing as part of a v3.11.5 bookkeeping sweep. Migration `f1a2b3c4d5e7` ("session pre_timeline_fix marker (#328)") adds a boolean NOT NULL DEFAULT false on `sessions`, backfilled true for every session that already had a transcript. Surfaced through `app/models/session.py:179` and `app/schemas/session.py:161`, both explaining that such a session's event ordering and speaker attribution are unreliable. The migration's own note is the part worth preserving: those recordings **cannot be repaired** — the source audio is gone — so the marker is provenance, not a to-do. And the backfill needs no date comparison because the fix ships in the same release. That framing turned out to matter more than expected. When v4.0.0 rewrote transcription, extraction, validation and composition, this marker is what distinguishes a session whose attribution can be trusted from one whose cannot, without anyone having to remember which release a recording predates.

claude-bot closed this issue

2026-08-29 07:57:57 +00:00