## Release v0.32.0

Bumps version from `0.31.0` to `0.32.0`. Promotes `dev` → `main`.

Ships `@pipelex/sdk` (`js`), `starter-js`, `starter-python` and the
method-app family (`method-apps`: `@pipelex/create-method-app`,
`webapp-js`, and `cli-python` for the first time), all at 0.32.0. Holds
back nothing; `pipelex-sdk` (`python`) is unchanged since v0.31.0 and
keeps that version.

### Changelog

#### `@pipelex/sdk` (`js/`)

##### Changed

- **The `.mthds` check hook's lint engine moves to `@pipelex/tools-wasm`
0.4.0**: the bundle built by `npm run build:hook` now embeds
`@pipelex/tools-wasm` 0.4.0, whose MTHDS schema accepts binding steps in
a `PipeSequence`'s steps, a dotted `batch_over` on a sequence step, and
the `PipeDocGen` and `PipeJudge` pipe types, and refuses dotted input
names, so the hook no longer blocks those valid forms and blocks a
dotted input name with a schema error.

#### `starter-js`

##### Changed

- **Codegen reads `POST /v1/pipe-io` instead of validating each method
(Breaking)**: `npm run codegen`, `npm run codegen:verify` and `make
add-method` read a method's contracts and form descriptors from `POST
/v1/pipe-io`, which loads the method without dry-running it, where they
ran a full `POST /v1/validate`. The contracts and descriptors are the
same, byte for byte, but the header of each `contracts.ts` now names the
new route, so the first regeneration rewrites that line and
`codegen:verify` reports the old one as drift until it does. A method
whose pipes are still declared as signatures is now refused, naming
them, since it cannot run, while a method whose dry run would fail is no
longer refused when generating and fails at its first run instead. The
default pipe `make add-method` scaffolds is the route's entry pipe,
which a bundle whose domains each declare a `main_pipe` does not have,
so such a bundle is now refused with a request for `PIPE` where the
first declaring domain's pipe used to be taken. The base URL must serve
`/v1/pipe-io`, as `api.pipelex.com` does and `pipelex-api` does from
v0.33.1, and the method's own description, which `make add-method`
respells a derived label from, is now read from its `.mthds` files with
`smol-toml`, a new development dependency.
- **`@pipelex/sdk` 0.30.0, whose file preparation reads `POST
/v1/pipe-io` (Breaking)**: bumped from 0.26.0. The PDF example's run
actions, and every action `make add-method` writes for a method that
takes a file, prepare their inputs with the SDK's `prepareInputs`, which
now reads the method's inputs from `POST /v1/pipe-io` instead of
validating the method, so preparing a file no longer dry-runs it.
`api.pipelex.com` serves that route, and so does `pipelex-api` from
v0.33.1; a project whose `PIPELEX_BASE_URL` names an older runner moves
it forward, or its file-taking methods are refused before the run. Each
action already names its pipe by its qualified reference, so the route
selects the same pipe, and a pipe it cannot select is reported as an
input-preparation failure carrying the server's reason. The SDK's other
breaking changes in between, the `/v1/build/*` wrappers removed, slimmer
run-history rows, an optional `main_stuff` and model decks carrying
`judgment` models, reach nothing the app calls.
- **`mthds` stays in two copies**: the SDK's own copy of `mthds` moves
from 0.28 to 0.30, beside the 0.25 that `@pipelex/mthds-form` asks for,
so `npm ls mthds` keeps listing two copies until the form kernel moves
to `mthds` 0.30. The protocol types the app passes from one to the other
are still declared identically, so the app type-checks. The template's
`bump-mthds-form` skill no longer claims that the two packages always
share one copy: it says two copies can check clean, and which package to
move when their ranges part.

#### `starter-python`

##### Changed

- **`pipelex-sdk` 0.30.0 and `mthds` 0.18.0 are the floors**: bumped
from 0.14.0 and 0.17.0. A project made from the template that lists the
model deck with the client's `models()` no longer fails the whole call
on a deck holding a `judgment` model: `mthds` 0.18.0 reads that
category, and keeps the raw string in `ModelInfo.type` for a category it
does not know. The SDK's breaking changes in between, run-history rows
reduced to `RunHistoryItem`, `PipeStatus` removed, an optional
`main_stuff` and `prepare_inputs` reading `POST /v1/pipe-io`, reach
nothing the starter calls: it reads `main_stuff` only from a full
results read, where a completed run without one still raises
`MissingMainStuffError`.

#### The method-app family (`method-apps/`)

##### Added

- **`cli-python`, the Python command-line template**: a uv project whose
one command runs one MTHDS method through `pipelex-sdk` and prints its
result as JSON on stdout, with the run id, progress, downloaded files,
the cost report and errors on stderr. By default a run is followed until
its result arrives, however long that takes; `--blocking` runs it in one
request, `--detach` prints the run id alone for `--resume <run-id>` to
collect later, and Ctrl-C leaves a run going and prints the `--resume`
command that picks it up; a server that cannot hold runs is an error
naming `--blocking`, never a silent fallback. The template ships no
method, so its command says to run `make create`. No initializer serves
it yet: its README copies it out of the tag of v0.32.0, the first
release that ships it, or of a later release, with `curl` and `tar`,
stopping at the first step that fails.
- **`cli-python` takes the method's inputs as options and checks its
result, from contracts it generates**: `make codegen` writes the
method's typed models and its contracts into the package through the
API, `make codegen-check` says offline, as part of `make check`, whether
they are still current with the method, and `make codegen-verify` asks
the API whether they are still what the method resolves to. The command
takes one option per input the method declares, derived from the
committed input form when it loads, puts on the wire what the web app
template's form sends for the same values, uploads a local file before
the run, prints the inputs template with `--inputs-template`, and
refuses a run missing a required input with exit code 2. A result the
generated output model refuses is not printed, every hint names the
command as it was invoked, and a finished download leaves a manifest by
which a second `--resume` tells it whole.
- **`cli-python`'s `make create` turns a copy of the template into the
command for one method**: `make create METHOD=<bundle path | mt_… |
address>` takes the family's arguments, fetches the method once, writes
it into the package with its generated models, its contracts and a
`binding.py` naming the pipe the command runs, and names the
distribution, the import package and the command after the method. It
then writes `.env` readable by its owner alone, with one
`PIPELEX_BASE_URL` line and the key from the shell, quoted so a `#` or a
`$` survives, re-syncs `uv.lock`, runs `make all`, and removes its
bootstrap once the checks are green; it never asks a question, refuses
what it cannot derive by naming the variable that supplies it, and with
`DRY_RUN=1` prints its plan and writes nothing. The bootstrap skill it
runs, also usable on its own to finish a create that stopped after
writing the method, removes the gesture and every passage about it from
the project it creates.
- **`cli-python` carries a `bump-sdk` skill, which stays in every
project created from it**: asked to bump the SDK, a coding agent reads
the changelogs of `pipelex-sdk` and of the `mthds` version it pins
exactly for the versions in between, weighs each entry against the files
the SDK reaches in the project and the tests that catch a change under
each, applies mechanical renames, raises both floors in
`pyproject.toml`, re-locks `uv.lock` to the target exactly, runs `make
all`, offers `make codegen-verify` and one live run, and prepares a
commit.

##### Changed

- **`@pipelex/create-method-app` sends a request for `cli-python` to its
copy-out**: `--template cli-python` is still refused with `refused:
other-ecosystem`, and its line now points at the section of the
template's README that copies it out of a release of
`Pipelex/pipelex-sdk`, where it named `uvx create-pipelex-method-app`, a
Python initializer that does not exist yet.
- **The web app template's codegen reads `POST /v1/pipe-io` instead of
validating each method (Breaking)**: `make create`, `make add-method`,
`npm run codegen` and `npm run codegen:verify` read a method's contracts
and form descriptors from `POST /v1/pipe-io`, which loads the method
without dry-running it, where they ran a full `POST /v1/validate`. The
contracts and descriptors are the same, byte for byte, but the header of
each `contracts.ts` now names the new route, so a project's first
regeneration rewrites that line and `codegen:verify` reports the old one
as drift until it does. A method whose pipes are still declared as
signatures is now refused, naming them, since it cannot run, while a
method whose dry run would fail is no longer refused when generating and
fails at its first run instead. The default pipe `make create` and `make
add-method` scaffold is the route's entry pipe, which a bundle whose
domains each declare a `main_pipe` does not have, so such a bundle is
now refused with a request for `PIPE` where the first declaring domain's
pipe used to be taken. The base URL must serve `/v1/pipe-io`, as
`api.pipelex.com` does and `pipelex-api` does from v0.33.1, and the
method's own description, from which `make create` describes the project
and the gestures respell a derived title or label, is now read from its
`.mthds` files with `smol-toml`, a new development dependency.
- **The web app template runs on `@pipelex/sdk` 0.30.0, whose file
preparation reads `POST /v1/pipe-io` (Breaking)**: bumped from 0.26.0.
The action that `make create` or `make add-method` writes for a method
taking a file prepares its inputs with the SDK's `prepareInputs`, which
now reads the method's inputs from `POST /v1/pipe-io` instead of
validating the method, so preparing a file no longer dry-runs it.
`api.pipelex.com` serves that route, and so does `pipelex-api` from
v0.33.1; a project whose `PIPELEX_BASE_URL` names an older runner moves
it forward, or its file-taking methods are refused before the run. Each
action already names its pipe by its qualified reference, so the route
selects the same pipe, and a pipe it cannot select is reported as an
input-preparation failure carrying the server's reason. The SDK's other
breaking changes in between, the `/v1/build/*` wrappers removed, slimmer
run-history rows, an optional `main_stuff` and model decks carrying
`judgment` models, reach nothing a project created from the template
calls.
- **The web app template's `mthds` stays in two copies**: the SDK's own
copy of `mthds` moves from 0.28 to 0.30, beside the 0.25 that
`@pipelex/mthds-form` asks for, so `npm ls mthds` keeps listing two
copies until the form kernel moves to `mthds` 0.30. The protocol types
the app passes from one to the other are still declared identically, so
the app type-checks. The template's `bump-mthds-form` skill no longer
claims that the two packages always share one copy: it says two copies
can check clean, and which package to move when their ranges part.

##### Fixed

- **The web app template's codegen refuses a method that changed while
it was being generated**: `npm run codegen`, `make add-method` and `make
create` now ask `POST /v1/codegen` again once `POST /v1/pipe-io` has
answered, and write nothing when the method resolved to another crate in
between, saying so and to run the command again. A method edited or
republished between the two requests used to leave the generated types
of one revision beside the contracts of another, a tree `codegen:check`
called current.
- **The web app template no longer describes a failed input preparation
as a failed upload**: when a run's inputs cannot be prepared, for
instance because the API refuses the pipe the action names, the error
now reads "Preparing the inputs failed" and names the method's signature
or its pipe as the usual cause, with the server's reason in the
technical details. It used to say that the app could not upload the file
to Pipelex storage, although a run's files are stored before it starts.

🤖 Generated with [Claude Code](https://claude.com/claude-code)


<!-- This is an auto-generated description by cubic. -->
---
## Summary by cubic
This is the v0.32.0 release: it bumps the repository version from 0.31.0
to 0.32.0 and promotes `dev` to `main`, shipping `@pipelex/sdk`,
`starter-js`, `starter-python`, and the method-app family
(`@pipelex/create-method-app`, `webapp-js`, and — for the first time —
`cli-python`) at 0.32.0. `pipelex-sdk` (Python) is unchanged since
v0.31.0 and keeps that version.

**New Features**
- Adds `cli-python`, the method-app family's Python command-line
template: a uv project whose one Typer command runs one MTHDS method
through `pipelex-sdk`, printing the result as JSON on stdout with
progress, run id, the cost report, downloaded files, and errors on
stderr.
- The command derives one option per declared input from the method's
committed contracts, generated by `make codegen`, and validates each
result strictly against the generated output model.
- `make create METHOD=<bundle path | mt_… | address>` turns a copy of
the template into the named CLI for one method, writing `.env`,
re-syncing `uv.lock`, and running `make all`; `DRY_RUN=1` prints the
plan and writes nothing.

**Breaking Changes**
- `starter-js`, `webapp-js`, and `starter-python` codegen (and
file-touching actions) now read `POST /v1/pipe-io` instead of running
`POST /v1/validate`; contracts and descriptors are byte-identical, but
each `contracts.ts` header names the new route, so the first
regeneration rewrites that line and `codegen:verify` reports the old one
as drift until it does. Methods whose pipes are still declared as
signatures are refused, and file-taking methods are refused on runners
older than `pipelex-api` v0.33.1.
- The web app template's codegen now refuses to write when the method
resolved to a different crate between its codegen and pipe-io answers,
and describes a failed input preparation as "Preparing the inputs
failed" rather than as an upload failure.
- The `.mthds` check hook's lint engine moves to `@pipelex/tools-wasm`
0.4.0, which accepts binding steps, a dotted `batch_over`, and the
`PipeDocGen`/`PipeJudge` pipe types, and refuses dotted input names.
- `starter-python` floors rise to `pipelex-sdk` 0.30.0 and `mthds`
0.18.0; the SDK's `prepare_inputs` now reads `POST /v1/pipe-io`, which
no starter's code calls, and `ModelInfo.type` keeps a raw string for an
unknown category.

<sup>Written for commit 13d35c5f3889a2c50c9ed554b8116fb94792e6fd.
Summary will update on new commits.</sup>

<a
href="https://cubic.dev/pr/Pipelex/pipelex-sdk/pull/36?utm_source=github"
target="_blank" rel="noopener noreferrer"
data-no-image-dialog="true"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source
media="(prefers-color-scheme: light)"
srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img
alt="Review in cubic"
src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a>

<!-- End of auto-generated description by cubic. -->