snow-flow 11.0.5 → 11.0.7

package/package.json

@@ -1,6 +1,6 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
-  "version": "11.0.5",
+  "version": "11.0.7",
   "name": "snow-flow",
   "description": "Snow-Flow - ServiceNow Multi-Agent Development Framework powered by AI",
   "license": "Elastic-2.0",

package/src/bundled-skills/blast-radius/SKILL.md

@@ -12,7 +12,7 @@ tools:
   - snow_blast_radius_table_configs
   - snow_blast_radius_artifact_dependencies
   - snow_blast_radius_field_references
-  - snow_blast_radius_reverse_dependencies
+  - snow_blast_radius_dependents
   - snow_code_search
 ---
 
@@ -28,7 +28,7 @@ Blast Radius provides configuration dependency analysis across a ServiceNow inst
 | `snow_blast_radius_table_configs` | All configs on a table | "What runs on the incident table?" |
 | `snow_blast_radius_field_references` | Reverse field lookup | "What touches incident.assignment_group?" |
 | `snow_blast_radius_artifact_dependencies` | Forward dependency analysis | "What does this business rule read/write?" |
-| `snow_blast_radius_reverse_dependencies` | Reverse artifact lookup | "What calls the IncidentUtils script include?" |
+| `snow_blast_radius_dependents` | Find what uses / calls an artifact (deep 3-phase scan, 100+ tables) | "What calls IncidentUtils?" / "Can I safely delete this business rule?" |
 | `snow_code_search` | Substring search across every script-bearing table (business rules, script includes, client scripts, widgets, scripted REST ops, UI actions, ACLs, notifications, UX scripts, …) | "Where is `IncidentUtils.resolve` referenced anywhere?" — use when reverse-dependency tools don't index what you need |
 
 ## Coverage
@@ -138,7 +138,7 @@ Returns fields read/written, tables queried, script includes called, and a compl
 Find what depends on a specific artifact (e.g., a script include):
 
 ```
-→ snow_blast_radius_reverse_dependencies(artifact_type: "script_include", artifact_identifier: "IncidentUtils")
+→ snow_blast_radius_dependents(artifact_type: "script_include", artifact_identifier: "IncidentUtils")
 ```
 
 ## Common Questions and Which Tool to Use
@@ -149,10 +149,10 @@ Find what depends on a specific artifact (e.g., a script include):
 | "What business rules run on incident?" | `snow_blast_radius_table_configs` |
 | "What touches the state field on change_request?" | `snow_blast_radius_field_references` |
 | "What does this business rule do?" | `snow_blast_radius_artifact_dependencies` |
-| "What uses the TaskUtils script include?" | `snow_blast_radius_reverse_dependencies` |
+| "What uses the TaskUtils script include?" | `snow_blast_radius_dependents` |
 | "Is it safe to remove this field?" | `snow_blast_radius_field_references` |
 | "How complex is this business rule?" | `snow_blast_radius_artifact_dependencies` |
-| "What's the blast radius of changing this script include?" | `snow_blast_radius_reverse_dependencies` |
+| "What's the blast radius of changing this script include?" | `snow_blast_radius_dependents` |
 
 ## Script Analysis Patterns
 

package/src/project/agents-template.txt

@@ -53,10 +53,10 @@ tool_search({ query: "...", enable: true })
 
 You do **NOT** call `activity_start`, `activity_update`, `activity_add_artifact`, or `activity_complete` manually. The harness watches tool calls and reports them for you:
 
-- Pick up a Jira/Azure DevOps issue (`jira_get_next_todo`, `jira_get_issue`, `azure_get_work_item`, …) → story is buffered.
-- Create or switch an Update Set via `snow_update_set_manage` → activity starts automatically, linked to that story if one was buffered.
-- Any `snow_create_*`, `snow_deploy_*`, `snow_update_*`, or `snow_edit_*` that returns a `sys_id` → artifact is attached automatically.
-- `snow_update_set_manage action=complete` → activity is completed automatically.
+- Pick up an issue from Jira / Azure DevOps via the relevant integration tool → story is buffered.
+- Create or switch an Update Set → activity starts automatically, linked to the buffered story if any.
+- Any successful create / deploy / update / edit of a ServiceNow artifact that returns a `sys_id` → artifact is attached automatically.
+- Complete an Update Set → activity is completed automatically.
 
 If the user wants an ad-hoc activity without a ticket, just create the Update Set and start working — the activity starts with `source: "manual"`.
 
@@ -135,7 +135,7 @@ ServiceNow server-side JavaScript runs on Mozilla Rhino, which only supports ES5
 ### Standard development (widgets, business rules, scoped apps, etc.)
 
 1. Decide application scope (scoped app `x_vendor_appname` or global) — see `Skill({ skill: "scoped-apps" })`
-2. Create Update Set via `snow_update_set_manage` (activity tracking starts automatically)
+2. Create an Update Set (activity tracking starts automatically)
 3. Develop the artifact(s) — load the relevant skill (`widget-coherence`, `business-rule-patterns`, `flow-designer`, etc.)
 4. Test and verify
 5. Complete the Update Set (activity is closed automatically)
@@ -180,6 +180,10 @@ Users want production-ready code. Real ServiceNow queries, real error handling,
 
 Never assume a table doesn't exist because it isn't "standard". Never declare a configuration broken without testing. Never claim an API isn't available without checking. Verify, then act.
 
+### 5. Deleting / refactoring without an impact scan
+
+Before you delete, rename, or change the signature of an artifact (script include, business rule, client script, UI action, UI policy, widget, table, etc.), run a dependency / blast-radius scan on it. The instance has dozens of places where references can hide — workflows, email notifications, catalog scripts, scheduled jobs, custom scripted tables — and reading five tables by hand will silently miss most of them. Discover the right tool via `tool_search`; never tell the user "it's safe to remove X" without seeing the full impact list.
+
 ---
 
 ## 🎓 FINAL CHECKLIST

package/src/servicenow/servicenow-mcp-unified/tools/blast-radius/index.ts

@@ -15,6 +15,6 @@ export {
   execute as snow_blast_radius_field_references_exec,
 } from "./snow_blast_radius_field_references.js"
 export {
-  toolDefinition as snow_blast_radius_reverse_dependencies_def,
-  execute as snow_blast_radius_reverse_dependencies_exec,
-} from "./snow_blast_radius_reverse_dependencies.js"
+  toolDefinition as snow_blast_radius_dependents_def,
+  execute as snow_blast_radius_dependents_exec,
+} from "./snow_blast_radius_dependents.js"

package/src/servicenow/servicenow-mcp-unified/tools/blast-radius/{snow_blast_radius_reverse_dependencies.ts → snow_blast_radius_dependents.ts}

@@ -1,17 +1,18 @@
 /**
- * snow_blast_radius_reverse_dependencies - Find what depends on an artifact
+ * snow_blast_radius_dependents - Find every artifact that uses a given one
  *
- * Reverse dependency analysis using a 3-phase deep search:
+ * The go-to "what will break if I touch this?" tool. Uses a 3-phase deep
+ * search so it never silently misses a caller:
  *   1. Curated catalog (25+ artifact types from ARTIFACT_SPECS)
  *   2. sys_dictionary discovery (every table with script-type fields)
  *   3. Long-tail batch search (concurrency-limited)
  *
- * Covers the common-case tool-use: "I'm about to refactor / remove this
- * script_include — what else will break?" Looks in business rules, client
- * scripts, UI actions + policies, script includes, workflows, flow actions,
- * email notifications, catalog client scripts, scheduled jobs, transform
- * scripts, processors, ACLs, assessment metrics, and any custom script-
- * bearing table the customer added (discovered dynamically).
+ * Looks in business rules, client scripts, UI actions + policies, script
+ * includes, workflows, flow actions, email notifications, inbound email
+ * actions, catalog client scripts / UI policies, scheduled jobs, fix
+ * scripts, transform scripts, processors, ACLs, metric definitions, ATF
+ * steps, and any custom script-bearing table the customer has added
+ * (discovered dynamically via sys_dictionary).
  */
 
 import { MCPToolDefinition, ServiceNowContext, ToolResult } from "../../shared/types.js"
@@ -21,35 +22,58 @@ import { ARTIFACT_TABLE_MAP } from "./shared/metadata-tables.js"
 import { searchDependents, type SearchPattern } from "./shared/deep-search.js"
 
 export const toolDefinition: MCPToolDefinition = {
-  name: "snow_blast_radius_reverse_dependencies",
-  description: `Find what depends on a given artifact (reverse dependency analysis).
+  name: "snow_blast_radius_dependents",
+  description: `Find every artifact on the instance that USES / CALLS / DEPENDS ON a given artifact. Answers: "what breaks if I change or delete this?"
 
-📋 USE THIS TO:
-- Find all artifacts that call a script include
-- See what references a specific business rule, UI action, or widget
-- Assess the blast radius of changing or removing an artifact
-- Identify cross-scope dependencies
+🛑 CALL THIS BEFORE:
+- Deleting a script include, business rule, client script, UI action, UI policy, or widget
+- Refactoring the name / api_name / signature of any script include
+- Removing a table
+- Promoting a breaking change to another instance
+- Telling the user "it's safe to remove X"
 
-🔍 EXAMPLE: "What calls the IncidentUtils script include?"
+The output is the impact list — every caller, every referrer, in every
+scope. Do not rely on reading 5 tables by hand; this tool scans 100+
+tables including workflows, notifications, email actions, catalog
+scripts, scheduled jobs, and custom scripted tables.
+
+🔍 TRIGGER PHRASES (agent should invoke this):
+- "what uses X" / "what calls X" / "what references X"
+- "wat gebruikt X" / "wat roept X aan" / "wat heeft X nodig"
+- "can I delete X" / "is it safe to remove X" / "kan ik X verwijderen"
+- "impact analysis" / "blast radius" / "dependency audit"
+- User asks to refactor, rename, or remove a named artifact
+
+🔍 EXAMPLES:
+- "What calls the IncidentUtils script include?"
+- "Is it safe to delete this business rule?"
+- "Show me everything referencing the incident table"
 
 📊 RETURNS:
-- List of dependents with type, name, scope, and — importantly — the
-  source table + field where the reference was found (so you can
-  distinguish a business-rule hit from a workflow hit or a custom
-  scripted table hit).
-- Search stats showing how many tables were scanned across three phases.
+- dependents[]: each with type, name, scope, source_table, source_field,
+  cross_scope flag. source_table/source_field let you distinguish a
+  workflow-condition hit from a business-rule hit — critical for triage.
+- summary: by_type + by_table counts + cross_scope count + truncation flag.
+- search_stats: per-phase timing + tables scanned + cache hit, so you
+  know the scan was thorough (expect 100+ tables on a typical instance).
 
-🔎 HOW IT SEARCHES:
-- Phase 1: 25+ curated artifact types (business rules, workflows,
-  email notifications, catalog scripts, transform scripts, processors,
-  ACLs, metric definitions, inbound email actions, …)
-- Phase 2: sys_dictionary discovery → every table with script-type fields
+🔎 HOW IT SEARCHES (why you can trust the "none found"):
+- Phase 1: 25+ curated artifact types (human-attributed labels)
+- Phase 2: sys_dictionary discovery — every table with script-type fields
 - Phase 3: concurrency-limited batch query over the long tail
-
-This is deep-only by design. A typical run covers 100+ tables.`,
+Deep-only by design. Takes 2-10s depending on instance size.`,
   category: "blast-radius",
   subcategory: "dependency-analysis",
-  use_cases: ["impact-analysis", "dependency-audit", "refactoring"],
+  use_cases: [
+    "impact-analysis",
+    "dependency-audit",
+    "refactoring",
+    "safe-delete-check",
+    "find-callers",
+    "find-references",
+    "breaking-change-review",
+    "blast-radius",
+  ],
   complexity: "advanced",
   frequency: "medium",
   permission: "read",