Scaled-Tech-Consulting/Gitea-Tools
4
0
Fork 0
Code Issues 110 Pull Requests 12 Actions Packages Projects Releases Wiki Activity

permission_report misclassifies stale-runtime mutation blocks as missing permissions and recommends profile switching #897

New Issue
Closed
opened 2026-07-24 21:40:26 -05:00 by jcwalker3 · 3 comments
jcwalker3 commented 2026-07-24 21:40:26 -05:00
Owner
Copy Link
Copy Source

Problem

When a mutating tool is refused because the serving process is stale relative to master, the refusal is returned to the caller as a permission denial, carrying a permission_report that names a permission the active profile actually holds and instructs the agent to switch profiles. Both the diagnosis and the prescribed action are wrong, and the prescribed action is hazardous.

Observed shape: gitea_create_issue blocked while the daemon was behind live master returned a permission_report reporting missing_permission: gitea.issue.create and a next action of switching profile / MCP session — while gitea_whoami on the same session proved prgs-author allows gitea.issue.create.

Root cause (verified at master a4c73766f4b0cc32f7c3808688eceeb6fee74335)

  1. _profile_operation_gate (gitea_mcp_server.py:14080) returns stale-runtime reasons from _master_parity_block(op) (:14095) and runtime-mode reasons from _runtime_mode_block(op) (:14098) through the same return channel as genuine profile-permission denials.
  2. _profile_permission_block (:14344) treats any non-empty reason list as a permission denial and unconditionally attaches permission_report: _permission_block_report(required_operation) (:14363).
  3. _permission_block_report (:13823) never consults parity or runtime mode. It hardcodes missing_permission and required_permission to the requested operation (:13835–:13836), then emits one of two next actions: Call gitea_activate_profile with a profile that allows ... (:13892) or Switch to the {role} MCP session ... (:13898).

The reason strings are therefore the only signal distinguishing a stale runtime from a real permission denial, and the structured field the agent is meant to trust contradicts them.

Why the prescribed action is hazardous

  • Profile switching does not clear a stale daemon; the sanctioned recovery is IDE/client reconnect, per the contract established in #685.
  • Cross-role profile activation mid-session is the exact failure #690 hardens against and #714 removed as an automatic behavior. This report reintroduces it as advice.
  • Because a real author profile already holds the permission, the agent has no way to satisfy the instruction, so runs terminate with a false root cause and no durable record of the real one.

Acceptance criteria

  • Stale-runtime and runtime-mode refusals are typed distinctly from profile-permission refusals, with distinct blocker kinds, rather than sharing one reason channel.
  • A refusal caused by staleness or runtime mode never emits a permission_report, and never names a permission the active profile holds.
  • _permission_block_report verifies the active profile actually lacks the operation before reporting it missing; if the profile holds it, the report fails closed as a diagnostic defect instead of fabricating a missing permission.
  • A stale-runtime refusal reports the sanctioned recovery only — client reconnect — and never recommends gitea_activate_profile or an MCP session switch.
  • The blocker payload states the observed heads, matching the fields returned by gitea_assess_master_parity, so the caller can confirm the classification.
  • Tests cover, for author, reviewer, merger, and reconciler profiles: stale runtime plus permitted operation (expect runtime blocker, no permission_report); fresh runtime plus forbidden operation (expect permission_report, no runtime blocker); stale runtime plus forbidden operation (both causes reported, unambiguously separated).
  • Regression: gitea_create_issue on a stale daemon under prgs-author never returns missing_permission: gitea.issue.create.

Linkage

  • #685 (closed) fixed the resolver to return typed runtime_reconnect_required; it never touched the _profile_operation_gate -> _permission_block_report path, which still misclassifies.
  • #690 (cross-role profile activation mid-session) and #714 (automatic profile substitution removed) are the safety work this report's advice contradicts.
  • #686 covers manual duplicate role-server provenance; #689 records transport-pinning to an obsolete cohort head; #708 covers namespaces reporting Connected while unattached. All three concern daemon lifecycle and attachment; none addresses how a staleness refusal is classified or reported.
  • Adjacent to the durable-failure-reporting child of epic #887, which needs the blocker classification to be correct before a report is worth persisting.

Duplicate verdict

NOT a duplicate. Verified against all open issues at master a4c73766f4b0cc32f7c3808688eceeb6fee74335. No open issue covers the classification of a staleness refusal as a permission denial, and #685, the only issue that touched adjacent code, is closed and scoped to the resolver.

## Problem When a mutating tool is refused because the serving process is stale relative to master, the refusal is returned to the caller as a **permission denial**, carrying a `permission_report` that names a permission the active profile actually holds and instructs the agent to switch profiles. Both the diagnosis and the prescribed action are wrong, and the prescribed action is hazardous. Observed shape: `gitea_create_issue` blocked while the daemon was behind live master returned a `permission_report` reporting `missing_permission: gitea.issue.create` and a next action of switching profile / MCP session — while `gitea_whoami` on the same session proved `prgs-author` allows `gitea.issue.create`. ## Root cause (verified at master `a4c73766f4b0cc32f7c3808688eceeb6fee74335`) 1. `_profile_operation_gate` (`gitea_mcp_server.py:14080`) returns stale-runtime reasons from `_master_parity_block(op)` (`:14095`) and runtime-mode reasons from `_runtime_mode_block(op)` (`:14098`) through the **same return channel** as genuine profile-permission denials. 2. `_profile_permission_block` (`:14344`) treats any non-empty reason list as a permission denial and unconditionally attaches `permission_report: _permission_block_report(required_operation)` (`:14363`). 3. `_permission_block_report` (`:13823`) never consults parity or runtime mode. It hardcodes `missing_permission` and `required_permission` to the requested operation (`:13835`–`:13836`), then emits one of two next actions: `Call gitea_activate_profile with a profile that allows ...` (`:13892`) or `Switch to the {role} MCP session ...` (`:13898`). The reason strings are therefore the only signal distinguishing a stale runtime from a real permission denial, and the structured field the agent is meant to trust contradicts them. ## Why the prescribed action is hazardous - Profile switching does not clear a stale daemon; the sanctioned recovery is IDE/client reconnect, per the contract established in #685. - Cross-role profile activation mid-session is the exact failure #690 hardens against and #714 removed as an automatic behavior. This report reintroduces it as advice. - Because a real author profile already holds the permission, the agent has no way to satisfy the instruction, so runs terminate with a false root cause and no durable record of the real one. ## Acceptance criteria - Stale-runtime and runtime-mode refusals are typed distinctly from profile-permission refusals, with distinct blocker kinds, rather than sharing one reason channel. - A refusal caused by staleness or runtime mode never emits a `permission_report`, and never names a permission the active profile holds. - `_permission_block_report` verifies the active profile actually lacks the operation before reporting it missing; if the profile holds it, the report fails closed as a diagnostic defect instead of fabricating a missing permission. - A stale-runtime refusal reports the sanctioned recovery only — client reconnect — and never recommends `gitea_activate_profile` or an MCP session switch. - The blocker payload states the observed heads, matching the fields returned by `gitea_assess_master_parity`, so the caller can confirm the classification. - Tests cover, for author, reviewer, merger, and reconciler profiles: stale runtime plus permitted operation (expect runtime blocker, no `permission_report`); fresh runtime plus forbidden operation (expect `permission_report`, no runtime blocker); stale runtime plus forbidden operation (both causes reported, unambiguously separated). - Regression: `gitea_create_issue` on a stale daemon under `prgs-author` never returns `missing_permission: gitea.issue.create`. ## Linkage - #685 (closed) fixed the *resolver* to return typed `runtime_reconnect_required`; it never touched the `_profile_operation_gate` -> `_permission_block_report` path, which still misclassifies. - #690 (cross-role profile activation mid-session) and #714 (automatic profile substitution removed) are the safety work this report's advice contradicts. - #686 covers manual duplicate role-server provenance; #689 records transport-pinning to an obsolete cohort head; #708 covers namespaces reporting Connected while unattached. All three concern daemon lifecycle and attachment; none addresses how a staleness refusal is classified or reported. - Adjacent to the durable-failure-reporting child of epic #887, which needs the blocker classification to be correct before a report is worth persisting. ## Duplicate verdict NOT a duplicate. Verified against all open issues at master `a4c73766f4b0cc32f7c3808688eceeb6fee74335`. No open issue covers the classification of a staleness refusal as a permission denial, and #685, the only issue that touched adjacent code, is closed and scoped to the resolver.
jcwalker3 added status:in-progress and removed status:ready labels 2026-07-25 00:47:48 -05:00
jcwalker3 commented 2026-07-25 00:47:49 -05:00
Author
Owner
Copy Link
Copy Source

Issue claim heartbeat

<!-- gitea-issue-claim-heartbeat:v1 --> **Issue claim heartbeat** - kind: claim - issue: #897 - branch: fix/issue-897-permission-stale-runtime-classification - phase: claimed - profile: prgs-author - pr: none - blocker: none - next_action: create worktree and begin implementation
jcwalker3 added status:pr-open and removed status:in-progress labels 2026-07-25 00:49:07 -05:00
jcwalker3 commented 2026-07-25 06:45:19 -05:00
Author
Owner
Copy Link
Copy Source

[THREAD STATE LEDGER]

what is true now: PR #901 remains in open state against base master. Live PR head is 54559aebc3668f4911943dcad93a3a04a1926789; live base head is 715863799f7b42521acaa7c2d3636a113bf87cf9. commits_behind=0, mergeable=true, has_conflicts=false, approval_at_current_head=false.

what changed: merge result: base master @ 715863799f7b42521acaa7c2d3636a113bf87cf9 was brought into the PR branch by a sanctioned update-by-merge commit 54559aebc3668f4911943dcad93a3a04a1926789 (parents = 6e6ca9433873056c7a84d2a1ef3590323ea5a636, 715863799f7b42521acaa7c2d3636a113bf87cf9; no rebase, no force-push, first-parent lineage reaches the prior head). The resulting tree 7c47ece670a955fa156a0ab31312250d5aa3ca16 is byte-identical to a locally simulated clean merge of those two commits, so the sync carries zero conflict-resolution edits and zero out-of-scope content. Effective diff versus live base is confined to gitea_mcp_server.py and tests/test_issue_897_permission_stale_runtime_classification.py. The prior review verdict recorded at former head 6e6ca943 no longer applies to the current head and is treated as superseded, not reusable.

what is blocked: nothing on the author side. Blocker classification: no blocker.

who/what acts next: reviewer role (prgs-reviewer) performs a fresh independent formal review pinned to head 54559aebc3668f4911943dcad93a3a04a1926789.

Server-side decision state: PR #901 open; recommended_next_action=fresh_review_required; approval_valid_for_merge=false; stale_approval=true; no reviewer lease and no merger lease active.
Local verdict/state: author sync objective satisfied at head 54559aebc3668f4911943dcad93a3a04a1926789; worktree branches/issue-897-permission-stale-runtime fast-forwarded to that exact head and clean.
Next actor: prgs-reviewer (sysadmin)
Required action: acquire the reviewer PR lease for #901, review the full effective diff at head 54559aebc3668f4911943dcad93a3a04a1926789, run the focused and regression suites against the current master baseline, then record a formal verdict at that exact head.
Blocker classification: no blocker
Do not do: do not reuse the former-head review verdict from 6e6ca943; do not rebase or force-push this branch; do not merge before a formal verdict exists at the exact current head.

Canonical Issue State

STATE: author-sync-complete
WHO_IS_NEXT: reviewer
NEXT_ACTION: fresh independent formal review of PR 901 at head 54559aebc3
NEXT_PROMPT:

Execute the sanctioned gitea-reviewer workflow for PR #901 at head 54559aebc3668f4911943dcad93a3a04a1926789. Acquire the reviewer PR lease, review the complete effective diff against base master 715863799f7b42521acaa7c2d3636a113bf87cf9, run the focused suite for issue #897 plus the full regression suite from a branches/ worktree, compare failures against the current master baseline, and record a formal verdict pinned to that exact head.

WHAT_HAPPENED: The PR branch was synchronized with live base master via update-by-merge, advancing the head from 6e6ca94338 to 54559aebc3. Ancestry, parent set, and resulting tree were verified against a locally simulated clean merge and match exactly. commits_behind is now 0 and the PR reports mergeable with no conflicts.
WHY: Branch protection required the PR branch to contain the current base after PR #898 landed on master, and the head advance invalidates any verdict recorded at the former head.
RELATED_PRS: #901
BLOCKERS: none
VALIDATION: sync assessment reports pr_head_sha=54559aebc3668f4911943dcad93a3a04a1926789, base_head_sha=715863799f7b42521acaa7c2d3636a113bf87cf9, commits_behind=0, mergeable=true, has_conflicts=false; local ancestry proof merge-base --is-ancestor 715863799f7b 54559aeb succeeds; merge tree 7c47ece670 equals merge-tree --write-tree 6e6ca943 715863799f.
LAST_UPDATED_BY: prgs-author (jcwalker3)

[THREAD STATE LEDGER] what is true now: PR #901 remains in open state against base `master`. Live PR head is `54559aebc3668f4911943dcad93a3a04a1926789`; live base head is `715863799f7b42521acaa7c2d3636a113bf87cf9`. `commits_behind=0`, `mergeable=true`, `has_conflicts=false`, `approval_at_current_head=false`. what changed: merge result: base `master` @ `715863799f7b42521acaa7c2d3636a113bf87cf9` was brought into the PR branch by a sanctioned update-by-merge commit `54559aebc3668f4911943dcad93a3a04a1926789` (parents = `6e6ca9433873056c7a84d2a1ef3590323ea5a636`, `715863799f7b42521acaa7c2d3636a113bf87cf9`; no rebase, no force-push, first-parent lineage reaches the prior head). The resulting tree `7c47ece670a955fa156a0ab31312250d5aa3ca16` is byte-identical to a locally simulated clean merge of those two commits, so the sync carries zero conflict-resolution edits and zero out-of-scope content. Effective diff versus live base is confined to `gitea_mcp_server.py` and `tests/test_issue_897_permission_stale_runtime_classification.py`. The prior review verdict recorded at former head `6e6ca943` no longer applies to the current head and is treated as superseded, not reusable. what is blocked: nothing on the author side. Blocker classification: no blocker. who/what acts next: reviewer role (`prgs-reviewer`) performs a fresh independent formal review pinned to head `54559aebc3668f4911943dcad93a3a04a1926789`. Server-side decision state: PR #901 open; `recommended_next_action=fresh_review_required`; `approval_valid_for_merge=false`; `stale_approval=true`; no reviewer lease and no merger lease active. Local verdict/state: author sync objective satisfied at head `54559aebc3668f4911943dcad93a3a04a1926789`; worktree `branches/issue-897-permission-stale-runtime` fast-forwarded to that exact head and clean. Next actor: prgs-reviewer (sysadmin) Required action: acquire the reviewer PR lease for #901, review the full effective diff at head `54559aebc3668f4911943dcad93a3a04a1926789`, run the focused and regression suites against the current master baseline, then record a formal verdict at that exact head. Blocker classification: no blocker Do not do: do not reuse the former-head review verdict from `6e6ca943`; do not rebase or force-push this branch; do not merge before a formal verdict exists at the exact current head. ## Canonical Issue State STATE: author-sync-complete WHO_IS_NEXT: reviewer NEXT_ACTION: fresh independent formal review of PR 901 at head 54559aebc3668f4911943dcad93a3a04a1926789 NEXT_PROMPT: ```text Execute the sanctioned gitea-reviewer workflow for PR #901 at head 54559aebc3668f4911943dcad93a3a04a1926789. Acquire the reviewer PR lease, review the complete effective diff against base master 715863799f7b42521acaa7c2d3636a113bf87cf9, run the focused suite for issue #897 plus the full regression suite from a branches/ worktree, compare failures against the current master baseline, and record a formal verdict pinned to that exact head. ``` WHAT_HAPPENED: The PR branch was synchronized with live base master via update-by-merge, advancing the head from 6e6ca9433873056c7a84d2a1ef3590323ea5a636 to 54559aebc3668f4911943dcad93a3a04a1926789. Ancestry, parent set, and resulting tree were verified against a locally simulated clean merge and match exactly. `commits_behind` is now 0 and the PR reports mergeable with no conflicts. WHY: Branch protection required the PR branch to contain the current base after PR #898 landed on master, and the head advance invalidates any verdict recorded at the former head. RELATED_PRS: #901 BLOCKERS: none VALIDATION: sync assessment reports pr_head_sha=54559aebc3668f4911943dcad93a3a04a1926789, base_head_sha=715863799f7b42521acaa7c2d3636a113bf87cf9, commits_behind=0, mergeable=true, has_conflicts=false; local ancestry proof `merge-base --is-ancestor 715863799f7b 54559aeb` succeeds; merge tree 7c47ece670a955fa156a0ab31312250d5aa3ca16 equals `merge-tree --write-tree 6e6ca943 715863799f`. LAST_UPDATED_BY: prgs-author (jcwalker3)
sysadmin commented 2026-07-25 06:54:56 -05:00
Owner
Copy Link
Copy Source

[THREAD STATE LEDGER]

what is true now: PR #901 remains in open state at head 54559aebc3668f4911943dcad93a3a04a1926789 against base master 715863799f7b42521acaa7c2d3636a113bf87cf9. Review 592 carries an APPROVE review verdict recorded via the review API at that exact head (approval_at_current_head=true, review_feedback_stale=false). Former-head review 588 is now dismissed and reported stale. commits_behind=0, mergeable=true, has_conflicts=false, checks_status=not_required.

what changed: a fresh independent formal review was carried out at the post-sync head and recorded as review 592 by sysadmin under prgs-reviewer. The former-head verdict was not reused. Evidence: the sync commit's parents are exactly 6e6ca9433873056c7a84d2a1ef3590323ea5a636 and 715863799f7b42521acaa7c2d3636a113bf87cf9, and its tree 7c47ece670a955fa156a0ab31312250d5aa3ca16 is byte-identical to a locally simulated clean merge, so the branch sync contributed no content. Focused suite at this head: 23 passed, 12 subtests passed. Full suite at this head: 23 failed, 5267 passed, 6 skipped, 926 subtests passed. Master baseline at 715863799f from a separate branches/ worktree: 23 failed, 5256 passed, 6 skipped, 914 subtests passed. The two failure sets are identical line-by-line — no new failures and none fixed — and the delta is exactly the 11 new test methods plus 12 new subtests this PR adds. Two mutation probes confirm the new tests are not vacuous: neutering _reason_is_stale_runtime produced 11 failures, and restoring the pre-PR short-circuit in _profile_operation_gate produced 1. A live probe at the tool boundary reproduced all three typed refusal classes.

what is blocked: nothing on the reviewer side. Blocker classification: no blocker.

who/what acts next: merger role (prgs-merger) merges PR #901 pinned to head 54559aebc3668f4911943dcad93a3a04a1926789.

Server-side decision state: PR #901 open; review 592 APPROVED at 54559aebc3668f4911943dcad93a3a04a1926789; approval_valid_for_merge satisfied at that head; has_blocking_change_requests=false; reviewer lease held by session 18549-06adf7e9875e and available for sanctioned merger adoption.
Local verdict/state: three non-blocking observations recorded on review 592 (O1 unconverted gitea.pr.merge gate return in gitea_acquire_merger_pr_lease, proven unreachable while stale because the preceding gitea.pr.comment gate is typed and trips first; O2 latent reproof substring mismatch for namespace re-proof reasons, unreachable because no namespace is passed on that path; O3 the no-short-circuit accumulation lacks a direct test). None changes behaviour for the shipped paths.
Next actor: prgs-merger (sysadmin)
Required action: adopt the active reviewer lease through the sanctioned merger capability, then merge PR #901 with expected_head_sha=54559aebc3668f4911943dcad93a3a04a1926789.
Blocker classification: no blocker
Do not do: do not re-review at this head; do not merge at any other head; do not create a competing lease while the reviewer lease remains adoptable.

Canonical Issue State

STATE: reviewer-approved
WHO_IS_NEXT: merger
NEXT_ACTION: merge PR 901 at head 54559aebc3
NEXT_PROMPT:

Execute the sanctioned gitea-merger workflow for PR #901 at head 54559aebc3668f4911943dcad93a3a04a1926789 with base master 715863799f7b42521acaa7c2d3636a113bf87cf9. Adopt the active reviewer lease from session 18549-06adf7e9875e, re-resolve the merge capability, and merge with the head pinned.

WHAT_HAPPENED: A fresh independent review at the post-sync head recorded review 592 with an APPROVE verdict. The update-by-merge was audited as content-free, the full effective diff re-read, the #897 acceptance criteria re-verified against the real reason strings emitted by master_parity_gate and stable_control_runtime, and the full-suite failure set compared against the current master baseline.
WHY: The fix holds at this exact head, the sync introduced nothing of its own, no regression appeared against baseline, and the new tests demonstrably fail when the fix is neutered.
RELATED_PRS: #901
BLOCKERS: none
VALIDATION: focused pytest tests/test_issue_897_permission_stale_runtime_classification.py tests/test_permission_reports.py at 54559aeb -> 23 passed, 12 subtests; full suite at 54559aeb -> 23 failed / 5267 passed; baseline at 715863799f -> 23 failed / 5256 passed; failure sets identical; mutation probes MUT=1 -> 11 failed, MUT=2 -> 1 failed.
LAST_UPDATED_BY: prgs-reviewer (sysadmin)

NATIVE_REVIEW_PROOF: transport=native_mcp; entrypoint=mcp_server; token_fingerprint=3f9d215f6de35cd6

[THREAD STATE LEDGER] what is true now: PR #901 remains in open state at head `54559aebc3668f4911943dcad93a3a04a1926789` against base master `715863799f7b42521acaa7c2d3636a113bf87cf9`. Review 592 carries an APPROVE review verdict recorded via the review API at that exact head (`approval_at_current_head=true`, `review_feedback_stale=false`). Former-head review 588 is now dismissed and reported stale. `commits_behind=0`, `mergeable=true`, `has_conflicts=false`, `checks_status=not_required`. what changed: a fresh independent formal review was carried out at the post-sync head and recorded as review 592 by `sysadmin` under `prgs-reviewer`. The former-head verdict was not reused. Evidence: the sync commit's parents are exactly `6e6ca9433873056c7a84d2a1ef3590323ea5a636` and `715863799f7b42521acaa7c2d3636a113bf87cf9`, and its tree `7c47ece670a955fa156a0ab31312250d5aa3ca16` is byte-identical to a locally simulated clean merge, so the branch sync contributed no content. Focused suite at this head: 23 passed, 12 subtests passed. Full suite at this head: 23 failed, 5267 passed, 6 skipped, 926 subtests passed. Master baseline at `715863799f` from a separate `branches/` worktree: 23 failed, 5256 passed, 6 skipped, 914 subtests passed. The two failure sets are identical line-by-line — no new failures and none fixed — and the delta is exactly the 11 new test methods plus 12 new subtests this PR adds. Two mutation probes confirm the new tests are not vacuous: neutering `_reason_is_stale_runtime` produced 11 failures, and restoring the pre-PR short-circuit in `_profile_operation_gate` produced 1. A live probe at the tool boundary reproduced all three typed refusal classes. what is blocked: nothing on the reviewer side. Blocker classification: no blocker. who/what acts next: merger role (`prgs-merger`) merges PR #901 pinned to head `54559aebc3668f4911943dcad93a3a04a1926789`. Server-side decision state: PR #901 open; review 592 APPROVED at `54559aebc3668f4911943dcad93a3a04a1926789`; `approval_valid_for_merge` satisfied at that head; `has_blocking_change_requests=false`; reviewer lease held by session `18549-06adf7e9875e` and available for sanctioned merger adoption. Local verdict/state: three non-blocking observations recorded on review 592 (O1 unconverted `gitea.pr.merge` gate return in `gitea_acquire_merger_pr_lease`, proven unreachable while stale because the preceding `gitea.pr.comment` gate is typed and trips first; O2 latent `reproof` substring mismatch for namespace re-proof reasons, unreachable because no `namespace` is passed on that path; O3 the no-short-circuit accumulation lacks a direct test). None changes behaviour for the shipped paths. Next actor: prgs-merger (sysadmin) Required action: adopt the active reviewer lease through the sanctioned merger capability, then merge PR #901 with `expected_head_sha=54559aebc3668f4911943dcad93a3a04a1926789`. Blocker classification: no blocker Do not do: do not re-review at this head; do not merge at any other head; do not create a competing lease while the reviewer lease remains adoptable. ## Canonical Issue State STATE: reviewer-approved WHO_IS_NEXT: merger NEXT_ACTION: merge PR 901 at head 54559aebc3668f4911943dcad93a3a04a1926789 NEXT_PROMPT: ```text Execute the sanctioned gitea-merger workflow for PR #901 at head 54559aebc3668f4911943dcad93a3a04a1926789 with base master 715863799f7b42521acaa7c2d3636a113bf87cf9. Adopt the active reviewer lease from session 18549-06adf7e9875e, re-resolve the merge capability, and merge with the head pinned. ``` WHAT_HAPPENED: A fresh independent review at the post-sync head recorded review 592 with an APPROVE verdict. The update-by-merge was audited as content-free, the full effective diff re-read, the #897 acceptance criteria re-verified against the real reason strings emitted by `master_parity_gate` and `stable_control_runtime`, and the full-suite failure set compared against the current master baseline. WHY: The fix holds at this exact head, the sync introduced nothing of its own, no regression appeared against baseline, and the new tests demonstrably fail when the fix is neutered. RELATED_PRS: #901 BLOCKERS: none VALIDATION: focused pytest tests/test_issue_897_permission_stale_runtime_classification.py tests/test_permission_reports.py at 54559aeb -> 23 passed, 12 subtests; full suite at 54559aeb -> 23 failed / 5267 passed; baseline at 715863799f -> 23 failed / 5256 passed; failure sets identical; mutation probes MUT=1 -> 11 failed, MUT=2 -> 1 failed. LAST_UPDATED_BY: prgs-reviewer (sysadmin) NATIVE_REVIEW_PROOF: transport=native_mcp; entrypoint=mcp_server; token_fingerprint=3f9d215f6de35cd6
sysadmin removed the status:pr-open label 2026-07-25 06:56: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
bug
Something is not working
 duplicate
This issue or pull request already exists
 enhancement
New feature
 help wanted
Need some help
 invalid
Something is wrong
 question
More information is needed
 wontfix
This won't be fixed
No labels mcp-health safety stale-runtime type:bug workflow-hardening
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
jcwalker3 jwalker (Regular User Account) superadmin (Admin Account) sysadmin (Regular User Account)
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

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