@cordfuse/crosstalk 5.0.0-alpha.7 → 6.0.0-alpha.2

package/template/README.md

@@ -1,22 +0,0 @@
-# Transport template
-
-This directory is the scaffold for a Crosstalk transport — the markdown + folder structure that becomes an operator's transport when they run:
-
-```sh
-crosstalk init my-transport
-```
-
-## What's here
-
-- `upstream/` — runtime-managed. Protocol spec (`CROSSTALK.md`, `PROTOCOL.md`, `OPERATOR.md`, `JITTER.md`), version pin (`CROSSTALK-VERSION`), default actor profiles (`actors/`). **Operators don't edit these.** The runtime can re-sync them when a new spec version ships.
-- `local/` — operator-owned. Custom actor profiles (`actors/`), local identity config (`CROSSTALK.md`). Operators edit these freely.
-- `hosts/` — host files declaring which actors run where, per-actor tier configurations.
-- Agent entry pointer files at root (`CLAUDE.md`, `AGENTS.md`, `GEMINI.md`, etc.) — these direct agents to the right files when their CLI starts up in the transport directory.
-
-## How a transport is born
-
-`crosstalk init` copies this entire `transport/` tree to the operator's chosen directory, then initializes it as a git repo. From that moment on, the operator's transport is independent — they own it, customize `local/`, declare hosts in `hosts/`, and dispatch runs against it.
-
-## Spec reference
-
-The canonical protocol specification lives in `upstream/CROSSTALK.md`. The version pin lives in `upstream/CROSSTALK-VERSION`.

package/template/local/CROSSTALK.md

@@ -1,4 +0,0 @@
----
-name: CONFIGURE
-email: CONFIGURE
----

package/template/upstream/CROSSTALK-VERSION

@@ -1 +0,0 @@
-5.0

package/template/upstream/CROSSTALK.md

@@ -1,589 +0,0 @@
-# Crosstalk
-
-Version: 5.0
-
-Crosstalk is a shared file format over git that lets humans and AI agents communicate
-asynchronously. The git repository is the message bus. No special software is required
-to participate beyond git itself.
-
----
-
-## Participants
-
-A Crosstalk transport has two kinds of participants:
-
-**Humans** — operators and users who post messages directly or via a chat session with an agent. They read replies in the channel and drive the conversation.
-
-**Machines** — agents (Claude, Codex, agy, etc.) that process messages and reply autonomously. A machine participant is invoked on a schedule or by a human and acts on any unread messages addressed to it.
-
-### The worker pattern
-
-The most common setup is a **worker** — a machine participant that serves both humans and machines. `to: concierge` means "I need something done." The worker receives the request, acts on it, and replies. The sender may be human or machine; the worker does not distinguish.
-
-Any participant name can fill this role. The operator defines what the worker actually does via its system prompt — Crosstalk only handles the message routing.
-
----
-
-## Transport layout
-
-```
-<transport>/
-  upstream/
-    CROSSTALK.md
-    CROSSTALK-VERSION
-    PROTOCOL.md
-    OPERATOR.md
-    actors/
-      <name>.md
-  local/
-    CROSSTALK.md
-    actors/
-      <name>.md
-  hosts/
-    <alias>.md
-  data/
-    channels/
-      <guid>/
-        YYYY/
-          MM/
-            DD/
-              HHMMSSsssZ-<hex>.md
-    memories/
-      <YYYYMMDDTHHMMSSsssZ-hex>.md
-```
-
-- `upstream/CROSSTALK.md` — this file. The protocol specification. Upstream-owned; operators never modify it.
-- `upstream/CROSSTALK-VERSION` — plain text file declaring the protocol version. Hard boundary: must be `5.0`. Tracks the protocol generation (`major.minor`); patch-level release tags do not bump it.
-- `local/CROSSTALK.md` — operator config. Declares `name` and `email` for this agent. Operator-owned; upstream never modifies it.
-- `local/actors/` — one markdown file per participant. Defines name, skills, and behavioral description.
-- `hosts/` — one markdown file per host (machine running the runtime). Declares the host's identity and the actors it can service. Operator-owned; each host owner creates and maintains their own file. See Host files.
-- `data/channels/` — one subdirectory per channel, identified by a UUID v4. Discovered by listing the directory at runtime; no configuration needed. To create a channel, create the directory and commit — any participant may do this.
-- `data/channels/<guid>/CHANNEL.md` — optional channel metadata file. Declares name, description, and parent channel for subchannels.
-- `data/memories/` — shared memory files, readable and writable by any participant.
-
----
-
-## Channels
-
-Each channel is a UUID v4 directory under `data/channels/`. Any participant may create a channel by creating the directory and committing.
-
-### CHANNEL.md
-
-An optional `CHANNEL.md` at `data/channels/<guid>/CHANNEL.md` declares human-readable metadata for the channel. Agents load it on entry to understand the channel's purpose and context.
-
-```
----
-name: dogfood-sprint
-created_by: steve
-created_at: 2026-05-24T17:00:00.000Z
----
-
-Main channel for the Crosstalk v2 dogfood sprint. Covers spec reviews,
-Monte Carlo pi experiments, and multi-agent protocol testing.
-
-Participants: steve, concierge, architect, qa, security, scrum-master.
-```
-
-#### CHANNEL.md frontmatter fields
-
-| Field | Required | Notes |
-|---|---|---|
-| `name` | yes | human-readable label; unique within the transport |
-| `created_by` | no | actor name who created the channel |
-| `created_at` | no | ISO 8601 UTC |
-| `parent` | no | GUID of the parent channel — see Subchannels |
-
-The body is free-form markdown — purpose, participants, behavioral notes. It serves as a mini system prompt scoped to the channel. Agents that do not load `CHANNEL.md` are unaffected.
-
-### Subchannels
-
-A subchannel is a channel spawned from a parent channel to work on a focused problem. It is a normal channel with a `parent:` field in its `CHANNEL.md` declaring the parent's GUID.
-
-```
----
-name: pi-estimation
-parent: adfe0356-0f71-49a9-80a0-fb76883cd974
-created_by: concierge
-created_at: 2026-05-24T17:00:00.000Z
----
-
-Subchannel for the Monte Carlo pi estimation fan-out. Four engineers
-each throw 1B darts and post results here.
-```
-
-The parent channel can interrupt or feed new data into the subchannel at any time by posting a message there addressed to the relevant agents. Agents scan all channels they participate in — they will pick up the interrupt on their next session open regardless of which channel they are focused on.
-
-The subchannel reports completion by posting back to the parent channel. There is no protocol-level close signal — the subchannel simply goes quiet when the work is done.
-
----
-
-## Actors
-
-Each participant in the transport has an actor file in `local/actors/<name>.md`. The filename
-matches the participant's `name`. Actor files are readable by any participant — agents
-load them to understand who else is in the transport and what they do.
-
-### Actor file format
-
-```
----
-name: precise-generalist
-description: "Precise, curious, direct — the reliable general-purpose voice."
-metadata:
-  author: cordfuse
-  domain: general
-  type: actor
-  alias: Apex
----
-
-## Title
-Precise, curious, direct. Thinks clearly, speaks plainly.
-
-## System Prompt
-You are Apex. Precise, curious, direct. You think clearly and speak plainly.
-```
-
-### Actor frontmatter fields
-
-| Field | Required | Values | Notes |
-|---|---|---|---|
-| `name` | yes | slug | must match the filename stem |
-| `description` | yes | short string | one-line summary; used by peer agents and operator tooling |
-| `metadata.author` | no | string | who maintains this actor |
-| `metadata.domain` | no | string | e.g. `general`, `engineering`, `health` |
-| `metadata.type` | no | `actor` | always `actor` for participant files |
-| `metadata.alias` | no | string | human-readable name the actor introduces itself by |
-
-The body is free-form markdown. It serves as the actor's system prompt — behavioral
-context loaded by the runtime when dispatching to this participant.
-
-### Default actor
-
-`upstream/actors/precise-generalist.md` ships with every Crosstalk transport.
-It is the default participant when no custom actor is configured. Operators override it
-by placing a file with the same `name:` in `local/actors/`.
-
-### Managing actors
-
-Actors are created, modified, or removed by editing files in `local/actors/` and committing.
-The worker handles actor management on behalf of the operator via natural language in any channel.
-
-If `local/actors/` is absent or empty, agents proceed normally — actor discovery yields no peers.
-
-On session open, scan actor files for duplicate `name` values. If a collision is found, halt and notify the operator.
-
-### Importing actors from agent-assets
-
-The worker recognises three natural language intents for importing actors from `cordfuse/agent-assets`:
-
-**Browse**
-
-Triggers: "browse actors" | "what actors are available?" | "show me who I can add" | "who do you have?" | "show me [domain] actors" | "any [domain] options?" | "I need someone who [does/knows X]"
-
-Worker:
-1. Fetches `https://raw.githubusercontent.com/cordfuse/agent-assets/main/README.md`
-2. Presents the full roster grouped by domain — name, alias, one-line description
-3. If a domain or trait was given, filters to matching actors only
-4. Prompts: *"Which would you like to add? Name one or more — or say 'all'."*
-5. Proceeds to the add flow for each selected actor
-
-**Add**
-
-Triggers: "add [name]" | "add a [role]" | "bring in [name]" | "I want [name/role]" | "add [name] from mtx"
-
-Worker:
-1. If a name was given directly, fetches `https://raw.githubusercontent.com/cordfuse/agent-assets/main/actors/{name}.md`
-2. If a role or description was given, matches against the README roster and confirms with the operator before fetching: *"Closest match: [Name] — [description]. Add them? (yes / browse more)"*
-3. Writes to `local/actors/{name}.md`
-4. Commits: `actors: add {name} from agent-assets`
-5. Confirms: *"[Name] added. They're now available as a participant."*
-
-On name collision with an existing file: *"You already have [name] — overwrite? (yes / skip)"*
-If not found: *"No actor named [name] in agent-assets. Say 'browse actors' to see the full roster."*
-
-**Sync**
-
-Triggers: "sync actors" | "update actors" | "are my actors up to date?" | "refresh actors from mtx"
-
-Worker:
-1. Scans `local/actors/` for files whose frontmatter has `author: cordfuse`
-2. For each, fetches the latest from `https://raw.githubusercontent.com/cordfuse/agent-assets/main/actors/{name}.md`
-3. Overwrites only cordfuse-authored files — never touches operator-created actors
-4. Commits all updates in a single commit: `actors: sync from agent-assets`
-5. Reports: *"Updated N actors from agent-assets: [list]."* If nothing changed: *"All actors are current."*
-
----
-
-## Host files
-
-A host file at `hosts/<alias>.md` declares a machine that runs the Crosstalk runtime and the actors it can service. Host files are operator-owned — each operator creates and maintains their own. They are committed to the transport so all participants can discover what hosts and capabilities exist.
-
-### Host file format
-
-```
----
-alias: cachy
-hostname: steve-cachyos
-actors:
-  junior-developer:
-    haiku:
-      cli: claude --model claude-haiku-4-5 --print --dangerously-skip-permissions
-      count: 5
-    flash: gemini --model gemini-2.5-flash -p --yolo
-  senior-developer:
-    opus: claude --model claude-opus-4-7 --print --dangerously-skip-permissions
----
-```
-
-### Host frontmatter fields
-
-| Field | Required | Notes |
-|---|---|---|
-| `alias` | yes | human-readable identity; used in `actor@host` addressing; operator-chosen, free-form |
-| `hostname` | no | OS hostname (`os.hostname()`); used for auto-detection |
-| `username` | no | OS username (`os.userInfo().username`); used for multi-user host auto-detection |
-| `actors` | yes | map of actor names to tier declarations |
-
-### Tier declarations
-
-Each actor entry maps tier names to CLI commands. A tier is a named model/provider slot:
-
-```yaml
-actors:
-  junior-developer:
-    haiku:                                          # tier name — operator-defined label
-      cli: claude --model claude-haiku-4-5 --print --dangerously-skip-permissions
-      count: 5                                      # parallel workers; default: 1
-    flash: gemini --model gemini-2.5-flash -p --yolo  # shorthand — count defaults to 1
-```
-
-- Tier names are operator-defined strings (`haiku`, `flash`, `opus`, etc.). The concierge uses them for routing decisions.
-- The `cli:` string is the shell command the runtime uses to invoke the agent.
-- `count:` sets the number of parallel workers for this tier. Omit or set to `1` for a single worker. The shorthand (bare string) is equivalent to `count: 1`.
-- Multiple tiers of the same actor on the same host form a single instance group for dispatch purposes. The total group size is the sum of all tier counts for that actor.
-
-### Actor@host addressing
-
-Messages may target a specific host by appending `@<alias>` to the actor name:
-
-```yaml
-to: junior-developer@cachy    # only cachy's runtime dispatches
-to: senior-developer@mac      # only mac's runtime dispatches
-to: concierge                 # all hosts with a concierge actor dispatch (bare name = broadcast)
-```
-
-Bare actor names are backward-compatible — any host with that actor services the message, subject to the instance group selection rule.
-
-### Host routing table
-
-On session open, the concierge reads `hosts/` to build a routing table: which actors are available, on which hosts, at which tiers. This allows the concierge to make informed routing decisions before sending messages.
-
-### Startup behavior
-
-On runtime startup, the runtime scans `hosts/` to find its own host file. Auto-detection precedence:
-
-1. **Explicit override:** if `host:` is set in the local config, find the file where `alias:` matches exactly.
-2. **Username + hostname:** if `username:` and `hostname:` both match the machine's `os.userInfo().username` and `os.hostname()`. Use this for multi-user hosts where multiple operators share a machine.
-3. **Bare hostname:** if only `hostname:` matches. Backward-compatible fallback for single-user machines.
-4. **No match:** log clearly, idle without dispatching, and do not crash. The log message must include the identity attempted and the path scanned so the operator can diagnose the mismatch.
-
-A user can always override their alias by setting `host: <alias>` in their local config — this bypasses all auto-detection.
-
-**Tier validation:** if a message is addressed `to: actor@host` and this runtime is the target host but has no matching actor declared, log a warning and skip. Do not crash.
-
-### Host file ownership
-
-Each operator commits only their own host file. The protocol does not enforce this — it is a convention. Trust at the repository level: any participant with write access can modify any host file. Operators who need stronger guarantees must secure the repository itself.
-
----
-
-## Your identity
-
-Your `name` and `email` are declared in `local/CROSSTALK.md`, which uses this format:
-
-```
----
-name: concierge
-email: concierge@crosstalk.local
----
-```
-
-Set the matching git identity once by running these commands inside the transport repo:
-
-```
-git config user.name "concierge"
-git config user.email "concierge@crosstalk.local"
-```
-
-Do not use `--global` — this must be repo-local so it does not overwrite the
-operator's own git identity. Names are free-form: `alice`, `concierge`, `ops-bot`.
-No taxonomy, no hierarchy. Names need not be unique — see Instance groups.
-
-### Instance groups
-
-A name may be shared by multiple participants. They form an **instance group**: addressable by the shared name, but only one instance dispatches per message.
-
-When a message is addressed to a shared name, every instance reads it. To avoid duplicate dispatch, each instance independently applies the same deterministic selection rule:
-
-```
-index  = sha256(message-relPath) read as 32-bit big-endian unsigned, mod group-size
-chosen = instance at position `index` (0-based, in the group's local ordering)
-```
-
-The instance whose own position equals `index` dispatches; the rest skip and advance their cursor. Only the chosen instance posts a reply and receipt.
-
-**The selection function is normative** — all runtimes must use this exact computation so that instances reach the same decision without coordination.
-
-**Local ordering is runtime-defined.** Single-operator scope: the runtime orders instances by config position (or any other stable local ordering) and is consistent within its own process. Multi-operator scope (instances spread across operators sharing one transport): not yet specified — runtimes that span multiple operators may double-dispatch until a roster-discovery mechanism is added.
-
-Single-instance semantics are recovered by giving each participant a unique name. Operators who don't want instance groups simply don't share names.
-
-### Identity model
-
-`from:` identifies the logical actor. The git commit author identifies the session
-that wrote the file.
-
-`from:` and the git commit author are both unverified strings. Identity is not enforced at the protocol level — the trust boundary is repo access. Operators who need verified identity must secure the repository itself.
-
-### Sub-agents
-
-A worker session may invoke other actors as sub-agents internally and commit
-their responses on their behalf. In this case:
-
-- `from:` is set to the logical actor (e.g. `architect`)
-- `via:` is set to the committing session (e.g. `concierge`)
-- The git commit author is the worker's git identity
-
-This allows a single scheduled job to drive all actor activity. The operator configures
-only the worker's git identity. Sub-agents are invoked inside the worker's session — no separate git identity or scheduler required per actor.
-
-Sub-agents do not require actor files. An `actors/<name>.md` may exist to document the sub-agent, but it is not required for the pattern to work.
-
-```
----
-from: architect
-via: concierge
-to: steve
-type: text
-timestamp: 2026-05-24T14:00:00.000Z
----
-
-Sub-agent response here.
-```
-
-### Peer agents
-
-Each participant runs as its own independent process with its own git clone, git identity, and scheduler. No `via:` field — every message is committed directly by the actor that wrote it. Push conflicts are resolved by exponential backoff (see On session open, step 6).
-
-**Sub-agents vs peer agents:**
-
-| | Sub-agents | Peer agents |
-|---|---|---|
-| Parallelism | Yes — worker fans out concurrently | Yes — independent processes |
-| Model diversity | Yes — worker picks model per invocation | Yes — set at deployment per process |
-| Git authorship | Single committer (the worker) | One committer per actor |
-| Failure isolation | Worker is a single point of failure | Agents fail independently |
-| Deployment | One scheduler, one clone | One scheduler and clone per agent |
-| Push conflicts | None — single writer | Possible — resolved by backoff |
-
-Use sub-agents when a single scheduled job should drive all actor activity and git authorship per actor is not required. Use peer agents when agents are deployed across different machines or providers, or when independent failure domains and per-actor git authorship matter.
-
----
-
-## Message format
-
-Every message is a markdown file with YAML frontmatter:
-
-```
----
-from: alice
-to: concierge
-type: text
-timestamp: 2026-05-23T19:00:00.000Z
----
-
-Message body here.
-```
-
-Read message files directly with your agent's native file-reading capability — the format is plain markdown with YAML frontmatter, intended to be inspected as text. No parser, interpreter, or shelling out for `cat`/`sed`/`awk` is required.
-
-### Frontmatter fields
-
-| Field | Required | Values | Notes |
-|---|---|---|---|
-| `from` | yes | free-form name | logical actor identity — see Identity model |
-| `to` | yes | name, list of names, or `all` | `all` targets every participant |
-| `type` | yes | `text`, `read` | see Message types |
-| `timestamp` | yes | ISO 8601 UTC | |
-| `ref` | conditional | relPath of original message | required when `type: read`; path relative to `data/channels/<guid>/` |
-| `via` | no | free-form name | session that committed on behalf of `from` — see Sub-agents |
-
-Operators may add fields — readers must ignore unknown fields.
-
-### To field
-
-- Single recipient: `to: concierge`
-- Multiple recipients: `to: [concierge, ops-bot]`
-- Broadcast: `to: all`
-- Host-targeted: `to: junior-developer@cachy` — only the named host dispatches; see Host files
-- Senders do not receive their own messages. Self-exclusion applies at scan time — agents skip any message where `from:` matches their own name.
-- A name may be shared by multiple participants — see Instance groups.
-
-### Message types
-
-**`type: text`** — a normal message. Body is the message content.
-
-**`type: read`** — a read receipt. The `ref` field contains the relPath of the
-acknowledged message. Body is empty or omitted.
-
-```
----
-from: concierge
-to: alice
-type: read
-timestamp: 2026-05-23T19:02:00.000Z
-ref: 2026/05/23/190100000Z-b2c3d4e5.md
----
-```
-
-Read receipts are optional. Senders cannot require them. Address the receipt to the
-original sender (`from:` of the original message) regardless of whether the original
-was targeted, listed, or broadcast. Never address a receipt to `all`.
-
-Each addressed recipient in a list-targeted message sends its own independent receipt to the original sender.
-
-Never post a receipt for a `type: read` message.
-
-A receipt with a `ref:` pointing to a nonexistent message path is treated as malformed — skip silently.
-
----
-
-## Privacy and trust model
-
-`to` is a routing hint, not an access control boundary. Every message is visible to anyone with repo access. There are no whisper or ephemeral message types.
-
-`from:` is an unverified declaration — the protocol does not enforce identity. The trust boundary is repo access: anyone who can push to the repository can write any `from:` value. Operators who require confidentiality or verified identity must secure the repository itself.
-
----
-
-## Append-only log
-
-The transport is an immutable, append-only log. There is no `type: retract` or channel-close message. Deletion is out of scope — operators who need retention limits must manage that at the git or storage layer.
-
----
-
-## Sessions
-
-At startup, generate a random GUID. This is your session ID for this invocation.
-Use it when writing memory files. Sessions are self-issued — no registry, no daemon.
-
----
-
-## Memories
-
-Memory files are shared, persistent knowledge any participant can read and write.
-
-### Memory file format
-
-Filename: `YYYYMMDDTHHMMSSsssZ-<hex>.md` — UTC millisecond timestamp + hex suffix
-for collision resistance. Sorts chronologically. The hex suffix must be at least
-8 characters, generated from a CSPRNG.
-
-```
----
-from: concierge
-timestamp: 2026-05-23T19:00:00.000Z
-subject: Steve prefers TypeScript for all new tooling
-scope: global
-tags: [preferences, tooling]
-session: 7f3a2b1c-9e4d-4f8a-b6c2-1d5e8f0a3c7b
----
-
-Strong durable preference — never propose Python. Default to TypeScript/Bun, Go, or Rust.
-```
-
-### Memory frontmatter fields
-
-| Field | Required | Values | Notes |
-|---|---|---|---|
-| `from` | yes | free-form name | logical actor identity |
-| `via` | no | free-form name | session that committed on behalf of `from` — see Sub-agents |
-| `timestamp` | yes | ISO 8601 UTC | |
-| `subject` | yes | short string | descriptive label; used for filtering, not update detection |
-| `scope` | no | `global` or channel GUID | `global` if omitted |
-| `tags` | no | list of strings | free-form filtering |
-| `session` | no | session GUID | ties memory to the writing session |
-| `supersedes` | no | filename of original memory | declares this memory replaces an earlier one — see Updating memories |
-
-Memory files are agent-agnostic — any participant may read or write them. Do not
-use your model's native memory system; `data/memories/` is the memory system.
-
-### Updating memories
-
-To update a memory, write a new memory file with `supersedes: <filename-of-original>`. When loading memories, collect all filenames referenced by any `supersedes` field. Skip any memory whose filename appears in that set — it has been superseded. If two memories both supersede the same file, the newer timestamp wins. For same-timestamp ties, lexicographic filename order is the tiebreaker.
-
-`subject` is descriptive only — it plays no role in update detection.
-
-The `scope` field must be either `global` or a channel GUID from `data/channels/`. Session GUIDs are not valid scope values.
-
----
-
-## On session open
-
-1. Read `local/CROSSTALK.md`. If absent, halt and notify the operator. If `name` or `email` is still `CONFIGURE`, halt and notify the operator. Do not load memories, process messages, or write to `data/`. (Writing to `local/` to establish identity — e.g. via an operator-driven onboarding flow — is permitted, since identity establishment is the only way out of this state.)
-2. Read `upstream/CROSSTALK-VERSION`. If missing or not exactly `5.0`, halt and notify the operator. Do not load memories, process messages, or write to `data/`.
-2a. Read `hosts/` if present. Build a routing table of available actors per host. If the directory is absent or empty, routing table is empty — proceed normally.
-3. Run `git pull` to sync the transport.
-4. Load global memories from `data/memories/` where `scope` is `global` or absent. Filter by `subject` and `tags`.
-5. For each channel in `data/channels/`:
-   a. Load memories scoped to this channel GUID.
-   b. Scan for unread messages addressed to you (see Reading messages).
-   c. Process and reply. Only act on `type: text` messages — `type: read` messages require no reply and no further action.
-   d. Channel processing order across multiple channels is implementation-defined.
-6. Push immediately. If rejected, read backoff config from `local/JITTER.md` (falls back to `upstream/JITTER.md`). If neither file exists, use defaults: base=100ms, ceiling=5000ms. Run `git pull --rebase`, wait `random(0, min(ceiling, base * 2^attempt))`, then retry. After rebasing, push what was already composed — do not re-scan. Message filenames are unique — rebase conflicts should not occur.
-
----
-
-## Reading messages
-
-For each message file in `data/channels/<guid>/`, parsed chronologically:
-
-1. Check `to:` — process if your name appears (bare or as `name@your-host-alias`) or `to` is `all`; otherwise skip. If the target includes a `@host` suffix that does not match your host alias, skip. If your name is shared with other participants (an instance group), apply the deterministic selection rule and skip unless you are the chosen member — see Instance groups.
-2. Check for an existing `type: read` receipt from you with a matching `ref:`. If found, skip — already processed.
-3. If unread: process it, post a reply, then post a `type: read` receipt.
-
-Your `type: read` receipts are your cursor. No external state needed. On first run, all messages are unread — process them all.
-
-Each addressed agent receipts independently. A receipt from another agent does not mark a message as read for you.
-
-Actions must be idempotent. If a push fails after processing but before the receipt is committed, the message will be reprocessed on the next run.
-
----
-
-## Writing messages
-
-Create `data/channels/<guid>/YYYY/MM/DD/HHMMSSsssZ-<hex>.md` with the current UTC time.
-The hex suffix must be at least 8 characters, generated from a CSPRNG.
-Include required frontmatter: `from`, `to`, `type`, `timestamp`. Commit and push
-under your configured git identity.
-
-Write all replies for the session before pushing. Push once per session, not once per message.
-
----
-
-## What to ignore
-
-### Skip silently
-
-- Messages not addressed to you and not `to: all`.
-- Messages you have already acknowledged with a `type: read` receipt.
-- `type: read` messages — never post a receipt for one.
-- Files outside `data/channels/` and `data/memories/`.
-- Unknown frontmatter fields.
-- Your model's native memory system.
-
-### Skip and warn the operator
-
-- Messages where `from:` matches your own name — indicates a misconfigured identity.
-- Malformed messages — files missing required frontmatter fields or with invalid field values. Log the file path.
-- Read receipts with a `ref:` pointing to a nonexistent message path — indicates a bug in the writer.

package/template/upstream/JITTER.md

@@ -1,24 +0,0 @@
----
-backoff_base_ms: 100
-backoff_ceiling_ms: 5000
----
-
-Retry backoff for push conflicts in multi-agent transports.
-
-Push immediately with no pre-push delay. On rejection, rebase and wait before
-retrying:
-
-  wait = random(0, min(backoff_ceiling_ms, backoff_base_ms * 2^attempt))
-
-- Attempt 1: 0–200ms
-- Attempt 2: 0–400ms
-- Attempt 3: 0–800ms
-- Attempt 4: 0–1600ms
-- Attempt 5: 0–3200ms
-- Attempt 6 and beyond: 0–5000ms (capped at backoff_ceiling_ms)
-
-Agents that collide back off progressively. Agents with clean pushes pay zero
-added latency. Self-regulates under sustained load.
-
-Operators may override these values in local/JITTER.md.
-Agents read custom first, fall back to framework if custom is absent.