v0.46.0

@pipelex/sdk on npm

Added

• ApiResponseError.problem, the standard's reading of the answer: every ApiResponseError now also carries the same answer as the MTHDS standard reads it, typed as the standard's Problem and equal to the problem mthds's own ApiResponseError carries, so a caller handling both clients branches on problem.code, except that on start and execute runMayHaveStarted decides: client.outcome_unknown, naming the run when the body names one, wherever a run may have started, even when the body is a core problem document, which a runner inviting a retry would otherwise have the error carry beside runMayHaveStarted: true, and the reading of an answer to a request that creates no run wherever none did. The hosted members read exactly as before, and the platform's code and errors stay on the error, apart from the registry's problem.code and the problem items of problem.errors (docs/errors.md).

Changed

• ApiResponseErrorOptions.problem is now details (Breaking): an ApiResponseError built by hand passes the hosted problem document's typed members as details, and may pass the answer's headers, from which the standard's reading takes a Retry-After.
• The validate verdict's types stand alone (Breaking): PipelexValidationReport and PipelexInvalidReport no longer extend the standard's ValidationReport and InvalidValidationReport, which list problem items since protocol 2.0.0 while the hosted plane still sends validation_errors, so PipelexApiClient implements MTHDSProtocol for every route but validate, and a PipelexValidationResult is no longer assignable to the standard's ValidationResult. ValidationErrorItem and SuggestedFix keep the hosted shape, no longer pinned to the standard's, whose fix shares only its operation kinds, safeties and values.
• errorVerdictOf reads an mthds error by its problem, and problemVerdict translates the standard's verdict: the standard's client now carries its verdict on its problem, as domain and retry, so errorVerdictOf reads an mthds error as that problem's verdict in this SDK's vocabulary rather than from the error_domain and retryable a runner sent: input and method read as input, account and operator as config, runtime as runtime, and only a retry of yes is retryable. problemVerdict applies the same mapping to any problem of the standard.
• The mthds floor moves from ^0.30.0 to ^0.32.1 (Breaking): mthds 0.32.1 is the release that reads every answer as a problem document coded from the MTHDS core error registry 8.0.0 and moves the protocol to 2.0.0, the reading this SDK's errors and verdicts now follow. What this package re-exports from mthds/protocol follows it: ValidationError is gone, the standard's ValidationReport, InvalidValidationReport and ValidationResult list ProblemItems in errors, ConceptAbstract keeps only code and domain_code, and the standard's problem types and readers, Problem and readAnswer among them, are exported beside them. A project that also imports mthds itself moves to 0.32 with it, so that one copy is installed; 0.32.1 is published under the maint-0.32 dist-tag, so install it as mthds@^0.32.1, since latest names a release outside this range.

Fixed

• A body the protocol refuses as JSON is an answer the SDK cannot read: a 2xx body nested deeper than MAX_BODY_NESTING, or holding a number past the range of a double, which JSON.parse reads as Infinity, throws the ApiResponseError of an answer the SDK cannot read, an answer read exactly such as a run's results included, and a refusal whose body is such JSON carries no hosted member, as pipelex-sdk reads both.

pipelex-sdk on PyPI

Added

• problem on every error raised over a request, the standard's reading of the failure: an ApiResponseError carries the same answer as the MTHDS standard reads it, typed as the standard's Problem and equal to the problem mthds's own ApiResponseError carries, so a caller handling both clients branches on problem.code, except that on start and execute run_may_have_started decides: client.outcome_unknown, naming the run when the body names one, wherever a run may have started, even when the body is a core problem document, which a runner inviting a retry would otherwise have the error carry beside run_may_have_started=True, and the reading of an answer to a request that creates no run wherever none did; every other error raised over a request carries the core problem that states its failure, and argument_invalid_problem and response_unreadable_problem in pipelex_sdk.errors build the two a hand-built error most often needs. The hosted members read exactly as before, and the platform's code and errors stay on the error, apart from the registry's problem.code and the problem items of problem.errors (docs/errors.md).
• UploadAuthenticationError and ArtifactAuthenticationError tell a missing credential from a refused one: their problem is auth.missing_credential when the client sent no API key and auth.invalid_credential only when it sent one, so an anonymous caller is told to supply a key rather than that its key is wrong. Both constructors take credential_sent, True by default.
• HostedProblemMembers and ProblemUserAction: pipelex_sdk.error_models reads the hosted problem document's members itself, as the standard's client no longer does, and ProblemUserAction is the type of ApiResponseError.user_action.

Changed

• ApiResponseError.problem is the standard's problem, and the decoded document is problem_document (Breaking): code that read a member off err.problem as a dict reads it off err.problem_document, and an ApiResponseError built by hand passes the document as problem_document; the error is no longer generic over its validation item, and its user_action is a ProblemUserAction rather than the mthds UserAction.
• RequestArgumentError, InputPreparationError and ArtifactOperationError take an optional problem: a caller raising one of them by hand may pass the standard's problem it states, such as argument_invalid_problem(argument=..., reason=...), as a keyword; one built from a message alone, as before, carries a default problem stating its verdict: client.argument_invalid naming arguments for a RequestArgumentError and inputs for an InputPreparationError, with the reason unspecified, and runtime.unexpected for an ArtifactOperationError.
• upload_file, prepare_inputs and download_artifacts read the client's api_key (Breaking): the protocols typing their client, ArtifactCapableClient among them, now declare the api_key property PipelexAPIClient has, read to word a refused credential, so a stand-in client passed to them, such as a test's fake, declares one too.
• ApiUnreachableError is the standard's ApiTransportError: a handler written against the standard's client catches it, and it carries request_url and the standard's reading of the failure, client.unreachable, client.timeout or client.outcome_unknown.
• The validate verdict's types stand alone (Breaking): PipelexValidationReport and PipelexInvalidReport no longer subclass the standard's ValidationReport and InvalidValidationReport, which list problem items since protocol 2.0.0 while the hosted plane still sends validation_errors, and ValidationErrorItem no longer subclasses the standard's ValidationDiagnostic; every field they carried stays.
• error_verdict_of reads an mthds error by its problem, and problem_verdict translates the standard's verdict: the standard's client now carries its verdict on its problem, as domain and retry, so error_verdict_of reads an mthds error as that problem's verdict in this SDK's vocabulary rather than from the error_domain and retryable a runner sent: input and method read as input, account and operator as config, runtime as runtime, and only a retry of yes is retryable. problem_verdict in pipelex_sdk.error_verdicts applies the same mapping to any problem of the standard.
• A request_timeout_seconds that is not a finite number of seconds is refused (Breaking): the standard's client now refuses a time limit that is not finite or is negative, and the constructor raises it as a RequestArgumentError carrying the standard's problem, where such a limit used to be accepted.
• Requires mthds 0.22.1, the release that carries the problem document (Breaking): the exact pin moves from mthds==0.22.0 to mthds==0.22.1, so every environment holding this pipelex-sdk installs exactly that mthds, and a project that also pins mthds itself has to move with it. mthds 0.22.1 makes every error it raises carry a problem coded from the MTHDS core error registry 8.0.0 while a method still travels as mthds_contents, the reading this SDK's errors and verdicts now follow; code of your own that calls mthds's client directly follows mthds's changelog, where ClientNotConfiguredError replaces ClientAuthenticationError and a validate verdict lists its faults in errors.

Fixed

• A body the protocol refuses as JSON is an answer the SDK cannot read: a 2xx body nested deeper than the protocol's limit, or holding NaN, Infinity or a number past the range of a double, raises the ApiResponseError of an answer the SDK cannot read instead of a bare RecursionError or a value holding a non-finite float, and a refusal whose body is such JSON carries no hosted member, as @pipelex/sdk reads both.
• A base URL httpx cannot make a URL of is refused at construction: a host holding a control character raises the config RequestArgumentError of a refused base URL when the client is built, as @pipelex/sdk refuses it, rather than failing every request.

@pipelex/create-method-app on npm, with the method-app templates

Changed

• The CLI's test client declares api_key: the FakeClient in cli-python's tests/support.py carries the API key a client sends, which pipelex-sdk's prepare_inputs reads from its next release on to tell a missing credential from a refused one.
• Both templates run on the SDK 0.45.0, and the web app on @pipelex/mthds-form 0.17.1: @pipelex/sdk in the web app and pipelex-sdk in the CLI, with mthds 0.22.0 in the CLI, bumped from 0.39.0, mthds 0.21.0 and the kernel 0.10.0, and npm ls mthds now lists one copy in the web app, where it listed the form kernel's and the SDK's apart. In the web app, a result holding an integer past Number.MAX_SAFE_INTEGER arrives exact rather than rounded, so a generated schema expecting a number refuses it by name; each file in a result gains its own download button, an HTML result shows as one page with a "Download PDF" control and its stored pictures painted through the assets route, the JSON receipt stays beside the rendered result, an optional structure stays closed until the "+ N optional" disclosure opens it, a half-filled one holds the run back, and every tapped control is at least 44 pixels square on a phone. The CLI puts on the wire what it did, since the kernel's payload rules did not change, and its refusal of a value no file input takes now names the input's position; mthds 0.22.0 reports MTHDS standard 7.0.0, which neither template reads, and the SDK's other changes in between reach nothing either calls.

The JavaScript starter, Pipelex/pipelex-starter-js

Added

• A durable run's live timeline under every tab: while a run started in Durable mode goes, its form draws the run's progress with RunTimeline from @pipelex/mthds-ui, a new dependency, one row per pipe the run has reached, nested under the controller that ran it, and keeps it under the result or the error once the run ends; it never decides how a run ends, and no failure to read progress reaches the person. The browser reads it from the app's own GET /api/runs/{runId}/progress route, which reads the snapshot on the server, keeps a provider's raw failure text there, and answers unavailable where the base URL serves no progress, as production does not yet, so the timeline draws today against https://api-dev.pipelex.com and every tab elsewhere shows what it showed before. The view is a handful of files that never import the SDK, documented in docs/run-timeline.md with how to lift them into another app, and make add-method adds the timeline to every form it writes.
• A "Check claims" demo tab: methods/check-claims splits a text into its factual claims, checks each one in a batch and words the verdict through a condition, on a cheap model, so the run timeline has a sequence, a batch's items and a condition's outcome to draw; its tab was scaffolded by make add-method, and e2e/run-timeline.spec.ts drives it live wherever the base URL serves progress.

Changed

• The starter runs on @pipelex/sdk 0.45.0 and @pipelex/mthds-form 0.17.1: bumped from 0.39.0 and 0.10.1, and npm ls mthds now lists one copy, where it listed the form kernel's and the SDK's apart. A result holding an integer past Number.MAX_SAFE_INTEGER now arrives exact rather than rounded, so a generated schema expecting a number refuses it by name; in the result view each file gains its own download button, an HTML result shows as one page with a "Download PDF" control, and the JSON receipt stays beside the rendered result. On the form, an optional structure stays closed until the "+ N optional" disclosure opens it, a half-filled one holds the run back, and every tapped control is at least 44 pixels square on a phone.

The Python starter, Pipelex/pipelex-starter-python

Changed

• The starter runs on pipelex-sdk 0.45.0, with mthds 0.22.0: bumped from 0.39.0 and mthds 0.21.0. mthds 0.22.0 reports MTHDS standard 7.0.0 and Protocol 1.0.0, which nothing in the starter reads, and its other breaking changes sit in the lock, cache and manifest of method packages, which the starter does not use. The SDK's changes in between reach nothing the starter calls.