tubeless 0.2.12 → 0.2.13

package/docs/comparison.md

@@ -54,3 +54,23 @@ one of those tools in either of two ways:
 The host owns persistence and acknowledgement. A rejected run tells it that
 processing failed. The parent Tubeless process does not restore itself after
 exit; if that is required, the host must provide it.
+
+The [Tubeless ↔ Airflow guide](./airflow.md) connects both patterns in one example:
+submit a DAG through `fromRemote`, run a Tubeless pipeline inside its task, and
+validate the returned XCom before continuing locally.
+
+The [Temporal guide](./temporal.md) hosts a pipeline inside an Activity and keeps
+its execution outside replayed Workflow code, with Activity-owned retries,
+heartbeats, and cancellation.
+
+The [Inngest guide](./inngest.md) hosts a pipeline inside `step.run`. Inngest
+saves the successful result and retries failed attempts; each attempt executes
+the whole Tubeless pipeline. The example includes an event sender and local server.
+
+The [Dagster guide](./dagster.md) materializes an asset through Dagster Pipes,
+with progress logs, content data versions, and a trace for Tubeless Studio.
+Dagster owns retries of the asset; Tubeless owns execution of its internal steps.
+
+The [Step Functions guide](./step-functions.md) invokes a pipeline inside a Lambda
+Task and includes a SAM deployment. Step Functions owns workflow recovery;
+Tubeless supplies typed steps and progress within each Lambda invocation.

package/docs/concepts.md

@@ -399,14 +399,15 @@ result.steps.find((step) => step.attemptId)?.attemptId;
 result.finishedAtMs - result.startedAtMs;
 ```
 
-Trace events use the version 2 discriminated payload model. Every event carries
+New trace events use the version 3 discriminated payload model. Every event carries
 a unique execution `runId` and keeps reusable external correlation separate.
 `tubeless/tracing` intentionally exposes only that typed event union, the exporter
 interface, and exporter composition. Concrete JSON and telemetry SDK adapters
 belong in the workbench or application integration; see the
 [tracing recipe](../examples/tracing.ts). This narrow API does not weaken the
 recording contract: existing version 2 NDJSON traces remain readable by
-`tubeless history` and `tubeless ui`.
+`tubeless history` and `tubeless ui`. Version 3 adds iteration relationships for
+repeated child runs; their execution IDs remain unique.
 
 ### Local event store and studio
 
@@ -624,6 +625,73 @@ interleave, or advance time differently; call `test.abort()` to exercise the
 normal cancellation path. Use your test framework to assert on the results. Replace external I/O yourself;
 the test runtime does not mock network or filesystem operations.
 
+### Supplying step outputs
+
+Use `overrideStep` from `tubeless/testing` to supply a typed intermediate value
+without modifying the pipeline definition:
+
+```ts
+const test = createPipelineTestRuntime();
+const run = await test.run(pipeline, options, {
+  stepIds: ["load", "summarize"],
+  overrides: [overrideStep(load, ["alice", "bob"])],
+});
+```
+
+Each override pairs an actual step reference with a resolved handler output.
+For schema-backed steps, supply the **schema input** type: `outputSchema` still
+validates and transforms it, and dependents receive the transformed output.
+Invalid values fail with `TUBELESS_STEP_OUTPUT_VALIDATION_FAILED`. An explicit
+`undefined` is a published value when the step's type and schema allow it.
+Functions can be domain values; they are never called as lazy factories.
+Await asynchronous fixture setup before constructing overrides.
+
+A selected overridden step never calls its `run`, `skip`, or custom `dryRun`
+handler. It bypasses required-input and failure-gate checks and `dryRun: "skip"`,
+since the supplied value replaces its entire computation. Overriding a child,
+fan-out, or remote wrapper also bypasses item enumeration, mappings, adapter
+calls, and child launches. Overrides belong to this run only and do not flow
+into children. Duplicate overrides and foreign references (including same-named
+steps from another graph) reject before execution. Custom pipeline wrappers
+are unsupported; use the object returned by `definePipeline`.
+
+Selection and scheduling remain explicit:
+
+- Overrides do not select steps, prune ancestors, or change target closure.
+  A filtered step stays filtered and does not validate or publish its override.
+  To isolate a downstream branch, use exact `stepIds` including the supplied
+  intermediate and its dependents, excluding upstream I/O. Plans describe the
+  ordinary graph and do not apply overrides.
+- Scheduling still waits for all prerequisite steps to reach terminal states.
+  Override validation occupies a concurrency slot. Fail-fast can prevent an
+  override from starting; `continueOnError` allows it to publish after upstream
+  failure, while the run retains that failure.
+- Cancellation prevents unstarted overrides and is checked again after async
+  output validation. Successfully overridden steps unlock required dependents
+  and failure gates and supply optional inputs normally.
+- Finalization and `resultSchema` use the supplied outputs through the usual
+  boundaries, including required finalizers and the default last-step result.
+
+An override uses the normal lifecycle: `running`, then `completed`, `failed`,
+or `cancelled`. From the start of its validation attempt, reports and hooks
+carry `outputSource: "override"`. The same metadata survives validation failure
+or cancellation. Successful overrides emit `onStepComplete`, so tests exercise
+the same completion callbacks and dependency rules as handler-produced outputs.
+There is no separate override status or hook.
+
+Traces use the existing `step.running`, `step.complete`, `step.failed`, and
+`step.cancelled` events with `payload.outputSource: "override"`; they do not
+record the supplied value. Both CLI reporters and Studio show the ordinary
+status with an override annotation, such as **completed (overridden)** or
+**failed (overridden)**. Existing recordings remain readable. Ordinary runs omit
+this metadata, as do filtered overrides and overrides cancelled before their
+validation attempt starts; absence does not prove a handler ran.
+
+Overrides are available only through the test runtime's `run` and `runOrThrow`.
+Ordinary pipeline controls, CLI flags, and Studio launch forms do not expose
+them, and trace recordings cannot automatically be replayed as override values.
+See the [executable override recipe](../examples/step-output-overrides.ts).
+
 ## Implementation guidelines
 
 - Keep step IDs stable, use `name` only for a friendlier display label, and keep

package/docs/dagster.md

@@ -0,0 +1,161 @@
+# Tubeless on Dagster
+
+Run a Tubeless pipeline as a Dagster asset using Dagster Pipes. Dagster owns
+asset scheduling, dependencies, and retries; Tubeless owns the typed steps,
+progress, and execution trace inside the asset's subprocess.
+
+```text
+Dagster asset → PipesSubprocessClient → Node.js → Tubeless pipeline
+                     ← logs, traces, and materialization metadata ←
+```
+
+The example normalizes rows, validates the dataset, and writes a JSON artifact.
+After successful execution, it reports a materialization with the row count,
+artifact path, content data version, Tubeless run ID, and trace path. Operators
+can follow progress in Dagster and inspect individual pipeline steps in Tubeless
+Studio. See Dagster's [TypeScript Pipes integration](https://docs.dagster.io/integrations/libraries/typescript).
+
+## The example
+
+| File                                                             | Responsibility                                                            |
+| ---------------------------------------------------------------- | ------------------------------------------------------------------------- |
+| [`pipeline.ts`](../examples/dagster/pipeline.ts)                 | Normalize, validate, and publish through public Tubeless imports          |
+| [`hosted.ts`](../examples/dagster/hosted.ts)                     | Bridge Pipes context, logs, traces, and materialization reporting         |
+| [`worker.ts`](../examples/dagster/worker.ts)                     | Open and close Pipes, forward process termination to Tubeless             |
+| [`definitions.py`](../examples/dagster/definitions.py)           | Define the asset, launch Node, save the trace, and yield materializations |
+| [`test_definitions.py`](../examples/dagster/test_definitions.py) | Exercise the real Python host and Node worker                             |
+
+The pipeline has no Dagster imports and also runs from the local project.
+The bridge uses `@dagster-io/dagster-pipes` 0.1.0, installed as a repository
+development dependency. Applications adopting this bridge install the SDK in
+their own project. Tubeless itself retains a dependency-free runtime.
+The Python example is tested with Dagster 1.13.24.
+
+## Run locally
+
+Use Node.js 22.6 or later, Bun, Python 3.12, and
+[uv](https://docs.astral.sh/uv/getting-started/installation/). From the repository root:
+
+```sh
+bun ci
+bun run build
+bunx tsc -p examples/dagster/tsconfig.build.json
+uv venv --python 3.12 .context/dagster-venv
+uv pip install --python .context/dagster-venv/bin/python \
+  'dagster==1.13.24' 'dagster-webserver==1.13.24'
+.context/dagster-venv/bin/dagster dev -f examples/dagster/definitions.py
+```
+
+The compiler writes JavaScript to `.context/dagster/`. Open the local Dagster
+UI at `http://localhost:3000`, select `normalized_rows`, and materialize it.
+The execution host must have Node, the compiled worker, and its installed
+dependencies available. Keep the dev server's process running while you inspect
+the asset and run history.
+
+The default input produces `{"rows":["alpha","beta"]}` in
+`.context/dagster-artifacts/<dagster-run-id>/rows.json`. Open the materialization's
+metadata to find the artifact, row count, data version, and Tubeless trace.
+These paths refer to the execution host's filesystem. For distributed workers,
+publish artifacts and traces to shared storage and report accessible locations.
+
+To change the input, open the asset's launch configuration and supply:
+
+```yaml
+ops:
+  normalized_rows:
+    config:
+      lines: [" Alpha ", "Beta", "ALPHA"]
+```
+
+Use the local Tubeless command below for previews. The Dagster asset always
+publishes: Pipes requires asset outputs even when an asset declares its output
+optional. The host disables implicit materializations and requires exactly one
+explicit materialization from the worker, so a missing report fails the attempt.
+The worker rejects `dryRun: true` instead of accidentally publishing a preview.
+
+## Logs, traces, and asset identity
+
+The bridge forwards pipeline logs and progress counts through the Pipes logger.
+It sends raw Tubeless trace events as Pipes custom messages. After a successful
+subprocess exit, the Python host writes these events to `trace.ndjson`.
+The sample does not retain a separate trace file for failed or
+killed subprocesses; their Pipes logs remain in Dagster. For large or long-running
+jobs, stream traces to your own durable exporter rather than accumulating custom
+messages in the host.
+
+Copy the recorded trace path into these commands to inspect a finished run:
+
+```sh
+bun run tubeless -- history --trace .context/dagster-artifacts/<dagster-run-id>/trace.ndjson
+bun run tubeless -- ui --trace .context/dagster-artifacts/<dagster-run-id>/trace.ndjson
+```
+
+Replace `<dagster-run-id>` with the actual ID before running the commands.
+Trace files contain recorded logs and event payloads; apply your application's
+redaction policy at the exporter.
+
+Each Tubeless attempt has a fresh `runId`. Its correlation ID combines the
+Dagster run ID and asset key and stays stable across step retries within that
+run. The optional `parentRunId` in the bridge is reserved for a known Tubeless
+execution; a Dagster run ID is a separate identity.
+
+The materialization's `dataVersion` hashes the normalized row array, so repeated
+attempts with the same rows have the same version. It describes logical content,
+not the file's formatting or the implementation release. Tubeless's
+`implementationVersion` separately identifies the example's handler release.
+This recipe handles one selected asset per invocation.
+
+## Retries and cancellation
+
+Dagster retries the asset at most twice after its initial attempt. An exception
+from `runOrThrow` causes a nonzero worker exit, which fails the asset attempt.
+Validation failure prevents publication and materialization. Successful
+publication is reported only after the pipeline finishes.
+
+A retry runs the whole Tubeless pipeline again. The example replaces the same
+run-specific JSON dataset; a new Dagster run gets a separate directory. This
+does not make arbitrary side effects exactly-once. If publication succeeds and
+reporting fails, Dagster may retry. Use idempotent writes or business-level keys
+when adapting the pipeline to external services. Split independently retryable
+datasets into separate Dagster assets when you need recovery at those boundaries.
+
+The default `PipesSubprocessClient` forwards host termination to its subprocess.
+The worker turns `SIGTERM` and `SIGINT` into an abort signal and closes Pipes
+when execution settles. Normalization cooperates through `context.sleep`.
+Cancellation does not roll back an artifact already written, and blocking I/O
+can delay it; Dagster may forcibly stop a subprocess that exceeds its termination
+timeout. See [Dagster Pipes](https://docs.dagster.io/integrations/external-pipelines/using-dagster-pipes)
+for other execution environments.
+
+## Run the pipeline directly
+
+Use the same pipeline through the example project for local iteration:
+
+```sh
+bun run tubeless -- plan --project examples/project/tubeless.project.ts dagster-dataset
+bun run tubeless -- run --project examples/project/tubeless.project.ts dagster-dataset -- \
+  --lines " Alpha " --lines "Beta" --output-path ./rows.json --dry-run
+```
+
+Local execution writes no Dagster metadata. Relative output paths resolve from
+the project execution directory. The Pipes worker requires a real Pipes context
+and rejects standalone launches without one.
+
+## Verification
+
+`make check` compiles the TypeScript examples and tests the real Pipes SDK in
+subprocesses without a Dagster service. Tests cover metadata and content versions,
+retry identity, raw traces, malformed inputs, validation failure, dry runs, and
+cooperative termination.
+
+After the local setup and worker compilation, run the Python integration tests:
+
+```sh
+.context/dagster-venv/bin/python -m unittest discover -s examples/dagster -p 'test_*.py'
+```
+
+These launch the compiled Node worker from the real Dagster execution engine.
+They verify a successful materialization and trace, and a failed dataset that
+exhausts Dagster's retry policy without materializing an asset.
+The Python tests are optional and are not part of the dependency-free package's
+`make check` environment.

package/docs/inngest.md

@@ -0,0 +1,163 @@
+# Tubeless on Inngest
+
+Run a Tubeless pipeline inside an Inngest `step.run`. Inngest owns event delivery,
+retries, and durable step results; Tubeless owns the typed graph, progress, and
+execution report within each attempt.
+
+```text
+Event sender → Inngest function → step.run → Tubeless pipeline
+```
+
+Keep the pipeline invocation inside the durable step callback. Inngest may
+execute the function handler several times as it restores saved step results.
+Code outside steps can execute again. See
+[how Inngest functions execute](https://www.inngest.com/docs/learn/how-functions-are-executed).
+
+## The example
+
+| File                                               | Responsibility                                                                  |
+| -------------------------------------------------- | ------------------------------------------------------------------------------- |
+| [`pipeline.ts`](../examples/inngest/pipeline.ts)   | Normalize and deduplicate rows using public Tubeless imports                    |
+| [`functions.ts`](../examples/inngest/functions.ts) | Validate event data and run the pipeline in a durable step with correlated logs |
+| [`client.ts`](../examples/inngest/client.ts)       | Configure the shared Inngest client                                             |
+| [`server.ts`](../examples/inngest/server.ts)       | Serve the function at `/api/inngest` using Node's HTTP server                   |
+| [`send.ts`](../examples/inngest/send.ts)           | Send a sample event and print its accepted event IDs                            |
+
+The pipeline has no Inngest imports and also runs locally. The example uses
+Inngest TypeScript SDK 4.21.0 and `@inngest/test` 1.0.0, installed as development
+dependencies here. Consumer applications install `inngest` themselves. Tubeless
+keeps its dependency-free runtime and adds no Inngest public API.
+
+SDK v4 puts `triggers` in the `createFunction` options. Older v3 examples use a
+separate trigger argument; see the
+[v4 migration guide](https://www.inngest.com/docs/reference/typescript/v4/migrations/v3-to-v4).
+
+## Run locally
+
+Use Node.js 22.6 or later and Bun 1.3.14 or later. From the repository root:
+
+```sh
+bun ci
+bun run build
+bunx tsc -p examples/inngest/tsconfig.build.json
+INNGEST_DEV=1 node .context/inngest/server.js
+```
+
+The compiler writes JavaScript to `.context/inngest/`. The server listens on
+`127.0.0.1:3000`. In a second terminal, start the
+[Inngest Dev Server](https://www.inngest.com/docs/local-development):
+
+```sh
+npx inngest-cli@latest dev -u http://127.0.0.1:3000/api/inngest
+```
+
+Open `http://localhost:8288` and confirm that `tubeless-example` has synced and
+lists `normalize-rows`. In a third terminal, send the sample event:
+
+```sh
+INNGEST_DEV=1 node .context/inngest/send.js
+```
+
+The sender prints accepted event IDs. It does not wait for the pipeline result.
+Open the resulting run in the Dev Server UI: `run-pipeline` returns
+`rows: ["alpha", "beta"]`, `count: 2`, a Tubeless `runId`, and `preview: false`.
+Sending again creates another event and function run. This example does not
+deduplicate separate submissions.
+
+`INNGEST_DEV=1` selects local development for both server and sender. For a
+deployment, host the endpoint where Inngest can reach it, remove that setting,
+configure `INNGEST_SIGNING_KEY` and `INNGEST_EVENT_KEY` through your host's secret
+configuration, and sync the app. The example server always binds to
+`127.0.0.1:3000`. To reuse it in production, run a reverse proxy on the same host
+and forward your public HTTPS `/api/inngest` endpoint to
+`http://127.0.0.1:3000/api/inngest`, preserving the request method, body, and
+headers. Sync the public URL with Inngest. If your deployment cannot proxy to
+that loopback listener, register `normalizeFunction` using your application's
+Inngest framework adapter instead of running `server.ts`.
+See [serving functions](https://www.inngest.com/docs/reference/typescript/serve)
+and [client configuration](https://www.inngest.com/docs/reference/typescript/client/create).
+
+## Validation, results, and observation
+
+The function validates `event.data` before calling `runOrThrow`. Invalid rows or
+control metadata throw Inngest's `NonRetriableError` directly. A TypeScript type
+on the sender cannot validate incoming events. Keep this validation outside the
+Tubeless invocation so its execution-error wrapper cannot hide the host's
+non-retryable error type. See
+[Inngest errors](https://www.inngest.com/docs/reference/typescript/errors).
+
+The correlation ID combines the Inngest run ID and durable step ID. It stays
+stable across retries of that step. Each pipeline attempt gets a fresh Tubeless
+`runId`. Only pass `parentRunId` when it identifies a known Tubeless execution;
+an Inngest run ID belongs in correlation metadata.
+
+The pipeline returns plain JSON data. Inngest serializes step results, so avoid
+returning contexts, errors, signals, class instances, or a whole execution report.
+Large datasets should live in external storage with a small reference returned
+from the step. See [step result serialization](https://www.inngest.com/docs/reference/typescript/functions/step-run).
+
+Pipeline logs, progress hooks, and trace events go through the function logger.
+The Inngest UI records one durable step for the pipeline. To inspect individual
+Tubeless steps in Studio, retain raw trace events using an application-owned
+exporter. Logger envelopes are not importable Tubeless NDJSON traces. Apply
+redaction before retaining or forwarding events.
+
+## Retries and durable boundaries
+
+The function sets `retries: 2`: up to three attempts for the durable step.
+`runOrThrow` lets execution failures reach Inngest. A failed attempt reruns the
+entire pipeline, including any successful internal steps. Once Inngest saves
+the durable step's successful result, subsequent handler executions reuse that
+result, including the original Tubeless `runId`, without invoking the pipeline.
+
+Normalization and deduplication are safe to repeat. If you add writes, use
+business-level idempotency keys: a process can fail after a write but before its
+result is saved. Correlation IDs do not deduplicate side effects. See
+[Inngest steps](https://www.inngest.com/docs/learn/inngest-steps).
+
+For independently retryable phases, define multiple Inngest steps at the
+function level, each calling a smaller Tubeless pipeline and passing JSON
+results to the next phase. Do not call Inngest step tools from inside Tubeless
+handlers or hooks nested in `step.run`. Place durable sleeps and event waits
+between these phases. Tubeless `context.sleep` is an ordinary process-local
+wait, and internal progress is not a durable checkpoint.
+
+## Cancellation and dry runs
+
+Inngest cancellation prevents subsequent steps from running; it does not stop
+an already executing step. This adapter therefore does not supply a host
+cancellation signal. Cancelling a run in the dashboard can leave its active
+Tubeless pipeline running to completion. Closing the sender does not cancel
+the function. See [Inngest cancellation](https://www.inngest.com/docs/features/inngest-functions/cancellation).
+
+The pipeline cooperates with signals supplied by local callers. Applications
+that need an execution deadline can supply their own signal and forward it to
+I/O, but a local abort is separate from Inngest cancellation. Keep work within
+the execution limits of your deployment and make side effects safe to retry.
+
+Set `dryRun: true` in the sender's job to forward Tubeless dry-run controls.
+This still sends a real event and runs an Inngest function. The example performs
+only pure transformations. Mark any added writes with `dryRun: "skip"` or a
+side-effect-free preview handler.
+
+To plan or preview without contacting Inngest, use the project registration:
+
+```sh
+bun run tubeless -- plan --project examples/project/tubeless.project.ts inngest-normalize
+bun run tubeless -- run --project examples/project/tubeless.project.ts inngest-normalize -- \
+  --lines " Alpha " --lines "Beta" --dry-run
+```
+
+## Verification
+
+`make check` compiles the examples against the real SDK and uses
+[`InngestTestEngine`](https://www.inngest.com/docs/reference/typescript/v4/testing)
+to exercise the durable step with the real Tubeless pipeline. Tests cover JSON
+results, progress and traces, invalid input, dry runs, and mocked durable step
+output. The mocked-output test checks that the function returns the supplied
+value without calling the pipeline; it does not test persisted-state recovery.
+A separate test substitutes a real two-step Tubeless pipeline with fake storage
+I/O: its save handler fails once, then a fresh attempt reruns both load and save
+with stable correlation. These tests need no service or credentials and do not
+test server-side persistence or retry scheduling. Use the local server flow above
+to verify event delivery and inspect the run; test deployment authentication and side-effect idempotency separately.

package/docs/llms.txt

@@ -12,6 +12,7 @@ Start:
 - First pipeline: ./getting-started.md
 - CLI: ./cli.md
 - Local studio: ./studio.md
+- Artifacts and lineage: ./artifacts.md
 - YAML and JSON pipelines: ./declarative-pipelines.md
 - Pipeline document JSON Schema v1: ./pipeline-document.schema.json
 - Choose a pattern: ./recipes.md
@@ -26,6 +27,7 @@ Agent instructions:
 - Minimal project: ../examples/tubeless.project.ts
 - Project with custom adapters: ../examples/project/tubeless.project.ts
 - Maintain stable step IDs.
+- For static parameterized step families, keep expansion synchronous and preserve literal IDs with the recipe-local tuple helper in ../examples/parameterized-steps.ts
 - Use optional step names only as display overrides; dependencies and selection use IDs.
 - Use pipeline.toMermaid() to generate static graph documentation.
 - Use tubeless list to enumerate pipelines from defineProject. Use stable pipeline IDs with inspect, plan, graph, and run; no command modules are discovered from the filesystem or history.
@@ -36,7 +38,7 @@ Agent instructions:
 - Use tubeless history to list or show recorded runs from SQLite, or pass --trace to inspect a finished NDJSON artifact without importing it. Studio also accepts --trace as a strictly read-only source. Default print is the projection; --events emits raw NDJSON. Trace files may contain sensitive logs and event payloads.
 - Set dryRun: "skip" on external side effects, or provide a side-effect-free dryRun handler.
 - Use context.log, context.signal, context.sleep, and progress APIs.
-- Use createPipelineTestRuntime from tubeless/testing for deterministic tests with captured logs, statuses, progress, clock, and cancellation.
+- Use createPipelineTestRuntime from tubeless/testing for deterministic tests with captured logs, statuses, progress, clock, and cancellation. Pass overrideStep(step, value) through test-run overrides to supply typed outputs; output schemas still validate and normal step statuses carry outputSource: "override" provenance.
 - Import compilePipelineDocument from tubeless/project to compile parsed YAML/JSON with an explicit registry; use compiled.get(id) directly or pass selected pipelines to defineProject. Reuse compiled.metadata for project presentation. Import definePipelineCommand from tubeless/cli for explicit adapters; register each pipeline exactly once, directly or through its command in the same project entry list for CLI and Studio.
 - Omit mapOptions only when validated CLI flags already satisfy same-name pipeline options; map renamed, loaded, or derived values explicitly. --step and --target are argv flags; mapOptions and hooks receive stepIds and targets.
 - Expose --resume only through managed checkpoint configuration or an explicit resume: true command that handles values.resume. Unsupported commands reject it and omit it from Studio.
@@ -58,6 +60,11 @@ Advanced:
 
 - Child pipelines: ./child-pipeline-composition.md
 - Remote steps: ./remote-step-composition.md
+- Tubeless and Airflow: ./airflow.md
+- Tubeless on Temporal: ./temporal.md
+- Tubeless on Inngest: ./inngest.md
+- Tubeless on Dagster: ./dagster.md
+- Tubeless on AWS Step Functions: ./step-functions.md
 - Public exports: ./api-reference.md
 - Machine-readable surface: ./api-report.json
 Executable examples:
@@ -74,10 +81,32 @@ Executable examples:
 - ../examples/best-effort.ts
 - ../examples/child-pipeline.ts
 - ../examples/remote-steps.ts
+- ../examples/airflow/remote.ts
+- ../examples/airflow/hosted.ts
+- ../examples/airflow/tubeless_example.py
+- ../examples/inngest/pipeline.ts
+- ../examples/inngest/functions.ts
+- ../examples/inngest/client.ts
+- ../examples/inngest/server.ts
+- ../examples/inngest/send.ts
+- ../examples/temporal/pipeline.ts
+- ../examples/temporal/activities.ts
+- ../examples/temporal/workflows.ts
+- ../examples/temporal/worker.ts
+- ../examples/temporal/client.ts
+- ../examples/dagster/pipeline.ts
+- ../examples/dagster/hosted.ts
+- ../examples/dagster/worker.ts
+- ../examples/dagster/definitions.py
+- ../examples/step-functions/pipeline.ts
+- ../examples/step-functions/handler.ts
+- ../examples/step-functions/state-machine.asl.json
+- ../examples/step-functions/template.json
 - ../examples/fan-out-progress.ts
 - ../examples/resumable-enrichment.ts
 - ../examples/cli-job.ts
 - ../examples/cancellation-and-testing.ts
+- ../examples/step-output-overrides.ts
 - ../examples/live-tui.ts
 - ../examples/peloton.ts
 - ../examples/tracing.ts