Struct TapesAttribution 

pub struct TapesAttribution {
    pub harness_id: String,
    pub session_id: Option<String>,
    pub version: Option<String>,
    pub cwd: Option<String>,
    pub name: Option<String>,
    pub parent_sid: Option<String>,
    pub metadata: Map<String, Value>,
}

Session-attribution envelope to serialize into X-Tapes-* headers.

Fields are public so a consumer can construct an attribution the named constructors below don’t express — the fixture oracle does exactly that, because the shared corpus spans harnesses (pi) and field combinations production has no constructor for.

Fields

harness_id: String

Harness identifier; HARNESS_ID_UNKNOWN selects the single-header path.

session_id: Option<String>

Opaque harness-side session id.

version: Option<String>

Harness version string.

cwd: Option<String>

Harness working directory; percent-encoded on the wire.

name: Option<String>

User-given session name; capped and percent-encoded on the wire.

parent_sid: Option<String>

Fork-parent’s harness session id.

metadata: Map<String, Value>

Free-form harness metadata; base64url(JSON) on the wire.

Implementations

impl TapesAttribution

pub fn unknown() -> Self

The cold-race / unrecognised-harness fallback.

pub fn codex() -> Self

Codex traffic whose session identity has not been resolved.

pub fn codex_with_metadata(metadata: Map<String, Value>) -> Self

Codex traffic with no resolved rollout, carrying request-derived metadata (a proxy that saw useful request headers but could not name a session still forwards what it learned).

pub fn codex_session( session_id: &str, cwd: Option<&str>, cli_version: Option<&str>, metadata: Map<String, Value>, ) -> Self

Codex traffic attributed to a resolved rollout session.

pub fn codex_session_with_parent( session_id: &str, parent_sid: Option<&str>, cwd: Option<&str>, cli_version: Option<&str>, metadata: Map<String, Value>, ) -> Self

Codex traffic attributed to a session id with optional resume/fork parent lineage.

parent_sid keeps the envelope’s resume/fork meaning: it must name a harness SESSION, never a sub-thread. A thread-spawn transcript’s parent_thread_id names a THREAD, and emitting it here would make a consumer placeholder-insert a bogus session keyed by that thread id — pass None for subagent rollouts.

pub fn from_headers(headers: &HeaderMap) -> Option<Self>

Read an attribution back out of an envelope a harness stamped on itself, for harnesses whose session identity comes from a managed extension rather than from this crate’s session watchers.

None unless the headers carry a complete envelope: a harness id that is present and is not the HARNESS_ID_UNKNOWN sentinel, plus a non-blank session id. That completeness rule is the point of this constructor. The same rule decides two things in different processes — here, whether a capture client files a turn under an inbound envelope; and in inject_unattributed_envelope, whether the producer preserves an inbound envelope instead of overwriting it with unknown. Two spellings of it drift into a request whose headers say pi and whose ingest row says unknown, so both callers come through here.

Only the plain-text fields are read. cwd, session name, and metadata are percent-encoded or base64url on the wire, and this module is the envelope’s producer half — the parsers live on the tapes side and table-test against the same corpus. Decoding here would stand up a second, drifting implementation of an encoder that is twenty lines above, so those fields come back empty rather than guessed. Nothing is lost today: the self-attributing harnesses stamp exactly the fields this reads. A harness that starts sending the encoded ones wants the decode half added here, once, not at each call site.

pub fn from_session( session: &impl HarnessSession, parent_sid: Option<&str>, ) -> Self

Traffic attributed to a resolved harness session, with optional recovered fork-parent lineage.

Takes HarnessSession rather than any harness’s own session type. That is the whole reason this module can live beside the wire format instead of beside the harness registry: the projection from “what the harness published” to “what the envelope carries” is stated once, as a requirement, and each harness satisfies it on its own side. A new harness reaches this constructor by implementing the trait — nothing here learns its name.