WIN-012: Windows transcript sections and screenshot-marker linkage (deferred from WIN-011)

[deffenda]

Summary

Two macOS transcript.md blocks remain unimplemented on Windows after WIN-011 / #995 because
Windows has no data source for them. They were deliberately not faked.

Evidence

macOS Sources/BugNarrator/Models/TranscriptSession.swift markdownContent emits:

1. ## Transcript Sections — one ### <title> per section with a - Time: <range> line and body
   text. Windows CompletedSession
   (windows/src/BugNarrator.Core/Models/CompletedSession.cs) has no transcript-sections field,
   and nothing in the Windows pipeline segments a transcript into sections.
2. Screenshot → marker linkage: macOS renders linked to **<marker title>** using
   SessionScreenshot.associatedMarkerID. Windows ScreenshotArtifact
   (windows/src/BugNarrator.Core/Models/ScreenshotArtifact.cs) has no associated-marker id. The
   relationship exists only in the opposite direction — SessionTimelineMoment.RelatedScreenshotId.

Adding either field today would produce an always-empty model field (speculative churn), which is
why #995 scoped them out. This ticket tracks doing it properly.

Scope

NEW:

• transcript-section shaping in BugNarrator.Core once a segmentation source exists

EDIT:

• windows/src/BugNarrator.Core/Models/CompletedSession.cs
• windows/src/BugNarrator.Core/Models/ScreenshotArtifact.cs
• windows/src/BugNarrator.Core/Workflow/CompletedSessionMarkdownBuilder.cs

Non-goals: changing macOS Swift behavior; re-opening the summary.md split settled in #995.

done_when

• Windows either produces real transcript sections and renders ## Transcript Sections matching the
  macOS shape, or this ticket records an explicit decision that Windows will not segment transcripts
  and the parity matrix says so.
• Screenshot→marker linkage is derived from real recorded data (e.g. by inverting
  SessionTimelineMoment.RelatedScreenshotId) and rendered like macOS, or explicitly declined in
  the parity matrix.
• No model field is added that nothing populates.

validation

• dotnet build windows/BugNarrator.Windows.sln -c Debug
• dotnet test windows/tests/BugNarrator.Core.Tests/BugNarrator.Core.Tests.csproj -c Debug
• dotnet test windows/tests/BugNarrator.Windows.Tests/BugNarrator.Windows.Tests.csproj -c Debug

evidence

• Golden-string test output for the extended transcript contract.

Split out of #995. Related drift context: #965.

[deffenda]

Related, for when this one is picked up: see #1000 and my note on #998.

WIN-012 extends transcript.md (sections + screenshot-marker links) — the same surface where I found that the Windows-side parity test asserts a macOS output macOS does not produce (the Recorded: line is locale/timezone-dependent on macOS and invariant/UTC on Windows).

If #1000 lands before this is built, WIN-012 can assert against the shared golden fixture instead of a hand-typed literal, and the sections/marker-link format gets machine-checked across both implementations rather than eyeballed.

[deffenda]

Moved to ai/blocked by the shepherd sweep.

Not a scope or contract problem — this ticket is blocked by its own stated
evidence. Both remaining clauses depend on a Windows data source that does not
exist:

• ## Transcript Sections — CompletedSession has no transcript-sections field,
  and nothing in the Windows pipeline segments a transcript into sections.
• Screenshot→marker linkage — ScreenshotArtifact has no associated-marker id;
  the relationship exists only in the opposite direction
  (SessionTimelineMoment.RelatedScreenshotId).

The ticket itself records that adding either field today would produce an
always-empty model field, which is why #995 scoped them out.

Per the repo's effort-leak guardrails, a ticket blocked on a missing input stays
in ai/blocked with the blocker named rather than sitting in ai/backlog where
it reads as available work. Leaving it in the backlog is what makes an autonomous
loop pick it up and produce placeholder churn.

Unblocking input required: a decision on whether Windows will segment transcripts
at all (and if so, the segmentation source), or an explicit parity-matrix entry
declining it. Either unblocks the ticket; neither is a coding task.

[deffenda]

Unblocked. The "no data source" premise is false.

Reviewed by an independent committee (codex + agy, same prompt, neither seeing the
other). Both reached the same verdict.

The data is already there. macOS does not invent sections — TranscriptSectionBuilder
derives them from timestamped segments in a verbose_json response. Windows
already requests exactly that:

windows/src/BugNarrator.Windows.Services/Transcription/OpenAiTranscriptionClient.cs:43
content.Add(new StringContent("verbose_json"), "response_format");

It then discards everything except text.

codex: "The missing capability is parsing/plumbing, not data availability."
agy: "The data exists; the Windows client is just ignoring it. Claiming 'no data
source' because you haven't written the parsing logic yet is a cop-out."

The provider-variation worry is also covered — a fact the committee found that
this ticket did not have: macOS already tolerates absent segments and falls back to
proportional text sections (TranscriptSectionBuilder.swift:27). A provider that
returns no segments is an ordinary compatibility case, not a blocker.

Screenshot→marker needs no new field either. The inverse relation already
exists as SessionTimelineMoment.RelatedScreenshotId. Both reviewers independently
warned against adding a marker id to ScreenshotArtifact — that duplicate
reference is the speculative churn this ticket was right to avoid, but the runtime
reverse lookup is not.

Split into two slices, smallest first:

1. Render screenshot→marker linkage by inverting RelatedScreenshotId. No schema
   migration, no model change.
2. Separately, widen the Windows transcription return from string to
   { text, segments }, then build and render ## Transcript Sections.

Do not bundle UI or issue-extraction changes into either.