@salesforce/afv-skills 1.59.0 → 1.61.0

package/skills/service-itsm-agentic-setup-incident-sla-configure/references/workflow.md

@@ -0,0 +1,295 @@
+# Incident SLA setup — full step-by-step workflow
+
+Detailed companion to `SKILL.md`. The SKILL.md body carries the phase **overview**, the
+**Rules / Constraints** table, and the **Verification Checklist**; this file carries the
+per-phase step-by-step detail (every read, delegated write, and API quirk). All steps are
+sequential. **Always read before you write.** Every call goes through `mcp__headless-360__*`
+tools. Call shapes / templates / response envelope / gotchas live in `references/mcp-invocation.md`.
+
+## Phase 0 — Reuse what the session already knows
+
+Each Phase 1 read carries a **skip-if-already-known** clause: skip only when the same fact was
+produced **this session** by a successful `dispatch_readonly` on the current org and unwritten since —
+a user statement is never cache-eligible. Cacheable: master Incident Mgmt pref (step 1, only if
+`ENABLED`), SLA feature + Versioning (Phase 0.5), Incident describe (3, incl. the `Incident.Priority`
+picklist), `BusinessHoursId` (4), SLA Connect ops (2). (Step 5 resolves no Account — Incident has
+none.) **When in doubt, re-check.**
+
+## Phase 0.5 — SLA Management for IT Service prerequisite gate
+
+**Resolve this gate first, on its own. Reads are safe up front; confirm the org before any write.**
+"SLA Management for IT Service" is enabled only when **both** Simplified SLA Setup **and** SLA
+Versioning are on; either off → not enabled. These are **two separate writes** — enabling SLA
+Management (which flips its composite prefs atomically, and requires Entitlements already on) does
+**not** turn on Versioning; Versioning is a distinct, **permanent, one-way** write. Both the reads and
+the writes are **delegated to `itsm-shakti/SLASettings`** (owns the SLA-Management
+settings surface) — discover → describe → dispatch rather than re-deriving the routes here.
+Shapes / preconditions / `enableBlockedReasons` / ack wording: `references/mcp-invocation.md`.
+
+- **Read both** (`dispatch_readonly`); proceed to Phase 0.6 **only when both are on**.
+- **On an OFF org, read the master license first** (Phase 1 step 1, `service-cloud-itsm-incident`):
+  `NOT_AVAILABLE` → **HALT** — don't flip the permanent Versioning switch where Incident SLA can't run.
+- **Two separate `AskUserQuestion` acks — never merge.** (a) master Incident Mgmt `NOT_ENABLED` → ask
+  to enable it first (reversible, no permanence warning). (b) a *distinct* permanence ack: completing
+  the gate also turns on **SLA Versioning** (a **separate** write), which **can't be turned off** (SLA
+  Management disables later but Versioning stays on). Offer **enable**/**stop** — no "versioning-off";
+  a bare "enable SLA" is **not** consent.
+- **Decline (b), non-empty `enableBlockedReasons`, or a re-read mismatch → HALT** — enable no SLA
+  Mgmt/Versioning, don't proceed to Phase 0.6/1 (a reversible master enable from (a) stands). **After
+  any write, re-read both and report the REAL state** — never trust `201`/`204`.
+
+## Phase 0.6 — Predefined (OOB) vs Custom
+
+Once the gate passes, offer the OOB policy **before** any custom-flow questions. **Incident only.**
+
+1. **Prerequisite + detect.** Confirm master Incident Mgmt pref `ENABLED` (Phase 1 step 1). Then
+   `dispatch_readonly` `GET /headless/invoke/platform/slasettings` (get-existing-checkbox-states) —
+   its lowercase-keyed map's `incident` value is the authoritative "is the OOB default seeded?"
+   answer (this is the seeder's own dedup read; it maps to display name **"Standard Support for
+   Incidents"**).
+   - **`incident: true`** → **no re-seed** (no idempotency), no custom upsell; report it is seeded.
+     **If warn/escalate actions were requested → resolve the named existing milestones → Phase 2.5 →
+     Phase 3 verify → STOP** (attach actions even though the policy was already seeded).
+2. **Fork.** **First — before presenting the fork prompt** — read the live `Incident.Priority`
+   picklist. This is the **Phase 1 step 3 `Incident/describe`** pulled forward (its
+   `fields[].picklistValues`), cached per Phase 0 — so the Custom branch's Phase 1 step 3 is then a
+   no-op, not a second describe (**Custom-Priority coverage note; informational — NOT an OOB option**). If it carries
+   **custom active values beyond the four standard tiers** (Critical / High / Moderate / Low) — e.g.
+   an org-added `Emergency` — the fork prompt must **say plainly that the predefined policy covers
+   only the standard tiers**, so those custom values get **no First Response milestone under OOB**.
+   Do **not** *proactively* offer to bolt a milestone for them onto the predefined policy, and **never
+   re-seed** (the seeder builds one fixed bundle server-side and isn't idempotent — re-running
+   duplicates). Point the user to the **Custom** path by default, which reconciles every value against
+   the live picklist **and adds a milestone for each custom active Priority value** (Phase 1.4 / Phase 2
+   step 10). **But if the user *explicitly* asks to add a milestone for a custom tier onto the seeded
+   policy, honor it** — resolve the seeded *Standard Support for Incidents* policy by name (SOQL) and
+   delegate a **direct `csp-sun/create-milestone`** against that policy id (the same milestone-attach op
+   the Custom flow uses at Phase 2 step 10 — a direct attach, **not** a re-seed of the bundle). The
+   default decision stays a clean Predefined-vs-Custom fork; the explicit attach is opt-in only. **Then** ask one `AskUserQuestion`, **Predefined first / recommended**:
+   Salesforce's predefined Incident policy (*Standard Support for Incidents* — priority-tiered) **or**
+   a custom one. One-way: predefined seeds an **active** policy + Entitlement, no un-seed path (manual
+   delete only).
+   - **Predefined →** **do not resolve or ask for an Account.** The seeder wires the policy's
+     Entitlement and BusinessHours **server-side itself**, so Phase 1 steps 4 (default BusinessHours)
+     and 5 (Account) are Custom-flow inputs and are **not** run here — asking for an Account on this
+     branch is an over-ask. The Phase 3 test Incident sets the seeded Entitlement's `EntitlementId`
+     **directly** (no Account needed). → **Phase 2-OOB** → **Phase 2.5** (if actions requested) →
+     Phase 3 verify → **STOP**.
+   - **Custom →** existing Phase 1 → 1.4 → 1.5 → 2 → 3, unchanged.
+
+## Phase 1 — Preflight & discovery
+
+**On any `401` / `403` / `404` from a step below, halt and surface the raw error** — the org/client is misconfigured. `401` → MCP auth (ECA/token). `403` → user perm OR ITSM Incident Management license/pref missing. `404` → `headless-360` not activated OR Entitlement Management not enabled for Incident.
+
+1. **Master Incident Management pref — direct read** *(skip conditions in Phase 0)*.
+   `dispatch_readonly` `GET .../connect/setup/discovery/features`, filter `features[]` to the **exact**
+   `apiName == "service-cloud-itsm-incident"` — never a look-alike (`service-cloud-incident-management`
+   is generic Case-based Incident Management, not our target). Read `status`: `ENABLED` → proceed;
+   `NOT_AVAILABLE` (license missing) → **halt and surface it** — cannot be enabled here, no delegate/ack;
+   `NOT_ENABLED` → **explicit `AskUserQuestion` ack first (never auto-enable as an implied SLA
+   dependency)**, then delegate to `service-itsm-incident-mgmt-configure` inline (confirms-to-write) and
+   re-read; if declined, halt — every SLA artifact below depends on the master being on. Full shape + why
+   setup-org-preferences 404s here: `references/mcp-invocation.md` (Preflight A).
+2. **Discover the Connect operations** — *(skip if already verified this session — see Phase 0)*.
+   `mcp__headless-360__discover(query="sla-management milestone")` to confirm the SLA Management
+   Connect API is indexed, then `mcp__headless-360__describe(id=<operation_id>)`
+   for the `milestone-types`, `sla-policies`, and `sla-policies/{id}/milestones` POST operations to pull
+   their exact input schemas + HTTP routes. If `discover` returns nothing after rewording the query,
+   the corpus does not index this surface for the org — direct the user to **Setup → SLA/Entitlement
+   setup** and stop.
+3. **Verify Incident Management + SLA fields** — *(skip if `Incident.describe` result for the
+   current org is already in context — see Phase 0)*. Otherwise `dispatch_readonly` on
+   `GET /services/data/v{version}/sobjects/Incident/describe` and confirm `fields[]` includes
+   `EntitlementId`, `SlaStartDate`, `SlaExitDate`. If the describe 404s or fields are missing, direct
+   the user to enable Entitlement Management for Incident and stop. **This same describe also yields
+   the live `Incident.Priority` picklist** (`fields[].picklistValues`) consumed by the Phase 0.6 fork
+   note and the Phase 1.4 / Phase 2 step 10 reconciliation — so on the Custom branch it is already in
+   context from Phase 0.6 step 2 (Phase 0 skip).
+4. **Find default BusinessHours** — *(skip if `BusinessHoursId` for the current org's default is
+   already captured this session)*. Otherwise `dispatch_readonly` on `GET /services/data/v{version}/query` with
+   `query_params.q="SELECT Id, Name FROM BusinessHours WHERE IsActive = true AND IsDefault = true"`.
+   If `body.records` is empty, stop with a message to create default Business Hours in Setup. Capture
+   `BusinessHoursId`.
+5. **Account — NOT required for Incident; do not resolve or ask for one.** Unlike Case, `Incident`
+   has no customer-`Account` field, and the Custom flow's Entitlement auto-provisions on activation
+   (`createEntitlement=true`, step 11) **without** an `AccountId` — no write in this flow consumes an
+   Account (engagement is per-Incident via `EntitlementId`; see step 12). So **skip this step** — asking
+   for an Account here is an over-ask that also seeds the false "Account-scoped auto-apply" premise.
+   (Only revisit if a specific leaf's `describe` proves it hard-requires an `AccountId`; it does not
+   today.) If the user *volunteers* an Account name, acknowledge it but do not treat it as required.
+6. **Read existing SLA artifacts (idempotency probe)** — `dispatch_readonly` SOQL for `SlaProcess` by
+   name (`... WHERE Name = '<name>' AND SobjectType = 'Incident'` — the field is `SobjectType`;
+   `ProcessType` returns `INVALID_FIELD`), each `MilestoneType` the strategy would create,
+   `SlaMilestone` under the matched policy, and `Entitlement` by name (no Account filter — Incident has none). If
+   **every** artifact already exists with the requested config, set `noOp=true` and skip Phase 1.4 +
+   Phase 2 (skip condition (b)); any missing/divergent artifact → proceed to Phase 1.4.
+
+**Coexistence with an existing active Incident policy (Custom flow).** When the Phase 0.6 / Phase 1
+reads surface a *different* active Incident SLA policy already present (e.g. a predefined *Standard
+Support for Incidents* detected at Phase 0.6 step 1) **and the user has explicitly asked for Custom**
+(this is the deliberate-Custom case while that policy stays seeded — not the upsell path Phase 0.6
+forbids): **do NOT offer to deactivate, replace, or un-scope the existing policy** — changing a policy
+the user didn't ask to touch is out of this skill's scope and risks disrupting a live SLA (deactivation
+is technically reachable via `activate-sla-policy` `isActive=false`, but that is not this flow's job),
+and predefined has **no un-seed path (manual delete only)**. The
+two are meant to coexist — creating the custom policy never removes or hides the existing one: both
+remain in **Setup → SLA/Entitlement setup** and both stay usable. The custom policy coexists cleanly
+**because it engages per-Incident via `EntitlementId`** (step 12), not by any Account-scoped auto-apply
+(Incident has no Account field to scope on) — narrate that, don't fork on it: "your existing *<name>*
+policy stays active; this custom policy is applied per-Incident by setting the Incident's Entitlement
+to it." State the one genuinely singular point without inventing a fix: an Incident engages exactly
+**one** Entitlement (its `EntitlementId`); to put the custom policy on a specific Incident, set that
+Incident's `EntitlementId` to the custom Entitlement (the mechanism Phase 3 already uses) — **never**
+reorder or disable the other policy's criteria. Keep this a Phase 1.5 plan-narration, **not** a
+Replace-vs-Keep-both prompt. **The closing report follows the same rule:** the existing/predefined
+policy stays the broad org-wide one and the custom is targeted per-Incident — do **not** end the report
+by offering to broaden the custom policy to auto-apply to **all** Incidents or to "decide/resolve
+precedence" against the existing policies (there is no leaf that arbitrates cross-policy precedence);
+point to `EntitlementId` for targeting a specific Incident instead.
+
+## Phase 1.4 — Milestone Strategy
+
+Every SLA policy needs at least one milestone. Load `examples/milestone-patterns.md` — it lists the
+skip conditions (concrete shape in prompt / idempotent no-op / explicit up-front authorization) and
+the five strategy options with their `AskUserQuestion` prompt, defaults, and MilestoneType-reuse
+rules. Skip condition (c) still requires Phase 1.5 plan-narration before dispatch. Multi-milestone
+selection expands to N creates in Phase 2 step 10 (one delegation per milestone, `order` 1..N, same SlaProcess).
+
+## Phase 1.5 — Confirm before mutating
+
+7. **Confirm the plan** — present the resolved config (target **org**, **SLA Policy** name, the
+   **engagement model** (per-Incident via `EntitlementId` — **no Account**, since Incident has no
+   Account field), and the **full per-milestone list** — never collapse Priority-tiered / Custom to
+   "N milestones"). **Skip the `AskUserQuestion`** (but still narrate the
+   plan before dispatch) when up-front authorization was granted (note `(authorized in prompt)`), the
+   branch is a no-op, or it was already confirmed in conversation (note `(confirmed in conversation)`);
+   otherwise require an explicit "yes" before Phase 2. Everything after this step mutates the org.
+
+## Phase 2 — Create SLA Artifacts (delegated writes — exact order, each depends on the previous)
+
+**The skill decides every input below; the raw writes are delegated to the approved csp-sun SLA leaf
+capabilities** (discover → describe → dispatch each) — they own the approved Connect contracts, so do
+not re-derive request shapes here. Capture each returned `id` for chaining only (never surface it —
+Output contract).
+
+8. **MilestoneType(s) → delegate to `csp-sun/MilestoneTypes`.** Decide the set + reuse rule **here**:
+   reuse a single MilestoneType across milestones that share a name (Priority-tiered "Incident First
+   Response" is reused across **all** its milestones, including any custom active Priority value);
+   create separate MilestoneTypes for distinct concerns (Response + Resolution = two; Escalation
+   ladder = three); skip a name the Phase 1 probe already found. Delegate the raw create per required
+   type; a detected/reused one is narrated by name only (Output contract: name, never `→ <Id>`).
+9. **SLA Policy → delegate to `csp-sun/create-sla-policy`.** Pass `processType='Incident'`, the
+   default `businessHourId` from Phase 1, and the entry/exit criteria confirmed in Phase 1.5. Created
+   **inactive** — activation is the explicit step 11 so the auto-entitlement is provisioned. **The
+   create response echoes nulls — verify via SOQL, not the body; narrate the policy by name, never
+   the Id** (Output contract).
+10. **Milestone(s) → delegate to `csp-sun/create-milestone`, one delegation per milestone** in
+    ascending time-trigger order (`order` 1..N, same policy). Build each `milestoneCriteria` **here**
+    from `assets/attach-milestone.json` + the per-pattern `filterItems` in
+    `examples/milestone-patterns.md`. **This is where the Priority reconciliation lands:** match every
+    criteria value against the **live** `Incident.Priority` picklist, drop/rename unmatched standard
+    rows, **and add a milestone for each custom active Priority value** the org added — no active value
+    left without an SLA. The leaf owns the UPPERCASE `milestoneState=ACTIVE`, `filterType=RuleFilter`,
+    no-`slaProcessId`-in-body, and confirm-from-body (this endpoint returns `201` even on a failed
+    save) contract. On any failure, halt (no half-attached policy) — narrate each by `MilestoneType`
+    name, never its Id/`triggerId` (Output contract).
+11. **Activate + auto-provision Entitlement → delegate to `csp-sun/activate-sla-policy`.** Activate
+    the policy and provision its Entitlement in one call — `isActive` and `createEntitlement` are
+    **QUERY params, not a body** (always send `createEntitlement` explicitly). This is the **custom
+    flow only** — it replaces the old `active:true`-on-create + manual `POST /sobjects/Entitlement`.
+    The **OOB seed path does not run this step at all**: its single `save-selected-options` call seeds
+    an already-active policy and auto-provisions the Entitlement itself (see Phase 2-OOB). The leaf carries the
+    no-500 activation contract: a `200` with a returned `entitlementId` is the success shape. Capture the
+    returned `entitlementId`. **Verify by reading the policy back (`active=true`)**, never the write response.
+12. **Engagement targeting (Incident has NO Account-scoped auto-apply).** Unlike Case, **`Incident`
+    has no customer-`Account` field** (its only Account-ish field is the polymorphic `ReportedById`),
+    so an Entitlement's auto-apply criteria **cannot be Account-scoped for Incident** — do not attempt
+    it, and **do not ask for or bind an Account for auto-apply scope** (that was an over-ask that also
+    caused a mid-flow contradiction). **Default: per-Incident targeting** — the custom policy engages by
+    setting an Incident's `EntitlementId` to this policy's Entitlement (the same mechanism Phase 3
+    uses); create **no auto-apply criterion**, and say so in the plan/report ("engages per-Incident via
+    `EntitlementId`; no auto-apply criterion — Incident has no Account field to scope on"). Only if the
+    user **explicitly** wants an org-wide always-match criterion do you delegate to
+    `csp-sun/create-entitlement-criteria` (`entitlementId` from step 11; leaf owns the uppercase
+    `AND|OR|CUSTOM` `criteriaType` contract — mixed-case / `RuleFilter` / `Formula` silently fail to
+    open on the Setup edit page; verify by "read every rule in the org, match by `entitlementId`") —
+    and first surface that an always-match criterion **collides** with any existing broad Incident
+    policy (Coexistence rule). Narrate by name, never the Id.
+
+## Phase 2-OOB — Seed the Predefined Incident Policy
+
+Reached only from Phase 0.6 Predefined (replaces Phase 1.4/1.5/2). The predefined **"Standard
+Support for Incidents"** bundle is seeded by **one** call to the platform's own default-policy
+seeder — the same action the SLA Settings Setup page runs — served headless on the Aura dispatcher
+route. Core's seeder builds the entire active bundle itself (policy + MilestoneTypes + milestones +
+Entitlement + entitlement criteria), so the skill neither hand-lists the milestones nor provisions
+the Entitlement. This replaces the former hand-rebuilt seed (a raw `active:true` `POST .../sla-policies`
++ 6 `create-milestone` calls + a manual `POST /sobjects/Entitlement`) — that whole replica is retired.
+The detect + seed are **delegated to `itsm-shakti/SLASettings`** (contract owner of the seeder route).
+
+Follow the seed recipe in `references/mcp-invocation.md` (**Predefined Incident Policy**):
+
+1. **Detect (dedup).** `dispatch_readonly` `GET /headless/invoke/platform/slasettings`
+   (get-existing-checkbox-states) — its lowercase-keyed map's `incident` value is the authoritative
+   "is the OOB default already seeded?" answer. **`incident: true`** → **no re-seed** (the seeder is
+   NOT idempotent — re-running duplicates), no custom upsell; report it seeded and skip to Phase 2.5/3.
+2. **Seed.** `dispatch` `PATCH /headless/invoke/platform/slasettings/save-selected-options` with body
+   `{"selectedOptions": ["incident"]}` — **the value MUST be lowercase `incident`**; the capitalized
+   `Incident` returns a server-side `500`. A `200` with body `true` is success. This provisions the
+   full **active** bundle + auto-entitlement in one shot — no manual Entitlement, and no Connect
+   activate PATCH, so the 500 that path could throw never arises.
+3. **Verify.** Re-read `GET /headless/invoke/platform/slasettings` and confirm `incident: true`, then
+   SOQL `SlaProcess` for **"Standard Support for Incidents"** `IsActive = true` (do not trust the write
+   body). Narrate the policy by name, never its Id.
+
+Then Phase 2.5 (if actions requested), Phase 3 (a non-lowest tier — Moderate/Low, not Critical),
+and **STOP** — no *proactive* custom offer. Any custom-Priority coverage gap was surfaced at the
+Phase 0.6 fork (as an informational note + redirect to the Custom path), **not** by proactively
+augmenting the seeded OOB policy here. **The one exception is an *explicit* user request** to attach a
+milestone (or a warn/escalate action) to the seeded policy — honor it via a **direct
+`csp-sun/create-milestone`** (resolve the *Standard Support for Incidents* policy by name; a direct
+attach, **never** a re-seed), then verify and STOP.
+
+## Phase 2.5 — Milestone Actions (optional: Warn / Escalate)
+
+After milestones exist (Phase 2 or 2-OOB), **only if** the user asked to warn/escalate/notify: apply
+the requested checkpoint(s) to **every milestone the user named** (not just one), each offset computed
+from that milestone's own target. Map "warn at X%" → an offset *before* target, "on breach" →
+*at/after* it; **confirm the full set before writing** (up-front auth waives the re-ask; narrate it
+regardless — no headless delete), then, per milestone, delegate to headless
+**`create-milestone-action`** (`discover` → `describe` → `dispatch`). **Confirm each from the response
+body** (`success` + non-empty `actionMappings`; a *timed* checkpoint also returns a `triggerId`), never
+the `201`. Narrate each by its **`MilestoneType` name**, never the milestone Id/`triggerId` (Output
+contract). **Id-leak guard — the #1 retest failure lands here:** you hold the policy Id and each
+milestone Id internally (you need them to target each action write), but the **pre-write plan table
+AND the closing report MUST key every row by the milestone's tier / Priority / MilestoneType name**
+(e.g. row header `Emergency`, `Critical`), **never** its Id. Do **not** write `Emergency
+(553VW000000…)`, a `Policy … (552VW000009…)` header, or any `55…`/`553…` Id in a table cell, a
+parenthetical, or the report — those Ids are chaining-only. Formula, roles, example body, defaults,
+IST business-hours note: `references/mcp-invocation.md` (Milestone Actions).
+
+## Phase 3 — Verify
+
+13. **Verify the SLA Policy** — SOQL on `SlaProcess` (do not trust the create response); confirm it
+    read back `active=true` — from the activation delegation (Custom flow) or from the seeder (OOB).
+14. **Create a test Incident** to prove engagement — **both flows: set the policy's `EntitlementId`
+    directly on the test Incident** (`Incident` has no Account field, so there is no Account-scoped
+    auto-apply to rely on; `EntitlementId`-direct is the reliable engagement path — Custom uses the
+    Entitlement returned by activation, OOB the seeded Entitlement). For Priority-tiered / OOB
+    strategies, test a tier **other than the lowest `order`** — Critical is order-1, the collapse
+    fallback, so it can't detect a dropped criterion. If a direct `Priority` insert is rejected (it
+    may be matrix-derived), set `Urgency`/`Impact` to derive the tier. Narrate by `IncidentNumber`,
+    never the Id.
+15. **Verify engagement + tiering** — SOQL that an `EntityMilestone` landed on the **correct tier**
+    (a Moderate/Low Incident → the 240/960 tier, NOT 30/120) with a `TargetDate` — that row is the
+    reliable engagement proof. `Incident.SlaStartDate` is populated when you set `EntitlementId` at
+    insert, but can be **null** when the Entitlement is auto-applied via criteria (the milestone still
+    lands); treat a null `SlaStartDate` as a non-blocker, not a failure. The create `201` always
+    echoes `milestoneCriteria:[]`; only this runtime read proves the ACTIVE criteria persisted.
+16. **Report results** using the output format in `examples/output-templates.md`.
+
+---
+
+The **Rules / Constraints** table and the **Verification Checklist** live in `SKILL.md`
+(body) — read them there before executing; they are the non-negotiable gates this step-by-step
+detail implements.

package/skills/service-itsm-incident-priority-configure/SKILL.md

@@ -2,9 +2,9 @@
 name: service-itsm-incident-priority-configure
 description: "Configures the Incident Priority Matrix for Salesforce ITSM through the sf CLI — enabling or disabling the matrix, shaping the Impact x Urgency grid that derives Priority on Incident records, toggling the manual-override preference, and reading or setting the default fallback priority. Reads every value before writing, is idempotent, and requires explicit user confirmation before any mutation. Use when the user wants to view, enable, disable, set up, seed, add to, change, or remove priority matrix configuration for Incident records, change the default incident priority, or asks about incident priority setup, impact/urgency mapping, override, or the ITSM incident priority matrix. DO NOT TRIGGER for Problem or ChangeRequest priority matrices, Case priority fields, standard Priority picklists outside ITSM, SLA or milestone configuration, or enabling Incident Management itself (use the service-itsm-incident-mgmt-configure skill)."
 metadata:
-  version: "1.4"
   relatedSkills:
     - "service-itsm-incident-mgmt-configure"
+  version: "1.4"
   domains: ["Service"]
   minApiVersion: "67.0"
   cliTools:

package/skills/service-itsm-slack-itservice-configure/SKILL.md

@@ -4,7 +4,8 @@ description: "Configure the \"Set Up Self Service for Employees on Slack\" / \"S
 metadata:
   version: "1.0"
   minApiVersion: "67.0"
-  domains: ["Service"]
+  domains:
+    - "Service"
   relatedSkills:
     - "experience-portal-create"
     - "service-itsm-agentic-setup-employee-agent-configure"

package/skills/service-itsm-slack-itservice-configure/references/manage-slack-connection.md

@@ -19,8 +19,8 @@ Returns the live state (verified `200`):
 {
   "team": {
     "status": "CONNECTED",
-    "teamName": "Slackfarm 1473",
-    "teamDomain": "https://slackfarm-1473.enterprise.slack.com",
+    "teamName": "Acme Workspace",
+    "teamDomain": "https://acme.enterprise.slack.com",
     "teamId": "E0…"
   },
   "currentUserMapping": { "salesforceUserId": "005…", "slackUserId": "U0…" }

package/skills/service-omni-channel-setup-coordinate/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: service-omni-channel-setup-coordinate
-description: "Use to stand up Omni-Channel headlessly: base settings, users, service channels, routing configs, queues and members, presence statuses, permissions, supervisor configuration, and Case or VoiceCall routing flows. Reuses existing records and creates missing ones. Optional stages cover Command Center V2 on supported releases, agent experience, and skills-based routing. TRIGGER when: set up Omni-Channel, configure Omni routing, provision Omni agents, provision Omni supervisors, or configure Case, Incident, MessagingSession, or VoiceCall routing. Do not use for Agentforce bots, one existing field change, or bare metadata deployment."
+description: "Use to stand up Omni-Channel setup headlessly on Salesforce: base settings, agent users, service channels, routing configs, queues (create and align) and members, presence statuses, permission assignments, the classic Omni Supervisor config plus its action/tab surface, and — for Case and VoiceCall — the record-triggered routing flow. Supports Case, Incident, MessagingSession, and VoiceCall targets; reuses existing records and creates what is missing. Opt-in extras: presence user config, Omni sidebar, skills-based routing, and field-based WorkSkillRouting; also reports (read-only) whether the org is on the classic supervisor surface or Command Center V2. Triggers: set up Omni-Channel, configure Omni routing, provision Omni agents or supervisors, configure Case/Incident/Messaging/Voice routing. Do not use for Agentforce agents or bots, a single existing Omni field change, bare metadata deployment (use platform-metadata-deploy), or to enable Command Center V2 (not writable via the Metadata API)."
 allowed-tools: Bash Read Write Edit Glob Grep AskUserQuestion TodoWrite
 metadata:
   version: "1.0"
@@ -11,9 +11,7 @@ metadata:
     - "service-agentforce-human-escalation-configure"
     - "service-omni-agent-users-create"
     - "service-omni-base-settings-configure"
-    - "service-omni-channel-inventory-analyze"
     - "service-omni-command-center-analyze"
-    - "service-omni-command-center-configure"
     - "service-omni-permission-set-assign"
     - "service-omni-presence-status-deploy"
     - "service-omni-presence-user-config-deploy"
@@ -81,22 +79,20 @@ bash scripts/integration-driver.sh --run  <org-alias> [agent_count] [routing_tar
 - `Incident` targets require the Incident Management feature enabled; `MessagingSession` requires Enhanced Messaging; `VoiceCall` requires Service Cloud Voice. The readiness check hard-fails with a click-path when a requested target sObject is absent.
 - **Production guardrail:** `safe_to_write` is `true` iff any of `IsSandbox = true`, `TrialExpirationDate != null`, or `OrganizationType IN ('Developer Edition', 'Base Edition')`. The run hard-refuses when it is false. CDOs return `IsSandbox=false` with a non-null `TrialExpirationDate` and must be permitted, so `IsSandbox` alone is never the guard.
 
-Readiness check (mandatory, before any write leaf runs):
+Readiness check (silent, mandatory, before any leaf runs):
 
 1. `sf org display` → confirm the org alias is authenticated; refuse (exit 1) if not.
 2. `Organization` (`IsSandbox`, `TrialExpirationDate`, `OrganizationType`) → compute `safe_to_write`; refuse (exit 1) if false.
-3. `service-omni-channel-inventory-analyze` → capture the complete channel/routing baseline through the approved read-only aggregate operation; a blocked inventory prevents writes because the coordinator cannot safely establish the starting state.
-4. Preflight entity availability → for each **non-`Case`** routing target, confirm the sObject exists via `EntityDefinition`; a missing target hard-fails with a feature-enablement click-path (exit 2). `Case` is assumed present and skipped.
+3. Preflight entity availability → for each **non-`Case`** routing target, confirm the sObject exists via `EntityDefinition`; a missing target hard-fails with a feature-enablement click-path (exit 2). `Case` is assumed present and skipped.
 
 Omni-Channel base-settings enablement is not a separate upfront probe — it is detected by the base-settings leaf (step 1), and downstream Omni-dependent leaves are deferred as pending in `--plan` until it is on. The driver does not pre-check `UserLicense` headroom or `ServicePresenceStatus`/`QueueRoutingConfig` availability in this readiness pass.
 
 ## Skills this coordinates
 
-The coordinator delegates every write to a leaf skill. sObject-specific leaves (3, 5, 6, 6c, 7) loop once per routing target; the rest run once. For SkillsBased routing, steps 6a and 6b complete before any trigger flow is activated. Step 10a (`command-center-configure`) is opt-in through `OMNI_COMMAND_CENTER_V2=1`; step 10b (`command-center-analyze`) is a read-only advisory and always runs. Step 11a (`supervisor-surface-deploy`) always runs after the supervisor config succeeds. Leaves 12–13 are the opt-in rep-experience stages (`OMNI_REP_EXPERIENCE=1`).
+The coordinator delegates every write to a leaf skill. sObject-specific leaves (3, 5, 6, 6c, 7) loop once per routing target; the rest run once. For SkillsBased routing, steps 6a and 6b complete before any trigger flow is activated. Step 10a (`command-center-analyze`) is a read-only advisory and always runs. Step 11a (`supervisor-surface-deploy`) always runs after the supervisor config succeeds. Leaves 12–13 are the opt-in rep-experience stages (`OMNI_REP_EXPERIENCE=1`).
 
 | # | Child skill | Role |
 |---|---|---|
-| 0 | `service-omni-channel-inventory-analyze` | Capture the read-only cross-channel and routing baseline before any writes |
 | 1 | `service-omni-base-settings-configure` | Deploy `Settings:OmniChannel` (5 toggles) |
 | 2 | `service-omni-agent-users-create` | Provision the requested agent users |
 | 3 | `service-omni-service-channel-configure` | Reuse the standard `ServiceChannel` for the target sObject, or deploy the canonical XML |
@@ -110,8 +106,7 @@ The coordinator delegates every write to a leaf skill. sObject-specific leaves (
 | 8 | `service-omni-permission-set-assign` | Assign the `Omni_Agent` PermissionSet to agent users; self-heals the bundled metadata when absent (run mode only) |
 | 9 | `service-omni-supervisor-users-create` | Provision supervisor users |
 | 10 | `service-omni-supervisor-permset-assign` | Assign the standard `ContactCenterSupervisor` PermissionSet to supervisor users |
-| 10a | `service-omni-command-center-configure` | *(opt-in)* Enable Command Center V2 through preserved `OmniChannel.settings` and verify its seeded page and tab |
-| 10b | `service-omni-command-center-analyze` | **Read-only advisory** — report whether the org is on the classic supervisor surface or Command Center V2; never writes, never hard-blocks |
+| 10a | `service-omni-command-center-analyze` | **Read-only advisory** — report whether the org is on the classic supervisor surface or Command Center V2; never writes, never hard-blocks |
 | 11 | `service-omni-supervisor-config-deploy` | Deploy `OmniSupervisorConfig` binding supervisor users to the queues discovered in step 5 |
 | 11a | `service-omni-supervisor-surface-deploy` | Populate the supervisor **action + tab surface** (`OmniSupervisorConfigAction` / `OmniSupervisorConfigTab`) on the config from step 11 |
 | 12 | `service-omni-presence-user-config-deploy` | *(opt-in)* Deploy `PresenceUserConfig` + `PresenceDeclineReason` (decline + ACW) and assign the provisioned agents |
@@ -124,7 +119,7 @@ The coordinator delegates every write to a leaf skill. sObject-specific leaves (
 
 **Ordering and gating.** Leaves run in dependency order. Base settings are a hard prerequisite for every write below. For SkillsBased routing, agent `SkillUser` bindings (6a) and the `WorkSkillRouting` rule (6b) must succeed before the routing-flow leaf (6c) can activate the trigger. The flow also requires the queue (5) and its members (6), and it round-trips `FlowDefinitionView.ActiveVersionId` to prove the flow is Active. A required runtime proof does not pass merely because a PSR exists: SkillsBased requires at least one `SkillRequirement` on that PSR.
 
-**Supervisor path.** Supervisor users (9) use the same Anonymous Apex `System.setPassword` model as agent users. Because a password literal can be captured in an `ApexLog` when a debug TraceFlag is active, both user-create leaves fail closed *before* the first `System.setPassword`: they prove via a SOQL-filtered Tooling API query (`ExpirationDate > now`) that no active TraceFlag exists for the running user, and if that cannot be positively proven they set no password at all (users left ACTIVE and `reset_required`, with a `security_warning`). They never delete logs, so unrelated audit logs are untouched. The supervisor permset leaf (10) assigns the standard `ContactCenterSupervisor` — never the custom `Omni_Supervisor`, whose license-gated permissions fail assignment — and a contract test asserts this wiring. With `OMNI_COMMAND_CENTER_V2=1`, the coordinator enables and verifies the V2 org preference through `service-omni-command-center-configure`; optional `OMNI_COMMAND_CENTER_*` booleans select its subordinate controls. A read-only Command Center analysis then reports the resulting supervisor surface and never hard-blocks (ambiguous detection is yellow, a clean read green). Once the classic config lands (11), the surface leaf (11a) inserts the standard action + tab companions (`OmniSupervisorConfigAction` / `OmniSupervisorConfigTab`) against the config's Id — plain Data API rows, so no metadata-file redeploy — and is idempotent (only missing types are inserted). It runs only after the config succeeds; a skipped or failed config skips the surface with a dependency note.
+**Supervisor path.** Supervisor users (9) use the same Anonymous Apex `System.setPassword` model as agent users. Because a password literal can be captured in an `ApexLog` when a debug TraceFlag is active, both user-create leaves fail closed *before* the first `System.setPassword`: they prove via a SOQL-filtered Tooling API query (`ExpirationDate > now`) that no active TraceFlag exists for the running user, and if that cannot be positively proven they set no password at all (users left ACTIVE and `reset_required`, with a `security_warning`). They never delete logs, so unrelated audit logs are untouched. The supervisor permset leaf (10) assigns the standard `ContactCenterSupervisor` — never the custom `Omni_Supervisor`, whose license-gated permissions fail assignment — and a contract test asserts this wiring. After the supervisor permset, a read-only Command Center analysis (10a) reports the org's supervisor surface (classic vs Command Center V2); it never writes and never hard-blocks (ambiguous detection is yellow, a clean read green). Once the config lands (11), the surface leaf (11a) inserts the standard action + tab companions (`OmniSupervisorConfigAction` / `OmniSupervisorConfigTab`) against the config's Id — plain Data API rows, so no metadata-file redeploy — and is idempotent (only missing types are inserted). It runs only after the config succeeds; a skipped or failed config skips the surface with a dependency note.
 
 **Optional rep-experience stages.** With `OMNI_REP_EXPERIENCE=1`, presence user config (12) deploys a validator-safe `PresenceUserConfig` with its decline reason and assigns every resolved agent username, including reused users. Sidebar (13) pins the Omni utility region on `OMNI_CONSOLE_APP`, or auto-detects a single console app. SkillsBased routing is not a cosmetic rep-experience stage: when requested, its SkillUser and WorkSkillRouting prerequisites run before flow activation.
 
@@ -147,11 +142,23 @@ Report content rules:
 ## Limitations
 
 - Routing-flow deploy covers `Case` and `VoiceCall` only.
-- Classic `OmniSupervisorConfig`, including its standard action and tab surface, is supported. Command Center V2 is an explicit opt-in (`OMNI_COMMAND_CENTER_V2=1`) and runs only when the org's Metadata API exposes the V2 settings; otherwise the configure leaf fails closed. Custom actions, FlexiPages, AWS dashboards, and AI-agent surfaces still need external references and separate setup.
+- Classic `OmniSupervisorConfig` (including its action + tab surface) only. Command Center V2 (Enhanced Omni-Channel) is reported by the read-only analysis step but not enabled — the org preference is not writable via the Metadata API. The surface leaf populates only the reference-free standard action/tab types; custom-action, FlexiPage, AWS-dashboard, and AI-agent surfaces need an external reference and must be set up in Setup.
 - The rep-experience stages (presence user config, decline reasons, sidebar) run only with `OMNI_REP_EXPERIENCE=1`. SkillsBased routing is selected explicitly or inferred from a complete `OMNI_WSR_*` mapping and runs independently of that flag.
 - Teardown is **plan-only**: `--run` emits `deploy_ids.json` (a provenance manifest) and a dry-run `teardown.sh` that prints the reverse-order removal/restore plan, but does not execute destructive changes. Automated reversal is deliberately deferred until every leaf emits a normalized provenance block and the reversal is validated live — metadata-deployed components need destructiveChanges deploys and adopted records must never be deleted. Reversal today is a manual operator task guided by the plan and the per-skill artifacts.
 
-Detailed coverage and known headless gaps are maintained in `references/gap-catalog.md`. In short, Case routing is fully coordinated; VoiceCall needs a provisioned voice runtime; Incident and generic MessagingSession routing are adopted rather than created; and Omni Inbox or external supervisor surfaces remain outside this workflow.
+### Use-case coverage (current)
+
+| Use case | Status | What is / isn't headless |
+| --- | --- | --- |
+| Case routing | Ready | Full create-and-bind thread (queue + QRC + members + routing flow), idempotent; runtime `PendingServiceRouting` proof optional. |
+| VoiceCall / AFCC routing | Conditional | QRC + queue + members + routing flow are deployable, but require a **provisioned Amazon/AFCC contact center** and a live Voice runtime to prove end-to-end. Contact-center provisioning is the caller's responsibility. |
+| Open CTI → AFCC migration | Partial | The coordinator creates the Omni routing resources; it does not provision or migrate the contact center itself. |
+| Incident routing | Partial | Service channel + presence are supported; the coordinator **verifies/adopts** Incident routing but does not create a missing queue/QRC/flow for it. |
+| Generic MessagingSession routing | Partial | Service channel + presence supported; full create-and-bind is delegated to `service-agentforce-human-escalation-configure`, not run generically here. |
+| Classic Omni Supervisor | Ready | Users, permissions, config, queues/users, and the action/tab surface companions are all implemented. |
+| Command Center V2 | Detection only | The read-only analysis step reports classic vs V2; the org preference `CommandCenterForServiceV2` is **not writable via the Metadata API** (tracked: W-23827287) and must be enabled in Setup. |
+| Supervisor monitoring OrgValues | Not implemented | `OmniSuperConvMonitor`, `OmniSuperAgentSneakpeek`, `OmniSuperClientSneakpeek`, `OmniSuperWhisper`, `OmniSuperAdminSkillQueue` are OrgValues with no proven supported external write API. |
+| Omni Inbox | Not implemented | The sidebar leaf pins the Omni sidebar (`isOmniPinnedViewEnabled`); it does not create or configure Omni Inbox, a console app, or utility items. |
 
 ## References
 

package/skills/service-omni-channel-setup-coordinate/scripts/integration-driver.sh

@@ -68,25 +68,6 @@ SUPERVISOR_COUNT="${4:-1}"
 AGENT_PROFILE="${OMNI_AGENT_PROFILE:-}"
 SUPERVISOR_PROFILE="${OMNI_SUPERVISOR_PROFILE:-}"
 SUPERVISOR_CONFIG_DN="${OMNI_SUPERVISOR_CONFIG_DEVELOPER_NAME:-Omni_Supervisor}"
-COMMAND_CENTER_V2="${OMNI_COMMAND_CENTER_V2:-0}"
-
-case "$COMMAND_CENTER_V2" in
-  0|1) ;;
-  *) echo "{\"error\":\"Invalid OMNI_COMMAND_CENTER_V2 '$COMMAND_CENTER_V2'. Supported: 0 or 1.\"}" >&2; exit 2 ;;
-esac
-
-for command_center_setting in \
-  OMNI_COMMAND_CENTER_CONVERSATION_MONITORING \
-  OMNI_COMMAND_CENTER_AGENT_SNEAK_PEEK \
-  OMNI_COMMAND_CENTER_CUSTOMER_SNEAK_PEEK \
-  OMNI_COMMAND_CENTER_WHISPER_MESSAGING \
-  OMNI_COMMAND_CENTER_QUEUES_AND_SKILLS; do
-  command_center_value="${!command_center_setting:-}"
-  if [ -n "$command_center_value" ] && [ "$command_center_value" != "true" ] && [ "$command_center_value" != "false" ]; then
-    echo "{\"error\":\"Invalid $command_center_setting '$command_center_value'. Supported: true or false.\"}" >&2
-    exit 2
-  fi
-done
 
 # A complete WorkSkillRouting mapping is an unambiguous SBR request. Infer SkillsBased so callers do
 # not need a hidden second switch; an explicit OMNI_ROUTING_TYPE still wins.
@@ -563,7 +544,7 @@ run_skill() {
   # configured/bound/assigned/ok/success/skipped.
   local color
   case "$status" in
-    analyzed|reused|updated|created|deployed|configured|bound|assigned|ok|success|skipped)
+    reused|updated|created|deployed|configured|bound|assigned|ok|success|skipped)
       color="green"
       ;;
     action_needed|partial|unsupported_v1|not_evaluated)
@@ -630,16 +611,6 @@ run_skill() {
   return 0
 }
 
-# ---- Read-only cross-channel baseline ----
-# A blocked inventory means the coordinator cannot establish an authoritative starting state, so no
-# write leaf is allowed to run.
-run_skill "service-omni-channel-inventory-analyze" \
-  "service-omni-channel-inventory-analyze" \
-  "Omni channel and routing inventory (read-only preflight)" \
-  '.status' \
-  analyze.sh "$ORG" \
-  || exit 1
-
 # ---- Base settings ----
 # Plan detects; run deploys the 5 OmniChannelSettings toggles + re-verifies. Hard prerequisite for
 # every write skill below (INVALID_TYPE when Omni is off), so a red here fails fast.
@@ -1276,32 +1247,11 @@ else
     || true
 fi
 
-# ---- Command Center V2 configuration (explicit opt-in) ----
-if [ "$COMMAND_CENTER_V2" = "1" ]; then
-  if [ "$MODE" = "run" ]; then
-    COMMAND_CENTER_ARGS=(run "$ORG" --apply)
-  else
-    COMMAND_CENTER_ARGS=(plan "$ORG")
-  fi
-
-  [ -z "${OMNI_COMMAND_CENTER_CONVERSATION_MONITORING:-}" ] || COMMAND_CENTER_ARGS+=(--conversation-monitoring "$OMNI_COMMAND_CENTER_CONVERSATION_MONITORING")
-  [ -z "${OMNI_COMMAND_CENTER_AGENT_SNEAK_PEEK:-}" ] || COMMAND_CENTER_ARGS+=(--agent-sneak-peek "$OMNI_COMMAND_CENTER_AGENT_SNEAK_PEEK")
-  [ -z "${OMNI_COMMAND_CENTER_CUSTOMER_SNEAK_PEEK:-}" ] || COMMAND_CENTER_ARGS+=(--customer-sneak-peek "$OMNI_COMMAND_CENTER_CUSTOMER_SNEAK_PEEK")
-  [ -z "${OMNI_COMMAND_CENTER_WHISPER_MESSAGING:-}" ] || COMMAND_CENTER_ARGS+=(--whisper-messaging "$OMNI_COMMAND_CENTER_WHISPER_MESSAGING")
-  [ -z "${OMNI_COMMAND_CENTER_QUEUES_AND_SKILLS:-}" ] || COMMAND_CENTER_ARGS+=(--queues-and-skills "$OMNI_COMMAND_CENTER_QUEUES_AND_SKILLS")
-
-  run_skill "service-omni-command-center-configure" \
-    "service-omni-command-center-configure" \
-    "Command Center for Service V2 (opt-in Metadata API configuration)" \
-    '.status' \
-    configure-and-report.sh "${COMMAND_CENTER_ARGS[@]}" \
-    || true
-fi
-
 # ---- Command Center surface analysis (read-only advisory) ----
-# Reports whether the org is on the classic Omni Supervisor surface or Command Center V2 after any
-# requested V2 configuration. It never writes and never hard-blocks: ambiguous detection surfaces
-# as yellow, while a clean read is green.
+# Reports whether the org is on the classic Omni Supervisor surface or Command Center V2 (Enhanced
+# Omni-Channel). Advisory only: this coordinator configures the classic surface; V2 enablement is an
+# org-preference flip outside the Metadata API. It never writes, so it runs identically in plan and
+# run and never hard-blocks - ambiguous detection surfaces as yellow, a clean read as green.
 run_skill "service-omni-command-center-analyze" \
   "service-omni-command-center-analyze" \
   "Command Center surface analysis (classic vs V2, read-only)" \

package/skills/service-omni-channel-setup-coordinate/scripts/tests/test_omni_contracts.py

@@ -586,26 +586,6 @@ class SkillsBasedRoutingFlowTests(unittest.TestCase):
             return _run(_FLOW_SCRIPT, args, path_prefix=fake_dir, extra_env=merged)
 
 
-class CoordinatorInventoryPreflightTests(unittest.TestCase):
-    """The authoritative cross-channel inventory must run before the first write leaf."""
-
-    DRIVER = SKILLS_ROOT / "service-omni-channel-setup-coordinate" / "scripts" / "integration-driver.sh"
-
-    def test_inventory_runs_before_base_settings(self):
-        source = self.DRIVER.read_text()
-        inventory_index = source.index('run_skill "service-omni-channel-inventory-analyze"')
-        base_index = source.index('run_skill "service-omni-base-settings-configure"')
-        self.assertLess(inventory_index, base_index)
-
-    def test_inventory_failure_stops_the_driver(self):
-        source = self.DRIVER.read_text()
-        invocation = re.search(
-            r'run_skill "service-omni-channel-inventory-analyze"[\s\S]+?\|\| exit 1',
-            source,
-        )
-        self.assertIsNotNone(invocation, "blocked inventory must stop the coordinator before writes")
-
-
 class VoiceMembershipContractTests(unittest.TestCase):
     """(7) Explicit real-agent membership contract for service-omni-queue-members-assign."""
 
@@ -785,24 +765,6 @@ class CoordinatorSupervisorSurfaceTests(unittest.TestCase):
             self.src, r'(?m)^run_skill "service-omni-command-center-analyze"',
             "command-center-analyze must be invoked top-level, outside the OMNI_REP_EXPERIENCE gate")
 
-    def test_command_center_v2_configuration_is_explicit_and_precedes_analysis(self):
-        self.assertIn('COMMAND_CENTER_V2="${OMNI_COMMAND_CENTER_V2:-0}"', self.src)
-        self.assertIn('run_skill "service-omni-command-center-configure"', self.src)
-        configure_at = self.src.index('run_skill "service-omni-command-center-configure"')
-        analyze_at = self.src.index('run_skill "service-omni-command-center-analyze"')
-        self.assertLess(configure_at, analyze_at)
-        self.assertIn('COMMAND_CENTER_ARGS=(run "$ORG" --apply)', self.src)
-
-    def test_command_center_control_inputs_are_forwarded(self):
-        for option in (
-            "--conversation-monitoring",
-            "--agent-sneak-peek",
-            "--customer-sneak-peek",
-            "--whisper-messaging",
-            "--queues-and-skills",
-        ):
-            self.assertIn(option, self.src)
-
     def test_supervisor_surface_invoked_after_config(self):
         self.assertIn("service-omni-supervisor-surface-deploy", self.src,
                       "coordinator never invokes supervisor-surface-deploy")

package/skills/service-omni-command-center-analyze/SKILL.md

@@ -8,7 +8,6 @@ metadata:
   minApiVersion: "66.0"
   relatedSkills:
     - "service-omni-channel-setup-coordinate"
-    - "service-omni-command-center-configure"
     - "service-omni-supervisor-config-deploy"
   accessCheck:
     - type: license
@@ -61,7 +60,7 @@ bash scripts/analyze.sh <org-alias> [supervisor_username_or_id]
 | `v2_ready` | Capability + seed present (and supervisor has permission, if checked) | verify only (coordinator proceeds to V2 verification) |
 | `v2_permission_missing` | V2 enabled but the named supervisor lacks `CommandCenterForServiceUser` | Manual — assign `CommandCenterForServiceUser` (headless-capable via PermissionSet; packaging pending) |
 | `v2_seed_incomplete` | Capability present but the FlexiPage/tab provisioning is inconsistent | Manual — re-check in Setup → Omni-Channel → Supervisor Settings (no supported public write API) |
-| `v2_available_not_enabled` | Org supports V2 but the preference is off | `service-omni-command-center-configure` when the W-24039822 Metadata API contract is available; otherwise enable manually |
+| `v2_available_not_enabled` | Org supports V2 but the preference is off | Manual — enable in Setup → Omni-Channel → Supervisor Settings (no supported Metadata/Tooling write API) |
 | `legacy_selected` | V2 capability absent | `service-omni-supervisor-config-deploy` |
 | `ambiguous` | A required signal could not be read through a supported API | none — **blocks**, do not guess |
 
@@ -73,7 +72,7 @@ A single JSON object: `status` (`detected` | `blocked`), `state` (one of the six
 
 ## Limitations
 
-- The analyzer keeps using the seeded FlexiPage as its cross-release read signal. On releases containing W-24039822, `service-omni-command-center-configure` can write and re-read the preference through `Settings:OmniChannel`.
+- The `CommandCenterForServiceV2` org preference has no supported public read; its state is **inferred** from the seeded FlexiPage (the platform seeds on the ON-flip). This is called out in `signals` and is why a bare capability-without-seed reads as `v2_available_not_enabled`.
 - The release gater cannot be read directly; capability is inferred from the presence of the user-permission column on the org schema.
 - Tab detection is best-effort; when the tab query cannot run, `v2_tab_present` is `"unknown"` and state is derived from the remaining signals.
 - Read-only: it never enables V2, seeds pages, assigns permissions, or deploys config.