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

New Issue

2026-07-09T17:30:25-05:00

jcwalker3 commented

2026-07-09 17:30:25 -05:00

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

Parity tool reports local HEAD, daemon start SHA, and live remote target SHA separately.
A stale daemon cannot produce a mutation-safe parity result.
Resolver/parity disagreement returns a typed blocker.
Tests cover local parity green but daemon stale relative to live master.
Final reports must identify resolver as authoritative for mutation safety.
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 added the type:guardrail status:ready workflow-hardening anti-stomp mcp-health stale-runtime labels 2026-07-09 17:30:26 -05:00

jcwalker3 commented

2026-07-09 17:30:43 -05:00

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

Issue claim heartbeat

kind: claim
issue: Capability resolver and master parity checks disagree on stale MCP runtime (#610)
branch: feat/issue-610-live-remote-parity
phase: claimed
profile: prgs-author
pr: none
blocker: none
next_action: create worktree and begin implementation

**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 referenced this issue from a commit

2026-07-09 17:53:15 -05:00

feat: make master-parity live-remote aware so a stale daemon fails closed (Closes #610)