@windyroad/itil 2.4.0-preview.1221 → 2.4.1-preview.1235

package/.claude-plugin/plugin.json

@@ -497,5 +497,5 @@
     }
   },
   "name": "wr-itil",
-  "version": "2.4.0"
+  "version": "2.4.1"
 }

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "wr-itil",
-  "version": "2.4.0",
+  "version": "2.4.1",
   "description": "ITIL problem-management workflows for AI coding agents",
   "author": {
     "name": "Windy Road Technology",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@windyroad/itil",
-  "version": "2.4.0-preview.1221",
+  "version": "2.4.1-preview.1235",
   "description": "ITIL-aligned IT service management for Claude Code and Codex",
   "bin": {
     "windyroad-itil": "./bin/install.mjs"

package/skills/work-problems/SKILL.md

@@ -342,6 +342,8 @@ There is no turn-bound: the loop runs until a real end state (printed Gate (0) z
 
 **One-directional anchor.** The goal forces continuation; it never authorises a stop. A goal that is cleared (or was never set) does NOT discharge Gate (0) — `ALL_DONE` still requires the full Step 2.4 sequence. Requirements floor: `/goal` needs workspace trust + hooks enabled; below the floor the loop degrades honestly to Gate (0)-only behaviour.
 
+**Loop entry (the "The agent treats the user's absence as a stop signal for the loop that exists to run during it" problem).** Invoking this skill puts the session INSIDE the loop — from Step 0's first pre-flight onward, before any iteration has been dispatched, and whether or not an anchor was set. From here the orchestrator session ends only through an ending it names in the transcript; see **Mid-loop ask discipline → Named-exit discipline (the "The agent treats the user's absence as a stop signal for the loop that exists to run during it" problem)** for the rule and the ending set. The anchor is the external enforcement of that rule; the rule binds unanchored runs identically.
+
 ### Step 1: Scan the backlog
 
 Read `docs/problems/README.md` if it exists and is fresh (check via git history — see manage-problem step 9 for the cache freshness check). If stale or missing, scan all open + known-error tickets via the dual-tolerant pattern `ls docs/problems/*.open.md docs/problems/*.known-error.md docs/problems/open/*.md docs/problems/known-error/*.md 2>/dev/null` (the ": docs/problems/ flat layout migration — per-state subdirs + adopter auto-migration" release design migration window — covers BOTH the flat `<NNN>-<title>.<state>.md` filename-suffix layout AND the per-state subdir `<state>/<NNN>-<title>.md` layout), extract their WSJF scores, and rank them.
@@ -362,6 +364,8 @@ Stop the loop and report a summary if any of these are true:
 2. **All remaining problems require interactive input** — their scope expanded beyond what's safe to auto-resolve, or they need user verification with **no evidence available**. A verifying ticket carrying cited evidence (a `yes — observed: <citation>` Verification Queue cell, or an in-session exercise the loop can cite) is **not** interactive-gated — it is drainable by evidence-backed closure per the "The Verification Pending → Closed transition is reserved for the maintainer, so evidence-based closure never fires and the verification queue grows without bound" problem, and its presence disproves this stop condition.
 3. **All remaining problems are blocked** — investigation hit a dead end, or the fix requires changes outside the project
 
+These conditions say when a stop is *permitted*; they are not the only way a loop can end early. An orchestrator can also end by simply not continuing — forbidden per **Mid-loop ask discipline → Named-exit discipline (the "The agent treats the user's absence as a stop signal for the loop that exists to run during it" problem)**.
+
 **Step 2.5 fires unconditionally at loop end** (the "Decision-delegation contract — agents over-apply Rule 1's interactive default to framework-resolved decisions; codify the framework-resolution boundary + AFK loop's batched-questions-as-deliverable + lazy-AskUserQuestion measurement" problem Phase 3 / the "— Decision-Delegation Contract: when agents act on the framework vs ask the user" architecture rule) — promoted from "fallback when stop-condition #2" to **default loop-end emit shape**. Anti-BUFD framing per the "— Decision-Delegation Contract: when agents act on the framework vs ask the user" architecture rule: the AFK loop is the empirical-discovery engine; direction-class observations + deviation-candidates accumulate from real friction across iters; loop-end batched presentation is the user-facing deliverable. Per-iter surfacing was the old (now-superseded) pattern; Phase 3 makes batch-at-loop-end the default for ALL stop conditions, not just #2.
 
 For stop-conditions #1 and #3 (no actionable problems / all blocked), Step 2.5 still runs — it reads the accumulated `outstanding_questions` queue from `.afk-run-state/outstanding-questions.jsonl` and presents the batch. Empty queue → no `AskUserQuestion` fires; non-empty queue → batched per the "Structured User Interaction for Governance-Skill Decisions" architecture rule Rule 1 cap (≤4 per call, sequential if >4).
@@ -382,7 +386,7 @@ Before the orchestrator emits the final `ALL_DONE` sentinel for the AFK loop, it
 
 3. *Decide.* If the re-scan yields **≥1 dispatchable ticket**, `ALL_DONE` is FORBIDDEN: the stop-condition the orchestrator was about to emit does NOT objectively hold. Route by class. A dispatchable **open / known-error** ticket loops back to Step 3 tier-first selection (Critical-bypass → Inbound-reported → Internal, within-tier WSJF per the "Inbound-reported problems rank ahead of internally-discovered problems via a sort tier" architecture rule) over the dispatchable set. A dispatchable **verifying** ticket routes to the **Step 6.1 verification drain — never to Step 3**: Step 1 excludes `.verifying.md` from dev-work ranking under the "Problem lifecycle — add a Verification Pending status between Known Error and Closed" architecture rule's multiplier-0 rule and Step 3 selects only from the ranked set, so sending it to Step 3 would either conflict with that rule or leave it with no consumer while this gate forbids `ALL_DONE` — a livelock. Having routed, the orchestrator dispatches the next iter — it does NOT proceed to gate (a)/(b)/(c). Only when the re-scan yields **zero dispatchable tickets** does gate (0) pass and the sequence proceed to gate (a). Gate (0) finding work is a **loopback, not a halt** — it is productive (the loop resumes draining), so it is NOT a Hard-fail halt trigger.
 
-**Why gate (0) fires first**: gates (a)/(b)/(c) (surface questions → retro → emit) presume the loop is genuinely done; running the retro and emitting `ALL_DONE` while dispatchable work remains prematurely ends the AFK drain (the "agent ends the work-problems loop (emits ALL_DONE) prematurely while actionable Tier-2 backlog remains, by rationalising the remainder as out-of-scope / interactive-gated" problem), forcing the user to re-prompt "keep working the backlog" and defeating the ": Progress the Backlog While I'm Away" user outcome. Gate (0) makes "the backlog is objectively empty of dispatchable tickets" a hard, re-verified precondition of the whole sequence rather than a subjective agent judgement. A user-directed mid-loop pivot (e.g. an eval-cohort detour) does NOT discharge the Tier-exhaustion obligation: after the pivot, gate (0)'s re-scan resumes tier selection rather than terminating — which also catches the "agent ends the work-problems loop (emits ALL_DONE) prematurely while actionable Tier-2 backlog remains, by rationalising the remainder as out-of-scope / interactive-gated" problem coverage miss where a Tier-1 ticket (the "work-problems `claude -p` iter subprocesses miss project-scoped governance plugins (need `--plugin-dir` in dispatch)" problem) was skipped entirely. Sibling class: the "run-retro skips Step 1.5 / Step 3 / Step 4b Stage 1 under session-length rationalization — recurrence of anti-pattern class on the run-retro meta-surface" problem (run-retro skip rationalisation), the "Agent defers ticket creation to retro summary "Tickets Deferred" section instead of immediately invoking `/wr-itil:manage-problem` — observations could be lost if user is in a rush" problem (Stage-1 ticketing skip), the "Agent over-narrows scope-pin words ("just", "only", "first") into count constraints — halts AFK loop on agent-inferred scope rather than framework-prescribed stop conditions" problem (scope-pin loop-control inference) — all agent-invented loop-control stops the framework did not authorise (the "— Decision-Delegation Contract: when agents act on the framework vs ask the user" architecture rule "Continue / stop loops" is framework-resolved: the natural stop is concrete — `ALL_DONE` conditions objectively met — not "this feels done").
+**Why gate (0) fires first**: gates (a)/(b)/(c) (surface questions → retro → emit) presume the loop is genuinely done; running the retro and emitting `ALL_DONE` while dispatchable work remains prematurely ends the AFK drain (the "agent ends the work-problems loop (emits ALL_DONE) prematurely while actionable Tier-2 backlog remains, by rationalising the remainder as out-of-scope / interactive-gated" problem), forcing the user to re-prompt "keep working the backlog" and defeating the ": Progress the Backlog While I'm Away" user outcome. Gate (0) makes "the backlog is objectively empty of dispatchable tickets" a hard, re-verified precondition of the whole sequence rather than a subjective agent judgement. A user-directed mid-loop pivot (e.g. an eval-cohort detour) does NOT discharge the Tier-exhaustion obligation: after the pivot, gate (0)'s re-scan resumes tier selection rather than terminating — which also catches the "agent ends the work-problems loop (emits ALL_DONE) prematurely while actionable Tier-2 backlog remains, by rationalising the remainder as out-of-scope / interactive-gated" problem coverage miss where a Tier-1 ticket (the "work-problems `claude -p` iter subprocesses miss project-scoped governance plugins (need `--plugin-dir` in dispatch)" problem) was skipped entirely. Sibling class: the "run-retro skips Step 1.5 / Step 3 / Step 4b Stage 1 under session-length rationalization — recurrence of anti-pattern class on the run-retro meta-surface" problem (run-retro skip rationalisation), the "Agent defers ticket creation to retro summary "Tickets Deferred" section instead of immediately invoking `/wr-itil:manage-problem` — observations could be lost if user is in a rush" problem (Stage-1 ticketing skip), the "Agent over-narrows scope-pin words ("just", "only", "first") into count constraints — halts AFK loop on agent-inferred scope rather than framework-prescribed stop conditions" problem (scope-pin loop-control inference) — all agent-invented loop-control stops the framework did not authorise (the "— Decision-Delegation Contract: when agents act on the framework vs ask the user" architecture rule "Continue / stop loops" is framework-resolved: the natural stop is concrete — `ALL_DONE` conditions objectively met — not "this feels done"). Gate (0) does not cover the silent exit (the "The agent treats the user's absence as a stop signal for the loop that exists to run during it" problem): it fires only when the orchestrator is about to emit `ALL_DONE`, so an orchestrator that ends its turn having emitted nothing reaches no gate at all — see **Mid-loop ask discipline → Named-exit discipline**.
 
 **Gate (0) × Step 0e `/goal` anchor (the "AFK loops anchor completion with the native `/goal` external evaluator" architecture rule).** Under an active goal, the `ALL_DONE` emit does not by itself end the session — the Step 0e external evaluator reads the printed gate (0) table + sentinel and independently confirms the condition holds; a premature emit just triggers a "keep working" turn with the evaluator's reason as guidance. The anchor is one-directional: a cleared goal (or a loop that was never anchored) does NOT relax this gate — gate (0) fires unconditionally either way.
 
@@ -1189,6 +1193,20 @@ The orchestrator MUST NOT call `AskUserQuestion` between iterations except at th
 
 **No mid-iter ask points.** Every other point in the orchestrator's main turn (between Step 5 dispatch completing and Step 6.5 release-cadence check; between Step 6.75 verification and Step 7 loop-back; between Step 7 and Step 1 next-iteration; between consecutive iters generally) is a mechanical-stage transition that the framework has already resolved. Do NOT introduce ad-hoc `AskUserQuestion` calls at those points to confirm "is it OK to proceed?" or "want me to start the next iter?" — proceeding IS the framework-resolved default. Continue iterating until quota or stop-condition #1/#2/#3 fires.
 
+<!-- @jtbd the ": Progress the Backlog While I'm Away" user outcome (Progress the Backlog While I'm Away — the announcement of absence is the loop's trigger, never its terminator; the orchestrator session cannot end by simply not continuing) -->
+<!-- @problem the "The agent treats the user's absence as a stop signal for the loop that exists to run during it" problem -->
+**Named-exit discipline — silence is not an exit (the "The agent treats the user's absence as a stop signal for the loop that exists to run during it" problem).** Every guard above fires on the `ALL_DONE` emit path: Step 2.4 gate (0) re-scans when the orchestrator is *about to emit*; the scope-pin clause forbids emitting *from a modifier*; Step 2 lists the conditions that *permit* an emit. An orchestrator that stops by simply not continuing — printing nothing, ending its turn mid-loop — passes all of them by reaching none. **Silence is an unguarded exit**, and it is the one the "The agent treats the user's absence as a stop signal for the loop that exists to run during it" problem took: the pre-flight ran, an interruption redirected the session for hours, and the loop was wrapped up with zero iterations ever dispatched.
+
+Scope is the **orchestrator session**. An iteration subprocess has its own end states — the ones the "Per-ticket goal anchors each AFK iteration" architecture rule names for an iteration: a `worked` `ITERATION_SUMMARY` carrying a `commit_sha`, a `skipped` one carrying a `skip_reason_category`, or a halt naming a concrete blocker, with quota exhaustion deliberately absent because quota death prints no summary at all. Do NOT read this rule onto an iter.
+
+The rule: once Step 0's pre-flight has run, the session is INSIDE the loop, and it leaves only through an ending it **names in the transcript**. The ending set is the one Step 0e's canonical goal condition already publishes — read it from the `<!-- CANONICAL-GOAL-CONDITION-SOURCE -->` block rather than keeping a second list here, since only that block is drift-checked and a future amendment naming a further terminal report extends that block, not this clause — plus one delta: an **explicit user stop directive** about the LOOP. That directive also requires the goal to be cleared, or the one-directional anchor (the "AFK loops anchor completion with the native `/goal` external evaluator" architecture rule) keeps firing continuation turns; on the Claude Code surface only the user can type `/goal`, while on Codex the orchestrator clears it itself via `thread/goal/clear` (the "Per-ticket goal anchors each AFK iteration" architecture rule). A user-stop exit that prints a final AFK summary inherits the Step 2.4 gate sequence like any other summary-emitting path.
+
+The obligation attaches to every turn in which the orchestrator is executing the loop: such a turn MUST end having either printed one of those endings or dispatched the next iteration. **There is no third state.** A turn spent serving an interrupting user request on another subject is not a loop turn — it is neither an ending nor a violation of this rule. How long the loop's liveness survives such a detour is an open contract (the "The agent treats the user's absence as a stop signal for the loop that exists to run during it" problem investigation task 1) and is deliberately not answered here; until it is recorded, infer no answer from this clause's silence in either direction.
+
+A closing summary that calls the drain "parked", "ready when you are" or "waiting for you", or that hands the user an instruction for restarting the loop, is the silent-exit defect wearing a report: it is not one of the named endings, and it moves the framework's obligation onto the user's checklist. The framework-prescribed halt points enumerated above are NOT that defect — each is either a Hard-fail halt directive naming the gate that could not complete, or the Gate (0) + `ALL_DONE` ending itself. Nothing in this clause licenses dispatching past a genuine halt.
+
+**Absence is a CONTINUE signal, never a stop (the "The agent treats the user's absence as a stop signal for the loop that exists to run during it" problem).** "I'm off to bed", "goodnight", "heading out", "back in the morning", "afk", "leaving you to it" — these are the loop's **precondition**, not its termination. the ": Progress the Backlog While I'm Away" user outcome is *Progress the Backlog While I'm Away*, and this skill's own trigger is a user who "says they'll be away and wants problems handled". The clearest AFK signal available is therefore the strongest instruction to keep dispatching, and reading it as a cue to wrap up inverts the feature in exactly the window the feature exists for. This extends the presence clause above from ask-discipline to loop-control: presence-detection is unreliable AND presence is not loop-control input at all. An announcement that the user is leaving, going to sleep, or will be unreachable is not a stop directive.
+
 <!-- @jtbd the ": Progress the Backlog While I'm Away" user outcome (Progress the Backlog While I'm Away — scope-pin invocation does not trigger agent-inferred premature halt; loop advances pinned-ticket work until framework-prescribed stop fires) -->
 <!-- @jtbd the ": Enforce Governance Without Slowing Down" user outcome (Enforce Governance Without Slowing Down — the "— Decision-Delegation Contract: when agents act on the framework vs ask the user" architecture rule framework-resolution boundary for loop control codified in skill prose; no re-prompt round-trip after scope-pin invocation) -->
 <!-- @problem the "Agent over-narrows scope-pin words ("just", "only", "first") into count constraints — halts AFK loop on agent-inferred scope rather than framework-prescribed stop conditions" problem -->