What a host serving transcripts must answer, described once.
These are descriptions, not servers: a consumer attaches its own logic with serverLogic and interprets the result with whichever Tapir server matches the effect system it already runs — ZIO, cats-effect, Future, sync. That is why Tapir sits on this side of the module and not in the cross-built sources: the element reaches the same address with the browser's own fetch, so the browser bundle carries none of this.
The address is taken from TranscriptEndpoint, the one place the path and its parameter are written down, so the description and the URL the element builds cannot drift apart.
A transcript names its pictures rather than carrying them, so this is where a page fetches one: the session, the call it answered, and which part of that answer it is. Only the picture formats the contract shows are served, and the answer says what it is rather than leaving a browser to work it out from the bytes — which is what makes an artifact safe to show in a page that is not ours.
Reads one session's transcript, already rendered as the cc-* markup a page inserts as-is.
Reads one session's transcript, already rendered as the cc-* markup a page inserts as-is.
This is the address CC-D3 gives the browser: a transcript's rows have one producer, on the JVM, so the element fetches this instead of drawing rows from the JSON history carries. A refusal answers in the same vocabulary — TranscriptMarkup.trouble, written as HTML — so the element has one thing to do with either answer: insert what came back.
The error output cannot be decoded back into a TranscriptFailure: the wire only ever carries the rendered trouble markup, and there is no reading a status and a page of HTML that recovers which case produced it. That is fine here — this endpoint is read by the browser's own fetch, never by a Tapir client, so nothing ever calls the decode direction. A consumer that wants the failure as data reads it off history, whose error body stays JSON.