Concurrent build lanes clobber each other's scratchpad working files mid-run

[usirin]

Triage verdict — type:bug, p1, homed in the Worktree-Isolation Integrity campaign. Every source claim below was read first-hand against this checkout in this run and is cited file+line. Anything not verified here is labelled unverified, not softened. This desk wrote to no other issue; see Outstanding actions.

The question this ticket was filed to settle

Does #4544's fix also fix this? No. Same root-cause class, disjoint fix surface — #4544's scope and every one of its acceptance criteria enumerate exactly four skills, and write-code is not among them. Folding this into #4544 would silently drop the build path. Detail in Reconciliation, below.

What is wrong

The §SP contract promises that concurrent runs cannot name each other's scratch files. On the build path that promise is delivered by convention alone, in two places where it does not hold.

1. Every write-code scratch write hand-rolls the §SP path instead of allocating through the shipped allocator — so no owner stamp exists and there is no refusal to hit.

The allocator's protection is the exclusive-create owner stamp, not the path shape: openNamespace writes .kampus-run-owner with flag: "wx" (packages/pipeline-cli/src/tools/scratchpad/store.ts:83-85), and classifyOwnership (packages/pipeline-cli/src/tools/scratchpad/scratchpad.ts:194-199) refuses a same-session stamp carrying a different CLAUDE_PID as foreign. The shell entry points that reach it are kp_scratch_open / kp_scratch_path (claude-plugins/kampus-pipeline/lib/common.sh:380-381).

write-code calls neither. Eight committed sites interpolate the §SP path as a literal string and mkdir -p it, which creates no stamp and therefore can never return ForeignNamespace:

Site (under claude-plugins/kampus-pipeline/skills/write-code/scripts/)	Line	Slug
step6-progress-comment.sh	40	write-code-<N>
step7-epic-handoff.sh	39	write-code-<N>
stepR3-push-and-note.sh	53	write-code-<N>
stepR-frozen-ac.sh	28	write-code-repair-<PR>
stepR-round-count.sh	30	write-code-repair-<PR>
stepR1-verdicts.sh	42	write-code-repair-<PR>
stepR2-fail-body.sh	38	write-code-repair-<PR>
stepR2-inline-comments.sh	29	write-code-repair-<PR>

Three of those scripts carry an in-file comment conceding the bypass verbatim — "The hand-rolled RUN_SCRATCH derivation duplicates kp_scratch_path; collapsing it onto that helper is phase 2's call (#1929)" (step6-progress-comment.sh:14, step7-epic-handoff.sh:12, stepR3-push-and-note.sh:15). So the bypass is known and deferred, not accidental.

The slugs do carry the work item, so two lanes on two different issues resolve two different directories — that separator holds. What the missing stamp removes is the protection on the cases where the slug is not a separator: a second role on the same lane, a re-run, or a repair round over the same issue number. There the allocator would refuse; the hand-rolled path silently re-enters and clobbers.

2. Nothing binds the intermediates an agent invents mid-run to §SP at all. The three artifacts this report names — a mutation-harness script, a PR-body draft, a progress note — are exactly that class. Two of them have no skill-prescribed path anywhere:

• The PR body is composed inline into gh pr create --body from a here-document (claude-plugins/kampus-pipeline/skills/write-code/SKILL.md:1476 ff). There is no file in the prescribed shape, so a lane that drafts the body to a file is improvising a path the skill never named.
• A mutation-harness script has no prescribed shape at all.
• The progress note is the one that is prescribed — progress.md inside the run scratch directory under slug write-code-<N> (SKILL.md:1550-1560, step6-progress-comment.sh:40).

write-code's only §SP instruction is scoped to one instance and says so: the branch-name block at SKILL.md:812-844 closes with "This is the local instance of the per-run scratchpad namespace, §SP...". There is no general rule in SKILL.md or repair.md binding every run-scoped intermediate the agent creates to §SP or to a rule-4 mktemp. That is precisely the rule #4544 requires of the four gate skills — and it is what would have prevented this report.

The banned surface an improvised write most likely lands on is the harness-provided session scratchpad directory, which §SP explicitly carves out: "A session-scoped scratchpad handed to an agent by the runtime is shared across the concurrent runs of that session, and generic leaf names under it ... collide" (claude-plugins/kampus-pipeline/skills/gh-issue-intake-formats.md:1985-1991). Six concurrent sibling lanes of one parent session share that directory by construction. The report does not name the concrete directory its three artifacts were written to, so which surface each collision landed on is not verifiable from the board — carried as unverified. The finding does not depend on it: both candidate surfaces are §SP violations at an improvised call site.

Why the price is what it is

Priced on the unmitigated failure mode, not the observed outcome. The clean result here was produced by write ordering, which is not a control. The class is silent by construction — a clobbered file reads back successfully, with plausible content, because it is a genuine artifact of a genuine lane. The two live outcomes are one lane overwriting another's state, or one lane adopting another lane's content and posting it: a PR body describing work the diff does not contain, and — because write-code PR bodies carry a closing keyword (Fixes #<N>, SKILL.md:1502) — a merge that closes the wrong issue.

p1 and not p0: the direction that makes #4544 p0 is a gate reading corrupted content and emitting a well-formed false PASS. That direction is absent here — a build-lane artifact swap is misattribution, and the code gate still reads the diff. p1 because the fix is a small prose unit that rides an in-flight p0's fix at near-zero marginal cost, and the hazard fires in the factory's normal operating mode (six lanes).

Reconciliation — #4544 vs this issue: same class, non-overlapping surface

Both are the same root-cause class: run-scoped intermediates not bound to the §SP allocator. They cover different write sites, and neither fix reaches the other's:

	#4544 (p0)	This issue (#4875)
Skills in scope	review-code, review-plan, ship-it, review-skill — named in its Scope bullet and in its first acceptance criterion	write-code (including repair.md)
Write sites	Agent-authored gate intermediates (file lists, set-comparison inputs, working copies of a base SKILL.md)	Agent-authored build intermediates (mutation harness, PR-body draft) plus the eight committed hand-rolled sites tabled above
Allocator relation	Never routed	Path-shaped like §SP but stamp-free — allocator refusals unavailable
Worst case	A gate emits a confident false PASS	A lane posts another lane's PR body / progress note; a wrong Fixes #<N> closes a foreign issue

Recommendation: do not fold, and do not make this a child of #4544. #4544's triage explicitly verified its own scope against origin/main and fixed it to the four gate skills; write-code was never in it. The right shape is sibling tickets on one convention: whoever writes #4544's rule should write the identical paragraph into write-code/SKILL.md and repair.md, and this ticket is what makes that second half tracked rather than assumed. If an implementer takes both at once, this issue is the one that closes on the write-code half.

Relation to #4692 — closest neighbour, and a correction to its sweep

#4692 ("Unkeyed scratchpad filename let a lane commit another lane's commit message", type:bug p2 axis:pipeline-hardening) is the same class at a third build-path call site, and its acceptance criteria already cover the stamp-free no-CLI fallback in lib/common.sh, three fixed-slug allocations, and a mechanical §SP-conformance guard. It is the nearest thing to a duplicate of this issue and an implementer should read it first. Two reasons this is not closed into it:

1. Unkeyed scratchpad filename let a lane commit another lane's commit message #4692's acceptance criteria name three write-code allocator-bypassing scripts (stepR-round-count.sh, stepR1-verdicts.sh, stepR2-fail-body.sh). The sweep run for this triage finds eight under skills/write-code/scripts/ (table above) — the five additional ones (step6-progress-comment.sh:40, step7-epic-handoff.sh:39, stepR3-push-and-note.sh:53, stepR-frozen-ac.sh:28, stepR2-inline-comments.sh:29) are not in Unkeyed scratchpad filename let a lane commit another lane's commit message #4692's list, and three of them sit on the non-repair main path. Closing this as a duplicate would carry that undercount forward.
2. Neither Unkeyed scratchpad filename let a lane commit another lane's commit message #4692 nor Gate skills still write fixed-name scratchpad intermediates, bypassing the shipped allocator #4544 has an acceptance criterion for the improvised-write-site half on the build path — a lint can only see committed scripts, and Gate skills still write fixed-name scratchpad intermediates, bypassing the shipped allocator #4544's prose rule stops at the gate skills.

Relation to #4864 — distinct mechanism, confirmed

Distinct. This refutes the "may share a root cause" hedge in the original report. #4864 is about the inside of the allocator; this issue is about writes that never reach it.

• scratchpad open concurrency test fails only in merge-queue batch: loser exits 6, not 4 #4864's mechanism is the non-atomic owner stamp: the wx write at store.ts:83-85 makes the create exclusive but not the content write, so a loser hitting EEXIST can read a zero-byte stamp, parseOwner returns null (scratchpad.ts:171-183), and the loser takes the NamespaceUnavailable branch (store.ts:90-96, exit 6) instead of ForeignNamespace (exit 4).
• That is a wrong refusal code on a fail-closed path — scratchpad open concurrency test fails only in merge-queue batch: loser exits 6, not 4 #4864's own triage states the refusal stays fail-closed and no run is handed a namespace it does not own.
• This issue is the opposite direction: no refusal is reached at all, because the write sites either never call the allocator or never write a stamp. A fully atomic stamp would change nothing here.
• They meet at one point only: bringing the write-code sites onto kp_scratch_open increases traffic through scratchpad open concurrency test fails only in merge-queue batch: loser exits 6, not 4 #4864's claim path. That is a sequencing note, not a shared cause.

#4864 is claimed and under active build. This desk proposes no change to it and did not write to it.

Relation to #4516 — upstream, not the same defect

#4516 ("Per-run scratch namespace's session key is shared across lanes and roles", type:bug p1) is the keying defect: the session id does not distinguish concurrent sibling lanes. It is upstream of this issue and does not subsume it — the write-code slugs already carry the work item (write-code-<N>), so lane separation on the build path survives a shared session id. What #4516 fixes is the residual same-lane / cross-role collision; what this issue fixes is the sites that have no stamp and the writes that have no rule. A fix here should adopt #4516's chosen lane identity rather than inventing a second one.

Scope note for the implementer

• §CP surface. claude-plugins/kampus-pipeline/skills/write-code/ is control-plane, so the prose half rides the §CP review/merge path with a human approval at head. packages/pipeline-cli/src/tools/scratchpad/ is not touched by this ticket's fix.
• Do not fix this by keying leaf filenames. §SP rule 2 puts uniqueness in the directory and names a randomized leaf as the anti-pattern (gh-issue-intake-formats.md:2063-2078). The original report's non-binding suggestion ("lane-unique filenames within the scratchpad namespace") is the fix the contract already rejects — recorded here so it is not re-bred.
• §SP rule 1 first. Several of these intermediates need no file at all (the PR body is already a here-document; a harness script consumed inside one Bash call is a rule-4 mktemp).

Acceptance criteria

• write-code's own body (claude-plugins/kampus-pipeline/skills/write-code/SKILL.md and repair.md) states that every run-scoped intermediate the agent creates — a harness script, a PR-body draft, a file list, a working copy — is allocated under §SP via kp_scratch_open / kp_scratch_path (or a rule-4 single-call mktemp), never a fixed leaf in the harness scratchpad and never a bare temp-root path. The rule is general, not a second branch-name-shaped local instance.
• The eight hand-rolled §SP path interpolations under claude-plugins/kampus-pipeline/skills/write-code/scripts/ (tabled above) allocate through kp_scratch_open / kp_scratch_path, so an owner stamp exists and a same-slug concurrent peer is refused rather than silently re-entering.
• The rule as written is reconciled with Gate skills still write fixed-name scratchpad intermediates, bypassing the shipped allocator #4544's gate-skill rule — one convention, one wording, cross-linked both ways — and with Per-run scratch namespace's session key is shared across lanes and roles #4516's chosen lane identity (same identity, or an explicit reason they differ).
• The wrong-data direction is named where the rule lives: a clobbered draft reads back successfully and plausibly, which is why a lane can post another lane's PR body — including its Fixes #<N> — and nothing errors.
• No criterion is satisfied by keying leaf filenames (§SP rule 2), and none is satisfied by a change confined to the one reported artifact.
• The PR touching claude-plugins/kampus-pipeline/ carries a human approval at head (§CP).

Outstanding actions this desk did not take

• No cross-issue write to Gate skills still write fixed-name scratchpad intermediates, bypassing the shipped allocator #4544, scratchpad open concurrency test fails only in merge-queue batch: loser exits 6, not 4 #4864, Unkeyed scratchpad filename let a lane commit another lane's commit message #4692, or Per-run scratch namespace's session key is shared across lanes and roles #4516. This desk had no pre-authorization for those issues, so three things are surfaced here rather than silently dropped: (a) Gate skills still write fixed-name scratchpad intermediates, bypassing the shipped allocator #4544 should gain a cross-link naming this issue as its build-path sibling; (b) Unkeyed scratchpad filename let a lane commit another lane's commit message #4692's call-site count is an undercount on the write-code half — five further allocator-bypassing sites are listed above; (c) scratchpad open concurrency test fails only in merge-queue batch: loser exits 6, not 4 #4864 needs a sequencing note only, and is under active build, so nothing is proposed for it.
• Nothing was closed. Unkeyed scratchpad filename let a lane commit another lane's commit message #4692 stays open as the broader class carrier.

---

Original report (verbatim)

Summary

Six build lanes ran concurrently today and shared one scratchpad namespace; one lane reported sibling lanes overwriting its just-written working files at three distinct moments during its run. No wrong artifact is known to have shipped this time, but the collision itself was real, and only timing — not any guard — kept the outcome clean.

What I was doing

Running as one of six build lanes executing concurrently, doing normal in-lane work: writing a mutation-harness script, drafting a PR body, and writing a progress note into the per-run scratchpad namespace.

What I observed

Across the run, this lane found three of its own scratchpad artifacts overwritten by what appears to be sibling lanes writing into the same namespace: a mutation-harness script, then a PR-body draft, then a progress note. Each of this lane's own writes happened to land after the prior clobber and before the next one, so by luck the artifact it read back and used (including the PR body it ultimately posted) was verified on GitHub to be its own. The writes themselves genuinely collided — this is not a near-miss, just a clean outcome produced by timing nobody controls.

Why it matters

If timing had gone the other way, a lane could read back a sibling's PR-body draft or progress note and post it to the wrong PR or issue, misattributing one lane's work to another — the same shape as the earlier incident where a lane wrote directly to a foreign lane's issue. With concurrency rising (six lanes today), the odds of an incidental clean outcome go down while the collision rate goes up.

Pointers

• Related, filed 2026-07-30: Gate skills still write fixed-name scratchpad intermediates, bypassing the shipped allocator #4544 — "Gate skills still write fixed-name scratchpad intermediates, bypassing the shipped allocator" — same collision shape (fixed-name scratch writes clobbered under concurrency), but scoped to review-gate lanes (review-code/review-plan/ship-it), not build lanes. This report may be the same root-cause class occurring on the build-lane side, or a distinct occurrence — worth reconciling.
• Related: scratchpad open concurrency test fails only in merge-queue batch: loser exits 6, not 4 #4864 — "scratchpad open concurrency test fails only in merge-queue batch: loser exits 6, not 4" — a separate report of a race in the scratchpad namespace-open path itself (a non-atomic owner-file claim can let a losing racer read a partial owner stamp). May share a root cause with this report's clobber, or may be independent — worth triage determining which rather than assuming.
• packages/pipeline-cli/src/tools/scratchpad/ — the scratchpad allocator implementation referenced by both related issues above.

Suggested next step (non-binding)

Reported candidate fix (not evaluated, record only): lane-unique filenames within the scratchpad namespace, so concurrent lanes cannot target the same path even if they otherwise share a namespace. Triage may find this is exactly #4544's class applied to build lanes rather than gate lanes, in which case the fix may already be in flight there.

---

_{Filed by an agent · session fcd74bd3-8872-4023-b100-a81ac870eb43 · branch main · 2026-08-08T00:51:53Z}

[usirin]

Triage fold — #5000 closed as a duplicate of this issue. #5000 is a second, independent sighting of exactly the unit this issue's "2. Nothing binds the intermediates an agent invents mid-run to §SP at all" names first: the PR-body draft. Same skill, same surface, same fix. Folding what it adds below; its full body is preserved verbatim at the end.

1. The surface this issue carried as unverified is now verified

Both this issue and #4692 stated the harness-provided session scratchpad as the likely surface and explicitly carried it as unverified, because neither report named the concrete directory. #5000's did not either — but the directory was readable first-hand at triage time, and it is surface 1:

• The colliding pr-body.md lives in the harness-provided session scratchpad — the directory the runtime injects into an agent's prompt, keyed <project-dir-hash>/<session-id>/scratchpad. §SP has no jurisdiction there and explicitly bans it.
• That one flat directory currently holds several lanes' PR bodies side by side: a pr-body.md carrying one issue's Fixes #<N>, a pr-body-new.md, and a pr-body-<N>-lane.md — the lane-keyed filename the A per-run scratchpad file read back with ANOTHER lane's PR body — silent clobber on an unkeyed leaf name #5000 reporter added as their own workaround. Multiple concurrent lanes, one unkeyed leaf name, no owner stamp anywhere in that tree.
• Meanwhile the correctly allocated §SP namespaces for the two issues involved in the incident both exist, as separate directories under the same session. §SP's slug did its job. The collision happened entirely on the banned surface, at an improvised call site — which is this issue's diagnosis, now with the evidence attached.

2. A finding that removes a backstop the board currently records as holding

CLAUDE_CODE_SESSION_ID and CLAUDE_PID are pane-scoped, not run-scoped. Read first-hand from live owner stamps: one pane's §SP root holds 84 distinct triage-<N> namespaces all stamped with one identical pid — the same pid exported into a subagent of that pane at read time; a second pane's root holds write-code-* stamps spanning 2026-07-26 → 2026-08-09, every one carrying the same (session, pid) pair.

So classifyOwnership (packages/pipeline-cli/src/tools/scratchpad/scratchpad.ts) returns "mine" for every sibling lane of one pane, and openNamespace's EEXIST branch returns the namespace as is, without clearing (packages/pipeline-cli/src/tools/scratchpad/store.ts). The "byte-identical identity" case the module docblock records as the one pair the stamp cannot separate is not an edge case in this topology — it is the normal case for concurrent lanes.

Consequence for this issue: on the eight hand-rolled, stamp-free sites tabled above there was never a refusal to lose, and on the allocator path there is no refusal within a pane either. The only separator that actually operates between concurrent lanes is the slug. Filed as its own unit at #5028, since it reaches beyond write-code (it also falsifies #4692's "exit 4 — a loud refusal, not a clobber" for its three fixed-slug sites, and settles #4881's "three regimes" question in the worst direction).

3. Silent or loud, and how far it crosses — stated plainly

Silent in every respect that matters. The write succeeds, the read succeeds, the content is valid markdown that reads like a legitimate PR body, and there is no timestamp, checksum, or owner marker in the file to compare against. Nothing errors.

It crosses both ways. Concurrent, cross-lane within one pane — the reported case: the harness scratchpad is shared by every lane the pane spawns, and an unkeyed leaf is a shared mutable surface. Sequential, same lane — a re-run matches the stamp, takes the EEXIST re-enter branch, and reads back the earlier run's leftovers, because clearLeftovers runs only for a run that won a fresh claim.

And yes: it can produce an artifact attributed to the wrong run. #5000's near-miss is the concrete case — a PR body composed for one PR read back carrying another PR's text and that PR's Fixes #<N> line. Posted, it would have wired a foreign closing keyword onto a PR that never touched that issue, and merging it would have silently closed an issue the diff does not address (#1259 class). The same shape already landed once as a merge-gate artifact: #3718's reviewer diffed the wrong PR.

4. Recommendation — re-band p1 → p0 (NOT applied here)

This issue's p1 argument was: "the direction that makes #4544 p0 is a gate reading corrupted content and emitting a well-formed false PASS. That direction is absent here — a build-lane artifact swap is misattribution, and the code gate still reads the diff." Two things now cut against it:

• The clobbered artifact is a gate input, not just a description: a PR body carries Fixes #<N>, and the merge acts on it. A wrong-run PR body is a silent wrong-issue close at merge time, not a cosmetic misattribution.
• The allocator backstop that made "the lane would have been refused" arguable is proven inert within a pane (§2 above), which is the factory's normal operating mode at six concurrent lanes.

I have not touched this issue's labels — re-banding a different issue is outside the pre-authorization for the #5000 triage. Flagging for the founder / EA as a recommendation only.

#5000 (closed duplicate) — full body

Summary

A coder lane composed its PR body into a file under the per-run scratchpad, and when it read that file back a moment later the file contained another PR's body. The read succeeded, the content was well-formed markdown, and nothing errored. Had the lane not seen the content before posting, it would have overwritten its own PR description with an unrelated PR's text — including that PR's Fixes #NNNN line.

What I was doing

Building #4744 (wiring verify-step0-class-parity.sh into CI). I wrote the PR body to a scratchpad file, edited it to add CI run evidence, then went to PATCH the PR body from that file.

What I observed

Between writing the file and reading it back, its contents were replaced wholesale. The file I wrote described PR #4997 (Fixes #4744, the class-parity harness). The file I read back described a different PR entirely — a review-ui naming disambiguation touching .decisions/0144-depo-internal-asset-cdn.md and .glossary/TERMS.md, carrying Fixes #4951.

Both lanes were writing a file named pr-body.md in the same scratchpad directory. The path is nominally per-session, so a collision was not expected there.

The failure is silent in every respect that matters:

• the write succeeded
• the read succeeded
• the content parses as valid markdown and reads like a legitimate PR body
• there is no timestamp, checksum, or owner marker in the file to compare against

The only thing that caught it was noticing the content had changed. A lane that piped the file straight into gh api -X PATCH would have clobbered its own PR description and never known.

Why it matters

This is the #2038 / #3718 silent-clobber class, both already recorded: a lane wrote its branch name to a shared scratch file, a sibling clobbered it, and the reader pushed to the sibling's ref (#2038); a reviewer diffed the wrong PR off the same shape (#3718). write-code's SKILL.md names this hazard in two places and prescribes §SP per-run namespacing as the fix. What this sighting adds is that §SP namespacing alone did not prevent it — the path was already session-scoped and the collision happened anyway, on the unkeyed leaf filename pr-body.md.

The blast radius is worse than a mis-push. A mis-pushed branch is usually caught by the next step. A clobbered PR body gets posted, looks plausible, and carries the other PR's closing keyword — so merging it would auto-close an issue this PR never touched, which is the #1259 class arriving through a new door.

What the lane did about it

Recomposed into a lane-keyed filename and added a sentinel assert before posting: the body must contain this PR's own Fixes #N or the post is refused. That is a per-lane workaround, not a fix — the next lane will not know to do it.

Pointers

• claude-plugins/kampus-pipeline/skills/write-code/SKILL.md — the live-derivation rule and the §SP progress-comment note, both of which name this class
• claude-plugins/kampus-pipeline/skills/gh-issue-intake-formats.md §SP — the per-run scratchpad namespace contract
• write-code caches branch name in a /tmp scratchpad shared across concurrent lanes → cross-lane push clobber #2038 (branch name clobbered, pushed to a sibling's ref), Concurrent reviewer agents collide on shared scratchpad filenames — a diff silently returned the WRONG PR's files #3718 (reviewer diffed the wrong PR) — the same class
• fix(ci): run the Step 0 class-parity harness, and make it able to fail (#4744) #4997 — the PR whose body was nearly overwritten

Suggested next step (non-binding)

Reporter's guess, triage's call. Two directions, not exclusive:

1. Make the leaf name carry the lane, not just the directory — the collision was on pr-body.md, not on the namespace above it.
2. Make the read-back assert ownership. A composed artifact destined for a gh write can carry a sentinel the writer checks before posting (its own issue/PR number). That turns a silent wrong-content post into a refusal, which is the fail-closed direction the rest of the pipeline takes.

Worth asking and deliberately not answered here: why the session-keyed path collided at all. If two lanes genuinely resolved the same scratch root, the namespacing has a hole worth finding rather than papering over with longer filenames.

---

_{Filed by an agent · session fcd74bd3-8872-4023-b100-a81ac870eb43 · branch usirin/wire-step0-class-parity-ci-4744-2D37ADA1 · 2026-08-09T03:09:31Z}

[usirin]

Re-banded p1 → p0 — the backstop that justified p1 is proven inert

What changed. This issue's p1 rested on two arguments, and tonight's triage of #5000 falsified both at source.

Argument 1 — "no false gate PASS here." The clobbered artifact is a gate input. A PR body carries Fixes #N, and the merge acts on it. A body composed for one PR, read back carrying another PR's text and its closing keyword, wires a foreign Fixes onto a PR that never touched that issue — and merging then closes it silently (the #1259 class). This is not a cosmetic mix-up; it is an artifact attributed to the wrong run, acted on by a merge.

Argument 2 — "the allocator refuses loudly, so a lane would have been stopped." This is the one that no longer holds. #4692 recorded the backstop as "exit 4 — a loud refusal, not a clobber." Verified tonight: CLAUDE_CODE_SESSION_ID and CLAUDE_PID are pane-scoped, not run-scoped. Live owner stamps show one pane's namespace root holding 84 distinct triage-<N> namespaces all stamped with one identical pid, and a second root holding write-code-* stamps spanning 2026-07-26 → 2026-08-09, every one carrying the same (session, pid) pair.

So classifyOwnership returns "mine" for every sibling lane of the same pane, and the EEXIST re-enter branch then returns the namespace without clearing. The "byte-identical identity" case the module's own docblock records as the one pair the stamp cannot separate is the normal case, not a corner. The refusal never fires within a pane — at six concurrent lanes, that is the operating condition, not an edge.

Silent in every direction: the write succeeds, the read succeeds, the content is valid markdown, and no owner marker exists in the file. It crosses both concurrent cross-lane within one pane and sequential same-slug re-runs, since the re-enter branch deliberately does not clear.

One correction to the record while re-banding: the collision is not in the properly-allocated namespaces. Those did their job — the two lanes involved had separate directories under the same session key. The colliding file sits in the harness-provided session scratchpad, the directory the runtime injects into a prompt, which the allocation convention explicitly bans. #4875 and #4692 both named that surface as a hypothesis and carried it as unverified. It is now verified.

Same shape has already landed once as a merge-gate artifact — #3718, where a reviewer diffed the wrong PR.

The deeper ownership-stamp defect is filed separately as #5028 and is not folded in here: this issue is the clobber and its fix; that one is why the guard cannot tell two lanes apart.

Re-band applied by the intake desk. The #5000 triage surfaced it as a recommendation rather than mutating another issue's labels without authorization — the right call, and the band change is recorded here rather than made silently.

[usirin]

New instance + a measured fact that undercuts the assumed fix (reporter intake, not triage)

Filing as a comment rather than a new issue: this is the same observation this ticket already
covers. Two things it adds — a second live instance that closes one of this ticket's explicit
unverified gaps, and a measurement that the allocator-refusal remedy does not fire between
sibling lanes.

1. Second live instance — 2026-08-10, and the clobbered file was a commit message

A write-code repair lane on PR #5262 found its own scratchpad/commit-msg.txt replaced
mid-run by a different lane's commit message — an ADR-0252 message belonging to the
concurrent PR #5259 lane, first line
fix(decisions): make the decline threshold strict and ground its ordering key (#4766).

Harmless in this instance only because that lane's commit had already landed before the
overwrite. Had it read the file back after, it would have committed under another lane's
message: a PR whose commit text describes work it does not contain, and — since commit
messages carry closing keywords — a plausible route to closing the wrong issue. Silent by
construction, same as the rest of this class: no error, a well-formed file, wrong contents.

This closes this ticket's unverified gap about which surface the collision lands on. The
body says "The report does not name the concrete directory its three artifacts were written
to ... carried as unverified." Here it is verifiable: the file sits in the runtime-provided
session scratchpad directory, the surface §SP already carves out
(claude-plugins/kampus-pipeline/skills/gh-issue-intake-formats.md, §SP "The harness-provided
'scratchpad directory' is NOT this namespace"). That directory is keyed on the session id, and
tonight's instance of it holds ~150 files written by many different lanes across ~3 hours.
Also worth noting commit-msg.txt is an invented intermediate: no skill prescribes it, so
it lands squarely in this ticket's category 2 ("nothing binds the intermediates an agent
invents mid-run to §SP at all").

2. The owner stamp cannot separate sibling lanes — session id AND pid are lane-invariant

This ticket's remedy for category 1 leans on the allocator refusing: "There the allocator
would refuse; the hand-rolled path silently re-enters and clobbers." Measured on a live
kampus-run tree tonight, that refusal cannot fire between siblings of one crew run.

classifyOwnership calls a stamp foreign only when the session id or the pid differs
(packages/pipeline-cli/src/tools/scratchpad/scratchpad.ts). Reading every
.kampus-run-owner written tonight, each crew run produced exactly one (session, pid)
pair shared by all of its lanes:

• one run: 5 stamps, all session 13ec3e8d… / pid 29336, opened across ~2 h under slugs
  belonging to different lanes;
• another run: 13 stamps, all session 903fddc5… / pid 58293, likewise across ~2.5 h;
• different crew runs do get different pairs.

One session-id directory in that tree holds 18 slug namespaces from clearly different lanes
(write-code-4735, write-code-repair-5259, write-code-repair-5262, review-doc-cp,
review-code-bundle, …).

So sibling lanes are exactly the byte-identical identity case the source treats as a
degenerate edge — "two runs whose identity is byte-identical (same session id AND same
$CLAUDE_PID, or neither carrying one) — nothing in the environment distinguishes them, so the
loser re-enters" (scratchpad.ts; same text in §SP). Under crew runs that is not the edge
case, it is the normal case. Consequences worth someone checking:

• The source comment on RunIdentity — session id is "distinct per agent run (sibling
  subagents of one pane each get their own)" — does not hold for these runs, and §SP's prose
  repeats the same claim.
• With the stamp inert between siblings, uniqueness rests entirely on the slug. Slugs
  without a work item are in live use (review-doc-cp, review-code-bundle), and repeat
  rounds over one PR share a slug. Same slug + same identity ⇒ non-destructive re-entry, then
  both lanes write the same leaf name — the original clobber, inside the fix.
• The no-CLI fallback is worse: kp_sp_open_fallback
  (claude-plugins/kampus-pipeline/skills/shared/scripts/scratchpad.sh) writes no stamp
  and does rm -rf "$RUN_SCRATCH" on open, so a same-slug sibling deletes the other's state
  outright. 298 of 1071 namespaces in that tree carry no stamp, so that arm is in live use.

On #3718

Reporter's read, triage decides: this looks like genuinely the same defect recurring inside
its own fix, not a rhyme. #3718 was "shared mutable surface under a non-unique name"; the fix
made the name unique by keying on $CLAUDE_CODE_SESSION_ID (+ $CLAUDE_PID in the stamp).
The measurement above says both are constant across sibling lanes of one crew run, so the fix's
uniqueness key is not per-lane and #3718's condition is reproduced between siblings.

Suggested direction (non-binding)

Key the namespace and the owner stamp on a per-lane / per-spawned-agent identity rather
than the session id, so siblings cannot alias at all. The alternative worth weighing is keeping
the shared namespace and forcing lane-unique leaf names — weaker, since it re-imports the
"every new write must remember the convention" failure mode §SP was written to remove. Either
way the RunIdentity doc comment and §SP's "sibling subagents each get their own" line should
be corrected or re-verified, since other reasoning rests on them.

---

_{Filed by an agent · session 13ec3e8d-d9a3-4656-8f2e-a2babcb4251c · branch worktree-agent-a2d54c07856139baf · 2026-08-10T03:17:45Z}

[usirin]

New first-hand instance — 2026-08-10, two build lanes of one session (#5023 / PR #5341)

Adding a fresh occurrence of exactly the shape this issue tracks (PR-body draft + progress note clobbered mid-run between concurrent build lanes). Instance data only — no classification, no re-labelling, no edit to the issue body.

What happened. Two build lanes running concurrently in the same crew session shared one session-keyed scratchpad directory, and one lane overwrote the other's files while it was still using them:

• <run-scratchpad>/pr-body.md and <run-scratchpad>/progress.md were both overwritten with a different lane's content (the map group's) while the Implement the grilling contract's verbs in packages/fabrika-cli/ #5023 lane was still working from them.
• The clobbering lane was Implement the wayfinding contract's verbs in packages/fabrika-cli/ #5022 (wayfinding verbs), running concurrently under the same session id.

Outcome: no damage — but only because the agent re-verified. It re-read PR #5341's posted body and its posted progress comment, confirmed both were its own, and moved its remaining files to distinct paths. Had it not checked, one lane could have posted the other lane's PR body or progress text. Same as this issue's original report: the clean outcome came from timing nobody controls, not from a guard.

What this instance adds. The general shape, stated plainly: the §SP namespace is keyed per session, while the unit of concurrent work is the lane. Any session running more than one lane at a time has lanes sharing one directory. Two lanes is the ordinary case under a WIP cap above 1 — not an edge case. Same identity question #4516 tracks, and it is why the "prescribed progress.md under write-code-<N>" half does not cover the improvised-artifact half: both lanes here were write-code lanes in one session.

Pointers

• This instance: issue Implement the grilling contract's verbs in packages/fabrika-cli/ #5023, PR feat(fabrika): implement the grilling contract's five verbs in packages/fabrika-cli (#5023) #5341; concurrent lane on issue Implement the wayfinding contract's verbs in packages/fabrika-cli/ #5022.
• Affected artifacts: the PR-body draft and the progress note in the run scratchpad — the two named in this issue's original report.
• Related: Per-run scratch namespace's session key is shared across lanes and roles #4516 (lane vs session identity for the §SP key), pipeline: two coder lanes wrote the same scratch file and one silently clobbered the other's PR body #5339 (same shape reported 2026-08-10 on PR fix(fabrika): delete the browser-provisioning CI skip and cache the browser instead (#5169) #5336), Unkeyed scratchpad filename let a lane commit another lane's commit message #4692 (broader class carrier).

Non-binding note. Nothing new proposed — this issue's acceptance criteria already cover the fix surface. Recording the recurrence so the rate under rising concurrency is visible: at least the second same-shape occurrence reported on 2026-08-10 alone.

[usirin]

Cross-link from triage of #5339 — a second, independently-observed instance of this class, with one detail that may bear on the fix premise.

#5339 reports a pr-body.md clobbered between two concurrent lanes on 2026-08-10 (PR #5336 / issue #5169 vs. the #4736 lane, PR #5337 seven minutes later). That is exactly the "PR-body draft" artifact this ticket already names, and exactly the wrong-Fixes #N outcome it already prices — so on the face of it, it is this issue happening again.

The one detail that is not covered here: the reporter states the scratch root was "keyed on my claim token", i.e. the fabrika build scratch shape (<tmp>/fabrika-build/<session>/<issue>-<claim-nonce>/<slug>), not the v1 session-keyed shape — and says another lane still landed in it. He explicitly does not assert the cause (namespace vs. filename), and the clobber is not verifiable from the board, so this is carried as his first-hand observation, not as confirmed fact.

If that detail holds, the claim-nonce keying this ticket's fix leans on has a hole, and the fix as scoped would not close it. #5339 is triaged type:investigation / p1 in this same campaign to settle that one fork; its first acceptance criterion is attributing the clobber to either a non-allocated path (⇒ this ticket covers it, fold #5339 in as a confirming incident) or a genuine per-lane-keyed collision (⇒ this ticket's premise needs revisiting).

No change requested here — flagging so whoever implements this reads #5339's answer first.