sysadminandClaude Opus 4.8
243f52dc79
Slice A of Issue #790, per the controller reassessment in comment 13958. Does
not close the issue: terminal retirement (Slice B) and the read-side generation
check plus the #760 renewal re-scope (Slice C) are deliberately not implemented.
The defect. `issue_lock_store.assess_lock_freshness` parsed `last_heartbeat_at`
and then never consulted it. Liveness was decided by an absolute four-hour
`expires_at` and by PID liveness, and the recorded PID is the long-lived MCP
daemon rather than the authoring task, so an abandoned claim stayed live for the
full four hours. A tree-wide search found the field written in exactly one place
and advanced by nothing. Issue #787 / PR #789 hit this; Issue #760 / PR #791 hit
it again, blocking reconciliation for over five hours after its work had landed.
A1 — central policy. New `lease_policy` declares every duration for every task
class in one place: author initial/sliding TTL 10 minutes, heartbeat cadence 2,
stale warning 5, missed-heartbeat grace 10, absolute cap 8 hours, recovery grace
10, terminal race-drain 2. It ships first so the first heartbeat and TTL
behavior to run reads from it (AC-N7). The duplicated four-hour literal is gone
from both `issue_lock_store` and `gitea_mcp_server`. Reviewer, merger, and
conflict-fix classes are declared but not rewired — Slice C moves those call
sites — and a test asserts the declaration still equals the constants #747 and
`pr_work_lease` own, so the two cannot drift apart unnoticed.
A2 — load-bearing freshness, with two deliberate asymmetries. An alive PID never
establishes freshness anywhere (AC-N2); it is recorded as evidence and no branch
returns live because of it. A dead PID still marks a lease stale, and that band
still precedes every heartbeat evaluation, so #753 dead-session recovery keys on
exactly the classification it always did. New bands `stale_missed_heartbeat` and
`stale_absolute_cap` are classified in `branch_cleanup_guard` rather than
falling through to unknown-status, and still block unless the ownership record
proves `reclaim_allowed is True`. A heartbeat lease carrying no heartbeat is
contradictory and fails closed. `assess_expired_lock_reclaim` accepts a lapsed
heartbeat as reclaim grounds for heartbeat-lifecycle leases only: under this
lifecycle the heartbeat is the liveness proof, and also requiring a dead PID
would reinstate the original defect.
A3/A4 — task-session identity and the writer. `mint_task_session_id` produces an
ownership key containing no process identifier, since the daemon PID is reused
by every task it serves and identifies none of them. `heartbeat_session_lock`
writes inside the existing per-issue flock under the #772 generation
compare-and-swap, verifying exact issue, branch, realpath-normalized worktree,
claimant username, claimant profile, and recorded session identifier. It cannot
acquire, take over, or revive: a lease past its grace is refused and must use
the reclaim path, so a session that stopped proving liveness cannot restore
ownership retroactively. New `gitea_heartbeat_issue_lock` gates on the same
authority as `lock_issue`, being strictly narrower.
A5 — legacy compatibility (AC-N8). The explicit `lifecycle_version` marker, never
a timestamp comparison, discriminates legacy from heartbeat leases: a legacy lock
has `last_heartbeat_at == created_at` forever precisely because nothing advanced
it, and a freshly minted heartbeat lease has them equal too, so the equality
carries no information in either direction. Legacy locks keep their recorded
absolute expiry and are never evaluated against the short grace, so deployment
cannot make an existing claim instantly reclaimable. They leave that state only
by terminal retirement (Slice B) or by `rebind_legacy_lock`, which re-verifies
the exact owner and mints a genuine identifier and first heartbeat while
preserving the original claim under `legacy_origin`. Rebinding a lapsed legacy
lease is refused; that belongs to #760 renewal or #601 reclaim.
A6 — native coverage. Review #499 proved assessor-level tests miss discard
points, so `tests/test_issue_790_heartbeat_mcp_path.py` drives the real tools
against a real git repository and a real durable lock: lock creation and
read-back, policy window, freshness, survival of `verify_lock_for_mutation`,
invariance of the duplicate-work and linked-open-PR gates, CAS rejection,
foreign-session and foreign-claimant refusal, alive-PID-only refusal, missed
heartbeat, legacy protection on deployment, and legacy rebinding.
Tests. New suites 55 passed. Lock and lease regression set (issue_lock_store,
lease_lifecycle, #753, #755, #760 x2, #768, #772, lock registration, worktree,
adoption, duplicate gate, branch cleanup guard, capability invariants, claim
heartbeat, worktrees) 383 passed with 98 subtests. Full suite 4295 passed, 11
failed, 6 skipped, 499 subtests passed, against a clean master baseline worktree
at 620ed6e9 that reports 11 failed and 4240 passed — the same eleven node IDs.
The 55-test delta is exactly the new suites; no new failures.
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_011u6GKSJwwrrYjguPjs1aK5
5.9 KiB
5.9 KiB
Registered MCP tool inventory
This is the canonical list of tools the Gitea-Tools MCP server registers. It
exists because documentation and the registered inventory drifted: the workflow
documented a gitea_edit_issue tool that no namespace had ever registered, so a
mutation could be planned against a tool that did not exist and only fail at
execution time (#781).
The rule
Documentation must never name a tool an actor cannot reach.
Two guards enforce it, both in tests/test_issue_781_edit_issue_tool.py:
- The list below must equal the registered tool set exactly — sorted, no duplicates, nothing missing in either direction. Adding a tool without documenting it fails, and documenting a tool without registering it fails.
- Every backticked
gitea_*/mcp_*identifier inskills/**/*.mdmust be a registered tool. Module and script names that share the prefix are listed explicitly inmcp_tool_inventory.NON_TOOL_IDENTIFIERSrather than being waved through by a looser pattern.
Updating this file
When you add or remove an @mcp.tool(), regenerate the block below:
PYTEST_CURRENT_TEST=1 venv/bin/python -c "
import mcp_server, mcp_tool_inventory
print(mcp_tool_inventory.render_inventory_block(
mcp_server.mcp._tool_manager._tools))
"
Replace everything between the markers with that output. Do not hand-edit individual entries — the generator and the guard share one ordering rule.
Registered tools
Namespaces (gitea-tools, gitea-reviewer, gitea-merger, gitea-reconciler)
register the same tool set; what differs per namespace is the execution profile
that gates each call, not which tools exist.
gitea_abandon_workflow_leasegitea_acquire_conflict_fix_leasegitea_acquire_merger_pr_leasegitea_acquire_reviewer_pr_leasegitea_activate_profilegitea_adopt_merger_pr_leasegitea_adopt_workflow_leasegitea_allocate_next_workgitea_assess_already_landed_reconciliationgitea_assess_conflict_fix_classificationgitea_assess_conflict_fix_pushgitea_assess_gitea_operation_pathgitea_assess_master_paritygitea_assess_mcp_namespace_healthgitea_assess_pr_sync_statusgitea_assess_review_merge_state_machinegitea_assess_reviewer_pr_leasegitea_assess_terminal_label_hygienegitea_assess_work_issue_duplicategitea_assess_worktree_cleanup_integritygitea_audit_configgitea_audit_runtime_recovery_contaminationgitea_audit_stable_branch_contaminationgitea_audit_worktree_cleanupgitea_authorize_reconciliation_cleanup_phasegitea_authorize_review_correctiongitea_capability_stop_terminal_reportgitea_capture_branches_worktree_snapshotgitea_check_pr_eligibilitygitea_cleanup_merged_pr_branchgitea_cleanup_obsolete_reviewer_comment_leasegitea_cleanup_post_merge_moot_leasegitea_cleanup_stale_claimsgitea_cleanup_stale_review_decision_lockgitea_cleanup_terminal_pr_labelsgitea_close_issuegitea_commit_filesgitea_consume_irrecoverable_decision_lock_provenancegitea_create_issuegitea_create_issue_commentgitea_create_labelgitea_create_prgitea_delete_branchgitea_diagnose_review_decision_lockgitea_diagnose_reviewer_pr_lease_handoffgitea_diagnose_terminalgitea_dry_run_pr_reviewgitea_edit_issuegitea_edit_prgitea_expire_workflow_leasesgitea_get_authenticated_usergitea_get_current_usergitea_get_filegitea_get_pr_review_feedbackgitea_get_profilegitea_get_runtime_contextgitea_get_shell_healthgitea_heartbeat_issue_lockgitea_heartbeat_reviewer_pr_leasegitea_inspect_workflow_leasegitea_issue_irrecoverable_provenance_authorizationgitea_list_dependency_edgesgitea_list_issue_commentsgitea_list_issuesgitea_list_labelsgitea_list_profilesgitea_list_prsgitea_list_workflow_leasesgitea_load_review_workflowgitea_lock_issuegitea_mark_final_review_decisiongitea_mark_issuegitea_merge_prgitea_mirror_refsgitea_observability_link_issuegitea_observability_list_projectsgitea_observability_reconcile_incidentgitea_post_heartbeatgitea_quarantine_contaminated_reviewgitea_reclaim_expired_workflow_leasegitea_reconcile_already_landed_prgitea_reconcile_issue_claimsgitea_reconcile_merged_cleanupsgitea_reconcile_superseded_by_merged_prgitea_record_daemon_process_kill_attemptgitea_record_irrecoverable_decision_lock_provenancegitea_record_pre_review_commandgitea_record_shell_spawn_outcomegitea_record_stable_branch_push_attemptgitea_release_merger_pr_leasegitea_release_reviewer_pr_leasegitea_release_workflow_leasegitea_resolve_task_capabilitygitea_resume_review_draftgitea_review_prgitea_route_task_sessiongitea_save_review_draftgitea_scan_already_landed_open_prsgitea_sentry_get_issue_eventsgitea_sentry_link_gitea_issuegitea_sentry_list_issuesgitea_sentry_reconcile_issuegitea_sentry_watchdoggitea_set_issue_labelsgitea_submit_pr_reviewgitea_update_pr_branch_by_mergegitea_validate_review_final_reportgitea_view_issuegitea_view_prgitea_whoamigitea_workflow_dashboardmcp_check_workflow_skill_preflightmcp_get_control_plane_guidemcp_get_skill_guidemcp_list_project_skills
Issue-content editing
gitea_edit_issue is the only path that changes an issue's title or body. It
PATCHes the issue endpoint, refuses a pull-request number, sends only the fields
the caller named, and proves the result by read-after-write — including that
state, labels, assignees, and milestone did not move.
gitea_edit_pr remains pull-request-only. The two paths never merge: a single
tool that accepted either kind would make the narrower capability reachable
through the wider one.