Release v0.15.0

CHANGELOG.md

@@ -1,5 +1,16 @@
 # Changelog
 
+## [v0.15.0] - 2026-09-18
+
+### Added
+
+- **`mthds.protocol.method_files` — the catalog serialization of a stored method's source**: `MethodFile` (`name` + `content`) and the pair `serialize_method_files` / `parse_method_files` between a list of files and the JSON `[{ name, content }]` string the hosted platform persists for a method's `.mthds` source and its custom PipeFunc `python`. The empty list serializes to `""`, the platform's "no source" sentinel, never to `"[]"`; blank-content entries are dropped in both directions; anything but the named array raises `PipelineRequestError`, including the three constants Python's `json` accepts and `JSON.parse` refuses. It mirrors the `mthds` npm package's `protocol/method_files.ts` edge for edge — blank is ECMAScript-blank, and the bytes are `JSON.stringify`'s down to both surrogate rules, an unpaired one escaped and an adjacent pair combined into the astral character Python alone can spell two ways — so a Python client reads a stored method's bundle from here rather than re-porting the platform's decoder. Python's own number model is kept out of the way too: integers decode as floats, the twin's single number type, so a literal longer than `sys.get_int_max_str_digits()` cannot raise a bare `ValueError` through the typed surface. One divergence from the twin is forced rather than chosen and is documented as such: Python's decoder recurses where `JSON.parse` iterates, so a deeply nested source is refused here and accepted there, at a depth that is an interpreter build constant.
+- **`mthds.protocol.options` — the run-source argument surface:** predicates that decide which combinations of `pipe_code`, `mthds_contents`, the bundle encodings `files` / `bundle_b64`, `method_ref` and `method_id` may be sent together (`assert_exclusive_run_sources`, `has_bundle_payload`, `assert_method_ref_pairs_with_nothing`), plus the selector normalization `normalized_selector` / `run_selector_extensions`, which refuses a non-string selector. Nothing in this package calls them, so no client behaviour changes: `MthdsAPIClient` still forwards the keys inside `extra` without interpreting them.
+
+### Changed
+
+- **`ConceptAbstract` names a concept and nothing more, and `StuffAbstract` serializes `concept` as the ref string (Breaking)**: the protocol's concept model keeps `code`, `domain_code` and the `concept_ref` property — `description`, `structure_class_name` and `refines` are gone, since a concept's definition belongs to the library the method loads and never travels beside a stuff, and a runtime that needs one of them in memory declares it on its own subclass. `StuffAbstract` now carries a field serializer on `concept`, so every dump of a stuff emits `{"concept": "<domain>.<Code>", "content": …}` — the wire form the standard's [CLI I/O contract](https://mthds.ai/latest/spec/cli-io-contract/) requires — instead of leaving each runner to reduce the object itself. The dependency-contributed crate key `<package_address>::<domain>.<Code>` is a subclass's to produce, by overriding `StuffAbstract.serialize_concept` under that name: the protocol model holds no declaring package address. The dump is one-way, which is the point rather than an oversight — a `StuffAbstract`, a `WorkingMemoryAbstract` or a `PipeOutputAbstract` can no longer be validated back from its own dump, since the definition such a parse would need is exactly what no longer travels. A consumer that used to re-validate a dump resolves the concept by ref through the library the method loads, the way the input side already does. Which of the two override points a runtime picks decides what this SDK's own output path emits: `DictRunResultExecute.from_pipe_output` reduces a stuff by `concept_ref`, so a `concept_ref` override reaches it and a `serialize_concept` override does not.
+
 ## [v0.14.0] - 2026-09-06
 
 ### Added

README.md

@@ -14,7 +14,7 @@ pip install mthds
 
 ## What's in the box
 
-- **The protocol** (`mthds.protocol`) — `MTHDSProtocol`, the five-route interface every runner implements (`execute`, `start`, `validate`, `models`, `version`); the wire models (`RunResult`, `ModelDeck`, `ValidationReport`, `VersionInfo`); and the domain shapes methods are built from (`concept`, `stuff`, `working_memory`, `pipe_output`, `pipeline_inputs`).
+- **The protocol** (`mthds.protocol`) — `MTHDSProtocol`, the five-route interface every runner implements (`execute`, `start`, `validate`, `models`, `version`); the wire models (`RunResult`, `ModelDeck`, `ValidationReport`, `VersionInfo`); the domain shapes methods are built from (`concept`, `stuff`, `working_memory`, `pipe_output`, `pipeline_inputs`); and the catalog serialization of a stored method's source (`method_files`).
 - **Runners** (`mthds.runners`) — `MthdsAPIClient` (`mthds.runners.api.client`), the HTTP client for any MTHDS-Protocol server plus the hosted run-lifecycle (polling) extension; and `PipelexRunner` (`mthds.runners.pipelex.runner`), which shells out to a locally installed `pipelex` CLI.
 - **Package management** (`mthds.package`) — read, lock, and resolve `METHODS.toml` manifests.