Expose explicit adoption proof in gitea_lock_issue response when existing own branch is adopted #477

New Issue

2026-07-07T19:54:27-05:00

jcwalker3 commented

2026-07-07 19:54:27 -05:00

Problem

During #473 recovery, the sanctioned gitea_lock_issue → gitea_create_pr path succeeded after #465, #461, and #464 landed. Offline assessment via assess_own_branch_adoption returned ADOPT for the preserved branch, and gitea_create_pr succeeded.

However, the live gitea_lock_issue response did not surface an explicit, citable adoption proof block. The session received only a standard lock success response, forcing author/recovery reports to infer adoption from separate offline checks rather than quoting the live lock tool output directly.

This weakens recovery auditability and final-report evidence chains.

Context

issue_lock_adoption.py (#442 / #443) already implements adoption decision logic and build_adoption_proof(). gitea_lock_issue conditionally attaches an adoption object when adoption["adopt"] is true, but the live response shape is not sufficiently explicit or discoverable for author sessions documenting recovery.

Observed gap: sessions cannot reliably cite fields such as adoption decision, adopted branch/head, matcher summary, competing-branch check, and safe next action from the lock response alone.

Required behavior

When gitea_lock_issue adopts an existing own branch, the live tool response must include visible adoption proof fields, for example:

adoption_decision: ADOPT (or aligned enum with assess_own_branch_adoption outcome)
adopted_branch
adopted_branch_head
issue_number
matcher / proof summary (why this branch qualified)
competing_branch_check result
safe_next_action

Non-adoption lock responses should remain clear and unchanged, except for optional safe proof metadata that does not imply adoption.

Acceptance criteria

gitea_lock_issue response includes explicit adoption proof when adopting an existing branch — sufficient for #473-style recovery reports to cite the live lock response directly.
Non-adoption lock responses remain clear and unchanged except for safe optional proof metadata.
Tests cover:
- exact own-branch adoption proof is returned in the live lock response
- competing-branch block proof is returned when adoption is blocked
- unrelated branch NO_MATCH does not claim adoption
- substring-collision cases remain boundary-safe (issue-42 vs issue-420)
No unsafe recovery paths introduced: no raw API fallback, branch deletion, force-push recovery, or manual lock-file seeding.
Author/recovery reports can cite the live gitea_lock_issue response as primary adoption evidence without separate inference.

Related work

#442 / #443 — own-branch adoption decision logic
#440 — boundary-safe issue marker matching
#400 — duplicate-work gate
#473 — recovery session that exposed this reporting gap

Suggested implementation notes

Extend or reshape build_adoption_proof() / gitea_lock_issue result assembly so adoption proof is top-level and consistently named.
Align field names with assess_own_branch_adoption outcomes (ADOPT, BLOCK_COMPETING, NO_MATCH).
Update adoption message text to explicitly state branch adoption when ADOPT.
Add MCP/integration tests asserting response shape for adopt, block, and no-match paths.

## Problem During **#473** recovery, the sanctioned `gitea_lock_issue` → `gitea_create_pr` path succeeded after **#465**, **#461**, and **#464** landed. Offline assessment via `assess_own_branch_adoption` returned **ADOPT** for the preserved branch, and `gitea_create_pr` succeeded. However, the **live `gitea_lock_issue` response** did not surface an explicit, citable adoption proof block. The session received only a standard lock success response, forcing author/recovery reports to infer adoption from separate offline checks rather than quoting the live lock tool output directly. This weakens recovery auditability and final-report evidence chains. ## Context `issue_lock_adoption.py` (#442 / #443) already implements adoption decision logic and `build_adoption_proof()`. `gitea_lock_issue` conditionally attaches an `adoption` object when `adoption["adopt"]` is true, but the live response shape is not sufficiently explicit or discoverable for author sessions documenting recovery. Observed gap: sessions cannot reliably cite fields such as adoption decision, adopted branch/head, matcher summary, competing-branch check, and safe next action from the lock response alone. ## Required behavior When `gitea_lock_issue` adopts an existing own branch, the **live tool response** must include visible adoption proof fields, for example: - `adoption_decision`: `ADOPT` (or aligned enum with `assess_own_branch_adoption` outcome) - `adopted_branch` - `adopted_branch_head` - `issue_number` - matcher / proof summary (why this branch qualified) - `competing_branch_check` result - `safe_next_action` Non-adoption lock responses should remain clear and unchanged, except for optional safe proof metadata that does not imply adoption. ## Acceptance criteria 1. **`gitea_lock_issue` response includes explicit adoption proof** when adopting an existing branch — sufficient for #473-style recovery reports to cite the live lock response directly. 2. **Non-adoption lock responses remain clear** and unchanged except for safe optional proof metadata. 3. **Tests cover:** - exact own-branch adoption proof is returned in the live lock response - competing-branch block proof is returned when adoption is blocked - unrelated branch `NO_MATCH` does not claim adoption - substring-collision cases remain boundary-safe (`issue-42` vs `issue-420`) 4. **No unsafe recovery paths introduced:** no raw API fallback, branch deletion, force-push recovery, or manual lock-file seeding. 5. **Author/recovery reports** can cite the live `gitea_lock_issue` response as primary adoption evidence without separate inference. ## Related work - #442 / #443 — own-branch adoption decision logic - #440 — boundary-safe issue marker matching - #400 — duplicate-work gate - #473 — recovery session that exposed this reporting gap ## Suggested implementation notes - Extend or reshape `build_adoption_proof()` / `gitea_lock_issue` result assembly so adoption proof is top-level and consistently named. - Align field names with `assess_own_branch_adoption` outcomes (`ADOPT`, `BLOCK_COMPETING`, `NO_MATCH`). - Update adoption message text to explicitly state branch adoption when `ADOPT`. - Add MCP/integration tests asserting response shape for adopt, block, and no-match paths.

jcwalker3 added the status:in-progress label 2026-07-07 23:33:45 -05:00

jcwalker3 commented

2026-07-07 23:33:46 -05:00

Issue claim heartbeat

kind: claim
issue: Expose explicit adoption proof in gitea_lock_issue response when existing own branch is adopted (#477)
branch: pending
phase: claimed
profile: prgs-author
pr: none
blocker: none
next_action: create worktree and begin implementation

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

jcwalker3 commented

2026-07-07 23:34:09 -05:00

Issue claim heartbeat

kind: claim
issue: Expose explicit adoption proof in gitea_lock_issue response when existing own branch is adopted (#477)
branch: feat/issue-477-lock-adoption-proof
phase: claimed
profile: prgs-author
pr: none
blocker: none
next_action: create worktree and begin implementation

**Issue claim heartbeat** - kind: claim - issue: #477 - branch: feat/issue-477-lock-adoption-proof - phase: claimed - profile: prgs-author - pr: none - blocker: none - next_action: create worktree and begin implementation

jcwalker3 commented

2026-07-07 23:34:23 -05:00

Issue claim heartbeat

kind: claim
issue: Expose explicit adoption proof in gitea_lock_issue response when existing own branch is adopted (#477)
branch: feat/issue-477-adoption-proof
phase: claimed
profile: prgs-author
pr: none
blocker: none
next_action: create worktree and begin implementation

**Issue claim heartbeat** - kind: claim - issue: #477 - branch: feat/issue-477-adoption-proof - phase: claimed - profile: prgs-author - pr: none - blocker: none - next_action: create worktree and begin implementation

jcwalker3 commented

2026-07-07 23:39:43 -05:00

Issue claim heartbeat

kind: claim
issue: Expose explicit adoption proof in gitea_lock_issue response when existing own branch is adopted (#477)
branch: feat/issue-477-lock-adoption-proof
phase: claimed
profile: prgs-author
pr: none
blocker: none
next_action: create worktree and begin implementation

**Issue claim heartbeat** - kind: claim - issue: #477 - branch: feat/issue-477-lock-adoption-proof - phase: claimed - profile: prgs-author - pr: none - blocker: none - next_action: create worktree and begin implementation

jcwalker3 referenced this issue from a commit

2026-07-07 23:40:15 -05:00

feat: surface explicit adoption proof in gitea_lock_issue response (Closes #477)

jcwalker3 referenced a pull request that will close this issue

2026-07-07 23:42:07 -05:00

feat: expose explicit adoption proof in gitea_lock_issue response (Closes #477) #481

sysadmin referenced this issue

2026-07-08 01:41:56 -05:00

feat: expose explicit adoption proof in gitea_lock_issue response (Closes #477) #481

sysadmin referenced this issue

2026-07-08 01:42:08 -05:00

feat: expose explicit adoption proof in gitea_lock_issue response (Closes #477) #481