Master-parity previously compared only the daemon's startup commit against the
local on-disk HEAD. When the checkout was not pulled, parity reported green even
though the live remote master had advanced, so a stale daemon could claim a
mutation-safe result while running outdated capability gates (observed during
PR #592 recovery, where the resolver correctly required restart but parity said
in_parity=true).
Changes:
- master_parity_gate.assess_master_parity() gains an optional live_remote_head
and reports the three commits distinctly (daemon_start_head, local_head,
live_remote_head) plus live_known / live_stale / mutation_safe. A result is
mutation_safe only when daemon, local checkout, and live remote all agree.
- parity_block_reasons() now blocks mutations on live-staleness too; read-only
operations remain unblocked (non-goal: never block diagnostics offline).
- New parity_resolver_disagreement(): typed fail-closed blocker naming the
capability resolver as authoritative when it requires restart but parity
looks locally green.
- New read_remote_master_head(): best-effort `git ls-remote` for the live
target, cached with a 60s TTL (bounded offline latency, no network probe per
gate call); env override GITEA_TEST_LIVE_REMOTE_HEAD keeps tests hermetic.
- Server: _current_master_parity() reads the live remote head;
gitea_assess_master_parity and runtime_context surface the distinguished
SHAs, mutation_safe, and resolver-authoritative guidance.
Tests: 13 new cases (live-remote parity, live-stale blocking + typed blocker,
remote-head reader + TTL cache, server wiring). Full suite: 2423 passed; the 8
remaining failures (test_config TestAuthIntegration, test_credentials
TestGetCredentials) are baseline-proven keychain/env failures identical on the
unmodified base.
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
The MCP server loads capability-gate code into memory at startup, so a
newly merged gate (e.g. the branch-delete capability gate #408/#410) does
not take effect until the process restarts. A long-running server could
therefore still perform a mutation the updated codebase forbids.
Runtime profile/config data is already read live from disk each call
(gitea_config.load_config re-reads the JSON), so allowed_operations changes
apply without a restart. This closes the remaining gap: *code* parity.
- master_parity_gate.py: capture the process's startup commit and, at
mutation time, compare it against the on-disk master HEAD; pure,
injectable assessment plus block-reasons and a restart-required report.
- gitea_mcp_server.py: capture _STARTUP_PARITY at import; _profile_operation_gate
fails closed for mutating ops when stale while leaving gitea.read allowed;
gitea_get_runtime_context surfaces master_parity; new read-only
gitea_assess_master_parity tool reports parity/restart-required.
- Escape hatches: GITEA_MCP_DISABLE_PARITY_GATE (ops), GITEA_TEST_CURRENT_HEAD (tests).
- tests/test_master_parity_gate.py: 18 cases (pure logic, block/report,
read override, and server wiring: reads pass, mutations blocked when stale).
Validation: venv/bin/python -m pytest -q -> 1618 passed, 6 skipped.
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
sysadminandClaude Opus 4.8