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

Open
opened 2026-07-26 09:35:47 -05:00 by jcwalker3 · 0 comments
Owner

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:

  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:

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 status:pr-open and removed status:ready labels 2026-07-26 10:49:44 -05:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Scaled-Tech-Consulting/Gitea-Tools#945