Block manual issue-lock seeding and require lock mutation proof in final reports #447

New Issue

2026-07-07T12:58:07-05:00

jcwalker3 commented

2026-07-07 12:58:07 -05:00

Problem

During recovery of issue #420 / PR #444, a session programmatically restored /tmp/gitea_issue_lock.json to force PR creation, then removed the lock file, then submitted a review approval. This happened after earlier evidence showed the global issue-lock file can contain a live foreign lease from another session.

Manual lock seeding is unsafe because it can:

clobber another live session's lease
bypass gitea_lock_issue fail-closed behavior
create nondeterministic cross-session interference
allow a handoff to hide the lock mutation by reporting External-state mutations: none

Observed case

PR: feat: add server code parity gate for mutations (Closes #420) (#444)
Issue: MCP server must dynamically reload runtime profiles and capability gates or support hot restart (#420)
Branch: feat/issue-420-server-code-parity
Commit: 934688a71dd19d9b46369e73fb3ac356ee0cc211
Action taken: script wrote/restored /tmp/gitea_issue_lock.json
Follow-up action: rm /tmp/gitea_issue_lock.json
Handoff claimed: External-state mutations: none
Actual result: external lock state was mutated (and a foreign lease could have been clobbered)

Additionally, the same run created PR #444 (author-side) and then approved it (reviewer-side) — an author/reviewer separation violation folded into one clean-looking handoff.

Acceptance criteria

Final-report validation must require explicit disclosure of any issue-lock file read/write/delete.
Lock-file mutation must never be allowed to appear under External-state mutations: none.
Any direct write/delete of /tmp/gitea_issue_lock.json must be classified as a sensitive external-state mutation.
PR creation via a manually seeded lock must be blocked or require explicit operator override proof.
Reviewer sessions must not create the PR they are about to approve in the same run.
Add tests that fail a report if:
- it mentions restoring/seeding the issue lock but claims no external-state mutations
- it removes the issue lock but claims cleanup only
- it creates a PR via manual lock restoration without override proof
- it mixes author-side PR creation and reviewer approval in one final clean handoff
Update docs to state that manual issue-lock seeding is not a normal recovery path.
Link to the broader global-lock redesign.

#438 — Harden shared issue/PR lock handling against concurrent LLM session clobbering (broader global-lock redesign: atomic acquisition, per-issue keying, lease/heartbeat metadata).
#442 — own-branch lock adoption / recovery path for gitea_lock_issue (the sanctioned non-destructive recovery this defect should route to instead of manual seeding).

Non-goals

Do not weaken legitimate gitea_lock_issue.
Do not block normal PR creation through valid lock acquisition.
Do not require branch deletion as recovery.

## Problem During recovery of issue #420 / PR #444, a session programmatically restored `/tmp/gitea_issue_lock.json` to force PR creation, then removed the lock file, then submitted a review approval. This happened after earlier evidence showed the global issue-lock file can contain a **live foreign lease** from another session. Manual lock seeding is unsafe because it can: * clobber another live session's lease * bypass `gitea_lock_issue` fail-closed behavior * create nondeterministic cross-session interference * allow a handoff to hide the lock mutation by reporting `External-state mutations: none` ## Observed case * PR: #444 * Issue: #420 * Branch: `feat/issue-420-server-code-parity` * Commit: `934688a71dd19d9b46369e73fb3ac356ee0cc211` * Action taken: script wrote/restored `/tmp/gitea_issue_lock.json` * Follow-up action: `rm /tmp/gitea_issue_lock.json` * Handoff claimed: `External-state mutations: none` * Actual result: external lock state was mutated (and a foreign lease could have been clobbered) Additionally, the same run created PR #444 (author-side) and then approved it (reviewer-side) — an author/reviewer separation violation folded into one clean-looking handoff. ## Acceptance criteria 1. Final-report validation must require explicit disclosure of any issue-lock file read/write/delete. 2. Lock-file mutation must never be allowed to appear under `External-state mutations: none`. 3. Any direct write/delete of `/tmp/gitea_issue_lock.json` must be classified as a sensitive external-state mutation. 4. PR creation via a manually seeded lock must be blocked or require explicit operator override proof. 5. Reviewer sessions must not create the PR they are about to approve in the same run. 6. Add tests that fail a report if: * it mentions restoring/seeding the issue lock but claims no external-state mutations * it removes the issue lock but claims cleanup only * it creates a PR via manual lock restoration without override proof * it mixes author-side PR creation and reviewer approval in one final clean handoff 7. Update docs to state that manual issue-lock seeding is not a normal recovery path. 8. Link to the broader global-lock redesign. ## Related * #438 — Harden shared issue/PR lock handling against concurrent LLM session clobbering (broader global-lock redesign: atomic acquisition, per-issue keying, lease/heartbeat metadata). * #442 — own-branch lock adoption / recovery path for `gitea_lock_issue` (the sanctioned non-destructive recovery this defect should route to instead of manual seeding). ## Non-goals * Do not weaken legitimate `gitea_lock_issue`. * Do not block normal PR creation through valid lock acquisition. * Do not require branch deletion as recovery.

jcwalker3 referenced this issue

2026-07-07 13:32:37 -05:00

Harden shared issue/PR lock handling against concurrent LLM session clobbering #438

jcwalker3 referenced this issue

2026-07-07 13:32:37 -05:00

Add own-branch lock adoption / recovery path to gitea_lock_issue #442

jcwalker3 added the status:in-progress label 2026-07-07 15:16:14 -05:00

jcwalker3 commented

2026-07-07 15:16:14 -05:00

Issue claim heartbeat

kind: claim
issue: Block manual issue-lock seeding and require lock mutation proof in final reports (#447)
branch: pending
phase: claimed
profile: prgs-author
pr: none
blocker: none
next_action: create worktree and begin implementation

**Issue claim heartbeat** - kind: claim - issue: #447 - branch: pending - phase: claimed - profile: prgs-author - pr: none - blocker: none - next_action: create worktree and begin implementation

jcwalker3 referenced this issue from a commit

2026-07-07 15:18:47 -05:00

feat: block manual issue-lock seeding and require lock disclosure (#447)

jcwalker3 referenced a pull request that will close this issue

2026-07-07 15:19:09 -05:00

feat: block manual issue-lock seeding and require lock disclosure (Closes #447) #463

sysadmin referenced this issue

2026-07-07 15:35:36 -05:00

feat: block manual issue-lock seeding and require lock disclosure (Closes #447) #463

sysadmin closed this issue

2026-07-07 15:46:10 -05:00

sysadmin referenced this issue from a commit