Development record

Which session holds which worktree, branch or record is coordinated entirely by conversation, so every new session repeats a handshake that nothing records. A session joining work in progress has no way to ask what is already claimed: it messages the peers it can see, waits for replies, and rebuilds a picture that the sessions before it had already built and did not write down. One measured encounter cost four messages and about fifteen minutes before any work began, and the picture it produced is not durable, so the session after that pays again. The convention that a diff you did not make is a peer's work depends on knowing who the peers are and what they hold, which is precisely the thing no artefact carries. The repository already records this gap for the narrow case of detecting a peer session before mutating git state; the wider case is claim rather than presence, and the two want the same substrate. Whatever holds it should be as cheap to write as it is to read, because a coordination record nobody updates is worse than the chat it replaced.

intentsupersededminorstandaloneitd-2609150819440345

Superseded by itd-2610170634394993 on 2026-10-17: the shared central view of who holds what, with each session's details kept on its own computer, is now carried by the coordination intent

Press Release

Seeded by promotion from iss-2609100519122086. Expand into the full press-release narrative before planning.

Decisions

Settled with the product thinker on 2026-09-20, while interviewing the listing draft (itd-2609091416295622):

This record is the register. Where a session's claims and the records it holds live so any other session can see them: across accounts on one machine and across machines on a network, a tailnet being the working example. The listing draft is the local read of that register; the claim draft (itd-2609091034175565) is the write; the implement verb (itd-2609201916151817) is the consumer that claims, checks, and implements or drops and picks the next.
Built-in basic, pluggable SOTA, as abcd's practice: a basic register abcd carries itself, and an adapter seam for an external implementation. The first agent to work on a repository registers it; others discover it.
The transport is the interview's first question. Candidates: the forge as the register (one ref per session pushed to the remote; needs no daemon, sees only what was pushed); a small peer service abcd runs per machine, found over the tailnet by its DNS name or by an announcement, which sees uncommitted state but needs a process that stays up; or both, the service first and the forge as the fallback when no peer answers. A LAN-only discovery (mDNS) reaches one network segment and is a candidate for the adapter, not the built-in.

The marker is a claim branch abcd lists, on the shared remote (the product thinker, 2026-10-03, with a second person now working on the project and the repository public): A claim is a small marker the remote holds per item, taken only if absent, carrying who holds it, the files it expects to touch and an expiry, renewed while work continues, and re-checked before merging; abcd lists the claims. As first ruled the marker was a ref the website does not show; the product thinker narrowed it to a branch the same day, because a hosted cloud session can push only branches (itd-2609091034175565, decision 10). It answers decision 3's transport question with its first candidate. It covers people who can change the project directly; outside contributors, who cannot push one, are itd-2610031259176838's follow-up. Reserving one item is built first, in itd-2609091034175565 (the product thinker, 2026-10-03: "A today, B later"); this record keeps the wider register of running sessions and what they hold, for later. Anything kept only on one computer (the local tier, a note on the desktop, same-account messaging) is never the register, because the other person never sees it; it may only speed up notice. A claim's contents are public, so they carry nothing private. Grounds: The state-of-the-art review and the run lessons of 2026-10-03 (2026-10-03-multi-agent-coordination-sota-and-run-lessons.md).

Why This Matters

Graduated from iss-2609100519122086: Which session holds which worktree, branch or record is coordinated entirely by conversation, so every new session repeats a handshake that nothing records. A session joining work in progress has no way to ask what is already claimed: it messages the peers it can see, waits for replies, and rebuilds a picture that the sessions before it had already built and did not write down. One measured encounter cost four messages and about fifteen minutes before any work began, and the picture it produced is not durable, so the session after that pays again. The convention that a diff you did not make is a peer's work depends on knowing who the peers are and what they hold, which is precisely the thing no artefact carries. The repository already records this gap for the narrow case of detecting a peer session before mutating git state; the wider case is claim rather than presence, and the two want the same substrate. Whatever holds it should be as cheap to write as it is to read, because a coordination record nobody updates is worse than the chat it replaced.. Read that issue record for the source observation.

Mechanism

Prompted (the claim-recording gradient): why the authors expect this to work, as a falsifiable "we expect X because Y" — not the outcome restated. Replace this line with the claim, or with the exact token None stated. alone on its line to record the claim as considered and declined.

Scope Conditions

Required (the claim-recording gradient): the population, platform, scale, or assumptions this claim holds under, one per top-level bullet — abcd intent plan stamps each with a persistent identity. Replace this line with those bullets, or with the exact token None stated. alone on its line.

Acceptance Criteria

Required (the itd-1 discipline): add at least one Given-When-Then bullet describing the verifiable bar for "shipped" before this draft can be planned.

Open Questions

None recorded yet.

Audit Notes

Empty. Populated by intent-auditor when intent moves to shipped/.

Frontmatter

id	itd-2609150819440345
type	intent
lifecycle	superseded
kind	standalone
severity	minor

.abcd/development/intents/superseded/itd-2609150819440345-which-session-holds-which-worktree.md
open on GitHub ↗ · commit history ↗

References2

itd-2609091034175565Before an agent starts on an item, it reserves it on the shared remote, and everyone who works on the project sees the reservationbuilds on
itd-2609091416295622A session sees the records its peers hold before it mints or fixes onebuilds on

Referenced by8

adr-2610031352212697Claims are branches on the shared remote; nothing kept on one computer is the register; claim text is datarelated
iss-2609100519122086Which session holds which worktree, branch or record is coordinated entirely by conversation, so every new session repeats a handshake that nothing records. A session joining work in progress has no way to ask what is already claimed: it messages the peers it can see, waits for replies, and rebuilds a picture that the sessions before it had already built and did not write down. One measured encounter cost four messages and about fifteen minutes before any work began, and the picture it produced is not durable, so the session after that pays again. The convention that a diff you did not make is a peer's work depends on knowing who the peers are and what they hold, which is precisely the thing no artefact carries. The repository already records this gap for the narrow case of detecting a peer session before mutating git state; the wider case is claim rather than presence, and the two want the same substrate. Whatever holds it should be as cheap to write as it is to read, because a coordination record nobody updates is worse than the chat it replaced.related
itd-2609091034175565Before an agent starts on an item, it reserves it on the shared remote, and everyone who works on the project sees the reservationrelated
itd-2609091416295622A session sees the records its peers hold before it mints or fixes onerelated
itd-2609151838312703Sessions under any account, on any machine or in the cloud announce what they are doing through short fixed-form announcements on the shared remote, a person reads everyone's status with one command, and what is really a hold stays a reservationrelated
itd-2609221656373558Two sessions share one run, and the run measures which way of dividing the work is bestrelated
itd-2610120738075547Work handed to a cloud session comes back, or says why notrelated
itd-2610170634394993Headless agents in parallel coordinate through the shared remote, not conversationsuperseded by

mentions11

dcn-26092200000000042026-09-22 — Two intents the product thinker added for the autonomous run of 2026-09-23, interviewed and planned the night before (both READY, both in the run's batch 1b). A managed repository reports back to abcd (itd-2609221656361680): one verb files a written account against an abcd-issued template with a machine-readable block beside the prose, into an inbox in the user account's machine store, never in either repository's tree; abcd says at its next start how many wait and from how many repositories; a read-only verb renders them naming the sender; nothing is filed until a person or a session acts, and what is filed carries the sender's root-commit fingerprint and a generic description, never its name. Two sessions share one run (itd-2609221656373558): the second joins without a word from the first and the first never waits on it; all three division modes are tried, one per window in order (a claim per record, whole batches, build against review-and-land), because the product thinker wants each measured rather than one chosen in advance; a claim is an atomic create with a lease that lapses; the second session holds at most one lane, may never cut a release or take a lane that recalibrates the reading corpus, backs off on contention with a logged reason, and its stop conditions stop only itself; the run's report compares the three modes on lanes landed, wall clock, collisions and agent minutes. Cross-account and cross-machine agent communication stays out of the run: the four drafts (itd-33, itd-2609151838312703, itd-2609151838327688, itd-2609150819440345) get planning briefs only, with the trust question a shared mailbox raises named in the brief.
dcn-26100300000000012026-10-03 — Reserving work across people (product thinker, at an interactive interview, with a second person now working on this public repository). Rulings: anything kept on one computer (the local tier, a desktop note, same-account messaging) is never the record of who works on what, because the other person never sees it; an item is reserved by a reservation branch on the shared remote, `abcd-reserved/<record-id>`, which abcd lists and nobody merges, chosen over a hidden ref because a hosted cloud session can push branches only (probe of 2026-10-03 and the host's documentation); a hosted cloud session takes part exactly as a second person's machine does; itd-2609091034175565 is planned and built today with every acceptance criterion, and the session register itd-2609150819440345 stays a draft for later; outside contributors, who cannot push a claim branch, are the follow-up itd-2610031259176838, not urgent. The ruling of 2026-09-22 ("Cross-account and cross-machine agent communication stays out of the run") covered the run of 2026-09-23 only, confirmed by the product thinker today, so nothing is overturned. The 2026-09-09 ruling's two-release migration for a `claimed_by` stamp does not arise, because no stamp is written on any record (decided without a question: one defensible answer). The research and both reviews are filed as research/notes/2026-10-03-multi-agent-coordination-sota-and-run-lessons.md.
iss-2609200830169721A managed repository is running the whole intent lifecycle through one sub-agent per record, and asks whether the pattern should become an abcd recipe. The shape, reported by the Gropius session gropiusllm-2b on 2026-09-20: a main session interviews the product thinker one decision at a time, reading the reviewer's recorded options off the draft rather than re-deriving them, records each answer as it is given, then fans out one Opus 5 sub-agent per intent or issue, each in its own worktree, which fills the draft from the answers, runs abcd intent plan, writes the spec, implements test-first, runs the security and ruthless reviewers as its own sub-agents, closes the spec in the landing pull request and arms auto-merge; record-only lanes edit exactly one record each and may not plan. The session named what abcd already gave it (quoted-text filing, capture provenance flags, intent ready --json as the gate every lane runs, the Review and Open Questions convention on a held draft) and what it lacked (recorded separately: the answer write path, the hold state, the append-lock on the decision log, the integration-branch landing, the lane worktree location). Whether abcd documents this as a recipe (a plugin page, a runbook in the brief, or a scaffolded lane brief) is the product thinker's to decide; recorded here so the decision has a record to rest on. Note that abcd's own record already plans the worktree half (itd-148) and asks the same session-per-lane question from the coordination side (itd-2609150819440345).
iss-2609240227595724itd-33 (draft, written 2026-07-06) runs against three later rulings, which its planning interview has to settle. (1) adr-2609091248200336 (2026-09-09): agent and session state is machine-scoped under ~/.abcd/ keyed on the root commit, and the checkout holds only its declared tiers; itd-33 puts per-machine live state and locks (active-work.json, *.lock) in a new .abcd/coordination/ directory inside the checkout, which is no declared tier, beside a committed audit/ log. The shipped claim of itd-2609221656373558 already keeps its run store outside the repository. (2) The basics-plus-adapter principle (principles/basics-built-in-adapters-bring-power.md, 2026-09-15): every capability ships a basic form and offers an opt-in adapter for the full form; itd-33 is always on with no opt-out and rules out any external route, so it offers no adapter. This one is a tension in spirit: the principle's letter does not forbid an always-on basic. (3) itd-2609221656361680 Decision 4, identity in the inbox and a fingerprint in the record: anything committed carries the root-commit key and a generic description; itd-33's committed audit log names the person from git config on every agent_registered event and in resolved_by_human. Decision 4's letter governs the managed-repository reports; applying it here is by extension. The register ruling (itd-2609150819440345 Decision 1, the register is where claims live) overlaps its claim model too. Distinct from iss-2608230943533581, which asks for the coordination SOTA sweep.
iss-2610150726331622abcd peers does two unrelated things: it lists records that sibling worktrees and local branches hold that this checkout does not (an agent's duplicate check before filing), and it fetches and lists the reservations on the shared remote. The second duplicates abcd status from itd-2609151838312703, the people's view of what everyone else is doing. The product thinker ruled on 2026-10-15 that peers keeps its name for its future meaning, which sessions are running now, local first and later over a private network such as Tailscale or WireGuard (the session register itd-2609150819440345), and that the local duplicate check belongs under abcd status --local.
iss-2610150749053362Several draft intents carry H1 titles that read badly now that the out-of-scope drafts index is generated from each record's H1: itd-70's H1 is the placeholder 'Drawn-out intent', itd-2610070544145422's H1 is cut off mid-sentence ('…and it just works: the'), and eleven drafts have paragraph-length H1s of 300 to 1,093 characters (for example itd-2609150819440345 and itd-149).
itd-1Every Intent Has Acceptance Criteria; Every Audit Verifies Them
itd-2609201916151817One verb takes a READY intent to delivered, and refuses while a decision is open
itd-2609201925079472An autonomous run paces itself by default, and one flag sets the pace
itd-2610031259176838Outside contributors reserve work through a draft pull request that abcd honours
spc-2610031753359849Reservations on the shared remote: `abcd reserve`, one liveness judgement, and the build, drain and land integration