feature/Re-vendor-hook-sdk-0541 · L-261025-087fe8

CHANGELOG.md

@@ -13,7 +13,7 @@
 - **`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.53.0, with `@pipelex/tools-wasm` still at 0.6.0, and its lint, its format and the request its validate stage sends are unchanged, except that its `User-Agent` names 0.53.0.
+- **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