@windyroad/itil 0.49.2 → 0.49.3

package/.claude-plugin/plugin.json

@@ -497,5 +497,5 @@
     }
   },
   "name": "wr-itil",
-  "version": "0.49.2"
+  "version": "0.49.3"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@windyroad/itil",
-  "version": "0.49.2",
+  "version": "0.49.3",
   "description": "ITIL-aligned IT service management for Claude Code (problem, and future incident/change skills)",
   "bin": {
     "windyroad-itil": "./bin/install.mjs"

package/skills/work-problems/SKILL.md

@@ -961,6 +961,8 @@ Before spawning the next iteration's subagent, verify the working tree state aga
 
 Go back to step 1. The backlog may have changed — new problems may have been created during fixes, priorities may have shifted, and the README.md cache will be stale.
 
+Natural-language modifiers in the invocation args (`just`, `only`, `first`, `merely`, `simply` paired with a ticket reference — e.g. `/wr-itil:work-problems just work P170`) are **SCOPE FILTERS** that override Step 1's WSJF selection; they do NOT alter Step 7's loop-back semantics. See **Mid-loop ask discipline → Scope-pin-word semantics (P175)** below for the load-bearing prose.
+
 ## Non-Interactive Decision Making
 
 When `AskUserQuestion` is unavailable or the user is AFK, the skill (and the delegated manage-problem skill) should resolve decisions automatically:
@@ -1013,6 +1015,11 @@ 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 JTBD-006 (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 JTBD-001 (Enforce Governance Without Slowing Down — ADR-044 framework-resolution boundary for loop control codified in skill prose; no re-prompt round-trip after scope-pin invocation) -->
+<!-- @problem P175 -->
+**Scope-pin-word semantics (P175).** Natural-language modifiers in the invocation args — `just`, `only`, `first`, `merely`, `simply` paired with a ticket reference (e.g. `/wr-itil:work-problems just work P170`) — are **SCOPE FILTERS** over Step 1's WSJF selection: they pin the loop to the named ticket instead of letting Step 3's tier + tie-break ladder select. They are NOT count constraints. The Step 7 → Step 1 loop-back contract is unchanged; iterations continue on the pinned ticket until a framework-prescribed stop condition fires (Step 2 #1 no actionable / #2 all interactive / #3 all blocked; Step 2.4 gate (a)/(b) pre-`ALL_DONE` sequence; quota exhaustion; Step 6.5 / Step 6.75 / Step 0 halt paths). The orchestrator MUST NOT emit `ALL_DONE` from natural-language modifier interpretation alone — `ALL_DONE` is reserved for the framework-resolved stop surface per Step 2.4 gate (c). Concretely: if iter 1 on the pinned ticket returns `outcome: partial-progress` with `outstanding_questions` queued and remaining slices named in `notes`, the orchestrator dispatches iter 2 on the same pinned ticket; the loop only stops when the ticket's actionable work is exhausted (Step 2 #1 then fires for the pinned-scope view) OR a halt path fires. This is the **inverse-direction** failure mode of P130's inverse-presence pattern — both stem from agent over-inferring loop-control semantics the framework already resolved (per ADR-044 framework-resolution boundary's "Continue / stop loops" mediation; loop control is framework-resolved, agents do not invent halt criteria from natural-language modifiers). When the user invokes the orchestrator with a scope-pin word, treat that word as a **selection override** only, not a loop-control directive.
+
 **Accumulated-question discipline at surface time** (per ADR-044's six-class authority taxonomy — questions that reach the user must be load-bearing):
 
 - **Direction-setting only** — questions that ONLY the user can answer because they reflect goals, intent, or trade-offs the framework has not yet captured. Other accumulated observations (deviation-approval, one-time-override, silent-framework, taste, correction-followup) follow the same shape as the deviation-candidate schema in Step 5's `outstanding_questions` contract.
@@ -1115,6 +1122,7 @@ When every skipped ticket is in the `upstream-blocked` category (stop-condition
 - **P053** — Outstanding Design Questions surfacing at stop-condition #2 (Step 2.5); fed by the iteration subagent's `outstanding_questions` field.
 - **P122** (`docs/problems/122-work-problems-stop-condition-2-defaults-to-afk-table-instead-of-asking-interactively.verifying.md`) — established the AskUserQuestion-default-when-available routing at Step 2.5. The routing prose (default branch, Rule 6 fallback, cross-skill principle, user-answerable scoping) was originally landed under Step 2.5; P126 moved it into the reusable Step 2.5b sub-step.
 - **P126** (`docs/problems/126-work-problems-failure-handling-halt-bypasses-step-2-5-routing.known-error.md`) — extended the principle to every halt path that emits a final AFK summary. Step 2.5b is the single source of truth that Step 2.5, Step 0 (session-continuity + fetch-failure), Step 6.5 (Failure handling + Rule 5 above-appetite), and Step 6.75 (dirty-for-unknown-reason) all cross-reference. The principle: `halt-paths-must-route-design-questions-through-Step-2.5b`. Behavioural second-source: `test/work-problems-step-2-5b-cross-halt-routing.bats`.
+- **P175** (`docs/problems/open/175-agent-over-narrows-scope-pin-words-into-count-constraints-halts-loop-on-agent-inferred-scope.md`) — driver for the **Scope-pin-word semantics** paragraph in the "Mid-loop ask discipline" subsection plus a brief forward-pointer at Step 7. Bug shape: when the user invokes `/wr-itil:work-problems just work P170` (or `only`/`first`/`merely`/`simply` paired with a ticket reference), the orchestrator over-narrows the natural-language modifier as a count constraint and emits `ALL_DONE` after iter 1 even when iter 1 returned `outcome: partial-progress` with named remaining slices AND no Step 2 stop-condition fired. Fix: SKILL.md prose classifies the scope-pin vocabulary as **selection override** (Step 1 WSJF override only); explicitly disclaims any loop-control effect; reminds that the Step 7 → Step 1 loop-back contract is unchanged and `ALL_DONE` is reserved for the framework-resolved stop surface per Step 2.4 gate (c). Inverse-direction sibling of P130 (P130 is inverse-presence inference; P175 is inverse-scope inference; both stem from agent over-inferring loop-control semantics the framework already resolved per ADR-044 "Continue / stop loops"). Behavioural second-source: `eval/promptfooconfig.yaml` Tier-A regex + Tier-B llm-rubric asserting the orchestrator does NOT emit `ALL_DONE` after iter 1 on a scope-pin-word invocation with named remaining slices.
 - **ADR-013** (`docs/decisions/013-structured-user-interaction-for-governance-decisions.proposed.md`) — Rule 6 non-interactive fail-safe applies to every iteration-subagent decision surface.
 - **ADR-014** (`docs/decisions/014-governance-skills-commit-their-own-work.proposed.md`) — preserved under the iteration subagent; the subagent commits its own work.
 - **ADR-015** (`docs/decisions/015-on-demand-assessment-skills.proposed.md`) — Agent-tool-vs-Skill-tool delegation precedent (Step 6.5's wording mirror).