Description
The itil-correction-detect UserPromptSubmit hook false-positives on orchestrator-authored and AFK-iteration prompt text. CORRECTION_SIGNAL_PATTERNS in packages/itil/hooks/lib/detectors.sh matches the strong-affect tokens DO NOT / NEVER / MUST NOT. These tokens appear routinely in orchestrator-authored constraint blocks (for example AFK /wr-itil:work-problems iter dispatch prompts), which are not user corrections. When they match, the hook injects the full "MANDATORY correction signal detected -- OFFER ticket capture FIRST" instruction block on that prompt.
This injected instruction is both inapplicable and unfireable in the AFK case: no user correction occurred, and it demands an AskUserQuestion-shaped capture offer that AFK loop rules forbid. Every affected iteration must reason its way out of the resulting instruction conflict, paying a context and reasoning tax. The hook fired on the very dispatch prompt that surfaced this report.
Symptoms
- AFK iter prompts containing
DO NOT / NEVER / MUST NOT constraint language receive the full MANDATORY capture-offer injection block on every UserPromptSubmit (observed across multiple AFK iters, e.g. 2026-06-11).
- The injected instruction demands an
AskUserQuestion-shaped offer that AFK loop rules forbid, placing the iter in an instruction conflict it must reason its way out of before doing useful work.
Workaround
The iter agent recognises the false positive (orchestrator text, not a user correction), declines the offer, and notes it for retro. This costs context plus reasoning on every affected iter; there is no way to suppress the injection itself.
Affected plugin / component
@windyroad/itil — packages/itil/hooks/lib/detectors.sh (CORRECTION_SIGNAL_PATTERNS) and the correction-detect UserPromptSubmit hook that consumes it.
Frequency
Most AFK iters. Orchestrator constraint blocks routinely contain DO NOT / NEVER, so the false positive fires on a large fraction of AFK loop iterations.
Versions
- Local plugin:
@windyroad/itil@0.49.4
- Upstream package: not applicable (the gap is in the windyroad plugin itself)
- Claude Code CLI: 2.1.177
- Node: v22.17.1
- OS: Darwin 25.3.0 x86_64
Evidence
- The match is purely lexical:
CORRECTION_SIGNAL_PATTERNS keys on \bDO NOT\b (and siblings) with no provenance check distinguishing user-authored corrections from orchestrator/system-authored constraint text.
- Severity is low (noise and context tax, no data loss), but it recurs on nearly every AFK loop iteration.
Suggested fix shape
Two candidate surfaces:
- Detector-side: skip prompts carrying AFK / orchestrator markers (for example an
ITERATION_SUMMARY contract block or a work-problems sentinel) before matching CORRECTION_SIGNAL_PATTERNS.
- Instruction-side: give the injected capture-offer instruction an AFK branch that queues the observation rather than demanding an interactive offer.
Cross-reference
Reported from https://github.com/voder-ai/voder-mcp-hub docs/problems/open/110-itil-correction-detect-hook-false-positives-on-orchestrator-prompt-text.md (private repo).
This issue is tracked locally as P110 in the downstream project's docs/problems/ directory.
Description
The
itil-correction-detectUserPromptSubmithook false-positives on orchestrator-authored and AFK-iteration prompt text.CORRECTION_SIGNAL_PATTERNSinpackages/itil/hooks/lib/detectors.shmatches the strong-affect tokensDO NOT/NEVER/MUST NOT. These tokens appear routinely in orchestrator-authored constraint blocks (for example AFK/wr-itil:work-problemsiter dispatch prompts), which are not user corrections. When they match, the hook injects the full "MANDATORY correction signal detected -- OFFER ticket capture FIRST" instruction block on that prompt.This injected instruction is both inapplicable and unfireable in the AFK case: no user correction occurred, and it demands an
AskUserQuestion-shaped capture offer that AFK loop rules forbid. Every affected iteration must reason its way out of the resulting instruction conflict, paying a context and reasoning tax. The hook fired on the very dispatch prompt that surfaced this report.Symptoms
DO NOT/NEVER/MUST NOTconstraint language receive the full MANDATORY capture-offer injection block on everyUserPromptSubmit(observed across multiple AFK iters, e.g. 2026-06-11).AskUserQuestion-shaped offer that AFK loop rules forbid, placing the iter in an instruction conflict it must reason its way out of before doing useful work.Workaround
The iter agent recognises the false positive (orchestrator text, not a user correction), declines the offer, and notes it for retro. This costs context plus reasoning on every affected iter; there is no way to suppress the injection itself.
Affected plugin / component
@windyroad/itil—packages/itil/hooks/lib/detectors.sh(CORRECTION_SIGNAL_PATTERNS) and the correction-detectUserPromptSubmithook that consumes it.Frequency
Most AFK iters. Orchestrator constraint blocks routinely contain
DO NOT/NEVER, so the false positive fires on a large fraction of AFK loop iterations.Versions
@windyroad/itil@0.49.4Evidence
CORRECTION_SIGNAL_PATTERNSkeys on\bDO NOT\b(and siblings) with no provenance check distinguishing user-authored corrections from orchestrator/system-authored constraint text.Suggested fix shape
Two candidate surfaces:
ITERATION_SUMMARYcontract block or awork-problemssentinel) before matchingCORRECTION_SIGNAL_PATTERNS.Cross-reference
Reported from https://github.com/voder-ai/voder-mcp-hub
docs/problems/open/110-itil-correction-detect-hook-false-positives-on-orchestrator-prompt-text.md(private repo).This issue is tracked locally as P110 in the downstream project's
docs/problems/directory.