Scaled-Tech-Consulting/Gitea-Tools
2
0
Fork 0
Code Issues 73 Pull Requests 9 Actions Packages Projects Releases Wiki Activity

MCP servers report Connected but tool namespaces are not attached to the active session #708

New Issue
Open
opened 2026-07-13 21:18:46 -05:00 by jcwalker3 · 1 comment
jcwalker3 commented 2026-07-13 21:18:46 -05:00
Owner
Copy Link
Copy Source

Problem

Gitea MCP servers can report Connected at the CLI / host inventory layer while the active LLM session exposes none of their tool namespaces. Native workflow tools are therefore unavailable until an interactive /mcp reconnect attaches the namespaces to the session.

This is a session-attachment failure, not a missing config entry, not a transport-closed error, and not a stale-runtime self-kill path. The host believes the servers are healthy; the agent session still cannot call gitea-author / gitea-merger / gitea-reviewer / gitea-reconciler / gitea-tools until the operator performs a manual reconnect.

Failure signature

Layer Observed
CLI / host MCP status Servers report Connected
Active LLM session tool surface No Gitea role tool namespaces exposed
Recovery that works today Interactive /mcp reconnect (operator babysitting)
Native workflows during failure Fail closed; cannot proceed without human reconnect

Distinction from related issues

This issue is not a duplicate of the following; keep them separate:

Issue What it covers Why this is different
#672 Active Antigravity IDE MCP config missing Gitea role server entries (config drift vs global) Here servers are present and report Connected; the gap is session namespace attachment, not missing config entries
#678 Codex cannot invoke a sanctioned reconnect tool when stale/closed is already detected Here the false-healthy Connected state hides the need for reconnect; attachment lifecycle is the defect, not only missing reconnect exposure
#685 gitea_resolve_task_capability stale path touches config + os._exit, causing client EOF Here there is no required transport death from the resolver; Connected stays green while namespaces never attach
#584 Namespaces fail with Transport closed; recovery via host auto-reconnect at session startup Here transport is reported Connected, not closed; namespaces still absent from the active session until interactive reconnect

Do not collapse this into config-drift, reconnect-exposure, resolver side-effects, or transport-closed trackers without explicit operator approval and evidence that the root causes are identical.

Impact

  • Native workflows fail closed even when operators and status UIs show healthy Connected servers.
  • Agents and controllers must babysit sessions: stop work, ask for /mcp reconnect, re-run identity/capability preflight.
  • Creates false confidence (Connected ≠ tools available) and misdiagnosis as stale-runtime, missing config, or auth failure.
  • Blocks AUTHOR / REVIEWER / MERGER / RECONCILER work that is required to be native-MCP-only.
  • Encourages unsafe improvisation if not hard-stopped (see workflow-safety below).

Recurrence evidence (blocked PR #696 merger session)

PR #696 (feat(guard): native MCP transport binding and contaminated-review quarantine (Closes #695)) is linked only as the observed blocked task, not as the implementation target of this issue.

During a merger session targeting merged PR #696:

  • Gitea MCP servers were reported Connected at the CLI layer.
  • The active LLM session exposed none of the Gitea role tool namespaces.
  • Merger work could not proceed via native MCP until an interactive /mcp reconnect.
  • After reconnect, namespaces became available; the blockage was attachment, not missing server definitions or permanent transport death.

PR #696 itself implements #695 (native transport binding / contaminated-review quarantine) and is merged. This issue tracks the session attachment / discovery defect that blocked that merger workflow class — it does not reopen #695 or re-implement #696.

Investigation requirements

Investigate and document (with tests where possible) the full client attachment lifecycle:

  1. Client attachment lifecycle

    • When does the host mark a server Connected?
    • When are tool schemas / namespaces bound into the active LLM session tool list?
    • Is Connected computed independently of session-local namespace registration?

  2. Startup ordering

    • Race: session tool snapshot taken before MCP servers finish initialize/list_tools?
    • Parallel connect of multiple role servers (gitea-author, gitea-merger, …) leaving session with empty namespaces while later Connected flips true?

  3. Discovery cache

    • Stale empty tool list cached after partial connect?
    • Does Connected status refresh without invalidating the session tool cache?
    • Does only interactive /mcp reconnect force rediscovery?

  4. Reconnect behavior

    • What does interactive /mcp reconnect change that automatic session start does not?
    • Can the client auto-attach when Connected ∧ namespaces empty?
    • Typed blocker vs silent empty tool surface?

Candidate code/docs surfaces (non-exhaustive): mcp_namespace_health.py, mcp_discoverability.py, mcp_session_state.py, mcp_daemon_guard.py, test_mcp_conn.py, docs/mcp-namespace-health.md, client integration notes for Antigravity/Codex/Grok CLI.

Acceptance criteria

  1. Distinct detection — Connected-but-namespaces-missing is detected and reported as its own typed condition (not config-drift #672, not transport-closed #584, not resolver EOF #685), with namespace names and proof of Connected vs attached tool surface.
  2. Automatic attachment or recovery — When servers are Connected but session namespaces are empty, the client/runtime either auto-attaches namespaces or returns a typed exact_next_action that is only the sanctioned reconnect path (no shell/process/config hacks). Prefer automatic attachment when safe.
  3. Canonical guidance — Docs and workflow skills state: Connected ≠ tools available; required preflight proof is live tool visibility + gitea_whoami (or equivalent) on the required role namespace, not CLI Connected alone.
  4. Regression coverage — Tests (or harness) cover: Connected with empty session tool list; successful attach; reconnect rediscovery; multi-role server startup ordering; no false healthy final report without namespace attachment proof.
  5. Telemetry — Emit structured signals: server Connected status, session-attached namespaces, discovery cache age/hit, reconnect required vs auto-recovered, without leaking secrets.
  6. No unsafe fallback — Failure must never route work through direct imports, CLI API mutation, profile hopping, or session-state overrides.

Workflow-safety requirement

When this failure is detected, workflows must fail closed and must never encourage or perform:

  • direct imports of MCP server modules / offline helpers
  • CLI or raw Gitea API mutation as a substitute for native tools
  • profile hopping to another MCP profile/namespace to bypass the empty session
  • session-state overrides or hand-edited session/ledger files to fake capability
  • pkill / process kill, touch/mtime config tricks, .env edits, or manual daemon launches

Only sanctioned recovery: client attach/reconnect path, then full preflight (whoami → capability resolve → task).

Related hard stops: #630 (no process-kill recovery), #695/#696 (no offline import after native transport failure), #678 (sanctioned reconnect exposure for clients that lack it).

Linkage

Link Role
PR #696 Observed blocked merger task (recurrence evidence only); not the implementation of this issue
#695 Related native-transport / no-offline-import policy; distinct defect
#672 Config missing role servers — related misdiagnosis risk
#678 Sanctioned reconnect tool exposure — complementary recovery surface
#685 Resolver side-effect EOF — distinct
#584 Transport closed — distinct
#630 / #655 / #669 Forbidden kill recovery; governed restart / scoped recovery

Explicit non-goals

  • Do not re-implement or reopen PR #696 / issue #695 as this ticket.
  • Do not treat full MCP process restart as the primary fix.
  • Do not auto-overwrite user MCP config without an explicit drift/repair path (#672).
  • Do not weaken fail-closed native-MCP-only workflow policy.

Required implementation

  1. Preflight: gitea_whoami + gitea_resolve_task_capability on prgs-author (or the role implementing the fix); bind issue-backed worktree under branches/ only.
  2. Implement distinct detection for Connected ∧ session-namespaces-empty.
  3. Implement automatic session attachment or typed blocker with sanctioned reconnect-only exact_next_action.
  4. Add regression tests for discovery/attachment/reconnect and multi-role ordering.
  5. Add telemetry fields (Connected vs attached namespaces; cache/reconnect outcomes).
  6. Update canonical docs/workflow guidance; forbid unsafe fallbacks in error text and skills.
  7. Open PR with Closes this issue; stop; hand off to independent reviewer. Do not implement from root checkout; do not merge from author role.

Required final response and handoff

Author final response must include:

  • Issue number and PR number
  • Proof of detection path (sample structured report: Connected vs attached namespaces)
  • Test evidence for AC regression cases
  • Explicit statement that recovery path does not use direct import, CLI API mutation, profile hopping, or session-state overrides
  • Handoff: WHO_IS_NEXT: reviewer with PR URL/number and request for independent review
STATE: ready-for-author
WHO_IS_NEXT: author
NEXT_ACTION: Investigate client attachment lifecycle + implement distinct detection, auto-attach or sanctioned reconnect recovery, tests, telemetry, and docs
NEXT_PROMPT:
Role: AUTHOR
Repo: prgs / Scaled-Tech-Consulting / Gitea-Tools
Issue: this issue

1. Native MCP only; whoami + resolve_task_capability on prgs-author; issue-backed worktree under branches/.
2. Implement Connected-but-namespaces-missing detection and recovery per AC; never unsafe fallbacks.
3. PR with Closes; stop; hand off to independent reviewer.
## Problem Gitea MCP servers can report **Connected** at the CLI / host inventory layer while the **active LLM session exposes none of their tool namespaces**. Native workflow tools are therefore unavailable until an **interactive** `/mcp` reconnect attaches the namespaces to the session. This is a **session-attachment** failure, not a missing config entry, not a transport-closed error, and not a stale-runtime self-kill path. The host believes the servers are healthy; the agent session still cannot call `gitea-author` / `gitea-merger` / `gitea-reviewer` / `gitea-reconciler` / `gitea-tools` until the operator performs a manual reconnect. ### Failure signature | Layer | Observed | |---|---| | CLI / host MCP status | Servers report **Connected** | | Active LLM session tool surface | **No** Gitea role tool namespaces exposed | | Recovery that works today | Interactive `/mcp` reconnect (operator babysitting) | | Native workflows during failure | Fail closed; cannot proceed without human reconnect | ## Distinction from related issues This issue is **not** a duplicate of the following; keep them separate: | Issue | What it covers | Why this is different | |---|---|---| | **#672** | Active Antigravity IDE MCP **config missing** Gitea role server entries (config drift vs global) | Here servers **are** present and report Connected; the gap is **session namespace attachment**, not missing config entries | | **#678** | Codex cannot **invoke** a sanctioned reconnect tool when stale/closed is already detected | Here the false-healthy Connected state hides the need for reconnect; attachment lifecycle is the defect, not only missing reconnect exposure | | **#685** | `gitea_resolve_task_capability` stale path **touches config + `os._exit`**, causing client EOF | Here there is no required transport death from the resolver; Connected stays green while namespaces never attach | | **#584** | Namespaces fail with **Transport closed**; recovery via host auto-reconnect at session startup | Here transport is reported Connected, not closed; namespaces still absent from the active session until interactive reconnect | Do not collapse this into config-drift, reconnect-exposure, resolver side-effects, or transport-closed trackers without explicit operator approval and evidence that the root causes are identical. ## Impact * **Native workflows fail closed** even when operators and status UIs show healthy Connected servers. * Agents and controllers must **babysit** sessions: stop work, ask for `/mcp` reconnect, re-run identity/capability preflight. * Creates false confidence (Connected ≠ tools available) and misdiagnosis as stale-runtime, missing config, or auth failure. * Blocks AUTHOR / REVIEWER / MERGER / RECONCILER work that is required to be native-MCP-only. * Encourages unsafe improvisation if not hard-stopped (see workflow-safety below). ## Recurrence evidence (blocked PR #696 merger session) **PR #696** (`feat(guard): native MCP transport binding and contaminated-review quarantine (Closes #695)`) is linked **only as the observed blocked task**, not as the implementation target of this issue. During a **merger** session targeting merged PR **#696**: * Gitea MCP servers were reported **Connected** at the CLI layer. * The active LLM session exposed **none** of the Gitea role tool namespaces. * Merger work could not proceed via native MCP until an interactive `/mcp` reconnect. * After reconnect, namespaces became available; the blockage was attachment, not missing server definitions or permanent transport death. PR #696 itself implements #695 (native transport binding / contaminated-review quarantine) and is **merged**. This issue tracks the **session attachment / discovery** defect that blocked that merger workflow class — it does **not** reopen #695 or re-implement #696. ## Investigation requirements Investigate and document (with tests where possible) the full client attachment lifecycle: 1. **Client attachment lifecycle** * When does the host mark a server Connected? * When are tool schemas / namespaces bound into the **active** LLM session tool list? * Is Connected computed independently of session-local namespace registration? 2. **Startup ordering** * Race: session tool snapshot taken before MCP servers finish initialize/list_tools? * Parallel connect of multiple role servers (`gitea-author`, `gitea-merger`, …) leaving session with empty namespaces while later Connected flips true? 3. **Discovery cache** * Stale empty tool list cached after partial connect? * Does Connected status refresh without invalidating the session tool cache? * Does only interactive `/mcp` reconnect force rediscovery? 4. **Reconnect behavior** * What does interactive `/mcp` reconnect change that automatic session start does not? * Can the client auto-attach when Connected ∧ namespaces empty? * Typed blocker vs silent empty tool surface? Candidate code/docs surfaces (non-exhaustive): `mcp_namespace_health.py`, `mcp_discoverability.py`, `mcp_session_state.py`, `mcp_daemon_guard.py`, `test_mcp_conn.py`, `docs/mcp-namespace-health.md`, client integration notes for Antigravity/Codex/Grok CLI. ## Acceptance criteria 1. **Distinct detection** — Connected-but-namespaces-missing is detected and reported as its own typed condition (not config-drift #672, not transport-closed #584, not resolver EOF #685), with namespace names and proof of Connected vs attached tool surface. 2. **Automatic attachment or recovery** — When servers are Connected but session namespaces are empty, the client/runtime either auto-attaches namespaces or returns a typed `exact_next_action` that is **only** the sanctioned reconnect path (no shell/process/config hacks). Prefer automatic attachment when safe. 3. **Canonical guidance** — Docs and workflow skills state: Connected ≠ tools available; required preflight proof is live tool visibility + `gitea_whoami` (or equivalent) on the required role namespace, not CLI Connected alone. 4. **Regression coverage** — Tests (or harness) cover: Connected with empty session tool list; successful attach; reconnect rediscovery; multi-role server startup ordering; no false healthy final report without namespace attachment proof. 5. **Telemetry** — Emit structured signals: server Connected status, session-attached namespaces, discovery cache age/hit, reconnect required vs auto-recovered, without leaking secrets. 6. **No unsafe fallback** — Failure must never route work through direct imports, CLI API mutation, profile hopping, or session-state overrides. ## Workflow-safety requirement When this failure is detected, workflows **must fail closed** and **must never** encourage or perform: * direct imports of MCP server modules / offline helpers * CLI or raw Gitea **API mutation** as a substitute for native tools * **profile hopping** to another MCP profile/namespace to bypass the empty session * **session-state overrides** or hand-edited session/ledger files to fake capability * `pkill` / process kill, `touch`/mtime config tricks, `.env` edits, or manual daemon launches Only sanctioned recovery: client attach/reconnect path, then full preflight (`whoami` → capability resolve → task). Related hard stops: #630 (no process-kill recovery), #695/#696 (no offline import after native transport failure), #678 (sanctioned reconnect exposure for clients that lack it). ## Linkage | Link | Role | |---|---| | **PR #696** | Observed **blocked merger task** (recurrence evidence only); **not** the implementation of this issue | | #695 | Related native-transport / no-offline-import policy; distinct defect | | #672 | Config missing role servers — related misdiagnosis risk | | #678 | Sanctioned reconnect tool exposure — complementary recovery surface | | #685 | Resolver side-effect EOF — distinct | | #584 | Transport closed — distinct | | #630 / #655 / #669 | Forbidden kill recovery; governed restart / scoped recovery | ## Explicit non-goals * Do not re-implement or reopen PR #696 / issue #695 as this ticket. * Do not treat full MCP process restart as the primary fix. * Do not auto-overwrite user MCP config without an explicit drift/repair path (#672). * Do not weaken fail-closed native-MCP-only workflow policy. ## Required implementation 1. Preflight: `gitea_whoami` + `gitea_resolve_task_capability` on `prgs-author` (or the role implementing the fix); bind issue-backed worktree under `branches/` only. 2. Implement distinct detection for Connected ∧ session-namespaces-empty. 3. Implement automatic session attachment **or** typed blocker with sanctioned reconnect-only `exact_next_action`. 4. Add regression tests for discovery/attachment/reconnect and multi-role ordering. 5. Add telemetry fields (Connected vs attached namespaces; cache/reconnect outcomes). 6. Update canonical docs/workflow guidance; forbid unsafe fallbacks in error text and skills. 7. Open PR with `Closes` this issue; stop; hand off to independent reviewer. **Do not** implement from root checkout; **do not** merge from author role. ## Required final response and handoff Author final response must include: * Issue number and PR number * Proof of detection path (sample structured report: Connected vs attached namespaces) * Test evidence for AC regression cases * Explicit statement that recovery path does **not** use direct import, CLI API mutation, profile hopping, or session-state overrides * Handoff: **WHO_IS_NEXT: reviewer** with PR URL/number and request for independent review ```text STATE: ready-for-author WHO_IS_NEXT: author NEXT_ACTION: Investigate client attachment lifecycle + implement distinct detection, auto-attach or sanctioned reconnect recovery, tests, telemetry, and docs NEXT_PROMPT: Role: AUTHOR Repo: prgs / Scaled-Tech-Consulting / Gitea-Tools Issue: this issue 1. Native MCP only; whoami + resolve_task_capability on prgs-author; issue-backed worktree under branches/. 2. Implement Connected-but-namespaces-missing detection and recovery per AC; never unsafe fallbacks. 3. PR with Closes; stop; hand off to independent reviewer. ```
jcwalker3 added the status:readyworkflow-hardeningmcp-healthstale-runtimetype:bug labels 2026-07-13 21:18:46 -05:00
sysadmin commented 2026-07-13 21:33:53 -05:00
Owner
Copy Link
Copy Source

[THREAD STATE LEDGER] Issue #708 — quarantine-tool rediscovery outcome and containment of reviews 427/431

What is true now:

  • Server-side decision state: server-side state changed — durable quarantine records now exist for review 427 (PR #694, audit comment 11465) and review 431 (PR #701, audit comment 11467), each with merge_authorization=void and forensic evidence retained.
  • Local verdict/state: prgs-reconciler session (identity sysadmin) on the native production MCP transport — pid 69262, token fingerprint fdc08554e469c8b6, transport stdio, mode production, session_state_dir pinned to ~/.cache/gitea-tools/session-state, direct_import_env unset. Master parity healthy: startup_head == current_head == 1eafb757a9.
  • Latest known validation: post-quarantine readback on both PRs shows quarantined=true on the target reviews, approval_visible=false, approval-at-current-head false, no valid approving head recorded, quarantined_approvals_at_current_head=1 each; the forensic review objects remain fully visible with their original verdict text.

What changed:

  • gitea_quarantine_contaminated_review attached to client discovery this session: client-side tool rediscovery after the /mcp reconnect returned the live schema, and direct native invocation succeeded twice. No additional server restart or further rediscovery cycle was required.
  • This resolves the earlier post-restart recurrence where server parity was healthy at 1eafb757, production native transport was true, and the tool was decorated in server code, yet the tool was absent from client discovery and direct native invocation failed.
  • Key distinction confirmed: server runtime parity (daemon code vs prgs/master) and client tool attachment (the tool list a client session holds) are independent health axes. Parity green does not imply the client's tool list is current; the recovery lever for a missing tool is client-side rediscovery/reconnect, not a server restart.
  • Review 427 (reviewer sysadmin, reviewed head 1844e29880) quarantined natively with the schema-required confirmation string; audit comment 11465.
  • Review 431 (reviewer sysadmin, reviewed head 6b675f5c83) quarantined natively with the schema-required confirmation string; audit comment 11467.

What is blocked:

  • Blocker classification: no blocker

Who/what acts next:

  • Next actor: reviewer
  • Required action: fresh leased native reviewer session for PR #703 against issue #702 AC2/AC3; separately PR #701 remains in open state and requires its own fresh native review — quarantined review 431 does not authorize merge.
  • Do not do: do not merge PR #694 or PR #701 on the strength of reviews 427/431; do not clean lease 11392 (last native assessment returned cleanup_allowed=false, mutation_eligibility=prohibited); do not set controller_recovery_authorized; do not touch PR #611, forensic files, or session-state directories.

Canonical Issue State

STATE:
containment-complete

WHO_IS_NEXT:
reviewer

NEXT_ACTION:
Fresh leased native reviewer session reviews PR #703 at its live head against issue #702 AC2/AC3. PR #701 requires a separate fresh native review before any merge consideration.

NEXT_PROMPT:

Acquire a fresh reviewer lease via the native prgs-reviewer namespace and review PR #703 at its live head against issue #702 AC2/AC3. Do not adopt any prior verdicts. Do not touch PR #701's reviews; review 431 is quarantined and void for merge authorization. Do not clean lease 11392.

WHAT_HAPPENED:
Post-restart recurrence check on Issue #708: gitea_quarantine_contaminated_review attached to client discovery after reconnect plus client-side tool rediscovery; no further restart was needed. Reviews 427 (PR #694) and 431 (PR #701) were then quarantined through the native production transport, and readback proves both APPROVE verdicts are void for merge authorization while forensic evidence is retained.

WHY:
Both reviews were produced by non-native execution paths documented in issue #695 (offline-runner bypass for 427; run_submit.py direct-import with redirected .mcp_session_701 session-state directory for 431). Per #695 AC8 such verdicts are void and require durable quarantine records that the feedback, eligibility, and merge gates honor by review_id.

RELATED_PRS:
PR #694 (open state, review 427 quarantined), PR #701 (open state, unreviewed for merge purposes, review 431 quarantined), PR #703 (awaiting fresh reviewer).

BLOCKERS:
None for this containment task. Lease 11392 intentionally untouched per its last native assessment (cleanup_allowed=false, mutation_eligibility=prohibited).

VALIDATION:
gitea_get_pr_review_feedback readback on PR #694 and PR #701: quarantined=true on reviews 427/431, approval_visible=false, quarantined_approvals_at_current_head=1 each, stale-approval reason states the contaminated approval is void for merge authorization; gitea_check_pr_eligibility(PR #701, merge) returned eligible=false.

LAST_UPDATED_BY:
prgs-reconciler (sysadmin), native runtime at 1eafb757a9, server clock 2026-07-14T02:32Z.

[THREAD STATE LEDGER] Issue #708 — quarantine-tool rediscovery outcome and containment of reviews 427/431 What is true now: - Server-side decision state: server-side state changed — durable quarantine records now exist for review 427 (PR #694, audit comment 11465) and review 431 (PR #701, audit comment 11467), each with merge_authorization=void and forensic evidence retained. - Local verdict/state: prgs-reconciler session (identity sysadmin) on the native production MCP transport — pid 69262, token fingerprint fdc08554e469c8b6, transport stdio, mode production, session_state_dir pinned to ~/.cache/gitea-tools/session-state, direct_import_env unset. Master parity healthy: startup_head == current_head == 1eafb757a91e4606ed9f82413e4122ad6bcf94fd. - Latest known validation: post-quarantine readback on both PRs shows quarantined=true on the target reviews, approval_visible=false, approval-at-current-head false, no valid approving head recorded, quarantined_approvals_at_current_head=1 each; the forensic review objects remain fully visible with their original verdict text. What changed: - gitea_quarantine_contaminated_review attached to client discovery this session: client-side tool rediscovery after the /mcp reconnect returned the live schema, and direct native invocation succeeded twice. No additional server restart or further rediscovery cycle was required. - This resolves the earlier post-restart recurrence where server parity was healthy at 1eafb757, production native transport was true, and the tool was decorated in server code, yet the tool was absent from client discovery and direct native invocation failed. - Key distinction confirmed: server runtime parity (daemon code vs prgs/master) and client tool attachment (the tool list a client session holds) are independent health axes. Parity green does not imply the client's tool list is current; the recovery lever for a missing tool is client-side rediscovery/reconnect, not a server restart. - Review 427 (reviewer sysadmin, reviewed head 1844e298809373be19a526fd39b7d8b0669eb5bd) quarantined natively with the schema-required confirmation string; audit comment 11465. - Review 431 (reviewer sysadmin, reviewed head 6b675f5c834b41f9d74e8a54294ff44dddf28ae4) quarantined natively with the schema-required confirmation string; audit comment 11467. What is blocked: - Blocker classification: no blocker Who/what acts next: - Next actor: reviewer - Required action: fresh leased native reviewer session for PR #703 against issue #702 AC2/AC3; separately PR #701 remains in open state and requires its own fresh native review — quarantined review 431 does not authorize merge. - Do not do: do not merge PR #694 or PR #701 on the strength of reviews 427/431; do not clean lease 11392 (last native assessment returned cleanup_allowed=false, mutation_eligibility=prohibited); do not set controller_recovery_authorized; do not touch PR #611, forensic files, or session-state directories. ## Canonical Issue State STATE: containment-complete WHO_IS_NEXT: reviewer NEXT_ACTION: Fresh leased native reviewer session reviews PR #703 at its live head against issue #702 AC2/AC3. PR #701 requires a separate fresh native review before any merge consideration. NEXT_PROMPT: ```text Acquire a fresh reviewer lease via the native prgs-reviewer namespace and review PR #703 at its live head against issue #702 AC2/AC3. Do not adopt any prior verdicts. Do not touch PR #701's reviews; review 431 is quarantined and void for merge authorization. Do not clean lease 11392. ``` WHAT_HAPPENED: Post-restart recurrence check on Issue #708: gitea_quarantine_contaminated_review attached to client discovery after reconnect plus client-side tool rediscovery; no further restart was needed. Reviews 427 (PR #694) and 431 (PR #701) were then quarantined through the native production transport, and readback proves both APPROVE verdicts are void for merge authorization while forensic evidence is retained. WHY: Both reviews were produced by non-native execution paths documented in issue #695 (offline-runner bypass for 427; run_submit.py direct-import with redirected .mcp_session_701 session-state directory for 431). Per #695 AC8 such verdicts are void and require durable quarantine records that the feedback, eligibility, and merge gates honor by review_id. RELATED_PRS: PR #694 (open state, review 427 quarantined), PR #701 (open state, unreviewed for merge purposes, review 431 quarantined), PR #703 (awaiting fresh reviewer). BLOCKERS: None for this containment task. Lease 11392 intentionally untouched per its last native assessment (cleanup_allowed=false, mutation_eligibility=prohibited). VALIDATION: gitea_get_pr_review_feedback readback on PR #694 and PR #701: quarantined=true on reviews 427/431, approval_visible=false, quarantined_approvals_at_current_head=1 each, stale-approval reason states the contaminated approval is void for merge authorization; gitea_check_pr_eligibility(PR #701, merge) returned eligible=false. LAST_UPDATED_BY: prgs-reconciler (sysadmin), native runtime at 1eafb757a91e, server clock 2026-07-14T02:32Z.
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
No Label mcp-health stale-runtime status:ready type:bug workflow-hardening
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
jcwalker3 sysadmin
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Scaled-Tech-Consulting/Gitea-Tools#708
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?