Allow exact-owner renewal of expired author issue locks #760

New Issue

Closed

opened 2026-07-19 11:51:08 -05:00 by jcwalker3 · 9 comments

jcwalker3 commented 2026-07-19 11:51:08 -05:00

Owner

Copy Link

Copy Source

Summary

An expired file-store author issue lock cannot be renewed by its exact owner when the recorded PID remains alive and the worktree still exists.

Because the PID represents a persistent MCP daemon rather than the individual author task, daemon liveness is not proof that task ownership remains active. The expired-lock path treats same-owner continuation as a foreign takeover and returns before exact ownership is considered.

Verified against master bde5c5fb20fbf6aec9cd6b802341c43078921d13.

Observed production state

Issue #757 was a historical instance of the expired-plus-live-daemon condition. It is not reproduced live at the time of filing, and this issue does not claim that it is.

Durable lock record for #757, read from ~/.cache/gitea-tools/issue-locks/prgs-Scaled-Tech-Consulting-Gitea-Tools-757.json:

issue_number      757
branch_name       fix/issue-757-create-issue-bootstrap-anti-stomp
worktree_path     branches/issue-757-create-issue-bootstrap-anti-stomp
operation_type    author_issue_work
claimant          jcwalker3 / prgs-author
pid, session_pid  3543
created_at        2026-07-19T06:11:51Z
expires_at        2026-07-19T10:11:51Z
last_heartbeat_at 2026-07-19T06:11:51Z

Corroborating repository state, all verified:

• registered worktree present and clean;
• local branch head, remote branch head, and open PR #759 head all adc61255b2d7eb65d1670e09e561dbd84b652317;
• last_heartbeat_at equals created_at, so the lease was never renewed across a multi-hour authoring task;
• the control-plane lease database holds no row for issue 757, confirming the lock exists only in the file store.

Why this instance no longer demonstrates the defect

Recorded PID 3543 has since exited. kill -0 3543 reports no such process, and the live MCP daemon cohorts carry unrelated PIDs.

With a dead PID the reclaim gate now permits recovery: dead becomes true, the fail-closed return is skipped, assess_expired_lock_reclaim returns reclaim_allowed=true, and assess_same_issue_lease_conflict returns None. Issue #757 is therefore recoverable today through the existing dead-PID path and is filed here as evidence of the condition, not as a live reproduction.

What remains proven

The expired-plus-live-PID same-owner renewal gap is proven by production code inspection and by the absence of any test covering it. Nothing in the source grants renewal to an exact owner whose lease expired while its recording daemon stayed alive, and no regression asserts that behavior in either direction. Because the recorded PID is the long-lived MCP daemon, a live PID at expiry is the ordinary case for any author task that outlives the four-hour TTL — the condition will recur.

Root cause

Gate ordering

assess_same_issue_lease_conflict (issue_lock_store.py:436) computes same-owner evidence before it consults it:

• issue_lock_store.py:461-464 — same_owner is computed from the locked branch and the realpath-normalized worktree.
• issue_lock_store.py:465 — the expired-lease branch is entered.
• issue_lock_store.py:466-470 — on reclaim_allowed, returns None.
• issue_lock_store.py:471-475 — otherwise returns the "Recovery review is required before takeover (fail closed)" error.
• issue_lock_store.py:476 — the same_owner allowance. Unreachable whenever the lease is expired, because both preceding paths return.

assess_expired_lock_reclaim (issue_lock_store.py:379) permits reclaim only on dead PID or missing worktree (issue_lock_store.py:404-420, gate at :410). An exact owner whose daemon is alive and whose worktree is present satisfies neither, so it takes the fail-closed return and never reaches line 476.

Why the lease expires under an active task

session_pid and pid are bound from os.getpid() at issue_lock_store.py:170-171 and :174, recording the persistent MCP daemon rather than the individual author task. The session pointer path also embeds that PID (issue_lock_store.py:73).

Expiry is computed once at creation — gitea_mcp_server.py:2016-2027, with WORK_LEASE_TTL_HOURS = 4 at gitea_mcp_server.py:1913 — from the single call site at gitea_mcp_server.py:3398. No renewal writer exists for this store. gitea_post_heartbeat (gitea_mcp_server.py:15481) does not reference the file store, work_lease, or expires_at. gitea_heartbeat_reviewer_pr_lease (gitea_mcp_server.py:12297) renews a reviewer PR comment lease, a different substrate. Once wall-clock passes expires_at, assess_lock_freshness (issue_lock_store.py:340-355) reports the lock non-live no matter how active the owning task is.

Two distinct substrates

File-store author locks are JSON on disk (issue_lock_store.py:34, :59, :117, :129). Control-plane workflow leases are SQLite (control_plane_db.py:23, :44, :254; lease_lifecycle.py:31).

gitea_adopt_workflow_lease (gitea_mcp_server.py:18313), gitea_release_workflow_lease (:18368), and gitea_reclaim_expired_workflow_lease (:18488) all delegate to lease_lifecycle, which never imports issue_lock_store. Those tools cannot clear, refresh, or overwrite a file-store issue lock.

The only writer is blocked

gitea_lock_issue is the sole native writer of the file store: gitea_mcp_server.py:3428 calls _save_issue_lock (:1982, :1993), which calls bind_session_lock, which performs the writes at issue_lock_store.py:197-198. It is refused by the expired conflict at two points — the pre-check at gitea_mcp_server.py:3215-3223 and again under the exclusive file lock at issue_lock_store.py:189-196 — before reaching the write.

Downstream, verify_lock_for_mutation (issue_lock_store.py:565, call site gitea_mcp_server.py:3628) requires a live lock at issue_lock_store.py:577-579, so no author mutation can proceed.

Related but separately owned

assess_lock_freshness (issue_lock_store.py:340-355) has two independent non-live triggers: expired-by-time and dead-PID. Line 465 gates the reclaim assessor on expiry alone, so the two triggers have symmetric but opposite gaps. The dead-PID-under-unexpired-lease side is documented at issue_lock_recovery.py:12-14 and is owned by #753; it is not re-owned here.

Verify current line numbers during implementation rather than treating reported locations as immutable.

Safety impact

• Valid author work becomes permanently unmodifiable through sanctioned tools once its lease expires under a live daemon.
• Request-changes remediation cannot proceed, because the author cannot re-acquire the lock its own open PR depends on.
• Restarting a daemon or hand-editing the lock JSON becomes a tempting false workaround; both launder false evidence through a guard.
• Long-running daemons make PID liveness unsuitable as task-liveness evidence — a live PID proves only that the server is up, not that the authoring task still holds the work.
• Automation stalls even though exact ownership evidence remains fully intact and independently verifiable.

Acceptance criteria

AC1. Distinguish exact-owner renewal from foreign takeover.

AC2. Evaluate a strengthened same-owner renewal disposition before the expired foreign-takeover return.

AC3. Renewal requires exact match of: remote; owner; repository; issue number; operation type; branch; realpath-normalized worktree; claimant username; claimant profile.

AC4. The registered worktree must exist and be clean.

AC5. Local branch head must equal the remote branch head.

AC6. When an owning PR exists, local head, remote branch head, and live PR head must all match.

AC7. No competing live lock, competing branch claim, or other owning PR may exist.

AC8. Any missing or contradictory evidence fails closed.

AC9. Successful renewal atomically records: prior PID; replacement PID; prior expiry; renewal timestamp; new expiry; claimant and evidence provenance.

AC10. The renewed lock must immediately satisfy the existing downstream verify_lock_for_mutation path.

AC11. Foreign expired-lock takeover continues to require the existing dead-PID or missing-worktree recovery conditions.

AC12. A live foreign lease remains non-recoverable.

AC13. Renewal is available through a native sanctioned tool path; no JSON edit, daemon restart, fabricated worktree, or direct API/CLI mutation is required.

AC14. Do not expose a caller-controlled boolean that declares ownership or renewal eligibility.

AC15. Tests cover: expired plus alive PID plus present clean worktree plus exact owner, renewal allowed; different branch refused; different worktree refused; different claimant or profile refused; dirty worktree refused; local and remote head mismatch refused; PR-head mismatch refused; competing lock, branch, or PR refused; live foreign lease refused; existing dead-PID reclaim unchanged; renewed lock satisfies downstream mutation ownership.

AC16. Add an explicit regression proving an MCP daemon PID remaining alive is not sufficient evidence of an active author task after lease expiry.

AC17. Do not special-case #757, PR #759, or any repository issue number.

Validation expectations

• Focused unit tests for the renewal disposition covering each rejection reason independently.
• An MCP-level regression through native gitea_lock_issue, not only against the assessor functions.
• A test asserting line-476-equivalent reachability for the exact-owner expired case, so the ordering defect cannot silently return.
• The relevant full-suite baseline comparison, reported against known pre-existing master failures rather than as an absolute pass count.

Linkage and ownership boundary

• #753 — closed; dead PID under an unexpired lease. Opposite trigger of the same freshness assessor. Do not reopen or re-own.
• #755 — closed; owning-PR duplicate gate during dead-session recovery. Different gate.
• #601 — closed; introduced the lease lifecycle and assess_expired_lock_reclaim. The component being corrected.
• #757, PR #759 — evidence only. Do not modify their scope, labels, or review state as part of this work.

Canonical issue state

STATE: ready-for-author
WHO_IS_NEXT: author
NEXT_ACTION: Lock this issue in a separately bounded author task, then implement AC1-AC17
NEXT_PROMPT: Author the exact-owner expired-lock renewal disposition; PR; stop

## Summary An expired file-store author issue lock cannot be renewed by its exact owner when the recorded PID remains alive and the worktree still exists. Because the PID represents a persistent MCP daemon rather than the individual author task, daemon liveness is not proof that task ownership remains active. The expired-lock path treats same-owner continuation as a foreign takeover and returns before exact ownership is considered. Verified against master `bde5c5fb20fbf6aec9cd6b802341c43078921d13`. ## Observed production state Issue #757 was a historical instance of the expired-plus-live-daemon condition. It is **not** reproduced live at the time of filing, and this issue does not claim that it is. Durable lock record for #757, read from `~/.cache/gitea-tools/issue-locks/prgs-Scaled-Tech-Consulting-Gitea-Tools-757.json`: ```text issue_number 757 branch_name fix/issue-757-create-issue-bootstrap-anti-stomp worktree_path branches/issue-757-create-issue-bootstrap-anti-stomp operation_type author_issue_work claimant jcwalker3 / prgs-author pid, session_pid 3543 created_at 2026-07-19T06:11:51Z expires_at 2026-07-19T10:11:51Z last_heartbeat_at 2026-07-19T06:11:51Z ``` Corroborating repository state, all verified: * registered worktree present and clean; * local branch head, remote branch head, and open PR #759 head all `adc61255b2d7eb65d1670e09e561dbd84b652317`; * `last_heartbeat_at` equals `created_at`, so the lease was never renewed across a multi-hour authoring task; * the control-plane lease database holds **no** row for issue 757, confirming the lock exists only in the file store. ### Why this instance no longer demonstrates the defect Recorded PID `3543` has since exited. `kill -0 3543` reports no such process, and the live MCP daemon cohorts carry unrelated PIDs. With a dead PID the reclaim gate now permits recovery: `dead` becomes true, the fail-closed return is skipped, `assess_expired_lock_reclaim` returns `reclaim_allowed=true`, and `assess_same_issue_lease_conflict` returns `None`. Issue #757 is therefore recoverable today through the existing dead-PID path and is filed here as evidence of the condition, not as a live reproduction. ### What remains proven The expired-plus-live-PID same-owner renewal gap is proven by production code inspection and by the absence of any test covering it. Nothing in the source grants renewal to an exact owner whose lease expired while its recording daemon stayed alive, and no regression asserts that behavior in either direction. Because the recorded PID is the long-lived MCP daemon, a live PID at expiry is the ordinary case for any author task that outlives the four-hour TTL — the condition will recur. ## Root cause ### Gate ordering `assess_same_issue_lease_conflict` (`issue_lock_store.py:436`) computes same-owner evidence before it consults it: * `issue_lock_store.py:461-464` — `same_owner` is computed from the locked branch and the realpath-normalized worktree. * `issue_lock_store.py:465` — the expired-lease branch is entered. * `issue_lock_store.py:466-470` — on `reclaim_allowed`, returns `None`. * `issue_lock_store.py:471-475` — otherwise returns the "Recovery review is required before takeover (fail closed)" error. * `issue_lock_store.py:476` — the `same_owner` allowance. **Unreachable whenever the lease is expired**, because both preceding paths return. `assess_expired_lock_reclaim` (`issue_lock_store.py:379`) permits reclaim only on dead PID or missing worktree (`issue_lock_store.py:404-420`, gate at `:410`). An exact owner whose daemon is alive and whose worktree is present satisfies neither, so it takes the fail-closed return and never reaches line 476. ### Why the lease expires under an active task `session_pid` and `pid` are bound from `os.getpid()` at `issue_lock_store.py:170-171` and `:174`, recording the persistent MCP daemon rather than the individual author task. The session pointer path also embeds that PID (`issue_lock_store.py:73`). Expiry is computed once at creation — `gitea_mcp_server.py:2016-2027`, with `WORK_LEASE_TTL_HOURS = 4` at `gitea_mcp_server.py:1913` — from the single call site at `gitea_mcp_server.py:3398`. No renewal writer exists for this store. `gitea_post_heartbeat` (`gitea_mcp_server.py:15481`) does not reference the file store, `work_lease`, or `expires_at`. `gitea_heartbeat_reviewer_pr_lease` (`gitea_mcp_server.py:12297`) renews a reviewer PR comment lease, a different substrate. Once wall-clock passes `expires_at`, `assess_lock_freshness` (`issue_lock_store.py:340-355`) reports the lock non-live no matter how active the owning task is. ### Two distinct substrates File-store author locks are JSON on disk (`issue_lock_store.py:34`, `:59`, `:117`, `:129`). Control-plane workflow leases are SQLite (`control_plane_db.py:23`, `:44`, `:254`; `lease_lifecycle.py:31`). `gitea_adopt_workflow_lease` (`gitea_mcp_server.py:18313`), `gitea_release_workflow_lease` (`:18368`), and `gitea_reclaim_expired_workflow_lease` (`:18488`) all delegate to `lease_lifecycle`, which never imports `issue_lock_store`. Those tools cannot clear, refresh, or overwrite a file-store issue lock. ### The only writer is blocked `gitea_lock_issue` is the sole native writer of the file store: `gitea_mcp_server.py:3428` calls `_save_issue_lock` (`:1982`, `:1993`), which calls `bind_session_lock`, which performs the writes at `issue_lock_store.py:197-198`. It is refused by the expired conflict at two points — the pre-check at `gitea_mcp_server.py:3215-3223` and again under the exclusive file lock at `issue_lock_store.py:189-196` — before reaching the write. Downstream, `verify_lock_for_mutation` (`issue_lock_store.py:565`, call site `gitea_mcp_server.py:3628`) requires a live lock at `issue_lock_store.py:577-579`, so no author mutation can proceed. ### Related but separately owned `assess_lock_freshness` (`issue_lock_store.py:340-355`) has two independent non-live triggers: expired-by-time and dead-PID. Line 465 gates the reclaim assessor on expiry alone, so the two triggers have symmetric but opposite gaps. The dead-PID-under-unexpired-lease side is documented at `issue_lock_recovery.py:12-14` and is owned by #753; it is not re-owned here. Verify current line numbers during implementation rather than treating reported locations as immutable. ## Safety impact * Valid author work becomes permanently unmodifiable through sanctioned tools once its lease expires under a live daemon. * Request-changes remediation cannot proceed, because the author cannot re-acquire the lock its own open PR depends on. * Restarting a daemon or hand-editing the lock JSON becomes a tempting false workaround; both launder false evidence through a guard. * Long-running daemons make PID liveness unsuitable as task-liveness evidence — a live PID proves only that the server is up, not that the authoring task still holds the work. * Automation stalls even though exact ownership evidence remains fully intact and independently verifiable. ## Acceptance criteria **AC1.** Distinguish exact-owner renewal from foreign takeover. **AC2.** Evaluate a strengthened same-owner renewal disposition before the expired foreign-takeover return. **AC3.** Renewal requires exact match of: remote; owner; repository; issue number; operation type; branch; realpath-normalized worktree; claimant username; claimant profile. **AC4.** The registered worktree must exist and be clean. **AC5.** Local branch head must equal the remote branch head. **AC6.** When an owning PR exists, local head, remote branch head, and live PR head must all match. **AC7.** No competing live lock, competing branch claim, or other owning PR may exist. **AC8.** Any missing or contradictory evidence fails closed. **AC9.** Successful renewal atomically records: prior PID; replacement PID; prior expiry; renewal timestamp; new expiry; claimant and evidence provenance. **AC10.** The renewed lock must immediately satisfy the existing downstream `verify_lock_for_mutation` path. **AC11.** Foreign expired-lock takeover continues to require the existing dead-PID or missing-worktree recovery conditions. **AC12.** A live foreign lease remains non-recoverable. **AC13.** Renewal is available through a native sanctioned tool path; no JSON edit, daemon restart, fabricated worktree, or direct API/CLI mutation is required. **AC14.** Do not expose a caller-controlled boolean that declares ownership or renewal eligibility. **AC15.** Tests cover: expired plus alive PID plus present clean worktree plus exact owner, renewal allowed; different branch refused; different worktree refused; different claimant or profile refused; dirty worktree refused; local and remote head mismatch refused; PR-head mismatch refused; competing lock, branch, or PR refused; live foreign lease refused; existing dead-PID reclaim unchanged; renewed lock satisfies downstream mutation ownership. **AC16.** Add an explicit regression proving an MCP daemon PID remaining alive is not sufficient evidence of an active author task after lease expiry. **AC17.** Do not special-case #757, PR #759, or any repository issue number. ## Validation expectations * Focused unit tests for the renewal disposition covering each rejection reason independently. * An MCP-level regression through native `gitea_lock_issue`, not only against the assessor functions. * A test asserting line-476-equivalent reachability for the exact-owner expired case, so the ordering defect cannot silently return. * The relevant full-suite baseline comparison, reported against known pre-existing master failures rather than as an absolute pass count. ## Linkage and ownership boundary * **#753** — closed; dead PID under an unexpired lease. Opposite trigger of the same freshness assessor. Do not reopen or re-own. * **#755** — closed; owning-PR duplicate gate during dead-session recovery. Different gate. * **#601** — closed; introduced the lease lifecycle and `assess_expired_lock_reclaim`. The component being corrected. * **#757**, **PR #759** — evidence only. Do not modify their scope, labels, or review state as part of this work. ## Canonical issue state ```text STATE: ready-for-author WHO_IS_NEXT: author NEXT_ACTION: Lock this issue in a separately bounded author task, then implement AC1-AC17 NEXT_PROMPT: Author the exact-owner expired-lock renewal disposition; PR; stop ```

jcwalker3 added the mcpreliabilitystatus:readyworkflow-hardeningrecoverysafetytype:bug labels 2026-07-19 11:51:09 -05:00

jcwalker3 referenced this issue 2026-07-19 12:06:35 -05:00

fix(mcp): honor the create-issue bootstrap in anti-stomp preflight (Closes #757) #759

jcwalker3 referenced this issue 2026-07-20 02:08:47 -05:00

fix(mcp): make recovered author remediation publishable after a dead session #768

jcwalker3 referenced this issue 2026-07-20 13:48:29 -05:00

fix(mcp): recover clean unpublished author work after the owning session exits #772

jcwalker3 referenced this issue 2026-07-21 22:47:14 -05:00

Unify task leases with sliding heartbeats and safe terminal dead-owner recovery #790

jcwalker3 commented 2026-07-21 22:53:04 -05:00

Author

Owner

Copy Link

Copy Source

Implementation sequencing with Issue #790

Issue #760 must not be implemented concurrently with Issue #790 without an explicit integration plan. Both may modify the same ownership and lease surfaces:

• issue_lock_store.assess_same_issue_lease_conflict

  • #760 changes gate ordering so an expired lease can be renewed by the exact existing owner.
  • #790 broadens reclaim decisions from is_lease_expired(...) toward shared liveness and heartbeat semantics.
  • Independent implementations could conflict both textually and semantically.

• Issue-lock expiry and freshness behavior

  • #760 retains absolute wall-clock expiry and adds exact-owner renewal.
  • #790 introduces sliding heartbeat renewal, lease generations, fencing tokens, and unified cross-role lifecycle behavior.
  • #790 may subsume or replace portions of the renewal path introduced by #760.

Before allocating implementation, choose one sequence:

1. Land #760 first, then rebase and design #790 against its renewal behavior; or
2. Incorporate #760’s acceptance criteria into #790 and close #760 as superseded after confirming complete coverage.

Do not allocate #760 and #790 concurrently to separate authors unless their code boundaries and final integration order are explicitly coordinated.

Canonical Issue State

STATE: awaiting-sequencing-decision
WHO_IS_NEXT: controller
NEXT_ACTION: Choose and record the #760/#790 implementation order before allocating either issue.
NEXT_PROMPT:

Decide whether to land #760 first and rebase #790 onto it, or incorporate #760's acceptance criteria into #790 and close #760 as superseded after confirming complete coverage. Record the decision on both issues before allocation.

WHY: Both issues modify overlapping issue-lock conflict assessment and expiry/freshness behavior. Concurrent implementation without an integration order risks textual and semantic conflicts.
BLOCKERS: Allocation is blocked only until the controller records the sequencing decision.
VALIDATION: Issues #760 and #790 are open; #790 has status:ready; overlapping implementation surfaces were verified; no implementation has been allocated.

## Implementation sequencing with Issue #790 Issue #760 must not be implemented concurrently with Issue #790 without an explicit integration plan. Both may modify the same ownership and lease surfaces: - `issue_lock_store.assess_same_issue_lease_conflict` - #760 changes gate ordering so an expired lease can be renewed by the exact existing owner. - #790 broadens reclaim decisions from `is_lease_expired(...)` toward shared liveness and heartbeat semantics. - Independent implementations could conflict both textually and semantically. - Issue-lock expiry and freshness behavior - #760 retains absolute wall-clock expiry and adds exact-owner renewal. - #790 introduces sliding heartbeat renewal, lease generations, fencing tokens, and unified cross-role lifecycle behavior. - #790 may subsume or replace portions of the renewal path introduced by #760. Before allocating implementation, choose one sequence: 1. Land #760 first, then rebase and design #790 against its renewal behavior; or 2. Incorporate #760’s acceptance criteria into #790 and close #760 as superseded after confirming complete coverage. Do not allocate #760 and #790 concurrently to separate authors unless their code boundaries and final integration order are explicitly coordinated. ## Canonical Issue State STATE: awaiting-sequencing-decision WHO_IS_NEXT: controller NEXT_ACTION: Choose and record the #760/#790 implementation order before allocating either issue. NEXT_PROMPT: ```text Decide whether to land #760 first and rebase #790 onto it, or incorporate #760's acceptance criteria into #790 and close #760 as superseded after confirming complete coverage. Record the decision on both issues before allocation. ``` WHY: Both issues modify overlapping issue-lock conflict assessment and expiry/freshness behavior. Concurrent implementation without an integration order risks textual and semantic conflicts. BLOCKERS: Allocation is blocked only until the controller records the sequencing decision. VALIDATION: Issues #760 and #790 are open; #790 has status:ready; overlapping implementation surfaces were verified; no implementation has been allocated.

jcwalker3 referenced this issue 2026-07-21 23:02:03 -05:00

Unify task leases with sliding heartbeats and safe terminal dead-owner recovery #790

jcwalker3 commented 2026-07-21 23:02:16 -05:00

Author

Owner

Copy Link

Copy Source

Ledger correction — supersedes comment 13871

Corrects the VALIDATION field only. The sequencing analysis and every other field in comment 13871 stand unchanged; this comment is the authoritative ledger for Issue #760.

Prior wording asserted status:ready for #790 alone. Both issues carry it, verified live at the time of this comment.

Canonical Issue State

STATE: awaiting-sequencing-decision
WHO_IS_NEXT: controller
NEXT_ACTION: Choose and record the #760/#790 implementation order before allocating either issue.
NEXT_PROMPT:

Decide whether to land #760 first and rebase #790 onto it, or incorporate #760's acceptance criteria into #790 and close #760 as superseded after confirming complete coverage. Record the decision on both issues before allocation.

WHY: Both issues modify overlapping issue-lock conflict assessment and expiry/freshness behavior. Concurrent implementation without an integration order risks textual and semantic conflicts.
BLOCKERS: Allocation is blocked only until the controller records the sequencing decision.
VALIDATION: Issues #760 and #790 are open; both #760 and #790 have status:ready; overlapping implementation surfaces were verified; no implementation has been allocated.

## Ledger correction — supersedes comment 13871 Corrects the `VALIDATION` field only. The sequencing analysis and every other field in comment 13871 stand unchanged; this comment is the authoritative ledger for Issue #760. Prior wording asserted `status:ready` for #790 alone. Both issues carry it, verified live at the time of this comment. ## Canonical Issue State STATE: awaiting-sequencing-decision WHO_IS_NEXT: controller NEXT_ACTION: Choose and record the #760/#790 implementation order before allocating either issue. NEXT_PROMPT: ```text Decide whether to land #760 first and rebase #790 onto it, or incorporate #760's acceptance criteria into #790 and close #760 as superseded after confirming complete coverage. Record the decision on both issues before allocation. ``` WHY: Both issues modify overlapping issue-lock conflict assessment and expiry/freshness behavior. Concurrent implementation without an integration order risks textual and semantic conflicts. BLOCKERS: Allocation is blocked only until the controller records the sequencing decision. VALIDATION: Issues #760 and #790 are open; both #760 and #790 have status:ready; overlapping implementation surfaces were verified; no implementation has been allocated.

jcwalker3 commented 2026-07-21 23:05:12 -05:00

Author

Owner

Copy Link

Copy Source

Sequencing decision: Issue #760 lands first

The controller has selected the implementation order:

1. Implement, review, and land Issue #760 first.
2. Do not implement Issue #790 concurrently.
3. After #760 lands, reassess #790 against the delivered renewal behavior.
4. Rebase or redesign #790 as necessary so its shared heartbeat lifecycle incorporates rather than duplicates or conflicts with #760.

This resolves the sequencing decision previously recorded in comments 13871 and 13875.

Canonical Issue State

STATE: ready-for-allocation
WHO_IS_NEXT: controller
NEXT_ACTION: Allocate Issue #760 for implementation before Issue #790.
NEXT_PROMPT:

Allocate and implement Gitea-Tools Issue #760 first. Preserve its exact-owner renewal requirements and tests. Do not begin Issue #790 concurrently. After #760 lands, hand control back to the controller so #790 can be reassessed against the landed behavior.

WHY: Issue #760 provides the narrower exact-owner renewal behavior on which the broader shared-heartbeat work in #790 should be based.
BLOCKERS: None for allocating Issue #760. Issue #790 remains sequenced behind it.
VALIDATION: Issues #760 and #790 are open and both have status:ready; the controller selected #760 to land first; no implementation was allocated by this comment.

## Sequencing decision: Issue #760 lands first The controller has selected the implementation order: 1. Implement, review, and land Issue #760 first. 2. Do not implement Issue #790 concurrently. 3. After #760 lands, reassess #790 against the delivered renewal behavior. 4. Rebase or redesign #790 as necessary so its shared heartbeat lifecycle incorporates rather than duplicates or conflicts with #760. This resolves the sequencing decision previously recorded in comments 13871 and 13875. ## Canonical Issue State STATE: ready-for-allocation WHO_IS_NEXT: controller NEXT_ACTION: Allocate Issue #760 for implementation before Issue #790. NEXT_PROMPT: ```text Allocate and implement Gitea-Tools Issue #760 first. Preserve its exact-owner renewal requirements and tests. Do not begin Issue #790 concurrently. After #760 lands, hand control back to the controller so #790 can be reassessed against the landed behavior. ``` WHY: Issue #760 provides the narrower exact-owner renewal behavior on which the broader shared-heartbeat work in #790 should be based. BLOCKERS: None for allocating Issue #760. Issue #790 remains sequenced behind it. VALIDATION: Issues #760 and #790 are open and both have status:ready; the controller selected #760 to land first; no implementation was allocated by this comment.

jcwalker3 referenced this issue 2026-07-21 23:05:36 -05:00

Unify task leases with sliding heartbeats and safe terminal dead-owner recovery #790

jcwalker3 commented 2026-07-21 23:19:51 -05:00

Author

Owner

Copy Link

Copy Source

Allocation ledger — Issue #760 allocated for implementation

Per the sequencing decision in comment 13877, Issue #760 is now allocated. Issue #790 remains sequenced behind it and was not touched.

Allocated artifacts:

• Branch: fix/issue-760-exact-owner-renewal, cut from prgs/master at 3d0c13fa5a756ff94441dc57cf4e74318f45ba41
• Worktree: /Users/jasonwalker/Development/Gitea-Tools/branches/fix-issue-760-exact-owner-renewal (registered, clean, dedicated to #760)
• Lock generation 1, no adoption (adoption_decision: NO_MATCH, competing branch check clear)
• Lease author_issue_work, acquired 2026-07-22T04:19:08Z, expires 2026-07-22T08:19:08Z, owner PID alive, freshness live

Observation worth recording for #790: this lease was minted with the same fixed four-hour TTL and no heartbeat renewal that #790 exists to correct. It is the current sanctioned behavior, not a defect in this allocation.

Canonical Issue State

STATE: allocated-for-implementation
WHO_IS_NEXT: author
NEXT_ACTION: Implement Issue #760 in the allocated branch and worktree.
NEXT_PROMPT:

Implement Gitea-Tools Issue #760 only, in branch fix/issue-760-exact-owner-renewal and worktree /Users/jasonwalker/Development/Gitea-Tools/branches/fix-issue-760-exact-owner-renewal. Preserve every acceptance criterion AC1-AC17 and deliver the tests named in AC15 and AC16. Do not widen scope into Issue #790's shared heartbeat lifecycle, and do not modify Issue #787 artifacts. Open a PR when complete and hand back to the controller.

WHY: The controller selected #760 to land before #790.
BLOCKERS: None. No conflicting lock, branch, worktree, claim, linked PR, or live owner existed for #760 at allocation time.
VALIDATION: Author issue-work lock verified live for issue 760 on branch fix/issue-760-exact-owner-renewal from worktree /Users/jasonwalker/Development/Gitea-Tools/branches/fix-issue-760-exact-owner-renewal; identity jcwalker3, profile prgs-author, role author; repository binding Scaled-Tech-Consulting/Gitea-Tools on prgs; runtime/master parity healthy and in parity at 3d0c13fa5a756ff94441dc57cf4e74318f45ba41; worktree registered, on the expected branch, and clean; Issue #790 confirmed unlocked, unbranched, and unallocated.

## Allocation ledger — Issue #760 allocated for implementation Per the sequencing decision in comment 13877, Issue #760 is now allocated. Issue #790 remains sequenced behind it and was not touched. Allocated artifacts: - Branch: `fix/issue-760-exact-owner-renewal`, cut from `prgs/master` at `3d0c13fa5a756ff94441dc57cf4e74318f45ba41` - Worktree: `/Users/jasonwalker/Development/Gitea-Tools/branches/fix-issue-760-exact-owner-renewal` (registered, clean, dedicated to #760) - Lock generation 1, no adoption (`adoption_decision: NO_MATCH`, competing branch check `clear`) - Lease `author_issue_work`, acquired `2026-07-22T04:19:08Z`, expires `2026-07-22T08:19:08Z`, owner PID alive, freshness `live` Observation worth recording for #790: this lease was minted with the same fixed four-hour TTL and no heartbeat renewal that #790 exists to correct. It is the current sanctioned behavior, not a defect in this allocation. ## Canonical Issue State STATE: allocated-for-implementation WHO_IS_NEXT: author NEXT_ACTION: Implement Issue #760 in the allocated branch and worktree. NEXT_PROMPT: ```text Implement Gitea-Tools Issue #760 only, in branch fix/issue-760-exact-owner-renewal and worktree /Users/jasonwalker/Development/Gitea-Tools/branches/fix-issue-760-exact-owner-renewal. Preserve every acceptance criterion AC1-AC17 and deliver the tests named in AC15 and AC16. Do not widen scope into Issue #790's shared heartbeat lifecycle, and do not modify Issue #787 artifacts. Open a PR when complete and hand back to the controller. ``` WHY: The controller selected #760 to land before #790. BLOCKERS: None. No conflicting lock, branch, worktree, claim, linked PR, or live owner existed for #760 at allocation time. VALIDATION: Author issue-work lock verified live for issue 760 on branch fix/issue-760-exact-owner-renewal from worktree /Users/jasonwalker/Development/Gitea-Tools/branches/fix-issue-760-exact-owner-renewal; identity jcwalker3, profile prgs-author, role author; repository binding Scaled-Tech-Consulting/Gitea-Tools on prgs; runtime/master parity healthy and in parity at 3d0c13fa5a756ff94441dc57cf4e74318f45ba41; worktree registered, on the expected branch, and clean; Issue #790 confirmed unlocked, unbranched, and unallocated.

jcwalker3 referenced this issue from a commit 2026-07-21 23:40:03 -05:00

feat(lock): allow exact-owner renewal of expired author issue locks (Closes #760)

jcwalker3 referenced a pull request that will close this issue 2026-07-21 23:40:51 -05:00

fix(lock): allow exact-owner renewal of expired author issue locks (Closes #760) #791

jcwalker3 added status:pr-open and removed status:ready labels 2026-07-21 23:40:52 -05:00

jcwalker3 commented 2026-07-21 23:42:00 -05:00

Author

Owner

Copy Link

Copy Source

Author handoff — Issue #760 implementation complete, PR #791 open

Implemented under the allocation recorded in comment 13881. Exact-owner renewal of an expired author issue lease now has a sanctioned path; foreign takeover, live-lease, and dead-PID dispositions are unchanged.

Canonical Issue State

STATE: implementation-complete
WHO_IS_NEXT: reviewer
NEXT_ACTION: Review the new PR for complete Issue #760 acceptance-criteria coverage.
NEXT_PROMPT:

Review Gitea-Tools PR #791 at head 1a97ced133fbb16a560ea4c3bf71b97b7401950c, base master, in the repository Scaled-Tech-Consulting/Gitea-Tools on the prgs remote. It closes Issue #760, exact-owner renewal of an expired author issue lock. Read Issue #760 for AC1-AC17 and verify each one against the diff: the renewal disposition must be evaluated before the expired foreign-takeover return; renewal must require exact match of remote, org, repo, issue number, operation type, branch, realpath-normalized worktree, claimant username, and claimant profile, plus a present clean worktree on the locked branch, agreeing local and remote heads, and an agreeing PR head when an owning PR exists; any missing evidence must fail closed. Confirm PID liveness is never treated as authorization (AC16), that only an expired lease is a candidate so live foreign leases stay non-recoverable (AC12), that dead-PID takeover keeps its existing conditions (AC11), that no caller-facing renewal parameter was added (AC14), and that no issue or PR number is special-cased (AC17). Verify the durable renewal record and the compare-and-swap. Confirm the change does not implement Issue #790's sliding heartbeat lifecycle, fencing tokens, or shared cross-role lease model, and does not weaken branches-only, duplicate-work, lock-adoption, stale-runtime, identity, binding, or anti-stomp guards. Run the test suite and compare failures against the master baseline at 3d0c13fa, which already carries 11 pre-existing failures in test_commit_payloads.py, test_issue_702_review_findings_f1_f6.py, test_mcp_server.py TestPreflightVerification, test_post_merge_moot_lease.py, and test_reconciler_supersession_close.py. Review only this PR at this exact head; do not merge, and do not begin Issue #790.

WHAT_HAPPENED: Added the pure assessor issue_lock_renewal.py; issue_lock_store now carries a server-computed renewal_sanctioned waiver evaluated ahead of the expired foreign-takeover return; gitea_mcp_server gathers the evidence server-side, records a durable lease_renewal block, and covers the write with the existing compare-and-swap. 40 new tests were added and two test doubles in the #772 suite now forward the new keyword.
WHY: Issue #760 was implemented first according to the recorded sequencing decision.
RELATED_PRS: #791 (open, head 1a97ced133, base master, closes this issue)
BLOCKERS: None for review. Issue #790 remains blocked behind this PR landing, by design.
VALIDATION: Commit and PR head 1a97ced133, pushed to prgs and confirmed by git ls-remote; PR #791 open against base master, mergeable, author jcwalker3. Tests run with venv/bin/python -m pytest from the allocated worktree: new suite tests/test_issue_760_exact_owner_lease_renewal.py 40 passed; lock and lease regression set 240 passed with 2 subtests passed; full suite 4230 passed, 11 failed, 6 skipped, 493 subtests passed, where all 11 failures reproduce identically on master at 3d0c13fa and none touch lease, lock-conflict, or renewal code. Branch fix/issue-760-exact-owner-renewal and worktree /Users/jasonwalker/Development/Gitea-Tools/branches/fix-issue-760-exact-owner-renewal verified registered, on the expected branch, and clean; the stable control checkout stayed on master at 3d0c13fa and clean throughout. Issue lock for 760 live and non-reclaimable, owner jcwalker3 / prgs-author, PID alive, lease acquired 2026-07-22T04:19:08Z and expiring 2026-07-22T08:19:08Z. Identity jcwalker3, profile prgs-author, role author, binding Scaled-Tech-Consulting/Gitea-Tools on prgs; runtime and master parity in parity at 3d0c13fa5a before each mutation. Issue #790 confirmed unlocked, unbranched, unallocated, and unmodified.
LAST_UPDATED_BY: jcwalker3 / prgs-author (author session)

## Author handoff — Issue #760 implementation complete, PR #791 open Implemented under the allocation recorded in comment 13881. Exact-owner renewal of an expired author issue lease now has a sanctioned path; foreign takeover, live-lease, and dead-PID dispositions are unchanged. ## Canonical Issue State STATE: implementation-complete WHO_IS_NEXT: reviewer NEXT_ACTION: Review the new PR for complete Issue #760 acceptance-criteria coverage. NEXT_PROMPT: ```text Review Gitea-Tools PR #791 at head 1a97ced133fbb16a560ea4c3bf71b97b7401950c, base master, in the repository Scaled-Tech-Consulting/Gitea-Tools on the prgs remote. It closes Issue #760, exact-owner renewal of an expired author issue lock. Read Issue #760 for AC1-AC17 and verify each one against the diff: the renewal disposition must be evaluated before the expired foreign-takeover return; renewal must require exact match of remote, org, repo, issue number, operation type, branch, realpath-normalized worktree, claimant username, and claimant profile, plus a present clean worktree on the locked branch, agreeing local and remote heads, and an agreeing PR head when an owning PR exists; any missing evidence must fail closed. Confirm PID liveness is never treated as authorization (AC16), that only an expired lease is a candidate so live foreign leases stay non-recoverable (AC12), that dead-PID takeover keeps its existing conditions (AC11), that no caller-facing renewal parameter was added (AC14), and that no issue or PR number is special-cased (AC17). Verify the durable renewal record and the compare-and-swap. Confirm the change does not implement Issue #790's sliding heartbeat lifecycle, fencing tokens, or shared cross-role lease model, and does not weaken branches-only, duplicate-work, lock-adoption, stale-runtime, identity, binding, or anti-stomp guards. Run the test suite and compare failures against the master baseline at 3d0c13fa, which already carries 11 pre-existing failures in test_commit_payloads.py, test_issue_702_review_findings_f1_f6.py, test_mcp_server.py TestPreflightVerification, test_post_merge_moot_lease.py, and test_reconciler_supersession_close.py. Review only this PR at this exact head; do not merge, and do not begin Issue #790. ``` WHAT_HAPPENED: Added the pure assessor issue_lock_renewal.py; issue_lock_store now carries a server-computed renewal_sanctioned waiver evaluated ahead of the expired foreign-takeover return; gitea_mcp_server gathers the evidence server-side, records a durable lease_renewal block, and covers the write with the existing compare-and-swap. 40 new tests were added and two test doubles in the #772 suite now forward the new keyword. WHY: Issue #760 was implemented first according to the recorded sequencing decision. RELATED_PRS: #791 (open, head 1a97ced133fbb16a560ea4c3bf71b97b7401950c, base master, closes this issue) BLOCKERS: None for review. Issue #790 remains blocked behind this PR landing, by design. VALIDATION: Commit and PR head 1a97ced133fbb16a560ea4c3bf71b97b7401950c, pushed to prgs and confirmed by git ls-remote; PR #791 open against base master, mergeable, author jcwalker3. Tests run with venv/bin/python -m pytest from the allocated worktree: new suite tests/test_issue_760_exact_owner_lease_renewal.py 40 passed; lock and lease regression set 240 passed with 2 subtests passed; full suite 4230 passed, 11 failed, 6 skipped, 493 subtests passed, where all 11 failures reproduce identically on master at 3d0c13fa and none touch lease, lock-conflict, or renewal code. Branch fix/issue-760-exact-owner-renewal and worktree /Users/jasonwalker/Development/Gitea-Tools/branches/fix-issue-760-exact-owner-renewal verified registered, on the expected branch, and clean; the stable control checkout stayed on master at 3d0c13fa and clean throughout. Issue lock for 760 live and non-reclaimable, owner jcwalker3 / prgs-author, PID alive, lease acquired 2026-07-22T04:19:08Z and expiring 2026-07-22T08:19:08Z. Identity jcwalker3, profile prgs-author, role author, binding Scaled-Tech-Consulting/Gitea-Tools on prgs; runtime and master parity in parity at 3d0c13fa5a756ff94441dc57cf4e74318f45ba41 before each mutation. Issue #790 confirmed unlocked, unbranched, unallocated, and unmodified. LAST_UPDATED_BY: jcwalker3 / prgs-author (author session)

sysadmin referenced this issue 2026-07-21 23:55:43 -05:00

fix(lock): allow exact-owner renewal of expired author issue locks (Closes #760) #791

sysadmin referenced this issue 2026-07-21 23:56:33 -05:00

fix(lock): allow exact-owner renewal of expired author issue locks (Closes #760) #791

sysadmin referenced this issue 2026-07-21 23:59:25 -05:00

fix(lock): allow exact-owner renewal of expired author issue locks (Closes #760) #791

jcwalker3 referenced this issue from a commit 2026-07-22 00:10:57 -05:00

fix(lock): make the exact-owner renewal waiver survive downstream gates (#760)

jcwalker3 commented 2026-07-22 00:11:41 -05:00

Author

Owner

Copy Link

Copy Source

Author handoff — review #499 remediated, PR #791 at a new head

Both blocking findings from review #499 are fixed. Review #499 is now stale solely because of this push; it is undismissed and remains in the audit history.

F1 — the renewal waiver now survives downstream gates. assess_issue_lock_worktree gains a renewal_sanctioned parameter that waives base-equivalence on the same grounds as recovery_sanctioned, and gitea_lock_issue passes it. Cleanliness is evaluated before the waiver and is never relaxed; the assessment reports which waiver applied. Writing the MCP-level regression then exposed a second discard point the review had not reached: the duplicate-work gate rejected renewals with "open PR already covers issue" — the very PR the lock being renewed owns. Added owning_pr_renewal_evidence, the mirror of #755's owning_pr_recovery_evidence, carried into that gate only when renewal was granted, re-checking that PR, local, and remote heads agree.

F2 — MCP-level regression added. tests/test_issue_760_mcp_renewal_path.py, 10 cases driving native gitea_lock_issue against a real git repository and a real durable lock: expired lease, live recorded PID, committed non-base-equivalent branch.

Neither waiver is caller-supplied and gitea_lock_issue still gains no parameter. Absolute wall-clock expiry unchanged. No #790 behavior introduced; #753 recovery untouched. F3 and F4 were left alone as non-blocking, except where the duplicate-gate fix was strictly required for F1 to work.

Canonical Issue State

STATE: implementation-complete
WHO_IS_NEXT: reviewer
NEXT_ACTION: Re-review PR #791 at its new head a30a3ce4c3.
NEXT_PROMPT:

Re-review Gitea-Tools PR #791 at head a30a3ce4c37b2dde725301bef8b9ef8e04160088, base master, in Scaled-Tech-Consulting/Gitea-Tools on the prgs remote. It closes Issue #760 and remediates review #499. Verify F1: assess_issue_lock_worktree now accepts renewal_sanctioned and gitea_lock_issue passes it, base-equivalence is waived only for a proven exact-owner renewal, worktree cleanliness and every other precondition are still enforced, and the duplicate-work gate exemption via owning_pr_renewal_evidence re-checks that PR, local, and remote heads agree. Verify F2: tests/test_issue_760_mcp_renewal_path.py drives native gitea_lock_issue end to end and proves the renewal completes, records prior and replacement lease evidence, advances the lock generation once, yields a live lock satisfying verify_lock_for_mutation, and does not claim dead-session recovery, with negative companions for foreign claimant, foreign profile, unpublished branch, mismatched PR head, dirty worktree, and no-waiver base-equivalence. Confirm no caller-controlled bypass was added, no Issue #790 heartbeat or fencing-token or shared-lifecycle behavior appears, and Issue #753 recovery is unchanged. Run the new MCP suite, the full Issue #760 suites, the lock and lease regression set, and the full suite with tracebacks suppressed so no environment values print, comparing against the master baseline at 3d0c13fa which carries 11 pre-existing failures. Review only this PR at this exact head; do not merge and do not begin Issue #790.

WHAT_HAPPENED: Remediated review #499. Threaded renewal_sanctioned into assess_issue_lock_worktree and its call site, added owning_pr_renewal_evidence so the duplicate-work gate does not reject a renewal on the PR it already owns, and added a 10-case MCP-level regression driving native gitea_lock_issue through a sanctioned renewal plus its negative companions.
WHY: The renewal waiver was computed and then discarded at two later gates, so exact-owner renewal was unreachable end to end, and no MCP-level regression existed to catch it.
ISSUE: #760
RELATED_PRS: #791 (open, previous head 1a97ced133 reviewed by #499, new head a30a3ce4c3)
BLOCKERS: None outstanding. Both review #499 blocking findings are remediated; the non-blocking F3 and F4 remain open by design.
VALIDATION: New commit a30a3ce4c3 pushed to prgs and confirmed by git ls-remote; PR #791 current_head_sha reads a30a3ce4c3, state open, base master. Review #499 now reports dismissed false, stale true, author_pushed_after_request_changes true, so it is stale only because of this push and stays in the audit history. Tests from the allocated author worktree: new MCP suite tests/test_issue_760_mcp_renewal_path.py 10 passed; both Issue #760 suites together 50 passed; lock and lease regression set 200 passed with 2 subtests passed; full suite 4240 passed, 11 failed, 6 skipped, 493 subtests passed, run with tracebacks suppressed so no environment values printed. The 11 failures are the same node IDs as the master baseline at 3d0c13fa and 4240 passed reflects exactly the 10 added cases, so no new failures were introduced. Author worktree clean on fix/issue-760-exact-owner-renewal at a30a3ce4; stable control checkout untouched on master at 3d0c13fa and clean; reviewer worktree untouched at 1a97ced1 and clean. Issue #760 author lock live and non-reclaimable, owner jcwalker3 / prgs-author, PID 39849 alive, lease expiring 2026-07-22T08:19:08Z. Issue #790 confirmed unlocked, unbranched, unallocated, and unmodified.
LAST_UPDATED_BY: jcwalker3 / prgs-author (author session)

## Author handoff — review #499 remediated, PR #791 at a new head Both blocking findings from review #499 are fixed. Review #499 is now stale solely because of this push; it is undismissed and remains in the audit history. **F1 — the renewal waiver now survives downstream gates.** `assess_issue_lock_worktree` gains a `renewal_sanctioned` parameter that waives base-equivalence on the same grounds as `recovery_sanctioned`, and `gitea_lock_issue` passes it. Cleanliness is evaluated before the waiver and is never relaxed; the assessment reports which waiver applied. Writing the MCP-level regression then exposed a second discard point the review had not reached: the duplicate-work gate rejected renewals with "open PR already covers issue" — the very PR the lock being renewed owns. Added `owning_pr_renewal_evidence`, the mirror of #755's `owning_pr_recovery_evidence`, carried into that gate only when renewal was granted, re-checking that PR, local, and remote heads agree. **F2 — MCP-level regression added.** `tests/test_issue_760_mcp_renewal_path.py`, 10 cases driving native `gitea_lock_issue` against a real git repository and a real durable lock: expired lease, live recorded PID, committed non-base-equivalent branch. Neither waiver is caller-supplied and `gitea_lock_issue` still gains no parameter. Absolute wall-clock expiry unchanged. No #790 behavior introduced; #753 recovery untouched. F3 and F4 were left alone as non-blocking, except where the duplicate-gate fix was strictly required for F1 to work. ## Canonical Issue State STATE: implementation-complete WHO_IS_NEXT: reviewer NEXT_ACTION: Re-review PR #791 at its new head a30a3ce4c37b2dde725301bef8b9ef8e04160088. NEXT_PROMPT: ```text Re-review Gitea-Tools PR #791 at head a30a3ce4c37b2dde725301bef8b9ef8e04160088, base master, in Scaled-Tech-Consulting/Gitea-Tools on the prgs remote. It closes Issue #760 and remediates review #499. Verify F1: assess_issue_lock_worktree now accepts renewal_sanctioned and gitea_lock_issue passes it, base-equivalence is waived only for a proven exact-owner renewal, worktree cleanliness and every other precondition are still enforced, and the duplicate-work gate exemption via owning_pr_renewal_evidence re-checks that PR, local, and remote heads agree. Verify F2: tests/test_issue_760_mcp_renewal_path.py drives native gitea_lock_issue end to end and proves the renewal completes, records prior and replacement lease evidence, advances the lock generation once, yields a live lock satisfying verify_lock_for_mutation, and does not claim dead-session recovery, with negative companions for foreign claimant, foreign profile, unpublished branch, mismatched PR head, dirty worktree, and no-waiver base-equivalence. Confirm no caller-controlled bypass was added, no Issue #790 heartbeat or fencing-token or shared-lifecycle behavior appears, and Issue #753 recovery is unchanged. Run the new MCP suite, the full Issue #760 suites, the lock and lease regression set, and the full suite with tracebacks suppressed so no environment values print, comparing against the master baseline at 3d0c13fa which carries 11 pre-existing failures. Review only this PR at this exact head; do not merge and do not begin Issue #790. ``` WHAT_HAPPENED: Remediated review #499. Threaded renewal_sanctioned into assess_issue_lock_worktree and its call site, added owning_pr_renewal_evidence so the duplicate-work gate does not reject a renewal on the PR it already owns, and added a 10-case MCP-level regression driving native gitea_lock_issue through a sanctioned renewal plus its negative companions. WHY: The renewal waiver was computed and then discarded at two later gates, so exact-owner renewal was unreachable end to end, and no MCP-level regression existed to catch it. ISSUE: #760 RELATED_PRS: #791 (open, previous head 1a97ced133fbb16a560ea4c3bf71b97b7401950c reviewed by #499, new head a30a3ce4c37b2dde725301bef8b9ef8e04160088) BLOCKERS: None outstanding. Both review #499 blocking findings are remediated; the non-blocking F3 and F4 remain open by design. VALIDATION: New commit a30a3ce4c37b2dde725301bef8b9ef8e04160088 pushed to prgs and confirmed by git ls-remote; PR #791 current_head_sha reads a30a3ce4c37b2dde725301bef8b9ef8e04160088, state open, base master. Review #499 now reports dismissed false, stale true, author_pushed_after_request_changes true, so it is stale only because of this push and stays in the audit history. Tests from the allocated author worktree: new MCP suite tests/test_issue_760_mcp_renewal_path.py 10 passed; both Issue #760 suites together 50 passed; lock and lease regression set 200 passed with 2 subtests passed; full suite 4240 passed, 11 failed, 6 skipped, 493 subtests passed, run with tracebacks suppressed so no environment values printed. The 11 failures are the same node IDs as the master baseline at 3d0c13fa and 4240 passed reflects exactly the 10 added cases, so no new failures were introduced. Author worktree clean on fix/issue-760-exact-owner-renewal at a30a3ce4; stable control checkout untouched on master at 3d0c13fa and clean; reviewer worktree untouched at 1a97ced1 and clean. Issue #760 author lock live and non-reclaimable, owner jcwalker3 / prgs-author, PID 39849 alive, lease expiring 2026-07-22T08:19:08Z. Issue #790 confirmed unlocked, unbranched, unallocated, and unmodified. LAST_UPDATED_BY: jcwalker3 / prgs-author (author session)

sysadmin referenced this issue 2026-07-22 00:21:10 -05:00

fix(lock): allow exact-owner renewal of expired author issue locks (Closes #760) #791

sysadmin referenced this issue 2026-07-22 00:27:15 -05:00

fix(lock): allow exact-owner renewal of expired author issue locks (Closes #760) #791

sysadmin referenced this issue 2026-07-22 00:30:33 -05:00

fix(lock): allow exact-owner renewal of expired author issue locks (Closes #760) #791

sysadmin referenced this issue 2026-07-22 00:31:43 -05:00

fix(lock): allow exact-owner renewal of expired author issue locks (Closes #760) #791

sysadmin referenced this issue 2026-07-22 01:01:51 -05:00

fix(lock): allow exact-owner renewal of expired author issue locks (Closes #760) #791

sysadmin closed this issue 2026-07-22 01:02:40 -05:00

sysadmin removed the status:pr-open label 2026-07-22 01:02:41 -05:00

sysadmin referenced this issue from a commit 2026-07-22 01:02:42 -05:00

Merge pull request 'fix(lock): allow exact-owner renewal of expired author issue locks (Closes #760)' (#791) from fix/issue-760-exact-owner-renewal into master

sysadmin commented 2026-07-22 01:05:12 -05:00

Owner

Copy Link

Copy Source

[THREAD STATE LEDGER] Issue #760 / PR #791 — merge commit 620ed6e9a9 landed on prgs/master

What is true now:

• Server-side decision state: PR #791 merge performed through native MCP gitea_merge_pr; merge result: PR #791 merged via 'merge'. Merge commit 620ed6e9a9550b8da2ceb82d9ab8744e8920490f. PR #791 state is closed with merged_at 2026-07-22T01:02:40-05:00. Issue #760 state is closed, closed automatically through the PR's "Closes #760" reference.
• Local verdict/state: Merger session sysadmin / prgs-merger made no code edit, no branch mutation, no rebase, no amend, and no push. The author branch fix/issue-760-exact-owner-renewal is untouched at a30a3ce4c37b2dde725301bef8b9ef8e04160088. The stable control checkout stayed on master and clean.
• Latest known validation: At head a30a3ce4c37b2dde725301bef8b9ef8e04160088 — approval_visible=true, approval_at_current_head=true, latest_approved_head_sha equals the current head, has_blocking_change_requests=false, review_feedback_stale=false, quarantined_approvals_at_current_head=0. Review #500 carries the APPROVE review verdict recorded via the review API, with dismissed=false and stale=false. Review #499 (REQUEST_CHANGES at prior head 1a97ced133fbb16a560ea4c3bf71b97b7401950c) is preserved in audit history with its full body intact and quarantined=false; its dismissed flag was set server-side by the superseding approval, not by any tool call. gitea_assess_pr_sync_status returned recommended_next_action merge_now with commits_behind=0, mergeable=true, has_conflicts=false, approval_valid_for_merge=true, stale_approval=false, checks_required=false and checks_status not_required. Read-after-write: git ls-remote prgs refs/heads/master reports 620ed6e9a9550b8da2ceb82d9ab8744e8920490f.

What changed:

• PR #791 was merge-committed to prgs/master as 620ed6e9a9550b8da2ceb82d9ab8744e8920490f using the repository's canonical merge method (merge), pinned with expected_head_sha a30a3ce4c37b2dde725301bef8b9ef8e04160088.
• Issue #760 moved to closed state through the PR's closing reference.
• The status:pr-open label was retired from Issue #760 at merge time and verified residual-free (labels_after: mcp, recovery, reliability, safety, type:bug, workflow-hardening).
• The prgs-reviewer review decision lock was cleared after the merge event; audit comment 13943.
• A merger PR lease was acquired at comment 13938 under session 58066-cf14e86f060e, pinned to the exact approved head.

What is blocked:

• Blocker classification: no blocker

Who/what acts next:

• Next actor: controller
• Required action: Reassess Issue #790 against the exact-owner lease renewal behavior delivered by this change before allocation.
• Do not do: Do not start, lock, branch, or implement Issue #790 from a merger session. Do not delete the author branch fix/issue-760-exact-owner-renewal, the reviewer worktree branches/review-pr791-issue-760, or the baseline worktree branches/baseline-master-pr791 from this session — post-merge lease finalization and branch/worktree cleanup both require the prgs-reconciler role and fail closed for a merger.

Canonical Issue State

STATE: merged
WHO_IS_NEXT: controller
APPROVAL: review #500 by sysadmin (prgs-reviewer)
APPROVED_HEAD: a30a3ce4c3
MERGE_COMMIT: 620ed6e9a9
NEXT_ACTION: Reassess Issue #790 against the merged #760 behavior before allocation.
NEXT_PROMPT:

Reassess Gitea-Tools Issue #790 in Scaled-Tech-Consulting/Gitea-Tools on the prgs remote against the exact-owner expired-lock renewal behavior that PR #791 delivered for Issue #760, now on master at merge commit 620ed6e9a9550b8da2ceb82d9ab8744e8920490f. Re-read Issue #790 in full, then read the landed implementation — issue_lock_renewal.py, the renewal_sanctioned threading through issue_lock_store.assess_same_issue_lease_conflict, bind_session_lock, and issue_lock_worktree.assess_issue_lock_worktree, and the gitea_lock_issue call site — plus tests/test_issue_760_exact_owner_lease_renewal.py and tests/test_issue_760_mcp_renewal_path.py. Identify which of #790's requirements the landed renewal already satisfies and which remain outstanding, specifically its sliding heartbeat renewal, shared cross-role lease lifecycle, fencing-token design, and broader lease-generation semantics, none of which were implemented by #791. Note that #790 and #760 both edit assess_same_issue_lease_conflict and the issue_lock_store expiry path, so confirm no concurrent allocation exists before proceeding. Update the #790 plan and acceptance criteria to reflect the post-#760 baseline, then decide whether to allocate it to an author session. Do not implement #790 during this reassessment. Separately, hand the residual post-merge cleanup to a prgs-reconciler session with gitea.branch.delete capability proof: the moot merger lease on PR #791 (session 58066-cf14e86f060e, lease marker comment 13938, cleanup_allowed already true by dry run), the author branch fix/issue-760-exact-owner-renewal, and the worktrees branches/review-pr791-issue-760 and branches/baseline-master-pr791. Also consider filing the separate defect reviews #499 and #500 both flagged: tests/test_issue_702_review_findings_f1_f6.py::TestF2PreflightPathVerification asserts on os.environ and prints the entire environment on failure, exposing live credential values.

WHAT_HAPPENED: A merger session verified every pre-merge gate at head a30a3ce4c3, could not adopt the reviewer lease because it had expired, acquired a sanctioned merger lease pinned to that exact head through the documented recovery path, and performed the merge of PR #791 into master through native MCP, producing merge commit 620ed6e9a9 and closing Issue #760 through the PR's closing reference.
WHY: PR #791 carried a valid APPROVE review verdict at the exact current head with approval_at_current_head=true and no blocking change request, was conflict-free and mergeable with no required status checks, and gitea_assess_pr_sync_status routed it directly to the sanctioned merger workflow with merge_now.
RELATED_PRS: #791 (implements AC1-AC17 for this issue; merge commit 620ed6e9a9 on master). Issue #790 remains open and deliberately sequenced behind this work, untouched by this session.
BLOCKERS: None. Residual non-blocking follow-ups belong to the reconciler and the controller: the moot merger lease on PR #791, author branch and worktree cleanup, and the three non-blocking review notes carried forward from review #500 (F3 duplicated evidence gathering with both waivers grantable at once, F4 contention diagnostics regression, and the owning_pr_renewal_evidence negative-case coverage gap).
VALIDATION: Merger identity sysadmin, profile prgs-merger, role merger, independent from PR author jcwalker3; session bound to Scaled-Tech-Consulting/Gitea-Tools on prgs at gitea.prgs.cc. Canonical workflow loaded from skills/llm-project-workflow/workflows/review-merge-pr.md hash 263d0a6cb8a6, boundary clean. Runtime and master parity in parity at 3d0c13fa5a with restart_required=false. MCP namespace gitea-merger proven healthy through the live client namespace for gitea_merge_pr with blocks_merge_workflow=false. Pre-merge state at head a30a3ce4c3: PR open, base master, mergeable=true, approval_at_current_head=true, has_blocking_change_requests=false, review #500 dismissed=false and stale=false, review #499 preserved with quarantined=false, sync status merge_now, commits_behind=0, checks_required=false. The reviewer lease from session 7835-d4bf525741c2 had expired at 2026-07-22T05:37:14Z, so gitea_adopt_merger_pr_lease failed closed with "no active reviewer lease on PR #791 to adopt" and posted nothing; the documented recovery path for an expired reviewer lease, gitea_acquire_merger_pr_lease, was then used and returned lease session 58066-cf14e86f060e at comment 13938 pinned to the approved head. The live head was re-confirmed unchanged immediately before the merge. Merge performed with confirmation "MERGE PR 791", expected_head_sha a30a3ce4c3, method merge; lease_proof_sanctioned=true with lease_proof_kind sanctioned_acquire_merger. Read-after-write: PR #791 state closed, merged_at 2026-07-22T01:02:40-05:00, merge_commit_sha 620ed6e9a9550b8da2ceb82d9ab8744e8920490f; git ls-remote reports prgs/master at that same SHA; Issue #760 state closed with status:pr-open retired and verified residual-free; review #500 still visible and attributable to head a30a3ce4c3 with no blocking review remaining. A read-only gitea_cleanup_post_merge_moot_lease dry run reports lease_moot=true and cleanup_allowed=true, with required_role_kind reconciler, so the merger did not finalize it. No file was edited, no branch created, pushed, rebased, amended, or deleted, and no worktree was removed by this session. Issue #790 was not started, locked, branched, commented on, or otherwise mutated.
LAST_UPDATED_BY: sysadmin / prgs-merger (merger session)

[THREAD STATE LEDGER] Issue #760 / PR #791 — merge commit 620ed6e9a955 landed on prgs/master What is true now: - Server-side decision state: PR #791 merge performed through native MCP `gitea_merge_pr`; merge result: PR #791 merged via 'merge'. Merge commit `620ed6e9a9550b8da2ceb82d9ab8744e8920490f`. PR #791 state is closed with merged_at 2026-07-22T01:02:40-05:00. Issue #760 state is closed, closed automatically through the PR's "Closes #760" reference. - Local verdict/state: Merger session sysadmin / prgs-merger made no code edit, no branch mutation, no rebase, no amend, and no push. The author branch `fix/issue-760-exact-owner-renewal` is untouched at `a30a3ce4c37b2dde725301bef8b9ef8e04160088`. The stable control checkout stayed on master and clean. - Latest known validation: At head `a30a3ce4c37b2dde725301bef8b9ef8e04160088` — approval_visible=true, approval_at_current_head=true, latest_approved_head_sha equals the current head, has_blocking_change_requests=false, review_feedback_stale=false, quarantined_approvals_at_current_head=0. Review #500 carries the APPROVE review verdict recorded via the review API, with dismissed=false and stale=false. Review #499 (REQUEST_CHANGES at prior head `1a97ced133fbb16a560ea4c3bf71b97b7401950c`) is preserved in audit history with its full body intact and quarantined=false; its dismissed flag was set server-side by the superseding approval, not by any tool call. `gitea_assess_pr_sync_status` returned recommended_next_action merge_now with commits_behind=0, mergeable=true, has_conflicts=false, approval_valid_for_merge=true, stale_approval=false, checks_required=false and checks_status not_required. Read-after-write: `git ls-remote prgs refs/heads/master` reports `620ed6e9a9550b8da2ceb82d9ab8744e8920490f`. What changed: - PR #791 was merge-committed to prgs/master as `620ed6e9a9550b8da2ceb82d9ab8744e8920490f` using the repository's canonical merge method (`merge`), pinned with expected_head_sha `a30a3ce4c37b2dde725301bef8b9ef8e04160088`. - Issue #760 moved to closed state through the PR's closing reference. - The `status:pr-open` label was retired from Issue #760 at merge time and verified residual-free (labels_after: mcp, recovery, reliability, safety, type:bug, workflow-hardening). - The prgs-reviewer review decision lock was cleared after the merge event; audit comment 13943. - A merger PR lease was acquired at comment 13938 under session `58066-cf14e86f060e`, pinned to the exact approved head. What is blocked: - Blocker classification: no blocker Who/what acts next: - Next actor: controller - Required action: Reassess Issue #790 against the exact-owner lease renewal behavior delivered by this change before allocation. - Do not do: Do not start, lock, branch, or implement Issue #790 from a merger session. Do not delete the author branch `fix/issue-760-exact-owner-renewal`, the reviewer worktree `branches/review-pr791-issue-760`, or the baseline worktree `branches/baseline-master-pr791` from this session — post-merge lease finalization and branch/worktree cleanup both require the prgs-reconciler role and fail closed for a merger. ## Canonical Issue State STATE: merged WHO_IS_NEXT: controller APPROVAL: review #500 by sysadmin (prgs-reviewer) APPROVED_HEAD: a30a3ce4c37b2dde725301bef8b9ef8e04160088 MERGE_COMMIT: 620ed6e9a9550b8da2ceb82d9ab8744e8920490f NEXT_ACTION: Reassess Issue #790 against the merged #760 behavior before allocation. NEXT_PROMPT: ```text Reassess Gitea-Tools Issue #790 in Scaled-Tech-Consulting/Gitea-Tools on the prgs remote against the exact-owner expired-lock renewal behavior that PR #791 delivered for Issue #760, now on master at merge commit 620ed6e9a9550b8da2ceb82d9ab8744e8920490f. Re-read Issue #790 in full, then read the landed implementation — issue_lock_renewal.py, the renewal_sanctioned threading through issue_lock_store.assess_same_issue_lease_conflict, bind_session_lock, and issue_lock_worktree.assess_issue_lock_worktree, and the gitea_lock_issue call site — plus tests/test_issue_760_exact_owner_lease_renewal.py and tests/test_issue_760_mcp_renewal_path.py. Identify which of #790's requirements the landed renewal already satisfies and which remain outstanding, specifically its sliding heartbeat renewal, shared cross-role lease lifecycle, fencing-token design, and broader lease-generation semantics, none of which were implemented by #791. Note that #790 and #760 both edit assess_same_issue_lease_conflict and the issue_lock_store expiry path, so confirm no concurrent allocation exists before proceeding. Update the #790 plan and acceptance criteria to reflect the post-#760 baseline, then decide whether to allocate it to an author session. Do not implement #790 during this reassessment. Separately, hand the residual post-merge cleanup to a prgs-reconciler session with gitea.branch.delete capability proof: the moot merger lease on PR #791 (session 58066-cf14e86f060e, lease marker comment 13938, cleanup_allowed already true by dry run), the author branch fix/issue-760-exact-owner-renewal, and the worktrees branches/review-pr791-issue-760 and branches/baseline-master-pr791. Also consider filing the separate defect reviews #499 and #500 both flagged: tests/test_issue_702_review_findings_f1_f6.py::TestF2PreflightPathVerification asserts on os.environ and prints the entire environment on failure, exposing live credential values. ``` WHAT_HAPPENED: A merger session verified every pre-merge gate at head a30a3ce4c37b2dde725301bef8b9ef8e04160088, could not adopt the reviewer lease because it had expired, acquired a sanctioned merger lease pinned to that exact head through the documented recovery path, and performed the merge of PR #791 into master through native MCP, producing merge commit 620ed6e9a9550b8da2ceb82d9ab8744e8920490f and closing Issue #760 through the PR's closing reference. WHY: PR #791 carried a valid APPROVE review verdict at the exact current head with approval_at_current_head=true and no blocking change request, was conflict-free and mergeable with no required status checks, and gitea_assess_pr_sync_status routed it directly to the sanctioned merger workflow with merge_now. RELATED_PRS: #791 (implements AC1-AC17 for this issue; merge commit 620ed6e9a9550b8da2ceb82d9ab8744e8920490f on master). Issue #790 remains open and deliberately sequenced behind this work, untouched by this session. BLOCKERS: None. Residual non-blocking follow-ups belong to the reconciler and the controller: the moot merger lease on PR #791, author branch and worktree cleanup, and the three non-blocking review notes carried forward from review #500 (F3 duplicated evidence gathering with both waivers grantable at once, F4 contention diagnostics regression, and the owning_pr_renewal_evidence negative-case coverage gap). VALIDATION: Merger identity sysadmin, profile prgs-merger, role merger, independent from PR author jcwalker3; session bound to Scaled-Tech-Consulting/Gitea-Tools on prgs at gitea.prgs.cc. Canonical workflow loaded from skills/llm-project-workflow/workflows/review-merge-pr.md hash 263d0a6cb8a6, boundary clean. Runtime and master parity in parity at 3d0c13fa5a756ff94441dc57cf4e74318f45ba41 with restart_required=false. MCP namespace gitea-merger proven healthy through the live client namespace for gitea_merge_pr with blocks_merge_workflow=false. Pre-merge state at head a30a3ce4c37b2dde725301bef8b9ef8e04160088: PR open, base master, mergeable=true, approval_at_current_head=true, has_blocking_change_requests=false, review #500 dismissed=false and stale=false, review #499 preserved with quarantined=false, sync status merge_now, commits_behind=0, checks_required=false. The reviewer lease from session 7835-d4bf525741c2 had expired at 2026-07-22T05:37:14Z, so gitea_adopt_merger_pr_lease failed closed with "no active reviewer lease on PR #791 to adopt" and posted nothing; the documented recovery path for an expired reviewer lease, gitea_acquire_merger_pr_lease, was then used and returned lease session 58066-cf14e86f060e at comment 13938 pinned to the approved head. The live head was re-confirmed unchanged immediately before the merge. Merge performed with confirmation "MERGE PR 791", expected_head_sha a30a3ce4c37b2dde725301bef8b9ef8e04160088, method merge; lease_proof_sanctioned=true with lease_proof_kind sanctioned_acquire_merger. Read-after-write: PR #791 state closed, merged_at 2026-07-22T01:02:40-05:00, merge_commit_sha 620ed6e9a9550b8da2ceb82d9ab8744e8920490f; git ls-remote reports prgs/master at that same SHA; Issue #760 state closed with status:pr-open retired and verified residual-free; review #500 still visible and attributable to head a30a3ce4c37b2dde725301bef8b9ef8e04160088 with no blocking review remaining. A read-only gitea_cleanup_post_merge_moot_lease dry run reports lease_moot=true and cleanup_allowed=true, with required_role_kind reconciler, so the merger did not finalize it. No file was edited, no branch created, pushed, rebased, amended, or deleted, and no worktree was removed by this session. Issue #790 was not started, locked, branched, commented on, or otherwise mutated. LAST_UPDATED_BY: sysadmin / prgs-merger (merger session)

sysadmin commented 2026-07-22 01:27:11 -05:00

Owner

Copy Link

Copy Source

[THREAD STATE LEDGER] Issue #760 / PR #791 — post-merge reconciliation pass; worktrees cleared, source branch retained under live author ownership

What is true now:

• Server-side decision state: PR #791 state is closed with merged_at 2026-07-22T01:02:40-05:00; merge result: merge commit 620ed6e9a9550b8da2ceb82d9ab8744e8920490f landed on prgs/master, verified by git ls-remote prgs refs/heads/master. Its two parents are exactly 3d0c13fa5a756ff94441dc57cf4e74318f45ba41 (prior master) and a30a3ce4c37b2dde725301bef8b9ef8e04160088 (the reviewed source head), and git merge-base --is-ancestor a30a3ce4 620ed6e9 returns true. Issue #760 state is closed. Completion comment 13947 re-read in full and is consistent with live state.
• Local verdict/state: Reconciler session sysadmin / prgs-reconciler made no code edit, no commit, no push, and no branch-ref mutation. Issue #790 was not read for allocation, locked, branched, commented on, or otherwise touched.
• Latest known validation: gitea_cleanup_post_merge_moot_lease read-only dry run on PR #791 with expected_session_id 58066-cf14e86f060e, expected_candidate_head a30a3ce4c37b2dde725301bef8b9ef8e04160088 and expected_lease_comment_id 13938 returns lease_moot=false, cleanup_allowed=false, active_lease=null, and a reason stating that PR #791 is already in its terminal post-merge closed state and that "no active reviewer lease remains; nothing to clean". The merger lease from comment 13938 carried expires_at 2026-07-22T06:11:51Z and had lapsed by the 06:22:16Z assessment, so no terminal released marker was warranted and none was posted. Runtime identity sysadmin, profile prgs-reconciler, role reconciler, bound to Scaled-Tech-Consulting/Gitea-Tools on prgs; server-implementation parity in_parity=true at 3d0c13fa5a756ff94441dc57cf4e74318f45ba41 with restart_required=false; the stable control checkout stayed on master at that commit and clean throughout.

What changed:

• Reviewer worktree branches/review-pr791-issue-760 (detached at a30a3ce4, zero-entry git status --porcelain, no process holding it) removed via git worktree remove.
• Baseline worktree branches/baseline-master-pr791 (detached at 3d0c13fa, zero-entry git status --porcelain, no process holding it) removed via git worktree remove.
• Reconciler worktree branches/reconcile-pr791 created detached at 620ed6e9, because gitea_cleanup_merged_pr_branch fails closed on a root-checkout invocation and requires an explicit branches/ worktree path. It is clean and retained so the deferred branch deletion can be retried without repeating this step.
• No Gitea-side mutation was performed in this pass beyond this record: no label change, no branch deletion, no lease marker.

What is blocked:

• Blocker classification: queue/lease blocker
• Deletion of source branch fix/issue-760-exact-owner-renewal (remote head a30a3ce4c37b2dde725301bef8b9ef8e04160088, fully contained in master) is deferred. gitea_cleanup_merged_pr_branch assessed safe_to_delete=true with an empty block_reasons list, then failed closed with blocker_kind active_branch_ownership and blocking_categories author_lease, author_session, worktree_binding. Cause: the durable author lock ~/.cache/gitea-tools/issue-locks/prgs-Scaled-Tech-Consulting-Gitea-Tools-760.json carries work_lease.expires_at 2026-07-22T08:19:08Z, still live by wall clock, with recorded pid 39849 which is an MCP daemon process that remains alive, and worktree branches/fix-issue-760-exact-owner-renewal still checked out on that branch. This is precisely the daemon-liveness condition Issue #760 documents. A reconciler may not clear it: no hand-editing of the lock file, no author namespace, no worktree removal while the lease is live.
• Operator window for the retry opens at 2026-07-22T08:19:08Z, after which the lease lapses, the author worktree may be removed, and the deletion may be re-run from branches/reconcile-pr791.

Who/what acts next:

• Next actor: controller
• Required action: Reassess Issue #790 against the exact-owner lease renewal behavior delivered for Issue #760, now on master at 620ed6e9a9550b8da2ceb82d9ab8744e8920490f.
• Do not do: Do not reopen Issue #760. Do not hand-edit or delete the issue-lock JSON for 760, and do not remove worktree branches/fix-issue-760-exact-owner-renewal while its lease is live. Do not delete branch fix/issue-760-exact-owner-renewal outside the sanctioned reconciler path.

Canonical Issue State

STATE: closed-with-residual-cleanup
WHO_IS_NEXT: controller
MERGE_COMMIT: 620ed6e9a9
APPROVED_HEAD: a30a3ce4c3
NEXT_ACTION: Reassess Issue #790 against the landed renewal behavior, and schedule the deferred source-branch deletion after the author lease lapses at 2026-07-22T08:19:08Z.
NEXT_PROMPT:

Reassess Gitea-Tools Issue #790 in Scaled-Tech-Consulting/Gitea-Tools on the prgs remote against the exact-owner expired-lock renewal behavior PR #791 delivered for Issue #760, now on master at 620ed6e9a9550b8da2ceb82d9ab8744e8920490f. Re-read Issue #790 in full, then read issue_lock_renewal.py, the renewal_sanctioned threading through issue_lock_store.assess_same_issue_lease_conflict, bind_session_lock and issue_lock_worktree.assess_issue_lock_worktree, the gitea_lock_issue call site, and tests/test_issue_760_exact_owner_lease_renewal.py plus tests/test_issue_760_mcp_renewal_path.py. Separate which of #790's requirements the landed behavior already satisfies from what remains outstanding: sliding heartbeat renewal, shared cross-role lease lifecycle, fencing tokens, and broader lease-generation semantics, none of which PR #791 implemented. Both issues edit assess_same_issue_lease_conflict and the issue_lock_store expiry path, so confirm no concurrent allocation exists first. Do not implement #790 during the reassessment. Separately, after 2026-07-22T08:19:08Z when the Issue #760 author work_lease lapses, dispatch a prgs-reconciler session to remove worktree branches/fix-issue-760-exact-owner-renewal and then re-run gitea_cleanup_merged_pr_branch for PR 791 on branch fix/issue-760-exact-owner-renewal from worktree branches/reconcile-pr791, copying the confirmation string out of the tool's own expected_confirmation field.

WHAT_HAPPENED: A prgs-reconciler session verified identity, binding, namespace health and parity, re-read PR #791, Issue #760 and completion comment 13947, confirmed the merge commit's parentage against the reviewed source head, assessed the outstanding merger lease read-only, removed the two clean detached session worktrees for this PR, and attempted the sanctioned source-branch deletion, which failed closed on live author branch ownership.
WHY: The merger lease had already lapsed by wall clock, so the sanctioned cleanup tool reported nothing to clean and no marker was appropriate; the two session worktrees were provably clean, contained and unowned, while the source branch remains protected by a live author lease, a live recorded daemon pid, and a bound worktree.
ISSUE: #760
RELATED_PRS: #791 (closed, merge commit 620ed6e9a9, source head a30a3ce4c37b2dde725301bef8b9ef8e04160088; source branch retained pending lease expiry). Issue #790 remains open and untouched by this session.
BLOCKERS: Source-branch deletion deferred behind the live Issue #760 author work_lease expiring 2026-07-22T08:19:08Z; blocker classification queue/lease blocker. No other residual item.
VALIDATION: Identity sysadmin, profile prgs-reconciler, role reconciler, session bound to Scaled-Tech-Consulting/Gitea-Tools on prgs at gitea.prgs.cc; workflow load proof present with boundary clean; server-implementation parity in_parity true at 3d0c13fa5a with stale false and restart_required false. PR #791 read live: state closed, merged_at 2026-07-22T01:02:40-05:00, merge_commit_sha 620ed6e9a9, base master, head branch fix/issue-760-exact-owner-renewal. Merge commit parents read locally as 3d0c13fa5a and a30a3ce4c3, and git merge-base --is-ancestor a30a3ce4 620ed6e9 returns true. Issue #760 read live: state closed, labels mcp, recovery, reliability, safety, type:bug, workflow-hardening, with no residual status:pr-open. git ls-remote prgs reports master at 620ed6e9a9 and fix/issue-760-exact-owner-renewal at a30a3ce4c3. gitea_cleanup_post_merge_moot_lease dry run returned lease_moot false, cleanup_allowed false, active_lease null; apply was never invoked. Preflight order gitea_whoami then gitea_resolve_task_capability(cleanup_merged_pr_branch) with nothing in between preceded each deletion attempt; capability resolved allowed_in_current_session true for gitea.branch.delete. Both removed worktrees reported zero porcelain entries and no owning process immediately before removal. Issue #790 was not opened for allocation, locked, branched, labelled, or commented on.
LAST_UPDATED_BY: sysadmin / prgs-reconciler (reconciler session)

[THREAD STATE LEDGER] Issue #760 / PR #791 — post-merge reconciliation pass; worktrees cleared, source branch retained under live author ownership What is true now: - Server-side decision state: PR #791 state is closed with merged_at 2026-07-22T01:02:40-05:00; merge result: merge commit `620ed6e9a9550b8da2ceb82d9ab8744e8920490f` landed on prgs/master, verified by `git ls-remote prgs refs/heads/master`. Its two parents are exactly `3d0c13fa5a756ff94441dc57cf4e74318f45ba41` (prior master) and `a30a3ce4c37b2dde725301bef8b9ef8e04160088` (the reviewed source head), and `git merge-base --is-ancestor a30a3ce4 620ed6e9` returns true. Issue #760 state is closed. Completion comment 13947 re-read in full and is consistent with live state. - Local verdict/state: Reconciler session sysadmin / prgs-reconciler made no code edit, no commit, no push, and no branch-ref mutation. Issue #790 was not read for allocation, locked, branched, commented on, or otherwise touched. - Latest known validation: `gitea_cleanup_post_merge_moot_lease` read-only dry run on PR #791 with expected_session_id `58066-cf14e86f060e`, expected_candidate_head `a30a3ce4c37b2dde725301bef8b9ef8e04160088` and expected_lease_comment_id `13938` returns lease_moot=false, cleanup_allowed=false, active_lease=null, and a reason stating that PR #791 is already in its terminal post-merge closed state and that "no active reviewer lease remains; nothing to clean". The merger lease from comment 13938 carried expires_at 2026-07-22T06:11:51Z and had lapsed by the 06:22:16Z assessment, so no terminal released marker was warranted and none was posted. Runtime identity sysadmin, profile prgs-reconciler, role reconciler, bound to Scaled-Tech-Consulting/Gitea-Tools on prgs; server-implementation parity in_parity=true at `3d0c13fa5a756ff94441dc57cf4e74318f45ba41` with restart_required=false; the stable control checkout stayed on master at that commit and clean throughout. What changed: - Reviewer worktree `branches/review-pr791-issue-760` (detached at `a30a3ce4`, zero-entry `git status --porcelain`, no process holding it) removed via `git worktree remove`. - Baseline worktree `branches/baseline-master-pr791` (detached at `3d0c13fa`, zero-entry `git status --porcelain`, no process holding it) removed via `git worktree remove`. - Reconciler worktree `branches/reconcile-pr791` created detached at `620ed6e9`, because `gitea_cleanup_merged_pr_branch` fails closed on a root-checkout invocation and requires an explicit `branches/` worktree path. It is clean and retained so the deferred branch deletion can be retried without repeating this step. - No Gitea-side mutation was performed in this pass beyond this record: no label change, no branch deletion, no lease marker. What is blocked: - Blocker classification: queue/lease blocker - Deletion of source branch `fix/issue-760-exact-owner-renewal` (remote head `a30a3ce4c37b2dde725301bef8b9ef8e04160088`, fully contained in master) is deferred. `gitea_cleanup_merged_pr_branch` assessed safe_to_delete=true with an empty block_reasons list, then failed closed with blocker_kind `active_branch_ownership` and blocking_categories `author_lease`, `author_session`, `worktree_binding`. Cause: the durable author lock `~/.cache/gitea-tools/issue-locks/prgs-Scaled-Tech-Consulting-Gitea-Tools-760.json` carries work_lease.expires_at `2026-07-22T08:19:08Z`, still live by wall clock, with recorded pid 39849 which is an MCP daemon process that remains alive, and worktree `branches/fix-issue-760-exact-owner-renewal` still checked out on that branch. This is precisely the daemon-liveness condition Issue #760 documents. A reconciler may not clear it: no hand-editing of the lock file, no author namespace, no worktree removal while the lease is live. - Operator window for the retry opens at `2026-07-22T08:19:08Z`, after which the lease lapses, the author worktree may be removed, and the deletion may be re-run from `branches/reconcile-pr791`. Who/what acts next: - Next actor: controller - Required action: Reassess Issue #790 against the exact-owner lease renewal behavior delivered for Issue #760, now on master at `620ed6e9a9550b8da2ceb82d9ab8744e8920490f`. - Do not do: Do not reopen Issue #760. Do not hand-edit or delete the issue-lock JSON for 760, and do not remove worktree `branches/fix-issue-760-exact-owner-renewal` while its lease is live. Do not delete branch `fix/issue-760-exact-owner-renewal` outside the sanctioned reconciler path. ## Canonical Issue State STATE: closed-with-residual-cleanup WHO_IS_NEXT: controller MERGE_COMMIT: 620ed6e9a9550b8da2ceb82d9ab8744e8920490f APPROVED_HEAD: a30a3ce4c37b2dde725301bef8b9ef8e04160088 NEXT_ACTION: Reassess Issue #790 against the landed renewal behavior, and schedule the deferred source-branch deletion after the author lease lapses at 2026-07-22T08:19:08Z. NEXT_PROMPT: ```text Reassess Gitea-Tools Issue #790 in Scaled-Tech-Consulting/Gitea-Tools on the prgs remote against the exact-owner expired-lock renewal behavior PR #791 delivered for Issue #760, now on master at 620ed6e9a9550b8da2ceb82d9ab8744e8920490f. Re-read Issue #790 in full, then read issue_lock_renewal.py, the renewal_sanctioned threading through issue_lock_store.assess_same_issue_lease_conflict, bind_session_lock and issue_lock_worktree.assess_issue_lock_worktree, the gitea_lock_issue call site, and tests/test_issue_760_exact_owner_lease_renewal.py plus tests/test_issue_760_mcp_renewal_path.py. Separate which of #790's requirements the landed behavior already satisfies from what remains outstanding: sliding heartbeat renewal, shared cross-role lease lifecycle, fencing tokens, and broader lease-generation semantics, none of which PR #791 implemented. Both issues edit assess_same_issue_lease_conflict and the issue_lock_store expiry path, so confirm no concurrent allocation exists first. Do not implement #790 during the reassessment. Separately, after 2026-07-22T08:19:08Z when the Issue #760 author work_lease lapses, dispatch a prgs-reconciler session to remove worktree branches/fix-issue-760-exact-owner-renewal and then re-run gitea_cleanup_merged_pr_branch for PR 791 on branch fix/issue-760-exact-owner-renewal from worktree branches/reconcile-pr791, copying the confirmation string out of the tool's own expected_confirmation field. ``` WHAT_HAPPENED: A prgs-reconciler session verified identity, binding, namespace health and parity, re-read PR #791, Issue #760 and completion comment 13947, confirmed the merge commit's parentage against the reviewed source head, assessed the outstanding merger lease read-only, removed the two clean detached session worktrees for this PR, and attempted the sanctioned source-branch deletion, which failed closed on live author branch ownership. WHY: The merger lease had already lapsed by wall clock, so the sanctioned cleanup tool reported nothing to clean and no marker was appropriate; the two session worktrees were provably clean, contained and unowned, while the source branch remains protected by a live author lease, a live recorded daemon pid, and a bound worktree. ISSUE: #760 RELATED_PRS: #791 (closed, merge commit 620ed6e9a9550b8da2ceb82d9ab8744e8920490f, source head a30a3ce4c37b2dde725301bef8b9ef8e04160088; source branch retained pending lease expiry). Issue #790 remains open and untouched by this session. BLOCKERS: Source-branch deletion deferred behind the live Issue #760 author work_lease expiring 2026-07-22T08:19:08Z; blocker classification queue/lease blocker. No other residual item. VALIDATION: Identity sysadmin, profile prgs-reconciler, role reconciler, session bound to Scaled-Tech-Consulting/Gitea-Tools on prgs at gitea.prgs.cc; workflow load proof present with boundary clean; server-implementation parity in_parity true at 3d0c13fa5a756ff94441dc57cf4e74318f45ba41 with stale false and restart_required false. PR #791 read live: state closed, merged_at 2026-07-22T01:02:40-05:00, merge_commit_sha 620ed6e9a9550b8da2ceb82d9ab8744e8920490f, base master, head branch fix/issue-760-exact-owner-renewal. Merge commit parents read locally as 3d0c13fa5a756ff94441dc57cf4e74318f45ba41 and a30a3ce4c37b2dde725301bef8b9ef8e04160088, and git merge-base --is-ancestor a30a3ce4 620ed6e9 returns true. Issue #760 read live: state closed, labels mcp, recovery, reliability, safety, type:bug, workflow-hardening, with no residual status:pr-open. git ls-remote prgs reports master at 620ed6e9a9550b8da2ceb82d9ab8744e8920490f and fix/issue-760-exact-owner-renewal at a30a3ce4c37b2dde725301bef8b9ef8e04160088. gitea_cleanup_post_merge_moot_lease dry run returned lease_moot false, cleanup_allowed false, active_lease null; apply was never invoked. Preflight order gitea_whoami then gitea_resolve_task_capability(cleanup_merged_pr_branch) with nothing in between preceded each deletion attempt; capability resolved allowed_in_current_session true for gitea.branch.delete. Both removed worktrees reported zero porcelain entries and no owning process immediately before removal. Issue #790 was not opened for allocation, locked, branched, labelled, or commented on. LAST_UPDATED_BY: sysadmin / prgs-reconciler (reconciler session)

sysadmin commented 2026-07-22 01:45:33 -05:00

Owner

Copy Link

Copy Source

[THREAD STATE LEDGER] Issue #760 / PR #791 — deferred cleanup re-attempted; author lease has NOT yet lapsed, source branch still retained

Supersedes the residual-cleanup status in comment 13952. The retry window recorded there has not opened.

What is true now:

• Server-side decision state: PR #791 state is closed with merged_at 2026-07-22T01:02:40-05:00 and merge_commit_sha 620ed6e9a9550b8da2ceb82d9ab8744e8920490f, base master, head branch fix/issue-760-exact-owner-renewal. Issue #760 state is closed; labels mcp, recovery, reliability, safety, type:bug, workflow-hardening, with no residual status:pr-open. Completion comment 13947 and reconciliation comment 13952 were re-read in full and remain consistent with live state.
• Local verdict/state: Reconciler session sysadmin / prgs-reconciler made no code edit, no commit, no push, no branch-ref mutation, and no Gitea-side mutation beyond this record. The stable control checkout stayed on master at 620ed6e9a9550b8da2ceb82d9ab8744e8920490f with a zero-entry git status --porcelain throughout.
• Latest known validation: git ls-remote prgs reports master at 620ed6e9a9550b8da2ceb82d9ab8744e8920490f and fix/issue-760-exact-owner-renewal at a30a3ce4c37b2dde725301bef8b9ef8e04160088. Merge commit parents read locally as 3d0c13fa5a756ff94441dc57cf4e74318f45ba41 and a30a3ce4c37b2dde725301bef8b9ef8e04160088; git merge-base --is-ancestor a30a3ce4 620ed6e9 returns true, as does the same check for the superseded head 1a97ced1. No control-plane lease row exists for issue 760 or PR 791 in either direction; gitea_list_workflow_leases with include_non_active returned 14 rows, none for work_number 760 or 791. No live PR #791 lease remains.

What changed:

• Obsolete reviewer worktree branches/review-fix-issue-760-exact-owner-renewal (detached at 1a97ced133fbb16a560ea4c3bf71b97b7401950c, zero-entry porcelain, no owning process, head contained in master, classified detached_review_leftover with removable true) was removed via git worktree remove. This is a different path from the branches/review-pr791-issue-760 worktree removed in comment 13952; both existed.
• Before/after gitea_capture_branches_worktree_snapshot reconcile exactly: branch directory count 51 to 50, registered branches worktrees 44 to 43, removed set is exactly that one path, added set empty, and no classification or head-SHA drift on any retained entry.
• Nothing else was removed, deleted, or mutated.

What is blocked:

• Blocker classification: queue/lease blocker
• Deletion of source branch fix/issue-760-exact-owner-renewal and removal of author worktree branches/fix-issue-760-exact-owner-renewal remain deferred. The durable author lock ~/.cache/gitea-tools/issue-locks/prgs-Scaled-Tech-Consulting-Gitea-Tools-760.json carries work_lease.expires_at 2026-07-22T08:19:08Z. Wall clock at assessment was 2026-07-22T06:39:43Z, so the lease is still live with roughly 1 hour 39 minutes remaining. It was neither renewed nor replaced: lock_generation is still 1, created_at and last_heartbeat_at are both 2026-07-22T04:19:08Z, claimant is still jcwalker3 / prgs-author, and recorded pid 39849 is unchanged and still alive as the long-lived MCP daemon started 2026-07-21 23:22:08 local.
• Because the lease is live, gitea_cleanup_merged_pr_branch was deliberately NOT invoked in this pass; the read-only audit on its own proves the call would fail closed on active_branch_ownership. gitea_audit_worktree_cleanup independently classifies the author worktree active_issue_work with removable false and preserve true, despite it being clean, on the locked branch, and fully contained in master.
• No process kill, no lock-file edit, no forced deletion, and no worktree removal under a live lease was attempted. This is the exact daemon-liveness condition Issue #760 documents and Issue #790 exists to correct.
• The operator window opens at 2026-07-22T08:19:08Z. Ownership must be re-verified at that time rather than assumed lapsed.

Who/what acts next:

• Next actor: controller
• Required action: Reassess Issue #790 against the exact-owner lease renewal behavior delivered for Issue #760, and re-dispatch the residual branch cleanup after the author lease actually lapses.
• Do not do: Do not reopen Issue #760. Do not hand-edit or delete the issue-lock JSON for 760. Do not remove branches/fix-issue-760-exact-owner-renewal or delete fix/issue-760-exact-owner-renewal while the lease is live. Do not remove branches/reconcile-pr791; it is retained on purpose as the invocation point for the deferred deletion, because gitea_cleanup_merged_pr_branch fails closed on a root-checkout invocation.

Canonical Issue State

STATE: closed-with-residual-cleanup
WHO_IS_NEXT: controller
MERGE_COMMIT: 620ed6e9a9
APPROVED_HEAD: a30a3ce4c3
NEXT_ACTION: After 2026-07-22T08:19:08Z, re-verify that the Issue #760 author lease actually lapsed and was not renewed, then complete the deferred source-branch and author-worktree cleanup.
NEXT_PROMPT:

Complete the residual post-merge cleanup for Gitea-Tools PR #791 / Issue #760 in Scaled-Tech-Consulting/Gitea-Tools on the prgs remote. Do not assume the lease lapsed because 2026-07-22T08:19:08Z has passed. First re-read ~/.cache/gitea-tools/issue-locks/prgs-Scaled-Tech-Consulting-Gitea-Tools-760.json and confirm work_lease.expires_at is still 2026-07-22T08:19:08Z, lock_generation is still 1, last_heartbeat_at is still 2026-07-22T04:19:08Z, and the claimant is still jcwalker3 / prgs-author; if any of those advanced, the lease was renewed and cleanup stays blocked. Then confirm current wall clock is past the expiry, gitea_audit_worktree_cleanup no longer classifies branches/fix-issue-760-exact-owner-renewal as active_issue_work, no process holds the worktree, the worktree is clean on fix/issue-760-exact-owner-renewal at a30a3ce4c37b2dde725301bef8b9ef8e04160088, and that head is still contained in master 620ed6e9a9550b8da2ceb82d9ab8744e8920490f. Only then remove worktree branches/fix-issue-760-exact-owner-renewal, and run gitea_cleanup_merged_pr_branch for PR 791 on branch fix/issue-760-exact-owner-renewal from worktree branches/reconcile-pr791, in the preflight order gitea_whoami then gitea_resolve_task_capability with task cleanup_merged_pr_branch and nothing in between, copying the confirmation string out of the tool's own expected_confirmation field. Remove branches/reconcile-pr791 last, after the deletion succeeds. Do not reopen Issue #760 and do not begin Issue #790.

WHAT_HAPPENED: A prgs-reconciler session verified identity, binding, namespace health and runtime/master parity, re-read PR #791, Issue #760 and comments 13947 and 13952, re-verified the merge commit and its parentage, confirmed no control-plane lease and no live PR #791 lease exist, and found the author issue lock still live and unrenewed with roughly 1 hour 39 minutes remaining. It removed one provably obsolete reviewer worktree and stopped short of every artifact protected by the live lease.
WHY: The retry window recorded in comment 13952 opens at 2026-07-22T08:19:08Z and had not yet opened at 2026-07-22T06:39:43Z, so the source branch and author worktree remain under live, unrenewed author ownership and cannot be cleaned through any sanctioned path.
ISSUE: #760
RELATED_PRS: #791 (state closed, merge commit 620ed6e9a9, source head a30a3ce4c37b2dde725301bef8b9ef8e04160088; source branch retained under live author lease). Issue #790 remains open and untouched by this session.
BLOCKERS: Source-branch deletion and author-worktree removal deferred behind the live Issue #760 author work_lease expiring 2026-07-22T08:19:08Z; blocker classification queue/lease blocker. No other residual item.
VALIDATION: Identity sysadmin, profile prgs-reconciler, role reconciler, bound to Scaled-Tech-Consulting/Gitea-Tools on prgs at gitea.prgs.cc, identity_match true. Server-implementation parity in_parity true at 620ed6e9a9 with stale false and restart_required false; runtime checkout on master, clean, workspace_roots_aligned true. MCP namespace gitea-reconciler proven healthy through the live client namespace for gitea_cleanup_merged_pr_branch with blocks_merge_workflow false. PR #791 read live in the closed post-merge state and Issue #760 read live in the closed state. git ls-remote prgs read after all local work: master 620ed6e9a9, fix/issue-760-exact-owner-renewal a30a3ce4c3. Local branch fix/issue-760-exact-owner-renewal still present at a30a3ce4. Author lock read directly from disk and unchanged from the values recorded in comment 13881; recorded pid 39849 confirmed alive via kill -0. lsof reported no process holding any of the three PR #791 worktree paths. Worktree snapshots before and after reconcile with a single explained removal and no drift. Preflight order gitea_whoami then gitea_resolve_task_capability with task comment_issue and nothing in between preceded this comment; allowed_in_current_session true. Issue #790 was read once read-only and confirmed to be in the open state with its label set unchanged; it was not locked, branched, labelled, commented on, or otherwise mutated.
LAST_UPDATED_BY: sysadmin / prgs-reconciler (reconciler session)

[THREAD STATE LEDGER] Issue #760 / PR #791 — deferred cleanup re-attempted; author lease has NOT yet lapsed, source branch still retained Supersedes the residual-cleanup status in comment 13952. The retry window recorded there has not opened. What is true now: - Server-side decision state: PR #791 state is closed with merged_at 2026-07-22T01:02:40-05:00 and merge_commit_sha `620ed6e9a9550b8da2ceb82d9ab8744e8920490f`, base master, head branch `fix/issue-760-exact-owner-renewal`. Issue #760 state is closed; labels mcp, recovery, reliability, safety, type:bug, workflow-hardening, with no residual `status:pr-open`. Completion comment 13947 and reconciliation comment 13952 were re-read in full and remain consistent with live state. - Local verdict/state: Reconciler session sysadmin / prgs-reconciler made no code edit, no commit, no push, no branch-ref mutation, and no Gitea-side mutation beyond this record. The stable control checkout stayed on master at `620ed6e9a9550b8da2ceb82d9ab8744e8920490f` with a zero-entry `git status --porcelain` throughout. - Latest known validation: `git ls-remote prgs` reports master at `620ed6e9a9550b8da2ceb82d9ab8744e8920490f` and `fix/issue-760-exact-owner-renewal` at `a30a3ce4c37b2dde725301bef8b9ef8e04160088`. Merge commit parents read locally as `3d0c13fa5a756ff94441dc57cf4e74318f45ba41` and `a30a3ce4c37b2dde725301bef8b9ef8e04160088`; `git merge-base --is-ancestor a30a3ce4 620ed6e9` returns true, as does the same check for the superseded head `1a97ced1`. No control-plane lease row exists for issue 760 or PR 791 in either direction; `gitea_list_workflow_leases` with include_non_active returned 14 rows, none for work_number 760 or 791. No live PR #791 lease remains. What changed: - Obsolete reviewer worktree `branches/review-fix-issue-760-exact-owner-renewal` (detached at `1a97ced133fbb16a560ea4c3bf71b97b7401950c`, zero-entry porcelain, no owning process, head contained in master, classified `detached_review_leftover` with removable true) was removed via `git worktree remove`. This is a different path from the `branches/review-pr791-issue-760` worktree removed in comment 13952; both existed. - Before/after `gitea_capture_branches_worktree_snapshot` reconcile exactly: branch directory count 51 to 50, registered branches worktrees 44 to 43, removed set is exactly that one path, added set empty, and no classification or head-SHA drift on any retained entry. - Nothing else was removed, deleted, or mutated. What is blocked: - Blocker classification: queue/lease blocker - Deletion of source branch `fix/issue-760-exact-owner-renewal` and removal of author worktree `branches/fix-issue-760-exact-owner-renewal` remain deferred. The durable author lock `~/.cache/gitea-tools/issue-locks/prgs-Scaled-Tech-Consulting-Gitea-Tools-760.json` carries `work_lease.expires_at` `2026-07-22T08:19:08Z`. Wall clock at assessment was `2026-07-22T06:39:43Z`, so the lease is still live with roughly 1 hour 39 minutes remaining. It was neither renewed nor replaced: `lock_generation` is still 1, `created_at` and `last_heartbeat_at` are both `2026-07-22T04:19:08Z`, claimant is still jcwalker3 / prgs-author, and recorded pid 39849 is unchanged and still alive as the long-lived MCP daemon started 2026-07-21 23:22:08 local. - Because the lease is live, `gitea_cleanup_merged_pr_branch` was deliberately NOT invoked in this pass; the read-only audit on its own proves the call would fail closed on `active_branch_ownership`. `gitea_audit_worktree_cleanup` independently classifies the author worktree `active_issue_work` with removable false and preserve true, despite it being clean, on the locked branch, and fully contained in master. - No process kill, no lock-file edit, no forced deletion, and no worktree removal under a live lease was attempted. This is the exact daemon-liveness condition Issue #760 documents and Issue #790 exists to correct. - The operator window opens at `2026-07-22T08:19:08Z`. Ownership must be re-verified at that time rather than assumed lapsed. Who/what acts next: - Next actor: controller - Required action: Reassess Issue #790 against the exact-owner lease renewal behavior delivered for Issue #760, and re-dispatch the residual branch cleanup after the author lease actually lapses. - Do not do: Do not reopen Issue #760. Do not hand-edit or delete the issue-lock JSON for 760. Do not remove `branches/fix-issue-760-exact-owner-renewal` or delete `fix/issue-760-exact-owner-renewal` while the lease is live. Do not remove `branches/reconcile-pr791`; it is retained on purpose as the invocation point for the deferred deletion, because `gitea_cleanup_merged_pr_branch` fails closed on a root-checkout invocation. ## Canonical Issue State STATE: closed-with-residual-cleanup WHO_IS_NEXT: controller MERGE_COMMIT: 620ed6e9a9550b8da2ceb82d9ab8744e8920490f APPROVED_HEAD: a30a3ce4c37b2dde725301bef8b9ef8e04160088 NEXT_ACTION: After 2026-07-22T08:19:08Z, re-verify that the Issue #760 author lease actually lapsed and was not renewed, then complete the deferred source-branch and author-worktree cleanup. NEXT_PROMPT: ```text Complete the residual post-merge cleanup for Gitea-Tools PR #791 / Issue #760 in Scaled-Tech-Consulting/Gitea-Tools on the prgs remote. Do not assume the lease lapsed because 2026-07-22T08:19:08Z has passed. First re-read ~/.cache/gitea-tools/issue-locks/prgs-Scaled-Tech-Consulting-Gitea-Tools-760.json and confirm work_lease.expires_at is still 2026-07-22T08:19:08Z, lock_generation is still 1, last_heartbeat_at is still 2026-07-22T04:19:08Z, and the claimant is still jcwalker3 / prgs-author; if any of those advanced, the lease was renewed and cleanup stays blocked. Then confirm current wall clock is past the expiry, gitea_audit_worktree_cleanup no longer classifies branches/fix-issue-760-exact-owner-renewal as active_issue_work, no process holds the worktree, the worktree is clean on fix/issue-760-exact-owner-renewal at a30a3ce4c37b2dde725301bef8b9ef8e04160088, and that head is still contained in master 620ed6e9a9550b8da2ceb82d9ab8744e8920490f. Only then remove worktree branches/fix-issue-760-exact-owner-renewal, and run gitea_cleanup_merged_pr_branch for PR 791 on branch fix/issue-760-exact-owner-renewal from worktree branches/reconcile-pr791, in the preflight order gitea_whoami then gitea_resolve_task_capability with task cleanup_merged_pr_branch and nothing in between, copying the confirmation string out of the tool's own expected_confirmation field. Remove branches/reconcile-pr791 last, after the deletion succeeds. Do not reopen Issue #760 and do not begin Issue #790. ``` WHAT_HAPPENED: A prgs-reconciler session verified identity, binding, namespace health and runtime/master parity, re-read PR #791, Issue #760 and comments 13947 and 13952, re-verified the merge commit and its parentage, confirmed no control-plane lease and no live PR #791 lease exist, and found the author issue lock still live and unrenewed with roughly 1 hour 39 minutes remaining. It removed one provably obsolete reviewer worktree and stopped short of every artifact protected by the live lease. WHY: The retry window recorded in comment 13952 opens at 2026-07-22T08:19:08Z and had not yet opened at 2026-07-22T06:39:43Z, so the source branch and author worktree remain under live, unrenewed author ownership and cannot be cleaned through any sanctioned path. ISSUE: #760 RELATED_PRS: #791 (state closed, merge commit 620ed6e9a9550b8da2ceb82d9ab8744e8920490f, source head a30a3ce4c37b2dde725301bef8b9ef8e04160088; source branch retained under live author lease). Issue #790 remains open and untouched by this session. BLOCKERS: Source-branch deletion and author-worktree removal deferred behind the live Issue #760 author work_lease expiring 2026-07-22T08:19:08Z; blocker classification queue/lease blocker. No other residual item. VALIDATION: Identity sysadmin, profile prgs-reconciler, role reconciler, bound to Scaled-Tech-Consulting/Gitea-Tools on prgs at gitea.prgs.cc, identity_match true. Server-implementation parity in_parity true at 620ed6e9a9550b8da2ceb82d9ab8744e8920490f with stale false and restart_required false; runtime checkout on master, clean, workspace_roots_aligned true. MCP namespace gitea-reconciler proven healthy through the live client namespace for gitea_cleanup_merged_pr_branch with blocks_merge_workflow false. PR #791 read live in the closed post-merge state and Issue #760 read live in the closed state. git ls-remote prgs read after all local work: master 620ed6e9a9550b8da2ceb82d9ab8744e8920490f, fix/issue-760-exact-owner-renewal a30a3ce4c37b2dde725301bef8b9ef8e04160088. Local branch fix/issue-760-exact-owner-renewal still present at a30a3ce4. Author lock read directly from disk and unchanged from the values recorded in comment 13881; recorded pid 39849 confirmed alive via kill -0. lsof reported no process holding any of the three PR #791 worktree paths. Worktree snapshots before and after reconcile with a single explained removal and no drift. Preflight order gitea_whoami then gitea_resolve_task_capability with task comment_issue and nothing in between preceded this comment; allowed_in_current_session true. Issue #790 was read once read-only and confirmed to be in the open state with its label set unchanged; it was not locked, branched, labelled, commented on, or otherwise mutated. LAST_UPDATED_BY: sysadmin / prgs-reconciler (reconciler session)

sysadmin referenced this issue 2026-07-22 02:22:32 -05:00

Unify task leases with sliding heartbeats and safe terminal dead-owner recovery #790

jcwalker3 referenced this issue from a commit 2026-07-22 03:20:22 -05:00

feat(lease): make the author task heartbeat load-bearing (#790 Slice A)

jcwalker3 referenced this issue 2026-07-22 03:27:19 -05:00

Terminal retirement of author issue leases (Issue #790 Slice B) #792

jcwalker3 referenced this issue 2026-07-22 03:28:20 -05:00

Complete lease fencing and align remaining task classes (Issue #790 Slice C) #793

jcwalker3 referenced this issue 2026-07-22 03:30:02 -05:00

Unify task leases with sliding heartbeats and safe terminal dead-owner recovery #790

jcwalker3 referenced this issue 2026-07-22 03:31:25 -05:00

feat(lease): make the author task heartbeat load-bearing (Closes #790, Slice A) #794

jcwalker3 referenced this issue 2026-07-22 13:54:40 -05:00

Web Console: Project registry API evolution (Phase 1) #635

jcwalker3 referenced this issue 2026-07-22 15:23:27 -05:00

Web Console: Project registry API evolution (Phase 1) #635

jcwalker3 referenced this issue 2026-07-22 15:25:29 -05:00

No sanctioned recovery for a dirty author worktree: uncommitted implementation cannot be checkpointed, and every publication gate demands the clean worktree only publication can produce #812

jcwalker3 referenced this issue 2026-07-22 15:30:50 -05:00

No sanctioned recovery for a dirty author worktree: uncommitted implementation cannot be checkpointed, and every publication gate demands the clean worktree only publication can produce #812

jcwalker3 referenced this issue 2026-07-22 17:07:02 -05:00

gitea_publish_unpublished_issue_branch fails closed for every caller: its own preflight discards the worktree_path it requires #816

jcwalker3 referenced this issue 2026-07-23 22:35:14 -05:00

Add sanctioned dirty-preserving same-claimant author-session rebind #864

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 this issue 2026-07-26 10:49:44 -05:00

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

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

sysadmin referenced this issue 2026-07-27 18:17:37 -05:00

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

jcwalker3 referenced this issue 2026-07-27 21:38:44 -05:00

fix(leases): align stale-lease inspection, dashboard, and cleanup enforcement #952

jcwalker3 referenced this issue 2026-07-27 22:48:51 -05:00

fix(author): prevent bootstrap lock-provenance dead ends before PR creation #953

jcwalker3 referenced this issue 2026-07-27 23:11:14 -05:00

fix(author): prevent bootstrap lock-provenance dead ends before PR creation #953

jcwalker3 referenced this issue from a commit 2026-07-27 23:35:47 -05:00

fix(author): unify the bootstrap and lock_issue issue-lock contract (Closes #953)

jcwalker3 referenced this issue 2026-07-27 23:38:10 -05:00

fix(author): unify the bootstrap and lock_issue issue-lock contract (Closes #953) #954

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

master

fix/issue-987-native-mcp-bootstrap

feat/issue-985-project-scoped-launcher-identity

fix/issue-983-cross-repo-base-ref

feat/issue-980-stale-worker-retirement

fix/issue-975-client-identity-heartbeat

fix/issue-973-cross-repo-canonical-roots

fix/issue-970-safely-resolve-missing-worktrees

fix/issue-969-native-mcp-bootstrap

feat/issue-664-break-glass-restart

feat/issue-708-mcp-namespace-attachment

feat/issue-665-restart-audit

fix/issue-700-durable-walls

fix/issue-704-prevent-env-workspace-bindings

feat/issue-707-cross-project-boundaries

fix/issue-690-review-profile-switch-guard

fix/issue-953-bootstrap-lock-provenance

feat/issue-949-native-fleet-inventory

fix/issue-943-runtime-context-helpers

fix/issue-945-owning-pr-renewal-evidence

fix/issue-941-scope-guard-bootstrap-wiring

docs/issue-930-remote-mcp-coupling-inventory

fix/issue-892-author-bootstrap-deadlock

fix/issue-686-detect-reject-manual-mcp

fix/issue-672-mcp-config-drift

fix/issue-689-deterministic-mcp-namespace

feat/issue-666-concurrent-mcp-restart-tests

feat/issue-659-maintenance-drain-mode

feat/issue-648-notifications-console

fix/issue-670-direct-master-incident

feat/issue-644-console-recovery

feat/issue-650-providers-insights

feat/issue-669-scoped-component-recovery

docs/issue-668-mcp-ha-rolling-restart

feat/issue-667-console-restart-controls

feat/issue-645-linkage-console

feat/issue-643-request-preview-initiate

fix/issue-897-permission-stale-runtime-classification

feat/issue-641-runtime-session-view

feat/issue-663-restart-classes

feat/issue-661-drain-proof-hard-gate

fix/issue-854-semantic-container-exclusion

issue-640

fix/issue-682-starlette-httpx2

v1.1.0

Labels

Clear labels

allocator

Controller-owned work allocator

anti-stomp

Prevent concurrent LLM session stomping

architecture

Architecture / structural design

bug

chore

codex

OpenAI Codex client / workflow session surface

concurrency

Concurrent session safety

contamination

Workflow or session contamination incident

control-plane

MCP control-plane coordination and allocation authority

dashboard

MCP operational dashboard/queue view

database

Internal coordination storage (SQLite/Postgres)

design

Design / investigation, no implementation

documentation

Docs / runbooks

enhancement

New feature or improvement

gitea

Gitea MCP workflow

glitchtip

GlitchTip integration

important

incident

Operational or process incident requiring durable audit trail

incident-bridge

Sentry-to-Gitea incident bridging

integration

Integration testing

jenkins

Jenkins integration

labels

Label taxonomy management

leases

Lease adopt/release/expire lifecycle

mcp

MCP server / tooling

mcp-health

MCP namespace and runtime health

mcp-menu

MCP menu surface

multi-project

Work spanning multiple monitoring projects or Gitea repos

mutating

Mutating action; requires gating

nice-to-have

observability

Observability, metrics, traces, error reporting

portability

Cross-platform / portability

preflight

Shared preflight gates before mutation

protected-branch

Protected branch / stable-branch policy concern

queue

Work queue visibility and allocation

read-only

Read-only, no mutation

reconnect

MCP client reconnect/reload recovery path

recovery

Recovery paths for stale/foreign leases

refactor

Code refactor / restructure

release

Release / versioning

reliability

Reliability / failure handling

resumable-review

Persist and resume prepared review verdicts across sessions

reviewer

Reviewer workflow tooling

roadmap

Roadmap / umbrella issue

safety

Safety rails and fail-closed mutation guards

security

Security / trust boundary

self-hosted

Self-hosted infrastructure integration

sentry

Sentry error monitoring integration

stale-runtime

Stale backend daemon / runtime-vs-master parity failures

status:blocked

Issue is blocked

status:in-progress

Issue is being worked on

status:pr-open

Issue has an open pull request

status:ready

Issue is ready for work

terminal-lock

Terminal review lock (#332) path

testing

Tests / test coverage

tracker

Issue tracker hygiene / meta

type:bug

Bug or defect

type:feature

Feature or enhancement

type:feature

Feature or enhancement

type:guardrail

Safety gate or guardrail

visibility

Workflow state visibility for LLMs/operators

workflow

Cross-tool workflow

workflow-hardening

LLM workflow coordination hardening

workflow-hardening

LLM workflow coordination hardening

bug

Something is not working

duplicate

This issue or pull request already exists

enhancement

New feature

help wanted

Need some help

invalid

Something is wrong

question

More information is needed

wontfix

This won't be fixed

No labels mcp recovery reliability safety type:bug workflow-hardening

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

jcwalker3 jwalker (Regular User Account) superadmin (Admin Account) sysadmin (Regular User Account)

No Assignees

2 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

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