@salesforce/afv-skills 1.55.0 → 1.56.0

package/skills/service-itsm-agentic-setup-cmdb-coordinate/SKILL.md

@@ -38,7 +38,7 @@ CMDB is gated by a 4-layer stack. Every CMDB Connect API checks `orgHasCMDBEnabl
 ```text
 Layer 0  Org SKU / license      Org perm ITSrvcsCnfgMgmnt must already be granted (edition/
                                 license/template). NOT settable by any API — verify only.
-Layer 1  Tenant provisioning    ITOM tenant must reach status PROVISIONED (async).
+Layer 1  Tenant provisioning    CMDB tenant must reach status PROVISIONED (async).
 Layer 2  Feature enable         Enable feature service-cloud-itsm-cmdb-integration. This is
                                 what internally sets CMDBEnabled and lifts the 403 gate.
 Layer 3  User access            Assign the PSL + CMDB permission sets to the user(s).
@@ -85,7 +85,7 @@ CMDB is enabled in ordered layers. Each must succeed before the next:
 | #   | Layer                    | What it does                                                 | Status  |
 | --- | ------------------------ | ------------------------------------------------------------ | ------- |
 | 0   | License check            | Confirm this org is licensed for CMDB (set by edition/license — can't be turned on) | Pending |
-| 1–2 | Provision & enable CMDB  | Set up the CMDB service, then turn on the CMDB feature so it's available to use | Pending |
+| 1–2 | Provision & enable CMDB  | Set up the CMDB tenant, then turn on the CMDB feature so it's available to use | Pending |
 | 3   | Assign user access       | Grant CMDB access to the chosen users                        | Pending |
 | 4   | Install content bundle   | Install the CMDB Foundation (base) content                   | Pending |
 | 5   | Enable Asset Discovery   | Turn on asset discovery and grant Discovery page access (final step — needs the steps above done first) | Pending |

package/skills/service-itsm-agentic-setup-cmdb-coordinate/examples/output-templates.md

@@ -13,7 +13,7 @@ Here are the features available for CMDB. Select one or more to configure:
 ┌───┬───────────────────────────────┬──────────────────────────────────────────────────┬──────────┐
 │ # │ Feature                       │ Description                                      │ Status   │
 ├───┼───────────────────────────────┼──────────────────────────────────────────────────┼──────────┤
-│ 1 │ CMDB feature enablement       │ Verify org SKU, provision the ITOM tenant, and   │ Not done │
+│ 1 │ CMDB feature enablement       │ Verify org SKU, provision the CMDB tenant, and   │ Not done │
 │   │                               │ turn on the service-cloud-cmdb feature           │          │
 │ 2 │ CMDB Foundation bundle        │ Install the CMDB Foundation base content bundle  │ Not done │
 │   │                               │ (CI types, layouts, sample records)              │          │

package/skills/service-itsm-agentic-setup-cmdb-discovery-configure/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: service-itsm-agentic-setup-cmdb-discovery-configure
-description: "Enable CMDB Asset Discovery in Service Cloud ITSM against a production or sandbox org by turning on the service-cloud-itsm-discovery-integration feature, then grant a user the Discovery page by assigning the IT Service Discovery Manager permission set and its license — the final CMDB setup layer, run after the CMDB feature, user access, and content bundle are in place. Use when the user asks to enable CMDB discovery, turn on asset discovery, enable service-cloud-itsm-discovery-integration, grant Discovery page access, or assign the Discovery Manager permission set. Triggers on: enable CMDB discovery, turn on asset discovery, service-cloud-itsm-discovery-integration, assign Discovery Manager access, CMDB discovery not enabled. DO NOT TRIGGER when: the user wants to enable the base CMDB feature, provision the ITOM tenant, assign the four CMDB Configuration-Item permission sets, install a CMDB content bundle, or work with CMDB records directly — those are earlier CMDB layers."
+description: "Enable CMDB Asset Discovery in Service Cloud ITSM against a production or sandbox org by turning on the service-cloud-itsm-discovery-integration feature, then grant a user the Discovery page by assigning the IT Service Discovery Manager permission set and its license — the final CMDB setup layer, run after the CMDB feature, user access, and content bundle are in place. Use when the user asks to enable CMDB discovery, turn on asset discovery, enable service-cloud-itsm-discovery-integration, grant Discovery page access, or assign the Discovery Manager permission set. Triggers on: enable CMDB discovery, turn on asset discovery, service-cloud-itsm-discovery-integration, assign Discovery Manager access, CMDB discovery not enabled. DO NOT TRIGGER when: the user wants to enable the base CMDB feature, provision the CMDB tenant, assign the four CMDB Configuration-Item permission sets, install a CMDB content bundle, or work with CMDB records directly — those are earlier CMDB layers."
 metadata:
-  version: "1.0"
+  version: "1.1"
   domains: ["Service"]
   minApiVersion: "67.0"
   relatedSkills:
@@ -45,7 +45,7 @@ CMDB is enabled in ordered layers, each gated on the prior one:
 
 ```text
 Layer 0  Org SKU / license      Org perm ITSrvcsCnfgMgmnt (verify only — no API can set it).
-Layer 1  Tenant provisioning    ITOM tenant must reach status PROVISIONED (async).
+Layer 1  Tenant provisioning    CMDB tenant must reach status PROVISIONED (async).
 Layer 2  CMDB feature           Enable service-cloud-itsm-cmdb-integration (lifts the 403 gate).
 Layer 3  User access            Assign the PSL + CMDB permission sets to the user(s).
 Layer 4  Content bundle         Install the CMDB Foundation (base) content bundle.
@@ -53,10 +53,14 @@ Layer 5  Asset Discovery        Enable service-cloud-itsm-discovery-integration
                                 IT Service Discovery Manager permission set  ← THIS SKILL
 ```
 
-Discovery is enabled **last**: it builds on the base CMDB feature and depends on the earlier layers
-being complete. The pre-check step below (`enableBlockedReasons`) is the authoritative signal that
-the prerequisites are met — if the base CMDB feature is not yet enabled, discovery cannot be enabled
-and the org reports a blocking reason rather than turning it on.
+Discovery is *recommended* **last**, but it does **not** require the base CMDB feature to already be
+on: the enable **cascade-enables** its dependency (the base CMDB feature) as part of turning Discovery
+on, provided that feature's own prerequisites (e.g. a provisioned CMDB tenant) are met. The
+`enableBlockedReasons` array in the pre-check is the authoritative blocker signal — a base CMDB feature
+that is merely `NOT_ENABLED` appears under `dependencyStatuses` with **empty** `enableBlockedReasons`
+and is **not** a blocker. So never tell the user a direct enable "will error out"; tell them it will
+turn on CMDB first, then Discovery. Only a **non-empty** `enableBlockedReasons` (e.g. tenant not
+provisioned) is a genuine unmet prerequisite that stops the enable.
 
 > **Enabling the feature lifts the org-level gate; the Discovery permission set gives a user the
 > Discovery page.** This skill does **both**: it turns Discovery on for the org (Step 2) and then
@@ -73,7 +77,7 @@ and the org reports a blocking reason rather than turning it on.
 - **In scope**: pre-checking, enabling, and verifying the `service-cloud-itsm-discovery-integration`
   feature; and — as a follow-up — assigning the **IT Service Discovery Manager** permission set (and its
   permission-set license) to the target user so they can access the Discovery page.
-- **Out of scope**: enabling the base CMDB feature / provisioning the tenant (Layer 2 —
+- **Out of scope**: enabling the base CMDB feature / provisioning the CMDB tenant (Layer 2 —
   `service-itsm-agentic-setup-cmdb-configure`), assigning the four Configuration-Item permission sets
   for CMDB *data* access (Layer 3 — `service-itsm-agentic-setup-cmdb-access-assign`), bundle
   installation (Layer 4 — `service-itsm-agentic-setup-cmdb-bundle-deploy`), CMDB record CRUD, Service
@@ -139,11 +143,16 @@ dispatch_readonly({ "url": "/services/data/v67.0/connect/setup/discovery/feature
 
 - `status == ENABLED` → feature already on; skip to verification (Step 3), then proceed to the access
   follow-up (Steps 4–7).
-- `status == NOT_ENABLED` with `enableBlockedReasons: []` → clear to enable (Step 2).
+- `status == NOT_ENABLED` with `enableBlockedReasons: []` → clear to enable (Step 2). **Before
+  confirming, inspect `dependencyStatuses`:** if the base CMDB feature
+  (`service-cloud-itsm-cmdb-integration`) is listed there as `NOT_ENABLED`, that is **not** a blocker —
+  enabling Discovery will **cascade-enable the base CMDB feature first, then Discovery**. Tell the user
+  exactly that ("this will turn on CMDB first, then Asset Discovery"). Do **not** warn that it "will
+  error out" or offer to "let it report the dependency error" — neither happens.
 - `enableBlockedReasons` non-empty → **STOP** and relay each reason to the user in plain language.
-  These are prerequisites the org still needs — most commonly the base CMDB feature is not yet
-  enabled. Point the user to the earlier CMDB setup skills (see "Common failures") and do **not**
-  attempt the enable.
+  These are genuine unmet prerequisites the org still needs (e.g. the CMDB tenant is not provisioned,
+  so the base feature cannot be enabled). Point the user to the earlier CMDB setup skills (see "Common
+  failures") and do **not** attempt the enable.
 - `403 FUNCTIONALITY_NOT_ENABLED` on this GET → the base CMDB gate itself is still closed; the org
   needs `service-itsm-agentic-setup-cmdb-configure` first. Stop and route the user there.
 
@@ -232,7 +241,7 @@ Re-run the two Step 5 assignment queries. The user has Discovery page access onl
 
 | Constraint | Rationale |
 |-----------|-----------|
-| Run only after the base CMDB feature is enabled | Discovery is the final layer and depends on Layers 0–4; the pre-check `enableBlockedReasons` enforces this |
+| Running after the base CMDB feature is recommended, not required | Discovery depends on the base CMDB feature, but the enable **cascade-enables** it when it is only `NOT_ENABLED` (empty `enableBlockedReasons`); message the cascade — never claim a direct enable "will error out". The pre-check `enableBlockedReasons` is what actually gates the enable |
 | Read the pre-check before enabling; verify with a read after enabling | The feature is stateful; the POST response can lag the real state |
 | Do not attempt the enable when `enableBlockedReasons` is non-empty | Those are unmet prerequisites — relay them and route the user to the earlier CMDB skills |
 | Always follow the enable with the Discovery-Manager assignment | The feature being on does not give any user the Discovery page; the permission set is what grants page access |
@@ -289,7 +298,8 @@ into what it means ("CMDB isn't fully set up yet"), rather than echoing the code
 
 | Symptom | Likely cause | What to tell the user |
 |---------|--------------|-----------------------|
-| Pre-check `enableBlockedReasons` non-empty | An earlier CMDB layer is incomplete (most often the base CMDB feature) | Relay each reason; finish CMDB setup first — run `service-itsm-agentic-setup-cmdb-configure` (base feature), then `-access-assign` (user access) and `-bundle-deploy` (content bundle), then retry discovery |
+| Pre-check `enableBlockedReasons` non-empty | A deeper prerequisite is genuinely unmet (e.g. the CMDB tenant is not provisioned — note a base CMDB feature that is only `NOT_ENABLED` does **not** populate this array; it cascade-enables) | Relay each reason; finish CMDB setup first — run `service-itsm-agentic-setup-cmdb-configure` (provision tenant + base feature), then `-access-assign` (user access) and `-bundle-deploy` (content bundle), then retry discovery |
+| Base CMDB feature was `NOT_ENABLED` before the discovery enable, and enabling discovery turned it on too | Expected — the discovery enable **cascade-enables** its base CMDB dependency; this is **not** a failure | Tell the user upfront (before enabling) that this will turn on CMDB first, then Discovery; never warn it "will error out" |
 | `403 FUNCTIONALITY_NOT_ENABLED` on the status GET | Base CMDB gate still closed (CMDB feature not enabled) | Not a discovery failure — enable the base CMDB feature first with `service-itsm-agentic-setup-cmdb-configure`, then retry |
 | Enable blocked (`enableBlockedReasons` non-empty) after a partial setup | Missing dependency the org still needs | Relay each reason; resolve those prerequisites, then retry |
 | Enable returned success but verification GET is not `ENABLED` | State lag or a downstream issue | Re-run the verification GET after a short wait; if it persists, treat it as not enabled and investigate |
@@ -305,7 +315,7 @@ into what it means ("CMDB isn't fully set up yet"), rather than echoing the code
 
 | When | Skill |
 |------|-------|
-| The base CMDB feature is not enabled yet (Discovery pre-check is blocked) | `service-itsm-agentic-setup-cmdb-configure` (Layers 0–2 — enable the base feature first, then return here) |
+| The pre-check reports a genuine blocker (`enableBlockedReasons` non-empty — e.g. the CMDB tenant is not provisioned) | `service-itsm-agentic-setup-cmdb-configure` (Layers 0–2 — provision the tenant and enable the base feature, then return here). A base feature that is only `NOT_ENABLED` is **not** a blocker — Discovery cascade-enables it |
 | A user needs the underlying CMDB **data** roles (Configuration Item Reader / Owner / Type Reader / Type Manager) | `service-itsm-agentic-setup-cmdb-access-assign` (Layer 3 — CMDB data access, distinct from Discovery page access) |
 
 ---

package/skills/service-itsm-agentic-setup-employee-agent-configure/SKILL.md

@@ -2,7 +2,7 @@
 name: service-itsm-agentic-setup-employee-agent-configure
 description: "Create and activate an IT Service Employee agent as a Next-Gen Authoring (NGA) native agent from an ITSM Employee agent template's Agent Script, via the Salesforce CLI (sf): read the template, check idempotency, create the NGA bundle then publish and activate, verify live. Defaults to the broad IT Service Employee template; when the user names a specialized Employee template (Password Manager Assistance, Certificate Management, Onboarding, Hardware Request, and ~47 others catalogued in references/specialized-templates.md — all under the `svc_emp_intelligence__` namespace), pins that one instead. Idempotent per developer name. TRIGGER when the user asks to create/set up/provision/activate the Employee agent, the IT Service Employee agent, or a specialized Employee agent (password manager, certificate, onboarding, hardware request, etc.). DO NOT TRIGGER: prerequisite checks (service-itsm-agentic-setup-agentforce-studio-validate), CMDB CRUD, Fulfiller setup (service-itsm-agentic-setup-fulfiller-agent-configure)."
 metadata:
-  version: "2.5"
+  version: "2.8"
   domains: ["Service", "Agentforce"]
   minApiVersion: "67.0"
   relatedSkills:
@@ -107,7 +107,8 @@ Substitute `<alias>` with the collected target org and `<developerName>` / `<lab
 6. **Phase 5 — Publish.** `POST /nextgen-authoring/bundle-versions/<bundleVersionId>/publish --body '{}'` (empty body required). Success: `{ lastPublishedOn, publishedBotId, publishedBotVersionId }` — this call creates the underlying `BotDefinition`/`BotVersion`. Any error ⇒ surface verbatim; never activate an unpublished version.
 7. **Phase 6 — Activate.** `POST /nextgen-authoring/bundle-versions/<bundleVersionId>/activate --body '{}'`. Success returns an **empty body** — check exit code, do not parse a payload.
 8. **Phase 7 — Verify.** SOQL `BotDefinition WHERE Id='<id>'` (+ `BotVersions` subquery) and classify — `<id>` is the create path's `publishedBotId` (captured from Phase 5) or, on the ALREADY-CREATED / reactivation path, the **live matched Id the Phase-2 classifier returned** (its `botDefinitionId`/`agentId` output — the actual `BotDefinition.Id` of the matched record), **not** the Phase-1 template `botDefinitionId` (which is null on a `matchedBy:"developerName"` fallback hit → the verify would run `WHERE Id=''` and falsely report failure after a successful skip/activation). Confirm `exists:true, count:1, latestVersionStatus:"Active"`. Any discrepancy ⇒ report verbatim, do not fabricate success.
-9. **Phase 8 — Aggregate verdict.** Emit CREATED / ALREADY-CREATED / ACTIVATED / FAILED (ACTIVATED on the Phase-2b path) + `BotDefinition` Id / bundle `id` by re-invoking `render-report.mjs` — the single source of report text. If `${outputDir}` was provided, overwrite `${outputDir}/report.md`; otherwise emit stdout as the turn-side report.
+9. **Phase 8 — Aggregate verdict.** Emit CREATED / ALREADY-CREATED / ACTIVATED / FAILED (ACTIVATED on the Phase-2b path) by re-invoking `render-report.mjs` — the single source of report text. **Never surface internal record IDs** — the bundle version `id`, `publishedBotId`/`BotDefinition`, or `BotVersion` — in the verdict, chat narration, or the report; they are captured only to drive the publish/activate/verify calls and mean nothing to the admin. Report by status/name only ("created and activated"), never "Bundle created (version id …)" / "Published (BotDefinition …)". If `${outputDir}` was provided, overwrite `${outputDir}/report.md`; otherwise emit stdout as the turn-side report.
+10. **Phase 9 — Runtime-access hand-off (REQUIRED on a live-agent verdict).** When the Phase-8 verdict is `CREATED`, `ALREADY-CREATED`, or `ACTIVATED` (a live agent now exists), raise an `AskUserQuestion` — the same enforced hand-off pattern as the Phase-1 prerequisite and Phase-2b reactivation offers — asking whether to set up the agent's **runtime access** now: _"The agent is live, but its actions call platform features (Prompt Templates, Data Cloud, Unified Catalog) a user can't run until access is granted, so it fails when opened. Set up runtime access now?"_. On **Yes**, delegate to `service-itsm-agentic-setup-agent-runtime-access-assign` (it runs its own target-user selection + confirm-to-write gate). On **No**, stop — the report's "set up access" next-step line stands as the record. Do **NOT** raise this on `PENDING CONFIRMATION`, `DECLINED`, or `FAILED` (no live agent to grant access to). This is an enforced `AskUserQuestion`, not report prose — `render-report.mjs` still emits its plain-language "set up access" line unchanged; the question is what guarantees the offer is actually made every time.
 
 ---
 
@@ -123,7 +124,8 @@ Substitute `<alias>` with the collected target org and `<developerName>` / `<lab
 | Enumerate `BotDefinition` **with the `BotVersions` subquery**; skip create when Active; offer Phase-2b reactivation when Inactive — never silent skip, never duplicate create | Subquery is what distinguishes Active/Inactive; the server rejects a duplicate `DeveloperName` at publish (unique-constraint → bundle cleanup) but not the pre-provisioned broad agent, so this read is what turns a repeat into a graceful skip instead of a hard error |
 | **REQUIRED confirm-to-write checkpoint** before create sequence or reactivation call | Both change live org state — explicit user approval required |
 | On `hasAccess=false` / `403 FUNCTIONALITY_NOT_ENABLED`, offer the readiness hand-off — never enable features here; never call legacy `/connect/service-itsm/createAgent` | Enablement is a Setup-UI/admin action; `createAgent` produces a Setup-page bot with an external-link icon (wrong kind of agent for this skill) |
-| Report exact CLI response text on any error | Enables support to diagnose failures |
+| **Never surface internal record IDs** — the bundle version `id` (`1bZ…`), `publishedBotId`/`BotDefinition` (`0Xx…`), `BotVersion` (`0Xv…`) — in chat narration, the confirm-to-write step, or the report; report progress and verdict by status/name only | These IDs are captured solely to drive the publish → activate → verify → verify-read calls; they are meaningless to an admin going through setup and only add noise. `render-report.mjs` renders status-only rows and defensively scrubs any ID; the model must likewise not echo them (never "Bundle created (version id 1bZ…)" / "Published (BotDefinition 0Xx…)") |
+| Report exact CLI response text on any error | Enables support to diagnose failures — this is the one place a raw ID may appear, inside a verbatim error the user must relay to support |
 
 ---
 
@@ -137,7 +139,8 @@ Substitute `<alias>` with the collected target org and `<developerName>` / `<lab
 - [ ] Bundle body built by `build-create-body.mjs`, POSTed via `--body @<file>` with the collected `developerName`/`label`; or write correctly skipped.
 - [ ] Same `bundleVersionId` (response `id`) used for publish + activate; reactivation used `POST /connect/bot-versions/<id>/activation`; legacy `createAgent` never called.
 - [ ] Phase-7 verify confirmed `BotDefinition` present + latest version Active.
-- [ ] Access token never extracted; final verdict + `BotDefinition`/bundle Id reported.
+- [ ] On a live-agent verdict (CREATED / ALREADY-CREATED / ACTIVATED), the Phase-9 runtime-access hand-off was raised as an `AskUserQuestion` (delegating to `service-itsm-agentic-setup-agent-runtime-access-assign` on "yes"); NOT raised on PENDING CONFIRMATION / DECLINED / FAILED.
+- [ ] Access token never extracted; final verdict reported with **no internal record IDs** (bundle version `id`, `publishedBotId`/`BotDefinition`, `BotVersion`) surfaced in chat, the confirm-to-write step, or the report — status/name only (raw IDs allowed only inside a verbatim error).
 
 ---
 
@@ -145,7 +148,7 @@ Substitute `<alias>` with the collected target org and `<developerName>` / `<lab
 
 The report layout is generated deterministically by `scripts/render-report.mjs` — the single source of report text for both the chat turn and the harness's `${outputDir}/report.md`. Never hand-compose the layout in prose (A9); always shell out to the helper. Full rendered shape, report-state JSON schema, and checkpoint-write rules live in `references/report-format.md`.
 
-Terminal verdicts: `CREATED | ALREADY-CREATED | ACTIVATED | PENDING CONFIRMATION | DECLINED | FAILED`. When `${outputDir}` is set, write at Phase 2, Phase 6 (or Phase 2b), and Phase 8 — each write overwrites the same file. Skip these writes in interactive/chat surfaces.
+Terminal verdicts: `CREATED | ALREADY-CREATED | ACTIVATED | PENDING CONFIRMATION | DECLINED | FAILED`. When `${outputDir}` is set, write at Phase 2, Phase 6 (or Phase 2b), and Phase 8 — each write overwrites the same file. Skip these writes in interactive/chat surfaces. The Phase-9 runtime-access hand-off fires after the Phase-8 report on a live-agent verdict; it does not change the verdict or re-render the report.
 
 ---
 

package/skills/service-itsm-agentic-setup-employee-agent-configure/references/report-format.md

@@ -23,8 +23,8 @@ Stage 2 — install & activate the agent from its template:
 | Preflight | Studio hasAccess=<true/false/cannot-confirm>; template agentScript present=<yes/no>; verdict=<READY/NOT-READY/CANNOT-CONFIRM> |
 | Enumerate | target agent exists before write=<yes/no>; latest version status=<Active/Inactive/n/a>; verdict=<exists:...> |
 | Confirm-to-write | user-confirmed=<true/false/pending> |
-| Create bundle | <bundleVersionId=... / ALREADY-CREATED / skipped (reactivation path) / pending confirmation / FAILED> |
-| Publish | <publishedBotId=... / skipped / pending confirmation / FAILED> |
+| Create bundle | <succeeded (created) / ALREADY-CREATED / skipped (reactivation path) / pending confirmation / FAILED> |
+| Publish | <succeeded / skipped / pending confirmation / FAILED> |
 | Activate | <succeeded (created) / succeeded (reactivated existing) / skipped / pending confirmation / FAILED> |
 | Verify | <BotDefinition present: yes/no; latest version Active: yes/no / skipped> |
 
@@ -55,6 +55,8 @@ The caller writes `${SCRATCH_DIR}/report-state.json` and passes it as the first
 
 The helper enforces a validated verdict set and picks the `Next steps` line from the verdict, so the file never drifts from that shape.
 
+**No internal record IDs in the report.** The stage rows carry status only — the bundle version `id`, `publishedBotId`/`BotDefinition`, and `BotVersion` are captured solely to drive the publish/activate/verify calls and are meaningless to an admin, so they are never displayed. The helper renders status-only rows and defensively scrubs any ID that a caller passes inside a stage-status string, so a report can never leak one regardless of the phase-state input. Do not add IDs back in turn-side narration either (never "Bundle created (version id …)" / "Published (BotDefinition …)").
+
 ## Checkpoint writes (harness / non-interactive runs)
 
 When `${outputDir}` is provided (via the harness's generated-file location directive), write the helper output to `${outputDir}/report.md` at three checkpoints so it always exists even when a run parks at a confirmation gate:

package/skills/service-itsm-agentic-setup-employee-agent-configure/references/workflow-detail.md

@@ -162,7 +162,7 @@ Confirm `exists:true` with `count:1`, and — on the create or reactivation path
 
 ## Phase 8 — Aggregate verdict
 
-Report the verdict (CREATED / ALREADY-CREATED / ACTIVATED / FAILED) and the resulting `BotDefinition` Id / bundle `id`. Use **ACTIVATED** when Phase 2b's reactivation path was taken (existing agent found inactive, activated instead of creating new). Emit the final report by re-invoking `scripts/render-report.mjs` with the fully populated phase-state JSON. If `${outputDir}` was provided, overwrite `${outputDir}/report.md`; otherwise emit the helper's stdout as the turn-side report.
+Report the verdict (CREATED / ALREADY-CREATED / ACTIVATED / FAILED). Use **ACTIVATED** when Phase 2b's reactivation path was taken (existing agent found inactive, activated instead of creating new). **Do not surface internal record IDs** (the bundle version `id`, `publishedBotId`/`BotDefinition`, `BotVersion`) in the verdict, report, or chat narration — they drive the publish/activate/verify calls but mean nothing to the admin; report by status/name only. Emit the final report by re-invoking `scripts/render-report.mjs` with the fully populated phase-state JSON (it renders status-only rows and scrubs any stray ID). If `${outputDir}` was provided, overwrite `${outputDir}/report.md`; otherwise emit the helper's stdout as the turn-side report.
 
 ```bash
 node "<skill_dir>/scripts/render-report.mjs" ${SCRATCH_DIR}/report-state.json "${outputDir}/report.md"

package/skills/service-itsm-agentic-setup-employee-agent-configure/scripts/render-report.mjs

@@ -115,22 +115,28 @@ const gatedFallback = isPending
   : isFailed ? 'skipped'
   : 'pending';
 
-const bundleVersionId = field(state.bundleVersionId, '');
-const bundleVersionIdSuffix = bundleVersionId ? ` bundleVersionId=${bundleVersionId}` : '';
-const onBundleVersionId = bundleVersionId ? ` on bundleVersionId=${bundleVersionId}` : '';
-
-function withCreateSuffix(base) {
-  if (base === 'pending' || base.startsWith('skipped') || base === 'pending confirmation') return base;
-  return `${base}${bundleVersionIdSuffix}`;
-}
-function withPublishActivateSuffix(base) {
-  if (base === 'pending' || base.startsWith('skipped') || base === 'pending confirmation') return base;
-  return `${base}${onBundleVersionId}`;
+// Internal record IDs (bundleVersionId `1bZ…`, BotDefinition `0Xx…`, BotVersion
+// `0Xv…`) are meaningless to an admin and must never appear in the user-facing
+// report — they are captured only to drive the publish/activate/verify calls.
+// The stage rows carry status only; `scrubInternalIds` strips any ID a caller
+// passed inside a status string, so the "single source of report text" stays
+// ID-free regardless of input (belt-and-braces, like `cell` below).
+function scrubInternalIds(s) {
+  return String(s)
+    // "bundleVersionId=1bZ…", "on bundleVersionId 1bZ…", "publishedBotId=0Xx…", "BotDefinition 0Xx…", …
+    .replace(/\s*\b(?:on\s+)?(?:bundleVersionId|bundleId|publishedBotId|publishedBotVersionId|botDefinitionId|BotDefinition|BotVersion|agentId)\b\s*[:=]?\s*[a-zA-Z0-9]{15,18}\b/g, '')
+    // any remaining bare Salesforce-ID token (15/18 alphanumeric, must contain a digit)
+    .replace(/\s*\b(?=[a-zA-Z0-9]*[0-9])[a-zA-Z0-9]{15}(?:[a-zA-Z0-9]{3})?\b/g, '')
+    // tidy separators orphaned by the removals above
+    .replace(/\s*[;,]\s*(?=[;,])/g, '')
+    .replace(/[;,\s]+$/g, '')
+    .replace(/\s{2,}/g, ' ')
+    .trim();
 }
 
-const createBundle = withCreateSuffix(field(state.createBundle, gatedFallback));
-const publish = withPublishActivateSuffix(field(state.publish, gatedFallback));
-const activate = withPublishActivateSuffix(field(state.activate, gatedFallback));
+const createBundle = scrubInternalIds(field(state.createBundle, gatedFallback));
+const publish = scrubInternalIds(field(state.publish, gatedFallback));
+const activate = scrubInternalIds(field(state.activate, gatedFallback));
 const verifyFallback = isDeclined || isPending || isFailed
   ? 'skipped'
   : isAlready
@@ -145,8 +151,15 @@ if (
 ) {
   verify = `${verify}; exists:true; latestVersionStatus=Active`;
 }
-
-const reason = String(state.reason ?? '').trim();
+verify = scrubInternalIds(verify);
+
+// `reason` is the FAILED/DECLINED-path field most likely to carry a raw upstream
+// platform error (e.g. an INSUFFICIENT_ACCESS message quoting a BotDefinitionId),
+// so it gets the same scrub as the stage rows above — an internal record ID must
+// never reach the user-facing report/chat (CWE-200/209). Scrubbing here, before
+// NEXT_STEPS, also keeps the FAILED next-step's `reason ? …` branch consistent
+// with what is actually shown in the Reason line.
+const reason = scrubInternalIds(String(state.reason ?? '').trim());
 
 // The "set up access" next step below is the handoff to the
 // `service-itsm-agentic-setup-agent-runtime-access-assign` skill (declared in

package/skills/service-itsm-agentic-setup-fulfiller-agent-configure/SKILL.md

@@ -2,7 +2,7 @@
 name: service-itsm-agentic-setup-fulfiller-agent-configure
 description: "Create and activate the IT Service Fulfiller agent as a Next-Gen Authoring (NGA) native agent from the shipped ITSM Fulfiller template's Agent Script, using the Salesforce CLI (sf): read the template, check idempotency, create the NGA bundle then publish and activate it, then verify it is live. Idempotent per developer name. The Fulfiller agent is the IT-technician-facing assistant for incident triage, case summarization, field updates, and related-record automations. Use when asked to create the Fulfiller agent, set up the IT Service Fulfiller agent, provision the fulfiller assistant, or activate the Fulfiller agent. Triggers: create fulfiller agent, set up fulfiller agent, provision fulfiller agent, activate fulfiller agent. DO NOT TRIGGER: checking org prerequisites (service-itsm-agentic-setup-agentforce-studio-validate), or CMDB CRUD."
 metadata:
-  version: "3.7"
+  version: "3.10"
   domains: ["Service", "Agentforce"]
   minApiVersion: "67.0"
   relatedSkills:
@@ -136,7 +136,8 @@ Substitute `<alias>` with the collected target org and `<developerName>` / `<lab
 7. **Phase 5 — Publish.** `POST /nextgen-authoring/bundle-versions/<bundleVersionId>/publish --body '{}'` (empty body required). Success: `{ lastPublishedOn, publishedBotId, publishedBotVersionId }` — this call creates the underlying `BotDefinition`/`BotVersion`. Any error ⇒ surface verbatim; never activate an unpublished version.
 8. **Phase 6 — Activate.** `POST /nextgen-authoring/bundle-versions/<bundleVersionId>/activate --body '{}'` captured to `${SCRATCH_DIR}/activate-response.json`, then `node "<skill_dir>/scripts/classify-activate-result.mjs" ${SCRATCH_DIR}/activate-response.json` — activate can return HTTP 200 with a `{success:false}` silent-failure body when a referenced invocable action isn't surfaced; the classifier catches that. `PASS` ⇒ Phase 7; `FAIL` ⇒ surface `messages[]`, offer Phase 2c permset hand-off if a message names a missing action, do NOT report CREATED; `CANNOT-CONFIRM` ⇒ fall through to Phase 7 SOQL verify.
 9. **Phase 7 — Verify.** SOQL `BotDefinition WHERE Id='<id>'` (+ `BotVersions` subquery) and classify — `<id>` is the create path's `publishedBotId` (captured from Phase 5) or, on the ALREADY-CREATED / reactivation path, the **live matched Id the Phase-2 classifier returned** (its `botDefinitionId`/`agentId` output — the actual `BotDefinition.Id` of the matched record), **not** the Phase-1 template `botDefinitionId` (which is always null for the Fulfiller, so on any existing-agent hit the verify would run `WHERE Id=''` and falsely report failure after a successful skip/activation). Confirm `exists:true, count:1, latestVersionStatus:"Active"`. Any discrepancy ⇒ report verbatim, do not fabricate success.
-10. **Phase 8 — Aggregate verdict.** Emit CREATED / ALREADY-CREATED / ACTIVATED / FAILED (ACTIVATED on the Phase-2b path) + `BotDefinition` Id / bundle `id` by re-invoking `render-report.mjs` — the single source of report text. If `${outputDir}` was provided, overwrite `${outputDir}/report.md`; otherwise emit stdout as the turn-side report.
+10. **Phase 8 — Aggregate verdict.** Emit CREATED / ALREADY-CREATED / ACTIVATED / FAILED (ACTIVATED on the Phase-2b path) by re-invoking `render-report.mjs` — the single source of report text. **Never surface internal record IDs** — the bundle version `id`, `publishedBotId`/`BotDefinition`, or `BotVersion` — in the verdict, chat narration, or the report; they are captured only to drive the publish/activate/verify calls and mean nothing to the admin. Report by status/name only ("created and activated"), never "Bundle created (version id …)" / "Published (BotDefinition …)". If `${outputDir}` was provided, overwrite `${outputDir}/report.md`; otherwise emit stdout as the turn-side report.
+11. **Phase 9 — Runtime-access hand-off (REQUIRED on a live-agent verdict).** When the Phase-8 verdict is `CREATED`, `ALREADY-CREATED`, or `ACTIVATED` (a live agent now exists), raise an `AskUserQuestion` — the same enforced hand-off pattern as the Phase-1 prerequisite and Phase-2c permset offers — asking whether to set up the agent's **runtime access** now: _"The agent is live, but its actions call platform features (Prompt Templates, Data Cloud, Unified Catalog) a user can't run until access is granted, so it fails when opened. Set up runtime access now?"_. On **Yes**, delegate to `service-itsm-agentic-setup-agent-runtime-access-assign` (it runs its own target-user selection + confirm-to-write gate). On **No**, stop — the report's "set up access" next-step line stands as the record. Do **NOT** raise this on `PENDING CONFIRMATION`, `DECLINED`, or `FAILED` (no live agent to grant access to). This is an enforced `AskUserQuestion`, not report prose — `render-report.mjs` still emits its plain-language "set up access" line unchanged; the question is what guarantees the offer is actually made every time.
 
 ---
 
@@ -152,7 +153,8 @@ Substitute `<alias>` with the collected target org and `<developerName>` / `<lab
 | Enumerate `BotDefinition` **with the `BotVersions` subquery**; skip create when Active; offer Phase-2b reactivation when Inactive — never silent skip, never duplicate create | Subquery is what distinguishes Active/Inactive; the server rejects a duplicate `DeveloperName` at publish (unique-constraint → bundle cleanup), so this read is what turns a repeat into a graceful skip instead of that hard error |
 | **REQUIRED confirm-to-write checkpoint** before create sequence or reactivation call | Both change live org state — explicit user approval required |
 | On `hasAccess=false` / `403 FUNCTIONALITY_NOT_ENABLED`, offer the readiness hand-off — never enable features here; never call legacy `/connect/service-itsm/createAgent` | Enablement is a Setup-UI/admin action; `createAgent` produces a Setup-page bot with an external-link icon (wrong kind of agent for this skill) |
-| Report exact CLI response text on any error | Enables support to diagnose failures |
+| **Never surface internal record IDs** — the bundle version `id` (`1bZ…`), `publishedBotId`/`BotDefinition` (`0Xx…`), `BotVersion` (`0Xv…`) — in chat narration, the confirm-to-write step, or the report; report progress and verdict by status/name only | These IDs are captured solely to drive the publish → activate → verify → verify-read calls; they are meaningless to an admin going through setup and only add noise. `render-report.mjs` renders status-only rows and defensively scrubs any ID; the model must likewise not echo them (never "Bundle created (version id 1bZ…)" / "Published (BotDefinition 0Xx…)") |
+| Report exact CLI response text on any error | Enables support to diagnose failures — this is the one place a raw ID may appear, inside a verbatim error the user must relay to support |
 
 ---
 
@@ -165,7 +167,8 @@ Substitute `<alias>` with the collected target org and `<developerName>` / `<lab
 - [ ] Bundle body built by `build-create-body.mjs`, POSTed via `--body @<file>` with the collected `developerName`/`label`; or write correctly skipped.
 - [ ] Same `bundleVersionId` (response `id`) used for publish + activate; reactivation used `POST /connect/bot-versions/<id>/activation`; legacy `createAgent` never called.
 - [ ] Phase-7 verify confirmed `BotDefinition` present + latest version Active.
-- [ ] Access token never extracted; final verdict + `BotDefinition`/bundle Id reported.
+- [ ] On a live-agent verdict (CREATED / ALREADY-CREATED / ACTIVATED), the Phase-9 runtime-access hand-off was raised as an `AskUserQuestion` (delegating to `service-itsm-agentic-setup-agent-runtime-access-assign` on "yes"); NOT raised on PENDING CONFIRMATION / DECLINED / FAILED.
+- [ ] Access token never extracted; final verdict reported with **no internal record IDs** (bundle version `id`, `publishedBotId`/`BotDefinition`, `BotVersion`) surfaced in chat, the confirm-to-write step, or the report — status/name only (raw IDs allowed only inside a verbatim error).
 
 ---
 
@@ -173,7 +176,7 @@ Substitute `<alias>` with the collected target org and `<developerName>` / `<lab
 
 The report layout is generated deterministically by `scripts/render-report.mjs` — the single source of report text for both the chat turn and the harness's `${outputDir}/report.md`. Never hand-compose the layout in prose (A9); always shell out to the helper. Full rendered shape, report-state JSON schema, and checkpoint-write rules live in `references/report-format.md`.
 
-Terminal verdicts: `CREATED | ALREADY-CREATED | ACTIVATED | PENDING CONFIRMATION | DECLINED | FAILED`. When `${outputDir}` is set, write at Phase 3, Phase 6 (or Phase 2b), and Phase 8 — each write overwrites the same file. Skip these writes in interactive/chat surfaces.
+Terminal verdicts: `CREATED | ALREADY-CREATED | ACTIVATED | PENDING CONFIRMATION | DECLINED | FAILED`. When `${outputDir}` is set, write at Phase 3, Phase 6 (or Phase 2b), and Phase 8 — each write overwrites the same file. Skip these writes in interactive/chat surfaces. The Phase-9 runtime-access hand-off fires after the Phase-8 report on a live-agent verdict; it does not change the verdict or re-render the report.
 
 ---
 

package/skills/service-itsm-agentic-setup-fulfiller-agent-configure/references/report-format.md

@@ -19,8 +19,8 @@ Stage 2 — install & activate the agent from its template:
 | Preflight | Studio hasAccess=<true/false/cannot-confirm>; template agentScript present=<yes/no>; verdict=<READY/NOT-READY/CANNOT-CONFIRM> |
 | Enumerate | target agent exists before write=<yes/no>; latest version status=<Active/Inactive/n/a>; verdict=<exists:...> |
 | Confirm-to-write | user-confirmed=<true/false/pending> |
-| Create bundle | <bundleVersionId=... / ALREADY-CREATED / skipped (reactivation path) / pending confirmation / skipped / FAILED> |
-| Publish | <publishedBotId=... / skipped / pending confirmation / FAILED> |
+| Create bundle | <succeeded (created) / ALREADY-CREATED / skipped (reactivation path) / pending confirmation / skipped / FAILED> |
+| Publish | <succeeded / skipped / pending confirmation / FAILED> |
 | Activate | <succeeded (created) / succeeded (reactivated existing) / skipped / pending confirmation / FAILED> |
 | Verify | <BotDefinition present: yes/no; latest version Active: yes/no / skipped / pending> |
 
@@ -33,6 +33,8 @@ Next steps:
 
 The helper enforces a validated verdict set and picks the `Next steps` line from the verdict, so the file never drifts from that shape.
 
+**No internal record IDs in the report.** The stage rows carry status only — the bundle version `id`, `publishedBotId`/`BotDefinition`, and `BotVersion` are captured solely to drive the publish/activate/verify calls and are meaningless to an admin, so they are never displayed. The helper renders status-only rows and defensively scrubs any ID that a caller passes inside a stage-status string, so a report can never leak one regardless of the phase-state input. Do not add IDs back in turn-side narration either (never "Bundle created (version id …)" / "Published (BotDefinition …)").
+
 ## Checkpoint writes (harness / non-interactive runs)
 
 When `${outputDir}` is provided (via the harness's generated-file location directive), invoke the helper at three checkpoints so a report always exists even when a run parks at a confirmation gate:

package/skills/service-itsm-agentic-setup-fulfiller-agent-configure/references/workflow-detail.md

@@ -142,7 +142,7 @@ Confirm `exists:true` with `count:1`, and — on the create or reactivation path
 
 ## Phase 8 — Aggregate verdict
 
-Report CREATED / ALREADY-CREATED / ACTIVATED / FAILED plus the `BotDefinition` Id / bundle `id`. Use **ACTIVATED** when Phase 2b's reactivation path was taken (existing agent found inactive, activated instead of creating new). Emit the final report by re-invoking `scripts/render-report.mjs` — the single source of report text. If `${outputDir}` was provided, overwrite `${outputDir}/report.md`; otherwise emit the helper's stdout as the turn-side report.
+Report CREATED / ALREADY-CREATED / ACTIVATED / FAILED. Use **ACTIVATED** when Phase 2b's reactivation path was taken (existing agent found inactive, activated instead of creating new). **Do not surface internal record IDs** (the bundle version `id`, `publishedBotId`/`BotDefinition`, `BotVersion`) in the verdict, report, or chat narration — they drive the publish/activate/verify calls but mean nothing to the admin; report by status/name only. Emit the final report by re-invoking `scripts/render-report.mjs` — the single source of report text (it renders status-only rows and scrubs any stray ID). If `${outputDir}` was provided, overwrite `${outputDir}/report.md`; otherwise emit the helper's stdout as the turn-side report.
 
 ```bash
 node "<skill_dir>/scripts/render-report.mjs" ${SCRATCH_DIR}/report-state.json "${outputDir}/report.md"

package/skills/service-itsm-agentic-setup-fulfiller-agent-configure/scripts/render-report.mjs

@@ -111,22 +111,28 @@ const gatedFallback = isPending
   : isFailed ? 'skipped'
   : 'pending';
 
-const bundleVersionId = field(state.bundleVersionId, '');
-const bundleVersionIdSuffix = bundleVersionId ? ` bundleVersionId=${bundleVersionId}` : '';
-const onBundleVersionId = bundleVersionId ? ` on bundleVersionId=${bundleVersionId}` : '';
-
-function withCreateSuffix(base) {
-  if (base === 'pending' || base.startsWith('skipped') || base === 'pending confirmation') return base;
-  return `${base}${bundleVersionIdSuffix}`;
-}
-function withPublishActivateSuffix(base) {
-  if (base === 'pending' || base.startsWith('skipped') || base === 'pending confirmation') return base;
-  return `${base}${onBundleVersionId}`;
+// Internal record IDs (bundleVersionId `1bZ…`, BotDefinition `0Xx…`, BotVersion
+// `0Xv…`) are meaningless to an admin and must never appear in the user-facing
+// report — they are captured only to drive the publish/activate/verify calls.
+// The stage rows carry status only; `scrubInternalIds` strips any ID a caller
+// passed inside a status string, so the "single source of report text" stays
+// ID-free regardless of input (belt-and-braces, like `cell` below).
+function scrubInternalIds(s) {
+  return String(s)
+    // "bundleVersionId=1bZ…", "on bundleVersionId 1bZ…", "publishedBotId=0Xx…", "BotDefinition 0Xx…", …
+    .replace(/\s*\b(?:on\s+)?(?:bundleVersionId|bundleId|publishedBotId|publishedBotVersionId|botDefinitionId|BotDefinition|BotVersion|agentId)\b\s*[:=]?\s*[a-zA-Z0-9]{15,18}\b/g, '')
+    // any remaining bare Salesforce-ID token (15/18 alphanumeric, must contain a digit)
+    .replace(/\s*\b(?=[a-zA-Z0-9]*[0-9])[a-zA-Z0-9]{15}(?:[a-zA-Z0-9]{3})?\b/g, '')
+    // tidy separators orphaned by the removals above
+    .replace(/\s*[;,]\s*(?=[;,])/g, '')
+    .replace(/[;,\s]+$/g, '')
+    .replace(/\s{2,}/g, ' ')
+    .trim();
 }
 
-const createBundle = withCreateSuffix(field(state.createBundle, gatedFallback));
-const publish = withPublishActivateSuffix(field(state.publish, gatedFallback));
-const activate = withPublishActivateSuffix(field(state.activate, gatedFallback));
+const createBundle = scrubInternalIds(field(state.createBundle, gatedFallback));
+const publish = scrubInternalIds(field(state.publish, gatedFallback));
+const activate = scrubInternalIds(field(state.activate, gatedFallback));
 const verifyFallback = isDeclined || isPending || isFailed
   ? 'skipped'
   : isAlready
@@ -141,8 +147,15 @@ if (
 ) {
   verify = `${verify}; exists:true; latestVersionStatus=Active`;
 }
-
-const reason = String(state.reason ?? '').trim();
+verify = scrubInternalIds(verify);
+
+// `reason` is the FAILED/DECLINED-path field most likely to carry a raw upstream
+// platform error (e.g. an INSUFFICIENT_ACCESS message quoting a BotDefinitionId),
+// so it gets the same scrub as the stage rows above — an internal record ID must
+// never reach the user-facing report/chat (CWE-200/209). Scrubbing here, before
+// NEXT_STEPS, also keeps the FAILED next-step's `reason ? …` branch consistent
+// with what is actually shown in the Reason line.
+const reason = scrubInternalIds(String(state.reason ?? '').trim());
 
 // The "set up access" next step below is the handoff to the
 // `service-itsm-agentic-setup-agent-runtime-access-assign` skill (declared in