@pipelex/sdk 0.47.0 → 0.48.0

package/dist/models.d.ts

@@ -8,8 +8,8 @@
  * the model reference check. Built on the protocol wire types imported from the
  * `mthds/protocol` subpath.
  */
-import type { InputForm, OutputForm, PipeIOContracts, RunResultExecute, RunResultStart } from "mthds/protocol";
-import type { BundleResources } from "./bundle-resources.js";
+import type { InputForm, MethodFiles, MethodTreeSource, OutputForm, PipeIOContracts, RunResultExecute, RunResultStart } from "mthds/protocol";
+import type { MethodTreeForm, NoMethodTree } from "./method-trees.js";
 export interface DictStuff {
     concept: string;
     content: unknown;
@@ -75,7 +75,7 @@ export interface PipelexRunResultStart extends RunResultStart {
  * The hosted tooling routes' own selector — the layer-3 extension the platform
  * adds on `POST /v1/validate`, `/v1/resolve`, `/v1/codegen`, and `/v1/pipe-io`: a stored
  * method's catalog id (`mt_…`), optionally naming a version, resolved server-side against
- * the org's catalog, the `.mthds` files of the version it names injected as inline source
+ * the org's catalog, the tree of the version it names injected as the method's `files`
  * before the runner sees the request. A bare `mt_…` names the latest published version,
  * `mt_…@<n>` version `n` and `mt_…@draft` the draft. A **pass-through to the hosted API**:
  * nothing is expanded client-side, and it is meaningless off-platform (a bare runner
@@ -97,11 +97,11 @@ export interface PipelexHostedToolingExtensions {
     method_id?: string;
 }
 /**
- * The method selector the tooling routes take in place of inline contents: a
+ * The method selector the tooling routes take in place of the method's tree: a
  * `method_ref` address (server-resolved by the runner through the same fetch
  * path as a `method_ref` run) OR a hosted `method_id` (platform-resolved) —
  * never both. The tooling routes are stateless, so the strict XOR applies:
- * exactly one of inline contents / `method_ref` / `method_id` per request.
+ * exactly one of the tree / `method_ref` / `method_id` per request.
  *
  * Lives here, beside the other wire shapes, rather than on the client: it is
  * the request's shape, and a module that composes a `validate` call of its own
@@ -115,6 +115,23 @@ export type ValidateMethodSelector = {
     method_id: string;
     method_ref?: never;
 };
+/**
+ * What `validate()` judges: the method's tree, in exactly one of the four forms of
+ * `MethodTreeForm` (a `directory`, `contents`, a `tree` or the `files` map), or one of the two
+ * selectors of `ValidateMethodSelector`. Each arm pins the others to `never`, so naming two is a
+ * compile error; an untyped caller naming none, or more than one, is refused with a
+ * `RequestArgumentError` before any request, as the route itself would refuse a second selector
+ * with a `422`. At run time a `null` member, an empty `directory` and an empty selector string
+ * are absent, and a `files` map or `contents` holding no file is refused, as the MTHDS standard
+ * refuses a tree holding no file.
+ *
+ * It widens the protocol's own `ValidateSource` (`{ files }` or `{ tree }`) with the two forms
+ * this client lists or encodes itself and the two selectors the Pipelex API resolves.
+ */
+export type PipelexValidateSource = (MethodTreeForm & {
+    method_ref?: never;
+    method_id?: never;
+}) | (ValidateMethodSelector & NoMethodTree);
 /** Per-pipe dry-run verdict in `validated_pipes[]` — mirror of pipelex's `DryRunStatus`. */
 export type DryRunStatus = "SUCCESS" | "FAILURE" | "SKIPPED";
 /** One entry of `PipelexValidationReport.validated_pipes` — `{pipe_ref, status}`. */
@@ -139,6 +156,35 @@ export interface LiftablePipeEntry {
     /** Where the possible absence originates (human-readable). */
     absence_source: string;
 }
+/**
+ * What a step reads a file of its method tree as — mirror of pipelex's `TreeFileUse`:
+ * `template`, the template a `PipeDocGen` step fills, named by its `template_file`;
+ * `template_asset`, an image, a stylesheet or a font that step's HTML template names by a
+ * literal relative URL, or that one of its stylesheets names; `python_module`, the module
+ * defining the function a `PipeFunc` step calls, named by the import path of its
+ * `function_name`.
+ *
+ * A report reads it open (see {@link TreeFileRead.use}): a runner of a later version may add
+ * a use as another kind of step comes to read files of its tree.
+ */
+export type TreeFileUse = "template" | "template_asset" | "python_module";
+/**
+ * One file of its method tree a step reads — mirror of pipelex's `TreeFileRead`, an entry of
+ * {@link PipelexValidationReport.tree_files_read}.
+ */
+export interface TreeFileRead {
+    /**
+     * The file's path from the root of the method's tree, with forward slashes, such as
+     * `templates/invoice.html`, never a path on the server.
+     */
+    tree_path: string;
+    /**
+     * What the step reads the file as. Read open: `string & {}` keeps the editor's completion
+     * on the uses this SDK knows, and a consumer that switches on this field has to say what a
+     * use it does not know does.
+     */
+    use: TreeFileUse | (string & {});
+}
 /**
  * Pipelex's `POST /v1/validate` 200 body for a VALID bundle — the canonical
  * `PipelexValidationReport`, carrying the `is_valid: true` discriminant of the
@@ -209,6 +255,27 @@ export interface PipelexValidationReport {
     output_form?: OutputForm;
     /** Pipes the runtime may skip when an optional slot resolves absent. */
     liftable_pipes: LiftablePipeEntry[];
+    /**
+     * Per step, the files of the method's tree it reads, keyed by namespaced `pipe_ref` over
+     * the same set as `pipe_io_contracts`, each file by its tree path with what the step reads
+     * it as. A `PipeDocGen` step reads its template and the images, stylesheets and fonts its
+     * HTML template names by literal relative URLs; a `PipeFunc` step reads the module of its
+     * function when that module is a file of the tree. A step that reads no file of the tree,
+     * a controller included, has an empty list. The paths come from what each step already
+     * names, so a client can show which step uses a file without parsing the method.
+     *
+     * OPTIONAL because a runner predating the field sends nothing: an absent field says the
+     * server did not report the reads, where an empty list says that step reads no file.
+     */
+    tree_files_read?: Record<string, TreeFileRead[]>;
+    /**
+     * The per-file view of `tree_files_read`: each tree path a step reads, in sorted order, to
+     * the namespaced refs of the steps that read it, each listed once. A file of the tree with
+     * no entry is read by no step: the bundles themselves, a README, a package's `__init__.py`
+     * beside its modules. Optional for the same reason as `tree_files_read`, and present
+     * whenever it is.
+     */
+    tree_file_readers?: Record<string, string[]>;
     /**
      * The qualified ref of the pipe a selector-less run of THIS request would execute —
      * the primary blueprint's declared `main_pipe` qualified by its domain and, for a
@@ -326,9 +393,8 @@ export type ValidationErrorCategory = "blueprint_validation" | "pipe_factory" |
  * not, so the same item arrives with explicit `null`s there. A truthiness check reads
  * both; an `=== undefined` check would be wrong on one of them.
  *
- * `source` is the declaring file path (CLI) or the per-content `mthds_sources` name
- * the API threads onto the in-memory load path — the owning file for cross-file
- * diagnostics.
+ * `source` is the declaring file: its path (CLI), or its tree path in the tree the
+ * request sent — the owning file for cross-file diagnostics.
  *
  * An `unknown_model` item (a model reference the runner's model deck does not know)
  * carries the reference as written, the kind of model the field takes and the close
@@ -514,50 +580,84 @@ export interface FormatResponse {
     diagnostics: Diagnostic[];
 }
 /**
- * One MTHDS file in a crate closure. `source` is an optional provenance label (a
- * filename, a URI) that the server threads onto every diagnostic it raises from
- * this file, so an invalid verdict can point at the file that caused it.
+ * The method every crate route takes — `/v1/resolve`, `/v1/codegen` and `/v1/pipe-io`
+ * (mirror of the runner's `MethodTreeRequest`).
  *
- * NOT the same type as `MthdsFile` (the one `validateFiles()` takes), which the
- * client adapts into `/v1/validate`'s parallel `mthds_contents` + `mthds_sources`
- * arrays: that route spells the label `uri`, this envelope spells it `source`. The
- * two collapse into one only if `/v1/validate` ever migrates onto `files[]` — a
- * protocol-level change owned by the MTHDS standard, not ours to make here.
- */
-export interface MthdsFileItem {
-    content: string;
-    source?: string;
-}
-/**
- * The closure selector every crate route shares — `/v1/resolve`, `/v1/codegen` and
- * `/v1/pipe-io` (mirror of the server's `MthdsFilesRequest`).
+ * Supply the method EITHER as its tree OR as a `method_ref` — never both, and never neither
+ * (both arms are a request-shape `422`); the hosted `method_id` joins them as a third form on
+ * each route's own request (see {@link PipelexHostedToolingExtensions}). The tree is the MTHDS
+ * protocol's map of file entries, keyed by tree path, given in exactly one of the four forms
+ * every route takes (`MethodTreeForms`):
  *
- * Supply the closure EITHER as inline `files` OR as a `method_ref` — never both, and
- * never neither (both arms are a request-shape `422`); the hosted `method_id` joins
- * them as a third form on each route's own request (see
- * {@link PipelexHostedToolingExtensions}). An **address-form** `method_ref`
- * (`github.com/<owner>/<repo>[/<selector>][@<tag>]`) is resolved by the server
- * (pipelex-api >= 0.21.0): the repository is fetched at the tag, the package is
- * located by manifest identity, and its `.mthds` files feed the closure with their
- * real relative paths as per-file sources. The **registry form** (any non-address
- * reference) stays reserved and answers `501` until a method registry exists.
+ * - `directory`, the method's directory on disk, listed by the `mthds` package's lister under
+ *   the standard's membership rule and the deployment's limits (Node only);
+ * - `contents`, each file's bytes or text by tree path;
+ * - `tree`, a `MethodTreeSource`, such as the `MethodTree` the `mthds` package's
+ *   `listMethodTree` returns;
+ * - `files`, the map itself, each value the file's text, `{ base64 }` or `{ sha256, size }` for
+ *   bytes the runner already holds, sent as given.
  *
- * The XOR is a server-side invariant, not a type-level one: expressing it as a union
- * here would make the common `{ files }` call site pick a branch for no gain, and the
- * server rejects the illegal shapes with a typed `ApiResponseError` either way.
+ * The client sends a `directory`, `contents` or `tree` inline when its inline map weighs 256 KiB
+ * or less and no more than the inline limit the API announces, or whatever its weight when the
+ * API keeps no blob store, and otherwise every file by hash, after uploading the files the API
+ * lacks, exactly as `createMethod` sends one (see `docs/method-trees.md`). Every `.mthds` file of
+ * the tree is one of the method's bundles, named by its tree path in diagnostics and in the
+ * crate's `source_map`, and every other file is one a step may read, such as a `PipeDocGen`
+ * template.
  *
- * `resources` accompanies inline `files`: the files the closure's steps read, such as a
- * `PipeDocGen` step's `template_file`, keyed by the path the step names, each as its bytes,
- * which the client encodes into the wire's base64 map before posting (see
- * `docs/bundle-resources.md`). It is the one member the client does not post verbatim. Beside
- * a `method_ref` it is the server's `422`, a published method's files being its package's
- * own; a step whose template file was not sent makes the closure invalid.
+ * An **address-form** `method_ref` (`github.com/<owner>/<repo>[/<selector>][@<tag>]`) is
+ * resolved by the server (pipelex-api >= 0.21.0): the package's whole tree is fetched at the tag
+ * and read as a tree sent in `files` is. The **registry form** (any non-address reference) stays
+ * reserved and answers `501` until a method registry exists.
+ *
+ * The XOR is a server-side invariant, not a type-level one: expressing it as a union here would
+ * make the common `{ files }` call site pick a branch for no gain, and the server rejects the
+ * illegal shapes with a typed `ApiResponseError` either way. Two forms of the tree at once are
+ * the one shape the client refuses itself, with a `RequestArgumentError`, since it prepares the
+ * tree before posting. An empty map or string is absent, as in the Python SDK: `files: {}`,
+ * `files: null`, `contents: {}`, `directory: ""` and `dependencies: {}` select and send nothing,
+ * so an empty one beside another selector never reaches the wire as a second selector.
+ *
+ * `dependencies` accompanies the tree: the method packages it calls by address that the runner
+ * cannot fetch, each a map of file entries keyed by its address, sent as given. These routes load
+ * a package the method calls only from what was shipped with it, so a call into one nothing
+ * shipped is the invalid verdict.
+ *
+ * The files the closure's steps read, such as a `PipeDocGen` step's `template_file`, are files of
+ * the tree like any other, so a directory sends them with its bundles.
+ *
+ * `read_scope` is the Pipelex API's scope the request reads the method under: a hash entry of
+ * `files` resolves in that scope's blob store, else in the caller's own. A tree sent by hash asks
+ * `POST /v1/blobs/missing` under the same scope, so its blobs are uploaded into the store the
+ * request reads. **The hosted platform ignores it**: it stamps the caller's organization as the
+ * read scope of every crate request and drops the one the caller sent, so it only reaches a
+ * runner called directly.
  */
 export interface CrateRequestBase {
-    files?: MthdsFileItem[];
+    /** The method's directory, listed by the standard's lister and sent as `tree` is. Node only. */
+    directory?: string | null;
+    /** The method's files, each one's bytes or text by tree path, sent as `tree` is. */
+    contents?: Readonly<Record<string, Uint8Array | string>> | null;
+    /** The method's tree as a listed source, sent inline when small and by hash otherwise. */
+    tree?: MethodTreeSource | null;
+    /** The method's tree as the protocol's map of file entries, sent as given. */
+    files?: MethodFiles | null;
+    /** The method packages the tree calls by address, each a map of file entries keyed by its address. */
+    dependencies?: Record<string, MethodFiles>;
     method_ref?: string;
-    /** The files the closure's steps read, keyed by the path a step names, each as its bytes. */
-    resources?: BundleResources | null;
+    /** The scope the runner reads the tree under; the hosted platform replaces it with the caller's organization. */
+    read_scope?: string;
+}
+/**
+ * What a crate route call — `resolve`, `codegen`, `pipeIo` — takes beside its request.
+ *
+ * `signal` is read between the steps a `tree` or `contents` costs before the request, and before
+ * the request itself: once it has aborted, no further file of the tree is read, neither the blob
+ * route nor an upload starts, and the route is not asked, and the call throws the abort. A request
+ * already sent runs to its end, as in `prepareInputs`, which passes its own `signal` here.
+ */
+export interface CrateRouteOptions {
+    signal?: AbortSignal;
 }
 /**
  * The `is_valid: false` arm shared by every crate route — `/v1/resolve`,
@@ -578,7 +678,7 @@ export interface CrateInvalidReport {
 }
 /**
  * `POST /v1/resolve` request — the crate envelope (no projection axes) plus the
- * hosted `method_id` selector. Exactly one of `files` / `method_ref` /
+ * hosted `method_id` selector. Exactly one of the tree / `method_ref` /
  * `method_id` — the strict tooling XOR; see {@link PipelexHostedToolingExtensions}.
  */
 export type ResolveRequest = CrateRequestBase & PipelexHostedToolingExtensions;
@@ -626,7 +726,7 @@ export type CodegenKind = "types";
 export type CodegenTarget = "ts-zod" | "python-pydantic" | "python-structures";
 /**
  * `POST /v1/codegen` request — the crate envelope plus the two explicit projection
- * axes and the hosted `method_id` selector (exactly one of `files` / `method_ref` /
+ * axes and the hosted `method_id` selector (exactly one of the tree / `method_ref` /
  * `method_id`; see {@link PipelexHostedToolingExtensions}).
  */
 export interface CodegenRequest extends CrateRequestBase, PipelexHostedToolingExtensions {
@@ -677,7 +777,7 @@ export interface CodegenValidReport {
 export type CodegenResponse = CodegenValidReport | CrateInvalidReport;
 /**
  * `POST /v1/pipe-io` request — the crate envelope plus the hosted `method_id` selector
- * (exactly one of `files` / `method_ref` / `method_id`; see
+ * (exactly one of the tree / `method_ref` / `method_id`; see
  * {@link PipelexHostedToolingExtensions}), a pipe selector, and two opt-ins.
  *
  * There is no `views` field: the valid arm always carries all three artifacts.
@@ -685,8 +785,9 @@ export type CodegenResponse = CodegenValidReport | CrateInvalidReport;
 export interface PipeIORequest extends CrateRequestBase, PipelexHostedToolingExtensions {
     /**
      * The pipe to describe, as a QUALIFIED `domain.pipe_code` ref. Omit it and the
-     * server's selection chain decides: a fetched package's manifest `main_pipe`, else
-     * the closure's single `main_pipe` declaration. A selection the server refuses is a
+     * server's selection chain decides: the `main_pipe` of the `METHODS.toml` at the tree's
+     * root, whether the tree was sent or fetched, else the closure's single `main_pipe`
+     * declaration. A selection the server refuses is a
      * `422` typed by what went wrong, with `error_domain: "input"` and the candidates, where
      * there are some, in its `detail`: `EntryPipeNotFoundError` for a ref that names no pipe
      * or (without `all_pipes`) a method with no entry pipe, `EntryPipeAmbiguousError` for a
@@ -705,9 +806,9 @@ export interface PipeIORequest extends CrateRequestBase, PipelexHostedToolingExt
      */
     all_pipes?: boolean;
     /**
-     * Echo the resolved closure's `.mthds` files on the valid arm as `files`, in the
-     * request's own `files[]` shape. Defaults to `false` server-side, and the field is then
-     * absent from the answer.
+     * Echo the text of the method's own `.mthds` bundles on the valid arm as `files`, keyed
+     * by tree path. Defaults to `false` server-side, and the field is then absent from the
+     * answer.
      */
     include_files?: boolean;
 }
@@ -739,7 +840,8 @@ export interface PipeIOValidReport {
     output_form: OutputForm;
     /**
      * The method's own entry pipe: the selection chain without the request's `pipe_ref` —
-     * the fetched manifest's `main_pipe`, else the closure's single declaration. A request
+     * the `main_pipe` of the `METHODS.toml` at the tree's root, sent or fetched, else the
+     * closure's single declaration. A request
      * that omits `pipe_ref` always answers `pipe_ref === default_pipe_ref`. A stated `null`
      * when the chain finds none or several.
      *
@@ -752,12 +854,13 @@ export interface PipeIOValidReport {
     /** `pending_signatures` is empty, as on `validate`. No dry run backs it. */
     is_runnable: boolean;
     /**
-     * The resolved closure's `.mthds` files, in the request's `files[]` shape. Present only
-     * when the request passed `include_files: true`: the request's files for inline
-     * `files`, the fetched package's `.mthds` files under their package-relative paths for
-     * a `method_ref`, the stored files under their stored names for a hosted `method_id`.
+     * The text of each `.mthds` bundle of the method's own tree, keyed by its tree path.
+     * Present only when the request passed `include_files: true`: for a tree the request
+     * sent, its bundles, whatever entry form carried them; for a `method_ref`, the fetched
+     * package's, keyed by their path from the package root; for a hosted `method_id`, the
+     * stored tree's. The tree's other files and its dependencies' bundles are never included.
      */
-    files?: MthdsFileItem[];
+    files?: Record<string, string>;
 }
 /** The `POST /v1/pipe-io` 200 response — pattern-match `is_valid` before reading the arm. */
 export type PipeIOResponse = PipeIOValidReport | CrateInvalidReport;

package/dist/prepare-inputs.d.ts

@@ -6,10 +6,10 @@
  * `pipelex-storage://` in `url`) plus one upload record per prepared asset.
  *
  * The method is named the same three ways every other method-taking operation
- * takes it — inline `files`, a `method_ref` address, or a stored `method_id` —
- * exactly one per call. All three are pass-throughs to `POST /v1/pipe-io`, which
- * resolves an address on the runner and an id on the platform, so nothing is
- * expanded client-side. The route also SELECTS the pipe: the caller's qualified
+ * takes it — its tree (a `directory`, `contents`, a listed `tree` or the `files`
+ * map), a `method_ref` address, or a stored `method_id` — exactly one per call.
+ * All three reach `POST /v1/pipe-io`: the tree as the `files` map `pipeIo` sends,
+ * an address resolved on the runner and an id on the platform. The route also SELECTS the pipe: the caller's qualified
  * `pipe_ref`, else the method's own entry pipe, and the ref it answers with is
  * the one prepared. It runs no dry run, so preparing inputs costs one static load.
  *
@@ -30,8 +30,9 @@
  * dict. See `docs/input-preparation.md`, which `pipelex-sdk-python` mirrors case
  * for case.
  */
-import type { BundleResources } from "./bundle-resources.js";
-import type { MthdsFileItem, PipeIORequest, PipeIOResponse } from "./models.js";
+import type { MethodFiles } from "mthds/protocol";
+import type { CrateRouteOptions, PipeIORequest, PipeIOResponse } from "./models.js";
+import type { MethodTreeForm } from "./method-trees.js";
 import type { UploadCapableClient, UploadRecord } from "./upload.js";
 /** The shared half of the request: the target pipe and the caller's inputs. */
 export interface PrepareInputsBase {
@@ -50,7 +51,9 @@ export interface PrepareInputsBase {
     /**
      * Stops the preparation between its steps, a file's read and its upload included: once it has
      * aborted, neither the pipe I/O request nor any upload starts, and `prepareInputs` throws the
-     * abort. A request already sent runs to its end. It is not sent to the server.
+     * abort. A `tree` or `contents` sent by hash counts its steps too — the version handshake, the
+     * blob route, each read and upload of a missing blob — so an abort during the handshake starts
+     * none of the rest. A request already sent runs to its end. It is not sent to the server.
      */
     signal?: AbortSignal;
     /**
@@ -63,35 +66,48 @@ export interface PrepareInputsBase {
      */
     allowUploads?: boolean;
 }
+/**
+ * The method's tree, in exactly one of the forms `pipeIo` takes it (see `CrateRequestBase`):
+ * `directory`, the method's directory on disk, listed by the `mthds` package's lister (Node only);
+ * `contents`, each file's bytes or text by tree path; `tree`, a listed source such as the
+ * `MethodTree` the `mthds` package's `listMethodTree` returns; or `files`, the protocol's map of
+ * file entries, sent as given. The client sends a `directory`, `contents` or `tree` inline when
+ * small and by hash otherwise.
+ */
+export type PrepareInputsTree = MethodTreeForm;
+/** What a published or stored method cannot carry: its tree is its own. */
+interface NoTree {
+    directory?: never;
+    contents?: never;
+    tree?: never;
+    files?: never;
+    dependencies?: never;
+}
 /**
  * How the method is named — exactly one of the three selectors, each pinning the
  * other two to `never` so a second one is a compile error (the same XOR
  * `ValidateMethodSelector` states for `validate`). All three reach the
- * server as-is: `files` inline, `method_ref` resolved by the runner, `method_id`
- * resolved by the platform.
+ * server: the tree as the `files` map, `method_ref` resolved by the runner,
+ * `method_id` resolved by the platform.
  *
- * Inline `files` may bring `resources`, the files the closure's steps read, such
- * as a `PipeDocGen` step's `template_file`, keyed by the path the step names, each
- * as its bytes: the pipe I/O route loads the closure, and a step whose template file
- * was not sent makes it fail to load. A published or stored method's files are its
- * own, so the other two selectors take none.
+ * The tree may bring `dependencies`, the method packages it calls by address, each a
+ * map of file entries keyed by its address. The files the closure's steps read, such as a
+ * `PipeDocGen` step's `template_file`, are files of the tree like any other. The pipe I/O
+ * route loads the closure, and a step whose template file is not in the tree, or a call
+ * into a package nothing shipped, makes it fail to load. A published or stored method's
+ * tree and packages are its own, so the other two selectors take no `dependencies`.
  */
-export type PrepareInputsClosure = {
-    files: MthdsFileItem[];
-    resources?: BundleResources | null;
+export type PrepareInputsClosure = (PrepareInputsTree & {
+    dependencies?: Record<string, MethodFiles>;
     method_ref?: never;
     method_id?: never;
-} | {
+}) | (NoTree & {
     method_ref: string;
-    files?: never;
     method_id?: never;
-    resources?: never;
-} | {
+}) | (NoTree & {
     method_id: string;
-    files?: never;
     method_ref?: never;
-    resources?: never;
-};
+});
 /** What `prepareInputs` takes: one method selector, the target pipe, the caller's inputs. */
 export type PrepareInputsRequest = PrepareInputsBase & PrepareInputsClosure;
 /** The result of `prepareInputs`: rewritten inputs (copy-on-write) plus upload records. */
@@ -107,7 +123,7 @@ export interface PreparedInputs {
  * `PipelexApiClient` satisfies it structurally.
  */
 export interface PrepareCapableClient extends UploadCapableClient {
-    pipeIo(request: PipeIORequest): Promise<PipeIOResponse>;
+    pipeIo(request: PipeIORequest, options?: CrateRouteOptions): Promise<PipeIOResponse>;
 }
 /**
  * Where an input-form entry breaks the shape `prepareInputs` reads, and what was
@@ -147,8 +163,10 @@ export declare function inputFormFault(entry: unknown): InputFormFault | undefin
  * that would need either throws {@link UploadNotAllowedError}, naming them too.
  *
  * The pipe and its signature come from one `POST /v1/pipe-io`, whatever the
- * selector — inline `files`, a `method_ref` the runner resolves, or a
- * `method_id` the platform resolves. A bare or alias-qualified `pipe_ref`, a
+ * selector — the method's tree, a `method_ref` the runner resolves, or a
+ * `method_id` the platform resolves. A `tree` or `contents` too large to send
+ * inline goes by hash, and a blob that fails to upload throws
+ * `MethodFileTransferError` before the route is asked. A bare or alias-qualified `pipe_ref`, a
  * closure that does not load, and a selection the route refuses (an unknown
  * `pipe_ref`, no entry pipe, several) throw {@link InputPreparationError}. So
  * does an answer that breaks the route's contract, with a `runtime` verdict that
@@ -160,3 +178,4 @@ export declare function inputFormFault(entry: unknown): InputFormFault | undefin
  * the route) surfaces as `ApiResponseError`, unchanged.
  */
 export declare function prepareInputs(client: PrepareCapableClient, request: PrepareInputsRequest): Promise<PreparedInputs>;
+export {};