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

Require BLOCKED + DIAGNOSE when LLM cannot perform required workflow step #552

New Issue
Closed
opened 2026-07-08 14:28:25 -05:00 by jcwalker3 · 3 comments
jcwalker3 commented 2026-07-08 14:28:25 -05:00
Owner
Copy Link
Copy Source

Problem

LLM workflow sessions sometimes continue after a required workflow step fails or is unavailable. Examples include missing skills, broken terminal execution, MCP capability deadlocks, wrong profile/session state, missing tool access, dirty or misbound worktrees, unavailable project instructions, failed preflights, or mutation guards blocking the requested operation.

This creates unsafe fallback pressure. Instead of stopping and reporting the real blocker, the LLM may continue with partial context, temp scripts, direct imports, direct API calls, manual workarounds, in-memory session restoration, or undocumented assumptions.

That hides process/tooling defects and causes repeated failures.

Required Default Rule

If an LLM cannot perform a required workflow step, it must immediately enter:

BLOCKED + DIAGNOSE

The LLM must not proceed as if the missing requirement is harmless.

Required Behavior

When a required workflow preflight, skill, tool, capability, worktree binding, identity check, terminal command, mutation guard, or project instruction is unavailable or fails, the LLM must:

  1. Stop before further git or Gitea mutation.
  2. Clearly state BLOCKED.
  3. Diagnose the failure.
  4. Attempt only safe, non-mutating recovery steps.
  5. Report what failed.
  6. Report what was expected.
  7. Report what was checked.
  8. Report what recovery was attempted.
  9. Classify the likely cause:
    • environment/session setup
    • missing skill mount
    • naming mismatch
    • MCP tool/capability defect
    • permission/profile issue
    • dirty or misbound worktree
    • terminal/runtime defect
    • project configuration issue
    • unavailable workflow instruction
  10. Recommend a durable fix.
  11. Recommend or create a follow-up issue only if authorized by role/workflow.
  12. Do not use temp scripts, direct API fallback, MCP internals, direct imports, in-memory state restoration, or manual bypasses unless explicitly authorized by a controller.

Examples of Required BLOCKED + DIAGNOSE Cases

  • Required gitea-workflow skill is unavailable.
  • Codex, Claude, Gemini, or ChatGPT expose different workflow skill names.
  • Terminal command runner is broken.
  • MCP capability resolution fails or resets required lease/session state.
  • Active profile is wrong for the requested role.
  • Runtime workspace binding points to the wrong worktree.
  • Root checkout would be mutated.
  • Dirty files are detected.
  • Runtime dirty-file state disagrees with real git status.
  • Gitea mutation guard blocks because the session is not in an authorized branches/ worktree.
  • Tool schema or required MCP operation is missing.
  • Review, merge, author, or reconciler workflow cannot complete with canonical tools.
  • A required project instruction or checked-in workflow guide cannot be loaded.

Acceptance Criteria

  • Add a canonical workflow rule requiring BLOCKED + DIAGNOSE whenever a required workflow step cannot be completed.
  • Update relevant workflow docs, prompts, templates, and skill guides so LLMs do not continue after missing required skills/tools/capabilities.
  • Add a standard blocker report template with:
    • required step
    • observed failure
    • expected behavior
    • checks performed
    • safe recovery attempted
    • likely classification
    • durable fix recommendation
    • whether mutation occurred
    • single next action
  • Ensure missing workflow skills fail before git or Gitea mutation.
  • Ensure broken terminal/tooling failures are reported as process defects, not silently bypassed.
  • Ensure missing or stale MCP capability state fails closed with diagnosis instead of fallback.
  • Add tests or proof docs showing that missing skill/tool/capability cases stop before mutation.
  • Ensure future controller prompts reinforce this rule.

Suggested Labels

  • workflow
  • guardrail
  • llm-runtime
  • blocked-diagnose
  • process-hardening

Notes

This rule is intended to make process/tooling problems visible and fixable. LLMs should not hide workflow failures by continuing with unsafe or undocumented alternatives.

## Problem LLM workflow sessions sometimes continue after a required workflow step fails or is unavailable. Examples include missing skills, broken terminal execution, MCP capability deadlocks, wrong profile/session state, missing tool access, dirty or misbound worktrees, unavailable project instructions, failed preflights, or mutation guards blocking the requested operation. This creates unsafe fallback pressure. Instead of stopping and reporting the real blocker, the LLM may continue with partial context, temp scripts, direct imports, direct API calls, manual workarounds, in-memory session restoration, or undocumented assumptions. That hides process/tooling defects and causes repeated failures. ## Required Default Rule If an LLM cannot perform a required workflow step, it must immediately enter: `BLOCKED + DIAGNOSE` The LLM must not proceed as if the missing requirement is harmless. ## Required Behavior When a required workflow preflight, skill, tool, capability, worktree binding, identity check, terminal command, mutation guard, or project instruction is unavailable or fails, the LLM must: 1. Stop before further git or Gitea mutation. 2. Clearly state `BLOCKED`. 3. Diagnose the failure. 4. Attempt only safe, non-mutating recovery steps. 5. Report what failed. 6. Report what was expected. 7. Report what was checked. 8. Report what recovery was attempted. 9. Classify the likely cause: - environment/session setup - missing skill mount - naming mismatch - MCP tool/capability defect - permission/profile issue - dirty or misbound worktree - terminal/runtime defect - project configuration issue - unavailable workflow instruction 10. Recommend a durable fix. 11. Recommend or create a follow-up issue only if authorized by role/workflow. 12. Do not use temp scripts, direct API fallback, MCP internals, direct imports, in-memory state restoration, or manual bypasses unless explicitly authorized by a controller. ## Examples of Required BLOCKED + DIAGNOSE Cases - Required `gitea-workflow` skill is unavailable. - Codex, Claude, Gemini, or ChatGPT expose different workflow skill names. - Terminal command runner is broken. - MCP capability resolution fails or resets required lease/session state. - Active profile is wrong for the requested role. - Runtime workspace binding points to the wrong worktree. - Root checkout would be mutated. - Dirty files are detected. - Runtime dirty-file state disagrees with real git status. - Gitea mutation guard blocks because the session is not in an authorized branches/ worktree. - Tool schema or required MCP operation is missing. - Review, merge, author, or reconciler workflow cannot complete with canonical tools. - A required project instruction or checked-in workflow guide cannot be loaded. ## Acceptance Criteria - Add a canonical workflow rule requiring `BLOCKED + DIAGNOSE` whenever a required workflow step cannot be completed. - Update relevant workflow docs, prompts, templates, and skill guides so LLMs do not continue after missing required skills/tools/capabilities. - Add a standard blocker report template with: - required step - observed failure - expected behavior - checks performed - safe recovery attempted - likely classification - durable fix recommendation - whether mutation occurred - single next action - Ensure missing workflow skills fail before git or Gitea mutation. - Ensure broken terminal/tooling failures are reported as process defects, not silently bypassed. - Ensure missing or stale MCP capability state fails closed with diagnosis instead of fallback. - Add tests or proof docs showing that missing skill/tool/capability cases stop before mutation. - Ensure future controller prompts reinforce this rule. ## Suggested Labels - workflow - guardrail - llm-runtime - blocked-diagnose - process-hardening ## Notes This rule is intended to make process/tooling problems visible and fixable. LLMs should not hide workflow failures by continuing with unsafe or undocumented alternatives.
jcwalker3 added the status:in-progress label 2026-07-08 14:28:32 -05:00
jcwalker3 commented 2026-07-08 14:28:32 -05:00
Author
Owner
Copy Link
Copy Source

Issue claim heartbeat

<!-- gitea-issue-claim-heartbeat:v1 --> **Issue claim heartbeat** - kind: claim - issue: #552 - branch: pending - phase: claimed - profile: prgs-author - pr: none - blocker: none - next_action: create worktree and begin implementation
jcwalker3 added mcpworkflowtrackergiteamutating and removed status:in-progress labels 2026-07-08 14:29:33 -05:00
jcwalker3 commented 2026-07-08 14:30:08 -05:00
Author
Owner
Copy Link
Copy Source

Duplicate search performed (using gitea_list_issues state=all + targeted view_issue)

Searched for:

  • BLOCKED DIAGNOSE
  • missing workflow skill
  • required workflow step unavailable
  • LLM stop diagnose blocker
  • unsafe fallback
  • temp script bypass
  • capability deadlock
  • broken terminal command
  • missing tool preflight

Results:

  • No exact match for the general default rule "Require BLOCKED + DIAGNOSE when LLM cannot perform required workflow step".
  • Closest: #551 "Codex sessions do not mount required gitea-workflow skill" — specific to Codex mounting + mentions BLOCKED for missing skill, but not the canonical general rule across all LLMs/workflows.
  • Related but specific: #548/#547 (preflight clear in adopt), #546 (lease clears preflight), #539 (bypass mutations + direct API), #514 (raw branch delete bypass), #535 (lease recovery non-bypassable), preflight issues like #469/#470, EOF/MCP issues #543/#544.
  • No issue defines the exact default behavior + blocker report template + acceptance criteria for all required step failures.

Created: #552
URL: #552

Labels applied: workflow, mcp, tracker, gitea, mutating

Mutations besides issue creation:

  • gitea_mark_issue (start) — claimed, posted heartbeat comment #7205
  • gitea_set_issue_labels (applied 5 labels)

No other git/Gitea mutations. Worktree used for guard compliance: branches/issue-blocked-diagnose-rule

Next action: Implement the rule in workflow docs, prompts, skill guides, and add blocker report template + tests/proof as per acceptance criteria. Claim #552 for implementation.

## Duplicate search performed (using gitea_list_issues state=all + targeted view_issue) Searched for: - BLOCKED DIAGNOSE - missing workflow skill - required workflow step unavailable - LLM stop diagnose blocker - unsafe fallback - temp script bypass - capability deadlock - broken terminal command - missing tool preflight **Results:** - No exact match for the general default rule "Require BLOCKED + DIAGNOSE when LLM cannot perform required workflow step". - Closest: #551 "Codex sessions do not mount required gitea-workflow skill" — specific to Codex mounting + mentions BLOCKED for missing skill, but not the canonical general rule across all LLMs/workflows. - Related but specific: #548/#547 (preflight clear in adopt), #546 (lease clears preflight), #539 (bypass mutations + direct API), #514 (raw branch delete bypass), #535 (lease recovery non-bypassable), preflight issues like #469/#470, EOF/MCP issues #543/#544. - No issue defines the exact default behavior + blocker report template + acceptance criteria for all required step failures. **Created:** #552 **URL:** https://gitea.prgs.cc/Scaled-Tech-Consulting/Gitea-Tools/issues/552 **Labels applied:** workflow, mcp, tracker, gitea, mutating **Mutations besides issue creation:** - gitea_mark_issue (start) — claimed, posted heartbeat comment #7205 - gitea_set_issue_labels (applied 5 labels) No other git/Gitea mutations. Worktree used for guard compliance: branches/issue-blocked-diagnose-rule **Next action:** Implement the rule in workflow docs, prompts, skill guides, and add blocker report template + tests/proof as per acceptance criteria. Claim #552 for implementation.
jcwalker3 added the status:in-progress label 2026-07-08 14:40:10 -05:00
jcwalker3 commented 2026-07-08 14:40:10 -05:00
Author
Owner
Copy Link
Copy Source

Issue claim heartbeat

<!-- gitea-issue-claim-heartbeat:v1 --> **Issue claim heartbeat** - kind: claim - issue: #552 - branch: issue-552-blocked-diagnose - phase: claimed - profile: author - pr: none - blocker: none - next_action: create worktree and begin implementation
sysadmin removed the status:in-progress label 2026-07-09 08:30:40 -05:00
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 labels gitea mcp mutating tracker workflow
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
jcwalker3 sysadmin
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

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