Issue-lock gate binds to the shared dev worktree, blocking all scratch-clone author sessions while any session is mid-branch #249

New Issue

2026-07-06T10:43:14-05:00

jcwalker3 commented

2026-07-06 10:43:14 -05:00

Problem

The #208 dogfood issue-lock gate (gitea_lock_issue → prerequisite for gitea_create_pr) validates lock preconditions against the MCP server process's working directory — the shared development worktree. Observed 2026-07-06:

Error executing tool gitea_lock_issue: tracked file edits exist before issue lock;
lock must precede implementation work; issue lock must be taken from base branch
(master/main), not 'feat/issue-243-forbidden-git-gaps' (fail closed)

The session attempting the lock (for issue #244) had a clean scratch clone ready and had never touched the shared worktree. The tracked edits and feature branch belonged to a different concurrent session working #243. Result: while any one session has the shared worktree on a feature branch, no other author session can lock any issue or open any PR, even though their work is fully isolated in scratch clones.

This contradicts the direction of the other walls:

#233 mandates scratch clones/worktrees for validation (shared worktree is explicitly not the place to work)
mcp-control-plane #91 forbids touching another session's claimed worktree — so the blocked session cannot "fix" the precondition without violating the interference wall
Cross-session parallelism is the observed norm (five external races on 2026-07-06 alone)

The gate's single-worktree assumption makes concurrent authoring serialize on a resource none of the sessions should be using for implementation in the first place.

Required behavior

gitea_lock_issue accepts an explicit worktree_path (or auto-detects from the caller's declared scratch clone) and validates that path's cleanliness/branch, not the MCP server CWD.
A lock taken from a clean scratch clone at master/main head is valid even when the shared dev worktree is dirty or on another session's branch.
The lock record stores which worktree path it was validated against, so the PR-creation gate can verify consistently.
Foreign state in the shared dev worktree must not block, and must not be mutated, by an unrelated session's lock attempt.

Acceptance criteria

Test: lock succeeds from a clean scratch clone while a (simulated) shared worktree is dirty on a foreign feature branch.
Test: lock still fails closed when the declared worktree itself has tracked edits or is not on base.
Test: PR-creation gate honors scratch-clone locks end to end.
Docs: llm-workflow runbook updated — lock from your own clean scratch clone, never manipulate the shared worktree to satisfy the gate.

Provenance

Blocked lock attempt for #244 while a concurrent session legitimately held the shared worktree on feat/issue-243-forbidden-git-gaps (dirty gitea_mcp_server.py). Related: #208 (lock gate), #233 (scratch-clone wall), #91 in mcp-control-plane (worktree ownership guard, PR #98 pending).

## Problem The #208 dogfood issue-lock gate (`gitea_lock_issue` → prerequisite for `gitea_create_pr`) validates lock preconditions against the **MCP server process's working directory** — the shared development worktree. Observed 2026-07-06: ``` Error executing tool gitea_lock_issue: tracked file edits exist before issue lock; lock must precede implementation work; issue lock must be taken from base branch (master/main), not 'feat/issue-243-forbidden-git-gaps' (fail closed) ``` The session attempting the lock (for issue #244) had a **clean scratch clone** ready and had never touched the shared worktree. The tracked edits and feature branch belonged to a *different* concurrent session working #243. Result: while any one session has the shared worktree on a feature branch, **no other author session can lock any issue or open any PR**, even though their work is fully isolated in scratch clones. This contradicts the direction of the other walls: - #233 mandates scratch clones/worktrees for validation (shared worktree is explicitly not the place to work) - mcp-control-plane #91 forbids touching another session's claimed worktree — so the blocked session cannot "fix" the precondition without violating the interference wall - Cross-session parallelism is the observed norm (five external races on 2026-07-06 alone) The gate's single-worktree assumption makes concurrent authoring serialize on a resource none of the sessions should be using for implementation in the first place. ## Required behavior 1. `gitea_lock_issue` accepts an explicit `worktree_path` (or auto-detects from the caller's declared scratch clone) and validates *that* path's cleanliness/branch, not the MCP server CWD. 2. A lock taken from a clean scratch clone at `master`/`main` head is valid even when the shared dev worktree is dirty or on another session's branch. 3. The lock record stores which worktree path it was validated against, so the PR-creation gate can verify consistently. 4. Foreign state in the shared dev worktree must not block, and must not be mutated, by an unrelated session's lock attempt. ## Acceptance criteria 1. Test: lock succeeds from a clean scratch clone while a (simulated) shared worktree is dirty on a foreign feature branch. 2. Test: lock still fails closed when the *declared* worktree itself has tracked edits or is not on base. 3. Test: PR-creation gate honors scratch-clone locks end to end. 4. Docs: llm-workflow runbook updated — lock from your own clean scratch clone, never manipulate the shared worktree to satisfy the gate. ## Provenance Blocked lock attempt for #244 while a concurrent session legitimately held the shared worktree on `feat/issue-243-forbidden-git-gaps` (dirty `gitea_mcp_server.py`). Related: #208 (lock gate), #233 (scratch-clone wall), #91 in mcp-control-plane (worktree ownership guard, PR #98 pending).

jcwalker3 referenced this issue

2026-07-06 10:43:30 -05:00

Review submissions land as PENDING drafts; merges proceed without a visible APPROVED verdict #244

jcwalker3 added the status:in-progress label 2026-07-06 10:45:16 -05:00

jcwalker3 referenced this issue from a commit

2026-07-06 10:46:50 -05:00

feat(mcp): bind issue lock to author scratch worktree (#249)

jcwalker3 commented

2026-07-06 10:46:52 -05:00

Scope update: the gate blocks cross-repo, not just Gitea-Tools work. A lock attempt for mcp-control-plane issue #76 (branch docs/issue-76-acceptance-matrix) failed with:

issue lock must be taken from base branch (master/main), not 'feat/issue-188-continuation-selection-wall' (fail closed)

feat/issue-188-continuation-selection-wall is a Gitea-Tools branch held by a concurrent session in the shared dev worktree — the MCP server's CWD — yet it vetoes a lock targeting a different repository whose own worktree is clean on master. Two lock attempts blocked tonight (#244 at ~02:00 by the #243 session's branch, #76 at ~10:45 by the #188 session's branch): while any session is mid-branch in the shared Gitea-Tools worktree, no other session can lock any issue in any repo.

Fix should additionally scope the validated worktree to the target repo of the lock (issue's org/repo), not the server process CWD.

Scope update: the gate blocks **cross-repo**, not just Gitea-Tools work. A lock attempt for `mcp-control-plane` issue #76 (branch `docs/issue-76-acceptance-matrix`) failed with: ``` issue lock must be taken from base branch (master/main), not 'feat/issue-188-continuation-selection-wall' (fail closed) ``` `feat/issue-188-continuation-selection-wall` is a **Gitea-Tools** branch held by a concurrent session in the shared dev worktree — the MCP server's CWD — yet it vetoes a lock targeting a different repository whose own worktree is clean on master. Two lock attempts blocked tonight (#244 at ~02:00 by the #243 session's branch, #76 at ~10:45 by the #188 session's branch): while any session is mid-branch in the shared Gitea-Tools worktree, no other session can lock **any issue in any repo**. Fix should additionally scope the validated worktree to the **target repo** of the lock (issue's org/repo), not the server process CWD.

jcwalker3 referenced a pull request that will close this issue

2026-07-06 10:47:26 -05:00

feat(mcp): bind issue lock to author scratch worktree (closes #249) #250

jcwalker3 commented

2026-07-06 10:47:30 -05:00

Claimed and implemented on feat/issue-249-issue-lock-scratch-worktree.

PR #250 adds worktree_path / GITEA_AUTHOR_WORKTREE support so issue locks validate the author's scratch clone instead of the shared MCP CWD.

Claimed and implemented on `feat/issue-249-issue-lock-scratch-worktree`. PR #250 adds `worktree_path` / `GITEA_AUTHOR_WORKTREE` support so issue locks validate the author's scratch clone instead of the shared MCP CWD.

jcwalker3 referenced this issue

2026-07-06 10:54:44 -05:00

Pre-flight order gate counts foreign workspace edits and sticks after fresh whoami, blocking legitimate review submissions #252

sysadmin referenced this issue

2026-07-06 11:14:39 -05:00

feat(mcp): bind issue lock to author scratch worktree (closes #249) #250

sysadmin referenced a pull request that will close this issue

2026-07-06 11:24:29 -05:00

feat(mcp): bind issue lock to author scratch worktree (closes #249) #250

sysadmin referenced this issue

2026-07-06 11:24:35 -05:00

feat(mcp): bind issue lock to author scratch worktree (closes #249) #250