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

Replace manual merger lease seeding with explicit guarded lease adoption #537

New Issue
Closed
opened 2026-07-08 06:37:21 -05:00 by jcwalker3 · 1 comment
jcwalker3 commented 2026-07-08 06:37:21 -05:00
Owner
Copy Link
Copy Source

Problem:
During the merges of PR #493 and PR #421, the merger could not use the normal MCP process-local lease state because reviewer_pr_lease._SESSION_LEASE was pointed at the wrong PR in the MCP server process. The merger profile also cannot acquire reviewer leases normally because it lacks gitea.pr.review.

To complete the merges, a dedicated Python process manually seeded reviewer_pr_lease._SESSION_LEASE with the target PR lease dictionary before calling the merge path. This satisfied the local preflight but was not a canonical MCP recovery tool.

Risk:
Manual seeding of process-local lease state can become a bypass pattern. Future sessions may fabricate or incorrectly seed lease state and still produce plausible merge reports. The guard is also fragile because it depends on process-local memory rather than durable, auditable lease records.

Required behavior:

  1. Manual mutation of reviewer_pr_lease._SESSION_LEASE outside an MCP tool must be rejected as a valid merge path.
  2. Add an explicit merger lease adoption/recovery MCP tool.
  3. The recovery tool must load lease proof from durable Gitea comments/state, not caller-provided raw dictionaries alone.
  4. Recovery must verify:
    • PR number
    • expected head SHA
    • PR is open
    • PR is mergeable
    • authenticated identity is not the PR author
    • approval exists at current head
    • no blocking REQUEST_CHANGES exists
    • lease/comment/session being adopted belongs to the same PR
  5. Recovery must write a canonical audit comment explaining the adopted lease and reason.
  6. gitea_merge_pr must distinguish:
    • normal process-local lease
    • adopted durable lease
    • rejected manual/injected lease
  7. Merge reports must include the lease proof source.

Acceptance criteria:

  • Add tests proving manual _SESSION_LEASE seeding is not accepted as canonical proof.
  • Add tests for successful guarded merger lease adoption from durable Gitea lease comments.
  • Add tests blocking adoption when the lease belongs to another PR.
  • Add tests blocking adoption when the expected head SHA differs.
  • Add tests blocking adoption without current-head approval.
  • Add tests blocking adoption when REQUEST_CHANGES exists.
  • Add canonical handoff/report fields for lease_proof_source, adoption_comment_id, and recovery_reason.
Problem: During the merges of PR #493 and PR #421, the merger could not use the normal MCP process-local lease state because `reviewer_pr_lease._SESSION_LEASE` was pointed at the wrong PR in the MCP server process. The merger profile also cannot acquire reviewer leases normally because it lacks `gitea.pr.review`. To complete the merges, a dedicated Python process manually seeded `reviewer_pr_lease._SESSION_LEASE` with the target PR lease dictionary before calling the merge path. This satisfied the local preflight but was not a canonical MCP recovery tool. Risk: Manual seeding of process-local lease state can become a bypass pattern. Future sessions may fabricate or incorrectly seed lease state and still produce plausible merge reports. The guard is also fragile because it depends on process-local memory rather than durable, auditable lease records. Required behavior: 1. Manual mutation of `reviewer_pr_lease._SESSION_LEASE` outside an MCP tool must be rejected as a valid merge path. 2. Add an explicit merger lease adoption/recovery MCP tool. 3. The recovery tool must load lease proof from durable Gitea comments/state, not caller-provided raw dictionaries alone. 4. Recovery must verify: - PR number - expected head SHA - PR is open - PR is mergeable - authenticated identity is not the PR author - approval exists at current head - no blocking `REQUEST_CHANGES` exists - lease/comment/session being adopted belongs to the same PR 5. Recovery must write a canonical audit comment explaining the adopted lease and reason. 6. `gitea_merge_pr` must distinguish: - normal process-local lease - adopted durable lease - rejected manual/injected lease 7. Merge reports must include the lease proof source. Acceptance criteria: - Add tests proving manual `_SESSION_LEASE` seeding is not accepted as canonical proof. - Add tests for successful guarded merger lease adoption from durable Gitea lease comments. - Add tests blocking adoption when the lease belongs to another PR. - Add tests blocking adoption when the expected head SHA differs. - Add tests blocking adoption without current-head approval. - Add tests blocking adoption when `REQUEST_CHANGES` exists. - Add canonical handoff/report fields for `lease_proof_source`, `adoption_comment_id`, and `recovery_reason`.
jcwalker3 commented 2026-07-09 11:28:33 -05:00
Author
Owner
Copy Link
Copy Source

Canonical Issue State

STATE:
closed

WHO_IS_NEXT:
controller

NEXT_ACTION:
No further implementation; guarded merger lease adoption already ships as gitea_adopt_merger_pr_lease.

NEXT_PROMPT:

Controller: treat issue #537 as completed (duplicate of shipped #536 adoption path). Use gitea_adopt_merger_pr_lease for merger lease recovery.

WHAT_HAPPENED:
Verified on master: merger_lease_adoption.py and gitea_adopt_merger_pr_lease require durable comment-backed adoption; record_session_lease requires sanctioned lease_provenance; bare manual _SESSION_LEASE seeding is rejected by is_sanctioned_session_lease.

WHY:
Acceptance criteria met by #536 implementation already on master; closing as completed without new code.

RELATED_PRS:
shipped #536 adoption path on master

BLOCKERS:
none

VALIDATION:
merger_lease_adoption.py SANCTIONED_PROVENANCE_SOURCES; gitea_adopt_merger_pr_lease tool present

LAST_UPDATED_BY:
jcwalker3 / prgs-author / 2026-07-09

## Canonical Issue State STATE: closed WHO_IS_NEXT: controller NEXT_ACTION: No further implementation; guarded merger lease adoption already ships as gitea_adopt_merger_pr_lease. NEXT_PROMPT: ```text Controller: treat issue #537 as completed (duplicate of shipped #536 adoption path). Use gitea_adopt_merger_pr_lease for merger lease recovery. ``` WHAT_HAPPENED: Verified on master: `merger_lease_adoption.py` and `gitea_adopt_merger_pr_lease` require durable comment-backed adoption; `record_session_lease` requires sanctioned `lease_provenance`; bare manual `_SESSION_LEASE` seeding is rejected by `is_sanctioned_session_lease`. WHY: Acceptance criteria met by #536 implementation already on master; closing as completed without new code. RELATED_PRS: shipped #536 adoption path on master BLOCKERS: none VALIDATION: merger_lease_adoption.py SANCTIONED_PROVENANCE_SOURCES; gitea_adopt_merger_pr_lease tool present LAST_UPDATED_BY: jcwalker3 / prgs-author / 2026-07-09
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#537