@salesforce/afv-skills 1.65.0 → 1.65.1

package/skills/automation-flow-coordinate/references/shared/end/end.md

@@ -1,267 +0,0 @@
----
-name: flow-end
-description: "FlowEnd (End node) metadata shape — the explicit terminal node that a terminating branch's connector targets. Covers the ends[] entry fields, WHEN an explicit End is emitted (GENERATE on AUTO_LAYOUT_CANVAS at apiVersion >= 68.0) versus the implicit omit-the-connector end, the never-on-Free-Form exclusion, and the per-branch-or-shared End topology (each terminating branch may have its own End or converge on a shared End — both valid). Load when emitting or reading End nodes in a flow payload. See shared/anti-patterns.md item 38 for why a shared End does not break auto-layout and why a fault pointed directly at an End is silently dropped (advisory, not a defect)."
-metadata:
-  version: "1.0"
-  related-skills: flow-connector, flow-node, flow-metadata-schema
----
-
-# FlowEnd — Explicit End Node
-
-An **End** is a terminal node: the node a terminating branch's connector points
-at when the branch stops the flow. End nodes live in the top-level **`ends[]`**
-array of the flow metadata (a sibling of `assignments`, `decisions`, etc. — see
-`shared/flow-metadata-schema.md`). Each entry defines one End.
-
-In a `.flow-meta.xml` each End is one `<ends>` element (plural, the same name as
-the JSON key) holding `<name>`, `<locationX>` and `<locationY>`. An `<end>`
-element fails the deploy with `Error parsing file: Element
-{http://soap.sforce.com/2006/04/metadata}end invalid at this location in type Flow`.
-
-An End is a `FlowNode` subclass (`FlowEnd` — see `shared/node/node.md`): it takes
-`name`, optional `label`/`description`, `locationX`/`locationY`, and the optional
-`group` back-reference (see [The `group` attribute](#the-group-attribute)). It has
-**no connector of any kind** — nothing flows out of an End.
-
-There are **two** ways a branch can terminate in a flow, and which one to use is
-decided entirely by the rule below:
-
-- **Explicit End** — an `ends[]` entry, targeted by one or more connectors
-  (`"connector": { "targetReference": "END_ELEMENT_1" }`; several non-fault
-  connectors may converge on one End — a valid shared End). **Stored in metadata.**
-- **Implicit end** — the branch's last element simply omits its `connector`. The
-  End is *not* serialized; the platform infers it.
-
----
-
-## When to emit an explicit End (the deciding rule)
-
-> **GENERATE, `AUTO_LAYOUT_CANVAS`, resolved `apiVersion` ≥ 68.0 → emit an
-> explicit End per terminating branch.** This is the default on a 68-capable org.
-> Explicit End nodes became storable metadata in API version 68.0; on such an org
-> the author recipe stores ends in metadata rather than relying on the implicit
-> omit-the-connector form, matching how Flow Builder itself serializes an
-> auto-layout flow.
-
-The resolved `apiVersion` is `max(apiVersionsList)` from `GET /services/data/vXX.0/flowbuilder/flow/version-info`
-(currently 68) — see `recipes/author/author.md` Phase 3 step 3 and
-`shared/flow-properties/flow-properties.md` § apiVersion. Emit the implicit end
-(omit the connector) instead in every other case:
-
-| Situation | Terminating branch → |
-|---|---|
-| GENERATE, `AUTO_LAYOUT_CANVAS`, `apiVersion` ≥ 68.0 | **explicit End** (`ends[]` entry, one connector into it) |
-| GENERATE, `apiVersion` < 68.0 (org max below 68) | implicit end (omit the connector) — explicit ends are not storable |
-| **Free-Form (`FREE_FORM_CANVAS`, or no `CanvasMode` PMV → opens Free-Form)** | **NEVER emit `ends[]`** — Free-Form flows do not support explicit End nodes. Omit the connector. |
-| EVOLVE (edit of a retrieved flow) | **preserve the source's `ends[]` verbatim**; add explicit Ends only for the terminating branches you introduce, and only if the source is auto-layout (see § EVOLVE) |
-
-**The rule is persistence-independent.** It applies to any flow the skill emits at
-v68+ auto-layout — the flow MCP save JSON payload *and* a `.flow-meta.xml` written
-to the project for a metadata deploy. A metadata deploy (e.g. `sf project deploy`)
-stores the flow **verbatim**: it does not synthesize End nodes, so any missing
-`ends[]` stays missing on the org and on the next retrieve. If the skill writes
-metadata XML instead of calling the save endpoint, it must still author the
-`<ends>` elements and point each terminating branch's connector at one.
-
-**Free-Form is a hard exclusion.** Never generate `ends[]` for a Free-Form flow,
-and never add an End when rewriting a retrieved Free-Form source. Canvas mode is
-carried by the `CanvasMode` process metadata value; a flow with no `CanvasMode`
-PMV opens Free-Form (see `shared/anti-patterns.md` item 37), so it is treated as
-Free-Form for this rule.
-
-**Implicit termination is NOT Free-Form.** Whether `ends[]` is stored has **no
-bearing** on canvas mode — canvas mode is set *only* by the `CanvasMode` PMV.
-Below 68.0 (and any time a branch terminates by omitting its connector), the flow
-is **still `AUTO_LAYOUT_CANVAS`** and still emits the `CanvasMode` PMV; it just
-terminates implicitly instead of storing End nodes. Do **not** reason "no `ends[]`
-⇒ the flow opens in Free-Form" — that is false, and it is never a reason to drop
-the `CanvasMode` PMV or to stop treating the flow as auto-layout. A sub-68
-auto-layout flow with omitted connectors opens in Auto-Layout exactly like a v68+
-one; the only difference is the End nodes are inferred rather than stored.
-
-Emitting a dedicated per-branch End under this rule is **not** fabrication — it is
-the v68+ auto-layout GENERATE default. The "never fabricate End elements"
-guidance in `shared/anti-patterns.md` item 38 applies to the cases where an
-explicit End is *not* called for (below 68.0, Free-Form, or EVOLVE preservation),
-not to this default.
-
----
-
-## `ends[]` entry fields
-
-| Field | Type | Required | Notes |
-|---|---|---|---|
-| `name` | string | yes | Unique dev-name; matches `[A-Za-z][A-Za-z0-9_]*`, ≤ 80 chars. Flow Builder names these `END_ELEMENT_1`, `END_ELEMENT_2`, … — follow that convention. Numbers need not be contiguous, but every End's `name` must be **unique** within the flow and is the value the terminating branch's `connector.targetReference` points at. |
-| `label` | string | no | Usually omitted / `null` — Flow Builder does not label End nodes. |
-| `description` | string | no | Usually omitted / `null`. |
-| `locationX` | number | yes | Canvas X. Use `0` for auto-layout flows (see `shared/node/node.md`). |
-| `locationY` | number | yes | Canvas Y. Use `0` for auto-layout flows. |
-| `group` | string | conditional | Present only when the End sits inside a group boundary; omitted otherwise. See [The `group` attribute](#the-group-attribute). |
-
-An End entry has **no `connector`, no `faultConnector`, and no other outgoing
-field** — it is a sink. It is reached, never left.
-
----
-
-## The `group` attribute
-
-`group` is the generic FlowNode membership back-reference (`shared/node/node.md`
-§ `group`): the `name` of the group container an element sits inside, present only
-when the element falls within a group boundary and omitted otherwise. An End is a
-FlowNode, so it carries `group` on exactly the same terms as any other element.
-
-For a net-new flow this attribute does not arise on its own — the author recipe
-does not generate group containers, so a generated End carries **no** `group`. It
-shows up only when **preserving** a retrieved source (EVOLVE) that already places
-an End inside a group: keep the source's `group` value verbatim, exactly as you
-preserve the rest of the `ends[]` entry. Do not add, remove, or re-derive a
-`group` on an End.
-
-```jsonc
-"ends": [
-  { "name": "END_ELEMENT_1", "locationX": 0, "locationY": 0 },                 // no group
-  { "name": "END_ELEMENT_2", "group": "Group_1", "locationX": 0, "locationY": 0 } // preserved from source
-]
-```
-
----
-
-## Referential integrity — connectors and `ends[]` are co-emitted
-
-An explicit End has **two halves that must be emitted together**:
-
-1. the terminating element's `connector` (or `defaultConnector` / `nextValueConnector` / `noMoreValuesConnector`) whose `targetReference` is the End's `name`, and
-2. the matching entry in the top-level `ends[]` array with that exact `name`.
-
-**Emit both or neither.** If you decide a branch terminates at an explicit End
-(the v68+ auto-layout default), you MUST both point its connector at
-`END_ELEMENT_n` **and** add `{ "name": "END_ELEMENT_n", ... }` to `ends[]`. A
-connector that targets an End with no matching `ends[]` entry fails the save with
-**"`<EndName>` not found"** (e.g. `End_Main not found`) — the same
-lookup-by-dev-name failure as a dangling connector (`shared/anti-patterns.md`
-item 14).
-
-**The fix for "`<EndName>` not found" is to ADD the missing `ends[]` entry — never
-to remove the connector.** Removing the connector deletes the terminating branch
-and silently changes the flow's behavior; the branch still needs to end. The
-`ends[]` array is the last thing built (`recipes/author/author.md` Build Order
-step 6), so a wired-but-undefined End is the classic slip — the pre-save check
-(author.md Phase 3 step 4) verifies every End target resolves.
-
-The invariant is **bidirectional**: every End-targeting connector resolves to an
-`ends[]` entry with that exact name, and every `ends[]` entry is targeted by at
-least one connector (no orphan Ends, no dangling End references). A shared End —
-one entry targeted by 2+ non-fault connectors — is valid; see § Topology rules.
-
-**Do not misdiagnose "`<EndName>` not found" as a version cap.** It is a
-referential-integrity error, never evidence that the org lacks v68 or that ends
-are unsupported. The org's ends support is decided **only** by the verified
-`max(apiVersionsList)` from `GET /services/data/vXX.0/flowbuilder/flow/version-info` (resolved up front — see
-`recipes/author/author.md` Phase 3 step 3), never inferred from a save failure. On
-this error, do NOT lower `apiVersion`, drop `ends[]`, switch the branch to implicit
-termination, or claim the flow "opens in Free-Form" — add the missing `ends[]`
-entry and re-save at the same version.
-
-## Topology rules (auto-layout)
-
-These match `shared/anti-patterns.md` item 38 — the rule is that in v68 ALC every
-terminating branch reaches an explicit End; how connectors converge is flexible:
-
-1. **Every terminating branch reaches an explicit End.** On GENERATE with
-   `AUTO_LAYOUT_CANVAS` at resolved `apiVersion` ≥ 68.0, co-emit the connector
-   and its matching `ends[]` entry. This includes the easy-to-miss termini: a
-   loop `noMoreValuesConnector`, a loop `nextValueConnector` (body) terminus, a
-   Decision `defaultConnector` terminus, and any decision rule/outcome terminus.
-2. **A shared End is valid; so is one End per branch.** Two or more **non-fault**
-   connectors converging on one `ends[]` entry is a legal, Flow-Builder-native
-   auto-layout shape (e.g. a Decision default and another outcome both ending at
-   one End). One dedicated End per branch is equally valid. Neither is mandated —
-   never "split" a shared End, never flag one as a defect. (Implicit ends can't
-   be shared: an omitted connector targets nothing.)
-3. **A `faultConnector` into an End is silently dropped, not fatal.** A fault
-   whose direct target is an End — or an empty/unwired fault — is removed on
-   reload; the flow stays `AUTO_LAYOUT_CANVAS` and does **not** fall back to
-   Free-Form. The only real cost is silent loss of that error path, so when you
-   want faults handled, route each to a real handler (a `Log_Error` /
-   `Handle_Fault` Assignment, `customErrors`, or an error screen) that reaches
-   *its own* End. A fault may also validly terminate at an End through a handler.
-
-See `shared/anti-patterns.md` item 38 for the full behavior, and item 34 for the
-orthogonal runtime concern (a fault rejoining a continuation that assumes success).
-Mid-graph convergence on a *continuing* element is legal and never flagged.
-
-#### Worked example — a Flow-Builder auto-layout flow with five Ends (`a_new_flow_to_test`)
-
-A real `AUTO_LAYOUT_CANVAS` flow at `apiVersion 68.0`, authored and re-opened
-cleanly in Flow Builder, shows every terminating-branch kind reaching an explicit
-End — including a **shared End** and a **fault that reaches an End through a
-handler**:
-
-```text
-Get_Cases  connector→Copy_1_of_Loop_Cases   faultConnector→Action_1   (fault → handler chain)
-Action_1   connector→END_ELEMENT_6          faultConnector→Action_2
-Action_2   connector→END_ELEMENT_7                                     (fault chain terminates at an End)
-Assignment_3  connector→END_ELEMENT_4                                  (loop-body terminus via nextValue)
-Decision_2 defaultConnector→END_ELEMENT_2                             ┐ shared End: default + Outcome_2
-           Outcome_1→END_ELEMENT_5                                     │  both target END_ELEMENT_2
-           Outcome_2→END_ELEMENT_2                                     ┘
-ends[]: END_ELEMENT_2, _4, _5, _6, _7   (END_ELEMENT_2 targeted twice — a valid shared End)
-```
-
-Takeaways: (1) `END_ELEMENT_2` is reached by two non-fault connectors and is
-perfectly valid — do NOT split it. (2) The `Get_Cases`/`Action_1` faults route to
-handler actions that themselves reach Ends; a fault pointed *directly* at an End
-(or left empty) is simply dropped on reload, not a round-trip breaker — directly
-verified by round-tripping a flow whose `faultConnector` targets an `END_ELEMENT`:
-the fault is removed and the flow stays `AUTO_LAYOUT_CANVAS`. (3)
-Each Decision outcome, the loop-body assignment, and each action terminus all reach
-an explicit End — that is the v68 obligation. (The source's `InvalidDraft` status
-came from empty element configs — an empty `Assignment_3` and `operator:None`
-outcomes — not from the End topology.)
-
----
-
-## EVOLVE
-
-On an edit of a retrieved flow, **preserve the source's `ends[]` verbatim** —
-never inject ends into, remove ends from, or restructure the end topology of an
-edited flow. "Preserve the existing `ends[]`" means keep each inherited End for
-the branch that already single-targets it — it does **not** mean fanning new
-branches or faults into an inherited End. Give each **new** terminating branch
-you add its **own** dedicated End (auto-layout sources only), and route new
-faults to a dedicated handler. Never add ends to a retrieved Free-Form source.
-See `shared/connector/connector.md` § End topology (auto-layout) EVOLVE worked
-example and `shared/anti-patterns.md` item 38 § EVOLVE note.
-
----
-
-## JSON structure
-
-**Explicit End targeted by a terminating branch (auto-layout, v68+):**
-```jsonc
-// terminating element
-{ "name": "Set_Result", "connector": { "targetReference": "END_ELEMENT_1" } }
-// ...
-"ends": [ { "name": "END_ELEMENT_1", "locationX": 0, "locationY": 0 } ]
-```
-
-**Implicit end (< v68, Free-Form, or org max below 68) — no `ends[]` entry:**
-```jsonc
-{ "name": "Set_Result" }   // no connector; End is inferred, not serialized
-```
-
-See `end/examples/` for runnable fragments.
-
----
-
-## See Also
-
-- `shared/connector/connector.md` — § End topology (auto-layout): the connector
-  side of the same rule, and the EVOLVE worked example.
-- `shared/node/node.md` — `FlowEnd` is a `FlowNode` subclass; the generic `group`
-  membership attribute.
-- `shared/anti-patterns.md` item 38 — a shared End is valid (does not break
-  auto-layout) and a fault pointed directly at an End is silently dropped on
-  reload (advisory, not a defect); item 37 — the `CanvasMode` PMV that decides
-  auto-layout vs. Free-Form.
-- `shared/flow-metadata-schema.md` — the top-level `ends[]` array key.

package/skills/automation-flow-coordinate/references/shared/flow-type-resolver/eval/README.md

@@ -1,69 +0,0 @@
-# flow-type-resolver — evaluation & validation
-
-Two independent checks guard this skill. They answer different questions.
-
-## 1. `verify_supported_types.py` — is the supported set *correct*? (org-check)
-
-Validates that every tuple in `taxonomy.json`'s authoritative `supportedTuples` set is
-actually a valid flow type in the connected Salesforce org. This is the guarantee that
-Project Codey never claims to support a flow type the platform rejects.
-
-**Validity rules** (see `taxonomy.json.supportedTuples.$comment`):
-
-- `processType` must be in `GET /flowbuilder/schema/process-types`.
-- A triggered tuple's `triggerType` must be in
-  `GET /flowbuilder/schema/trigger-types?processType=<pt>`.
-- A **no-trigger** tuple (no `triggerType`) is valid **by absence** — the org's
-  trigger-types list does not contain a `None` entry; a no-trigger flow simply omits the
-  trigger. Membership of the `processType` is sufficient.
-- `runInMode`, when declared, must be in `getFlowCapabilities.runInModes`.
-- `recordTriggerType` is **advisory**: `getFlowCapabilities` returns `200` even for an
-  invalid `recordTriggerType` (e.g. `RecordBeforeSave` + `Delete`), so the read endpoints do
-  not gate it — it is enforced only at save-time. The script only sanity-checks it against
-  `enums.recordTriggerType`.
-
-**Run it:**
-
-```bash
-# from repo root, so test-agent/.env resolves
-set -a; . test-agent/.env; set +a          # exports CORE_ORG_ALIAS
-python3 contributed-skills/flow-agentic-ai/automation-flow-coordinate/references/shared/flow-type-resolver/eval/verify_supported_types.py
-# or: python3 .../eval/verify_supported_types.py --org <alias> --api-version v68.0
-```
-
-Exits `0` if every supported tuple is valid; non-zero (listing each violation) otherwise.
-It also prints, per processType, the org-supported triggers the taxonomy **intentionally
-omits** — the supported set is a curated subset, not a mirror of everything the org allows,
-so review that list when you change `supportedTuples`. Requires the `sf` CLI
-(`sf api request rest`) and an authenticated org alias.
-
-## 2. `score.py` — does the resolver *classify correctly*? (behavioral eval)
-
-Scores the resolver's specCategory predictions (`predictions.jsonl`) against the curated
-fixture (`prompts.jsonl`), normalizing through `taxonomy.json`'s alias map, and gates on
-overall accuracy. See the header of `score.py`.
-
-A fixture row can also set `"expectAsk": true|false`. On those rows the prediction's
-`mustAsk` (missing counts as `false`) has to match too, so a prompt the resolver must ask
-about is a miss if it is answered without asking, and the other way round. The `FT-CRM`
-rows use this: a "CRM Triggered Flow" request that says "marketing" resolves with no
-question, and one that does not is asked first.
-
-```bash
-python3 contributed-skills/flow-agentic-ai/automation-flow-coordinate/references/shared/flow-type-resolver/eval/score.py --gate 0.95
-```
-
-**What this does and does not prove.** `predictions.jsonl` is a **committed snapshot** of the
-resolver's output for each fixture prompt — `score.py` reads it as-is and does **not**
-re-run the resolver. So the gate catches a `taxonomy.json` alias/normalizer break (a
-prediction that no longer maps to a known category) but **not** a live-classification
-regression: if a taxonomy or reasoning-engine change would make the resolver classify a
-prompt differently, that only shows up once you **regenerate `predictions.jsonl`** by
-re-running the resolver over `prompts.jsonl` and re-scoring. Treat a green `score.py` as
-"the committed predictions still normalize and clear the gate," not "the current resolver
-still classifies these correctly."
-
-Current score: **79/80 (98.8%)**. The lone miss is `FT-AUTO-003` — a button-invoked, flat
-headless clone process (expected `Autolaunched`) that the resolver reads as `Screen`. It is
-a documented hard case, kept in the fixture as an honest miss rather than hand-corrected in
-`predictions.jsonl`.

package/skills/automation-flow-coordinate/references/shared/flow-type-resolver/eval/predictions.jsonl

@@ -1,80 +0,0 @@
-{"id":"FT-SCRN-001","specCategory":"Screen"}
-{"id":"FT-AUTO-001","specCategory":"Autolaunched"}
-{"id":"FT-RTRIG-001","specCategory":"RecordTriggered"}
-{"id":"FT-SCHED-001","specCategory":"Scheduled"}
-{"id":"FT-PEVT-001","specCategory":"PlatformEvent"}
-{"id":"FT-SEG-001","specCategory":"Segment"}
-{"id":"FT-RTORCH-001","specCategory":"RecordTriggeredOrchestration"}
-{"id":"FT-AUTORCH-002","specCategory":"AutolaunchedOrchestration"}
-{"id":"FT-RTAPPR-004","specCategory":"RecordTriggeredApprovalOrchestration"}
-{"id":"FT-AUTAPPR-004","specCategory":"AutolaunchedApprovalOrchestration"}
-{"id":"FT-SCRN-002","specCategory":"Screen"}
-{"id":"FT-AUTO-002","specCategory":"Autolaunched"}
-{"id":"FT-RTRIG-002","specCategory":"RecordTriggered"}
-{"id":"FT-SCHED-002","specCategory":"Scheduled"}
-{"id":"FT-PEVT-002","specCategory":"PlatformEvent"}
-{"id":"FT-SEG-002","specCategory":"Segment"}
-{"id":"FT-RTORCH-002","specCategory":"RecordTriggeredOrchestration"}
-{"id":"FT-AUTORCH-003","specCategory":"AutolaunchedOrchestration"}
-{"id":"FT-RTAPPR-005","specCategory":"RecordTriggeredApprovalOrchestration"}
-{"id":"FT-AUTAPPR-005","specCategory":"AutolaunchedApprovalOrchestration"}
-{"id":"FT-SCRN-003","specCategory":"Screen"}
-{"id":"FT-AUTO-003","specCategory":"Screen"}
-{"id":"FT-RTRIG-003","specCategory":"RecordTriggered"}
-{"id":"FT-SCHED-003","specCategory":"Scheduled"}
-{"id":"FT-PEVT-003","specCategory":"PlatformEvent"}
-{"id":"FT-SEG-003","specCategory":"Segment"}
-{"id":"FT-RTORCH-003","specCategory":"RecordTriggeredOrchestration"}
-{"id":"FT-AUTORCH-004","specCategory":"AutolaunchedOrchestration"}
-{"id":"FT-RTAPPR-006","specCategory":"RecordTriggeredApprovalOrchestration"}
-{"id":"FT-AUTAPPR-006","specCategory":"AutolaunchedApprovalOrchestration"}
-{"id":"FT-SCRN-004","specCategory":"Screen"}
-{"id":"FT-AUTO-004","specCategory":"Autolaunched"}
-{"id":"FT-RTRIG-004","specCategory":"RecordTriggered"}
-{"id":"FT-SCHED-004","specCategory":"Scheduled"}
-{"id":"FT-PEVT-004","specCategory":"PlatformEvent"}
-{"id":"FT-SEG-004","specCategory":"Segment"}
-{"id":"FT-RTORCH-004","specCategory":"RecordTriggeredOrchestration"}
-{"id":"FT-RTAPPR-001","specCategory":"RecordTriggeredApprovalOrchestration"}
-{"id":"FT-AUTAPPR-001","specCategory":"AutolaunchedApprovalOrchestration"}
-{"id":"FT-SCRN-005","specCategory":"Screen"}
-{"id":"FT-AUTO-005","specCategory":"Autolaunched"}
-{"id":"FT-RTRIG-005","specCategory":"RecordTriggered"}
-{"id":"FT-SCHED-005","specCategory":"Scheduled"}
-{"id":"FT-PEVT-005","specCategory":"PlatformEvent"}
-{"id":"FT-SEG-005","specCategory":"Segment"}
-{"id":"FT-RTORCH-005","specCategory":"RecordTriggeredOrchestration"}
-{"id":"FT-RTAPPR-002","specCategory":"RecordTriggeredApprovalOrchestration"}
-{"id":"FT-AUTAPPR-002","specCategory":"AutolaunchedApprovalOrchestration"}
-{"id":"FT-SCRN-006","specCategory":"Screen"}
-{"id":"FT-AUTO-006","specCategory":"Autolaunched"}
-{"id":"FT-RTRIG-006","specCategory":"RecordTriggered"}
-{"id":"FT-SCHED-006","specCategory":"Scheduled"}
-{"id":"FT-PEVT-006","specCategory":"PlatformEvent"}
-{"id":"FT-SEG-006","specCategory":"Segment"}
-{"id":"FT-AUTORCH-001","specCategory":"AutolaunchedOrchestration"}
-{"id":"FT-RTAPPR-003","specCategory":"RecordTriggeredApprovalOrchestration"}
-{"id":"FT-AUTAPPR-003","specCategory":"AutolaunchedApprovalOrchestration"}
-{"id":"FT-IRR-001","specCategory":"IndivRelatedRecord"}
-{"id":"FT-IRR-002","specCategory":"IndivRelatedRecord"}
-{"id":"FT-IRR-003","specCategory":"RecordTriggered"}
-{"id":"FT-IRR-004","specCategory":"IndivRelatedRecord","mustAsk":false}
-{"id":"FT-IRR-005","specCategory":"RecordTriggered","mustAsk":false}
-{"id":"FT-IRR-006","specCategory":"AutomationEvent"}
-{"id":"FT-FORM-001","specCategory":"FormSubmissionEvent"}
-{"id":"FT-FORM-002","specCategory":"FormSubmissionEvent"}
-{"id":"FT-FORM-003","specCategory":"Screen"}
-{"id":"FT-CRM-001","specCategory":"IndivRelatedRecord","mustAsk":true}
-{"id":"FT-CRM-002","specCategory":"IndivRelatedRecord","mustAsk":true}
-{"id":"FT-CRM-003","specCategory":"IndivRelatedRecord","mustAsk":false}
-{"id":"FT-CRM-004","specCategory":"RecordTriggered","mustAsk":false}
-{"id":"FT-CRM-005","specCategory":"DataCloudDataChange","mustAsk":false}
-{"id":"FT-CRM-006","specCategory":"IndivRelatedRecord","mustAsk":false}
-{"id":"FT-CRM-007","specCategory":"IndivRelatedRecord","mustAsk":true}
-{"id": "FT-OND-001", "specCategory": "OnDemand"}
-{"id": "FT-OND-002", "specCategory": "OnDemand"}
-{"id": "FT-OND-003", "specCategory": "Autolaunched"}
-{"id": "FT-OND-004", "specCategory": "Autolaunched"}
-{"id": "FT-OND-005", "specCategory": "OnDemand"}
-{"id": "FT-OND-006", "specCategory": "OnDemand"}
-{"id": "FT-OND-007", "specCategory": "Autolaunched"}

package/skills/automation-flow-coordinate/references/shared/flow-type-resolver/eval/prompts.jsonl

@@ -1,116 +0,0 @@
-# Curated flow-type-resolver behavioral eval fixture. One {id,prompt,expected} per line;
-# `#`/`//` lines are skipped by the scorer. `expected` is a canonical
-# taxonomy specCategory.
-#
-# COVERAGE NOTE (project-codey port): this 60-prompt fixture covers the 10 families the
-# source PR shipped plus IndivRelatedRecord (Engagement / Journey-Triggered, family
-# FT-IRR), added for the individual-related-record routing and $Input record-context
-# work. It still has NO prompts for the other four trigger categories added during the
-# project-codey port (AutomationEvent, List, CampaignMember, RecordQuery). Running this
-# fixture validates the covered families did not REGRESS; it does NOT validate those
-# four categories. See CURATION.md.
-#
-# STATUS: OVERALL accuracy gated at 0.95. Source PR scored 98.2% (56/57 on the original
-# families); the lone miss is FT-AUTO-003 (button-invoked flat Autolaunched flow read as
-# Screen), kept as an honest hard case rather than dropped. This fixture adds the FT-IRR
-# family for 60 prompts total, then the FT-FORM family (FormSubmissionEvent, plus a
-# Screen look-alike and an Automation Event-worded prompt that must still resolve to
-# FormSubmissionEvent) for 63, then the FT-CRM family for 70. FT-CRM rows carry
-# "expectAsk": a CRM Triggered Flow ("CRM Triggered" / "CRM Trigger") request that says
-# "marketing" resolves to IndivRelatedRecord with no question; one that does not say
-# "marketing" leans IndivRelatedRecord but must ask (marketing Automation Event or
-# Record-Triggered Flow). Two look-alikes must not route there at all (a plain Contact
-# update with no CRM Triggered name stays RecordTriggered; a Data Cloud DMO change stays
-# DataCloudDataChange). The FT-OND family (OnDemandNoTrigger) brings it to 77: an On-Demand
-# Flow request and an "autolaunched" marketing send that the API starts for one person
-# resolve to OnDemand; an "on-demand flow" that Apex calls with no marketing send, and an
-# autolaunched flow that sends a plain email, stay Autolaunched; an On-Demand Flow named as
-# the type stays OnDemand even with no send. An API-started email "with consent from" a
-# subscription is a marketing send (OnDemand) even though the prompt never says marketing;
-# an API-started Email Alert stays Autolaunched. FT-IRR-004..006 bring it to 80: a user's
-# request word for word, a marketing "automation event flow" that triggers when a Lead's
-# status is Nurturing and sends to a journey, resolves to IndivRelatedRecord with no
-# question; the same Lead change with no marketing action stays RecordTriggered; and a
-# marketing "automation event flow" that starts on an email link click stays AutomationEvent.
-# FT-OND and FT-IRR-004..006 predictions were produced blind by an agent that read only
-# flow-type-resolver.md and taxonomy.json.
-{"id":"FT-SCRN-001","prompt":"Add a button to the Account page that walks a rep through a short form to capture renewal intent — the rep picks a renewal date, selects a reason code, and confirms before the record is updated.","expected":"Screen"}
-{"id":"FT-SCRN-002","prompt":"Build a multi-step wizard that sales reps launch from the Opportunity page to log a verbal commitment: first screen collects close date and amount, second screen lets them attach a note, then it saves everything on finish.","expected":"Screen"}
-{"id":"FT-SCRN-003","prompt":"I need a guided process a service agent can open from a Case to walk through a return request — they enter the product serial number, pick a return reason from a dropdown, and confirm the customer's shipping address before submitting.","expected":"Screen"}
-{"id":"FT-SCRN-004","prompt":"Create a step-by-step data-entry helper that customer success managers open via a custom button on the Contact record to collect NPS survey responses during a call — three screens, one question each, then save the results.","expected":"Screen"}
-{"id":"FT-SCRN-005","prompt":"When a finance team member clicks 'Submit Expense' on an Expense Report record, open a series of screens where they fill in receipt amounts, select a cost center, and upload a photo before the record is marked ready for approval.","expected":"Screen"}
-{"id":"FT-SCRN-006","prompt":"Build a new-lead intake form that inside sales reps pop open from the Leads list view: first screen captures company name and industry, second screen lets the rep assign a campaign source, and the last screen confirms before creating the Lead record.","expected":"Screen"}
-{"id":"FT-AUTO-001","prompt":"I need a reusable piece of logic that calculates a tiered discount percentage based on an Opportunity's annual contract value — my other flows will call it and pass in the amount to get back a discount rate.","expected":"Autolaunched"}
-{"id":"FT-AUTO-002","prompt":"Build a utility that our Apex service class can invoke to create a follow-up Task on any Account, passing in the subject, due date, and owner at runtime.","expected":"Autolaunched"}
-{"id":"FT-AUTO-003","prompt":"When a sales rep clicks a custom button on the Opportunity record, kick off a process that clones the opportunity and all its line items into a new draft record.","expected":"Autolaunched"}
-{"id":"FT-AUTO-004","prompt":"I want a standalone piece of automation that my order management Apex code can call to update the related Contract's status and send a confirmation email whenever a payment is posted.","expected":"Autolaunched"}
-{"id":"FT-AUTO-005","prompt":"Create a reusable block that other flows in our org can invoke as a subflow: given a Contact ID, it looks up the Contact's Account tier and returns the appropriate SLA level.","expected":"Autolaunched"}
-{"id":"FT-AUTO-006","prompt":"Set up a headless routine that our nightly batch Apex job can trigger to archive closed Cases older than 90 days by stamping an Archive_Date__c field and moving them to a cold storage record type.","expected":"Autolaunched"}
-{"id":"FT-RTRIG-001","prompt":"Whenever a new Opportunity is created with an amount over $50,000, automatically assign it to the Enterprise Sales queue and send the account owner an email notification.","expected":"RecordTriggered"}
-{"id":"FT-RTRIG-002","prompt":"Each time a Case status changes to 'Resolved', stamp the current date on a custom Resolved_Date__c field and update the related contact's Last_Support_Date__c.","expected":"RecordTriggered"}
-{"id":"FT-RTRIG-003","prompt":"As soon as a new Lead is saved with a country of 'Germany', set the Lead Owner to the EMEA round-robin queue and mark the region picklist as 'EMEA'.","expected":"RecordTriggered"}
-{"id":"FT-RTRIG-004","prompt":"When an Account's Annual Revenue field is updated to exceed one million dollars, automatically create a follow-up Task for the account owner due in three business days.","expected":"RecordTriggered"}
-{"id":"FT-RTRIG-005","prompt":"Any time a Contract record is deleted, log a custom Audit_Log__c record capturing the contract name, owner, and the timestamp of deletion.","expected":"RecordTriggered"}
-{"id":"FT-RTRIG-006","prompt":"The moment a Work Order is created with Priority set to 'Critical', immediately create a child Work Order Line Item, notify the field service manager via email, and set the target response time to two hours.","expected":"RecordTriggered"}
-{"id":"FT-SCHED-001","prompt":"Every night at midnight, find all Opportunities whose Close Date has passed and Status is still 'Open', then update their Stage to 'Closed Lost'.","expected":"Scheduled"}
-{"id":"FT-SCHED-002","prompt":"Each Monday morning, roll up the total number of won deals from the previous week onto each Account's 'Weekly Wins' field so the sales dashboard stays current.","expected":"Scheduled"}
-{"id":"FT-SCHED-003","prompt":"Run a daily job that scans all Cases open longer than 10 days and bumps their Priority to 'High' if it hasn't been set already.","expected":"Scheduled"}
-{"id":"FT-SCHED-004","prompt":"Once a month, zero out the 'Monthly Call Count' field on every Contact record so reps start each billing cycle with a clean slate.","expected":"Scheduled"}
-{"id":"FT-SCHED-005","prompt":"Every weekday at 7 AM, check which Leads haven't been touched in 30 days and assign them to the round-robin queue for re-engagement.","expected":"Scheduled"}
-{"id":"FT-SCHED-006","prompt":"Set up a nightly batch that looks for any active Contracts whose end date falls within the next 14 days and creates a renewal Opportunity linked to the parent Account.","expected":"Scheduled"}
-{"id":"FT-PEVT-001","prompt":"Whenever our payment processor publishes a Payment_Completed__e message to the event bus, pick it up and automatically update the related Order record's status to 'Paid' and close the linked invoice.","expected":"PlatformEvent"}
-{"id":"FT-PEVT-002","prompt":"Our IoT monitoring platform fires a Device_Alert__e event each time a sensor threshold is breached — subscribe to that event channel and create a high-priority maintenance Case for the affected equipment.","expected":"PlatformEvent"}
-{"id":"FT-PEVT-003","prompt":"When the external ERP pushes a Stock_Depleted__e event into Salesforce, catch it and automatically generate a new Purchase_Order__c record for the product that needs restocking.","expected":"PlatformEvent"}
-{"id":"FT-PEVT-004","prompt":"Listen for Shipment_Dispatched__e events coming from the fulfillment system and, each time one arrives, flip the related Opportunity stage to 'Fulfilled' and fire off a customer confirmation email.","expected":"PlatformEvent"}
-{"id":"FT-PEVT-005","prompt":"Our HR platform emits an Employee_Offboarded__e event when someone leaves; build something that subscribes to that event and deactivates the matching Salesforce user while reassigning their open Cases.","expected":"PlatformEvent"}
-{"id":"FT-PEVT-006","prompt":"Set up automation that waits for a Fraud_Flagged__e event from the risk-scoring service and, as soon as one comes in, creates a follow-up Task on the associated Account for the compliance team to review.","expected":"PlatformEvent"}
-{"id":"FT-SEG-001","prompt":"Whenever a contact qualifies for our 'High-Value Prospects' audience in Marketing Cloud, automatically send them a personalized introductory email and update their Lead Score field on their Contact record.","expected":"Segment"}
-{"id":"FT-SEG-002","prompt":"As soon as a lead enters the 'Dormant Accounts – 90 Days' re-engagement audience, send a win-back offer email and set the Re_Engagement_Sent__c checkbox to true on the Lead.","expected":"Segment"}
-{"id":"FT-SEG-003","prompt":"When a contact gets added to the 'Trade Show Attendees Fall 2026' segment, send a follow-up email with the recorded session links and stamp the Last_Campaign_Touch__c date field.","expected":"Segment"}
-{"id":"FT-SEG-004","prompt":"Once a lead falls into our 'Cold Nurture' drip audience, assign them to the nurture queue and fire off the first email in the onboarding sequence automatically.","expected":"Segment"}
-{"id":"FT-SEG-005","prompt":"Any time a contact enters the 'Enterprise Trial Users' marketing audience, notify their assigned Account Executive via email and flip the In_Trial_Nurture__c field to true on the Contact.","expected":"Segment"}
-{"id":"FT-SEG-006","prompt":"When someone is added to the 'Churned Customers – Winback' segment, send a discount offer email and create a follow-up Task on the related Account for the CSM to call within three days.","expected":"Segment"}
-{"id":"FT-RTORCH-001","prompt":"When an Opportunity is marked Closed Won, automatically kick off a multi-stage handoff: first assign a solutions architect to scope the implementation, wait for them to submit a plan, then route it to the provisioning team to set up the environment, and finally notify customer success to schedule the kickoff call.","expected":"RecordTriggeredOrchestration"}
-{"id":"FT-RTORCH-002","prompt":"Whenever a high-priority Case is created, coordinate a structured escalation across three teams: a Tier-2 agent investigates and documents root cause, then an engineering lead confirms the fix, then the support manager personally notifies the customer — each stage waiting for the prior one to finish.","expected":"RecordTriggeredOrchestration"}
-{"id":"FT-RTORCH-003","prompt":"When a Job Application record is moved to the 'Offer Extended' stage, trigger a coordinated onboarding prep process where IT, Facilities, and HR each complete their setup tasks in sequence before the new hire's start date.","expected":"RecordTriggeredOrchestration"}
-{"id":"FT-RTORCH-004","prompt":"Once a Work Order is created with Category set to 'Major Repair', automatically begin a staged approval and execution process: a field supervisor assesses the site, then procurement sources the parts, then the assigned technician completes the repair and logs the outcome.","expected":"RecordTriggeredOrchestration"}
-{"id":"FT-RTORCH-005","prompt":"When an Account's tier is upgraded to 'Enterprise', start a multi-team white-glove setup process — a technical architect reviews the account needs, followed by the migration team executing the upgrade, and finally the customer success manager confirms all services are live before closing out the process.","expected":"RecordTriggeredOrchestration"}
-{"id":"FT-AUTORCH-001","prompt":"When a sales rep clicks a 'Start Renewal' button on an Opportunity, we need a coordinated process that routes work to the sales team first to draft the proposal, then to legal for contract review, and finally to finance for pricing sign-off — each team finishing before the next gets their assignment.","expected":"AutolaunchedOrchestration"}
-{"id":"FT-AUTORCH-002","prompt":"Our HR team needs a way to manually kick off a multi-stage new-hire setup process from an Employee record — it should assign equipment tasks to IT, badge and desk setup to Facilities, and system enrollment to Payroll in sequence, with each department tracking their own steps.","expected":"AutolaunchedOrchestration"}
-{"id":"FT-AUTORCH-003","prompt":"Build a process that a project manager can launch from a button on a Project record to coordinate a client go-live: the solutions team configures the environment first, then IT provisions access, and finally the training team schedules onboarding sessions.","expected":"AutolaunchedOrchestration"}
-{"id":"FT-AUTORCH-004","prompt":"Let customer success managers initiate a formal account remediation process from a Case record by clicking a button; the process should assign an investigation step to support engineering, wait for their findings, then route a review step to the account executive before the CSM closes the loop with the customer.","expected":"AutolaunchedOrchestration"}
-{"id":"FT-RTAPPR-001","prompt":"Whenever a new Contract record is created with a Total Value above $50,000, automatically route it first to the Legal team for review and then to the VP of Finance for final sign-off before it can be activated.","expected":"RecordTriggeredApprovalOrchestration"}
-{"id":"FT-RTAPPR-002","prompt":"As soon as an Opportunity's Discount field is updated to more than 20%, kick off a sequential sign-off process where the regional manager approves first, followed by the CFO if the deal is over $100K.","expected":"RecordTriggeredApprovalOrchestration"}
-{"id":"FT-RTAPPR-003","prompt":"The moment a Capital Expenditure Request record is submitted (status flips to 'Pending'), have the department head, then the finance controller, and finally the COO each review and approve in sequence before the funds are released.","expected":"RecordTriggeredApprovalOrchestration"}
-{"id":"FT-RTAPPR-004","prompt":"When a Purchase Order record is created with a line total exceeding $25,000, automatically send it through a two-stage approval: first the procurement lead, then the budget owner, waiting for each person's decision before moving to the next.","expected":"RecordTriggeredApprovalOrchestration"}
-{"id":"FT-RTAPPR-005","prompt":"Any time a Job Requisition record's headcount is changed to more than three open roles, trigger a multi-step sign-off that routes to the HR Business Partner and then to the VP of Talent before the positions can be posted.","expected":"RecordTriggeredApprovalOrchestration"}
-{"id":"FT-RTAPPR-006","prompt":"When a customer Refund Request record is created for amounts over $5,000, automatically escalate it through a sequential review by the billing manager and then the finance director, pausing for each approval before processing the refund.","expected":"RecordTriggeredApprovalOrchestration"}
-{"id":"FT-AUTAPPR-001","prompt":"When a sales rep submits a contract record for sign-off, route it sequentially to the legal reviewer and then the VP of Sales, waiting for each approval before advancing, so the contract status can only become Active once both have authorized it.","expected":"AutolaunchedApprovalOrchestration"}
-{"id":"FT-AUTAPPR-002","prompt":"After a manager clicks the Submit for Review button on a Capital_Expenditure__c record, collect authorizations from the department director and the CFO in sequence before the purchase order is released.","expected":"AutolaunchedApprovalOrchestration"}
-{"id":"FT-AUTAPPR-003","prompt":"When a rep sends an Opportunity with a discount above 20% for approval, get sign-off from the regional VP and then the finance controller—holding each step until the previous approver responds—before the deal can close.","expected":"AutolaunchedApprovalOrchestration"}
-{"id":"FT-AUTAPPR-004","prompt":"When a hiring manager submits a Job_Requisition__c for review, gather approvals from the department head, HR director, and budget committee one after another, waiting at each stage before the requisition can proceed to posting.","expected":"AutolaunchedApprovalOrchestration"}
-{"id":"FT-AUTAPPR-005","prompt":"A sales user submits a high-value Quote for authorization; based on the total amount, route it to one or two pricing managers for sign-off before the quote is allowed to be sent to the customer.","expected":"AutolaunchedApprovalOrchestration"}
-{"id":"FT-AUTAPPR-006","prompt":"When a billing agent submits a large refund request on a Case for approval, first get the billing supervisor's authorization and then the finance director's before the refund is issued to the customer.","expected":"AutolaunchedApprovalOrchestration"}
-{"id":"FT-IRR-001","prompt":"Build an Individual Related Record-Triggered flow on the Lead object that fires when a lead record is updated, then pauses until the customer opens our nurture email before updating the consent status on the linked Individual.","expected":"IndivRelatedRecord"}
-{"id":"FT-IRR-002","prompt":"I need a flow for an individual that runs first when their record is updated and then pauses mid-flow until they click the link in our marketing email, and once they click, sends them a follow-up SMS.","expected":"IndivRelatedRecord"}
-{"id":"FT-IRR-003","prompt":"Create a flow for an individual that sets their Status to Active whenever their Contact record is created or updated.","expected":"RecordTriggered"}
-{"id":"FT-IRR-004","prompt":"I want to create a marketing automation event flow that triggers when Lead status is Nurturing.  The flow should have Send to Journey action which sends to NurtureSeries journey.  Then waits for the Journey Builder Goal Met for that journey.  If the goal is met, then create a high priority task for the Lead owner to follow up.","expected":"IndivRelatedRecord","expectAsk":false}
-{"id":"FT-IRR-005","prompt":"When a Lead's status changes to Nurturing, create a high priority task for the lead owner to follow up.","expected":"RecordTriggered","expectAsk":false}
-{"id":"FT-IRR-006","prompt":"Create a marketing automation event flow that starts when a customer clicks a link in our welcome email and then sends them a follow-up SMS.","expected":"AutomationEvent"}
-{"id":"FT-FORM-001","prompt":"When someone submits our webinar registration form, send them a confirmation email and add them to the webinar campaign.","expected":"FormSubmissionEvent"}
-{"id":"FT-FORM-002","prompt":"Build an Automation Event-triggered flow that fires when a prospect submits our Contact Us form and sets their Lead Rating to Warm.","expected":"FormSubmissionEvent"}
-{"id":"FT-FORM-003","prompt":"Build a form that walks a support agent step by step through collecting a customer's shipping address, then updates their Contact record.","expected":"Screen"}
-{"id":"FT-CRM-001","prompt":"Make me a CRM Triggered Flow that sends an email, the trigger should be everytime a contact is updated","expected":"IndivRelatedRecord","expectAsk":true}
-{"id":"FT-CRM-002","prompt":"Build a CRM Triggered flow on Lead that sends our welcome email whenever a new lead is created.","expected":"IndivRelatedRecord","expectAsk":true}
-{"id":"FT-CRM-003","prompt":"Set up a CRM Trigger so that when a Contact's mailing address is updated we send them our Address Confirmation marketing email.","expected":"IndivRelatedRecord","expectAsk":false}
-{"id":"FT-CRM-004","prompt":"Whenever a Contact is updated, send an email alert to the contact's owner.","expected":"RecordTriggered","expectAsk":false}
-{"id":"FT-CRM-005","prompt":"When a Data Cloud Individual DMO record (ssot__Individual__dlm) is updated, create a follow-up Task for the account owner.","expected":"DataCloudDataChange","expectAsk":false}
-{"id":"FT-CRM-006","prompt":"Make me a marketing CRM Triggered Flow that sends an email, the trigger should be everytime a contact is updated","expected":"IndivRelatedRecord","expectAsk":false}
-{"id":"FT-CRM-007","prompt":"Make a CRM Triggered flow on Contact that does an assignment","expected":"IndivRelatedRecord","expectAsk":true}
-{"id": "FT-OND-001", "prompt": "Build an On-Demand Flow that our mobile app calls through the API to send a welcome SMS to the customer who just signed up.", "expected": "OnDemand"}
-{"id": "FT-OND-002", "prompt": "Create an autolaunched flow our website calls through the REST API to send our marketing welcome email to the person who just registered.", "expected": "OnDemand"}
-{"id": "FT-OND-003", "prompt": "Create an on-demand flow that Apex calls to recalculate an Account's health score and update the record.", "expected": "Autolaunched"}
-{"id": "FT-OND-004", "prompt": "Build an autolaunched flow, called from Apex, that sends a plain notification email to the case owner.", "expected": "Autolaunched"}
-{"id": "FT-OND-005", "prompt": "Create an On-Demand Flow (not a regular autolaunched flow) that our support portal calls through the API to create a Case from a subject and a description.", "expected": "OnDemand"}
-{"id": "FT-OND-006", "prompt": "Build a flow our booking app calls through the API for one guest at a time. It sends them our \"Check-in Reminder\" email from our Front Desk sender, with consent from our \"Guest Updates\" subscription.", "expected": "OnDemand"}
-{"id": "FT-OND-007", "prompt": "Build a flow our booking app calls through the API that fires the \"New Booking\" email alert to the property manager.", "expected": "Autolaunched"}