[lchoquel]

Release v0.17.0

Bumps version from 0.16.0 to 0.17.0. Promotes dev → main.

Changelog

Added

• pipelex-inputs and pipelex-run look among your team's files first: before asking you for a file a method input takes, and when you name one that is not on disk, such as "the invoice uploaded this morning", the skills look among your organization's files with the Pipelex tools' mthds_list_files and pass the file you settle on by its pipelex-storage:// address, so nothing is uploaded again. With a version of the tools older than that listing, they ask for the file as before and name the npx -y @pipelex/mcp@latest refresh.
• Synthetic files upload as the method's test files: when pipelex-inputs uploads the files pipelex-synthetic-inputs made, it passes kind: "test" to mthds_prepare_inputs, so your organization's files list them as test files of the saved method, named by its bare catalog id or by the bundle directory's link, and a preparation that also uploads your own files does so in a second call, which keeps yours ordinary uploads. A published address, a version or draft id, a directory linked to no saved method, a role that may not record test files and a version of the tools older than test files all upload them as ordinary files, and the skill says which.

Changed

• pipelex-integrate sends the method's tree (Breaking): the call site the skill writes runs the method with its whole bundle directory as the method's tree, directory: BUNDLE_DIR on @pipelex/sdk 0.48.0 and tree=BUNDLE_DIR on pipelex-sdk 0.48.0, the floors step 8 now installs, so the template files a bundle's PipeDocGen steps name travel with every run in either language, and its docstring names prepareInputs with the same tree. A refresh raises an older pin and rewrites a module that still sends mthds_contents or resources; a python-structures project whose pipelex, once step 8 has run, still pins a pipelex-sdk from before the tree keeps the older module, and over a bundle naming template files the skill stops there as before. The skill judges that by the pipelex-sdk the project will run on after step 8, syncing the environment first when the version cannot be read, and takes the older module and the stop when it still cannot.
• pipelex-integrate records and checks the tree a run sends (Breaking): the skill passes a local bundle to the workshop as its folder and records the files it sent, and both drift gates list the bundle with the MTHDS standard's own lister, the one the SDK sends it with, so a file a .gitignore inside the bundle or the manifest's exclude keeps out of the run is out of the types and the gate too, and a .gitignore edit that changes which bundle or template files the tree carries makes the gate report stale-source. A METHODS.toml above the bundle is now a stop at step 1, before anything is generated, and the gates name its cure, moving the bundle out from under it or integrating the package's own directory, instead of sending you to a refresh that could never clear it; a bundle the workshop cannot read as a folder is a stop as well, since no other submission is the tree the call site sends. A refresh re-copies the new gate; the TypeScript gate finds that mthds beside @pipelex/sdk in node_modules or, under Yarn Plug'n'Play, through pnpapi, and gives no verdict when it is missing or older than the floor's, and the Python gate when pipelex-sdk is below the floor.
• pipelex-inputs uploads your files where they lie, and a method's folder keeps only inputs.json (Breaking): the skill no longer copies your files into inputs/ beside the method or writes inputs.prepared.json there; it uploads each file from where you keep it, an Office file as the PDF it exports into a temporary directory, and writes the pipelex-storage:// address it gets back into inputs.json, which pipelex-run then runs as it stands, sending a value that still names a local file back to pipelex-inputs to be uploaded first. pipelex-synthetic-inputs makes its files in a fresh temporary directory by default, on its own too, and reports their path and their name among your organization's files, so anything that read the copies under inputs/ or a method folder's inputs.prepared.json now reads the addresses in inputs.json, which resolve only inside the organization that uploaded the files. A pipelex-lab case is the exception and keeps its copies under cases/<case>/inputs/ with its prepared file beside them, so that it runs from any clone, and folders an earlier release prepared are not migrated.
• The validation hook sends the method's tree: the check.mjs bundle every target runs on a .mthds edit now sends the edited file's method to validation as the tree a run would send, rooted at the nearest METHODS.toml, every file the MTHDS membership rule keeps under its root rather than only its .mthds files and the templates its steps name. Names starting with a dot, such as .env, a run's inputs file, and what a .gitignore inside the tree or the manifest's exclude keeps out stay on your machine, and so does a file the hook's secret screen finds, named like a key or credentials file or holding a private key or a provider's key, which the verdict's note names without quoting it; a bundle or manifest that looks like a secret sends nothing, under a note. A .gitignore above the tree, such as a repository's root one, still keeps nothing out, and the screen recognizes only well-known shapes, so keep keys and credentials out of a method's directory, or list them in a .gitignore inside it. A tree holding a symbolic link, or past the hook's size caps, still passes the validation silently.
• The validation hook names each problem item of a refused method (Breaking): when the server sends no Markdown with an invalid verdict, the block reason the check.mjs bundle builds now gives every problem item of the verdict's errors[] a line of its own, with its code, its sentence and where it happened, such as its pipe and its file, and the item's suggested fix beneath it, where against a server speaking the MTHDS problem document it named no item at all. A server still answering the older shape is no longer read: the bundle ignores its validation_errors[], so when such a server also ignores the render request, the block reason holds the verdict's message alone and names none of its faults. It is rebuilt on @pipelex/sdk 0.54.1 and @pipelex/tools-wasm 0.6.1, and its lint, its format and the request its validate stage sends are unchanged, except that its User-Agent names 0.54.1.
• The skills read the Pipelex tools' errors as problem documents (Breaking): every skill now reads a failed tool call by its problem's code, domain, retry and next_step, a verdict's faults as errors[] items, its warnings as problem items such as pipelex.docgen.template_warning, and a failed run by its run_error, which is what the workshop sends from the release that moves its errors to the MTHDS problem document, instead of the class, retryable, hint and kind of an error, validation_errors[] outside the catalog's save and publish, and a run's failure_message, which it no longer sends. So a missing or refused key, a role, the organization's credit or an unreachable API stops a skill with the tool's next step relayed verbatim, the catalog tells an unknown id from a link naming another method, a version suffix and an empty stored source by their codes, pipelex-inputs reads a preparation failure by its code, and a failed run keeps the support line the tool's summary ends with; use these skills with a workshop that sends problem documents.

Fixed

• Your test documents no longer travel as files of the method: the documents pipelex-inputs copied and pipelex-synthetic-inputs rendered into inputs/ beside a bundle, and the inputs.prepared.json written there, were sent with every validation, run and catalog save of the method and stored with it, since the method's tree keeps out only inputs.json and reads no .gitignore above the method's folder. The skills no longer write either beside a method, and before its first call on a bundle an earlier release prepared, pipelex-run adds * to the .gitignore of each inputs/ beside an inputs.json and /inputs.prepared.json to the .gitignore beside that file, each only where the line is missing and saying so, so a second run changes nothing.
• pipelex-inputs anchors the .gitignore entries it writes: an inputs.json or inputs.prepared.json entry written into the bundle directory's own .gitignore was a bare name, which git matched at every depth below, so an inputs.json you commit elsewhere in the folder was silently ignored from then on. The entries now start with /, naming only the file beside the bundle.
• The development environment is built on Python 3.13: make install built .venv on the newest Python on the machine, so on Python 3.15 pydantic-core was compiled from source and failed to load, and every integrate gate test failed. The repository now pins 3.13 in .python-version, the version CI runs, the next make install rebuilds an environment made on another Python, PYTHON_VERSION=<version> make install tries another one, and make check fails when the pin, the floors in pyproject.toml and the workflows disagree.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ChCUgUaFZK7FTEAc8uPAVL