Messages between sessions this session saw are kept whole, with what is known of who sent them and what came of them

actor

A person, a later session, or a tool that reads sessions afterwards and must tell a peer's message from the person's own words.

problem

A message between sessions survives only inside two transcripts, where it reads like typing. Nothing shows a message that was refused, and the host's key-value store holds 4 MiB in all while file writes are not atomic.

outcome

Each session writes what it sent and received, verbatim, with its own session id, the time, the other party as the host named it and what came of the message, in files that a concurrent reader can read or skip.

value

A reader can tell, where the record has evidence, a peer's message from the person's own words, can see a message that was refused or never queued, and treats a gap or a damaged file as unknown rather than as nothing sent.

assumptions

• The record is observational. It covers what the mod saw while it ran and the disk accepted, and it is not an audit log.
• On version 2.1.314 the same peer reached the mod as a session id when the caller sent, as a socket address in the send event and under a name in other sends, and a received message carried a host envelope with a socket address that the sent text did not; no stable key joining these forms has been shown.

Open questions

• non-blocking · question.clientText line 27 · specs/coordination/record.sdp.md:27 · Should the record hold the full text of messages in a project whose material is confidential?Decider: ownerLinks: spec:cc-agents.coordination.adoptionProvisional: Yes, because attribution needs the text. The record stays on the machine where the session ran, and recordText set to metadata for a project replaces the text with its length and hash.
• non-blocking · question.correlation line 31 · specs/coordination/record.sdp.md:31 · Can a received entry be joined to the sender's sent entry?Decider: delegatedProvisional: No claim is made. Attribution may be unknown or ambiguous. Before a stronger claim is written, it is shown with two peers sending identical text, an ordinary agent message and a resumed session, and no identifier is inserted into any message.
• non-blocking · question.auditGrade line 34 · specs/coordination/record.sdp.md:34 · Does the owner need crash-proof durability, an audit-grade log?Decider: ownerProvisional: No. The record is observational with stated coverage limits, and a stronger write path waits until someone requires it.

rule.everyMessage line 40 · specs/coordination/record.sdp.md:40

A session records each message between sessions that it sends and each that it receives, as its mod sees them at the send and receive events, and observing changes nothing: the text passes on untouched and nothing is consumed.

no example exercises it

rule.sessionsOnly line 41 · specs/coordination/record.sdp.md:41

A message to or from an agent of this session and a notification the host raises are not recorded.

no example exercises it

rule.verbatim line 42 · specs/coordination/record.sdp.md:42

The text is kept whole and byte for byte. It is never summarised, shortened, tagged or given an identifier that the receiver would read.

no example exercises it

rule.sentIsAuthority line 43 · specs/coordination/record.sdp.md:43

A sent entry names the sender's own session id and is the authority on who wrote that entry. It does not show which received entry it corresponds to.

no example exercises it

rule.peerAsSeen line 44 · specs/coordination/record.sdp.md:44

The other party is recorded as the address or name the host gave at that event, exactly as given, and as a full session id only when the plugin resolved one. Attribution may be unknown or ambiguous, and the record says so rather than guessing.

no example exercises it

rule.envelopeKept line 45 · specs/coordination/record.sdp.md:45

A received entry keeps the host's envelope as it arrived, apart from the text, and nothing is decided from it.

no example exercises it

rule.deliveryResult line 46 · specs/coordination/record.sdp.md:46

A sent entry holds the result the host returned, which says only that the message was queued or not, with the reason when it was not. Queued is never read, acted on or reported on, and no part of the plugin infers any of those from it. A message the receiver refused before its mod saw it appears only as that sent entry.

no example exercises it

rule.receiveOutcome line 47 · specs/coordination/record.sdp.md:47

A received entry holds what the receive hook's downstream did with the message, which is queued, consumed, rejected or unknown. Queued means neither read nor acted on. A receive event alone does not show the message reached Claude.

no example exercises it

rule.transportIsNotReport line 48 · specs/coordination/record.sdp.md:48

A transport result is not a lead's substantive report, and the guidance says so. Acknowledgements stay out of the transport.

no example exercises it

rule.startEntry line 49 · specs/coordination/record.sdp.md:49

A session writes a start entry when its mod loads. Coverage of that session begins there, and a session with no start entry says nothing about what it sent or received.

no example exercises it

rule.oneWriter line 50 · specs/coordination/record.sdp.md:50

Every file has one writer and is written once. A session writes only inside its own folder, one file for each entry, and never rewrites or appends, because a write is not atomic. A reader skips a file it cannot parse, reads it again later, and treats one that never parses, such as a write cut short when the process was killed, as unknown evidence.

no example exercises it

rule.recordingMayFail line 51 · specs/coordination/record.sdp.md:51

A failure to write an entry never stops, delays or alters the message. The plugin says in the session that recording is degraded, and a message with no entry, a sent message whose write failed included, is unknown to the record.

no example exercises it

rule.storeHoldsNothing line 52 · specs/coordination/record.sdp.md:52

The mod's key-value store holds none of the record.

no example exercises it

rule.byDirectory line 53 · specs/coordination/record.sdp.md:53

Each entry names the working directory of the session that wrote it, so a reader assigns the entry to a project as it assigns the session itself.

no example exercises it

rule.staysLocal line 54 · specs/coordination/record.sdp.md:54

The record stays on the machine where the session ran, and the plugin sends it nowhere.

no example exercises it

rule.neverPruned line 55 · specs/coordination/record.sdp.md:55

The plugin never deletes, edits or compacts the record. Keeping it is the person's.

no example exercises it

rule.metadataOnly line 56 · specs/coordination/record.sdp.md:56

With recordText set to metadata, every field is kept except the text, which is replaced by its length and a hash.

no example exercises it

rule.outsideRoute line 57 · specs/coordination/record.sdp.md:57

A message that crosses by a route outside the host's own messaging is not seen by the mod and is not recorded.

no example exercises it

0 unkeyed rules.

entryFile line 61 · specs/coordination/record.sdp.md:61

<recordDir>/<session id>/<UTC time to the millisecond, without colons>-<sequence>.json, one JSON object for each file.

no citation recorded

entryKinds line 62 · specs/coordination/record.sdp.md:62

start, chain and message, named by the field kind.

no citation recorded

startEntry line 63 · specs/coordination/record.sdp.md:63

{ kind, sessionId, at, cwd, host, version, inbound }, where inbound is the value of the host's inbound setting as read.

no citation recorded

messageEntry line 64 · specs/coordination/record.sdp.md:64

{ kind, sessionId, at, side, peer, envelope, text, isQueued, reason, outcome, cwd }, where side is sent or received, peer is { as, sessionId? } with as the address or name exactly as the host gave it, isQueued and reason appear only on a sent entry, and envelope and outcome only on a received one.

no citation recorded

chainEntry line 65 · specs/coordination/record.sdp.md:65

{ kind, sessionId, at, parent, part, brief, cwd }, written by the chain specification's join.

no citation recorded

timeFormat line 66 · specs/coordination/record.sdp.md:66

at is UTC to the millisecond, in ISO 8601.

no citation recorded

ids line 67 · specs/coordination/record.sdp.md:67

a session's own id is the full id. A peer's address or name is kept as given, a shortened id is never an address, and a full peer id appears only when resolved.

criteria

• Run two sessions that accept inbound messages and send one message each way. Each session's folder holds a start entry and a message entry, and the text matches the original byte for byte.
• Send to a session that refuses inbound messages. The sender's entry holds isQueued false and a reason, and the receiver's folder holds no message entry.
• Send to a session that holds messages and to one that accepts. Each sender's entry holds the result the host returned, and the receiver's entry holds the outcome the host gave, rejected where the receive hook was refused.
• Have two peers send identical text to one session, then an ordinary agent message, then resume a session. Each received entry names its peer as given or as unknown, and none is attributed beyond its evidence.
• Kill a session while it writes an entry, and make the record folder unwritable. The message still arrives, the session says recording is degraded, and /chain and a reader treat the damaged or missing entry as unknown.
• Read a session's folder while it writes. A file that cannot be parsed is skipped and parses on a later read.
• Set recordText to metadata and send a message. The entry holds the length and hash and no text.

mode

manual

Verifier bindings

No verifier binding recorded.

Requirement drawing

• Declared verifying examples: no declared verifying example.
• Satisfying or referencing units: no recorded binding.
• Test or oracle bindings: no recorded binding.

Decisions

No decision record named.

No implementation neighborhood recorded.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.