Implement fail-closed continuation mode for issues already represented by open PRs #189

New Issue

2026-07-05T14:40:16-05:00

jcwalker3 commented

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

Problem:
When an issue is already represented by an open PR, author agents must enter continuation mode rather than selecting a new issue. However, continuation mode is currently not formalized or strictly validated with automated proofs.

Positive-but-not-perfect continuation example (Evidence from Claude run):
Claude ran as jcwalker3 / prgs-author, checked both Gitea-Tools and mcp-control-plane, and found an existing open PR:

PR Require and validate Controller Handoff sections in workflow final reports (Issue #182) (#186)
Issue Require controller handoff summaries in all LLM workflow final reports (#182)
Branch: feat/issue-182-controller-handoff-enforcement
State at reconciliation: open but not mergeable because master had moved
New base after rebase: prgs/master @ 601c608c
New head after update: 45c5cac2bc49dd112766ea218b18a71e9c5f8e99

Positive Behavior:

The run explicitly classified the work as #182 continuation, not fresh issue selection.
It did not claim a new issue.
It updated its own existing feature branch/PR.
It used author-only capabilities.
It did not review, approve, request changes, merge, close issues, or mutate unrelated items.
It included a Controller Handoff.
It restored PR #186 to mergeable state.
Validation passed (targeted tests: 50 passed; full suite: 690 passed, 6 skipped; git diff --check: clean; py_compile: OK; secret sweep: clean by reported grep).

Remaining Gaps to Formalize:

Continuation mode should require explicit evidence:
- existing PR number
- existing PR author
- issue claim status
- old remote PR head before update
- new PR head after update
- why the current author session is allowed to continue it
Force-with-lease updates must report:
- old remote head
- expected lease head
- new pushed head
- confirmation that only the feature branch was pushed
Issue claim/mark operations should have exact resolver support.
The run noted mark_issue is still unmapped and correctly avoided label mutation. This should remain a tracked capability-map gap.
Secret/provenance sweep should use a standard pattern/script.
The reported grep was exact, but the workflow should define a canonical sweep so each run is comparable.

Acceptance Criteria:
Continuation mode earns an A only when the workflow explicitly proves the issue is already represented by an existing PR, proves the current author is allowed to continue that PR, records old/new head SHAs, uses safe force-with-lease evidence if needed, and ends with a Controller Handoff.

Problem: When an issue is already represented by an open PR, author agents must enter continuation mode rather than selecting a new issue. However, continuation mode is currently not formalized or strictly validated with automated proofs. Positive-but-not-perfect continuation example (Evidence from Claude run): Claude ran as `jcwalker3 / prgs-author`, checked both `Gitea-Tools` and `mcp-control-plane`, and found an existing open PR: - PR #186 - Issue #182 - Branch: `feat/issue-182-controller-handoff-enforcement` - State at reconciliation: open but not mergeable because master had moved - New base after rebase: `prgs/master @ 601c608c` - New head after update: `45c5cac2bc49dd112766ea218b18a71e9c5f8e99` Positive Behavior: - The run explicitly classified the work as `#182 continuation`, not fresh issue selection. - It did not claim a new issue. - It updated its own existing feature branch/PR. - It used author-only capabilities. - It did not review, approve, request changes, merge, close issues, or mutate unrelated items. - It included a Controller Handoff. - It restored PR #186 to mergeable state. - Validation passed (targeted tests: 50 passed; full suite: 690 passed, 6 skipped; `git diff --check`: clean; `py_compile`: OK; secret sweep: clean by reported grep). Remaining Gaps to Formalize: 1. Continuation mode should require explicit evidence: - existing PR number - existing PR author - issue claim status - old remote PR head before update - new PR head after update - why the current author session is allowed to continue it 2. Force-with-lease updates must report: - old remote head - expected lease head - new pushed head - confirmation that only the feature branch was pushed 3. Issue claim/mark operations should have exact resolver support. The run noted `mark_issue` is still unmapped and correctly avoided label mutation. This should remain a tracked capability-map gap. 4. Secret/provenance sweep should use a standard pattern/script. The reported grep was exact, but the workflow should define a canonical sweep so each run is comparable. Acceptance Criteria: Continuation mode earns an A only when the workflow explicitly proves the issue is already represented by an existing PR, proves the current author is allowed to continue that PR, records old/new head SHAs, uses safe force-with-lease evidence if needed, and ends with a Controller Handoff.

jcwalker3 added the status:in-progress label 2026-07-05 14:40:19 -05:00

jcwalker3 commented

2026-07-05 14:42:54 -05:00

Issue-filing workflow gaps observed while creating #189

Evidence:
Gemini created Gitea-Tools issue #189, "Implement fail-closed continuation mode for issues already represented by open PRs," to track continuation-mode hardening. The run was safe in that it used jcwalker3 / prgs-author, did not review/approve/merge/close anything, and included a Controller Handoff.

However, the filing run exposed additional workflow gaps that should be included in #189 or tracked as acceptance criteria.

Observed gaps:

The operator asked to update an issue, but the run created a new issue.
This may be acceptable only if no suitable existing issue exists, but the final report did not prove a duplicate search or explain why an existing issue could not be updated.
Concrete instance: a suitable existing tracker did exist — #188 ("Require explicit continuation mode before working an issue already represented by an open PR"), filed earlier the same day, covering the same continuation-mode wall with selection-time classification requirements and harness assertions. #189 does not reference it. #188 and #189 now need an explicit relationship decision (canonical vs child: #188 = selection/classification wall, #189 = fail-closed implementation + evidence-shape requirements — complementary if cross-linked, duplicate if not).
The new issue was marked status:in-progress even though no implementation work began.
Filing a tracker issue should not automatically claim implementation unless the same session is actively implementing it. (#189 currently carries status:in-progress with no branch, PR, or claim comment — the phantom-claim pattern already documented in the #173 triage and mcp-control-plane #77.)
Capability proof was incomplete.
The run resolved create_issue and comment_issue, but also performed gitea_set_issue_labels. Label mutation needs exact capability proof too; nearby issue/comment permissions are not enough. Note: gitea_resolve_task_capability(task=mark_issue) currently fails closed as unmapped — a compliant run cannot prove label capability at all, which makes unproven label mutations doubly out of bounds (tracked as a capability-map gap in #189 body item 3 and mcp-control-plane #78's lineage).
The final report did not summarize the actual issue body / requirements created.
For tracker-creation tasks, the report must include the durable requirements added so the controller can verify the issue captured the intended evidence.
The report did not clearly state what existing continuation-related issues were found and why #189 was not a duplicate.

Required behavior:

Issue-update tasks must first search for an existing suitable issue and report the result.
New issue creation is allowed only when no suitable existing tracker exists, and the report must explain why.
Filing a tracker issue must not automatically add status:in-progress unless implementation starts.
Every mutation must have exact capability proof, including label changes.
Final reports for issue-filing tasks must include:
- issue number
- title
- whether it was new or updated
- duplicate search result
- exact mutations performed
- exact capability proof for each mutation
- summary of the requirements/evidence added
- Controller Handoff

Acceptance criteria:
Continuation-mode workflow hardening must cover not only PR/branch continuation, but also issue-filing discipline: update existing trackers when appropriate, avoid premature in-progress labels, prove label mutation capability, and report durable issue contents.

Filing note for this comment itself: capability proof — comment_issue resolver-allowed (fresh); mutation performed — this comment only; no labels touched (unmapped capability), no issues created/closed, #188/#189 consolidation left as operator decision.

## Issue-filing workflow gaps observed while creating #189 Evidence: Gemini created Gitea-Tools issue #189, "Implement fail-closed continuation mode for issues already represented by open PRs," to track continuation-mode hardening. The run was safe in that it used `jcwalker3 / prgs-author`, did not review/approve/merge/close anything, and included a Controller Handoff. However, the filing run exposed additional workflow gaps that should be included in #189 or tracked as acceptance criteria. Observed gaps: 1. The operator asked to update an issue, but the run created a new issue. This may be acceptable only if no suitable existing issue exists, but the final report did not prove a duplicate search or explain why an existing issue could not be updated. **Concrete instance:** a suitable existing tracker did exist — **#188** ("Require explicit continuation mode before working an issue already represented by an open PR"), filed earlier the same day, covering the same continuation-mode wall with selection-time classification requirements and harness assertions. #189 does not reference it. #188 and #189 now need an explicit relationship decision (canonical vs child: #188 = selection/classification wall, #189 = fail-closed implementation + evidence-shape requirements — complementary if cross-linked, duplicate if not). 2. The new issue was marked `status:in-progress` even though no implementation work began. Filing a tracker issue should not automatically claim implementation unless the same session is actively implementing it. (#189 currently carries `status:in-progress` with no branch, PR, or claim comment — the phantom-claim pattern already documented in the #173 triage and mcp-control-plane #77.) 3. Capability proof was incomplete. The run resolved `create_issue` and `comment_issue`, but also performed `gitea_set_issue_labels`. Label mutation needs exact capability proof too; nearby issue/comment permissions are not enough. Note: `gitea_resolve_task_capability(task=mark_issue)` currently fails closed as unmapped — a compliant run cannot prove label capability at all, which makes unproven label mutations doubly out of bounds (tracked as a capability-map gap in #189 body item 3 and mcp-control-plane #78's lineage). 4. The final report did not summarize the actual issue body / requirements created. For tracker-creation tasks, the report must include the durable requirements added so the controller can verify the issue captured the intended evidence. 5. The report did not clearly state what existing continuation-related issues were found and why #189 was not a duplicate. Required behavior: * Issue-update tasks must first search for an existing suitable issue and report the result. * New issue creation is allowed only when no suitable existing tracker exists, and the report must explain why. * Filing a tracker issue must not automatically add `status:in-progress` unless implementation starts. * Every mutation must have exact capability proof, including label changes. * Final reports for issue-filing tasks must include: * issue number * title * whether it was new or updated * duplicate search result * exact mutations performed * exact capability proof for each mutation * summary of the requirements/evidence added * Controller Handoff Acceptance criteria: Continuation-mode workflow hardening must cover not only PR/branch continuation, but also issue-filing discipline: update existing trackers when appropriate, avoid premature in-progress labels, prove label mutation capability, and report durable issue contents. --- *Filing note for this comment itself: capability proof — `comment_issue` resolver-allowed (fresh); mutation performed — this comment only; no labels touched (unmapped capability), no issues created/closed, #188/#189 consolidation left as operator decision.*

jcwalker3 referenced this issue

2026-07-05 14:42:56 -05:00

Harden issue-filing final reports: Controller Handoff, full SHAs, and exact mutation capability proof #191

jcwalker3 referenced this issue from a commit

2026-07-06 10:54:43 -05:00

feat(continuation): formalize continuation proofs for claim and push (closes #189)

jcwalker3 referenced a pull request that will close this issue

2026-07-06 10:54:50 -05:00

feat(continuation): formalize continuation proofs for claim and push (closes #189) #253

sysadmin referenced a pull request that will close this issue

2026-07-06 11:27:20 -05:00

feat(continuation): formalize continuation proofs for claim and push (closes #189) #253