Trait HarnessSession 

pub trait HarnessSession {
    // Required methods
    fn harness_id(&self) -> &str;
    fn session_id(&self) -> &str;

    // Provided methods
    fn version(&self) -> Option<&str> { ... }
    fn cwd(&self) -> Option<&str> { ... }
    fn name(&self) -> Option<&str> { ... }
    fn metadata(&self) -> Map<String, Value> { ... }
}

A harness session, as the envelope producer sees it.

Implement this on the type a harness crate already parses out of whatever the harness publishes — a session file, a rollout record, a lifecycle report. The methods are a projection, not a parser: they hand back what the implementor already holds.

Only harness_id and session_id are required, because an envelope without them is not an identity at all — the producer’s completeness rule rejects exactly that pair being absent. Everything else defaults to absent.

Required Methods

fn harness_id(&self) -> &str

The harness this session belongs to — the X-Tapes-Harness-Id value.

Returned by the implementor rather than passed in by the caller so one session type cannot be stamped under two different harness ids by two call sites. The HARNESS_ID_* constants are the vocabulary; a harness crate takes its id from there and reports it here.

fn session_id(&self) -> &str

The harness’s own session identifier — X-Tapes-Harness-Session-Id.

Required, and deliberately not Option: a harness that cannot name its session has no envelope to produce, and its capture client should emit the unknown sentinel rather than an identity with a hole in it.

Provided Methods

fn version(&self) -> Option<&str>

Harness version string — X-Tapes-Harness-Version.

fn cwd(&self) -> Option<&str>

Working directory the harness is running in — X-Tapes-Cwd.

fn name(&self) -> Option<&str>

User-given session name — X-Tapes-Session-Name.

fn metadata(&self) -> Map<String, Value>

Everything else this harness wants carried in X-Tapes-Harness-Metadata, as the JSON object it is encoded from.

Returned by value rather than borrowed because the map is assembled, not stored: a harness typically has a few modelled fields plus a verbatim passthrough of whatever its session file carried that the crate does not model, and the two are one object on the wire. Which keys those are, and how they are spelled, is harness knowledge and belongs on the implementor’s side of this boundary — the producer only caps, encodes, and drops.

Dyn Compatibility

This trait is dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors