@windyroad/itil 3.5.0 → 3.6.0-preview.1379

package/.claude-plugin/plugin.json

@@ -486,5 +486,5 @@
     }
   },
   "name": "wr-itil",
-  "version": "3.5.0"
+  "version": "3.6.0"
 }

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "wr-itil",
-  "version": "3.5.0",
+  "version": "3.6.0",
   "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": "3.5.0",
+  "version": "3.6.0-preview.1379",
   "description": "ITIL-aligned IT service management for Claude Code and Codex",
   "bin": {
     "windyroad-itil": "./bin/install.mjs"

package/skills/outcome-led-planning/SKILL.md

@@ -46,15 +46,17 @@ Include:
 
 The plan MUST consider bounded tasks within Now and expose useful opportunities for others to contribute. A starting battle plan may describe likely work, dependencies and parallel opportunities without precreating, assigning or reserving all future tasks. In shared work, contributors create/reuse and claim bounded tasks just before work under the selected coordination rules. The increment owner keeps acceptance, sequence and integration clear and resolves overlap; explicit assignments and handoffs remain valid.
 
+Reuse fitting code. Build required real cases fit for purpose: first, second, third; then refactor actual commonality and keep necessary differences. Do not extract a new shared abstraction before the third real implementation. Do not invent cases or abstractions. Call out implicit refactoring/cleanup in every Now increment; finish before final verification/acceptance and carry remaining responsibility through handover. Cleanup does not require extraction or a separate issue.
+
 Do not fill Next or Later with invented features. If evidence does not yet justify further work toward the confirmed outcome, leave those horizons to be determined from verified remaining gaps. Preserve known delivery stages required by the objective.
 
 Use INVEST as a quality check for **Now**: independently deliverable, negotiable means within the confirmed goal, valuable, estimable with uncertainty disclosed, small, and testable. Internal dependencies are acceptable when the whole increment remains coherently and safely deliverable. Do not manufacture precise estimates. Do not introduce story documents just to use INVEST; retain any story and approval requirements the project already imposes. Next and Later stay provisional and need less detail.
 
 Choose the smallest independently useful business result. Name who benefits and the observable improvement, validated decision or capability. Split again if a smaller result has value; shared code does not justify bundling. Technical activity alone is insufficient. Retain required security, integrity, recovery and acceptance. Foundations need explicit value and limits; environment promotion stages are not automatically increments. Deliver the verified minimum and replan before adding work. Apply whenever Now changes; keep remaining delivery plans provisional.
 
-If uncertainty prevents a bounded, estimable implementation increment, use a small discovery or qualification increment with explicit value, finite inspection targets, stopping condition, output and grounded qualitative effort. Read [bounded discovery guidance](references/planning-details.md#bounded-discovery) before making that increment executable. Keep later implementation provisional; do not replace the final outcome with discovery.
+If uncertainty prevents bounded implementation, read [bounded discovery guidance](references/planning-details.md#bounded-discovery) and propose a small discovery increment with value, finite scope, stopping condition, output, verification and grounded qualitative effort. Keep implementation provisional and the final outcome unchanged.
 
-Use the project's existing delivery and environment-promotion process. Do not turn a planning convention or hypothetical unrelated interference into extra operator preflights, predicted resource or diff allowlists, approval gates, scripts or pipelines. Preserve required project checks and authority boundaries. When the existing workflow qualifies changes in a test environment before promotion, inspect the actual result, repair through that workflow and promote when qualified. Investigate observed interference and reassess material risk; do not invent an extra prerequisite without evidence or an applicable project rule.
+Follow the project's existing delivery/promotion workflow, checks and authority. Do not invent preflights, resource/diff allowlists, gates, scripts or pipelines for hypothetical interference. Inspect test-environment results, repair through that workflow and promote when qualified; investigate actual interference and reassess material risk.
 
 Complete every delivery stage required by the confirmed outcome and project workflow. A commit, green CI, or publication proves only its own stage.
 
@@ -68,7 +70,7 @@ Task creation, claims and routine status updates within the assessed plan do not
 
 Use available independent reviewers and identify substitutions. Follow the JTBD recommendation-review prefix where required; that review does not authorize edits. If a substantive critic is unavailable, report the exact missing capability and hold dependent implementation; continue authorized preparation. Do not self-approve, claim a pass or treat ordinary go-ahead as a missing review. Read [reviewer capability guidance](references/planning-details.md#independent-reviewer-capability).
 
-The planner MUST NOT add speculative risk-mitigation tasks. The risk scorer identifies necessary treatments from the applicable risk policy and risk register. The risk critic vetoes speculative mitigation increments justified only by imagined failure or agent discomfort. Require an evidenced risk or applicable requirement, credible impact/likelihood, connection to the confirmed outcome and proportionate expected reduction relative to cost and delay. A prior incident is not required: established preventive risks and required controls remain valid. A low action-risk score permits an action within appetite; it does not establish necessity or priority. Remove unjustified mitigation work from Now/Next/Later instead of inventing a registry, report, human gate or mandatory discovery increment to justify it.
+Planner and implementer MUST NOT add speculative risk-reduction tasks, checks, tests, audits, gates or hardening. Do the requested work and required checks; **do not preempt the risk scorer.** The scorer directs additional treatments from the risk policy/register. Speculative work wastes resources, delays value and creates false confidence; remove it.
 
 Resolve substantive findings from all five critics and reduce above-appetite risk under the applicable policy. Reassess affected critics after material changes until the exact plan revision is coherent and within appetite. Record the reviewer identities, assessed revision, verdicts and evidence in the existing issue or plan artifact; no new report or template is required. A completed review with unresolved substantive findings is not a pass. Distinguish forecast controls from controls already verified. Plan assessment does not replace concrete code, commit, push, release, or operational reviews required by the project.
 
@@ -78,6 +80,8 @@ Perform reviews within existing authorization and policy. Replanning grants no w
 
 Execute the assessed **Now** increment through the applicable delivery workflow. Integrate independently safe changes promptly and preserve other owners' work. Keep unfinished functionality safely dormant where necessary.
 
+Before tests or deployment, try new integrations locally with real requests within existing authority. Inspect actual behaviour/responses; build from these, not guessed shapes or mocks. Never first experiment in production. Read [integration guidance](references/planning-details.md#new-integrations).
+
 For GitHub delivery, follow the [work checkpoints](references/github-coordination.md#reconcile-tracking-at-work-checkpoints), with regular discussion reads AND event checks. Reconcile each affected record and selected Project from saved state; read back changes.
 
 At each increment boundary:

package/skills/outcome-led-planning/references/planning-details.md

@@ -12,7 +12,7 @@ Iterate each **initial or materially revised executable plan with five independe
 
 - **Architect:** checks structural choices, interfaces and existing decisions.
 - **JTBD:** checks intended beneficiaries and their desired outcomes.
-- **Risk:** checks action risk and whether proposed mitigation work is justified.
+- **Risk:** checks action risk and whether proposed mitigation work is justified. The risk scorer vetoes speculative work justified only by imagined failure or agent discomfort. Necessary treatments require an established risk or applicable requirement, credible impact/likelihood and proportionate reduction relative to cost and delay. A prior incident is not required; established preventive risks and required controls remain valid. An in-appetite action score does not establish necessity or priority. Remove unjustified work rather than invent a registry, report, human gate or discovery increment to justify it.
 - **Cognitive accessibility:** checks whether beneficiaries and contributors can understand the result, choices and next action without unnecessary cognitive work, jargon or human handoffs.
 - **Planning:** tests INVEST for Now, especially whether a smaller still-valuable increment exists, and outcome-directed dependencies and sequencing across Now/Next/Later. Future horizons remain provisional, without full Now detail. For initial or material plan reviews, inspect the authoritative plan in the chosen vehicle and actual affected tracking records, where used, against the assessed revision, including relevant task and selected Project setup evidence. Return concrete discrepancies; have repairs reflected in that same vehicle and rechecked before dependent work. Do not create a new artifact or tracking vehicle just for review. This is the existing planning review, not another five-critic cycle for routine updates.
 
@@ -30,3 +30,7 @@ Give the critic the acceptance criteria, current revision, actual execution resu
 The critic identifies concrete discrepancies or missing results. Withhold Done, repair within existing authority and obtain a recheck of the repaired results and saved state. If the independent reviewer or required results are unavailable, report the precise gap and withhold the completion claim. This review grants no wider access or operation authority.
 
 This is an increment-acceptance boundary. Completing an individual task or making a routine update does not trigger it or another five-critic cycle. Earlier review, coordination and prerequisite obligations still apply.
+
+## New integrations
+
+Make the first real request from the local development environment to the actual service or its official sandbox within existing authority. Inspect actual responses and behaviour before writing integration tests or deploying; use what you observe to shape implementation and tests. Reuse already-known real behaviour where applicable. Do not invent response shapes, qualify an integration solely against mocks, or learn its behaviour by iterating in production. If real access is unavailable, state that gap and continue useful independent work; mocks do not establish that the interaction works. No new report is required.

package/skills/outcome-led-planning/references/project-tracking.md

@@ -40,6 +40,6 @@ A contributor chooses a useful bounded result in current assessed Now, announces
 
 Hold one contribution claim at a time. Finish, explicitly hand over or release it before claiming another. Coordination ownership does not reserve the work. Keep watched operations with their owners; useful non-conflicting help within that contribution is valid, but a wait does not justify repeated CI/provider operations or a second claim. Resolve overlap before edits, preserve prerequisites and evidence, and record claims/handoffs in the local plan or actual GitHub records according to the selected mode. Project fields apply only to a selected Project.
 
-Task creation, claims and routine status updates within the assessed plan do not restart all five reviews. Material plan changes still need the planning skill's five critics. The planner MUST NOT add speculative risk-mitigation tasks. The scorer derives necessary treatments from the applicable policy and register; explicit requirements and concrete observed risks remain respected. Remove busywork instead of inventing a registry, report, gate or discovery increment to justify it.
+Task creation, claims and routine status updates within the assessed plan do not restart all five reviews. Material plan changes still need the planning skill's five critics. Planner and implementer MUST NOT add speculative risk-reduction work or preempt the risk scorer. Do the requested work and required checks; the scorer directs additional treatments from the applicable policy/register. Remove speculative work rather than invent a registry, report, gate or discovery increment to justify it.
 
 Before asking a human to act, check existing authority. Explain plainly what they must decide and why; assess cognitive clarity with an available reviewer or an identified manual check. Do not invent approval requests for authorized agent work.

package/skills-codex/outcome-led-planning/SKILL.md

@@ -55,15 +55,17 @@ Include:
 
 The plan MUST consider bounded tasks within Now and expose useful opportunities for others to contribute. A starting battle plan may describe likely work, dependencies and parallel opportunities without precreating, assigning or reserving all future tasks. In shared work, contributors create/reuse and claim bounded tasks just before work under the selected coordination rules. The increment owner keeps acceptance, sequence and integration clear and resolves overlap; explicit assignments and handoffs remain valid.
 
+Reuse fitting code. Build required real cases fit for purpose: first, second, third; then refactor actual commonality and keep necessary differences. Do not extract a new shared abstraction before the third real implementation. Do not invent cases or abstractions. Call out implicit refactoring/cleanup in every Now increment; finish before final verification/acceptance and carry remaining responsibility through handover. Cleanup does not require extraction or a separate issue.
+
 Do not fill Next or Later with invented features. If evidence does not yet justify further work toward the confirmed outcome, leave those horizons to be determined from verified remaining gaps. Preserve known delivery stages required by the objective.
 
 Use INVEST as a quality check for **Now**: independently deliverable, negotiable means within the confirmed goal, valuable, estimable with uncertainty disclosed, small, and testable. Internal dependencies are acceptable when the whole increment remains coherently and safely deliverable. Do not manufacture precise estimates. Do not introduce story documents just to use INVEST; retain any story and approval requirements the project already imposes. Next and Later stay provisional and need less detail.
 
 Choose the smallest independently useful business result. Name who benefits and the observable improvement, validated decision or capability. Split again if a smaller result has value; shared code does not justify bundling. Technical activity alone is insufficient. Retain required security, integrity, recovery and acceptance. Foundations need explicit value and limits; environment promotion stages are not automatically increments. Deliver the verified minimum and replan before adding work. Apply whenever Now changes; keep remaining delivery plans provisional.
 
-If uncertainty prevents a bounded, estimable implementation increment, use a small discovery or qualification increment with explicit value, finite inspection targets, stopping condition, output and grounded qualitative effort. Read [bounded discovery guidance](references/planning-details.md#bounded-discovery) before making that increment executable. Keep later implementation provisional; do not replace the final outcome with discovery.
+If uncertainty prevents bounded implementation, read [bounded discovery guidance](references/planning-details.md#bounded-discovery) and propose a small discovery increment with value, finite scope, stopping condition, output, verification and grounded qualitative effort. Keep implementation provisional and the final outcome unchanged.
 
-Use the project's existing delivery and environment-promotion process. Do not turn a planning convention or hypothetical unrelated interference into extra operator preflights, predicted resource or diff allowlists, approval gates, scripts or pipelines. Preserve required project checks and authority boundaries. When the existing workflow qualifies changes in a test environment before promotion, inspect the actual result, repair through that workflow and promote when qualified. Investigate observed interference and reassess material risk; do not invent an extra prerequisite without evidence or an applicable project rule.
+Follow the project's existing delivery/promotion workflow, checks and authority. Do not invent preflights, resource/diff allowlists, gates, scripts or pipelines for hypothetical interference. Inspect test-environment results, repair through that workflow and promote when qualified; investigate actual interference and reassess material risk.
 
 Complete every delivery stage required by the confirmed outcome and project workflow. A commit, green CI, or publication proves only its own stage.
 
@@ -77,7 +79,7 @@ Task creation, claims and routine status updates within the assessed plan do not
 
 Use available independent reviewers and identify substitutions. Follow the JTBD recommendation-review prefix where required; that review does not authorize edits. If a substantive critic is unavailable, report the exact missing capability and hold dependent implementation; continue authorized preparation. Do not self-approve, claim a pass or treat ordinary go-ahead as a missing review. Read [reviewer capability guidance](references/planning-details.md#independent-reviewer-capability).
 
-The planner MUST NOT add speculative risk-mitigation tasks. The risk scorer identifies necessary treatments from the applicable risk policy and risk register. The risk critic vetoes speculative mitigation increments justified only by imagined failure or agent discomfort. Require an evidenced risk or applicable requirement, credible impact/likelihood, connection to the confirmed outcome and proportionate expected reduction relative to cost and delay. A prior incident is not required: established preventive risks and required controls remain valid. A low action-risk score permits an action within appetite; it does not establish necessity or priority. Remove unjustified mitigation work from Now/Next/Later instead of inventing a registry, report, human gate or mandatory discovery increment to justify it.
+Planner and implementer MUST NOT add speculative risk-reduction tasks, checks, tests, audits, gates or hardening. Do the requested work and required checks; **do not preempt the risk scorer.** The scorer directs additional treatments from the risk policy/register. Speculative work wastes resources, delays value and creates false confidence; remove it.
 
 Resolve substantive findings from all five critics and reduce above-appetite risk under the applicable policy. Reassess affected critics after material changes until the exact plan revision is coherent and within appetite. Record the reviewer identities, assessed revision, verdicts and evidence in the existing issue or plan artifact; no new report or template is required. A completed review with unresolved substantive findings is not a pass. Distinguish forecast controls from controls already verified. Plan assessment does not replace concrete code, commit, push, release, or operational reviews required by the project.
 
@@ -87,6 +89,8 @@ Perform reviews within existing authorization and policy. Replanning grants no w
 
 Execute the assessed **Now** increment through the applicable delivery workflow. Integrate independently safe changes promptly and preserve other owners' work. Keep unfinished functionality safely dormant where necessary.
 
+Before tests or deployment, try new integrations locally with real requests within existing authority. Inspect actual behaviour/responses; build from these, not guessed shapes or mocks. Never first experiment in production. Read [integration guidance](references/planning-details.md#new-integrations).
+
 For GitHub delivery, follow the [work checkpoints](references/github-coordination.md#reconcile-tracking-at-work-checkpoints), with regular discussion reads AND event checks. Reconcile each affected record and selected Project from saved state; read back changes.
 
 At each increment boundary:

package/skills-codex/outcome-led-planning/references/planning-details.md

@@ -12,7 +12,7 @@ Iterate each **initial or materially revised executable plan with five independe
 
 - **Architect:** checks structural choices, interfaces and existing decisions.
 - **JTBD:** checks intended beneficiaries and their desired outcomes.
-- **Risk:** checks action risk and whether proposed mitigation work is justified.
+- **Risk:** checks action risk and whether proposed mitigation work is justified. The risk scorer vetoes speculative work justified only by imagined failure or agent discomfort. Necessary treatments require an established risk or applicable requirement, credible impact/likelihood and proportionate reduction relative to cost and delay. A prior incident is not required; established preventive risks and required controls remain valid. An in-appetite action score does not establish necessity or priority. Remove unjustified work rather than invent a registry, report, human gate or discovery increment to justify it.
 - **Cognitive accessibility:** checks whether beneficiaries and contributors can understand the result, choices and next action without unnecessary cognitive work, jargon or human handoffs.
 - **Planning:** tests INVEST for Now, especially whether a smaller still-valuable increment exists, and outcome-directed dependencies and sequencing across Now/Next/Later. Future horizons remain provisional, without full Now detail. For initial or material plan reviews, inspect the authoritative plan in the chosen vehicle and actual affected tracking records, where used, against the assessed revision, including relevant task and selected Project setup evidence. Return concrete discrepancies; have repairs reflected in that same vehicle and rechecked before dependent work. Do not create a new artifact or tracking vehicle just for review. This is the existing planning review, not another five-critic cycle for routine updates.
 
@@ -30,3 +30,7 @@ Give the critic the acceptance criteria, current revision, actual execution resu
 The critic identifies concrete discrepancies or missing results. Withhold Done, repair within existing authority and obtain a recheck of the repaired results and saved state. If the independent reviewer or required results are unavailable, report the precise gap and withhold the completion claim. This review grants no wider access or operation authority.
 
 This is an increment-acceptance boundary. Completing an individual task or making a routine update does not trigger it or another five-critic cycle. Earlier review, coordination and prerequisite obligations still apply.
+
+## New integrations
+
+Make the first real request from the local development environment to the actual service or its official sandbox within existing authority. Inspect actual responses and behaviour before writing integration tests or deploying; use what you observe to shape implementation and tests. Reuse already-known real behaviour where applicable. Do not invent response shapes, qualify an integration solely against mocks, or learn its behaviour by iterating in production. If real access is unavailable, state that gap and continue useful independent work; mocks do not establish that the interaction works. No new report is required.

package/skills-codex/outcome-led-planning/references/project-tracking.md

@@ -40,6 +40,6 @@ A contributor chooses a useful bounded result in current assessed Now, announces
 
 Hold one contribution claim at a time. Finish, explicitly hand over or release it before claiming another. Coordination ownership does not reserve the work. Keep watched operations with their owners; useful non-conflicting help within that contribution is valid, but a wait does not justify repeated CI/provider operations or a second claim. Resolve overlap before edits, preserve prerequisites and evidence, and record claims/handoffs in the local plan or actual GitHub records according to the selected mode. Project fields apply only to a selected Project.
 
-Task creation, claims and routine status updates within the assessed plan do not restart all five reviews. Material plan changes still need the planning skill's five critics. The planner MUST NOT add speculative risk-mitigation tasks. The scorer derives necessary treatments from the applicable policy and register; explicit requirements and concrete observed risks remain respected. Remove busywork instead of inventing a registry, report, gate or discovery increment to justify it.
+Task creation, claims and routine status updates within the assessed plan do not restart all five reviews. Material plan changes still need the planning skill's five critics. Planner and implementer MUST NOT add speculative risk-reduction work or preempt the risk scorer. Do the requested work and required checks; the scorer directs additional treatments from the applicable policy/register. Remove speculative work rather than invent a registry, report, gate or discovery increment to justify it.
 
 Before asking a human to act, check existing authority. Explain plainly what they must decide and why; assess cognitive clarity with an available reviewer or an identified manual check. Do not invent approval requests for authorized agent work.