@runcofactor/cli 0.52.0 → 0.53.0

package/dist/{upgrade-5Y655TQ6.js → upgrade-EJGTMW44.js}

@@ -2,12 +2,12 @@ import { createRequire as __cr } from "module"; import { fileURLToPath as __fup
 import {
   installCommandLine,
   runUpgrade
-} from "./chunk-PRERH4DN.js";
-import "./chunk-QCYSONXI.js";
-import "./chunk-UEJ2HTKU.js";
+} from "./chunk-I2SOHQ2C.js";
+import "./chunk-CRYHWO4M.js";
+import "./chunk-MJVUMVLO.js";
 import "./chunk-TOWZAG3I.js";
 export {
   installCommandLine,
   runUpgrade
 };
-//# sourceMappingURL=upgrade-5Y655TQ6.js.map
+//# sourceMappingURL=upgrade-EJGTMW44.js.map

package/dist/{usage-KCXFY46V.js → usage-GZCQDULF.js}

@@ -1,21 +1,21 @@
 import { createRequire as __cr } from "module"; import { fileURLToPath as __fup } from "url"; import { dirname as __dn } from "path"; const require = __cr(import.meta.url); const __filename = __fup(import.meta.url); const __dirname = __dn(__filename);
 import {
   parseSinceFlag
-} from "./chunk-M752EUK3.js";
-import "./chunk-ROX7N3RK.js";
+} from "./chunk-3JU4UYYN.js";
+import "./chunk-V7HB5LAU.js";
 import {
   apiRequest
-} from "./chunk-LL6TSQWV.js";
+} from "./chunk-VKZOHJCE.js";
 import "./chunk-S3Q7MDCS.js";
-import "./chunk-76Z6E7XX.js";
+import "./chunk-4UZN6TVT.js";
 import {
   getArgValue,
   hasFlag,
   resolveConfig
-} from "./chunk-3HI6QC4V.js";
+} from "./chunk-WRBU6TX7.js";
 import {
   writeRawOutput
-} from "./chunk-UEJ2HTKU.js";
+} from "./chunk-MJVUMVLO.js";
 import "./chunk-TOWZAG3I.js";
 
 // src/usage.ts
@@ -126,4 +126,4 @@ export {
   formatUsageSummary,
   runUsage
 };
-//# sourceMappingURL=usage-KCXFY46V.js.map
+//# sourceMappingURL=usage-GZCQDULF.js.map

package/dist/{utilities-SUON2KZK.js → utilities-RIITD53A.js}

@@ -2,15 +2,15 @@ import { createRequire as __cr } from "module"; import { fileURLToPath as __fup
 import {
   parseDurationSeconds,
   runUtilities
-} from "./chunk-BF3IPGMP.js";
-import "./chunk-LL6TSQWV.js";
+} from "./chunk-XSSZMG65.js";
+import "./chunk-VKZOHJCE.js";
 import "./chunk-S3Q7MDCS.js";
-import "./chunk-76Z6E7XX.js";
-import "./chunk-3HI6QC4V.js";
-import "./chunk-UEJ2HTKU.js";
+import "./chunk-4UZN6TVT.js";
+import "./chunk-WRBU6TX7.js";
+import "./chunk-MJVUMVLO.js";
 import "./chunk-TOWZAG3I.js";
 export {
   parseDurationSeconds,
   runUtilities
 };
-//# sourceMappingURL=utilities-SUON2KZK.js.map
+//# sourceMappingURL=utilities-RIITD53A.js.map

package/dist/{visual-GJZVJC32.js → visual-FH67OKS2.js}

@@ -1,17 +1,17 @@
 import { createRequire as __cr } from "module"; import { fileURLToPath as __fup } from "url"; import { dirname as __dn } from "path"; const require = __cr(import.meta.url); const __filename = __fup(import.meta.url); const __dirname = __dn(__filename);
 import {
   apiRequest
-} from "./chunk-LL6TSQWV.js";
+} from "./chunk-VKZOHJCE.js";
 import "./chunk-S3Q7MDCS.js";
 import {
   VISUAL_CHECKPOINT_STATUSES
-} from "./chunk-76Z6E7XX.js";
+} from "./chunk-4UZN6TVT.js";
 import {
   getArgValue,
   hasFlag,
   resolveConfig
-} from "./chunk-3HI6QC4V.js";
-import "./chunk-UEJ2HTKU.js";
+} from "./chunk-WRBU6TX7.js";
+import "./chunk-MJVUMVLO.js";
 import "./chunk-TOWZAG3I.js";
 
 // src/visual.ts
@@ -104,4 +104,4 @@ async function runVisual(argv) {
 export {
   runVisual
 };
-//# sourceMappingURL=visual-GJZVJC32.js.map
+//# sourceMappingURL=visual-FH67OKS2.js.map

package/dist/{workflow-R5QAXWBX.js → workflow-34YJZ2QQ.js}

@@ -10,25 +10,25 @@ import {
 } from "./chunk-2TIRL6ZK.js";
 import {
   resolveWorkflowIdForRun
-} from "./chunk-G6BCST3G.js";
-import "./chunk-Z3MDQSZG.js";
-import "./chunk-PHNH3CEU.js";
-import {
-  resolveApplicationId
-} from "./chunk-CYSPCGO6.js";
-import "./chunk-775FI436.js";
+} from "./chunk-3ZOUNCA5.js";
+import "./chunk-PJFFGQSB.js";
 import {
   applyWorkflowTagFlags
-} from "./chunk-I5RHTCPY.js";
+} from "./chunk-EL6KJ4PO.js";
+import "./chunk-O4Z44BR7.js";
+import {
+  resolveApplicationId
+} from "./chunk-JEHHEMUL.js";
+import "./chunk-RVD6J6IZ.js";
 import {
   workflowToSpec
-} from "./chunk-ZL4O6C42.js";
+} from "./chunk-HXBK3AGD.js";
 import {
   alignSnapshotNodeIds,
   topoOrderNodes
 } from "./chunk-DEK6B6LX.js";
-import "./chunk-IY3ZK46I.js";
-import "./chunk-ABT3BLRC.js";
+import "./chunk-QOVJUSSL.js";
+import "./chunk-5TKXHS3X.js";
 import {
   apiRequest,
   fetchWorkflowEnvironments,
@@ -37,7 +37,7 @@ import {
   renderWorkflowUserError,
   resolveEnvironmentByNameOrId,
   stripOneTrailingNewline
-} from "./chunk-LL6TSQWV.js";
+} from "./chunk-VKZOHJCE.js";
 import "./chunk-S3Q7MDCS.js";
 import {
   NODE_TYPE_LABEL,
@@ -47,7 +47,7 @@ import {
   isBrowserViewportPreset,
   isWorkflowFlowType,
   normalizeNodeType
-} from "./chunk-76Z6E7XX.js";
+} from "./chunk-4UZN6TVT.js";
 import {
   apiFetch,
   exitOnFailure,
@@ -56,12 +56,12 @@ import {
   hasFlag,
   resolveConfig,
   resolveOrgAppUrl
-} from "./chunk-3HI6QC4V.js";
+} from "./chunk-WRBU6TX7.js";
 import {
   printGuide,
   specExtension,
   writeRawOutput
-} from "./chunk-UEJ2HTKU.js";
+} from "./chunk-MJVUMVLO.js";
 import "./chunk-AK7WEGGB.js";
 import "./chunk-NQ7LMSSS.js";
 import "./chunk-5QHORHJT.js";
@@ -2289,7 +2289,7 @@ function printSeedCreateHelp() {
 }
 
 // ../content/src/workflow-guide/overview.txt
-var overview_default = "Workflows are visual test sequences that model user journeys through your application. Each workflow is a directed graph of nodes \u2014 login, navigate, action, assertion, wait, condition, seed, and more \u2014 connected to form a testable path.\n\nWhen to use workflows:\n\n- Critical paths: signup, checkout, billing, onboarding\n- High-risk areas: features that regress often or have complex logic\n- Multi-step journeys: flows spanning multiple pages or user roles\n\nFor visual regression coverage, add one Visual checkpoint for each meaningful\nstate. Seed the state in Sandboxes v2 before capturing it. See\n`cofactor workflow guide visual-checkpoints` for native and Playwright examples.\n\nFLOW TYPES\n\n  standard    The default. Models a single user journey end-to-end.\n              Login \u2192 Navigate \u2192 Actions \u2192 Assertions \u2192 Cleanup.\n\n  setup       Deprecated. Formerly a prerequisite workflow referenced by a\n              setup node; use a seed workflow for shared data and suite\n              layers for ordering instead.\n\n  seed        A data-seeding workflow that generates test data and exports\n              variables for downstream workflows. Seed outputs are declared\n              in the workflow definition and available as $var.{dataKey}\n              in any workflow that references the seed.\n\n  teardown    A cleanup workflow that runs after a seed workflow completes.\n              Automatically invoked to remove data the seed created.\n\n  eval        A chat eval: one chat_scenario node holding a scripted\n              conversation against a chat target, each reply graded by an\n              LLM judge. Runs browserless. See the CHAT SCENARIO node type.\n\nEXECUTION MODEL\n\n  1. Login node provisions an authenticated browser session\n  2. Nodes execute in sequence (or branch at condition nodes)\n  3. Each action node interacts with the live application\n  4. Assertions verify expected outcomes\n  5. Additional login nodes switch to a different user \u2014 each starts a\n     new segment with a fresh session (great for multi-role testing)\n  6. Wait nodes pause execution (minutes, hours, days) \u2014 also creating\n     segments. After a wait, a login re-establishes the session.\n  7. On completion, the run is marked success or failure\n\nVERSION HISTORY\n\n  Workflows maintain version history. Publishing creates a versioned\n  snapshot. Previous versions can be previewed or restored to draft.\n  Seed nodes reference a specific published version of the seed workflow.\n";
+var overview_default = "Workflows are visual test sequences that model user journeys through your application. Each workflow is a directed graph of nodes \u2014 login, navigate, action, assertion, wait, condition, seed, and more \u2014 connected to form a testable path.\n\nWhen to use workflows:\n\n- Critical paths: signup, checkout, billing, onboarding\n- High-risk areas: features that regress often or have complex logic\n- Multi-step journeys: flows spanning multiple pages or user roles\n\nFor visual regression coverage, add one Visual checkpoint for each meaningful\nstate. Seed the state in Sandboxes v2 before capturing it. See\n`cofactor workflow guide visual-checkpoints` for native and Playwright examples.\n\nFLOW TYPES\n\n  standard    The default. Models a single user journey end-to-end.\n              Login \u2192 Navigate \u2192 Actions \u2192 Assertions \u2192 Cleanup.\n\n  setup       Deprecated. Formerly a prerequisite workflow referenced by a\n              setup node; use a seed workflow for shared data and suite\n              layers for ordering instead.\n\n  seed        A data-seeding workflow that generates test data and exports\n              variables for downstream workflows. Seed outputs are declared\n              in the workflow definition and available as $var.{dataKey}\n              in any workflow that references the seed.\n\n  teardown    A cleanup workflow that runs after a seed workflow completes.\n              Automatically invoked to remove data the seed created.\n\nEXECUTION MODEL\n\n  1. Login node provisions an authenticated browser session\n  2. Nodes execute in sequence (or branch at condition nodes)\n  3. Each action node interacts with the live application\n  4. Assertions verify expected outcomes\n  5. Additional login nodes switch to a different user \u2014 each starts a\n     new segment with a fresh session (great for multi-role testing)\n  6. Wait nodes pause execution (minutes, hours, days) \u2014 also creating\n     segments. After a wait, a login re-establishes the session.\n  7. On completion, the run is marked success or failure\n\nVERSION HISTORY\n\n  Workflows maintain version history. Publishing creates a versioned\n  snapshot. Previous versions can be previewed or restored to draft.\n  Seed nodes reference a specific published version of the seed workflow.\n";
 
 // ../content/src/workflow-guide/node-types.txt
 var node_types_default = `Every workflow is built from nodes. Each node has a type, a title, a description,
@@ -2570,53 +2570,6 @@ MCP
   (set alwaysUseAgent in config to skip replay). Requires the mcp.testing
   feature flag for the organization.
 
-CHAT SCENARIO
-  Runs a scripted conversation against a chat target \u2014 a saved description
-  of how to talk to an AI chat \u2014 and grades each reply with an LLM judge.
-  No browser involved. This is the node a chat eval is built around: a flow
-  of flowType "eval" holds the conversation in one chat_scenario node, and
-  may chain other nodes either side of it \u2014 an api_sequence before it to
-  establish ground truth a rubric compares against, a call_flow after it to
-  have a browser flow verify what the assistant claims it did.
-
-  When to use: the thing under test is what an assistant SAYS. It suits
-  binary invariants ("declines a cross-org request", "says a capability is
-  unavailable rather than inventing data"), not scoring or benchmarking.
-
-  Each turn sends one user message and judges the reply against that turn's
-  assertions plus every global invariant declared on the chat target \u2014 one
-  batched judge call per reply. An assertion is a plain-language rubric and
-  the verdict is binary; severity decides whether a failure fails the step
-  ("fail") or only warns ("warn").
-
-  Config:
-    chatTargetId  Chat target to talk to (required). Manage targets under
-                  Test Data -> Applications -> <app> -> Chat.
-    turns         Ordered list, at least one. Each turn is
-                  { id, message, assertions: [{ id, rubric, severity }] }.
-
-  Messages AND rubrics interpolate $var.{name}, so an upstream api_sequence
-  node can establish ground truth and a rubric can compare against it \u2014
-  "Reports a status matching $var.expected_status". Rubrics resolve against
-  non-credential variables only, so $var.credential.* can never reach the
-  judge. A rubric still holding an unresolved $var after expansion is
-  withheld from the judge and recorded as a failure naming the missing
-  variable, rather than being graded as literal template text.
-
-  One asymmetry: a message is expanded on the way OUT, but the transcript
-  and the judge see it as authored \u2014 a bubble can read "\u2026order
-  $var.order_id" though the target got the value. The judge grades the
-  RESPONSE, so this is usually cosmetic; when a rubric compares the reply
-  against the message, put the $var in the rubric too.
-
-  Chat scenarios are start-node eligible and run browserless, like mcp and
-  api_sequence, so a [chat_scenario, call_flow] flow boots no browser of its
-  own while the called child still drives a real one.
-
-  The evals feature flag gates chat targets \u2014 creating, listing and editing
-  them \u2014 so in practice an org needs it before a chat scenario has anything
-  to point at.
-
 CALL FLOW
   Runs another flow from inside this one, passing arguments in and getting
   that flow's declared outputs back as variables. The child executes as its
@@ -2626,7 +2579,7 @@ CALL FLOW
   When to use: a check you want to reuse. Unlike seed nodes \u2014
   which are hoisted out of the chain and run before everything else \u2014 a
   call_flow node runs exactly where you put it, which is what makes it
-  usable AFTER a chat_scenario or an action node.
+  usable after an action node.
 
   The flow picker in the designer lists only approved-and-promoted (or
   eligible) flows, so a draft is not offered \u2014 but that is a picker filter,
@@ -2678,7 +2631,7 @@ END
   should stop execution rather than continue.`;
 
 // ../content/src/workflow-guide/spec-grammar.txt
-var spec_grammar_default = 'This is the exact syntax of a `.cofactor.md` spec file \u2014 what the parser actually matches, not\na loose description. A spec that reads as good prose but drifts from this grammar does NOT\nerror at parse time in most cases: the parser drops the line/bullet it can\'t match and reports\nonly a warn-severity issue. A spec can validate as "ok" while silently missing content the\nauthor wrote. When in doubt, match the grammar below character-for-character rather than\nwriting what merely reads naturally.\n\nFRONTMATTER\n\n  A `---`-fenced YAML block, first thing in the file:\n\n    ---\n    name: Org onboarding \u2014 invite a member\n    workflowId: <uuid>          # present only once compiled; NEVER remove or edit it by hand\n    status: draft               # draft | approved\n    flowType: standard          # standard | seed | teardown | eval  (setup is deprecated)\n    actor: admin                # persona name (or "persona <role>"), "credential <name>"\n                                 # for one fixed account, or "seed-output <dataKey>" for a\n                                 # seed\'s credential output \u2014 see ACTOR FORMS below\n    authenticated: true\n    tags: [smoke, p0]\n    requirementRef: LIN-4421\n    ---\n\n  `workflowId` binds the file to a live workflow: present \u2192 `spec_compile` diffs/updates that\n  workflow; absent \u2192 `spec_compile` creates a new one. If it\'s present, treat it as immutable \u2014\n  removing it turns your next compile into a duplicate-creating CREATE instead of an UPDATE.\n\nSECTION HEADINGS (H2, in this order)\n\n  ## Spirit       \u2014 one blockquote paragraph: the user-visible promise this flow proves.\n                     Becomes the workflow\'s description, so it carries no capability codes,\n                     preconditions, issue ids, status, step narration or raw IDs.\n  ## Preflight     \u2014 plain prose or bullets: non-seedable preconditions the environment must\n                     already satisfy, including pre-existing data the test reads but does not\n                     own, and external systems (flags, payments, third parties) it relies on.\n                     Becomes the workflow\'s preflight field. Name things, never IDs.\n  ## Cleanup       \u2014 plain prose or bullets: how the run\'s side effects get reset. Becomes\n                     the workflow\'s cleanup field.\n  ## Inputs        \u2014 bullets: `- <name>: <defaultValue>` or `- credential <name>: <value>`.\n  ## Declared Outputs \u2014 seed flows only: `- <dataKey>` bullets with optional indented\n                     `- label:` / `- property:` / `- description:` sub-bullets. A\n                     credentialOutput block is NOT authorable here \u2014 it is preserved from\n                     the live seed (rendered as an HTML comment on pull) and set via the\n                     Flow Designer or `workflow seed create --from-file` / `workflow patch\n                     --seed-outputs-file` (see `workflow guide seed-users`).\n  ## Scenarios     \u2014 H3 sub-blocks per scenario: `### <Name> *(default)*` or `*(skip: <reason>)*`,\n                     with `- values: {...}` / `- credentials: {...}` YAML underneath.\n  ## Journey       \u2014 the linear sequence of nodes described below. Required \u2014 a spec with no\n                     Journey nodes fails to parse.\n\nJOURNEY LEAD-INS\n\n  Every Journey line is either a bold lead-in (`**...**`) or a blockquote/bullet attached to\n  the preceding lead-in. Blank lines between a lead-in, its description, and its bullets are\n  fine \u2014 the parser skips them.\n\n    **Navigate to** /path/here\n    **Action \u2014 Fill out the signup form**\n    **Assert** the confirmation toast is visible\n    **Wait** 30s                        (also accepts 5m, 2h)\n    **End**                             (add "fail" anywhere in the line for a failing End)\n    **Seed** seed-workflow-name\n    **Setup** setup-workflow-name       (deprecated \u2014 still parses; author **Seed** instead)\n    **Switch role to** admin            (or **Switch role to admin** \u2014 both forms work)\n    **Sandbox action \u2014 provision-org**\n    **Api sequence \u2014 Create via API**\n    **Visual checkpoint \u2014 Invoice list after seeding**\n    **If** $var.status is "blocked"\n    **Then:**\n      <nested nodes, indented 2 spaces>\n    **Else:**\n      <nested nodes, indented 2 spaces>\n\n  CRITICAL: for `Action`, `Sandbox action`, and `Api sequence`, the title goes AFTER an em-dash\n  (`\u2014`) or hyphen INSIDE the bold span: `**Action \u2014 Title**`. Writing `**Action** Title` (title\n  outside the bold) used to silently lose the title; it is now tolerated as a fallback, but the\n  em-dash-inside-bold form is canonical \u2014 use it. Do not invent a form for a lead-in not listed\n  above (e.g. there is no `**Click**` or `**Type**` lead-in) \u2014 express it as an Action instead.\n\nACTOR FORMS (frontmatter `actor:` and `**Switch role to** <ref>` take the same forms)\n\n    actor: Admin                    persona named "Admin" (default form)\n    actor: persona Admin            same, explicit\n    actor: credential admin-bob     one specific stored credential by name\n    actor: seed-output new_user     the credential output `new_user` of a **Seed** node\n                                    earlier in the Journey (credentialSource: from_seed)\n\n  `template <name>` is a legacy alias for `persona <name>`. `seed-output` binds to the\n  nearest **Seed** node that precedes the login, so the Seed must come first in the\n  Journey (for `actor:`, as the leading node); compile fails if no Seed precedes it.\n\nDESCRIPTION (optional, any lead-in)\n\n  A blockquote line immediately after the lead-in (or after a blank line) becomes the node\'s\n  description \u2014 free prose is fine and expected here:\n\n    **Action \u2014 Create the org**\n    > Fill the org form with orgName and plan, then submit.\n    - field name: $orgName\n\nACTION BULLET GRAMMAR (exact \u2014 only these forms parse; everything else is DROPPED)\n\n    - field <name> [(type)]: <value>       e.g. - field plan (select): $plan\n    - capture: <name>                      e.g. - capture: createdOrgId\n    - assert (warn|fail|fatal[, agentic]): <condition>\n                                            e.g. - assert (fail): URL ends with `/dashboard`\n                                            e.g. - assert (warn, agentic): chart looks right\n    - alwaysUseAgent: true\n    - captureAudio: true\n    - captureLabel: <label>\n    - captureExtraMs: <number>\n\n  A standalone `**Assert**` node takes its own kv option bullet the same way:\n\n    - severity: warn|fail|fatal            (assert nodes only; NOT `- severity: warn \u2014 text`,\n                                            which is an unparseable kv bullet, not an assert)\n\n  `Seed`/`Setup` bullets: `- version: latest`, `- mode: ...`, `- onFailure: block|warn`,\n  `- input.<name>: <value>`. `Sandbox action` bullets: `- label: ...`, `- outputs: a, b`,\n  `- param.<name>: <value>`. `Visual checkpoint` bullets: `- target: <plain-English element>`,\n  `- expected: <visible expected state>`, and `- severity: record|fail`.\n\nCOMPLETE MINIMAL EXAMPLE\n\n    ---\n    name: Login smoke\n    actor: admin\n    authenticated: true\n    requirementRef: LIN-101\n    ---\n\n    ## Spirit\n    > A returning admin can sign in and reach the dashboard.\n\n    ## Inputs\n    - adminEmail: $EMAIL()\n\n    ## Journey\n\n    **Navigate to** `/login`.\n\n    **Action \u2014 Sign in**\n    > Enter email and password, submit.\n    - field email: $adminEmail\n    - field password: $CREDENTIAL\n    - assert (fail): URL ends with `/dashboard`\n\n    **End**.\n\nCOMMON MISTAKES (each of these compiles into an empty or half-empty node \u2014 no parse error)\n\n  - A free-text bullet ("- Should reach the dashboard eventually") is not `field`/`capture`/\n    `assert (...)`/a known kv key \u2014 it is DROPPED. Put prose in the `>` description instead of\n    inventing a bullet shape.\n  - `- severity: warn \u2014 should show a toast` is a kv bullet with key `severity`; it is not a\n    recognized action option, so it is DROPPED. Use `- assert (warn): should show a toast`.\n  - `**Action** Do the thing` (title outside the bold) is tolerated but non-canonical \u2014 prefer\n    `**Action \u2014 Do the thing**`.\n  - Any Journey line that doesn\'t start with a recognized bold lead-in is DROPPED with only a\n    warn-severity "Unexpected line in Journey" issue \u2014 it will not error your compile.\n  - After authoring or editing a spec, always run `spec_validate` and inspect its\n    `droppedContent` field. Non-empty `droppedContent` means real content is about to be lost \u2014\n    treat it as a blocking error, not a warning, even though its underlying severity is `warn`.\n';
+var spec_grammar_default = 'This is the exact syntax of a `.cofactor.md` spec file \u2014 what the parser actually matches, not\na loose description. A spec that reads as good prose but drifts from this grammar does NOT\nerror at parse time in most cases: the parser drops the line/bullet it can\'t match and reports\nonly a warn-severity issue. A spec can validate as "ok" while silently missing content the\nauthor wrote. When in doubt, match the grammar below character-for-character rather than\nwriting what merely reads naturally.\n\nFRONTMATTER\n\n  A `---`-fenced YAML block, first thing in the file:\n\n    ---\n    name: Org onboarding \u2014 invite a member\n    workflowId: <uuid>          # present only once compiled; NEVER remove or edit it by hand\n    status: draft               # draft | approved\n    flowType: standard          # standard | seed | teardown  (setup is deprecated)\n    actor: admin                # persona name (or "persona <role>"), "credential <name>"\n                                 # for one fixed account, or "seed-output <dataKey>" for a\n                                 # seed\'s credential output \u2014 see ACTOR FORMS below\n    authenticated: true\n    tags: [smoke, p0]\n    requirementRef: LIN-4421\n    ---\n\n  `workflowId` binds the file to a live workflow: present \u2192 `spec_compile` diffs/updates that\n  workflow; absent \u2192 `spec_compile` creates a new one. If it\'s present, treat it as immutable \u2014\n  removing it turns your next compile into a duplicate-creating CREATE instead of an UPDATE.\n\nSECTION HEADINGS (H2, in this order)\n\n  ## Spirit       \u2014 one blockquote paragraph: the user-visible promise this flow proves.\n                     Becomes the workflow\'s description, so it carries no capability codes,\n                     preconditions, issue ids, status, step narration or raw IDs.\n  ## Preflight     \u2014 plain prose or bullets: non-seedable preconditions the environment must\n                     already satisfy, including pre-existing data the test reads but does not\n                     own, and external systems (flags, payments, third parties) it relies on.\n                     Becomes the workflow\'s preflight field. Name things, never IDs.\n  ## Cleanup       \u2014 plain prose or bullets: how the run\'s side effects get reset. Becomes\n                     the workflow\'s cleanup field.\n  ## Inputs        \u2014 bullets: `- <name>: <defaultValue>` or `- credential <name>: <value>`.\n  ## Declared Outputs \u2014 seed flows only: `- <dataKey>` bullets with optional indented\n                     `- label:` / `- property:` / `- description:` sub-bullets. A\n                     credentialOutput block is NOT authorable here \u2014 it is preserved from\n                     the live seed (rendered as an HTML comment on pull) and set via the\n                     Flow Designer or `workflow seed create --from-file` / `workflow patch\n                     --seed-outputs-file` (see `workflow guide seed-users`).\n  ## Scenarios     \u2014 H3 sub-blocks per scenario: `### <Name> *(default)*` or `*(skip: <reason>)*`,\n                     with `- values: {...}` / `- credentials: {...}` YAML underneath.\n  ## Journey       \u2014 the linear sequence of nodes described below. Required \u2014 a spec with no\n                     Journey nodes fails to parse.\n\nJOURNEY LEAD-INS\n\n  Every Journey line is either a bold lead-in (`**...**`) or a blockquote/bullet attached to\n  the preceding lead-in. Blank lines between a lead-in, its description, and its bullets are\n  fine \u2014 the parser skips them.\n\n    **Navigate to** /path/here\n    **Action \u2014 Fill out the signup form**\n    **Assert** the confirmation toast is visible\n    **Wait** 30s                        (also accepts 5m, 2h)\n    **End**                             (add "fail" anywhere in the line for a failing End)\n    **Seed** seed-workflow-name\n    **Setup** setup-workflow-name       (deprecated \u2014 still parses; author **Seed** instead)\n    **Switch role to** admin            (or **Switch role to admin** \u2014 both forms work)\n    **Sandbox action \u2014 provision-org**\n    **Api sequence \u2014 Create via API**\n    **Visual checkpoint \u2014 Invoice list after seeding**\n    **If** $var.status is "blocked"\n    **Then:**\n      <nested nodes, indented 2 spaces>\n    **Else:**\n      <nested nodes, indented 2 spaces>\n\n  CRITICAL: for `Action`, `Sandbox action`, and `Api sequence`, the title goes AFTER an em-dash\n  (`\u2014`) or hyphen INSIDE the bold span: `**Action \u2014 Title**`. Writing `**Action** Title` (title\n  outside the bold) used to silently lose the title; it is now tolerated as a fallback, but the\n  em-dash-inside-bold form is canonical \u2014 use it. Do not invent a form for a lead-in not listed\n  above (e.g. there is no `**Click**` or `**Type**` lead-in) \u2014 express it as an Action instead.\n\nACTOR FORMS (frontmatter `actor:` and `**Switch role to** <ref>` take the same forms)\n\n    actor: Admin                    persona named "Admin" (default form)\n    actor: persona Admin            same, explicit\n    actor: credential admin-bob     one specific stored credential by name\n    actor: seed-output new_user     the credential output `new_user` of a **Seed** node\n                                    earlier in the Journey (credentialSource: from_seed)\n\n  `template <name>` is a legacy alias for `persona <name>`. `seed-output` binds to the\n  nearest **Seed** node that precedes the login, so the Seed must come first in the\n  Journey (for `actor:`, as the leading node); compile fails if no Seed precedes it.\n\nDESCRIPTION (optional, any lead-in)\n\n  A blockquote line immediately after the lead-in (or after a blank line) becomes the node\'s\n  description \u2014 free prose is fine and expected here:\n\n    **Action \u2014 Create the org**\n    > Fill the org form with orgName and plan, then submit.\n    - field name: $orgName\n\nACTION BULLET GRAMMAR (exact \u2014 only these forms parse; everything else is DROPPED)\n\n    - field <name> [(type)]: <value>       e.g. - field plan (select): $plan\n    - capture: <name>                      e.g. - capture: createdOrgId\n    - assert (warn|fail|fatal[, agentic]): <condition>\n                                            e.g. - assert (fail): URL ends with `/dashboard`\n                                            e.g. - assert (warn, agentic): chart looks right\n    - alwaysUseAgent: true\n    - captureAudio: true\n    - captureLabel: <label>\n    - captureExtraMs: <number>\n\n  A standalone `**Assert**` node takes its own kv option bullet the same way:\n\n    - severity: warn|fail|fatal            (assert nodes only; NOT `- severity: warn \u2014 text`,\n                                            which is an unparseable kv bullet, not an assert)\n\n  `Seed`/`Setup` bullets: `- version: latest`, `- mode: ...`, `- onFailure: block|warn`,\n  `- input.<name>: <value>`. `Sandbox action` bullets: `- label: ...`, `- outputs: a, b`,\n  `- param.<name>: <value>`. `Visual checkpoint` bullets: `- target: <plain-English element>`,\n  `- expected: <visible expected state>`, and `- severity: record|fail`.\n\nCOMPLETE MINIMAL EXAMPLE\n\n    ---\n    name: Login smoke\n    actor: admin\n    authenticated: true\n    requirementRef: LIN-101\n    ---\n\n    ## Spirit\n    > A returning admin can sign in and reach the dashboard.\n\n    ## Inputs\n    - adminEmail: $EMAIL()\n\n    ## Journey\n\n    **Navigate to** `/login`.\n\n    **Action \u2014 Sign in**\n    > Enter email and password, submit.\n    - field email: $adminEmail\n    - field password: $CREDENTIAL\n    - assert (fail): URL ends with `/dashboard`\n\n    **End**.\n\nCOMMON MISTAKES (each of these compiles into an empty or half-empty node \u2014 no parse error)\n\n  - A free-text bullet ("- Should reach the dashboard eventually") is not `field`/`capture`/\n    `assert (...)`/a known kv key \u2014 it is DROPPED. Put prose in the `>` description instead of\n    inventing a bullet shape.\n  - `- severity: warn \u2014 should show a toast` is a kv bullet with key `severity`; it is not a\n    recognized action option, so it is DROPPED. Use `- assert (warn): should show a toast`.\n  - `**Action** Do the thing` (title outside the bold) is tolerated but non-canonical \u2014 prefer\n    `**Action \u2014 Do the thing**`.\n  - Any Journey line that doesn\'t start with a recognized bold lead-in is DROPPED with only a\n    warn-severity "Unexpected line in Journey" issue \u2014 it will not error your compile.\n  - After authoring or editing a spec, always run `spec_validate` and inspect its\n    `droppedContent` field. Non-empty `droppedContent` means real content is about to be lost \u2014\n    treat it as a blocking error, not a warning, even though its underlying severity is `warn`.\n';
 
 // ../content/src/workflow-guide/action-nodes.txt
 var action_nodes_default = `WHAT A STRONG ACTION NODE LOOKS LIKE
@@ -4022,15 +3975,9 @@ var cli_seeds_default = 'Use this section when you need to create or inspect see
 // ../content/src/workflow-guide/cli-api-sequences.txt
 var cli_api_sequences_default = 'Use this section when you need to drive API sequence authoring from the\nCofactor CLI. The conceptual model lives in `api-sequences`; this section is\nonly command orientation. Prefer each command\'s `--help` output for the\ncurrent flag list.\n\nCOMMON FLOW\n\n  1. Inspect the API catalog for candidate endpoints.\n\n       cofactor api-catalog sources list\n       cofactor api-catalog endpoints list --search <keyword>\n       cofactor api-catalog endpoints get <apiRequestId>\n\n  2. Compose a sequence JSON file locally. Reference endpoints by\n     apiRequestId and chain steps with {{stepId.response.path}}.\n\n  3. Create an API-only workflow from the sequence file.\n\n       cofactor workflow create --api-only --name "smoke: create project" \\\n         --sequence-from-file seq.json\n\n     The command returns the workflow, sequence, and node IDs.\n\n     To attach a sequence to an existing workflow that has none, run\n     `cofactor workflow api-sequence update <workflowId> --from-file seq.json`;\n     it creates the sequence when absent and replaces the config otherwise.\n\n  4. Execute immediately to surface template warnings and API failures.\n\n       cofactor workflow api-sequence execute <workflowId>\n\n  5. Inspect the run and iterate on the sequence file.\n\n       cofactor workflow runs list <workflowId> --side api\n       cofactor workflow runs get <workflowId> <runId>\n       cofactor workflow runs get <workflowId> <runId> --step <runStepId> --api-call <apiStepId>\n     Add --json for JSON; the flags print stored (capped) request/response bodies.\n     Get <runStepId> from runs get <workflowId> <runId> --json (steps[].id).\n       cofactor workflow api-sequence update <workflowId> --from-file seq.json\n\nREFERENCE\n\n  - Command help: `cofactor workflow api-sequence --help`\n  - Workflow creation help: `cofactor workflow create --help`\n  - API catalog help: `cofactor api-catalog --help`\n';
 
-// ../content/src/workflow-guide/cli-chat-evals.txt
-var cli_chat_evals_default = 'Use this section to author a chat eval from the Cofactor CLI. The conceptual\nmodel lives in the CHAT SCENARIO and CALL FLOW node types; this section is only\ncommand orientation. Prefer each command\'s `--help` output for the current flag\nlist.\n\nAn eval is a workflow of flowType "eval" built around one chat_scenario node.\nIt needs a chat target first \u2014 the saved description of how to talk to the AI\nchat under test. Both require the `evals` feature flag.\n\nCREATE THE CHAT TARGET\n\n  A chat target is application-scoped like a credential, and describes one\n  endpoint: how to send a message, how to read the reply, who to send it as.\n\n    cofactor chat-target create \\\n      --application "Acme App" --environment "Staging" \\\n      --credential "Support Agent" \\\n      --name "Acme support assistant" \\\n      --config ./target.json \\\n      --invariant "No cross-org data=Never reveals another organization\'s data."\n\n  `--config` takes a file or `-` for stdin, holding `message` (method,\n  urlTemplate, historyMode, bodyTemplate, optional headersTemplate) and\n  `response` (transport `ai-sdk-v5`, or `sse` with deltaPath, or `json` with\n  textPath).\n\n  Only three slots are substituted per turn: {{message}}, {{messages}} and\n  {{conversationId}}. There is NO {{baseUrl}} slot \u2014 write the endpoint as a\n  literal URL.\n\n  `$var.ENV.<name>` also resolves in a urlTemplate, which lets one target\n  follow whichever environment a run picks. But it resolves only during a\n  RUN: the live-chat path behind `chat-target chat` supplies no workflow\n  variables, so a target written that way cannot be smoke-tested with the\n  command below. Prefer a literal URL unless you need one target across\n  several environments, and know the tradeoff if you do.\n\n  `--invariant` is repeatable and declares a rubric judged against EVERY reply\n  in every scenario run against this target \u2014 the cheapest coverage available.\n  Severity defaults to fail; append `:warn` to the name to soften one.\n\nPROVE THE TARGET BEFORE BUILDING ON IT\n\n    cofactor chat-target chat "Acme support assistant" --message "What can you do?"\n\n  This sends one real turn down the same executor path a scenario uses, so a\n  reply here is evidence the config, credential binding and transport all work.\n  Expect 10-30s for a credentialed target \u2014 each message resolves an\n  authenticated session server-side. A failed turn exits non-zero.\n\nAUTHOR AND RUN THE EVAL\n\n  Author it like any other flow \u2014 `cofactor workflow create --from-file eval.json`\n  with `"flowType": "eval"` and one `chat_scenario` node whose configJson holds\n  `chatTargetId` and `turns` (see the CHAT SCENARIO entry for the shape).\n\n  Put an api_sequence node BEFORE the chat node to establish ground truth and\n  reference its exports from a rubric \u2014 "Reports a count matching\n  $var.expected_count". Put a call_flow node AFTER it to have a browser flow\n  verify something the assistant claims it did.\n\n  Watch the two path forms in an api_sequence: a `validations` entry\'s `left`\n  is step-qualified (`myStep.response.items.0.name`), while an `exports`\n  entry\'s `responsePath` is relative to that step\'s response body\n  (`items.0.name`) because it already names its `stepId`. Carrying the\n  `response.` prefix into an export silently yields nothing \u2014 the step still\n  passes, and the failure only surfaces later as a rubric that references a\n  variable no step produced.\n\n  Give the ground-truth step a `validations` entry as well as an export. An\n  export that resolves to nothing does not fail the step, so without a\n  validation the first sign of trouble is a withheld rubric further down.\n\n    cofactor workflow run <workflowId>\n    cofactor workflow runs get <runId>\n\n  Per-turn judge verdicts persist on the chat_scenario step as\n  `metadataJson.chatTranscript`, so the graded transcript is readable without\n  opening the browser.\n\nREFERENCE\n\n  - Chat target help: `cofactor chat-target --help`\n  - Node config shapes: `cofactor workflow guide node-types`\n';
-
 // ../content/src/workflow-guide/write-a-test.txt
 var write_a_test_default = 'Use this section to author a test straight from the CLI: plan the journey, check\nfor duplicates, create or update the workflow, run it, and hand back its URL.\nNo spec files are needed.\n\nAUTHORING LOOP\n\n  1. Understand the requirement. Read the ticket, PRD, or the user\'s intent, and\n     explore the real UI first (see `best-practices` and `cofactor session guide`).\n  2. Avoid duplicates:\n       cofactor workflow list --search "<keywords>"\n     If a workflow already covers the journey, update it instead of creating one.\n  3. Create it (JSON on stdin or from a file; shapes are in `node-types`):\n       cofactor workflow create --from-file test.json\n       cofactor workflow create --from-file test.json --tags "p0,checkout"\n     Input: { "name": "...", "nodes": [{ "nodeType": "...", "configJson": {...} }] }\n  4. Change an existing workflow:\n       cofactor workflow get <workflowId>                       (read it first)\n       cofactor workflow sync <workflowId> --from-file test.json   (replace all nodes)\n       cofactor workflow node patch <workflowId> <nodeId> --set-input key=value\n       cofactor workflow patch <workflowId> --name "..." --description "..."\n       cofactor workflow patch <workflowId> --preflight @preflight.md --cleanup @cleanup.md\n     Reuse each existing node `id` in sync to keep a minimal diff. Add --propose\n     to sync to open a proposal for review instead of applying directly.\n  5. Run it and look at the result:\n       cofactor workflow run <workflowId> --stream\n       cofactor workflow runs list <workflowId>\n       cofactor workflow debug <runId>        (when a run fails)\n  6. Return the workflow URL printed by the CLI to the user verbatim. Never\n     build the URL yourself.\n\n  Approving a test asserts that a human verified it checks the right thing. Do\n  not pass --yes to `workflow approve` until the user has confirmed.\n\nTHE RUBRIC: EVERY TEST MUST SATISFY ALL OF THESE\n\n  1. One coherent journey per workflow\n     One user objective, possibly with several verifications along the way.\n     "Atomic" means coherent, not minimal. If isolating a check would force you\n     to duplicate most of another test\'s setup, fold it in as an inline\n     assertion on the larger journey.\n       Good: create org -> invite a user -> claim invite -> land on dashboard.\n       Good: submit a ticket and confirm it appears in the queue.\n       Bad:  submit a ticket, edit a user, generate a report (three journeys,\n             three workflows).\n     Split only when the setup is genuinely different or the failure modes are\n     independent. A long single journey stays together; independent journeys\n     become separate workflows so they run in parallel and fail independently.\n\n  2. Specific, observable expected results\n     Every assertion is something a stranger could verify without judgement,\n     and comes from the requirement or confirmed user intent, not incidental\n     DOM details seen while exploring. Keep conditions about user-visible\n     behavior; do not invent ARIA/SVG checks or pixel thresholds.\n       Good: "URL ends with /dashboard." "A row named X appears in the table."\n       Bad:  "The page looks correct." "It works."\n     Attach assertions inline to the action that produced the result (see\n     `assertions`). Pick severity deliberately: fatal ends the run (gating\n     preconditions), fail marks the run failed but continues (feature claims),\n     warn records without failing (cosmetics). A test with no run-failing\n     assertion proves nothing.\n     Relative checks ("the count dropped by 2") must reference a value captured\n     upstream and used via $var.<name>, never rely on memory of the earlier state.\n\n  3. Idempotent, self-owned, isolated\n     - Rerunning passes without a manual reset: use macros ($EMAIL(), $UUID(),\n       "QA Test $RANDOM_STRING(6)") for anything that must be unique (see `macros`).\n     - The test creates the records it operates on, inline. A seed workflow is\n       for data that several tests share; a seed with one consumer is overhead.\n       Data the test only reads may pre-exist, but never mutate it.\n     - Never modify shared resources (billing, integrations, API keys, org\n       config) as a side effect.\n     - Tests that depend on one another run as ordered suite layers, never by\n       implicit ordering.\n     - A fatal assertion halts the run before trailing cleanup. Anything that\n       must be gone after a failure belongs in a seed with a teardown (see\n       `seed-workflows`, `data-lifecycle`).\n\n  4. Traceable\n     Link the test to the product-map capability it proves:\n       cofactor product-map link <CAP-code> <workflowId>\n     Traceability comes from that link, not from text: do not write capability\n     codes, ticket ids or requirement references into the name or description.\n     If no capability covers the test, tell the user; untraceable tests rot.\n\n  5. Risk-prioritized\n     Tag each test p0, p1, or p2 with --tags / --tags-add:\n       p0  happy path of the core promise; if it breaks the feature is broken\n       p1  primary edge cases, validation, role variants, common error states\n       p2  rare conditions, visual or agentic checks, low-frequency edges\n\n  6. Preconditions, data, and cleanup are explicit\n     Auth and role: use a persona (cofactor persona list --application "<app>")\n     rather than raw usernames and passwords. Shared setup: a seed node, placed\n     before login. Test data: workflow inputs with macros. Anything else the\n     test depends on (pre-existing data it reads, flags, third-party systems)\n     goes in the workflow\'s preflight, and how its side effects get reset goes\n     in its cleanup. Write each as a short markdown bullet list:\n       cofactor workflow patch <workflowId> --preflight @preflight.md\n       cofactor workflow patch <workflowId> --cleanup @cleanup.md\n\n  7. The description says what the test is for\n     Read together with the name, the description gives the spirit of the\n     test: what we are doing and why it matters, in one or two plain\n     sentences. It never holds capability codes, preconditions, issue ids,\n     status ("expected red", "blocked"), step narration, endpoints, payloads,\n     timings or cache details. Each of those lives elsewhere: the product-map\n     link, the preflight, the linked issue, the run history, the nodes.\n     People read the description, preflight and cleanup in the web UI, so\n     never put a raw ID in them: no UUID, UUID prefix, wf_/prule_ or other\n     prefixed id, issue id or run id. Name the thing instead (the seed\n     workflow\'s name, the teardown\'s name, the connection\'s name, the\n     record\'s name).\n       Good: name "Invite a teammate to Acme"\n             description "An admin invites a new teammate by email and the\n             teammate can sign in. Growing a team depends on invites\n             reaching people."\n       Bad:  description "CAP-ORG-004. Needs seed org + admin persona. Steps:\n             open /settings/team, POST /api/invites, wait 5s, check inbox.\n             Expected red until ISSUE-812 ships. Cache warm."\n       Bad preflight:\n             Seed 5e055090 creates an empty layer. Paired teardown d9a44386\n             deletes the flow.\n       Good preflight:\n             - The "Acme empty layer" seed creates an empty layer\n             - Its paired teardown, "Acme empty layer teardown", deletes the flow\n\n  8. Written as human intent, not UI mechanics\n     Action titles say what the user is trying to do ("Assign the ticket to\n     Support"), not click-by-click steps. Each action is one coherent,\n     assertable step: usually broader than one click, ends at a visible\n     boundary (modal gone, URL changed, row appeared), and has no conditionals\n     inside it. If the data might not exist, seed it instead of branching.\n\nCHOOSING VALUES\n\n  - Names existing data in the target app (a property, persona, credential, a\n    seeded record): do not guess. Look it up with `cofactor property list`,\n    `cofactor persona list --application "<app>"`, or\n    `cofactor workflow list --search <term>`, and ask the user when several\n    candidates fit.\n  - Synthesizable (email, UUID, throwaway string, date): use a macro and move on.\n  - Auth or role: prefer a persona over a raw credential.\n\nCOVERAGE CHECKLIST\n\n  Before handing work back, for each item either include a test or say why it\n  does not apply: happy path (p0); primary edges and boundary inputs; negative\n  paths and validation errors; permission and role variants; empty, loading,\n  and error states; cross-entity side effects (does this change something\n  visible elsewhere?); cleanup or undo.\n\n  Aim for the smallest set that proves the feature works. Five sharp tests beat\n  twenty fuzzy ones.\n';
 
-// ../content/src/workflow-guide/prove-changes.txt
-var prove_changes_default = 'Use this section to prove a change to the application with Cofactor tests, so a\npull request carries the tests that cover it and merging it adds them to the\nregression suite.\n\nTHE RULE\n\n  If a test already walks the journey, edit it (through a fork). Never add a new\n  test for a changed filter, column or field: the suite fills with near-duplicates.\n\nTHE LOOP\n\n  1. Find coverage first:\n       cofactor workflow list --search "<words>"\n       cofactor workflow get <workflowId> --format markdown     (read its assertions)\n  2. Choose:\n       A test covers the journey  ->  fork it, edit the fork, never the original:\n         cofactor workflow fork fork <workflowId>\n       Nothing covers it, or it needs its own data or role  ->  write a new test\n         (see `write-a-test`, `data-lifecycle`, `assertions`).\n       No test is possible  ->  say so (step 5).\n  3. Run it on a sandbox of your change until it passes. After your last change,\n     run it once more: that passing run is your proof, and the command prints its\n     run id (a uuid or wrun_...; either works):\n       cofactor sandbox claim --application <app> --wait\n       cofactor sandbox sync <id> [--build]\n       cofactor workflow run <fork> --sandbox <id> --stream\n  4. Push and open a draft pull request.\n  5. List each test with the run of it that passed. Print the block, never\n     hand-format it:\n       cofactor proofs block <workflowId> <runId> [<workflowId> <runId> ...]\n     or, when no test is possible, say why and what would make one possible:\n       cofactor proofs block --none "<reason>"\n     Paste the printed block into the pull request description:\n       <!-- cofactor:proofs -->\n       - wf_... <run id>  <name> (new | fork of <original>)\n       <!-- /cofactor:proofs -->\n     A listed test must be a new draft test or a fork of an approved test; an\n     approved test cannot be changed by listing it directly.\n  6. Cofactor does not run the tests again. It checks that each listed run\n     exists, belongs to its test, passed and ran the test as it is now (an edit\n     after the run makes it no proof), and reports one `cofactor / proofs` check.\n     It does not check which commit the run was against, so run the test after\n     your last change. The check is evaluated again when you push, edit the\n     description or press "Re-run all checks", and once more at merge. See what a\n     pull request lists:\n       cofactor proofs status --application <app> --pr <pr>\n  7. Merge. Merging is the approval: a new test whose run is proof is approved\n     ("approved by merge of #N by @login") and added to suite runs, and a fork\n     whose run is proof is merged into its original (added to suite runs if it was\n     not) and deleted, unless the original changed after the fork was\n     taken: then the proposal is left open in the original\'s proposals and the pull\n     request gets a comment. A test whose run is not proof is left as a draft and\n     runs in no suite. Cofactor does not require the check; it blocks a merge only\n     if the repository makes it a required check.\n\n  Closing the pull request without merging promotes nothing. The drafts and forks\n  it lists are archived 14 days later (undoable); reopening it within that window\n  keeps them.\n\nRECORD WHAT WAS UNCLEAR\n\n  In the pull request description add `## Proof notes`: each decision you were\n  unsure about (fork or new, what to assert, what you left uncovered) and why you\n  chose as you did.\n';
-
 // ../content/src/workflow-guide/visual-checkpoints.txt
 var visual_checkpoints_default = "Visual checkpoints capture a meaningful screen state and compare it with the\nrolling baseline for that checkpoint. Add one checkpoint at each state whose\nappearance matters to the user; avoid taking several screenshots of the same\nstate just because the journey has several steps.\n\nNATIVE WORKFLOW CHECKPOINTS\n\n  Checkpoints run in Sandboxes v2. Seed the sandbox into the exact state to\n  compare, then capture it. A standalone visual regression test is a short\n  workflow that prepares one state and takes its checkpoint. Examples include\n  seeding a populated list before capturing it, or submitting invalid input and\n  capturing the resulting validation error.\n\n  The `target` is optional plain English describing an element, such as\n  `the invoices table`; omit it to capture the whole page. Never put a CSS,\n  XPath, or Playwright selector in `target`.\n\n  `expected` is optional plain language describing the correct visible state.\n  It guides the AI in deciding whether the current state is correct and whether\n  a visual change is real or can be healed. Use a specific observable\n  description, for example, \"Three invoices are listed, each marked Paid, with\n  no error banner.\"\n\n  `record` is the default. It records visual findings without changing the\n  workflow result, and compares after the suite finishes. Choose `fail` when an\n  unresolved visual change should fail this workflow step; it compares inline.\n  Under either severity, a `target` that cannot be found is reported as a\n  checkpoint that could not be compared, and under `fail` it fails the step.\n  Both severities appear in Visual results.\n\n  Dynamic text is masked automatically. If the AI heals a difference, it saves\n  an element mask and its reason on the checkpoint. The review shows the heal;\n  a reviewer can revert the mask or mark the change as a regression. Masks are\n  automatic or healed; never author mask rules yourself.\n\nSTANDALONE VISUAL REGRESSION SPECS\n\n  These complete `.cofactor.md` examples use the current spec grammar. Replace\n  the illustrative seed name, persona, and routes with the published seed,\n  persona, and paths used by your application. In each, prepare one meaningful\n  state and capture it. Sandboxes v2 supplies the run.\n\n  Seed a populated invoice list, then checkpoint it:\n\n    ---\n    name: Invoice list visual regression\n    actor: admin\n    authenticated: true\n    ---\n\n    ## Spirit\n    > An admin can see the seeded invoices and their payment status.\n\n    ## Journey\n\n    **Seed** invoice-list-state\n\n    **Navigate to** `/invoices`\n\n    **Visual checkpoint \u2014 Populated invoice list**\n    - target: the invoices table\n    - expected: Three invoices are listed, each marked Paid, with no error banner.\n    - severity: fail\n\n    **End**.\n\n  Submit invalid form data and checkpoint the validation state:\n\n    ---\n    name: Signup validation visual regression\n    authenticated: false\n    ---\n\n    ## Spirit\n    > A visitor sees clear validation feedback when required signup fields are missing.\n\n    ## Journey\n\n    **Navigate to** `/signup`\n\n    **Action \u2014 Submit the empty signup form**\n    > Submit without entering any values so the required-field messages appear.\n    - assert (fail): A required-field validation message is visible.\n\n    **Visual checkpoint \u2014 Required-field validation**\n    - target: the signup form\n    - expected: Required fields have clear validation messages and the form has not been submitted.\n    - severity: record\n\n    **End**.\n\nPLAYWRIGHT ATTACHMENT CHECKPOINTS\n\n  In an external Playwright suite running on Sandboxes v2, an attached PNG is a\n  visual checkpoint:\n\n    await testInfo.attach(name, { body: await page.screenshot({ mask }), contentType: 'image/png' })\n\n  Its identity is the spec file, test title, and attachment name. Keep masking\n  in the test code with Playwright's `mask` option. The service explains and\n  reports Playwright changes but never fails the Playwright test. Failure\n  screenshots, trace frames, and `toHaveScreenshot` actuals are excluded. Do\n  not use `toHaveScreenshot` for this feature; attach the screenshot instead.\n\nREVIEW RESULTS\n\n  Review changes and comparisons on the Visual page. From the CLI, use\n  `cofactor visual list` to find captures. Mark or clear a regression with\n  `cofactor visual regression <captureId>` or\n  `cofactor visual regression <captureId> --clear`.\n";
 
@@ -4053,9 +4000,7 @@ var WORKFLOW_GUIDE_CONCEPT_SECTIONS = [
 var WORKFLOW_GUIDE_CLI_SECTIONS = [
   { title: "CLI: Seed Workflows", slug: "cli-seeds", content: cli_seeds_default },
   { title: "CLI: API Sequences", slug: "cli-api-sequences", content: cli_api_sequences_default },
-  { title: "CLI: Chat Evals", slug: "cli-chat-evals", content: cli_chat_evals_default },
-  { title: "Write a Test from the CLI", slug: "write-a-test", content: write_a_test_default },
-  { title: "Prove a Change with Tests", slug: "prove-changes", content: prove_changes_default }
+  { title: "Write a Test from the CLI", slug: "write-a-test", content: write_a_test_default }
 ];
 var WORKFLOW_GUIDE_SECTIONS = [
   ...WORKFLOW_GUIDE_CONCEPT_SECTIONS,
@@ -4601,6 +4546,7 @@ function printWorkflowHelp() {
       "  patch <workflowId> [options]                Update workflow properties",
       "  approve <workflowId> [--yes] [--json]       Mark the test as human-verified (spec is right)",
       "  promote <workflowId> [--force] [--json]     Include the test in suite runs (promotion model; requires approval)",
+      "  set-promotion <workflowId> --promote-on merge|never|deploy:<stage> [--target-suite <suite>]...  Configure proof promotion (never: archived at merge); target suites replace the current list",
       "  status <workflowId> [--set <status>]        Show or change the management status (blocked, paused, \u2026)",
       "  events <workflowId> [--limit <n>] [--json]  Audit timeline: status changes + node (de)activations",
       "  revisions <list|get|restore> <workflowId> [number]  Immutable definition history",
@@ -4803,7 +4749,7 @@ async function runWorkflow(argv) {
     return;
   }
   if (subCommand === "debug" && hasFlag(rest, "--help", "-h")) {
-    const { handleWorkflowDebug } = await import("./workflow-debug-RACNWWOL.js");
+    const { handleWorkflowDebug } = await import("./workflow-debug-HZB7TJGK.js");
     await handleWorkflowDebug(rest, "", "");
     return;
   }
@@ -4817,6 +4763,12 @@ async function runWorkflow(argv) {
     printGuide(WORKFLOW_GUIDE_SECTIONS, sectionSlug, jsonOutput);
     return;
   }
+  if (subCommand === "set-promotion") {
+    const { apiUrl: apiUrl2, token: token2 } = await resolveConfig(argv);
+    const { handleWorkflowPromotion } = await import("./workflow-promotion-U6WYFY5U.js");
+    await handleWorkflowPromotion(rest, apiUrl2, token2);
+    return;
+  }
   const { apiUrl, token, appSubdomain } = await resolveConfig(argv);
   switch (subCommand) {
     case "list":
@@ -4859,24 +4811,24 @@ async function runWorkflow(argv) {
       await runWorkflowRuns(rest, apiUrl, token);
       break;
     case "status": {
-      const { handleWorkflowStatus } = await import("./workflow-status-7KL73WS2.js");
+      const { handleWorkflowStatus } = await import("./workflow-status-RA3IEMEW.js");
       await handleWorkflowStatus(rest, apiUrl, token);
       break;
     }
     case "events": {
-      const { handleWorkflowEvents } = await import("./workflow-status-7KL73WS2.js");
+      const { handleWorkflowEvents } = await import("./workflow-status-RA3IEMEW.js");
       await handleWorkflowEvents(rest, apiUrl, token);
       break;
     }
     case "revisions": {
-      const { handleWorkflowRevisions } = await import("./workflow-revisions-5M6APN6R.js");
+      const { handleWorkflowRevisions } = await import("./workflow-revisions-BPUOLCZB.js");
       await handleWorkflowRevisions(rest, apiUrl, token);
       break;
     }
     case "event": {
       const [eventSub, ...eventRest] = rest;
       if (eventSub === "ticket") {
-        const { handleWorkflowEventTicket } = await import("./workflow-status-7KL73WS2.js");
+        const { handleWorkflowEventTicket } = await import("./workflow-status-RA3IEMEW.js");
         await handleWorkflowEventTicket(eventRest, apiUrl, token);
       } else {
         console.error(`Unknown event sub-command: ${eventSub ?? "(none)"}`);
@@ -4890,7 +4842,7 @@ async function runWorkflow(argv) {
       if (nodeSub === "patch") {
         await handleNodePatch(nodeRest, apiUrl, token);
       } else if (nodeSub === "deactivate" || nodeSub === "activate") {
-        const { handleNodeDeactivateToggle } = await import("./workflow-status-7KL73WS2.js");
+        const { handleNodeDeactivateToggle } = await import("./workflow-status-RA3IEMEW.js");
         await handleNodeDeactivateToggle(nodeRest, apiUrl, token, nodeSub === "deactivate");
       } else {
         console.error(`Unknown node sub-command: ${nodeSub ?? "(none)"}`);
@@ -4914,12 +4866,12 @@ async function runWorkflow(argv) {
       await handleWorkflowSync(rest, apiUrl, token);
       break;
     case "fork": {
-      const { handleWorkflowFork } = await import("./workflow-fork-LINDCYJ3.js");
+      const { handleWorkflowFork } = await import("./workflow-fork-IDYHAHCX.js");
       await handleWorkflowFork(rest, apiUrl, token);
       break;
     }
     case "proposals": {
-      const { handleWorkflowProposals } = await import("./workflow-proposals-E4EXKAGM.js");
+      const { handleWorkflowProposals } = await import("./workflow-proposals-MMVNIQT3.js");
       await handleWorkflowProposals(rest, apiUrl, token);
       break;
     }
@@ -4930,17 +4882,17 @@ async function runWorkflow(argv) {
       await handleWorkflowApiSequence(rest, apiUrl, token);
       break;
     case "cache": {
-      const { handleWorkflowCache } = await import("./workflow-cache-PFBTWLGM.js");
+      const { handleWorkflowCache } = await import("./workflow-cache-YQ3BGJIG.js");
       await handleWorkflowCache(rest, apiUrl, token);
       break;
     }
     case "debug": {
-      const { handleWorkflowDebug } = await import("./workflow-debug-RACNWWOL.js");
+      const { handleWorkflowDebug } = await import("./workflow-debug-HZB7TJGK.js");
       await handleWorkflowDebug(rest, apiUrl, token);
       break;
     }
     case "feedback": {
-      const { handleWorkflowFeedback } = await import("./workflow-feedback-RJIQ5R3R.js");
+      const { handleWorkflowFeedback } = await import("./workflow-feedback-6UOTIWIQ.js");
       await handleWorkflowFeedback(rest, apiUrl, token);
       break;
     }
@@ -4956,4 +4908,4 @@ export {
   runWorkflow,
   shouldPrintWorkflowUrlTrailer
 };
-//# sourceMappingURL=workflow-R5QAXWBX.js.map
+//# sourceMappingURL=workflow-34YJZ2QQ.js.map