fix(gate): preserve exact-owner renewal evidence across owning-PR duplicate rechecks #945

New Issue

2026-07-26T09:35:47-05:00

jcwalker3 commented

2026-07-26 09:35:47 -05:00

Summary

The exact-owner owning-PR waiver produced during sanctioned issue-lock renewal is recognized inside gitea_lock_issue but is not propagated to the shared duplicate recheck used by later author mutations.

As a result, a legitimate author repairing an existing owning PR can renew the issue lock successfully but still be blocked from committing, pushing, or updating the PR with:

outcome: duplicate_commit_prevented
owning_pr_recovery_exempted: false
owning_pr_recovery_notes: []

This creates a workflow deadlock when the repair is already present as uncommitted changes:

Commit is blocked by the missing owning-PR exemption.
Author comments and handoff mutations are blocked by the dirty-workspace binding.
Clearing the dirty state would require destroying, moving, or bypassing the completed repair.

Observed case

The defect was reproduced while addressing review 622 on:

Issue: fix(author bootstrap): restore missing runtime identity and session helpers (#943)
PR: fix(author bootstrap): restore missing runtime identity and session helpers (Closes #943) (#944)
Reviewed PR head: f49e781102b9f363834c28c055f69639d16290c9
Base/master: aab54d4825270f5a5c6f9c1abc1ab09eb4f3e218
Branch/worktree: fix/issue-943-runtime-context-helpers / issue-943-runtime-context-helpers
Author: jcwalker3
Profile: prgs-author

The exact owner renewed the issue lock through the sanctioned author workflow. Renewal produced canonical owning-PR evidence showing:

pr_number=944
Matching issue and branch
local_head == remote_head == recorded_head == accepted_head == pr_head
All head values equal the reviewed PR head
head_relation=equal
Matching identity and profile
Exact lock ownership

Despite that evidence, the read-only commit assessor and gitea_commit_files both refused the commit because the shared duplicate recheck reported no owning-PR recovery exemption.

Root cause

issue_lock_renewal.owning_pr_renewal_evidence constructs the owning-PR waiver for a sanctioned exact-owner renewal.

That evidence is consumed during gitea_lock_issue, but _enforce_locked_issue_duplicate_recheck, shared by subsequent commit/push/PR gates, derives its exemption only from recovered_owning_pr_from_lock.

That recovery path reads dead_session_recovery evidence but not the canonical lease_renewal evidence persisted by an ordinary exact-owner renewal.

The waiver therefore exists during renewal and disappears before the next author mutation.

This resembles the wiring class exposed by #941: the decision logic exists, but not every enforcement path receives its result.

Impact

A valid author cannot update an already-open owning PR after an exact-owner lock renewal.
Commit, push, and related PR-update paths can fail closed despite complete matching evidence.
A dirty repair worktree can become trapped because committing is refused while other Gitea mutations are rejected by workspace-integrity enforcement.
PR #944 currently has a completed and tested repair that cannot be delivered through the sanctioned author path.
Working around the gate would weaken auditability and workflow safety.

Expected behavior

The shared owning-PR duplicate recheck must recognize canonical exact-owner renewal evidence wherever the same exemption is supposed to apply.

It must permit continuation only when the existing open PR is conclusively the current issue's owning PR and all ownership, branch, head, identity, profile, repository, and session bindings match.

It must continue to fail closed for missing, stale, conflicting, expired, released, replaced, or unrelated evidence.

Acceptance criteria

Centralize or consistently propagate canonical owning-PR continuation evidence to every relevant enforcement path.
_enforce_locked_issue_duplicate_recheck recognizes valid exact-owner renewal evidence in addition to sanctioned dead-session recovery evidence.
The exemption is bound to the exact:
- Repository
- Issue
- Open PR
- Source branch
- Author identity
- Author profile
- Owning workflow/task session
- Assignment and lease where applicable
- Recorded, accepted, local, remote, and live PR heads
Valid exact-owner renewal permits the intended update of the existing owning PR.
It does not authorize creation of a second PR or unrelated commit.
Missing or ambiguous evidence fails closed.
Wrong issue, PR, branch, repository, identity, profile, or session fails closed.
Head divergence, force-push, stale recorded head, or unrelated remote movement fails closed or requires the canonical recovery flow.
Expired, released, replaced, or non-owning leases cannot produce an exemption.
Duplicate prevention remains enforced for genuinely duplicate or unrelated work.
Commit, push, and applicable PR-update gates use the same authoritative decision.
Structured refusal results preserve reason codes, retryability, transport survival, and audit evidence.
Regression tests cover both ordinary exact-owner renewal and dead-session recovery.
Tests reproduce the PR #944 failure before the fix and prove sanctioned continuation after the fix.
Tests prove no exemption is granted solely because an open PR exists.
Implementation is delivered in a separate issue branch and PR with independent review.
After merge, restart the MCP fleet at the resulting master revision and recommission the gate.
Preserve the uncommitted PR #944 repair until the deployed fix allows it to be committed and pushed normally.

Protected recovery state

Until this issue is fixed and deployed:

Preserve the dirty issue-943-runtime-context-helpers worktree exactly as-is.
Do not clean, reset, stash, relocate, or manually commit its repair.
Keep PR #944 open at f49e781102b9f363834c28c055f69639d16290c9.
Keep review 622 intact.
Keep PR #942 cleanup paused.
Keep issues #931 and #941 untouched.

Related work

#943 — missing author-bootstrap runtime/session helpers
PR #944 — completed repair currently blocked from delivery
Review 622 — requested changes addressed locally
#941 / PR #942 — earlier enforcement-path wiring defect and fix
#510 — dirty namespace/workspace mutation binding
#792 — terminal retirement/release capability remains open

## Summary The exact-owner owning-PR waiver produced during sanctioned issue-lock renewal is recognized inside `gitea_lock_issue` but is not propagated to the shared duplicate recheck used by later author mutations. As a result, a legitimate author repairing an existing owning PR can renew the issue lock successfully but still be blocked from committing, pushing, or updating the PR with: ```text outcome: duplicate_commit_prevented owning_pr_recovery_exempted: false owning_pr_recovery_notes: [] ``` This creates a workflow deadlock when the repair is already present as uncommitted changes: 1. Commit is blocked by the missing owning-PR exemption. 2. Author comments and handoff mutations are blocked by the dirty-workspace binding. 3. Clearing the dirty state would require destroying, moving, or bypassing the completed repair. ## Observed case The defect was reproduced while addressing review `622` on: * Issue: #943 * PR: #944 * Reviewed PR head: `f49e781102b9f363834c28c055f69639d16290c9` * Base/master: `aab54d4825270f5a5c6f9c1abc1ab09eb4f3e218` * Branch/worktree: `fix/issue-943-runtime-context-helpers` / `issue-943-runtime-context-helpers` * Author: `jcwalker3` * Profile: `prgs-author` The exact owner renewed the issue lock through the sanctioned author workflow. Renewal produced canonical owning-PR evidence showing: * `pr_number=944` * Matching issue and branch * `local_head == remote_head == recorded_head == accepted_head == pr_head` * All head values equal the reviewed PR head * `head_relation=equal` * Matching identity and profile * Exact lock ownership Despite that evidence, the read-only commit assessor and `gitea_commit_files` both refused the commit because the shared duplicate recheck reported no owning-PR recovery exemption. ## Root cause `issue_lock_renewal.owning_pr_renewal_evidence` constructs the owning-PR waiver for a sanctioned exact-owner renewal. That evidence is consumed during `gitea_lock_issue`, but `_enforce_locked_issue_duplicate_recheck`, shared by subsequent commit/push/PR gates, derives its exemption only from `recovered_owning_pr_from_lock`. That recovery path reads `dead_session_recovery` evidence but not the canonical `lease_renewal` evidence persisted by an ordinary exact-owner renewal. The waiver therefore exists during renewal and disappears before the next author mutation. This resembles the wiring class exposed by #941: the decision logic exists, but not every enforcement path receives its result. ## Impact * A valid author cannot update an already-open owning PR after an exact-owner lock renewal. * Commit, push, and related PR-update paths can fail closed despite complete matching evidence. * A dirty repair worktree can become trapped because committing is refused while other Gitea mutations are rejected by workspace-integrity enforcement. * PR #944 currently has a completed and tested repair that cannot be delivered through the sanctioned author path. * Working around the gate would weaken auditability and workflow safety. ## Expected behavior The shared owning-PR duplicate recheck must recognize canonical exact-owner renewal evidence wherever the same exemption is supposed to apply. It must permit continuation only when the existing open PR is conclusively the current issue's owning PR and all ownership, branch, head, identity, profile, repository, and session bindings match. It must continue to fail closed for missing, stale, conflicting, expired, released, replaced, or unrelated evidence. ## Acceptance criteria * Centralize or consistently propagate canonical owning-PR continuation evidence to every relevant enforcement path. * `_enforce_locked_issue_duplicate_recheck` recognizes valid exact-owner renewal evidence in addition to sanctioned dead-session recovery evidence. * The exemption is bound to the exact: * Repository * Issue * Open PR * Source branch * Author identity * Author profile * Owning workflow/task session * Assignment and lease where applicable * Recorded, accepted, local, remote, and live PR heads * Valid exact-owner renewal permits the intended update of the existing owning PR. * It does not authorize creation of a second PR or unrelated commit. * Missing or ambiguous evidence fails closed. * Wrong issue, PR, branch, repository, identity, profile, or session fails closed. * Head divergence, force-push, stale recorded head, or unrelated remote movement fails closed or requires the canonical recovery flow. * Expired, released, replaced, or non-owning leases cannot produce an exemption. * Duplicate prevention remains enforced for genuinely duplicate or unrelated work. * Commit, push, and applicable PR-update gates use the same authoritative decision. * Structured refusal results preserve reason codes, retryability, transport survival, and audit evidence. * Regression tests cover both ordinary exact-owner renewal and dead-session recovery. * Tests reproduce the PR #944 failure before the fix and prove sanctioned continuation after the fix. * Tests prove no exemption is granted solely because an open PR exists. * Implementation is delivered in a separate issue branch and PR with independent review. * After merge, restart the MCP fleet at the resulting master revision and recommission the gate. * Preserve the uncommitted PR #944 repair until the deployed fix allows it to be committed and pushed normally. ## Protected recovery state Until this issue is fixed and deployed: * Preserve the dirty `issue-943-runtime-context-helpers` worktree exactly as-is. * Do not clean, reset, stash, relocate, or manually commit its repair. * Keep PR #944 open at `f49e781102b9f363834c28c055f69639d16290c9`. * Keep review `622` intact. * Keep PR #942 cleanup paused. * Keep issues #931 and #941 untouched. ## Related work * #943 — missing author-bootstrap runtime/session helpers * PR #944 — completed repair currently blocked from delivery * Review `622` — requested changes addressed locally * #941 / PR #942 — earlier enforcement-path wiring defect and fix * #510 — dirty namespace/workspace mutation binding * #792 — terminal retirement/release capability remains open

jcwalker3 added the mcp reliability status:ready workflow-hardening leases recovery preflight safety type:bug labels 2026-07-26 09:35:47 -05:00

jcwalker3 referenced this issue from a commit

2026-07-26 10:42:46 -05:00

fix(gate): preserve exact-owner renewal evidence across duplicate rechecks (Closes #945)

jcwalker3 referenced a pull request that will close this issue

2026-07-26 10:49:44 -05:00

fix(gate): preserve exact-owner renewal evidence across duplicate rechecks (Closes #945) #946

jcwalker3 added status:pr-open and removed status:ready labels 2026-07-26 10:49:44 -05:00

sysadmin referenced this issue

2026-07-26 14:11:45 -05:00

fix(gate): preserve exact-owner renewal evidence across duplicate rechecks (Closes #945) #946

sysadmin referenced this issue

2026-07-26 14:25:08 -05:00

fix(gate): preserve exact-owner renewal evidence across duplicate rechecks (Closes #945) #946

sysadmin referenced this issue

2026-07-26 14:26:22 -05:00

fix(gate): preserve exact-owner renewal evidence across duplicate rechecks (Closes #945) #946

sysadmin commented

2026-07-26 14:29:55 -05:00

[THREAD STATE LEDGER]

What is true now

PR #946 implements #945 and is open at head 79334d48408fd446ddf1e8be332495960b847af6, whose parent equals live master at aab54d4825270f5a5c6f9c1abc1ab09eb4f3e218, so there is no base drift. It carries one formal REQUEST_CHANGES review, review 623, posted by sysadmin at that exact head and undismissed. Scope is exactly three files at +593/−7.

Server-side decision state: REQUEST_CHANGES recorded as review 623 at head 79334d48408fd446ddf1e8be332495960b847af6; has_blocking_change_requests true; approval_at_current_head false; PR state open, not integrated into master.
Local verdict/state: REQUEST_CHANGES, recorded on the server as review 623 and re-read back at the same head; review complete, reviewer lease released.

What changed

A full independent review ran at the exact head from isolated reviewer worktrees under branches/. The implementation was verified correct: the renewal evidence rebuild, the shared resolver, recovery-first precedence matching the lock path, and the rewiring of all three enforcement paths. The branch introduces no test regression — failing test id sets are identical at head and at a clean base worktree. One blocking finding was established by experiment rather than by inspection, and review 623 was posted at the reviewed head. The reviewer changed no repository code; the throwaway probe worktree used to demonstrate the finding was removed.

What is blocked

Integration of PR #946 into master is blocked. It holds no approval at its current head, and an undismissed REQUEST_CHANGES stands.

Blocker classification: code blocker.

B1 (blocker) — the wiring #945 exists to install has no regression coverage. tests/test_issue_945_owning_pr_renewal_continuation.py exercises the new helpers and the duplicate gate directly but never drives _enforce_locked_issue_duplicate_recheck, gitea_assess_work_issue_duplicate, _prove_author_ownership_for_pr, gitea_commit_files, or gitea_create_pr. Reverting the primary wiring at gitea_mcp_server.py:2894 to the recovery-only rebuild — which reintroduces this issue's exact defect — left the new suite at 49 passed and the full suite byte-identical to the PR's own result. No test in the repository detects it.

F2 (medium) — the new claimant check compares two fields inside the same lock file and is not bound to the authenticated caller; real cross-session binding comes from read_session_issue_lock() keying on session-{os.getpid()}.json.

F3 (minor) — _owning_pr_continuation_from_lock falls through to renewal when a recovery block is present but fails validation, even when the two name different PRs. Unreachable through the sanctioned writer, since gitea_lock_issue rebuilds its record per call.

Who/what acts next

Next actor: author jcwalker3 on PR #946, in the gitea-author namespace under profile prgs-author.
Required action: address review 623 at a new head, then obtain a fresh independent review at that new head.

Do not do:

Do not integrate PR #946 into master. It holds no approval at its current head.
Do not approve or dismiss review 623, and do not self-review the remediation.
Do not touch, stash, reset, clean, commit, or rebind the dirty issue-943-runtime-context-helpers worktree.
Do not modify PR #944 or review 622.
Do not clean up PR #942 or its worktrees and branches.
Do not modify issues #931 or #941.
Do not restart or reconnect the MCP fleet, and do not commission the new behaviour until the fix lands on master and the fleet is restarted at that revision.

Canonical Issue State

STATE: changes-requested

WHO_IS_NEXT: author

NEXT_ACTION: Author jcwalker3 must address review 623 on PR #946 — add regression coverage that drives the real enforcement paths with a renewal-bearing lock so that reverting gitea_mcp_server.py:2894, :5179, or :19464 fails a test (B1), correct or strengthen the caller-binding claim (F2), optionally make the conflicting-evidence guarantee explicit (F3), push to a new head, and publish a head-pinned handoff for a fresh independent review.

NEXT_PROMPT:

Address the REQUEST_CHANGES review 623 on PR #946 (Closes #945) in
Scaled-Tech-Consulting/Gitea-Tools on remote prgs.

Invoke the canonical gitea-workflow skill first. Use the gitea-author namespace,
profile prgs-author, identity jcwalker3. Reviewed head was
79334d48408fd446ddf1e8be332495960b847af6; base aab54d4825270f5a5c6f9c1abc1ab09eb4f3e218.

B1 (blocker): tests/test_issue_945_owning_pr_renewal_continuation.py never drives
an enforcement path, so reverting gitea_mcp_server.py:2894 to
issue_lock_recovery.recovered_owning_pr_from_lock leaves the full suite byte
identical (28F/5574P/6S/1002 subtests, same failing ids). Add coverage that
drives the real commit/create-PR duplicate recheck with a renewal-bearing lock
and asserts the exemption is granted; confirm it fails with :2894 reverted and
passes restored. Follow tests/test_issue_755_owning_pr_recovery.py, which drives
the real MCP handler for the recovery half. Cover the read-only assessor (:5179)
and push prover (:19464) too.

F2 (medium): the claimant check in issue_lock_renewal.owning_pr_renewal_from_lock
compares two fields inside the same lock file and is not bound to the
authenticated caller. Real cross-session binding comes from
read_session_issue_lock() keying on session-{os.getpid()}.json. Either correct
the PR body claim or compare against the live identity/profile the way
record_mutation_authority does.

F3 (minor): _owning_pr_continuation_from_lock falls through to renewal when a
recovery block is present but fails validation, even when the two name different
PRs. Unreachable through gitea_lock_issue because data is rebuilt per call, but
make that guarantee explicit rather than implicit.

Re-run the #945 suite, the targeted renewal/recovery/duplicate-gate suites, and
the full suite from a branches/ worktree, comparing failing test ids against a
clean base worktree.

Do not integrate this PR into master. Do not review your own work. Preserve the
uncommitted #943 repair, keep PR #942 cleanup paused, and leave issues #931 and
#941 untouched.

WHAT_HAPPENED: An independent review at the exact head read all three changed files, traced the evidence flow from owning_pr_renewal_evidence through the new rebuild, the shared resolver, and all three enforcement paths into issue_work_duplicate_gate._assess_owning_pr_exemption, and probed precedence and fall-through behaviour directly against the patched modules. The wiring, precedence and fail-closed matrix are correct. Reverting the primary wiring in a throwaway worktree at the same head left the new suite at 49 passed and the full suite byte identical to the PR's own result, proving no test protects the fix. Targeted and full suites ran at head and at a clean base worktree; failing test id sets are identical. Review 623 was posted at head 79334d4840 and the reviewer lease was released.

WHY: #945 exists because a correct decision layer was never wired into the paths that enforce it. PR #946 wires it correctly but ships no test that fails if the wiring is removed, so the same class of defect can silently return. The sibling recovery suite for #755 already drives the real MCP handler for exactly this reason, so the bar is established in this repository.

RELATED_PRS: #946 (open, head 79334d4840, REQUEST_CHANGES review 623)

BLOCKERS: code blocker

VALIDATION: New #945 suite at head: 49 passed, 8 subtests. Targeted 24-file sweep at head: 1 failed, 514 passed, 32 subtests in 32.49s; at clean base worktree aab54d48: 1 failed, 465 passed, 24 subtests in 32.13s; the single failure test_pidless_durable_lock_rejected reproduces on base in isolation. Full suite at head: 28 failed, 5574 passed, 6 skipped, 1002 subtests in 149.90s. Full suite at base: 28 failed, 5525 passed, 6 skipped, 994 subtests in 148.91s. Failing test id sets identical, so no regression originates from this branch. Wiring-revert probe at the same head: new suite 49 passed, full suite 28 failed / 5574 passed with an identical failing id set, demonstrating the absent coverage. Base reproduction of the new suite fails with AttributeError at call time on both new symbols, 0 collection or fixture errors. Parity at review time: live_stale false, restart_required false, mutation_safe true; live master aab54d4825 equals the PR head parent.

LAST_UPDATED_BY: sysadmin / prgs-reviewer / gitea-reviewer namespace, reviewer lease session 93257-9ba6b15dd243

[THREAD STATE LEDGER] ### What is true now PR #946 implements #945 and is open at head `79334d48408fd446ddf1e8be332495960b847af6`, whose parent equals live `master` at `aab54d4825270f5a5c6f9c1abc1ab09eb4f3e218`, so there is no base drift. It carries one formal REQUEST_CHANGES review, review `623`, posted by `sysadmin` at that exact head and undismissed. Scope is exactly three files at `+593/−7`. - Server-side decision state: REQUEST_CHANGES recorded as review `623` at head `79334d48408fd446ddf1e8be332495960b847af6`; `has_blocking_change_requests` true; `approval_at_current_head` false; PR state open, not integrated into `master`. - Local verdict/state: REQUEST_CHANGES, recorded on the server as review `623` and re-read back at the same head; review complete, reviewer lease released. ### What changed A full independent review ran at the exact head from isolated reviewer worktrees under `branches/`. The implementation was verified correct: the renewal evidence rebuild, the shared resolver, recovery-first precedence matching the lock path, and the rewiring of all three enforcement paths. The branch introduces no test regression — failing test id sets are identical at head and at a clean base worktree. One blocking finding was established by experiment rather than by inspection, and review `623` was posted at the reviewed head. The reviewer changed no repository code; the throwaway probe worktree used to demonstrate the finding was removed. ### What is blocked Integration of PR #946 into `master` is blocked. It holds no approval at its current head, and an undismissed REQUEST_CHANGES stands. - Blocker classification: code blocker. **B1 (blocker)** — the wiring #945 exists to install has no regression coverage. `tests/test_issue_945_owning_pr_renewal_continuation.py` exercises the new helpers and the duplicate gate directly but never drives `_enforce_locked_issue_duplicate_recheck`, `gitea_assess_work_issue_duplicate`, `_prove_author_ownership_for_pr`, `gitea_commit_files`, or `gitea_create_pr`. Reverting the primary wiring at `gitea_mcp_server.py:2894` to the recovery-only rebuild — which reintroduces this issue's exact defect — left the new suite at 49 passed and the full suite byte-identical to the PR's own result. No test in the repository detects it. **F2 (medium)** — the new claimant check compares two fields inside the same lock file and is not bound to the authenticated caller; real cross-session binding comes from `read_session_issue_lock()` keying on `session-{os.getpid()}.json`. **F3 (minor)** — `_owning_pr_continuation_from_lock` falls through to renewal when a recovery block is present but fails validation, even when the two name different PRs. Unreachable through the sanctioned writer, since `gitea_lock_issue` rebuilds its record per call. ### Who/what acts next - Next actor: author `jcwalker3` on PR #946, in the `gitea-author` namespace under profile `prgs-author`. - Required action: address review `623` at a new head, then obtain a fresh independent review at that new head. **Do not do:** - Do not integrate PR #946 into `master`. It holds no approval at its current head. - Do not approve or dismiss review `623`, and do not self-review the remediation. - Do not touch, stash, reset, clean, commit, or rebind the dirty `issue-943-runtime-context-helpers` worktree. - Do not modify PR #944 or review `622`. - Do not clean up PR #942 or its worktrees and branches. - Do not modify issues #931 or #941. - Do not restart or reconnect the MCP fleet, and do not commission the new behaviour until the fix lands on `master` and the fleet is restarted at that revision. ## Canonical Issue State STATE: changes-requested WHO_IS_NEXT: author NEXT_ACTION: Author jcwalker3 must address review 623 on PR #946 — add regression coverage that drives the real enforcement paths with a renewal-bearing lock so that reverting gitea_mcp_server.py:2894, :5179, or :19464 fails a test (B1), correct or strengthen the caller-binding claim (F2), optionally make the conflicting-evidence guarantee explicit (F3), push to a new head, and publish a head-pinned handoff for a fresh independent review. NEXT_PROMPT: ```text Address the REQUEST_CHANGES review 623 on PR #946 (Closes #945) in Scaled-Tech-Consulting/Gitea-Tools on remote prgs. Invoke the canonical gitea-workflow skill first. Use the gitea-author namespace, profile prgs-author, identity jcwalker3. Reviewed head was 79334d48408fd446ddf1e8be332495960b847af6; base aab54d4825270f5a5c6f9c1abc1ab09eb4f3e218. B1 (blocker): tests/test_issue_945_owning_pr_renewal_continuation.py never drives an enforcement path, so reverting gitea_mcp_server.py:2894 to issue_lock_recovery.recovered_owning_pr_from_lock leaves the full suite byte identical (28F/5574P/6S/1002 subtests, same failing ids). Add coverage that drives the real commit/create-PR duplicate recheck with a renewal-bearing lock and asserts the exemption is granted; confirm it fails with :2894 reverted and passes restored. Follow tests/test_issue_755_owning_pr_recovery.py, which drives the real MCP handler for the recovery half. Cover the read-only assessor (:5179) and push prover (:19464) too. F2 (medium): the claimant check in issue_lock_renewal.owning_pr_renewal_from_lock compares two fields inside the same lock file and is not bound to the authenticated caller. Real cross-session binding comes from read_session_issue_lock() keying on session-{os.getpid()}.json. Either correct the PR body claim or compare against the live identity/profile the way record_mutation_authority does. F3 (minor): _owning_pr_continuation_from_lock falls through to renewal when a recovery block is present but fails validation, even when the two name different PRs. Unreachable through gitea_lock_issue because data is rebuilt per call, but make that guarantee explicit rather than implicit. Re-run the #945 suite, the targeted renewal/recovery/duplicate-gate suites, and the full suite from a branches/ worktree, comparing failing test ids against a clean base worktree. Do not integrate this PR into master. Do not review your own work. Preserve the uncommitted #943 repair, keep PR #942 cleanup paused, and leave issues #931 and #941 untouched. ``` WHAT_HAPPENED: An independent review at the exact head read all three changed files, traced the evidence flow from owning_pr_renewal_evidence through the new rebuild, the shared resolver, and all three enforcement paths into issue_work_duplicate_gate._assess_owning_pr_exemption, and probed precedence and fall-through behaviour directly against the patched modules. The wiring, precedence and fail-closed matrix are correct. Reverting the primary wiring in a throwaway worktree at the same head left the new suite at 49 passed and the full suite byte identical to the PR's own result, proving no test protects the fix. Targeted and full suites ran at head and at a clean base worktree; failing test id sets are identical. Review 623 was posted at head 79334d48408fd446ddf1e8be332495960b847af6 and the reviewer lease was released. WHY: #945 exists because a correct decision layer was never wired into the paths that enforce it. PR #946 wires it correctly but ships no test that fails if the wiring is removed, so the same class of defect can silently return. The sibling recovery suite for #755 already drives the real MCP handler for exactly this reason, so the bar is established in this repository. RELATED_PRS: #946 (open, head 79334d48408fd446ddf1e8be332495960b847af6, REQUEST_CHANGES review 623) BLOCKERS: code blocker VALIDATION: New #945 suite at head: 49 passed, 8 subtests. Targeted 24-file sweep at head: 1 failed, 514 passed, 32 subtests in 32.49s; at clean base worktree aab54d48: 1 failed, 465 passed, 24 subtests in 32.13s; the single failure test_pidless_durable_lock_rejected reproduces on base in isolation. Full suite at head: 28 failed, 5574 passed, 6 skipped, 1002 subtests in 149.90s. Full suite at base: 28 failed, 5525 passed, 6 skipped, 994 subtests in 148.91s. Failing test id sets identical, so no regression originates from this branch. Wiring-revert probe at the same head: new suite 49 passed, full suite 28 failed / 5574 passed with an identical failing id set, demonstrating the absent coverage. Base reproduction of the new suite fails with AttributeError at call time on both new symbols, 0 collection or fixture errors. Parity at review time: live_stale false, restart_required false, mutation_safe true; live master aab54d4825270f5a5c6f9c1abc1ab09eb4f3e218 equals the PR head parent. LAST_UPDATED_BY: sysadmin / prgs-reviewer / gitea-reviewer namespace, reviewer lease session 93257-9ba6b15dd243

sysadmin referenced this issue

2026-07-26 14:30:14 -05:00

fix(gate): preserve exact-owner renewal evidence across duplicate rechecks (Closes #945) #946

jcwalker3 referenced this issue

2026-07-27 02:38:19 -05:00

Dirty same-claimant rebind cannot continue its owning open PR because no sanctioned path mints continuation evidence (#864 AC5 unmet) #947

jcwalker3 referenced this issue from a commit

2026-07-27 17:22:26 -05:00

fix(gate): complete owning-PR renewal enforcement coverage (#945)

jcwalker3 referenced this issue

2026-07-27 17:34:04 -05:00

fix(gate): preserve exact-owner renewal evidence across duplicate rechecks (Closes #945) #946