Concurrent Loops

1. Status

Living document, and unusually for this section — grounded in a single dated incident rather than a general argument. It's described plainly below, on purpose: an incident abstracted into a hypothetical is easier to wave off than one with a date on it. It was drafted the same week it happened, in the same peer-aware batch as Paper 7, which is where the draft-it-while-it's-raw discipline gets named formally. That shared batch is a production-schedule fact, not a claim that this incident was staged to illustrate a rule Paper 7 already had — the incident came first; Paper 7 just wrote down why that ordering matters.

2. Motivation

Paper 2 said the way this project adds capacity is another loop tier, not another hire. Paper 3 said every one of those loop tiers runs the same five-phase shape. Put those two together and the obvious consequence is: this project routinely runs more than one loop-directing session at once, in the same repository, sometimes in the same working directory. That's not a hypothetical scaling concern to plan for someday. It already happened, and it went wrong in a way worth describing exactly.

3. The Incident (2026-07-09, this repository)

Two Claude Code sessions were directing loops in the same working directory at the same time — one mid-fix on feature/MobileClient-345 (PR #263 CI), one starting fresh work on feature/MobileClient-350. Two separate collisions followed from that, independently, per docs/ANTI-PATTERNS.md ANTI-PATTERN #11:

Incident A — the other session's commit landed on the wrong branch. This session created a new branch with a plain git checkout -b in the shared root rather than an isolated worktree. Minutes later, the other session's commit landed on that new branch by accident — it had uncommitted work staged when the checkout happened, and git checkout silently carries staged/unstaged changes across branches whenever there's no path conflict. Not a bug in git checkout; its documented, unglamorous default, and the mechanism by which one session's commit ended up on a branch it had nothing to do with. Recovered via an isolated worktree cherry-pick and a git reset --soft, but only after real risk of losing or misattributing another session's in-progress work.

Incident B — a pre-push hook's full-repo test run picked up another session's uncommitted file. Minutes later, independently, this session's own pre-push hook ran its full repo-wide Jest pass — the validation this project deliberately moved out of pre-commit and into pre-push so day-to-day commits stay fast (see docs/HooksArchive/pre-commit-full-ci-parity-2026-07-09.md) — and that pass, scanning the whole working tree exactly as designed, picked up the other session's in-progress, uncommitted test file as if it belonged to this branch's tree. The foreign test failed in a context that had nothing to do with this session's actual change, and blocked an unrelated push until the false failure was traced back to a file this session had never touched and diagnosed as someone else's in-flight work, not a real regression.

Neither tool malfunctioned. git checkout's carry-forward and the pre-push hook's full-repo Jest pass are both correct, documented behavior for the single-session case they were built for. The failure was an assumption — that the working directory was exclusively this session's — that turned out to be false, twice, in the same session, from two unrelated tools.

4. Core Thesis

A shared working directory is not a neutral substrate between concurrent loops. Every tool with a side effect — a checkout, a full-repo test runner — operates on whatever is actually sitting on disk, not on "your" logical slice of it. A second session's in-progress, uncommitted work is invisible right up until it's silently swept into your session's operation by a tool doing exactly what it was designed to do.

5. Principles

6. Practices — What Actually Runs Today

• git worktree add is the documented default whenever another session or process may be using the same working directory — treated as the assumed case, not something to first prove, per the detection checklist established after this incident. Still a convention, per C1 — it works because it's followed, not because anything enforces it.
• A named resource lock (scripts/lib/loop-resource-lock.js), added the next morning as part of DEVLOOP's initial build (2026-07-10 — the day after this incident, not the day of), is the actual mechanical stopgap on top of that convention: DEVLOOP (Paper 3's L2/L5) acquires a git-working-directory (or cdk-deploy:<env>) lock before any git-mutating action or deploy, so a second loop attempting the same class of operation waits instead of silently colliding. This is closer to structural than the worktree convention alone, because it's enforced in the loop's own code path rather than remembered by the session — but it only covers loops that go through DEVLOOP, not every ad hoc git operation a session might run directly. Workflows: Concurrent Session Safety is the diagram-and-mechanism version of this same bullet, without this incident's own narrative attached.
• git status (and, if anything looks foreign, git reflog) immediately after any mutating git operation in a shared root — a standing habit now, not an occasional sanity check.
• Both the pre-commit lint-staged step and the pre-push full test run remain unchanged — nothing about this incident argues for weakening the automation. Worktree isolation removes their exposure to another session's files; it doesn't remove their job.
• The real structural fix has been adopted; rollout is starting, not finished. docs/ADR/0012-jujutsu-parallel-session-isolation.md (Accepted, 2026-07-10 — the stub opened the same day as this incident, docs/ImplementationPlans/Jujutsu-Parallel-Session-Vision/STUB.md, was rehydrated into this decision the same evening) adopts Jujutsu (jj), colocated with the existing .git via jj git init --colocate, specifically because its working-copy model has no shared mutable index to collide on in the first place — a property no amount of worktree discipline or lock convention replicates on top of plain git. Operational rules now live in docs/GuidanceForClaudeCode.md §2a: GIT GATE applies at the remote boundary (jj git push, jj git fetch, PR creation) rather than to every local jj auto-snapshot, jj workspace list replaces any session-registry file, and rollout is scoped to new parallel sessions going forward — branches already open under the old worktree convention finish that way rather than being migrated retroactively.

7. Non-Goals

• Not a treatment of Paper 1 P4's merge-order/composition-divergence hazard. P4 is a different problem: whether "invoke a non-deterministic AI worker once and fork the result" and "invoke it independently per branch" can genuinely diverge from the same starting ticket, and how this project decides between them. Everything in this paper — a checkout carrying uncommitted files across branches, a pre-push hook scanning a foreign uncommitted test file — is a filesystem/tool-side-effect hazard from two sessions sharing one working directory, not a case of two AI invocations disagreeing with each other. The actual mechanism P4 asks for remains unwritten in this series, the same way Paper 2's B5 flags the multi-operator case and Paper 5 is flagged ROADMAP — named here as an open gap, not silently dropped.
• Not a claim that every tool with a side effect has been audited for this failure mode — only the git-adjacent ones surfaced by this incident are covered so far.
• Not a claim that worktree isolation is universally adopted retroactively across every session today — it's the documented default going forward, not a claim of perfect historical compliance.
• Not a solution to true simultaneous-write conflict, where two loops both intend to edit the same file at once. That's a different, harder problem than "one session's tool accidentally touched another session's files," and this paper doesn't claim to have solved it.
• Not part of the Perspectivity Research Reports series. That series is made up on purpose; the two collisions in §3 have a timestamp in git log and did not need inventing.

8. Revision History