Scaled-Tech-Consulting/Gitea-Tools
2
0
Fork 0
Code Issues 97 Pull Requests 7 Actions Packages Projects Releases Wiki Activity

[controller][workflow] Automatically hand conflicting approved PRs to author remediation #842

New Issue
Open
opened 2026-07-23 00:06:27 -05:00 by jcwalker3 · 1 comment
jcwalker3 commented 2026-07-23 00:06:27 -05:00
Owner
Copy Link
Copy Source

Problem

The PR-sync lifecycle can distinguish:

  • merge_now
  • update_branch_by_merge
  • author_conflict_remediation
  • fresh_review_required
  • blocked

However, when an approved PR has actual conflicts with master, the merger currently returns BLOCKED + DIAGNOSE and stops. The required author-remediation transition is identified but is not durably queued and automatically selected by the next generic workflow run.

PR #818 demonstrated this gap:

The result was correct fail-closed behavior, but the workflow stalled instead of automatically advancing to the required author transition.

This issue extends #727. It must preserve the existing role boundaries and approval rules.

Required behavior

When merger assessment returns author_conflict_remediation:

  1. Persist a canonical workflow handoff for the exact PR, candidate head, and current base head.
  2. Mark the previous approval as unusable for merger once the candidate head changes.
  3. Place the remediation ahead of unrelated new author work.
  4. Make the next generic controller request select this exact remediation.
  5. Route it only to gitea-author / prgs-author.
  6. Preserve the existing PR and branch; do not create a replacement PR.
  7. Require a branch worktree owned by the author transition.
  8. Resolve conflicts by merging current master into the feature branch.
  9. Forbid rebase, force-push, and merger-authored conflict resolution.
  10. Run transition-specific validation and push the remediated head.
  11. Persist the old head, new head, merged base SHA, changed conflict files, and validation evidence.
  12. Route the new head to a fresh independent reviewer.
  13. Require a new approval covering the exact remediated head before merger eligibility can become true.
  14. Clear the remediation handoff only after verified push and reviewer handoff.

Clean-behind behavior

If the PR is behind but has no conflicts, retain the existing sanctioned update_branch_by_merge path. Do not classify a clean base update as conflict remediation.

Safety invariants

  • Merger must not resolve code conflicts.
  • Author must not review, approve, or merge.
  • Previous approval must never be reused after the candidate head changes.
  • No force-push or rebase.
  • No direct API, CLI, alternate-profile, or namespace fallback.
  • Every mutation requires current identity, parity, capability, ownership, and lease proof.
  • Failure must preserve the PR, branch, worktree, and diagnostic state.

Acceptance criteria

  • A conflicting approved PR produces a durable author_conflict_remediation transition.
  • The controller’s next-safe-action selects that remediation before unrelated issue work.
  • A generic workflow request routes the transition to the author namespace.
  • Successful remediation updates the existing PR branch and records the new head.
  • The old approval is reported as stale or invalid for merger.
  • The remediated PR appears in the fresh-review queue.
  • It cannot return to merge-ready until an independent approval covers the new head.
  • Cleanly behind PRs continue using the existing clean base-sync path.
  • Repeated runs are idempotent and do not create duplicate handoffs or leases.
  • Structured BLOCKED diagnostics identify unresolved files and the exact recovery action.

Tests

Add tests covering:

  • approved + cleanly behind → update_branch_by_merge
  • approved + conflicting → durable author_conflict_remediation
  • generic next-action selection prioritizes that remediation
  • author-only enforcement
  • merger conflict-resolution rejection
  • successful conflict remediation invalidates the previous approval
  • new head routes to fresh review
  • unchanged old approval cannot authorize merge
  • repeated assessments remain idempotent
  • failed remediation preserves branch and workflow ownership

References

## Problem The PR-sync lifecycle can distinguish: - merge_now - update_branch_by_merge - author_conflict_remediation - fresh_review_required - blocked However, when an approved PR has actual conflicts with master, the merger currently returns BLOCKED + DIAGNOSE and stops. The required author-remediation transition is identified but is not durably queued and automatically selected by the next generic workflow run. PR #818 demonstrated this gap: - reviewed head: 08061b7b8aebdd099a37d1abf5dafcf38e4fd3fb - approval: review #513 - commits behind master: 8 - mergeable: false - has_conflicts: true - recommendation: author_conflict_remediation The result was correct fail-closed behavior, but the workflow stalled instead of automatically advancing to the required author transition. This issue extends #727. It must preserve the existing role boundaries and approval rules. ## Required behavior When merger assessment returns `author_conflict_remediation`: 1. Persist a canonical workflow handoff for the exact PR, candidate head, and current base head. 2. Mark the previous approval as unusable for merger once the candidate head changes. 3. Place the remediation ahead of unrelated new author work. 4. Make the next generic controller request select this exact remediation. 5. Route it only to `gitea-author / prgs-author`. 6. Preserve the existing PR and branch; do not create a replacement PR. 7. Require a branch worktree owned by the author transition. 8. Resolve conflicts by merging current master into the feature branch. 9. Forbid rebase, force-push, and merger-authored conflict resolution. 10. Run transition-specific validation and push the remediated head. 11. Persist the old head, new head, merged base SHA, changed conflict files, and validation evidence. 12. Route the new head to a fresh independent reviewer. 13. Require a new approval covering the exact remediated head before merger eligibility can become true. 14. Clear the remediation handoff only after verified push and reviewer handoff. ## Clean-behind behavior If the PR is behind but has no conflicts, retain the existing sanctioned `update_branch_by_merge` path. Do not classify a clean base update as conflict remediation. ## Safety invariants - Merger must not resolve code conflicts. - Author must not review, approve, or merge. - Previous approval must never be reused after the candidate head changes. - No force-push or rebase. - No direct API, CLI, alternate-profile, or namespace fallback. - Every mutation requires current identity, parity, capability, ownership, and lease proof. - Failure must preserve the PR, branch, worktree, and diagnostic state. ## Acceptance criteria - A conflicting approved PR produces a durable `author_conflict_remediation` transition. - The controller’s next-safe-action selects that remediation before unrelated issue work. - A generic workflow request routes the transition to the author namespace. - Successful remediation updates the existing PR branch and records the new head. - The old approval is reported as stale or invalid for merger. - The remediated PR appears in the fresh-review queue. - It cannot return to merge-ready until an independent approval covers the new head. - Cleanly behind PRs continue using the existing clean base-sync path. - Repeated runs are idempotent and do not create duplicate handoffs or leases. - Structured BLOCKED diagnostics identify unresolved files and the exact recovery action. ## Tests Add tests covering: - approved + cleanly behind → `update_branch_by_merge` - approved + conflicting → durable `author_conflict_remediation` - generic next-action selection prioritizes that remediation - author-only enforcement - merger conflict-resolution rejection - successful conflict remediation invalidates the previous approval - new head routes to fresh review - unchanged old approval cannot authorize merge - repeated assessments remain idempotent - failed remediation preserves branch and workflow ownership ## References - Refs #727 - Refs PR #818
jcwalker3 added the type:featurestatus:readyworkflow-hardening labels 2026-07-23 00:06:27 -05:00
jcwalker3 added status:pr-open and removed status:ready labels 2026-07-23 02:23:52 -05:00
jcwalker3 added status:in-progress and removed status:pr-open labels 2026-07-23 03:50:16 -05:00
jcwalker3 commented 2026-07-23 03:50:17 -05:00
Author
Owner
Copy Link
Copy Source

Issue claim heartbeat

<!-- gitea-issue-claim-heartbeat:v1 --> **Issue claim heartbeat** - kind: claim - issue: #842 - branch: pending - phase: claimed - profile: prgs-author - pr: none - blocker: none - next_action: create worktree and begin implementation
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
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
No labels status:in-progress type:feature workflow-hardening
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
jcwalker3 sysadmin
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

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