README section documenting the containerd image store and a troubleshooting checklist for ImagePullBackOff after a deploy.
Changed
The registry auth payload sent during push now includes serveraddress, so Docker Desktop routes credentials to the pinexq registry on every version.
Update build backend uv_build to >=0.12.6,<0.13.0.
Fixed
deploy now aborts when the image push reports an error instead of reporting success. Previously a failed or partial push was swallowed and an unpullable code hash was registered, causing rare ImagePullBackOff failures in Kubernetes.
The registered code hash is now the digest reported for the push and is verified to exist in the registry before it is assigned, instead of a locally derived digest (RepoDigests/image ID) that could name a manifest the registry does not hold.
Security
Update dependency copier to 9.17.2, fixing CVE-2026-53951 (trust-prefix bypass via path traversal that could run template tasks unprompted).
Update dev dependency pytest to 9.1.1, fixing CVE-2025-71176 (unsafe /tmp directory handling).
Read-only list and show commands for six JMA Resources: job, workdata (alias wd), processing-step (alias ps), template, trigger, and folder. Each supports table, JSON, CSV, and quiet (-q) output, --wide, pagination (--limit/--offset/--all), sorting, and per-Resource filters; show accepts a UUID or URL for every noun, name@version for ProcessingSteps, and a /path for Folders. These commands resolve their connection leniently (flag → env → pinexq.toml) and run from any directory.
--help for every read command groups options into Connection / Output / Pagination / Filters panels; the enum filters (--state, --kind, --deployment-state) list their valid values and offer shell tab-completion.
Shell completion is enabled (pinexq --install-completion / --show-completion).
README “Reading Resources” section documenting the new commands.
pinexq job logs <ref> prints the Log entries of a Job, oldest first, following the Job’s Logs link to the monitoring service and paging through the whole log. -o text|raw|json selects the line format (text colours the level on a TTY, JSON is NDJSON), --level, --search, and --tail filter in the CLI, and --no-color (or NO_COLOR) forces plain output.
pinexq job metrics <ref> shows the Metrics of the Worker that ran a Job: a header with status, duration, and peak CPU and memory, followed by terminal plots of both series. -o json and -o csv emit the full series instead.
actions and action on every Resource noun, executing the hypermedia Actions the JMA advertises instead of a hardcoded set. actions <ref> lists what a Resource offers right now with each parameter’s type; action <ref> <name> executes one by name in any spelling. --root targets the Resource type’s creation Actions. Parameters come from --set KEY=VALUE and --json, typed and validated against the Action’s schema before anything is sent, and --dry-run prints the request without sending it.
Bound verbs on every noun, each wrapping exactly one advertised Action with typed flags: job start, delete, hide, unhide, rename, tag, move, set-error, and create; wd delete (with --force for a WorkData whose deletion is not allowed yet), hide, unhide, rename, comment, tag, move, upload, and download; ps deprecate, restore, delete, hide, unhide, rename, tag, move, set-defaults, and clear-defaults; template run, delete, edit, tag --scope, set-params, clear-params, set-input, clear-input, and create; trigger enable, disable, delete, edit, set-templates, set-cron, set-window, and create; folder create, rename, move, delete, and clear.
The multi-reference Bound verbs act on several Resources at once, read references from stdin with - (so job list -q --state failed | job delete - -y works), report a reference that fails and continue with the rest, and exit 1 if any failed.
wd upload <file> creates a WorkData from a local file, guessing the media type from the extension and applying --tag and --folder afterwards; wd download <ref> streams the content to a file, a path, or stdout, and refuses to overwrite without --force.
job create builds a fully configured Job in one request: ProcessingStep, --param values typed against the Function’s own schema, --input WorkData assignments (several per slot assign a collection), tags, a Folder, and --start.
An Action the JMA marks Destructive asks for confirmation before it runs. --yes skips the prompt, and without a terminal the command refuses rather than hanging.
show in table output now ends with the names of the Actions the Resource offers, so the next step is on screen. JSON and CSV output of show are unchanged.
README sections for the Action verbs, every noun’s Bound verbs, job logs, and job metrics.
Changed
The root --help groups the Resource commands under a “Resources” panel, and each noun lists its Bound verbs in a panel of their own.
New runtime dependencies: jsonschema (parameter validation) and plotille (the job metrics plots).
Live contract tests for the ProcessingStep name resolution, run against a real JMA with PINEXQ_LIVE_TESTS=1 uv run pytest -m live (they are skipped otherwise), so a mismatch between what the CLI sends and how the JMA filters is caught (#71).
Fixed
processing-step show <name> and <name>@<version> (and every Bound verb that takes such a reference) reported an existing ProcessingStep as not found. The name lookup sent the JMA’s ShowDeprecated and ShowPrerelease filters as true to include those versions, but the JMA reads true as “only these”, so the two together matched nothing. The lookup now sends no such filter, so deprecated, prerelease, and hidden versions all resolve (#71).
When a pinned version does not exist, the error now says which half failed: no ProcessingStep named <name>, or <name> has no version <version> followed by the versions that do exist (#71).
--hidden on job list, workdata list, and processing-step list, and --deprecated / --prerelease on processing-step list, now include those Resources as documented. They used to return only those Resources, for the same reason. processing-step list also excludes deprecated ProcessingSteps and prerelease versions by default now, as its help text always said.
job start --wait and template run --wait now wait for the resulting Job to reach a terminal state and exit non-zero when it does not complete successfully. --timeout limits the wait while leaving the Job running.
Step-by-step Job composition (#49). job create --name NAME now creates an empty Job to compose, --processing-step keeps the one-shot RapidSetupJob behaviour, and --parent JOB [--inherit-folder] creates a sub-job; a flag the chosen Action has no property for is a usage error before anything is sent.
job select-processing, job configure, job set-input, and job clear-input select a Job’s ProcessingStep, configure its parameters, and assign, source from a folder (--folder PATH [--no-recursive]), or clear the WorkData on one input DataSlot. job configure --param is typed against the Action’s own schema, falling back to the selected ProcessingStep’s parameter schema.
Input DataSlots are addressed by 0-based index or case-insensitive name, on job set-input / clear-input and on the Template verbs, and job show and template show now list the index.
Changed
Actions on sub-entities such as DataSlots stay reachable through the Bound verbs above rather than the generic action command (ADR-0006).
