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

Define partial reconciliation behavior when PR close capability is missing #302

New Issue
Closed
opened 2026-07-07 00:43:16 -05:00 by jcwalker3 · 1 comment
jcwalker3 commented 2026-07-07 00:43:16 -05:00
Owner
Copy Link
Copy Source

Already-landed PR reconciliation can prove that a PR should be closed, but may lack gitea.pr.close capability. In that case, the workflow currently stops without posting a comment even when comment_pr capability is available.

Observed behavior:

  • comment_pr capability was allowed.
  • comment_issue capability was allowed.
  • close_issue capability was allowed.
  • close_pr capability was blocked.
  • The workflow posted no comment and stopped.

Problem:

It is unclear whether the workflow should:

  1. stop without any Gitea mutation when close_pr is missing, or
  2. post a reconciliation comment with ancestor proof, then stop for human/authorized close.

Required behavior:

Define a durable policy for partial reconciliation.

Option A: strict all-or-nothing

  • If close_pr is missing, do not comment.
  • Produce recovery handoff only.

Option B: comment-then-stop

  • If comment_pr is allowed but close_pr is missing, post a reconciliation comment with:

    • PR head SHA
    • target branch SHA
    • ancestor proof
    • linked issue status
    • required missing capability

  • Then stop without closing.

Acceptance criteria:

  • Policy is documented in the PR reconciliation workflow.
  • MCP/tooling enforces the chosen policy.
  • Final reports explain why comments were or were not posted.
  • Tests cover close capability present, close capability missing with comment allowed, comment capability missing, and all capabilities missing.
Already-landed PR reconciliation can prove that a PR should be closed, but may lack `gitea.pr.close` capability. In that case, the workflow currently stops without posting a comment even when `comment_pr` capability is available. Observed behavior: * `comment_pr` capability was allowed. * `comment_issue` capability was allowed. * `close_issue` capability was allowed. * `close_pr` capability was blocked. * The workflow posted no comment and stopped. Problem: It is unclear whether the workflow should: 1. stop without any Gitea mutation when `close_pr` is missing, or 2. post a reconciliation comment with ancestor proof, then stop for human/authorized close. Required behavior: Define a durable policy for partial reconciliation. Option A: strict all-or-nothing * If `close_pr` is missing, do not comment. * Produce recovery handoff only. Option B: comment-then-stop * If `comment_pr` is allowed but `close_pr` is missing, post a reconciliation comment with: * PR head SHA * target branch SHA * ancestor proof * linked issue status * required missing capability * Then stop without closing. Acceptance criteria: * Policy is documented in the PR reconciliation workflow. * MCP/tooling enforces the chosen policy. * Final reports explain why comments were or were not posted. * Tests cover close capability present, close capability missing with comment allowed, comment capability missing, and all capabilities missing.
jcwalker3 added the status:in-progress label 2026-07-07 04:42:17 -05:00
jcwalker3 commented 2026-07-07 04:48:12 -05:00
Author
Owner
Copy Link
Copy Source

Implementation PR opened: #375 (branch feat/issue-302-partial-reconciliation-policy, head 852ac1f).

Policy decision: Option B — comment-then-stop. resolve_partial_reconciliation_plan maps proven capabilities to FULL_RECONCILE_CLOSE_ALLOWED / PARTIAL_RECONCILE_COMMENT_THEN_STOP / RECOVERY_HANDOFF_ONLY / GATE_NOT_PROVEN (fail-closed on missing capability dict or unproven ancestry). assess_partial_reconciliation_report forces reports to explain why the comment was or was not posted. Documented as §12A in workflows/reconcile-landed-pr.md with contract-test markers. 9 new tests + doc contract. Awaiting reviewer.

Implementation PR opened: #375 (branch `feat/issue-302-partial-reconciliation-policy`, head 852ac1f). Policy decision: **Option B — comment-then-stop**. `resolve_partial_reconciliation_plan` maps proven capabilities to FULL_RECONCILE_CLOSE_ALLOWED / PARTIAL_RECONCILE_COMMENT_THEN_STOP / RECOVERY_HANDOFF_ONLY / GATE_NOT_PROVEN (fail-closed on missing capability dict or unproven ancestry). `assess_partial_reconciliation_report` forces reports to explain why the comment was or was not posted. Documented as §12A in workflows/reconcile-landed-pr.md with contract-test markers. 9 new tests + doc contract. Awaiting reviewer.
sysadmin removed the status:in-progress label 2026-07-07 08:51:18 -05:00
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
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#302