@db-lyon/flowkit 0.17.2 → 0.18.0

package/docs/configuration.md

@@ -33,6 +33,10 @@ tasks:
 | `description` | `string` | no | Human-readable description |
 | `group` | `string` | no | Logical grouping label |
 | `options` | `object` | no | Default options (merged with step-level overrides) |
+| `options_schema` | `object` | no | Declared options, refining the class's `optionsSchema`. See [Declaring options](custom-tasks.md#declaring-options) |
+| `outputs` | `object` | no | Declared `data` outputs (`type`, `description`), for `describe`. Not enforced |
+| `deprecated` | `boolean \| string` | no | Mark the task deprecated. See [Deprecation](#deprecation) |
+| `replaced_by` | `string` | no | The task to use instead, named in the deprecation warning |
 
 ### Flow definition
 
@@ -49,22 +53,32 @@ flows:
         flow: other_flow            # reference another flow (nesting)
       3:
         task: None                  # skip sentinel — step is always skipped
+      4:
+        flow: None                  # same, for a step that referenced a flow
 ```
 
 | Field | Type | Required | Description |
 |-------|------|----------|-------------|
 | `description` | `string` | yes | Human-readable flow description |
 | `steps` | `object` | yes | Steps keyed by number (execution order) |
+| `checks` | `array` | no | Flow-level preflight checks. See [Preflight checks](#preflight-checks) |
+| `options_scope` | `'flat' \| 'step'` | no | How runtime `params` reach steps. See [Step-scoped runtime options](#step-scoped-runtime-options) |
+| `deprecated` | `boolean \| string` | no | Mark the flow deprecated. See [Deprecation](#deprecation) |
+| `replaced_by` | `string` | no | The flow to use instead, named in the deprecation warning |
 
 ### Flow step
 
-Each step must have exactly one of `task` or `flow` (mutually exclusive), unless `task: None` is used to mark a skipped step.
+Each step must have exactly one of `task` or `flow` (mutually exclusive), unless `task: None` or `flow: None` is used to mark a skipped step. `None` in either slot wins, so an overlay can switch off an inherited step by number whichever key the base used.
 
 | Field | Type | Required | Description |
 |-------|------|----------|-------------|
 | `task` | `string` | one of task/flow | Task name to execute |
 | `flow` | `string` | one of task/flow | Nested flow name to execute |
 | `options` | `object` | no | Override options for this step |
+| `when` | `string \| boolean` | no | Run the step only when truthy |
+| `ignore_failure` | `boolean` | no | Record a failure and continue |
+| `retries` / `retryDelay` / `retryOn` | | no | See [Per-step retry](#per-step-retry) |
+| `checks` | `array` | no | Preflight checks. See [Preflight checks](#preflight-checks) |
 
 Step numbers are sorted numerically at execution time, so `1, 2, 10` runs in that order (not lexicographic `1, 10, 2`).
 
@@ -93,6 +107,56 @@ flows:
 
 Runtime parameters passed to `FlowRunner.run({ params })` merge on top with the highest priority (**task defaults < step overrides < runtime params**).
 
+### Step-scoped runtime options
+
+By default runtime `params` are **flat**: every key is merged into every step's
+options, so `params: { environment: 'prod' }` reaches the build, the test and
+the deploy alike. Opt in to the **step** scope to address each step instead:
+
+```yaml
+flows:
+  release:
+    options_scope: step          # or FlowRunnerConfig.optionsScope / run({ optionsScope })
+    steps:
+      1: { task: build }
+      2: { flow: ci }            # ci: 1: lint, 2: test
+      3: { task: deploy }
+```
+
+```typescript
+await runner.run({
+  flowName: 'release',
+  params: {
+    deploy: { environment: 'prod' },   // every step running the `deploy` task
+    '2/2': { coverage: 90 },           // step 2 of the flow run by step 2 (ci's `test`)
+    '1': { target: 'release' },        // main step 1
+  },
+});
+```
+
+Under the step scope each `params` key is a **selector** and its value an
+options object:
+
+| Selector | Matches |
+|----------|---------|
+| a task name, e.g. `deploy` or `asset.list` (dots are part of the name) | every step running that task, anywhere in the run: main steps, nested flows and hook steps |
+| a step path, e.g. `3` or `2/1` | one main step; `/` descends into the flow a step runs, as in an expanded plan's `path` |
+
+- A path is more specific than a name: when both address a step, the path's
+  value wins on a shared key.
+- The scoped value takes the runtime slot in the precedence order, so it
+  still overrides task defaults, enclosing-flow overrides and step options.
+- A selector that matches no task name or step path, or a value that is not an
+  object, fails the run (and a plan) before anything starts, naming each bad key.
+- Hook steps are addressed by task name only.
+- The scope is fixed by the flow the run starts on. Nested flows follow it and
+  their own `options_scope` is ignored.
+- `when:` expressions and `conditionEvaluator` still receive `params` as passed.
+
+Resolution order for the scope: `run({ optionsScope })`, then the flow's
+`options_scope`, then `FlowRunnerConfig.optionsScope`, then `flat`. Nothing
+changes unless one of them says `step`.
+
 ### Step references
 
 Option values may reference the output of earlier steps in the same flow using `${steps.<id>.<path>}`:
@@ -121,6 +185,43 @@ flows:
 
 References resolve just before the step runs, against the results of already-completed steps in the current flow. Nested flows have their own reference scope — they don't see their parent flow's steps.
 
+#### Binding by identity, and the uniqueness rule
+
+A reference names a step by **identity**, its number or its task name, never by
+position relative to the referencing step. That is why step numbers are worth
+keeping stable (and gapped: `10`, `20`, `30`): an overlay that inserts step `15`
+changes no reference.
+
+- A number binds to exactly one step. Prefer it whenever a task runs more than
+  once in a flow.
+- A name binds to the step running that task. When several main steps run the
+  same task, the runtime rule is the one above: the most recently completed
+  one wins. That is well defined but fragile, because which one is "most
+  recent" depends on where the referencing step sits.
+- The same resolution applies in `when:` and in check `when`s. Hook steps see
+  every main step that ran. A flow step's `options` are overrides for the
+  tasks inside the nested flow, and references in them resolve against the
+  nested flow's steps.
+
+Set `strictStepReferences: true` on the `FlowRunner` to make the uniqueness
+rule an error instead: a run or plan refuses to start, naming each reference,
+when a `${steps.<id>}` in a step's options, `when` or checks is **ambiguous** (a
+name used by more than one main step), **unknown** (no such number or name) or
+**forward** (the step has not run yet at that point). The check covers the flow
+a run starts on and every flow nested under it. It is opt-in because a config
+that relies on "most recent wins" would otherwise stop running.
+`runner.checkStepReferences(flowName)` returns the same findings without
+enforcing them, for a linter or a `describe` command:
+
+```typescript
+runner.checkStepReferences('release');
+// [{ flowName: 'release', stepNumber: 3, reference: '${steps.deploy.url}', kind: 'ambiguous',
+//    message: '${steps.deploy.url}: "deploy" is the name of steps 1, 2; reference one by number' }]
+```
+
+Task definition defaults are not scanned: they resolve in whichever step runs
+the task.
+
 ### Flow-level hooks
 
 A flow can attach steps that run around the main step sequence, keyed by flow outcome:
@@ -227,6 +328,108 @@ steps:
 
 Returns `{ text, parsed?, usage? }`. Provider failures become step failures; missing provider is a clear error.
 
+### Preflight checks
+
+A flow or a step can declare `checks`: conditions that gate it, evaluated by the
+same `conditionEvaluator` as `when:` (or the built-in `${...}` truthiness
+fallback). A check **fires** when its `when` is truthy, and its `action` applies:
+
+| `action` | At run time |
+|----------|-------------|
+| `error` | The step fails with a `CheckFailedError` carrying `message`, before it starts. The flow aborts whatever `ignore_failure` says: a gate is not a failure to tolerate. |
+| `skip` | The step is skipped (`skipReason: 'check'`). |
+| `warn` | A `check` warning is added to `FlowRunResult.warnings` and the step runs. |
+
+```yaml
+flows:
+  import_assets:
+    checks:                                    # gate the whole flow
+      - when: "not editor.connected"
+        action: error
+        message: No editor is connected.
+    steps:
+      1:
+        task: import
+        checks:
+          - when: "editor.has_modal_dialog"
+            action: error
+            message: A modal dialog is open in the editor.
+          - when: "not project.python_enabled"
+            action: skip
+      2:
+        task: validate
+        checks:
+          - { when: "${project.dirty}", action: warn, message: Unsaved changes. }
+```
+
+- Step checks run in order, just before the step would run and after `when:`
+  has let it. Error beats skip beats warn.
+- Flow checks run before anything in the flow, `on_start` included. An `error`
+  fails the flow with no steps; a `skip` returns success with every main step
+  skipped (`skipReason: 'check'`). For a nested flow the verdict becomes the
+  flow step's.
+- Checks on hook steps are enforced too; a fired `error` is reported in
+  `hookErrors`.
+- A check whose expression throws (for example one that reads a step result
+  that does not exist) fails the step the way a throwing `when:` does, and
+  `ignore_failure` applies.
+- The evaluator's `ConditionContext` carries `check`, `step`, `flowName` and
+  `references` (the runner's host namespaces) alongside the usual `steps`,
+  `params`, `context` and `error`, so a check can be written against host state.
+- Fired checks are listed on the step (`FlowStepResult.checks`) and for the
+  whole run, nested flows included (`FlowRunResult.checks`).
+
+`FlowRunner.preflight(flowName, params?, { skip? })` evaluates every check in a
+flow without running anything and reports what would happen to each step:
+
+```typescript
+const pf = await runner.preflight('import_assets', { path: '/Game/X' });
+pf.ok;     // false when any `error` check fired
+pf.checks; // the flow's own checks, evaluated
+pf.steps;  // [{ path: '1', status: 'error', checks: [...] }, { path: '2', status: 'run', ... }]
+```
+
+Each row has a `status` of `run`, `skip` (statically, or a `skip` check fired),
+`error` or `unknown`. Nothing has run at preflight, so checks see no step
+results; one that reads a step result cannot be evaluated, its outcome carries
+the `error`, and the row is `unknown` rather than guessed. Nested flows are
+expanded with the same paths as an expanded plan, and hook steps are listed as
+`<phase>/<n>`. Plan mode (`run({ plan: true })`) lists each step's declared
+`checks` unevaluated.
+
+### Deprecation
+
+Tasks and flows can be retired without breaking the configs that still use
+them. A deprecated task or flow still runs; the run and the plan say so:
+
+```yaml
+tasks:
+  deploy_legacy:
+    class_path: tasks.Deploy
+    deprecated: "Targets the old cluster."   # or just `true`
+    replaced_by: deploy
+
+flows:
+  release_v1:
+    deprecated: true
+    replaced_by: release
+    steps:
+      1: { task: deploy_legacy }
+```
+
+- A run collects a structured warning for every deprecated task or flow it
+  ran, on the step's `result.warnings` and, without repeats, on
+  `FlowRunResult.warnings`:
+  `{ code: 'deprecated', kind: 'task', name: 'deploy_legacy', replacedBy: 'deploy', message: 'Task "deploy_legacy" is deprecated: Targets the old cluster. Use "deploy" instead.' }`.
+  `runTask` puts it on the returned `TaskResult.warnings`. The runner's logger
+  gets it at `warn` too.
+- Plan mode marks each deprecated row with `deprecated` and `replaced_by` and
+  returns the same warnings on the plan's `warnings`. Skipped steps are not
+  reported.
+- A task class can declare `static deprecated` and `static replacedBy`; a
+  definition's `deprecated` (including `false`) overrides the class.
+- `FlowRunner.describeTask(name)` and `describeFlow(name)` expose both fields.
+
 ## Config layering
 
 `loadConfig()` merges up to four layers, left to right:
@@ -315,6 +518,46 @@ Result: `['eslint', 'prettier', 'my-custom-plugin']`
 
 The `__merge` annotation is stripped from the final array.
 
+## Strict validation
+
+Zod drops keys a schema does not declare, so a typo such as `retires: 3` or
+`ignore_failur: true` loads cleanly and then does nothing. Pass `strict` to
+make the loader reject them instead:
+
+```typescript
+const { config } = loadConfig({
+  filename: 'pipeline.yml',
+  schema: EngineConfigSchema,
+  strict: true,
+});
+// UnknownConfigKeyError: Unknown config key:
+//   flows.ci.steps.2.retires (did you mean "retries"?)
+```
+
+The check runs on the merged layers, before the schema parses them, and walks
+the schema you pass: tasks, flows, steps, hook steps, agents, agent tools and
+budgets, plus any section a host adds with `EngineConfigSchema.extend(...)`.
+Free-form maps (`options`, an agent's `schema`, a tool's `parameters`) are not
+checked, and neither is any object schema declared `.passthrough()` or with a
+`.catchall()`.
+
+A host that keeps sections in the same file but does not declare them in the
+schema it passes lists them as `passthroughKeys`. Only top-level keys can be
+exempted this way:
+
+```typescript
+loadConfig({
+  filename: 'ue-mcp.yml',
+  schema: HostConfigSchema,
+  strict: { passthroughKeys: ['bridge', 'editor'] },
+});
+```
+
+Strict validation is opt-in. Without `strict`, unknown keys are dropped
+exactly as before. `findUnknownKeys(schema, value)` and
+`assertKnownKeys(schema, value)` run the same check on config that does not
+come through `loadConfig`.
+
 ## Finding config files
 
 `findConfigFile()` walks up parent directories to locate a file:
@@ -361,3 +604,21 @@ const { config } = loadConfig({
 
 // config.tasks, config.flows, config.database, config.features
 ```
+
+### Reusing the step and flow schemas
+
+A host that declares flows outside the main config file (a plugin manifest, a
+flow built in code) should validate them with flowkit's own schemas rather than
+a copy, so every step field (`when`, `ignore_failure`, `retries`, `None` skips,
+and whatever is added later) keeps working there too.
+
+```typescript
+import { FlowDefinitionSchema, FlowStepObjectSchema, refineFlowStep } from '@db-lyon/flowkit';
+
+// A whole flow, with a host-only field.
+const ManifestFlowSchema = FlowDefinitionSchema.extend({ group: z.string().optional() });
+
+// A step with a host-only field. `FlowStepSchema` is refined and cannot be
+// extended, so extend the object form and refine it again.
+const ManifestStepSchema = refineFlowStep(FlowStepObjectSchema.extend({ label: z.string().optional() }));
+```

package/docs/custom-tasks.md

@@ -55,6 +55,81 @@ export default class FetchData extends BaseTask<MyOptions> {
 | Member | Description |
 |--------|-------------|
 | `validate()` | Called before `execute()`. Throw to abort with a validation error. |
+| `static optionsSchema` | Declared options, checked before the task runs. See below. |
+| `static outputs` | Declared `data` keys, for `describe` and docs. Not enforced. |
+| `static description` | Used when the task definition has no `description`. |
+
+### Declaring options
+
+A task class can declare its options statically, the way a CumulusCI task
+declares `task_options`. `FlowRunner` checks a step's final options against the
+declaration before it constructs the task, so a bad option fails with a message
+naming the task and the option, and the task never runs:
+
+```typescript
+import { BaseTask, type OptionSpecs, type TaskResult } from '@db-lyon/flowkit';
+
+export default class Deploy extends BaseTask<{ environment: string; replicas: number }> {
+  static description = 'Deploy the build';
+  static optionsSchema: OptionSpecs = {
+    environment: { type: 'string', enum: ['staging', 'prod'], required: true, description: 'Target' },
+    replicas: { type: 'integer', minimum: 1, maximum: 5, default: 2 },
+  };
+  static outputs = { url: { type: 'string', description: 'Where it landed' } };
+
+  get taskName() { return 'deploy'; }
+  async execute(): Promise<TaskResult> { /* ... */ return { success: true }; }
+}
+// Task "deploy": option "environment" must be one of ["staging","prod"]
+```
+
+Each option spec takes `type` (one type or a list), `description`,
+`required`, `default`, and the JSON Schema constraint keywords `enum`, `const`,
+`minimum`, `maximum`, `exclusiveMinimum`, `exclusiveMaximum`, `minLength`,
+`maxLength`, `pattern`, `minItems`, `maxItems`, `items`, `properties`,
+`additionalProperties` and `nullable`.
+
+- `default` fills an option no layer supplied. It is the lowest precedence of
+  all, below the task definition's `options`.
+- `required` is checked after every layer (defaults, definition options, step
+  options, runtime params) has been merged.
+- Options the schema does not declare are allowed through.
+- A failed check is not retried, whatever the step's `retries`.
+
+A task definition refines the class declaration with `options_schema`, option
+by option and field by field, so one configured variant can narrow an enum,
+change a default or add an option without restating the rest:
+
+```yaml
+tasks:
+  deploy_staging:
+    class_path: tasks.Deploy
+    options_schema:
+      environment: { enum: [staging], default: staging }
+```
+
+The check runs on every `FlowRunner` path: flow steps, hook steps, `runTask`,
+rollback and composite child steps. A task built directly (`new Deploy(...)`)
+or through `this.call()` from another task is not checked.
+`validateTaskOptions(specs, options)` and `assertTaskOptions(name, specs,
+options)` run the same check for a host that constructs tasks itself.
+
+### Describing a task
+
+`registry.describe(name, taskDefinitions?)` folds a task's class metadata and
+its configured definition into one object, for a host's `describe` command or
+generated docs. `FlowRunner.describeTask(name)` does the same with the
+runner's own definitions:
+
+```typescript
+const d = await runner.describeTask('deploy');
+// {
+//   name: 'deploy', class_path: 'tasks.Deploy', description: 'Deploy the build',
+//   options: { replicas: 2 },               // schema defaults, then definition options
+//   options_schema: { environment: {...}, replicas: {...} },
+//   outputs: { url: {...} },
+// }
+```
 
 ### Available on `this`
 
@@ -87,6 +162,86 @@ The `${ns.path}` references in those configured defaults are interpolated for yo
 
 Calling a task requires a registry on the context, which `FlowRunner` supplies. A task constructed by hand without one throws.
 
+## Composite tasks
+
+A flow is a fixed sequence. When the children depend on the input (one child
+per item in a list, or pages until a cap), write a **composite**: a task that
+runs each child with `this.step()`. Unlike `this.call()`, a child step goes
+through the runner's bookkeeping, exactly like a flow step:
+
+- it is recorded under the parent, as `TaskResult.children` (a
+  `FlowStepResult[]` whose entries carry a `path` such as `2/1`), and is
+  therefore visible in the run result tree;
+- the runner's `beforeStep` / `afterStep` hooks fire for it, with that path;
+- the step retry policy applies (`{ retries, retryDelay, retryOn }` as the third
+  argument), as do option schemas and deprecation warnings;
+- its rollback record is harvested with the parent's: inside a flow with
+  `rollback_on_failure`, children unwind in reverse after the parent's own
+  record.
+
+```typescript
+class ImportBatch extends BaseTask<{ files: string[]; failFast?: boolean }> {
+  get taskName() { return 'import_batch'; }
+
+  async execute(): Promise<TaskResult> {
+    const results = [];
+    for (const file of this.options.files) {
+      const r = await this.step('asset.import', { file }, { retries: 2 });
+      results.push({ file, ok: r.success });
+      if (!r.success && this.options.failFast) {
+        return { success: false, error: r.error, data: { results, stoppedAt: file } };
+      }
+    }
+    return { success: true, data: { results } };
+  }
+}
+```
+
+`this.step(target, options?, spec?)` takes a configured task name, `{ task:
+name }` or `{ flow: name }`, and returns the child's `TaskResult`. It never
+throws for a failed child: the composite decides whether to go on. The
+`options` are the composite's runtime data. They are layered over the child
+task's configured defaults verbatim, not interpolated, and runtime `params` and
+enclosing-flow overrides do not reach children. For a flow child they are the
+flow's `params`.
+
+The runner supplies this for every task it runs, whether as a flow step, a hook,
+or on its own through `runner.runTask(name, options)`, so a composite behaves
+the same with or without an enclosing flow. Under `runTask`, the children are on
+the returned `TaskResult.children`, and `collectRollbackRecords(result)` returns
+every record in the tree (children first, invoke in reverse) for a host that
+does its own rollback. A task constructed by hand has no runner: a task child
+falls back to `this.call()` without bookkeeping, and a flow child fails.
+
+### `expand`: the child plan without running it
+
+A composite can declare a static `expand(options, ctx)` that returns the
+children it would run, as `{ task | flow, options? }` entries, without running
+anything. Return `null` when the children depend on runtime results (a pager
+cannot know how many pages there are):
+
+```typescript
+class ImportBatch extends BaseTask<{ files: string[] }> {
+  static expand(options: Record<string, unknown>): ChildPlanEntry[] | null {
+    const files = options.files;
+    return Array.isArray(files) ? files.map((file) => ({ task: 'asset.import', options: { file } })) : null;
+  }
+  // ...
+}
+```
+
+- `run({ plan: true, expandComposites: true })` follows each composite row with
+  its children, one level deeper and with paths (`1/1`, `1/2`), and marks the
+  row `composite: 'expanded'`. A composite whose `expand` returns `null` (or
+  throws) is marked `composite: 'opaque'`. Without `expandComposites` the plan is
+  unchanged. It composes with `expandNestedFlows`.
+- `runner.expandTask(name, options?)` returns the child plan for a `describe`
+  command, or `null`.
+- `expand` receives the options as far as they can be resolved before a run:
+  configured defaults, the step's options and its runtime params, with host
+  references interpolated and step references left as written. `ctx` carries
+  `taskName`, `taskDefinitions`, `flows` and `references`.
+
 ## The task lifecycle
 
 When `task.run()` is called (by the flow runner):

package/docs/releases.md

@@ -1,5 +1,52 @@
 # Release notes
 
+## 0.18.0
+
+Task and flow primitives for hosts that model every action as a task, a flow
+or a composite. Everything here is additive or opt-in: a config and a host
+that use none of it run exactly as before.
+
+- **`flow: None`** skips a step the way `task: None` does, so an overlay can
+  switch off an inherited step whichever key the base used.
+- **Shared step schema.** `FlowStepObjectSchema` (unrefined, extendable),
+  `refineFlowStep(schema)` and `FlowStepsSchema` let a host validate its own
+  manifests with the runner's step fields instead of a copy.
+- **Strict config (opt-in).** `loadConfig({ strict: true })` fails on keys the
+  schema does not declare, naming each by path with a did-you-mean;
+  `{ passthroughKeys }` exempts host top-level sections.
+  `findUnknownKeys` / `assertKnownKeys` / `UnknownConfigKeyError` run the same
+  check elsewhere.
+- **Option schemas.** Task classes declare `static optionsSchema` and
+  `static outputs`; a definition refines them with `options_schema` and
+  `outputs`. `FlowRunner` fills schema defaults and validates before
+  constructing the task, on every runner path, with a `TaskOptionsError` naming
+  the task and option (never retried). `registry.describe(name, defs)` and
+  `runner.describeTask(name)` fold class metadata with the definition.
+- **Deprecation.** `deprecated` / `replaced_by` on task and flow definitions,
+  `static deprecated` / `static replacedBy` on classes. Running or planning one
+  adds a structured `RunWarning` to the step, `TaskResult.warnings` and
+  `FlowRunResult.warnings`; `describeTask` and the new `describeFlow` expose it.
+- **Step-scoped runtime options (opt-in).** `options_scope: step` (flow),
+  `FlowRunnerConfig.optionsScope` or `run({ optionsScope })` make each `params`
+  key a selector (task name, or step path such as `2/1`) addressing only the
+  matching steps. Unknown selectors fail before anything runs. Default `flat`.
+- **Preflight checks.** Flows and steps declare
+  `checks: [{ when, action: error | warn | skip, message }]`, evaluated by the
+  `conditionEvaluator`, whose `ConditionContext` now also carries `references`,
+  `step`, `check` and `flowName`. The runner enforces them;
+  `runner.preflight(flowName, params)` reports every step's outcome without
+  running anything.
+- **Composites.** `ctx.step(target, options, spec)` / `BaseTask.step` run a
+  child task or flow through the runner: recorded on `TaskResult.children`,
+  step hooks, retries, option checks, deprecation and rollback capture, under a
+  flow or a bare `runTask`. An optional static `expand(options, ctx)` lists the
+  children for `run({ plan: true, expandComposites: true })` and
+  `runner.expandTask(name)`. `collectRollbackRecords(result)` walks the tree.
+- **Step references.** The identity rule and the most-recent-wins tie-break
+  are documented. `runner.checkStepReferences(flowName)` reports ambiguous,
+  unknown and forward `${steps.x}` references; `strictStepReferences: true`
+  refuses to run or plan such a flow (opt-in).
+
 ## 0.17.0
 
 `AgentTaskOptions` and `AgentPromptOptions` now accept an optional programmatic

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@db-lyon/flowkit",
-  "version": "0.17.2",
+  "version": "0.18.0",
   "description": "YAML-configured task and flow orchestration engine",
   "type": "module",
   "main": "dist/index.js",