Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,8 @@
- **`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 is rebuilt on `@pipelex/sdk` 0.48.1, with `@pipelex/tools-wasm` still at 0.6.0, so a validation sends the edited file's method 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 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.

### Fixed

Expand Down
7 changes: 7 additions & 0 deletions docs/decisions.md
Original file line number Diff line number Diff line change
Expand Up @@ -913,6 +913,13 @@ The section above kept the test documents beside a bundle out of the method's tr
- **The ignore guard keeps what it still guards.** It still checks an `inputs.json` holding a file's text, as a Text input read from a `.txt` or `.md` file does, and a case's copies and its prepared file; a copy git does not ignore still waits for the user, a tracked sample under the same name included. An `inputs.json` holding only addresses is not ignored: it is the method's sample for the team that shares it, and an address resolves only inside that organization, the trade-off the design accepts. The shared include's comment now cites the workshop's `runs/` mark as its example of a folder that marks itself, since `pipelex-inputs` marks nothing.
- **The ceiling paid for it with the copy step.** `pipelex-inputs` lost the marking guard, the question about an `inputs/` already there and the prepared file's default, and gained one guard, that a file is uploaded where it lies unless the calling skill asks for a case's copies. `pipelex-synthetic-inputs` lost its two marking guards for the temporary directory. `pipelex-run` names the lab case as the one place a prepared file is read, and dropped the path in its lab offer, which the earlier sentence already gives. The copy procedure, the link replacement and the list input's directory moved into the user-data reference's section on a case's copies, read only when the calling skill asks for them.

## The hook names an invalid verdict's problem items (2026-10-24)

A runner speaking the MTHDS problem document carries an invalid verdict's faults as problem items in `errors[]` and sends no `validation_errors[]`. The hook always asks for the server's Markdown, which renders those items, so the gap showed only against a server that ignores the `render` request: the bundle built its block reason from `validation_errors[]`, and the reason named no item at all. "The hook and the integrate call site send the method's tree" above left it as a strict expected failure in `tests/unit/test_hook_validate_verdict.py`.

- **The bundle is rebuilt on the `@pipelex/sdk` 0.53.0 release, the first whose hook reads the items.** Its banner names 0.53.0 and that release's commit, and `@pipelex/tools-wasm` stays at 0.6.0. The bundle was first re-vendored from the SDK branch that carried the reading, ahead of the release, which let the strict expected failure go early; `make check-hook-fresh` compares what lies below the banner with a rebuild on the SDK's `dev`, and that body holds the SDK's version string and every client module the bundle inlines, so the release gate held the bundle to a second re-vendor once the SDK released. The hook reads the items through the SDK's own reader of a verdict's problem items, `readProblemItems`, the one every verdict the SDK reads goes through. Nothing else the hook uses moved since the bundle built on `@pipelex/sdk` 0.48.1: its lint, its format and the request its validate stage sends are the same, and only its `User-Agent` names the new version. The bundle also carries the client changes the SDK made meanwhile, which the hook never calls, among them every error reshaped as a problem document; the validate stage catches whatever its call throws and is skipped, as before, so none of them reaches the agent.
- **The reason names each item, and `validation_errors[]` is no longer read.** Each item is a line with its code, its sentence and its location, in the `mthds` package's wording, with its suggested fix beneath it, and an entry the bundle cannot read is skipped or trimmed rather than failing the block. A server of the older shape that also ignores `render` now gets the verdict's message alone, which is accepted: the hosted plane, the hook's default, speaks the problem document, and nothing here keeps a compatibility path. The strict expected failure is gone, and the test passes outright.

## License & distribution

**Elastic License 2.0** since 2026-09-30, Apache 2.0 before. Two exceptions. Code the skills copy or write into a user's project is granted under MIT-0, stated in the README's License section and as an SPDX line in the two copied gates, because it lands in the user's own repository, which they may publish, and ELv2's terms would otherwise travel with it. The vendored `check.mjs` is MIT code from other Pipelex packages and a fork of Taplo, and ships with its notice beside it. The repo is public (required for easy marketplace install). Versions start at **0.1.0** (plugin and marketplace). GitHub home assumed `Pipelex/pipelex-plugins` — confirm at first push.
Loading
Loading