@controllerai/cli 0.2.20 → 0.2.22

package/skills/controllerai-triggers/references/lifecycle.md

@@ -1,71 +1,59 @@
+<!-- generated from .claude/skills by cli/scripts/render-skills.mjs; edit the source -->
 # Trigger lifecycle
 
 ## State sequence
 
 ```text
-source decision
-  -> exact node/event discovery
+source decision (basis)
+  -> exact node and event
   -> connection
-  -> dynamic prop resolution
-  -> create source + canvas
-  -> map payload into target flow
-  -> capture representative event
-  -> select typed sample
-  -> test target flow on development
-  -> replay captured event against development
-  -> publish workflow
+  -> prop and option resolution (latest dynamicPropsId)
+  -> create source and canvas trigger (triggerId, backendTriggerId, triggerNodeId, runSubflowNodeId)
+  -> declare the flow inputs
+  -> capture a representative event, select it
+  -> bind one mapping prop per input on the run-subflow node
+  -> run the target flow on development
+  -> replay the captured event on development
+  -> audit every trigger, then authorized publish
   -> optional live replay
 ```
 
-Skipping capture/sample selection commonly leaves downstream output untyped. Skipping mapping commonly produces a green trigger execution with empty flow inputs.
+Skipping capture or selection leaves the trigger output untyped. Skipping the mapping produces a green trigger execution with empty flow inputs. Leaving ambient dispatch allowed can produce double runs after publish.
 
 ## IDs
 
 | ID | Used by |
 | --- | --- |
-| Canvas `triggerId` | `trigger get`, `rename`, `set-enabled`, `delete`, `test-events` |
-| Numeric `backendTriggerId` | `trigger events`, `replay` |
-| `triggerNodeId` | `trigger select-event` |
-| Captured `eventId` | `trigger event`, `select-event`, `replay --event` |
+| Canvas `triggerId` | get, rename, set-enabled, delete, test-events |
+| Numeric `backendTriggerId` | captured events, replay (`--trigger`) |
+| `triggerNodeId` | select-event |
+| `runSubflowNodeId` | the mapping props, one per flow input |
+| Captured `eventId` | event read, select-event, replay |
 
-Always copy these from the transport output.
+Copy them from the responses. A replaced trigger has new IDs and possibly a new webhook URL.
 
-Development replay is the normal pre-publish check:
+## Switches and acknowledgements
 
-```bash
-cai trigger replay --trigger <backendTriggerId> --event <eventId> --target dev --json
-```
-
-Use `--target live --confirm-live` only for an intentional post-publish live verification.
-
-## Enable/disable
-
-`cai trigger set-enabled <triggerId> --enable|--disable` sets the requested state idempotently. Pass exactly one state flag.
+| Switch | Flags | Meaning |
+| --- | --- | --- |
+| Definition state | `set-enabled --enable` / `--disable` | Whether the trigger starts its flow; development edit until published |
+| Ambient development dispatch | `test-events --allow --acknowledge-dual-run` / `--disallow` | Real events also execute the development canvas; sticky permission bit, survives disable |
+| Replay rail | `replay --target dev` / `--target live --confirm-live` | Which version one captured event executes |
+| Publish while armed | `workflow publish --acknowledge-dual-dispatch` | User's informed acceptance of double runs and double billing |
 
-MCP: call `trigger_set_enabled` with `enabled: true` or `enabled: false`.
-
-## Lifecycle flag families
-
-```bash
-cai trigger set-enabled <triggerId> --enable|--disable --json
-cai trigger test-events <triggerId> --allow [--acknowledge-dual-run] --json
-cai trigger test-events <triggerId> --disallow --json
-cai trigger replay --trigger <backendTriggerId> --target dev --json
-cai trigger replay --trigger <backendTriggerId> --target live --confirm-live --json
-cai workflow publish --acknowledge-dual-dispatch --json
-```
+Each acknowledgement belongs to exactly one operation. Arming, publishing armed and live replay are three separate user decisions.
 
-Use enable/disable for the trigger definition, allow/disallow for ambient development capture, and target for replay rail. `--acknowledge-dual-run` applies only while arming. `--acknowledge-dual-dispatch` applies only when publishing an armed trigger. `--confirm-live` applies only to one Live replay. These acknowledgements are not interchangeable.
+## Lifecycle fields
 
-The allow flag is sticky even when the trigger is disabled. Always disallow after capture or an abandoned setup so later re-enablement cannot silently rearm development dispatch.
+The list and get reads report `devCanvasEnabled` at the top level and, under `deployment`, `liveCanvasEnabled` (null when no live canvas exists: never published, or this trigger was added after the last publish), `inLiveVersion`, `devDispatchArmed` (enabled and allowed) and `dualDispatchLive`; get adds captured event counts and issues. The audit summarizes coverage and double-run risk before a publish and names the disarm step for each armed trigger.
 
-## Debugging a missing run
+## Missing-run diagnosis
 
-1. `cai trigger list --json`: enabled, correct flow, recoverable backend ID.
-2. `cai workflow status --json`: published/active live state.
-3. `cai trigger events --trigger <backendId>`: did ingestion capture the event?
-4. `cai trigger event <eventId>`: does payload match the selected sample?
-5. `cai exec list --json`: did execution start?
-6. `cai exec tree <executionId> --json`: where did it stop?
+1. The trigger list: enabled, correct flow, recoverable backend ID?
+2. The workflow status: published, and is the live version active?
+3. The captured events for the backend trigger ID: did ingestion capture the event?
+4. The event read: does the payload match the selected sample?
+5. The execution list: did an execution start?
+6. The execution tree: where did it stop?
 
-No captured event means source/delivery/configuration. Captured event with no execution means enable/live/ingestion routing. An execution with empty inputs means mapping.
+No captured event points to the source, delivery or configuration. A captured event with no execution points to enablement, publish state or ingestion routing. An execution with empty inputs points to the mapping. Development works but live does not: compare the enabled state and the published configuration, and remember that live runs read the live data store.

package/skills/controllerai-workflows/SKILL.md

@@ -1,46 +1,126 @@
 ---
 name: controllerai-workflows
-description: Build, inspect, repair, test and publish Controller AI workflows: typed callable flows, deterministic actions, branching, durable workflow data and triggers. Use for automations or an agent-callable application backend.
+description: Build, inspect, edit, recover, and publish Controller AI workflows and their flows. Use when a user asks to create or change an automation, a flow, or a workflow release, and for the lifecycle rules every other workflow skill relies on.
 ---
+<!-- generated from .claude/skills by cli/scripts/render-skills.mjs; edit the source -->
 
-# Controller AI workflows
+# Workflows
 
-A workflow groups **flows**, **custom schemas**, **data collections** and **triggers**. A flow is one callable function with typed inputs and outputs; its connected nodes implement the function. Several flows can share the workflow's data store and call one another.
+## Use this when
 
-Flows are useful as API-like tools for agents. For example one “Investor CRM” workflow can expose create/get/update/delete/search flows for contacts, companies, deals and activities, plus a contact history view. An agent chooses a tool; the flow enforces its contract and performs the work.
+- Creating a workflow, adding or repairing flows, orienting inside an existing graph, validating, checkpointing, restoring, publishing, or deleting.
+- Another skill needs the shared lifecycle rules: which rail an edit lands on, how contracts and IDs behave, what validation and publishing require.
 
-## Start with the contract
+Load the narrow skill when the work reaches it: nodes, connections, props and wiring → `controllerai-node-config`; computed values and conditions → `controllerai-expressions`; Router, If/Else, loops, joins, subflows → `controllerai-flow-control`; runs and debugging → `controllerai-runs`; schedules, webhooks, app events → `controllerai-triggers`; schemas and records → `controllerai-data`; Ask AI and agent nodes → `controllerai-ai-nodes`; user-facing agents → `controllerai-agents`.
 
-Define each flow's inputs, outputs and failure behavior. Keep one operation per agent tool when that makes selection clearer than a giant operation dispatcher. Choose useful names and descriptions: “Search contacts by name, owner, tags and status” tells an agent when to call it.
+## How it works
 
-Create the workflow, then explicitly create the first flow. `workflow_outline` provides a compact inventory; `flow_get` provides a flow's contracts, graph and configured values. Workflow IDs, flow IDs and node IDs are different identities.
+A **workflow** groups flows, custom schemas, data collections and triggers, and its flows share one data store per environment. A **flow** is one canvas and one callable contract: typed inputs, connected nodes, typed outputs. A Return node maps values into the declared outputs; declaring an output does not fill it. Workflow, flow, node, input and output IDs are distinct identities; never swap one for another.
 
-Before changing an existing workflow, read its outline and the affected flow. Repair the existing IDs instead of creating replacements. For a substantial rewrite, save a named checkpoint. Restore rolls back the definition, not record changes or external effects.
+Every graph edit lands on the **development** version. Publishing creates the **live** release; a live agent that uses the workflow as a tool follows its latest live release without an agent publish, while the owner's Test conversations run the development version. Publishing never copies development records into the live store, and every environment keeps its own data.
 
-## Assemble and test
+Every save is a **state**. History lists states in groups and gives candidate state IDs; a restore rolls the definition back to one state and leaves records and external effects untouched. How far back history is listed and how far back a state can be restored are two separate plan limits, so a listed state is not always restorable.
 
-1. Create any custom schemas and flow inputs/outputs first.
-2. Discover actions and add nodes in execution order. Configure the type or action selector before dependent props; reload props if the selector changes.
-3. Bind expressions using current `expr_context` names. Wire the source output to the destination so it appears in `inputs`.
-4. Use a Return node to map promised flow outputs. Merely declaring an output does not populate it.
-5. Test a complete development path with explicit representative input. Check the returned contract and same-environment data changes.
-6. Apply the proven pattern to additional paths. Batch independent configuration when the available tool supports it; do not combine operations whose IDs depend on earlier responses.
-7. Layout each changed flow, validate the saved workflow, and re-read its outline.
+Deleting a workflow tears down its deployed triggers and soft-deletes it. It is refused while any draft or live agent depends on the workflow, and nothing undeletes. The dependency map shows a workflow's agent and workflow callers and the connections it uses. Deleting a flow removes its graph, its contract and the triggers targeting it, and breaks every caller bound to it.
 
-Use `controllerai-node-config` for action configuration, `controllerai-expressions` for computed values, `controllerai-flow-control` for routing/loops, `controllerai-data` for storage and `controllerai-runs` for execution evidence.
+The account event feed records only supported events: connections created, workflows created, updated, deleted, published and run, agents created and published, members added. Settings changes, member removals and label edits are not in it, and a past change that is not recorded cannot be reconstructed from names or current state.
 
-## Files and agents
+## Rules
 
-A chat attachment is handled by a user-facing agent. For CSV enrichment, make a per-row flow accepting `investorName` and optional `company`, returning normalized contact information and evidence. The agent reads and writes the CSV. The native Create File action can generate files; it does not imply a native CSV reader/upload trigger.
+1. **Before changing an existing workflow, read its outline and the affected flow**, then repair those IDs rather than creating a replacement workflow or flow. A repair that recreates loses history, triggers and callers.
+2. **Rename contracts in place.** Deleting and recreating an input or output breaks every expression, subflow mapping and agent tool bound to it. After a rename or deletion, re-read the flow and repair the affected dependents before validating or running; a stored input-ID binding survives a rename, so the readback may show nothing to repair.
+3. **"Store, save, log, record" without a named destination means a custom data type plus a create-record node.** A flow output alone persists nothing. When the user names a destination (a sheet, a CRM, an app, a file), write there through that integration; add a platform record only if they also want a copy kept here.
+4. **Validate after structural edits and before publishing.** Fix every listed prop, wire, expression, type, subflow, branch and trigger error, or report each one with what it breaks. Publish refuses errors; `--acknowledge-validation-errors` is for issues the user has seen and accepted, never a shortcut. If the user forbids a repair, report and stop.
+5. **Validation counts are status.** Do not write them into unrelated workflow properties unless the user asks for exactly that.
+6. **Deleting a workflow needs the user's explicit intent.** A confirmation flag is not authorization. Check dependencies first; detach draft tools with `cai agent remove-tool <agentId> --tool <toolId>`, and treat a live agent's republish as its own decision.
+7. **Layout once per changed flow.** After adds, deletes or rewires, run the flow layout as the last structural step; placement at add time only avoids overlap.
+8. **Never weaken the request to make a test pass.** Report an unsupported capability or ask the product question. Keep deliberately armed triggers and advisory-only nodes the user chose.
+9. **A conflict means re-read, then reapply the intent to the current graph.** Never replay a stale document or old IDs; the retried write uses the IDs the current state holds.
+10. **Say "not recorded" and change nothing** when asked to reconstruct history the feed does not hold.
 
-For an agent tool, attach the tested flow with `agent_tool_workflow_add`. Its flow inputs and outputs are the tool contract. For unattended operation, add a trigger and map its event into these same inputs.
+## Recipes
 
-## Release and recovery
+### Establish context
 
-Graph edits affect development. Publishing creates the workflow's live release; attached live agents follow its latest release without another agent publish. The development/live record stores remain separate.
+```bash
+cai auth status --json
+cai workflow list --json
+cai use <workflowId>
+cai workflow status --json
+```
 
-Use the user's existing authorization when deciding whether to publish. If publication is authorized, fix validation errors, publish, then verify Live. For a draft-only request, deliver the tested draft and its link.
+A create or `cai use` may not win the effective pin: read `selected`, `effectiveWorkflowId` and `pinSource`, and resolve as `pinSource` says (drop the command flag, use `cai use <id>`, or clear an inherited `CAI_WORKFLOW`). `cai config reset` clears stored pins only; `cai doctor` confirms the effective pin and development head.
 
-On a state conflict, re-read the current saved version and reapply the intended change. Do not overwrite a newer graph with an old document. Report validation issues by their practical effect and inspect empty results where data was expected.
+### Create
 
-Detailed CLI/MCP sequences and lifecycle operations: [command reference](references/command-reference.md). Multi-domain command lookup: [command map](references/command-map.md).
+```bash
+cai workflow create --name "<clear outcome-oriented name>" --json
+```
+
+Create with the final name. Read `flowCount` and `nextStep`: with 0 flows, create the first flow with `cai flow create --name "<name>" --json`; with one empty default flow, rename it and build in it; when either field is missing, list the flows before deciding. Add flows only for genuinely separate canvases, and stop at an empty workflow when that is what was asked. A missing projected field is not a failed create: read the full result or the exact inventory before retrying.
+
+### Orient
+
+```bash
+cai workflow outline --json
+cai workflow state --flow <flowId> --json
+cai flow get <flowId> --json
+```
+
+The outline shows flows, contracts, graph dependencies, triggers and data inventory in one call. State is a bounded projection; pass the flow ID for node and edge identities. The flow read exposes props and expressions.
+
+### Build
+
+1. Translate the request into inputs, steps, outputs, trigger, integrations, failure behavior and publish intent.
+2. Declare flow inputs and outputs before nodes whose props derive from them. Pass a human display label; use the current binding from `flow get` (`jsBinding`) or the outline (`binding`), never the diagnostic `legacyBinding`.
+3. Add nodes in execution order and name each after the data it produces; downstream bindings are seeded from that name when wired.
+4. Lay out each changed flow, validate, test on development, re-read status. Publish only when the user asked for a live change or authorized deployment.
+
+### Publish
+
+```bash
+cai workflow status --json
+cai trigger list --json
+cai workflow publish --json
+```
+
+Read status and every trigger first: publishing activates enabled triggers on the live release. The publish refuses validation errors and may return an approval that the user must grant.
+
+When the publish returns an approval, the CLI polls it; if polling is interrupted, `cai approval resume <approvalId>` continues the same intent instead of publishing again.
+
+### Checkpoint and recover
+
+```bash
+cai workflow save --name "<checkpoint>" --json
+cai workflow history --json
+cai workflow history --group <groupId> --json
+cai workflow restore --state <stateId> --json
+```
+
+Save before a risky rewrite. Expand a group to find the state ID; restore by state, not by group.
+
+### Delete
+
+```bash
+cai deps --json
+cai workflow delete <workflowId> --yes
+```
+`cai deps --account` maps the whole account. The `--force` flag is deprecated and inert.
+
+## Verify
+
+```bash
+cai workflow outline --json
+cai workflow validate --json
+cai workflow status --json
+cai flow get <flowId> --json
+cai run flow <flowId> --inputs <values.json> --json
+```
+
+Evidence that a build works: validation reports zero errors, or each remaining error is reported with its effect; required connections and props are complete; expressions resolve to the expected values, with intentional empties explained; the expected branch and error paths ran where practical; the flow outputs contain the promised values; the development or live state matches the request; the final outline matches the request, with only your own abandoned scratch objects removed. A checkpoint or a rename needs its readback, not a run. Once the requested blockers are fixed and each changed path ran once, stop; warnings alone do not justify a redesign.
+
+## Report
+
+What was built, what ran and what it returned, whether it is published, and any connection or product decision still pending. Share returned product links only; never guess one.
+
+Read [references/command-map.md](references/command-map.md) for the command families by domain when a task spans several areas.

package/skills/controllerai-workflows/references/command-map.md

@@ -1,40 +1,28 @@
-# Workflow command map
+<!-- generated from .claude/skills by cli/scripts/render-skills.mjs; edit the source -->
+# Workflow command families
 
-Read only the sections relevant to the requested work. On the CLI, use `cai <domain> --help` for flags. On MCP, inspect the typed tool schema and [the generated map](../../controllerai-start/references/mcp-tool-map.md).
+Read the family you need; `cai <domain> --help` lists flags, and the [generated tool map](../../controllerai-start/references/mcp-tool-map.md) gives the MCP tool and parameter names.
 
-## Setup and workflow lifecycle
+## Lifecycle
 
 ```text
-cai connect
-cai doctor
-cai config reset [--local|--global]
-cai auth status
 cai workflow list|create|get|rename|set-description|duplicate|delete
-cai workflow document|state|status|versions|releases|history|save|restore|publish
-cai use <workflowId>
+cai workflow outline|document|state|status|versions|releases|history|save|restore|publish
 ```
 
-MCP: `account_status` replaces `auth status` and `doctor`; `cai connect`, `config reset`, and `use` are local-only, so pass `workflowId` explicitly.
+`outline` is the compact inventory; `state --flow <flowId>` adds node and edge identities; `document` is the complete JSON. `save` creates a named checkpoint, `restore --state <stateId>` rolls the definition back, `publish` creates the live release and refuses validation errors unless the user has accepted them explicitly. `delete --yes` undeploys triggers and soft-deletes; it is refused while a draft or live agent depends on the workflow.
 
-`workflow state` is a bounded projection; use `--flow <flowId>` for node and edge identities. `workflow document` returns the complete opaque JSON. `workflow save` creates a named development checkpoint. `workflow publish` promotes development to live. Version history may be plan-gated. `workflow delete --yes` undeploys triggers and soft-deletes the workflow row; it refuses while any draft or LIVE agent depends on the workflow. Detach draft tools with `agent remove-tool`, publish detached drafts that are still LIVE, then retry. `--force` is deprecated and inert. Deletion is not a permanent history purge, and deleted rows currently have no CLI restore command.
-
-## Canvas and graph
+## Canvas
 
 ```text
 cai flow list|get|create|rename|duplicate|delete|reorder|layout
 cai flow input add|update|delete
 cai flow output add|update|delete
 cai integration search|actions|action
-cai node init|status|get|props|set|connect|disconnect|delete
+cai node add|status|get|props|set|connect|disconnect|delete
 ```
 
-MCP: `node set` and `expr set` are merged into `node_prop_set`.
-
-Declare flow outputs before adding a Return response node. Its props are derived from those outputs.
-
-`cai flow input add <flowId> --display "<human label>" --type <type>` returns the compiler-current `jsBinding`. Use the latest value from `flow get` (`jsBinding`) or `workflow outline` (`binding`), re-read it after every input rename, and never cache its spelling across renames. `legacyBinding` is diagnostic-only.
-
-## Conditions and composition
+## Composition
 
 ```text
 cai node only-when
@@ -43,38 +31,26 @@ cai flow for-each
 cai node set-flow
 ```
 
-MCP: use `flow_for_each_scaffold` for `flow for-each` and `node_subflow_set` for `node set-flow`; pass file-based loop source inline as `listJs` and branch condition source as `js`.
-
-Use branch-specific connection commands for Router and If/Else outputs. Generic `node connect` supports only `main` and `error` outputs.
+Router and If/Else outputs connect through the branch commands; generic `node connect` handles only `main` and `error` outputs.
 
 ## Verification
 
 ```text
 cai run inputs|node|flow|discover
-cai exec list|get|flow|node|ports|tree
+cai exec list|get|flow|node|tree
 ```
 
-MCP: `run_node` and `run_flow` take `waitSeconds` (default 60, maximum 120). `run_discover` never keeps its scratch graph.
+`run discover` executes the real action in a scratch flow and can cause third-party effects or charges; do not use it casually on mutating actions.
 
-`run discover` executes the real integration action in a scratch flow and can incur third-party effects or usage. Do not use it casually for mutating actions.
-
-## Product surfaces
+## Other domains
 
 ```text
-cai connection list|connect
-cai trigger list|get|search|props|options|create|events|event|select-event|replay|set-enabled|rename|delete
-cai schema list|get|resolve|create|update|delete
-cai data collections|fields|query|get|create|update|delete|delete-many|import|copy-to-live
-cai agent list|get|create|update|add-workflow|remove-tool|add-file|tools|publish-preflight|publish|versions|visibility
-cai agent conversation list|create|status|history|send|approve|deny
+cai connection list|update|delete
+cai trigger list|get|create|search|replay|test-events
+cai schema list|create|update|delete
+cai data collections|query|create|update|delete|import
+cai agent create|get|list|update|add-workflow|add-action|add-file|remove-tool|publish|conversation
+cai template-setup status|complete
 ```
 
-Connections are authorized in a browser. The CLI returns and may open the URL; MCP returns it from `connection_connect_url`.
-
-MCP: `trigger_set_enabled` takes the same explicit enabled state as the CLI setter.
-
-MCP: every data write requires explicit `env`; pass CSV text inline as `content` to `data_record_import`, and pass `env: "live"` to `data_copy_to_live`.
-
-MCP: `agent update` splits into `agent_update` and `agent_set_enabled`; `agent add-file` splits into `agent_knowledge_file_add` and `agent_workspace_file_add` with inline `content`. `agent_conversation_send` takes `waitSeconds`.
-
-Agent visibility supports only `private` and `organization`; organization is an explicit live access change after agent publish.
+Each family has its own skill; the map above covers CLI-to-MCP names for all of them.