Blocked reviewer workflows must stop cleanly on infra_stop and produce repair handoff #289

New Issue

2026-07-06T23:24:01-05:00

jcwalker3 commented

2026-07-06 23:24:01 -05:00

Reviewer workflows currently continue too far after MCP capability resolution fails with infra_stop: true.

Observed behavior:

LLM ran gitea_whoami
LLM ran gitea_resolve_task_capability
Capability check failed for review_pr due to infra_stop: true
LLM continued running broad diagnostics
LLM used schedule / manage_task
LLM waited for background tasks
LLM selected PR #276 as next PR to review
LLM pinned a PR head SHA even though review capability never cleared
No review mutation was submitted, which was correct

Problem:

Once infra_stop: true blocks capability for PR review, the workflow must stop PR queue work immediately. The LLM may enter explicit control-checkout repair mode only for MCP/runtime diagnostics, but it must not continue PR selection, queue advancement, validation, review, or merge planning.

Required behavior:

If gitea_resolve_task_capability returns blocked due to infra_stop, PR review/merge workflow must stop immediately.
The LLM must not select or advance to a next PR while capability is blocked.
The LLM must not claim a PR is eligible or next in queue without a complete live paginated PR inventory.
Any main-checkout diagnostics must be explicitly labeled CONTROL-CHECKOUT REPAIR MODE.
Control-checkout repair mode must not perform PR review work.
Background scheduling tools such as schedule / manage_task must not be used to work around blocked MCP gates.
The final response must be a repair handoff, not a PR review report.

Infra_stop diagnostic requirements:

When infra_stop blocks a capability, MCP must report:

MCP process root
active task workspace root, if any
inspected git root
exact conflict marker path, if found
exact merge/rebase control path, if found
whether the state is cached or live
MCP process PID/start time if available
safe next repair action

Acceptance criteria:

infra_stop: true prevents PR queue advancement.
No PR is selected as next while capability is blocked.
No review, approval, request-changes, merge, or comment mutation can occur while infra_stop is active.
Main-checkout diagnostics require explicit control-checkout repair mode.
Background scheduling/task tools are not used during blocked gate recovery.
Final output includes an executable repair handoff instead of stale PR review state.

Reviewer workflows currently continue too far after MCP capability resolution fails with `infra_stop: true`. Observed behavior: * LLM ran `gitea_whoami` * LLM ran `gitea_resolve_task_capability` * Capability check failed for `review_pr` due to `infra_stop: true` * LLM continued running broad diagnostics * LLM used `schedule` / `manage_task` * LLM waited for background tasks * LLM selected PR #276 as next PR to review * LLM pinned a PR head SHA even though review capability never cleared * No review mutation was submitted, which was correct Problem: Once `infra_stop: true` blocks capability for PR review, the workflow must stop PR queue work immediately. The LLM may enter explicit control-checkout repair mode only for MCP/runtime diagnostics, but it must not continue PR selection, queue advancement, validation, review, or merge planning. Required behavior: 1. If `gitea_resolve_task_capability` returns blocked due to `infra_stop`, PR review/merge workflow must stop immediately. 2. The LLM must not select or advance to a next PR while capability is blocked. 3. The LLM must not claim a PR is eligible or next in queue without a complete live paginated PR inventory. 4. Any main-checkout diagnostics must be explicitly labeled `CONTROL-CHECKOUT REPAIR MODE`. 5. Control-checkout repair mode must not perform PR review work. 6. Background scheduling tools such as `schedule` / `manage_task` must not be used to work around blocked MCP gates. 7. The final response must be a repair handoff, not a PR review report. Infra_stop diagnostic requirements: When `infra_stop` blocks a capability, MCP must report: * MCP process root * active task workspace root, if any * inspected git root * exact conflict marker path, if found * exact merge/rebase control path, if found * whether the state is cached or live * MCP process PID/start time if available * safe next repair action Acceptance criteria: * `infra_stop: true` prevents PR queue advancement. * No PR is selected as next while capability is blocked. * No review, approval, request-changes, merge, or comment mutation can occur while `infra_stop` is active. * Main-checkout diagnostics require explicit control-checkout repair mode. * Background scheduling/task tools are not used during blocked gate recovery. * Final output includes an executable repair handoff instead of stale PR review state.

jcwalker3 commented

2026-07-06 23:24:34 -05:00

Body correction: the issue creation transport corrupted the smart quote characters in the issue body. The durable issue should be read with this exact body:

Reviewer workflows currently continue too far after MCP capability resolution fails with infra_stop: true.

Observed behavior:

LLM ran gitea_whoami
LLM ran gitea_resolve_task_capability
Capability check failed for review_pr due to infra_stop: true
LLM continued running broad diagnostics
LLM used schedule / manage_task
LLM waited for background tasks
LLM selected PR #276 as next PR to review
LLM pinned a PR head SHA even though review capability never cleared
No review mutation was submitted, which was correct

Problem:

Once infra_stop: true blocks capability for PR review, the workflow must stop PR queue work immediately. The LLM may enter explicit control-checkout repair mode only for MCP/runtime diagnostics, but it must not continue PR selection, queue advancement, validation, review, or merge planning.

Required behavior:

If gitea_resolve_task_capability returns blocked due to infra_stop, PR review/merge workflow must stop immediately.
The LLM must not select or advance to a next PR while capability is blocked.
The LLM must not claim a PR is eligible or next in queue without a complete live paginated PR inventory.
Any main-checkout diagnostics must be explicitly labeled CONTROL-CHECKOUT REPAIR MODE.
Control-checkout repair mode must not perform PR review work.
Background scheduling tools such as schedule / manage_task must not be used to work around blocked MCP gates.
The final response must be a repair handoff, not a PR review report.

Infra_stop diagnostic requirements:

When infra_stop blocks a capability, MCP must report:

MCP process root
active task workspace root, if any
inspected git root
exact conflict marker path, if found
exact merge/rebase control path, if found
whether the state is cached or live
MCP process PID/start time if available
safe next repair action

Acceptance criteria:

infra_stop: true prevents PR queue advancement.
No PR is selected as next while capability is blocked.
No review, approval, request-changes, merge, or comment mutation can occur while infra_stop is active.
Main-checkout diagnostics require explicit control-checkout repair mode.
Background scheduling/task tools are not used during blocked gate recovery.
Final output includes an executable repair handoff instead of stale PR review state.

Body correction: the issue creation transport corrupted the smart quote characters in the issue body. The durable issue should be read with this exact body: Reviewer workflows currently continue too far after MCP capability resolution fails with `infra_stop: true`. Observed behavior: * LLM ran `gitea_whoami` * LLM ran `gitea_resolve_task_capability` * Capability check failed for `review_pr` due to `infra_stop: true` * LLM continued running broad diagnostics * LLM used `schedule` / `manage_task` * LLM waited for background tasks * LLM selected PR #276 as next PR to review * LLM pinned a PR head SHA even though review capability never cleared * No review mutation was submitted, which was correct Problem: Once `infra_stop: true` blocks capability for PR review, the workflow must stop PR queue work immediately. The LLM may enter explicit control-checkout repair mode only for MCP/runtime diagnostics, but it must not continue PR selection, queue advancement, validation, review, or merge planning. Required behavior: 1. If `gitea_resolve_task_capability` returns blocked due to `infra_stop`, PR review/merge workflow must stop immediately. 2. The LLM must not select or advance to a next PR while capability is blocked. 3. The LLM must not claim a PR is eligible or next in queue without a complete live paginated PR inventory. 4. Any main-checkout diagnostics must be explicitly labeled `CONTROL-CHECKOUT REPAIR MODE`. 5. Control-checkout repair mode must not perform PR review work. 6. Background scheduling tools such as `schedule` / `manage_task` must not be used to work around blocked MCP gates. 7. The final response must be a repair handoff, not a PR review report. Infra_stop diagnostic requirements: When `infra_stop` blocks a capability, MCP must report: * MCP process root * active task workspace root, if any * inspected git root * exact conflict marker path, if found * exact merge/rebase control path, if found * whether the state is cached or live * MCP process PID/start time if available * safe next repair action Acceptance criteria: * `infra_stop: true` prevents PR queue advancement. * No PR is selected as next while capability is blocked. * No review, approval, request-changes, merge, or comment mutation can occur while `infra_stop` is active. * Main-checkout diagnostics require explicit control-checkout repair mode. * Background scheduling/task tools are not used during blocked gate recovery. * Final output includes an executable repair handoff instead of stale PR review state.

jcwalker3 commented

2026-07-06 23:24:44 -05:00

Superseding correction for quote encoding: wherever the issue body or prior correction comment shows control characters around next phrases, read them as normal double quotes. The intended phrases are:

LLM selected PR #276 as "next PR to review"
The LLM must not select or advance to a "next PR" while capability is blocked.
No PR is selected as "next" while capability is blocked.

All other issue-body text is as created.

Superseding correction for quote encoding: wherever the issue body or prior correction comment shows control characters around next phrases, read them as normal double quotes. The intended phrases are: * LLM selected PR #276 as "next PR to review" * The LLM must not select or advance to a "next PR" while capability is blocked. * No PR is selected as "next" while capability is blocked. All other issue-body text is as created.

jcwalker3 added the status:in-progress label 2026-07-07 04:33:12 -05:00

jcwalker3 referenced this issue from a commit

2026-07-07 04:33:16 -05:00

Add infra-stop repair handoff verifier for blocked reviewers (#289)

jcwalker3 commented

2026-07-07 04:33:22 -05:00