None.

None.

actor

A person, or a session working for one, who needs to know what was asked across a project's sessions and what became of it.

problem

Directions are lost between sessions, and a transcript mixes the person's words with launcher prompts, peers' messages, tool output and summaries, so reading one naively attributes other sessions' words to the person.

outcome

Every message of the person in the sessions scanned is found verbatim, told apart from what only looks like it, and traced to what was done with it.

value

Nobody has to ask the person again, and failures that lost context are named with their cause.

assumptions

• The transcripts of Claude Code and Codex stay readable on disk in their current forms.

Open questions

• non-blocking · question.language line 25 · specs/coordination/session-scanning.sdp.md:25 · Should the scan's scripts stay in Python or move to the plugin's Node?Decider: delegatedProvisional: They stay in Python, on the standard library alone, because their tests exist and a port should change as little as it can. The plugin's own runtime stays Node.

rule.personsWords line 31 · specs/coordination/session-scanning.sdp.md:31

A scan takes the person's words from the transcripts, and marks each as the person's, a launcher's, a peer's or a notice.

no example exercises it

rule.everyDirectionTraced line 32 · specs/coordination/session-scanning.sdp.md:32

Each direction is traced to its outcome, or stated as open.

no example exercises it

rule.namedFilter line 33 · specs/coordination/session-scanning.sdp.md:33

A scan's prompt names the context it filters out, so that it reads pure context from the repositories and not orchestration noise that sessions repeat.

no example exercises it

rule.readOnly line 34 · specs/coordination/session-scanning.sdp.md:34

A scan reads transcripts directly and never resumes a session.

no example exercises it

rule.callerPlacesResult line 35 · specs/coordination/session-scanning.sdp.md:35

A scan writes plain files in a folder its caller names, and holds no assumption about where a project keeps its records.

no example exercises it

rule.completeOrLabelled line 36 · specs/coordination/session-scanning.sdp.md:36

A scan accounts for the sources it selected and the entries it extracted, keeps unresolved attribution and exclusions visible, and labels its result incomplete until its checks pass.

no example exercises it

rule.measuredDeployment line 37 · specs/coordination/session-scanning.sdp.md:37

A new version of the tooling is measured on a frozen sample against the last one before it is used, naming both revisions and the sample's hashes, and it is used only with no loss or a loss a person explicitly accepted.

no example exercises it

0 unkeyed rules.

criteria

• Run the scan's existing tests after the port. They all pass, and no test was removed.
• With the source of the port unavailable, run extraction and the record's checks from the delivered plugin. Both complete, and every path resolves inside the plugin.
• Leave one attribution unresolved. The final check refuses the result, and the scan stays labelled incomplete.
• Scan a sample holding a launcher's prompt, a peer's message and a compaction summary. None of them is attributed to the person.

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.

actor

The person or the tool that deploys the plugin, and a project whose sessions will coordinate.

problem

Coordination is wanted before the job runner has earned trust, and a session whose host setting holds or refuses inbound messages gives its sender no sign of it.

outcome

A person switches coordination on without the job runner, learns at once which of its sessions hold or refuse inbound messages, and a project adds only what is its own.

value

The first part of coordination can be deployed everywhere without moving any job off the runner it trusts today.

rule.twoPlugins line 24 · specs/coordination/adoption.sdp.md:24

Coordination and the job runner are two plugins of one marketplace, each enabled on its own, and enabling a plugin is the only switch.

no example exercises it

rule.runnerStaysOff line 25 · specs/coordination/adoption.sdp.md:25

With only the coordination plugin enabled, nothing of the job runner loads: no agent type, no agent definition and no sidecar.

no example exercises it

rule.coordinationOffIsInert line 26 · specs/coordination/adoption.sdp.md:26

With the coordination plugin disabled, nothing of it runs: no record, no command, no tool, and nothing drawn.

no example exercises it

rule.modOnly line 27 · specs/coordination/adoption.sdp.md:27

Coordination runs wholly in the mod and starts no process of its own.

no example exercises it

rule.readsInbound line 28 · specs/coordination/adoption.sdp.md:28

At session start the plugin reads the session's inbound setting, which is accept, hold, refuse or unset. It never changes the setting, which belongs to whoever deploys the session, and once the record exists it stores what it read in the session's start entry. This part needs no record.

no example exercises it

rule.saysTheState line 29 · specs/coordination/adoption.sdp.md:29

The plugin tells the person in that session at once, with one notice at start, which of the four states holds: accept needs no notice; hold means messages wait until released; refuse means they are refused; unset means the host's default applies and delivery depends on the permission modes of the two sessions. It says a message is dropped only where the host's behaviour establishes that.

no example exercises it

rule.stateIsDated line 30 · specs/coordination/adoption.sdp.md:30

The setting can change while the session runs, so wherever the plugin shows the state it says it is the value read at start, or reads the setting again when it draws.

no example exercises it

rule.projectAddsBoundaries line 31 · specs/coordination/adoption.sdp.md:31

A project takes coordination up by having the coordination plugin enabled, inbound messages accepted, and its own agent instructions naming which of its work justifies a lead. It keeps no copy of the record format, the chain or the guidance.

no example exercises it

rule.userScope line 32 · specs/coordination/adoption.sdp.md:32

Enabling the plugin and the record's folder are settings of the person, and a project cannot change them.

no example exercises it

0 unkeyed rules.

plugin line 36 · specs/coordination/adoption.sdp.md:36

coordination, a second plugin of the cc-agents marketplace, installed and enabled as coordination@cc-agents.

no citation recorded

recordDir line 37 · specs/coordination/adoption.sdp.md:37

recordDir, a plugin setting naming the record's folder. Its default is one folder for each operating-system user, shared by every profile of that user, because a chain can cross profiles.

no citation recorded

recordText line 38 · specs/coordination/adoption.sdp.md:38

recordText, a plugin setting with the values full and metadata, which the record specification gives meaning to.

no citation recorded

inboundSetting line 39 · specs/coordination/adoption.sdp.md:39

the host's crossSessionInbound, read through the mod's settings access and never written.

criteria

• Enable only the coordination plugin, then list the agent types and the running processes. No foreign agent type is registered and no sidecar runs.
• Enable only the job runner plugin and start a session. No record folder is created and no coordination command is listed.
• Start a session once with each of the four inbound states: accept, hold, refuse and unset. The notice at start names the state as the host defines it, says nothing for accept, and never says messages are dropped for hold or unset. Change the setting during the session and confirm the plugin either shows the new value or labels the old one as read at start. Where the record exists, its start entry holds the value that was read.
• With only the coordination plugin enabled, spawn each agent type once through the Agent tool and once as a Workflow role, and run a Relay job in the same Workflow. No foreign lane starts, no shipped agent definition is offered, and the Relay job runs.

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.

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.

actor

A lead, the session that started it, and the person watching both.

problem

A session started across a boundary does not know whom to report to, its starter does not know what it left running, and a later reader cannot tell either.

outcome

A lead declares its parent and its part in one call, its parent hears of it, and either side can read the whole chain from the record.

value

Whoever starts a session across a boundary can see that it exists and can tell whether it has gone quiet, and a lead always knows where its result goes.

rule.leadJoins line 28 · specs/coordination/chain.sdp.md:28

A lead declares itself by calling the join tool with its parent's full session id, a one-line part and, if there is one, where its brief is. This is its first act, and its brief says so.

no example exercises it

rule.joinTellsParent line 29 · specs/coordination/chain.sdp.md:29

Joining sends the parent one short message that names the lead's session id and part, and the tool result says whether it was delivered. When it was not, the lead says so in its first words to the person.

no example exercises it

rule.rolesFollowParents line 30 · specs/coordination/chain.sdp.md:30

A session with no declared parent is a top and a session with one is a lead. No other role exists and no role word is written.

no example exercises it

rule.treeFromEntries line 31 · specs/coordination/chain.sdp.md:31

The chain is read from the chain entries of the record. A session named as a parent that never declared, and whose records are on this machine, is shown as a top with no part.

no example exercises it

rule.laterJoinReplaces line 32 · specs/coordination/chain.sdp.md:32

A second join by the same session replaces the first for display, and the record keeps both.

no example exercises it

rule.reportsArePlainMessages line 33 · specs/coordination/chain.sdp.md:33

A lead reports to its parent with ordinary messages to its session id. The plugin adds no report format and no acknowledgement.

no example exercises it

rule.agentsAreNotMembers line 34 · specs/coordination/chain.sdp.md:34

An agent or a Workflow role never joins a chain and never appears in it: the join tool refuses a call made from an agent or a Workflow role context.

no example exercises it

rule.joinRefusals line 35 · specs/coordination/chain.sdp.md:35

The join tool also refuses a session that names itself as its parent. The tree is read so that it terminates when the records hold a cycle, and it flags each cycle it finds rather than drawing it.

no example exercises it

rule.localRecordsOnly line 36 · specs/coordination/chain.sdp.md:36

The tree is built from the records available on this machine. A parent whose entries are not here, such as one on another operating system, is shown as an unresolved boundary with its session id, never as a session with no part.

no example exercises it

rule.depthIsShown line 37 · specs/coordination/chain.sdp.md:37

A lead whose parent is itself a lead is recorded and shown with a notice that the chain has grown a level, and nothing refuses it.

no example exercises it

rule.lastHeardNotAlive line 38 · specs/coordination/chain.sdp.md:38

The tree states when each session was last heard, from its latest entry, and never states that a session is alive or dead, because the plugin does not poll.

no example exercises it

rule.guidanceShips line 39 · specs/coordination/chain.sdp.md:39

The plugin carries the guidance a session needs: when to start a lead, what a brief holds, how to join and report. A project adds only its own boundaries.

no example exercises it

0 unkeyed rules.

toolJoin line 43 · specs/coordination/chain.sdp.md:43

chain_join, with input { parent: string, part: string, brief?: string }, seen by Claude as mcp__coordination__chain_join.

no citation recorded

toolTree line 44 · specs/coordination/chain.sdp.md:44

chain_tree, with no input, seen as mcp__coordination__chain_tree; it returns the chain of the calling session as text, each session with its full id, parent, part and last heard.

no citation recorded

briefHolds line 45 · specs/coordination/chain.sdp.md:45

a brief states the root intent in the person's words, the goal of each session between the person and the lead, the rulings that bind the work, the lead's part, how it will know it is done, and the session that receives its result.

criteria

• Start a lead whose brief names the parent's session id. After its join, the parent's chain_tree lists the lead with its part, and the parent's folder holds the join message.
• Join with a parent id that no session holds. The tool result says not delivered, and the chain still shows the lead.
• Start an agent inside the lead. It never appears in the chain.
• Join a third session under the lead. The chain shows it with the notice about depth.
• Call the join tool from an agent inside a lead, and join a session under itself. Both are refused and the chain does not change.
• Join A under B and B under A. /chain terminates and flags the cycle.
• Join a lead under a parent whose records are on another machine. The tree shows the parent as an unresolved boundary.

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

• spec:cc-agents.coordination.boundary-only

  A second session is started only for one of three boundaries: another operating system, another repository or permission profile, or a part large or long enough to need a context of its own. The sessions started for one piece of work form a chain, in which the top has no parent and every other session is a lead with exactly one parent. A chain has no roles beyond top and lead. Inside a chain a message is a brief down, a report up or a correction down. A message between two sessions of no common chain is allowed, rare and recorded, and it gives neither side a role.

No implementation neighborhood recorded.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

actor

The person watching one session that belongs to a chain.

problem

Coordination is invisible: a lead goes quiet, a message is held or refused, and the person learns it only by asking Claude.

outcome

The person sees where the session stands in its chain, is told when a message arrives or cannot, and can print the chain on demand.

value

A quiet lead, or a session that cannot receive, is noticed by the person within a glance and without spending a turn.

Open questions

• non-blocking · question.pane line 27 · specs/coordination/view.sdp.md:27 · Does the chain need a pane beside the chat?Decider: delegatedProvisional: No. The status line and the command are enough for a chain of a top and a few leads, and the existing pane stays about agents.

rule.noModelTurn line 33 · specs/coordination/view.sdp.md:33

Every view is drawn by the mod and costs no model turn.

no example exercises it

rule.quietUnlessUseful line 34 · specs/coordination/view.sdp.md:34

The status line shows only what is true now and useful: the session's place in its chain, or the inbound state when it is hold or refuse, labelled as read at start unless it is read again when drawn. It is empty otherwise.

no example exercises it

rule.arrivalToast line 35 · specs/coordination/view.sdp.md:35

A message from another session raises a toast naming its part or short id where the record establishes one, otherwise the peer as the host gave it, or unknown peer, and it never shows its text.

no example exercises it

rule.chainCommand line 36 · specs/coordination/view.sdp.md:36

The chain command prints the chain of this session as a tree: each session's full id, whether it is top or lead, its part, when it was last heard, and whether a lead has sent its parent a message since it joined, not counting the notice that joining sends: yes, no, or unknown where the record cannot resolve the peer. The mark says only that a message was sent, never that the lead reported or finished.

no example exercises it

rule.readOnly line 37 · specs/coordination/view.sdp.md:37

No view changes the chain or the record.

no example exercises it

0 unkeyed rules.

criteria

• With the inbound setting at hold and then at refuse, the status line carries that state from the first prompt, and with it unset or accept it carries none.
• A lead sends its parent a message, and the parent shows the toast without the text and /chain shows the lead's last heard time. Before that message, /chain shows the lead as having sent nothing although its join notice reached the parent.
• Run /chain and compare usage before and after. No model turn was used.

mode

manual

statusLine line 41 · specs/coordination/view.sdp.md:41

one line under the prompt, for example lead of <short id>: <part>, top: 2 leads, or inbound: hold (as read at start).

arrivalToast line 42 · specs/coordination/view.sdp.md:42

message from <part or short id>, without text.

commandChain line 43 · specs/coordination/view.sdp.md:43

/chain, listed with the description Show this session's chain, which prints the tree without starting a turn.

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.