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

Capability resolver and master parity checks disagree on stale MCP runtime #610

New Issue
Closed
opened 2026-07-09 17:30:25 -05:00 by jcwalker3 · 5 comments
jcwalker3 commented 2026-07-09 17:30:25 -05:00
Owner
Copy Link
Copy Source

Problem

During PR #592 recovery, gitea_assess_master_parity reported local parity as green because it compared local HEAD to local state, while gitea_resolve_task_capability correctly detected stale runtime and required restart. This can mislead sessions into thinking mutation is safe when the backend daemon is stale relative to live master.

Observed behavior

  • PR #592 was already merged.
  • Master advanced to 7186718cfd48… and later beyond.
  • Capability resolver reported stale runtime / restart required.
  • gitea_assess_master_parity still reported in_parity=true because it was blind to live remote/master staleness.
  • Resolver was authoritative and correctly fail-closed.

Required behavior

  • Master parity tooling must not report mutation-safe parity unless it verifies live target branch state.
  • Parity output should clearly distinguish:
    • local checkout parity
    • daemon start commit
    • live remote master/current target commit
    • resolver mutation safety
  • If resolver and parity disagree, output must fail closed and instruct restart/reconnect.
  • Mutation tools must trust the resolver/anti-stomp gate, not local parity alone.

Acceptance criteria

  1. Parity tool reports local HEAD, daemon start SHA, and live remote target SHA separately.
  2. A stale daemon cannot produce a mutation-safe parity result.
  3. Resolver/parity disagreement returns a typed blocker.
  4. Tests cover local parity green but daemon stale relative to live master.
  5. Final reports must identify resolver as authoritative for mutation safety.
  6. No mutation tool may proceed based only on local parity.

Implementation notes

  • Touch points likely include master_parity_gate.py, gitea_assess_master_parity / _current_master_parity in gitea_mcp_server.py, and stale-runtime checks in gitea_resolve_task_capability.
  • Align parity's mutation-safety signal with the resolver's stale-runtime detection (or explicitly nest parity under resolver authority).
  • Related: #604 (anti-stomp preflight), #609 (resume after stale backend), #606 (Sentry observability for stale-runtime).

Non-goals

  • Do not weaken resolver fail-closed behavior to match optimistic local parity.
  • Do not require network access to block all read-only diagnostics if live remote cannot be fetched; mutation-safe claims still fail closed when live state is unknown or stale.
## Problem During PR #592 recovery, `gitea_assess_master_parity` reported local parity as green because it compared local HEAD to local state, while `gitea_resolve_task_capability` correctly detected stale runtime and required restart. This can mislead sessions into thinking mutation is safe when the backend daemon is stale relative to live master. ## Observed behavior * PR #592 was already merged. * Master advanced to `7186718cfd48…` and later beyond. * Capability resolver reported stale runtime / restart required. * `gitea_assess_master_parity` still reported `in_parity=true` because it was blind to live remote/master staleness. * Resolver was authoritative and correctly fail-closed. ## Required behavior * Master parity tooling must not report mutation-safe parity unless it verifies live target branch state. * Parity output should clearly distinguish: * local checkout parity * daemon start commit * live remote master/current target commit * resolver mutation safety * If resolver and parity disagree, output must fail closed and instruct restart/reconnect. * Mutation tools must trust the resolver/anti-stomp gate, not local parity alone. ## Acceptance criteria 1. Parity tool reports local HEAD, daemon start SHA, and live remote target SHA separately. 2. A stale daemon cannot produce a mutation-safe parity result. 3. Resolver/parity disagreement returns a typed blocker. 4. Tests cover local parity green but daemon stale relative to live master. 5. Final reports must identify resolver as authoritative for mutation safety. 6. No mutation tool may proceed based only on local parity. ## Implementation notes * Touch points likely include `master_parity_gate.py`, `gitea_assess_master_parity` / `_current_master_parity` in `gitea_mcp_server.py`, and stale-runtime checks in `gitea_resolve_task_capability`. * Align parity's mutation-safety signal with the resolver's stale-runtime detection (or explicitly nest parity under resolver authority). * Related: #604 (anti-stomp preflight), #609 (resume after stale backend), #606 (Sentry observability for stale-runtime). ## Non-goals * Do not weaken resolver fail-closed behavior to match optimistic local parity. * Do not require network access to block *all* read-only diagnostics if live remote cannot be fetched; mutation-safe claims still fail closed when live state is unknown or stale.
jcwalker3 commented 2026-07-09 17:30:43 -05:00
Author
Owner
Copy Link
Copy Source

Canonical Issue State

STATE: ready for independent implementation
WHO_IS_NEXT: author
NEXT_ACTION: claim this issue and align master parity with live remote + resolver authority so stale daemons cannot report mutation-safe parity
NEXT_PROMPT:

Implement #610 on Scaled-Tech-Consulting/Gitea-Tools: fix master-parity safety gap. gitea_assess_master_parity must report local HEAD, daemon start SHA, and live remote target SHA separately; must not claim mutation-safe parity when daemon is stale relative to live master. Resolver/parity disagreement returns typed blocker; mutation tools trust resolver/anti-stomp, not local parity alone. Tests: local green + daemon stale vs live master. Context: PR #592 recovery observation.

WHAT_HAPPENED: Durable issue #610 created from observed PR #592 recovery gap (parity green while resolver correctly required restart). Related: #604 anti-stomp preflight, #609 resumable review after stale backend.
WHY: Local-only parity can mislead sessions into believing mutation is safe when the MCP daemon is stale relative to live master.
RELATED_PRS: #592 (merged; incident context)
BLOCKERS: none
VALIDATION: issue created with type:guardrail status:ready and labels workflow-hardening,stale-runtime,anti-stomp,mcp-health
LAST_UPDATED_BY: jcwalker3 (prgs-author)

## Canonical Issue State STATE: ready for independent implementation WHO_IS_NEXT: author NEXT_ACTION: claim this issue and align master parity with live remote + resolver authority so stale daemons cannot report mutation-safe parity NEXT_PROMPT: ```text Implement #610 on Scaled-Tech-Consulting/Gitea-Tools: fix master-parity safety gap. gitea_assess_master_parity must report local HEAD, daemon start SHA, and live remote target SHA separately; must not claim mutation-safe parity when daemon is stale relative to live master. Resolver/parity disagreement returns typed blocker; mutation tools trust resolver/anti-stomp, not local parity alone. Tests: local green + daemon stale vs live master. Context: PR #592 recovery observation. ``` WHAT_HAPPENED: Durable issue #610 created from observed PR #592 recovery gap (parity green while resolver correctly required restart). Related: #604 anti-stomp preflight, #609 resumable review after stale backend. WHY: Local-only parity can mislead sessions into believing mutation is safe when the MCP daemon is stale relative to live master. RELATED_PRS: #592 (merged; incident context) BLOCKERS: none VALIDATION: issue created with type:guardrail status:ready and labels workflow-hardening,stale-runtime,anti-stomp,mcp-health LAST_UPDATED_BY: jcwalker3 (prgs-author)
jcwalker3 added status:in-progress and removed status:ready labels 2026-07-09 17:34:30 -05:00
jcwalker3 commented 2026-07-09 17:34:33 -05:00
Author
Owner
Copy Link
Copy Source

Issue claim heartbeat

<!-- gitea-issue-claim-heartbeat:v1 --> **Issue claim heartbeat** - kind: claim - issue: #610 - branch: feat/issue-610-live-remote-parity - 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-21 18:38:05 -05:00
jcwalker3 commented 2026-07-21 18:40:37 -05:00
Author
Owner
Copy Link
Copy Source

Canonical Issue State

STATE: pr_open_awaiting_review
WHO_IS_NEXT: reviewer
NEXT_ACTION: formal independent review of PR #788 at head 324b4b3e93
NEXT_PROMPT:

Review PR #788 (Closes #610) on prgs Scaled-Tech-Consulting/Gitea-Tools as prgs-reviewer.
Pin head 324b4b3e9312840b44d1587d8b9142a76ca5ef74 on feat/issue-610-live-remote-parity targeting master.
Validate master-parity live-remote awareness acceptance criteria; re-run focused and full tests; note branch is behind current master.
Submit one formal APPROVE or REQUEST_CHANGES; do not merge.

WHAT_HAPPENED: Publication recovery adopted existing remote branch feat/issue-610-live-remote-parity @ 324b4b3e93 (already published; no push), locked #610 via own-branch adoption, created PR #788 targeting master, applied status:pr-open. Terminal author handoff also posted on PR #788 as comment 13800.
WHY: Open issue #610 had completed committed work ahead of master with no PR; publisher opens the missing review surface only (no implementation).
RELATED_PRS: #788 (canonical open PR for this issue); #592 (historical incident context only, already merged)
BLOCKERS: none for review handoff; branch is behind master so merge may later need author update_branch_by_merge
VALIDATION: Authoring-commit evidence: 13 new tests; full suite 2423 passed; 8 baseline keychain/env failures identical on unmodified base (not branch-caused). Publisher did not re-run the suite.
LAST_UPDATED_BY: jcwalker3 (prgs-author)
LLM_LOCK_ID: grok-pr-publisher-prod-v1
LLM_EXECUTION_ID: grok-pr-publisher-prod-v1-20260721T232804Z-pid18507-7b750eda

## Canonical Issue State STATE: pr_open_awaiting_review WHO_IS_NEXT: reviewer NEXT_ACTION: formal independent review of PR #788 at head 324b4b3e9312840b44d1587d8b9142a76ca5ef74 NEXT_PROMPT: ```text Review PR #788 (Closes #610) on prgs Scaled-Tech-Consulting/Gitea-Tools as prgs-reviewer. Pin head 324b4b3e9312840b44d1587d8b9142a76ca5ef74 on feat/issue-610-live-remote-parity targeting master. Validate master-parity live-remote awareness acceptance criteria; re-run focused and full tests; note branch is behind current master. Submit one formal APPROVE or REQUEST_CHANGES; do not merge. ``` WHAT_HAPPENED: Publication recovery adopted existing remote branch feat/issue-610-live-remote-parity @ 324b4b3e9312840b44d1587d8b9142a76ca5ef74 (already published; no push), locked #610 via own-branch adoption, created PR #788 targeting master, applied status:pr-open. Terminal author handoff also posted on PR #788 as comment 13800. WHY: Open issue #610 had completed committed work ahead of master with no PR; publisher opens the missing review surface only (no implementation). RELATED_PRS: #788 (canonical open PR for this issue); #592 (historical incident context only, already merged) BLOCKERS: none for review handoff; branch is behind master so merge may later need author update_branch_by_merge VALIDATION: Authoring-commit evidence: 13 new tests; full suite 2423 passed; 8 baseline keychain/env failures identical on unmodified base (not branch-caused). Publisher did not re-run the suite. LAST_UPDATED_BY: jcwalker3 (prgs-author) LLM_LOCK_ID: grok-pr-publisher-prod-v1 LLM_EXECUTION_ID: grok-pr-publisher-prod-v1-20260721T232804Z-pid18507-7b750eda
jcwalker3 added status:in-progress and removed status:pr-open labels 2026-07-21 20:45:28 -05:00
jcwalker3 commented 2026-07-21 20:45:29 -05:00
Author
Owner
Copy Link
Copy Source

Issue claim heartbeat

<!-- gitea-issue-claim-heartbeat:v1 --> **Issue claim heartbeat** - kind: claim - issue: #610 - branch: feat/issue-610-live-remote-parity - phase: claimed - profile: prgs-author - pr: none - blocker: none - next_action: create worktree and begin implementation
jcwalker3 commented 2026-07-21 21:23:33 -05:00
Author
Owner
Copy Link
Copy Source

Issue claim heartbeat

  • kind: progress
  • issue: Capability resolver and master parity checks disagree on stale MCP runtime (#610)
  • branch: feat/issue-610-live-remote-parity
  • phase: blocked
  • profile: prgs-author
  • pr: 788
  • blocker: duplicate-gate head mismatch after external update-by-merge: recovered owning-PR evidence pins 324b4b3, live PR head is 0f19773; commit gate fails closed; evidence refresh requires non-live lock (sanctioned namespace reconnect, never manual kill)
  • next_action: operator reconnects gitea-author MCP namespace; new session re-runs gitea_lock_issue dead-session recovery on the clean worktree, then restores edits from /tmp/pr788-remediation.patch and commits via gitea_commit_files
<!-- gitea-issue-claim-heartbeat:v1 --> **Issue claim heartbeat** - kind: progress - issue: #610 - branch: feat/issue-610-live-remote-parity - phase: blocked - profile: prgs-author - pr: 788 - blocker: duplicate-gate head mismatch after external update-by-merge: recovered owning-PR evidence pins 324b4b3, live PR head is 0f19773; commit gate fails closed; evidence refresh requires non-live lock (sanctioned namespace reconnect, never manual kill) - next_action: operator reconnects gitea-author MCP namespace; new session re-runs gitea_lock_issue dead-session recovery on the clean worktree, then restores edits from /tmp/pr788-remediation.patch and commits via gitea_commit_files
sysadmin removed the status:in-progress label 2026-07-22 05:51:57 -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 anti-stomp mcp-health stale-runtime type:guardrail 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
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

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