runner v0.27.0

v0.27.0

Runner v0.27.0 is the cross-repo release of the v0.27.0 milestone. Ordinary runs may now
declare Spec Core 0.3.0 beside 0.2.0-draft, and the declared version chooses the
evaluator (#188). The Runner's durable Gateway contract moves to
Gateway v0.23.0
(#192). A preparation-only selected-profile namespace serves Desk #599 (#191). The
producer of the genuine Core 0.3.0 recording set ships (#174), and its set is published
in the Spec. The Spec's maturity remains draft. This release claims no Extended Runner
support.

What an operator must do

• Run Core 0.3.0 packs with a Runtime that evaluates Core 0.3.0, such as
  Runtime v0.39.0.
  A pack that declares 0.2.0-draft is evaluated as before; nothing is upgraded.
• Expect the new refusals named below if a caller names a selected profile on an
  ordinary route, or sends descriptorProvenance on a non-MCP acquisition.
• The usual care applies before any upgrade: stop Desk and Runner and back up the Jobs
  workspace, including SQLite/WAL, as
  State and backups describes. The store schema is
  unchanged and there is no migration. Selected profiles are kept under a new key of the
  existing metadata table; a store without one opens as before. A store written by
  v0.26.0 opens with no migration: its queued runs run under 0.2.0-draft, its exports
  verify, and re-exporting gives identical bytes.

Core 0.3.0 on ordinary runs (#188)

• Ordinary preview admits packs that declare specVersion 0.3.0 beside
  0.2.0-draft. The declared version selects the evaluator. The manual profile stays on
  0.2.0-draft.
• invalid_pack now names what the pack declares: This runner evaluates packs that declare specVersion 0.2.0-draft or 0.3.0; this pack declares "<v>", or "none" or
  "another version" when the value is empty or longer than 64 characters.
• The Runner holds the Runtime's existing evaluatorSpecVersion member, in run.result
  and in the audit record, to the release pack's declared specVersion. This adds no new
  record member.
• verify-run refuses evaluator-spec-mismatch when either member, where present,
  differs from the declared version. The check comes after the signature checks and
  before the preparation, and the refusal reports alone (exit 1, stderr). It also
  refuses member-name when a run result or audit member equals evaluatorSpecVersion
  except for case. Records made before this release keep their findings.

The selected-profile namespace (#191, #194)

Three preparation-only routes, each behind the exact installed JPack-Conversion-Contract
selector with the roles document-validation, preview, preparation and producer-carrier:

• GET /v1/retained-column/1/selected-profiles
• POST /v1/retained-column/1/selected-profiles: 201 when new, 200 when identical
• POST /v1/retained-column/1/selected-inputs/next

Without the prefix the same paths answer 422 selected_preparation_unselected.
GET /v1/status reports the capability selected-profile-preparation, contract
selected-profile-preparation/1. Its bound is 16 profiles and 81,920 bytes, separate
from the ordinary bound of 16. Planning persists nothing.

New refusal codes:

• selected_profile_unsupported (422), selected_profile_limit (422) and
  selected_profile_conflict (409).
• selected_profile_ordinary: 409 on admission, 422 on selected planning.
• input_profile_selected: 422 on ordinary bindings, planning, preview, import, release,
  job and job upgrade, and on a run's submission whose mapping names a selected profile.
  The submission is refused before the job, its release or the mapping comparison is
  read; an identical retry is answered first. 409 on ordinary registration of a selected
  id.

A selected profile never reaches ordinary evaluation. openapi.json carries the routes
and schemas. The new vector is vectors/selected-profile-preparation.json.

The durable Gateway contract (#192, #194)

The durable Gateway contract moves from Gateway v0.9.1 (5b49e1e) to v0.23.0
(82d4f8a). A receipt's acquisition.descriptorProvenance is accepted as a signed
member on an MCP acquisition, and refused acquisition-invalid on any other. The
Runner's acceptance does not establish the Gateway's own descriptor checks; see
durable sources.

The Core 0.3.0 recording set (#174)

scripts/recording-set.sh OUT and tools/preparation-vectors -core 0.3.0 produce the
genuine Core 0.3.0 recording set. Its manifest gains core, producer, signing,
notFixed, recordings, notRecorded, and recorded on each vector. The set of 46
recordings, made at Runner 275b5ce, is published in the Spec (Spec #281) beside the
unchanged historical set. vectors/preparation here is unchanged.

Verified with

Companion	Commit	Release
Tested Runtime	09206e7	main at runtime #291, contained in v0.38.0
Retained-column Runtime	12793d2	v0.39.0
Earlier Runtime	7a2fcfe	v0.27.1
Durable Gateway contract	82d4f8a	v0.23.0
Old Runner	1cc6b29	test-only

Desk is not pinned by this release; Desk adopts it in its own lane.

Known and not fixed

• A Core evaluation error on a 0.3.0 release under the private workflow host is
  recorded as interrupted, not as an evaluation error. No route reaches that host.
• No test pins that the non-MCP descriptorProvenance refusal comes before the
  signature check; the code is acquisition-invalid either way.
• An MCP descriptorProvenance is accepted in any form once signed by the trusted
  Gateway key; the Gateway's own verifier is stricter.
• CI does not run scripts/recording-set.sh. The published set was checked against this
  commit independently.

Review: the pre-release review of v0.26.0..44f0385 is on this pull request (a Claude
Opus review of a Claude Opus build; not a cross-vendor claim). It found 0 HIGH,
0 MEDIUM and 5 LOW.

runner v0.26.0

v0.26.0

Runner v0.26.0 completes the v0.26.0 milestone. It ships the explicitly selected
retained-column/1 Base consumer for Agent v0.11 that v0.26.0-alpha.1 introduced
(#183), moved from the Spec v0.3.0-rc.2 candidate to the published
Spec v0.3.0.
It also carries the CI headroom change from v0.26.0-alpha.2 (#184), and tests for
#86 and #147. The Spec's maturity remains draft. Ordinary Runner input routes are
unchanged and still evaluate under 0.2.0-draft. This release claims no Extended
Runner support.

What an operator must do

• Re-create alpha-era selected work. Selected releases, runs and exports made by
  v0.26.0-alpha.1 or v0.26.0-alpha.2 under the rc.2 contract cannot be read or
  verified by this release. Re-create them under the final contract. Ordinary
  (0.2.0-draft) releases, runs and exports are unaffected.
• Update callers that name the contract. A caller that selects the rc.2 contract
  is refused capability-unsupported, whether by header, flag or capability report.
  Select retained-column/1 at Spec v0.3.0@27cb29bf13e4a2d58d69fe19c7ebfeb762b014fc.
• The usual care applies before any upgrade: stop Desk and Runner and back up the Jobs
  workspace, including SQLite/WAL, as
  State and backups describes. The store schema
  is unchanged and there is no migration.

The installed contract

The installed selection moves from 0.3.0-rc.2@bcac15b7 to Spec
v0.3.0@27cb29bf13e4a2d58d69fe19c7ebfeb762b014fc. Schema
sha256:0cb49f238c78391cb163a65474cc9af962df2bb1024a55c5310c2b784b2f0557 and corpus
sha256:17b16ff7a9b74fe4cc81eb6f6129a6aabdd9834621d9e756aa2d4c1a3f245863 are
byte-identical to rc.2's. The leaf fixtures, release identity and inventory (file
sha256 c8e489b2cabd0ee0b794a8b6a817f06f901e338348e32ec23c8c83d7c40dfe58) come from
the verified v0.3.0 archive. /v1/health conversionContracts and
verify-preparation report the new tuple. A new public vector,
vectors/retained-column-selection-v0.3.0.json, sits beside the rc.2 vector, which is
kept as history.

The selected route admits Runtime's Core 0.3.0 Base evaluator. CI's retained
companion Runtime moves to v0.39.0 (12793d2d). The other Runtime, Gateway and
old-Runner pins do not move.

Dialect document checks (#86)

CI now holds the Runner's dialect reader to the Runtime v0.39.0 document tools.
Both sides give the same canonical bytes and digest on 47 shared vectors, and both
refuse 5 malformed documents. The Runtime's document tools are pinned to Spec
b7cc8906, not v0.3.0. This check therefore shows agreement with that revision
and makes no claim about the dialect page at v0.3.0. The Runner keeps its own
reader and calls no Runtime tool at run time; see
the design note. There is no production
change.

Governed dispatch admission (#147)

Acceptance tests cover the remaining cases of #147 against the real Runtime:

• omitted-dependency substitution;
• withdrawal, enqueue and dispatch orderings;
• a lost admission response;
• worker restart and fencing;
• identity revocation;
• restore from before a withdrawal.

There are 6 cases with 21 subtests. The orderings are scripted interleavings. No case
revealed a missing mechanic, so there is no production change. The fence is described
in the names of the agent's ADR-0025, {resource, owner, epoch}, in
the admission gate design. An epoch is accepted
only as a canonical decimal string, and a JSON number is refused. The Runner accepts
epochs up to 2^64−1, a superset of ADR-0025's 18-digit bound.

Not in this release

The genuine 0.3.0 dialect recording set (#174) needs ordinary Core 0.3.0
admission first, and that is tracked as #188. Both are in v0.28.0.

Also

docs/releasing.md names the two prerelease forms the development kit's policy
defines. -rc.N is a candidate of the complete milestone. -alpha.N is a scoped
cut for a named consumer that never graduates.

Review: the pre-release review of #187 and of v0.25.0.. is on #187 (a Claude Opus
review of a Claude Opus build; not a cross-vendor claim).

runner v0.26.0-alpha.2

v0.26.0-alpha.2

Runner v0.26.0-alpha.2 adds the explicitly selected retained-column/1
Base consumer for Agent v0.11. It uses the published Spec v0.3.0-rc.2
contract at bcac15b7537ce21879201b5e5dfe795496225121. The Spec's maturity
remains draft. This prerelease does not change ordinary Runner input routes
or claim Extended Runner support.

Selected retained columns

Authenticated retained-column routes require an exact installed contract selector
before reading the request body. The selector remains bound through preparation,
release/run persistence, restart and offline verification. It cannot install a
new trusted profile, producer, expected Spec identity or signing authority.

All five conversions and eight research types retain their original raw values,
complete original declaration inventory and provenance. Base limits apply to
complete artifacts; lower trusted capability limits remain effective. Existing
independent depth, numeric, count and binding-document bounds remain in force.
Converted basis pointers are distinct and sorted; selected lineage follows the
contract's fact-then-evidence order. Generated frames in CASE context refuse.

The selected route additionally admits Runtime's existing Core 0.3.0 Base
evaluator. Selected and ordinary 0.2.0-draft remain supported. Evaluation and
replay must report the evaluator version from the same retained release pack;
unknown or mismatched reports refuse. Manual and workflow paths are unchanged.
See the contract and transport details.

Offline verify-preparation --capabilities now declares interface version 2 and
report capability version 2 for the explicit selected contract and its additional
selection/profile refusal codes. Discovery remains a sole-flag operation. Ordinary
verification bounds, report members, exit statuses and canonical findings remain
unchanged; selected verification requires an exact --conversion-contract.

Operator and producer scope

Use an explicitly compatible Runtime and separately approved producer profile
for selected generated inputs. Ordinary inputs keep their existing configuration.
The usual upgrade backup and workspace care in
State and backups still applies.

The selected consumer checks original snapshot/frame consistency, the exact
producer tuple, signature, request commitment and freshness. The future Desk
adapter must independently implement original-history inventory validation and
its grant/stdout bounds. Runner's signed test producer and preparation-only
synthetic corpus do not establish that Desk cutover or producer compliance.

Validation and publication gates

Selected interoperability uses published Runtime
v0.39.0-alpha.2,
commit 57c854abb9ace8a91013a75ab688bd70d063797c. CI pins this companion
separately from historical ordinary and earlier Runtimes, and requires both
selected Core 0.2 and Core 0.3 lifecycle tests to run and pass. These tests cover
SQLite first-save/restart, signed preparation binding, exports 2/3/4/5 and offline replay.
Published synthetic fixtures cover their applicable conversion, capability,
producer-consistency and preparation owners; partial synthetic exports do not
establish full release/chain/sidecar authenticity.

Release qualification requires the stable Runner checklist, exact-head CI and
independent review. Tag-time evidence, archive smoke, checksums, attestations and
publication verification follow the release procedure.
No Windows archive is released.

CI budget correction and release status

The Runner CI jobs now have a bounded 60-minute execution budget. The sequential
unit check keeps its existing 3000-second aggregate limit, and every race-test
invocation keeps Go's default 600-second package timeout. Test selections,
40 MiB boundary fixtures, refusal assertions and release evidence requirements
are unchanged. The larger outer budget provides headroom for the observed
sequential workload; it does not guarantee execution time.

The signed annotated v0.26.0-alpha.1 tag remains unchanged and has no published
release. Its release attempt refused CI evidence because the Linux runner
identity differed; the fresh main CI attempt then reached the macOS job's
25-minute execution limit before completing its checks and evidence capture.
The cancellation establishes the outer timeout; it does not diagnose a product failure.
This correction requires a new version and tag; v0.26.0-alpha.1 is not moved or reused.

Publication of v0.26.0-alpha.2 requires independent review and
complete exact-commit main CI evidence from one successful attempt, followed by
the normal tag-time evidence admission, archive and publication gates. Earlier
green jobs and jobs from different attempts cannot be combined to qualify it.

runner v0.25.0

Runner v0.25.0 puts the Runner's durable state behind a store interface, with the
SQLite store as the shipped kind, an in-memory kind for tests and a conformance
suite that both kinds pass. It also carries the development-kit adoption rows,
the Idempotency-Key boundary tests and the wording change that dropped the
research-preview label. These changes cover the eleven source commits since
published v0.24.0 (#163–#169, #171, #176–#179). Nothing about the SQLite
store's files, statements, schema or lock changed.

What an operator must do

• Nothing new. The boot line's dir is consumed by the SQLite kind only and
  still names the Runner's working directory for Runtime files (releases,
  attempts, runtimes). No other kind can be selected from the boot line.
• The usual care applies before any upgrade: stop Desk and Runner and back up the
  Jobs workspace, including SQLite/WAL, as
  State and backups describes. A store this
  version opens is the same schema the previous version wrote; there is no
  migration.
• Two behaviours are stated rather than changed: a claim of a run, and an end of
  a run at queue time, now require the run to still be queued (with one
  dispatcher under the lock this never refuses), and Close releases the attempts
  directory before the store, with the process lock still released last.

The store behind an interface (#173)

The queue, releases, inputs and run records are reached through one interface in
the Runner's store package: reads (release, job, requested run, entry sequence,
run, oldest queued, entry line, chain page) and writes that go through one
serializable transaction (active runs, create run once per id and per request
key, put run against its expected state, running runs, last entry, create entry,
create release, append journal). Faults are typed: absent, taken, conflict,
durability, unreadable, refused; an error keeps its cause's text. The SQLite kind
is the previous code moved: the same twenty-three statements, a byte-identical
pragma and schema block, the same transactions, opening order, WAL mode and
exclusive process lock. The in-memory kind holds the same semantics for tests.
The conformance suite runs against both kinds: a release created once; a run
queued once by id and by request key; queue order; a queued run claimed once with
a stale claim refused; concurrent producers and claimers retrying on conflict;
a failed transaction keeping nothing; a failed commit reported as a durability
fault; one chain entry per run read in order; absent and unreadable typing; and,
for SQLite only, a reopened store holding what it held and a second process
refused by the lock. The unit-test step fails unless both kinds passed. See
the store interface. Triggers, occurrences, job
creation and revision, briefs, workflows, manual admission, metadata, the
listings and the journal's reads stay on the SQLite handle; the design note lists
each.

Development kit and tests (#163–#169, #176–#178)

The repository runs the development kit's vendored checks (scripts/dev/check.sh
at kit v0.9.0 with the changed-path selection); a pull request runs the checks
its changed paths map to and a push to main runs the whole list, which alone is
release evidence. The Idempotency-Key ASCII and length boundaries are covered by
tests (#168). The README and the security policy no longer call the Runner a
research preview (#171).

Source evidence and pending release gates

• Runner native Linux/macOS CI
  40363510184
  passed at 387b8b2b93e6b699ceea009323ccd645d166da5d (the reviewed store-interface change
  on top of main), including the release-contents job. The review record and
  its disposition table are on
  pull request #179: no HIGH or MEDIUM
  finding; the two stated behaviours above were traced as unobservable today;
  the twenty-three statements, the schema block and the transaction boundaries
  were compared on both sides; probes on both kinds (duplicate ids and request
  keys, stale claims, racing claimers, a real commit failure, a killed holder of
  a claimed run, chain order) and sixteen mutants all held.
• The push-triggered whole-list run on main at the merge commit is the
  evidence the release takes.

Tag-time CI, the packaged archives, checksums, attestations, native archive smoke
and draft/publication verification for v0.25.0 remain pending under
the release procedure. No Windows archive is released.

runner v0.24.0

Runner v0.24.0 adds startup capability negotiation, external executor ownership,
exact operational payload commitments and an explicitly enrolled experimental
manual Pack admission profile. Runner remains a single-owner local Jobs research
preview. These changes cover all four source commits since published v0.23.0
(#158–#161); they do not adopt a portable Policy standard.

What an operator must do

• Installing this version alone does not enroll a workspace. Published Desk still
  pins Runner v0.23.0 and Runtime v0.34.0; coordinated companion adoption and
  installed activation remain pending. A successful capability probe grants no
  permission. A supporting trusted host must explicitly enroll the entire
  workspace in local-admin-manual-pack/1, retain its independent ownership and
  Policy authority, and require matching capabilities in the actual boot.
• Before enrollment, stop Desk and Runner and back up the entire Jobs workspace,
  including SQLite/WAL, runtimes, releases and attempts, as
  State and backups describes. Desk chat
  backups do not include Jobs. Keep the external trusted enrollment and authority
  separate from portable Jobs copies; a copied store or backup is not authority.
• Enrollment requires explicit offline prepare-manual-store under the host's
  continuously held external exclusive lease. It accepts only an untouched
  schema-3 store with no triggers (even paused), queued/running work or pending
  acquisition/occurrences, then durably publishes its marker and schema 4.
  Ordinary enabled Open refuses older/restored schemas; it does not migrate
  them. The earlier ownership-era Runner was tested to refuse schema 4. There is
  no supported in-place downgrade or automatic undo of enrollment: a pre-enrollment
  backup alone does not clear the independently retained execution demand.
• A refusal, partial preparation or lost reply can follow durable changes. Only
  the original fresh committed preparation response can advance activation;
  a recovered observation cannot. Hold the workspace for explicit reviewed
  reconciliation rather than retrying automatically or stripping markers/demands.
• The enrolled workspace permits only immutable, registered, manual single-Pack
  jobs. Triggers, acquisition/provider operations, workflows, prepared or mapped
  inputs, input-profile installation and job upgrades are held across the entire
  workspace, including legacy resources. Choose a workspace compatible with this
  scope before enrolling it.

Exact operational payloads (#158)

The private judgment-pack-runner/execution-payload/1 descriptor commits the
existing frozen Release identity, exact Pack/configuration/lock and facts bytes,
evidence presence and bytes, typed preparation/SourceInput commitments and actual
operational signing mode/public key. It does not change legacy release digests or
invent a portable Policy canonical encoding. Raw facts and evidence retain number
spelling and whitespace. The codec alone interprets no Policy and grants no
execution permission; the manual gate uses its commitment at the actual starter.
See the payload contract.

Probe and ownership before startup (#159–#160)

The trusted host probes the exact executable using
jpack-runner capabilities --format json before sending boot authority, pins
that executable through launch, and repeats its requirements in the boot object.
Closed version 3 on supported admission hosts lists only the manual profile
alongside jobs/1, required boot capabilities and executor-ownership/1.
Unsupported hosts retain the closed ownership-only version-2 response; unknown
shapes or missing requirements must hold startup.

With explicit ownership configured, Runner acquires the existing independently
pinned external exclusive lease before portable state, recovery, providers or
workers. Every Service Runtime invocation, including utility checks, inherits
that ownership through the actual child lifetime. Closing or killing the parent
does not release it while an inheriting Runtime remains alive. A failed or stopped
configured service cannot fall back to unowned execution. The supported boundary
is cooperative exclusion on suitable local filesystems, described in
executor ownership.

Anchored local manual admission (#161)

local-admin-manual-pack/1 is a private experimental host contract. Its capability
response is support information, not authority or normative Policy conformance.
RFC 0023 remains Review and unadopted; Runtime prototype 0.0.2 and its explicit
proposed-draft candidate 1.0.0 remain distinct offline formats.

The same independently anchored Desk Policy authority governs registration,
current eligibility, intent, reservation and start commitment. Runner checks
matching external, store and boot demands, holds actual ownership, fixes signing
and activates a fresh authenticated session before recovery or workers. The
owner-only execution-binding export grants no registration or launch authority.

Manual admission preserves the original Idempotency-Key and exact original
request body, facts and optional evidence. Reusing the key with even a changed
outer whitespace body conflicts. The existing payload descriptor, exact resource
and registration bind reserve and commitStart. Actual files, Runtime, signing,
job/release tuple and custody are checked before commitment and again at the
common operational starter. Only an original fresh successful start reply,
durably journaled locally, can mint one in-memory launch consumed once through
the ownership-aware starter. No private workflow or alternate evaluator path can
substitute an ordinary utility call for that permit.

Withdrawal committed first blocks the start. A start committed first is the
irrevocable logical start: its physical process may spawn after a later
withdrawal. There is no atomic ledger/OS transaction. Lost reserve/start replies,
recovered receipts or history, uncertain outcomes and restart recovery never
authorize a launch or automatic replay. This does not resist hostile code under
the same OS user, an administrator, or rollback/replacement of the entire trusted
plane. See the manual gate and
offline preparation contract.

Source evidence and pending release gates

Existing reviewed source evidence is reused for this documentation-only release
preparation:

• Runner native Linux/macOS CI
  39270753757
  passed at d903728fb38368a5f0574990e01bc27acb2a2803. Its normal real-Runtime
  suite pins Runtime 09206e743cdf410d7b5ee970f1c9d09ca7c015ca (included in
  published v0.34.0), plus earlier signing Runtime v0.27.1 at
  7a2fcfe20cedba5f164246fc544c4920971d2c56; Gateway is v0.9.1 at
  5b49e1e094b55fdd1deb9f613815c2beebd411f1. The old-Runner schema-refusal
  fixture pins 1cc6b29885b344716a970cd21fefeaca0a4edaeb.
• Combined actual Desk/Runner/Runtime source acceptance passed all seven required
  manual checks in Desk CI
  39275718610,
  using reviewed Desk 2ff3773a55b61c84317474fd80753f933c04ec5d (merged as
  c4e6ef5c6170e7d134c8c3960adc7a9c909bc2bb with the same tree), Runner
  d903728fb38368a5f0574990e01bc27acb2a2803 and Runtime
  55a23b884f0ce67fe6a9141b04e081a518fd5d61. They cover exact registered
  input/withdrawal-first, commitment-first, lost-start and lost-reserve replies,
  actual MCP refusal when Jobs is unavailable, and the actual old-Desk registry
  rollback fence. These are source-fixture results, not installed archive tests.
• The Runtime release source 0554c43d2bea08e06b9a1e7be39834494ee29d5e has
  the same tree as that tested Runtime and passed main CI
  39165392059.
  Runtime v0.35.0 remains a held unpublished draft at
  515724946fe83e7db800b4281e74d5daf06524fa; it is not the tested candidate.

Tag-time CI, four packaged archives, checksums, attestations, native archive smoke
and draft/publication verification for v0.24.0 remain pending under
the release procedure. No Windows archive is released; the
darwin/amd64 archive is read but not run by release checks, and no release check
starts jpack-google-relay. Coordinated Desk pins and acceptance against exact
attested companion archives are still required before installed enablement.

runner v0.23.0

Runner v0.23.0: a stored profile the current form refuses no longer stops the store from opening; it is set aside, kept byte for byte, reported, and never bound. Set-level failures and configured profiles still refuse to start.

What an operator must do

• Nothing, unless v0.22.0 refused to open your store (registered input profile "<id>" is refused: …). Upgrade: the store opens, and the named profile is set aside. Every other registered profile works as before.
• What you then see. One line per set-aside profile on standard error at start (runner: the registered input profile "<id>" is set aside, kept and never bound: <reason>), and the profile in GET /v1/input-profiles with "state": "set-aside" and its reason. Any job, run, preview, import or trigger that names it is refused as 422 input_profile_set_aside, naming the profile. A run queued before the upgrade ends failed without starting, with reason profile-set-aside. The profile's id stays taken, and it still counts toward the bound of 16.
• To move a job on, upgrade it to a release that does not name the profile. Cancel its occurrences left needs-attention and pause its triggers first, as any upgrade requires. The job's earlier runs and exports stay served; verify-run given that profile still reads them as input-malformed.
• A Gateway connection configured for a set-aside profile refuses to start, naming the profile. Remove it or point it at another profile; the connection comes from the installation's own configuration.
• Configured profiles are unchanged. One the form refuses still refuses to start (configured input profile "<id>" is refused: …); edit the configuration.
• Under the Desk, you see neither signal until a binding is refused: the Desk reads the listing's entries as ordinary profiles until judgment-pack-desk#480 lands.

A stored profile the form refuses is set aside (#156, closes #154)

• At open, a registered profile that admission refuses on its own is set aside: kept, reported, never bound. The others load. Set-level failures still refuse to open the store: a row over its storage bound, unreadable, or holding an element that is not a profile in its exact form (null and {} included); more than 16 stored profiles, or more than 16 with the configured ones; an id stored twice; a stored profile with the id of a configured profile of another definition.
• A set-aside profile's stored bytes never change. A registration rewrites the row from the stored bytes, in order, with the new profile appended; registering the set-aside id again is 409 input_profile_conflict; a registration that would push the row past its storage bound is 422 input_profile_limit.
• GET /v1/input-profiles lists each set-aside profile after the installed ones, with its digest, state and reason; the items are oneOf InstalledInputProfile and the new SetAsideInputProfile, and installations with no set-aside profile get unchanged bytes. The run's reason enum gains profile-set-aside, and the error input_profile_set_aside is documented.
• Wherever the Runner resolves the installation's profiles, every id the input names is checked first: input and release previews, /v1/inputs/next, occurrence preparation, background acquisition, trigger readiness, Gateway mappings, job creation and upgrade, and run submission. Repeating the creation of a job made before the upgrade returns the job, and an identical retry of a mapping run keeps its original acceptance; an identical retry of an import run is refused.
• The offline verifier is unchanged: verify-run --profiles and verify-preparation still read a refused profile as input-malformed, as the specification does.

Verification

CI ran formatting, vet, the race tests and the real-Runtime integration tests on Linux and macOS at the pull request's head and again at the tag, against Runtime 09206e7 (released as v0.34.0).

• #156: one clean-room round by Claude Opus over a Claude Opus build, recorded on the pull request; the same vendor at the maintainer's direction while the OpenAI reviewer was unavailable, so not a cross-vendor review. It found no way to bind a set-aside profile on any production path and confirmed the stored bytes survive a registration and a reopen. Its three MEDIUM and three LOW findings were all fixed before merge: two surviving mutants (the row rewritten through a struct; the registration bound check removed) each got a test; a null or {} row element now refuses to open the store; job creation stays idempotent across the upgrade; a dead workflow method was dropped; words. Mutation checks: the builder's nineteen and four on the fixes, each caught; the coordinator reproduced the row-element one.

See releasing for how a download is verified.

runner v0.22.0

Runner v0.22.0: a profile's endpoint scope follows RFC 0018 round 16, refusing escaped slashes and backslashes and dot segments carrying parameters in a scoped page path; a refused stored profile is named when it stops the store from opening; a private offline consistency reader for retained draft workflows lands without any exposed surface.

What an operator must do

• Nothing for exact or unscoped profiles. Their check is unchanged, and every published vector is byte-identical to v0.21.0's.
• If you registered or configured a scoped page profile under v0.21.0, check each endpointScope entry first. An entry v0.21.0 admitted that now carries an escaped slash or backslash (%2f, %2F, %5c, %5C), or a segment whose part before its first ;, %3b, %3f, %23 or %00 is a dot segment, is input-malformed, and the Runner refuses to open its store, naming the profile (registered input profile "<id>" is refused: …). Registrations are immutable; how to recover such a store is open as #154. A page whose path carries an escaped slash can still be read under an exact-endpoint profile naming that URL.
• If you acquire pages for a research source under a scope, hold every requested URL to round 16's form before sending it; a receipt outside it is refused at verification.

Round 16's page path form (#153, closes #152)

• A scoped page path carries no escaped slash or backslash anywhere, and no segment's part before its first ;, %3b, %3B, %3f, %3F, %23 or %00, whichever comes first, is a dot segment; nothing is decoded. One form serves scope entries on the live and offline paths and check 3 on each receipt, as RFC 0018 §5.1 at judgment-pack-spec 4bec33a states it.
• The Runner and the specification's Python reader answer all 152 of the specification's endpoint-scope controls, round 15's and round 16's, byte for byte alike; a Runner built from v0.21.0 differs on exactly the 46 new refusals.
• A configured or registered profile the form refuses now stops the store from opening with the profile's id and its refusal, where the error named nothing.

A private offline reader for retained draft workflows (#144, part of #121)

• Checks a retained draft RFC 0020 workflow bundle's consistency across the whole current branch against independently supplied workflow, execution and Runtime pins and historical profiles. Private: no API, command or conformance claim. A cross-vendor audit after its merge (recorded on #144) found most of its consistency checks untested and two rules in tension; those are open as #148–#151 and judgment-pack-spec#213.

Also

• v0.21.0's notes no longer say the Desk checks page URLs before acquiring (#145); the published v0.21.0 release page was corrected the same way.

Verification

CI ran formatting, vet, the race tests and the real-Runtime integration tests on Linux and macOS at each pull request's head and again at the tag, against Runtime 09206e7 (released as v0.34.0).

• #153: one clean-room round by Claude Opus over a Claude Opus build, recorded on the pull request; the same vendor at the maintainer's direction while the OpenAI reviewer was unavailable, so not a cross-vendor review. It checked 204 probes of its own and 450,000 random cases against the specification's reader with no disagreement; its one MEDIUM, a stored profile stopping the store from opening with no name, was fixed before merge. Mutation checks: the escaped-slash refusal, the delimiter split, splitting at the last delimiter, the backslash case and hex case folding each removed and caught.
• #144: a same-vendor clean-room round by an OpenAI model at the maintainer's request, and a cross-vendor audit by Claude after the merge, both recorded on the pull request.

See releasing for how a download is verified.

runner v0.21.0

Runner v0.21.0: an input profile may hold its page receipts to an endpoint scope instead of one exact endpoint (RFC 0018 round 15), so one reviewed page profile verifies a research source's reads of more than one URL; verify-run names profile-mismatch when a release's frozen profile is not among the profiles it is given.

What an operator must do

• Nothing for existing profiles and runs. A profile without endpointScope keeps its form, its digest and its exact endpoint check; exports, the journal and the forty-one earlier vectors are byte-identical.
• To let one page profile verify several URLs, register it with endpoint null and endpointScope, an array of 1 to 32 prefixes in the constrained page form (https://, a DNS name, nothing, :443 or : for the port, an optional path), or https://* on a profile of class generated. The profile must be of shape http with the adapter adapter-web, and a generated one declares research with the capability page alone. It binds to a research source's page assignment; bound to an operation or a selected file it is profile-mismatch.
• If you acquire pages for a research source, hold every requested URL, discovered ones included, to the scope before sending it, as docs/MAPPING-V2.md ("Admission before acquisition is the caller's") states; the Runner itself sends no page request, and refuses a receipt outside the scope at verification. (These notes first said the Desk already does so; it does not yet, judgment-pack-desk#423.)
• If you read verify-run's refusal of a release whose frozen profile is not among those given, it now ends "(profile-mismatch). No decision was requested." as other coded refusals do; the exit code is unchanged.

An endpoint scope (#142, closes #141)

• endpointScope is admitted on every path that takes profiles (start, POST /v1/input-profiles, verify-run --profiles, and the offline verify-preparation, digested over canon bytes), with RFC 0018 §5.1's refusals: input-over-bound for its bounds, counted first; input-malformed for its form, the shape and adapter, a non-null endpoint, or the wildcard on a record profile.
• Check 3 under a scope: the receipt's acquisition.endpoint, the final URL after followed redirects with its query removed, must be in the constrained form and match an entry (hosts equal with ASCII case folded, the three spellings of port 443 equal, the path a prefix at a literal / boundary, no decoding). Without a scope the comparison is byte for byte as before. One matcher, written from the text, serves every path.
• Six new preparation vectors record judgment-pack-spec#199's evidence over synthetic pages a stand-in served: two paths of one origin and two origins under the wildcard, read and verified; an endpoint outside the scope, a redirect target outside it and a changed request, each acquisition-invalid; a changed scope, profile-mismatch. The specification stages them (judgment-pack-spec#208).

Verification

CI ran formatting, vet, the race tests and the real-Runtime integration tests on Linux and macOS at the pull request's head and again at the tag, against Runtime 09206e7 (released as v0.34.0).

• Agreement: the specification's Python reader answers the six vectors and all 100 of its endpoint-scope probes exactly as verify-preparation does.
• Mutation checks: the scope match, the segment boundary, the wildcard's class rule and the empty-port spelling each removed and caught.
• Review: one clean-room round by Claude Opus over a Claude Opus build, recorded on the pull request; the same vendor at the maintainer's direction while the OpenAI reviewer was unavailable, so not a cross-vendor review. One MEDIUM (the uncoded verify-run refusal above) and three LOW, all fixed before merge.

See releasing for how a download is verified.

runner v0.20.0

Runner v0.20.0: verify-run keeps the preparation's checked report beside an audit-disposition finding; a record delivery at a full queue is refused for retry instead of recorded as skipped, and the record-delivery contract a desk's collections rely on is written down and held by tests; every release is pinned to declare its audit directory; the private draft-workflow layer gains its inventory, attempt custody and source checkpoints, still without any exposed surface.

What an operator must do

• Nothing for existing runs. Exports, the journal and every published vector are unchanged; all forty-one vectors recompute byte for byte. One vector's expected verify-run report changes, as the next point says.
• If you read verify-run's report on an audit-disposition-mismatch, it now carries the members a verified export's report has (binding, exactBytes, exportVersion, scope, targetsByClass, and unsignedFreshness, unsignedParameters, runChain, signature and recordDigest where the export has them) beside retainedDisposition; the status, exit code 1, the error text and the refusal flags are unchanged. Where the preparation fails its own verification too, the report is the finding alone and the error carries both refusals.
• If your outbox delivers record revisions to POST /v1/triggers/{trigger}/deliveries, a delivery made while one hundred occurrences are pending is now refused with 429 queue_full, retryable, and nothing is admitted; deliver the same bytes again later. v0.19.0 admitted it as skipped, and because the event's identity is the revision's, that revision could never run afterwards. Deliveries through a credential to /v1/triggers/{trigger}/events are still recorded as skipped at a full queue, as that route documents.

The disposition finding keeps its checked report (#137, closes #69)

• verify-run verifies the preparation independently of the retained disposition, so a changed run.result.disposition no longer hides the freshness, binding and chain checks the release notes of v0.9.0 promise on every such export; nothing unverified is reported as verified. Before the preparation is verified, only the export's envelope, the release digest and the record's signature can refuse alone. docs/MAPPING-V2.md and --help give both report forms. The disposition-differs-from-audit vector's expected report is the new one; the generator reproduces the manifest byte for byte. The specification stages the same text (judgment-pack-spec#206).

The record-delivery contract (#139, closes #70)

• docs/design/record-delivery.md states how caller-owned eligibility, the reviewed mapping, the include-existing choice and the outbox use the existing event API: a record and revision identity, a fixed release binding, the same envelope returning the same occurrence, a changed payload refused as event_conflict, durable queue, overlap and restart recovery, reconciliation of an acknowledged or uncertain delivery through GET /v1/triggers/{trigger}/deliveries/{event} without a second run, and inputs frozen at admission. Eight of those clauses were already held by the code; eleven tests now hold each, a signed acquisition carried by a delivery among them, checked under the one receipt rule with no request to a Gateway. The ninth, the full queue, needed the refusal above.

Every release declares its audit directory (#138, for #68)

• Two tests pin that the configuration POST /v1/previews writes for a release declares audit.dir, and that the pinned Runtime takes a cited run of it, so the Runtime's refusal of --cites in a project that keeps no trail (its ADR-0051) cannot be reached through the Runner. docs/MAPPING-V2.md says why. Issue #68 is closed as unreachable while that holds.

The private draft-workflow layer (#134, #135, #136, part of #121)

• A reviewed selection reserves every direct consumer's child in one transaction, repeatable and refused when changed; an interrupted attempt keeps its answers and artifacts, with explicit retries and restart recovery that never acquires again; a one-attempt driver checkpoints each acquired source and the prepared input before evaluation, through the existing Gateway acquisition protocol and the pinned Runtime. No API, command or executor is exposed, and the workflow tables are created only by the private store, which no exposed path opens; existing runs are unchanged. No RFC 0020 conformance is claimed.

Verification

CI ran formatting, vet, the race tests and the real-Runtime integration tests on Linux and macOS at each pull request's head and again at the tag, against Runtime 09206e7 (released as v0.34.0).

• Mutation checks: #137's independent verification removed fails five tests, the vector among them; #139 nine of nine caught, three reproduced by the reviewer; #138 the audit member dropped fails both tests.
• Review: #137 and #139 one cross-vendor clean-room round each (OpenAI model over an Anthropic drafter, recorded on the pull requests). #137: one HIGH (a chain-agreement sentence printed after a failed chain check) and three MEDIUM, all fixed. #139: no finding; the two loopback tests the reviewer's sandbox could not run were run by the maintainer at the same head. #138 changes tests and one sentence and had no round. The draft-workflow slices (#134, #135, #136): one clean-room round each by an OpenAI model, the same vendor as the drafter at the maintainer's explicit request, recorded on the pull requests.

See releasing for how a download is verified.

runner v0.19.0

Runner v0.19.0: the offline verify-preparation command holds the profiles it is given to the dialect companion's §5.1 and digests them as given, so it agrees with the specification's reader on every probe; a local-file source may declare source parameters on the live path, as §3 and §4 admit; a private foundation for draft workflows lands without any exposed surface.

What an operator must do

• Nothing for existing runs. Exports, the journal, verify-run's report, its exit codes and refusal flags are byte-identical to v0.18.0's for every existing run; all forty-one published vectors recompute byte for byte. The installation's own profiles keep the Runner's admission and digest; a release's frozen profile digests still match.
• If a dialect gives a local file a source parameter, it is now admitted: the parameter is held to the same rule as any source parameter (an exact fact target of an earlier source), its value is carried into the outcome's parameters and the lineage's dependencies, and a parameter with no value skips the source as for any kind; a profile, maxAge or arguments on a local file are still refused.
• If a fixture's profile carries tools: [], or an unused profile's id is not a flat token, verify-preparation now reads it as the specification does, digesting the profile's canon bytes as written.

The offline verifier's profiles (#129, closing #124)

• Offline, each supplied profile is digested over its canon bytes (§1, §5.1) instead of the Runner's re-encoding, and held to §5.1's member table and §12's bounds: exact members with null only for endpoint, a non-empty distinct id, the key rule, the class and shape values, the closed adapter with a digest, distinct non-empty tools required for mcp, the calculator's form, the research declaration's form, the research maxima counted before forms; the Runner's own installation limits (the profile count, bytes per profile, the id's token form, the source, authority, adapter, endpoint and tool bounds) apply on live paths only.
• Agreement with the specification's Python reader: 68 of 68 vector calls, 11 of 11 Exchange fixtures, 108 of 108 of the review probes on #119, 56 of 56 new profile probes.

A local file's source parameters (#128, closing #126)

• The shared validator no longer refuses parameters on a local-file source; §3 and §4's table make parameters an optional member of every source, and §4.2 excludes only a profile, maxAge and a request. The parameter goes through the shared source-parameter rules, can reach a rule's derivation and never the file's identity or bytes; the message for the four refused members is narrowed to them.

A private foundation for draft workflows (#130, #132, #133)

• The private document, projection and selection checks a draft RFC 0020 workflow will need, built in a series of slices of #121: cases keep their missing, null, false, zero and -0 distinctions; output extraction tells an explicit empty result from a failure; a selection binds the whole offered envelope set and refuses reordered or repeated membership; inherited influence is preserved across stages; a stage's identities are frozen before acquisition. No API or command is exposed, and no workflow is executed; existing runs are unchanged.

Verification

CI ran formatting, vet, the race tests and the real-Runtime integration tests on Linux and macOS at each pull request's head and again at the tag, against Runtime 09206e7 (released as v0.34.0).

• Review: one cross-vendor clean-room round each (OpenAI model over an Anthropic drafter, recorded on the pull requests): #129 no finding, at high effort; #128 no blocking finding, one LOW on the specification's wording filed as judgment-pack-spec#200. The draft-workflow series (#130, #132, #133): one clean-room round each (OpenAI model, same vendor as the drafter at the maintainer's explicit request, recorded on the pull requests).

See releasing for how a download is verified.