Allow safe author-lock recovery after the owning MCP session exits #753

New Issue

Closed

opened 2026-07-18 18:20:34 -05:00 by jcwalker3 · 1 comment

jcwalker3 commented 2026-07-18 18:20:34 -05:00

Owner

Copy Link

Copy Source

Summary

A durable author issue lock becomes permanently unusable when the MCP session that created it exits, even though every piece of ownership evidence still matches exactly. There is no sanctioned native path to recover it, and the obvious re-lock path is blocked by a guard that a real PR branch can never satisfy.

Observed failure

Reproduced against PR #750 / issue #749 while attempting a routine branch update.

The durable lock record for issue #749 matches its work exactly:

• locked issue 749
• locked branch fix/issue-749-create-issue-bootstrap — the exact head branch of open PR #750
• locked worktree branches/issue-749-create-issue-bootstrap — a real, registered Git worktree
• claimant jcwalker3 / profile prgs-author
• worktree clean; local head, remote branch head, and PR #750 head all e349839fd739e10af2df9c0f429ac487e8ca8b9d

The only thing that changed is that the recording MCP process exited:

• recorded session_pid / pid = 48545, which is dead (kill -0 fails, no such process)
• the current MCP server processes carry different PIDs

Consequences observed:

1. assess_lock_freshness (issue_lock_store.py) returns status="stale", live=false, reason owner pid 48545 is not alive. Note the lease itself had not expired — work_lease.expires_at was still roughly 55 minutes in the future. The lock is non-live purely because of PID death.
2. gitea_update_pr_branch_by_merge requires a live author lock via verify_lock_for_mutation, and correctly fails closed.
3. gitea_lock_issue cannot recover the lock from the existing PR worktree. assess_issue_lock_worktree (issue_lock_worktree.py) rejects the worktree because base_equivalent is false, demanding that the worktree HEAD equal a base branch (master/main/dev) SHA before the lock may be taken.

Point 3 is the structural part of the defect: an existing PR branch is necessarily ahead of its base, so it can never be base-equivalent. The branch above is 2 commits ahead of and 1 behind master. Any branch with work on it fails this check by construction, which makes normal re-lock unreachable after a session restart for every PR that already exists.

Why the existing reclaim path does not cover this

assess_expired_lock_reclaim already sanctions reclaiming a non-live lock when the owner process is dead or the worktree is missing. However, assess_same_issue_lease_conflict only consults it inside an is_lease_expired(...) branch. A lock that is stale-by-dead-PID but whose lease has not yet expired never reaches that path, so the existing recovery affordance does not apply to this case.

Non-sanctioned escapes (explicitly rejected)

The following were considered and refused as recovery, because each launders false evidence through a guard:

• hand-editing the durable lock JSON
• declaring a false stacked_base_branch / stacked_base_pr to bypass base-equivalence
• creating a throwaway base-equivalent worktree to satisfy the check while the real work lives elsewhere
• waiting for the lease TTL to expire purely to unlock a different code path

Required behavior

Provide a native, truthful recovery path for a dead-session durable author lock when ownership evidence still matches exactly, without weakening the guards that protect brand-new issue claims.

Acceptance criteria

AC1 — Recovery may succeed only when all required evidence agrees:

• same remote, organization, repository, and issue
• same configured author identity/profile
• same locked branch
• same registered worktree path
• worktree is clean
• local head equals remote branch head
• open PR head equals that same head when a PR exists
• recorded PID is demonstrably dead
• no live competing author lock or lease exists
• no conflicting branch claims the issue
• no different worktree, branch, head, or author is being substituted

AC2 — The recovery must:

• atomically rebind or replace the dead session ownership
• record that recovery occurred after session death
• record the prior and replacement session identity/PID where safe
• renew the lease using normal policy

AC3 — The recovery must remain fail-closed for:

• a live prior PID
• dirty worktrees
• local/remote/PR head mismatch
• foreign branch, identity, worktree, or lease conflicts

AC4 — Scope discipline:

• recovery must not require an existing PR branch to match its base
• normal base-equivalence requirements are preserved for brand-new issue claims
• a native sanctioned MCP path is exposed rather than requiring file edits

AC5 — Downstream acceptance: a recovered lock must satisfy gitea_update_pr_branch_by_merge, existing PR mutation ownership verification, and subsequent author handoff and PR update paths.

AC6 — Evidence: structured recovery evidence is recorded for auditing, without exposing secrets.

AC7 — Regression tests cover positive recovery and every rejection condition above, including: dead PID with exact proof succeeds; live prior PID refused; different author/profile refused; different branch refused; different worktree refused; dirty worktree refused; local head differing from remote refused; PR head differing refused; competing live lock or lease refused; multiple candidate branches refused; malformed or incomplete durable lock refused; new-issue base-equivalence still enforced; recovered lock satisfies update-by-merge ownership checks; recovery record preserves truthful provenance; no manual file seeding required.

References

• #749 / #750 — the work blocked by this defect; PR #750 could not have its branch updated.
• #601 — introduced lease adopt/release/expire/abandon and assess_expired_lock_reclaim; its reclaim path is gated behind lease expiry and so does not reach the dead-PID-but-unexpired case.
• #249 — origin of the issue-lock worktree base-equivalence requirement.
• #484 — stacked-base opt-in; deliberately not usable as a recovery escape here.
• #702 — stale runtime binding and orphaned durable lease on daemon crash; adjacent, but did not address author-lock re-acquisition.
• #438 — verify_lock_for_mutation ownership re-check consuming lock freshness.

## Summary A durable author issue lock becomes permanently unusable when the MCP session that created it exits, even though every piece of ownership evidence still matches exactly. There is no sanctioned native path to recover it, and the obvious re-lock path is blocked by a guard that a real PR branch can never satisfy. ## Observed failure Reproduced against PR #750 / issue #749 while attempting a routine branch update. The durable lock record for issue #749 matches its work exactly: - locked issue `749` - locked branch `fix/issue-749-create-issue-bootstrap` — the exact head branch of open PR #750 - locked worktree `branches/issue-749-create-issue-bootstrap` — a real, registered Git worktree - claimant `jcwalker3` / profile `prgs-author` - worktree clean; local head, remote branch head, and PR #750 head all `e349839fd739e10af2df9c0f429ac487e8ca8b9d` The only thing that changed is that the recording MCP process exited: - recorded `session_pid` / `pid` = `48545`, which is dead (`kill -0` fails, no such process) - the current MCP server processes carry different PIDs Consequences observed: 1. `assess_lock_freshness` (`issue_lock_store.py`) returns `status="stale"`, `live=false`, reason `owner pid 48545 is not alive`. Note the lease itself had **not** expired — `work_lease.expires_at` was still roughly 55 minutes in the future. The lock is non-live purely because of PID death. 2. `gitea_update_pr_branch_by_merge` requires a live author lock via `verify_lock_for_mutation`, and correctly fails closed. 3. `gitea_lock_issue` cannot recover the lock from the existing PR worktree. `assess_issue_lock_worktree` (`issue_lock_worktree.py`) rejects the worktree because `base_equivalent` is `false`, demanding that the worktree HEAD equal a base branch (`master`/`main`/`dev`) SHA before the lock may be taken. Point 3 is the structural part of the defect: **an existing PR branch is necessarily ahead of its base**, so it can never be base-equivalent. The branch above is 2 commits ahead of and 1 behind master. Any branch with work on it fails this check by construction, which makes normal re-lock unreachable after a session restart for every PR that already exists. ### Why the existing reclaim path does not cover this `assess_expired_lock_reclaim` already sanctions reclaiming a non-live lock when the owner process is dead or the worktree is missing. However, `assess_same_issue_lease_conflict` only consults it inside an `is_lease_expired(...)` branch. A lock that is stale-by-dead-PID but whose lease has **not** yet expired never reaches that path, so the existing recovery affordance does not apply to this case. ### Non-sanctioned escapes (explicitly rejected) The following were considered and refused as recovery, because each launders false evidence through a guard: - hand-editing the durable lock JSON - declaring a false `stacked_base_branch` / `stacked_base_pr` to bypass base-equivalence - creating a throwaway base-equivalent worktree to satisfy the check while the real work lives elsewhere - waiting for the lease TTL to expire purely to unlock a different code path ## Required behavior Provide a native, truthful recovery path for a dead-session durable author lock when ownership evidence still matches exactly, without weakening the guards that protect brand-new issue claims. ## Acceptance criteria **AC1 — Recovery may succeed only when all required evidence agrees:** - same remote, organization, repository, and issue - same configured author identity/profile - same locked branch - same registered worktree path - worktree is clean - local head equals remote branch head - open PR head equals that same head when a PR exists - recorded PID is demonstrably dead - no live competing author lock or lease exists - no conflicting branch claims the issue - no different worktree, branch, head, or author is being substituted **AC2 — The recovery must:** - atomically rebind or replace the dead session ownership - record that recovery occurred after session death - record the prior and replacement session identity/PID where safe - renew the lease using normal policy **AC3 — The recovery must remain fail-closed for:** - a live prior PID - dirty worktrees - local/remote/PR head mismatch - foreign branch, identity, worktree, or lease conflicts **AC4 — Scope discipline:** - recovery must not require an existing PR branch to match its base - normal base-equivalence requirements are preserved for brand-new issue claims - a native sanctioned MCP path is exposed rather than requiring file edits **AC5 — Downstream acceptance:** a recovered lock must satisfy `gitea_update_pr_branch_by_merge`, existing PR mutation ownership verification, and subsequent author handoff and PR update paths. **AC6 — Evidence:** structured recovery evidence is recorded for auditing, without exposing secrets. **AC7 — Regression tests** cover positive recovery and every rejection condition above, including: dead PID with exact proof succeeds; live prior PID refused; different author/profile refused; different branch refused; different worktree refused; dirty worktree refused; local head differing from remote refused; PR head differing refused; competing live lock or lease refused; multiple candidate branches refused; malformed or incomplete durable lock refused; new-issue base-equivalence still enforced; recovered lock satisfies update-by-merge ownership checks; recovery record preserves truthful provenance; no manual file seeding required. ## References - **#749 / #750** — the work blocked by this defect; PR #750 could not have its branch updated. - **#601** — introduced lease adopt/release/expire/abandon and `assess_expired_lock_reclaim`; its reclaim path is gated behind lease expiry and so does not reach the dead-PID-but-unexpired case. - **#249** — origin of the issue-lock worktree base-equivalence requirement. - **#484** — stacked-base opt-in; deliberately not usable as a recovery escape here. - **#702** — stale runtime binding and orphaned durable lease on daemon crash; adjacent, but did not address author-lock re-acquisition. - **#438** — `verify_lock_for_mutation` ownership re-check consuming lock freshness.

jcwalker3 added the mcpreliabilitystatus:readyworkflow-hardeningrecoverysafetytype:bug labels 2026-07-18 18:20:34 -05:00

jcwalker3 referenced this issue from a commit 2026-07-18 18:32:22 -05:00

fix(mcp): allow author-lock recovery after the owning session exits (Closes #753)

jcwalker3 referenced a pull request that will close this issue 2026-07-18 18:33:05 -05:00

fix(mcp): allow author-lock recovery after the owning session exits (Closes #753) #754

jcwalker3 added status:pr-open and removed status:ready labels 2026-07-18 18:33:05 -05:00

jcwalker3 commented 2026-07-18 18:35:39 -05:00

Author

Owner

Copy Link

Copy Source

[THREAD STATE LEDGER] Issue #753 — implementation pushed; PR #754 opened by author

What is true now:

• Issue state: open, labels include status:pr-open
• PR #754 state: open against master
• Current head SHA: 3edeba4d7f
• Server-side decision state: no review verdict exists for PR #754
• Local verdict/state: author work complete; no verdict prepared by this session
• Latest known validation: full suite 3498 passed, 6 skipped, 2 failed; both failures reproduce identically on pristine master 0425bf9a43

What changed:

• Created issue #753 from a temporary registered pre-issue worktree, which was then removed
• Acquired the durable author lock for #753 on branch fix/issue-753-dead-pid-author-lock-recovery
• Added issue_lock_recovery.py, wired it into gitea_lock_issue, threaded recovery_sanctioned through assess_issue_lock_worktree, exposed branch_carries_issue_marker
• Committed 3edeba4d7f and pushed the branch
• Opened PR fix(mcp): allow author-lock recovery after the owning session exits (Closes #753) (#754)

What is blocked:

• Blocker classification: no blocker

Who/what acts next:

• Next actor: reviewer
• Required action: perform a fresh independent native review of PR #754 at head 3edeba4d7f
• Do not do: reuse this author session, and do not alter PR #750 or PR fix(mcp): bind post-merge moot-lease cleanup to the reconciler capability (Closes #745) (#746)
• Resume from: PR #754 diff and the acceptance criteria in this issue

Canonical Issue State

STATE:
Issue #753 is open with an implementation pushed and PR #754 opened against master at head 3edeba4d7f. No review verdict exists.

WHO_IS_NEXT:
reviewer

NEXT_ACTION:
Perform a fresh independent native review of PR #754 pinned at head 3edeba4d7f, checking each acceptance criterion AC1 through AC7 in this issue against the diff.

NEXT_PROMPT:

Review PR #754 in Scaled-Tech-Consulting/Gitea-Tools on remote prgs as an independent reviewer in a fresh session bound to prgs-reviewer. Pin head 3edeba4d7f2ae320fb46f76b0e848c952b3cd9ce. Verify AC1 through AC7 of issue #753: that dead-session recovery requires exact agreement on remote, org, repo, issue, author identity and profile, locked branch with the worktree occupying it, registered worktree path, clean worktree, local head matching remote head and open PR head, a demonstrably dead recorded PID, absence of competing live locks or leases, and absence of ambiguous branch claims; that the waiver suppresses only the base-branch match requirement and never cleanliness; that brand-new issue claims retain the full requirement; that a refused assessment withholds the waiver rather than raising, so the pre-existing guard still fails closed; and that recovery provenance is recorded without secrets. Do not alter PR #750 or PR #746.

WHAT_HAPPENED:
The author session verified the defect against the live durable lock for issue #749: the lock matched issue #749, branch fix/issue-749-create-issue-bootstrap, and the registered worktree branches/issue-749-create-issue-bootstrap, with a clean worktree and local head, remote head and PR #750 head all e349839fd7, while recorded pid 48545 was dead and the lease still had roughly 55 minutes remaining. Issue #753 was then created, its lock acquired on a fresh worktree at master, the recovery assessor implemented with regression tests, and PR #754 opened.

WHY:
A durable author lock records the owning MCP session PID. When that process exits the lock is classified stale even inside its lease TTL, so ownership checks fail closed, and re-locking is unreachable because the worktree gate requires the branch to match its base while any branch carrying work is ahead of its base. This change supplies a native recovery path gated on exact durable ownership evidence.

RELATED_PRS:
PR #754 implements this issue. PR #750 and issue #749 supplied the reproduction and were not modified. PR #746 was not modified.

BLOCKERS:
no blocker

VALIDATION:
New suite tests/test_issue_753_dead_pid_lock_recovery.py 33 passed. Issue-lock, adoption, store, provenance, registration, duplicate-gate, worktree and create-issue-guard suites 120 passed. MCP server, commit payloads, handoff ledger, PR ownership and branch cleanup suites 286 passed. Full suite 3498 passed, 6 skipped, 2 failed. The 2 failures are test_issue_702_review_findings_f1_f6.py::TestF1RecoveryBeforeTerminalProbe::test_removed_worktree_recovers_before_probe and test_reconciler_supersession_close.py::TestReconcilerSupersessionMcpTool::test_tool_posts_comment_and_closes_superseded_pr_issue, both reproduced identically in a throwaway detached worktree at pristine master 0425bf9a43, so they are pre-existing. git diff --check clean.

LAST_UPDATED_BY:
author

[THREAD STATE LEDGER] Issue #753 — implementation pushed; PR #754 opened by author What is true now: - Issue state: open, labels include status:pr-open - PR #754 state: open against master - Current head SHA: 3edeba4d7f2ae320fb46f76b0e848c952b3cd9ce - Server-side decision state: no review verdict exists for PR #754 - Local verdict/state: author work complete; no verdict prepared by this session - Latest known validation: full suite 3498 passed, 6 skipped, 2 failed; both failures reproduce identically on pristine master 0425bf9a4325a25b72739fba81604463e3e5e363 What changed: - Created issue #753 from a temporary registered pre-issue worktree, which was then removed - Acquired the durable author lock for #753 on branch fix/issue-753-dead-pid-author-lock-recovery - Added issue_lock_recovery.py, wired it into gitea_lock_issue, threaded recovery_sanctioned through assess_issue_lock_worktree, exposed branch_carries_issue_marker - Committed 3edeba4d7f2ae320fb46f76b0e848c952b3cd9ce and pushed the branch - Opened PR #754 What is blocked: - Blocker classification: no blocker Who/what acts next: - Next actor: reviewer - Required action: perform a fresh independent native review of PR #754 at head 3edeba4d7f2ae320fb46f76b0e848c952b3cd9ce - Do not do: reuse this author session, and do not alter PR #750 or PR #746 - Resume from: PR #754 diff and the acceptance criteria in this issue ## Canonical Issue State STATE: Issue #753 is open with an implementation pushed and PR #754 opened against master at head 3edeba4d7f2ae320fb46f76b0e848c952b3cd9ce. No review verdict exists. WHO_IS_NEXT: reviewer NEXT_ACTION: Perform a fresh independent native review of PR #754 pinned at head 3edeba4d7f2ae320fb46f76b0e848c952b3cd9ce, checking each acceptance criterion AC1 through AC7 in this issue against the diff. NEXT_PROMPT: ```text Review PR #754 in Scaled-Tech-Consulting/Gitea-Tools on remote prgs as an independent reviewer in a fresh session bound to prgs-reviewer. Pin head 3edeba4d7f2ae320fb46f76b0e848c952b3cd9ce. Verify AC1 through AC7 of issue #753: that dead-session recovery requires exact agreement on remote, org, repo, issue, author identity and profile, locked branch with the worktree occupying it, registered worktree path, clean worktree, local head matching remote head and open PR head, a demonstrably dead recorded PID, absence of competing live locks or leases, and absence of ambiguous branch claims; that the waiver suppresses only the base-branch match requirement and never cleanliness; that brand-new issue claims retain the full requirement; that a refused assessment withholds the waiver rather than raising, so the pre-existing guard still fails closed; and that recovery provenance is recorded without secrets. Do not alter PR #750 or PR #746. ``` WHAT_HAPPENED: The author session verified the defect against the live durable lock for issue #749: the lock matched issue #749, branch fix/issue-749-create-issue-bootstrap, and the registered worktree branches/issue-749-create-issue-bootstrap, with a clean worktree and local head, remote head and PR #750 head all e349839fd739e10af2df9c0f429ac487e8ca8b9d, while recorded pid 48545 was dead and the lease still had roughly 55 minutes remaining. Issue #753 was then created, its lock acquired on a fresh worktree at master, the recovery assessor implemented with regression tests, and PR #754 opened. WHY: A durable author lock records the owning MCP session PID. When that process exits the lock is classified stale even inside its lease TTL, so ownership checks fail closed, and re-locking is unreachable because the worktree gate requires the branch to match its base while any branch carrying work is ahead of its base. This change supplies a native recovery path gated on exact durable ownership evidence. RELATED_PRS: PR #754 implements this issue. PR #750 and issue #749 supplied the reproduction and were not modified. PR #746 was not modified. BLOCKERS: no blocker VALIDATION: New suite tests/test_issue_753_dead_pid_lock_recovery.py 33 passed. Issue-lock, adoption, store, provenance, registration, duplicate-gate, worktree and create-issue-guard suites 120 passed. MCP server, commit payloads, handoff ledger, PR ownership and branch cleanup suites 286 passed. Full suite 3498 passed, 6 skipped, 2 failed. The 2 failures are test_issue_702_review_findings_f1_f6.py::TestF1RecoveryBeforeTerminalProbe::test_removed_worktree_recovers_before_probe and test_reconciler_supersession_close.py::TestReconcilerSupersessionMcpTool::test_tool_posts_comment_and_closes_superseded_pr_issue, both reproduced identically in a throwaway detached worktree at pristine master 0425bf9a4325a25b72739fba81604463e3e5e363, so they are pre-existing. git diff --check clean. LAST_UPDATED_BY: author

sysadmin referenced this issue 2026-07-18 19:43:48 -05:00

fix(mcp): allow author-lock recovery after the owning session exits (Closes #753) #754

sysadmin referenced this issue 2026-07-18 19:48:04 -05:00

fix(mcp): allow author-lock recovery after the owning session exits (Closes #753) #754

sysadmin referenced this issue 2026-07-18 19:48:11 -05:00

fix(mcp): allow author-lock recovery after the owning session exits (Closes #753) #754

sysadmin referenced this issue 2026-07-18 20:03:16 -05:00

fix(mcp): allow author-lock recovery after the owning session exits (Closes #753) #754

sysadmin closed this issue 2026-07-18 20:03:27 -05:00

sysadmin referenced this issue from a commit 2026-07-18 20:03:31 -05:00

Merge pull request 'fix(mcp): allow author-lock recovery after the owning session exits (Closes #753)' (#754) from fix/issue-753-dead-pid-author-lock-recovery into master

jcwalker3 referenced this issue 2026-07-18 20:31:36 -05:00

Allow dead-session lock recovery when the issue already has its owning open PR #755

jcwalker3 referenced this issue from a commit 2026-07-18 20:49:22 -05:00

fix(mcp): let a sanctioned recovery keep its own owning PR (Closes #755)

jcwalker3 referenced this issue 2026-07-18 20:51:23 -05:00

fix(mcp): let a sanctioned recovery keep its own owning PR (Closes #755) #756

jcwalker3 referenced this issue 2026-07-18 20:54:43 -05:00

fix(mcp): let a sanctioned recovery keep its own owning PR (Closes #755) #756

sysadmin referenced this issue 2026-07-18 21:01:04 -05:00

fix(mcp): let a sanctioned recovery keep its own owning PR (Closes #755) #756

jcwalker3 referenced this issue 2026-07-18 21:22:34 -05:00

fix(mcp): allow create_issue from clean control checkout (Closes #749) #750

sysadmin referenced this issue 2026-07-18 21:31:17 -05:00

fix(mcp): allow create_issue from clean control checkout (Closes #749) #750

jcwalker3 referenced this issue 2026-07-18 21:51:59 -05:00

fix(mcp): bind post-merge moot-lease cleanup to the reconciler capability (Closes #745) #746

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

master

fix/issue-757-create-issue-bootstrap-anti-stomp

fix/issue-745-reconciler-moot-lease-gate

fix/issue-749-create-issue-bootstrap

fix/issue-755-owning-pr-recovery

fix/issue-753-dead-pid-author-lock-recovery

fix/issue-751-checks-assessor

feat/issue-747-sliding-lease-ttl

fix/issue-741-canonical-root-consumers

fix/issue-742-merger-lease-provenance

feat/issue-739-canonical-root-consumption

feat/issue-706-canonical-repository-root

fix/issue-735-author-org-repo-forwarding

fix/issue-733-delete-branch-repo-forwarding

feat/issue-609-prepared-review-verdict-resume

fix/issue-702-stale-binding-lease-recovery

issue-723-role-poisoning

fix/issue-723-capability-role-invariants

fix/issue-720-expired-decision-lock

docs/mcp-stable-control-runtime-policy

feat/issue-687-reconciler-branch-delete

fix/issue-709-decision-lock-cross-profile

fix/issue-695-native-transport-quarantine

fix/issue-698-report-validator-schema

fix/issue-699-structured-auth-mcp-errors

fix/issue-695-native-quarantine-v2

fix/issue-691-obsolete-reviewer-lease-cleanup

fix/issue-683-workflow-guard-hardening

chore/issue-681-preserve-review-session-wip

fix/issue-671-block-stable-branch-push

fix/issue-675-residual-preflight-remediation

fix/issue-673-remediate-regressions-part2

fix/issue-673-remediate-regressions

feat/issue-603-lifecycle-labels

fix/issue-627-set-issue-labels-pagination

feat/issue-601-first-class-leases

feat/issue-612-incident-bridge

feat/issue-600-controller-allocator-api

fix/issue-620-head-scoped-review-locks

feat/issue-613-allocator-db-substrate

feat/issue-610-live-remote-parity

feat/issue-503-reviewer-active-worktree

feat/issue-470-preflight-contract

feat/issue-440-lock-recovery

feat/issue-440-branch-recovery

feat/issue-458-queue-fail-closed-copy

feat/issue-400-early-duplicate-work-gate

feat/issue-308-reconcile-inventory-pagination

feat/issue-308-reconcile-pagination-proof

docs/issue-261-agent-temp-artifact-cleanup

feat/issue-262-map-commit-files

fix/infra-stop-conflict-marker-false-positive

feat/issue-139-role-aware-task-routing

feat/issue-188-continuation-selection-wall

feat/issue-189-continuation-mode-proofs

feat/issue-232-refresh-wiki-proof-heads

feat/issue-210-block-workspace-edits

feat/issue-204-exact-issue-lock

docs/issue-80-label-taxonomy

docs/issue-79-safety-boundary-updates

v1.1.0

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

No labels mcp recovery reliability safety status:pr-open type:bug workflow-hardening

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

jcwalker3 sysadmin

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

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