Conductor Runner 0.0.1-beta.13

Runner beta release

Version: 0.0.1-beta.13. Tag: v0.0.1-beta.13.
Public repository: https://github.com/ConductorCI/runner.

Beta.13 applies the step deadline to native artifact/report transfers, task package
downloads and upload-slot waits. A transfer stopped by its deadline fails as a step
timeout. It also batches backlogged task logs when the matching application
advertises taskLogBatch, with single-record fallback for older API instances.
Delivery continues while acknowledgements make progress, bounded by a 15-second
stall window and a ten-minute closing drain. Remote delivery gaps retain the
observed task result and report log_delivery_incomplete; capture, quota, storage
and ownership failures keep their existing failure behavior. See
task log boundaries and
the execution contract.

The companion application already implements the optional batch route, per-record
ingestion permits and manifest capability. Manifest v6, execution-v2, portable
bundle schema 2, Go 1.26.10, Node 24.18.0 and compatible beta.4 built-in task
minimums remain unchanged. Existing beta tags and assets remain immutable.
Canonical runner validation and a clean six-platform distribution are required
before publication; full application stress acceptance and VM image/catalog
approval remain separate evidence boundaries.

Previous beta.12 release

Version: 0.0.1-beta.12. Tag: v0.0.1-beta.12.
Public repository: https://github.com/ConductorCI/runner.

Beta.12 recovers a retired runner session without restarting the worker. It stops
the abandoned attempts, waits for their task trees to settle, creates a fresh
session, and resumes polling. Stale replies cannot change the replacement session.
Recovery fails closed if abandoned work cannot drain or session losses repeat
within five minutes. See the recovery design
and the validation record.

Manifest v6, execution-v2, portable bundle schema 2, Go 1.26.10, Node 24.18.0 and
the compatible beta.4 built-in task minimums remain unchanged. No server wire
change is required. Keep beta.1 through beta.11 tags and assets immutable.

Known beta.12 limitations

The October 29 operator decision permits deferring these existing reliability
findings for this beta. A single user can encounter them under slow I/O; they are
not limited to a large fleet. They remain open regression requirements in the
companion application's complex-pipeline tracker (opus:R-01 and astra:R17).

• Native artifact upload/download steps do not enforce the per-step deadline.
  A 100-second delayed upload response can succeed despite a one-minute step
  limit. Set a finite job-level timeout and allow enough time for artifact
  transfer; job cancellation/abort still governs the transfer request.
• A verbose task against a slow log API can exhaust the bounded delivery budget,
  fail after its process exited zero, and leave an explicit missing-output warning.
  Limit unnecessary log volume and investigate API/network latency. The companion
  suite retains the delayed-upload and two-job slow-log expected failures and
  adds a single-job slow-log regression. These markers remain until fixes pass
  the original success/deadline and complete-output assertions.

This prerelease deferral does not mark either requirement implemented. Public
portable publication, image acceptance and the independent VM approval tag are
separate operations.

Previous beta.11 release

Beta.11 replays a frozen StartJob acknowledgement after narrowly classified
transient transport/status failures, within one ten-second budget clipped to
the initial claim lease. Task execution waits for affirmative acknowledgement;
cancellation or ownership loss still prevents admission. Retry identity includes
the original current-job count, session, attempt, claim and event fences.

Process tasks index their first 256 captured warning/error commands. Excess
masked raw lines remain in the bounded log capture; the exact omitted-index count
is reported through reserved diagnostic space and the task fails explicitly.
Ordinary error annotations still do not fail a task. Plain log coalescing fits
32 KiB raw UTF-8 and 48 KiB serialized JSON, using the existing single-record API.
The 32 MiB capture cap, fifteen-second log delivery budgets and server rate limits
remain unchanged. An annotation cannot precede acknowledgement of its raw line,
including when journal storage rejects that line. Log-lane 429 backoff respects
Retry-After without blocking ownership/control traffic or extending its budget.
Chunking also makes bounded forward progress for malformed UTF-8 retained in raw
environment exports and substituted into native artifact status messages. It
preserves the existing per-invalid-byte JSON replacement and valid rune boundaries.

Manifest v6, execution-v2, portable bundle schema 2, Go 1.26.10, Node 24.18.0 and
the compatible beta.4 built-in task minimums remain unchanged. This worker fix
adds no API capability or batch route and supports the existing API path. Publish
and independently verify the exact clean beta.11 release before changing the
application source pin. Beta.1 through beta.10 tags/assets remain immutable.
See the beta.11 validation boundary and
task log boundaries. Publication and latest-approved
promotion remain separate from image construction, guest acceptance and rollout.

Previous beta.10 release

Beta.10 pins Go 1.26.10 after the canonical
security gate reported GO-2026-6809
(CVE-2026-111943), published October 21, 2026. The patch distrusts compromised
intermediate certificates in crypto/x509; Go versions before 1.26.10 are
affected. All six distributions and the full canonical gate must use the patched
pin. Beta.1 through beta.9 tags and assets remain immutable. The application
adopts this source only after the exact beta.10 release and all 26 assets have
been published and independently verified. Historical release notes below retain
the versions used for those releases.

Beta.10 also observes cancellation when an
active task result reaches the scheduler. Eligible cancellation/always cleanup
waits for active tasks to settle; ownership loss and hard abort still prevent
pending execution. The protected rental allocation, task-scoped credentials and
fail-closed launcher remain in the same execution path. Linux protected rentals
require the matching application's enrollment, scoped task-credential, bootstrap
and network contracts. Portable publication alone does not accept a guest image
or activate those controls. See task isolation and the
beta.10 validation record.

Manifest v6, protocol.step-execution.v2, portable bundle schema 2 and the
Node 24.18.0 runtime remain unchanged. Built-in task packages retain their
compatible beta.4 minimum; their handler interfaces have not changed.

After independent download verification, only the established latest-approved
alias may advance to beta.10 with an explicit lease. No latest alias is created,
and the separate latest-vm-approved image/security hold remains unchanged.
Publishing a prerelease makes it eligible for existing self-hosted installations
already opted into automatic beta updates through the registered-server feed.
Updates default to off/stable; ephemeral VM runners remain pinned with updates off.

Beta.9 keeps single-execution step logs free of attempt records and writes
readable retry decisions only when automatic retries are in play. Retry starts,
outcomes and waits remain acknowledged in the same logical-step journal.
The obsolete built-in HashiCorp Vault task and its task-specific tests are removed.
Manifest v6, portable bundle schema 2, the pinned toolchains and the remaining
built-in task minimum runner versions are unchanged. Use this release with the
matching application changes; publish and verify it before updating the
application source pin or building its VM image.

Beta.8 requires manifest v6 and protocol.step-execution.v2. It adds stable
step keys, bounded retries for process tasks, protected execution namespaces,
read-only task-attempt metadata and atomic successful exports/output completion.
Scalar retry: 3 permits four total executions. Retries share one step deadline,
retain the concurrency slot and never repeat host, protocol or logging failures.
Only manifest v6 executes; earlier manifests are rejected. This requires the
matching application API and artifact schema 3, and recompilation of saved YAML
before use. See the execution contract.

Publish and verify this immutable runner release before adopting its source pin
in the application or building an AWS image. Existing beta.7 instances, image
revisions and pipelines remain pinned until the coordinated application cutover.
Built-in packages retain their beta.4 minimum because their handler interfaces
remain compatible; the new application requires the execution-v2 capability.
Portable bundle schema 2 and the pinned Go/Node toolchains are unchanged.

Beta.7 rebuilds the worker and lifecycle manager with the supported Go 1.26.9
security toolchain. This includes the October 8 fixes for excessive HTTP/2
SETTINGS processing (CVE-2026-78669), HTTP Range parsing (CVE-2026-78667), and
TLS ECH extension memory amplification (CVE-2026-97031). The HTTP/2 advisory
includes clients, making the fix relevant to the runner's outbound HTTP use.
See Go's release notes and
HTTP/2 advisory.

Task protocols, manifest formats, bundled Node version, and built-in beta.4
minimum runner versions remain compatible. Rebuild all six portable targets,
run the canonical vulnerability gate, and import the immutable release pin into
the...

Conductor Runner 0.0.1-beta.12

Runner beta release

Version: 0.0.1-beta.12. Tag: v0.0.1-beta.12.
Public repository: https://github.com/ConductorCI/runner.

Beta.12 recovers a retired runner session without restarting the worker. It stops
the abandoned attempts, waits for their task trees to settle, creates a fresh
session, and resumes polling. Stale replies cannot change the replacement session.
Recovery fails closed if abandoned work cannot drain or session losses repeat
within five minutes. See the recovery design
and the validation record.

Manifest v6, execution-v2, portable bundle schema 2, Go 1.26.10, Node 24.18.0 and
the compatible beta.4 built-in task minimums remain unchanged. No server wire
change is required. Keep beta.1 through beta.11 tags and assets immutable.

Known beta.12 limitations

The October 29 operator decision permits deferring these existing reliability
findings for this beta. A single user can encounter them under slow I/O; they are
not limited to a large fleet. They remain open regression requirements in the
companion application's complex-pipeline tracker (opus:R-01 and astra:R17).

• Native artifact upload/download steps do not enforce the per-step deadline.
  A 100-second delayed upload response can succeed despite a one-minute step
  limit. Set a finite job-level timeout and allow enough time for artifact
  transfer; job cancellation/abort still governs the transfer request.
• A verbose task against a slow log API can exhaust the bounded delivery budget,
  fail after its process exited zero, and leave an explicit missing-output warning.
  Limit unnecessary log volume and investigate API/network latency. The companion
  suite retains the delayed-upload and two-job slow-log expected failures and
  adds a single-job slow-log regression. These markers remain until fixes pass
  the original success/deadline and complete-output assertions.

This prerelease deferral does not mark either requirement implemented. Public
portable publication, image acceptance and the independent VM approval tag are
separate operations.

Previous beta.11 release

Beta.11 replays a frozen StartJob acknowledgement after narrowly classified
transient transport/status failures, within one ten-second budget clipped to
the initial claim lease. Task execution waits for affirmative acknowledgement;
cancellation or ownership loss still prevents admission. Retry identity includes
the original current-job count, session, attempt, claim and event fences.

Process tasks index their first 256 captured warning/error commands. Excess
masked raw lines remain in the bounded log capture; the exact omitted-index count
is reported through reserved diagnostic space and the task fails explicitly.
Ordinary error annotations still do not fail a task. Plain log coalescing fits
32 KiB raw UTF-8 and 48 KiB serialized JSON, using the existing single-record API.
The 32 MiB capture cap, fifteen-second log delivery budgets and server rate limits
remain unchanged. An annotation cannot precede acknowledgement of its raw line,
including when journal storage rejects that line. Log-lane 429 backoff respects
Retry-After without blocking ownership/control traffic or extending its budget.
Chunking also makes bounded forward progress for malformed UTF-8 retained in raw
environment exports and substituted into native artifact status messages. It
preserves the existing per-invalid-byte JSON replacement and valid rune boundaries.

Manifest v6, execution-v2, portable bundle schema 2, Go 1.26.10, Node 24.18.0 and
the compatible beta.4 built-in task minimums remain unchanged. This worker fix
adds no API capability or batch route and supports the existing API path. Publish
and independently verify the exact clean beta.11 release before changing the
application source pin. Beta.1 through beta.10 tags/assets remain immutable.
See the beta.11 validation boundary and
task log boundaries. Publication and latest-approved
promotion remain separate from image construction, guest acceptance and rollout.

Previous beta.10 release

Beta.10 pins Go 1.26.10 after the canonical
security gate reported GO-2026-6809
(CVE-2026-111943), published October 21, 2026. The patch distrusts compromised
intermediate certificates in crypto/x509; Go versions before 1.26.10 are
affected. All six distributions and the full canonical gate must use the patched
pin. Beta.1 through beta.9 tags and assets remain immutable. The application
adopts this source only after the exact beta.10 release and all 26 assets have
been published and independently verified. Historical release notes below retain
the versions used for those releases.

Beta.10 also observes cancellation when an
active task result reaches the scheduler. Eligible cancellation/always cleanup
waits for active tasks to settle; ownership loss and hard abort still prevent
pending execution. The protected rental allocation, task-scoped credentials and
fail-closed launcher remain in the same execution path. Linux protected rentals
require the matching application's enrollment, scoped task-credential, bootstrap
and network contracts. Portable publication alone does not accept a guest image
or activate those controls. See task isolation and the
beta.10 validation record.

Manifest v6, protocol.step-execution.v2, portable bundle schema 2 and the
Node 24.18.0 runtime remain unchanged. Built-in task packages retain their
compatible beta.4 minimum; their handler interfaces have not changed.

After independent download verification, only the established latest-approved
alias may advance to beta.10 with an explicit lease. No latest alias is created,
and the separate latest-vm-approved image/security hold remains unchanged.
Publishing a prerelease makes it eligible for existing self-hosted installations
already opted into automatic beta updates through the registered-server feed.
Updates default to off/stable; ephemeral VM runners remain pinned with updates off.

Beta.9 keeps single-execution step logs free of attempt records and writes
readable retry decisions only when automatic retries are in play. Retry starts,
outcomes and waits remain acknowledged in the same logical-step journal.
The obsolete built-in HashiCorp Vault task and its task-specific tests are removed.
Manifest v6, portable bundle schema 2, the pinned toolchains and the remaining
built-in task minimum runner versions are unchanged. Use this release with the
matching application changes; publish and verify it before updating the
application source pin or building its VM image.

Beta.8 requires manifest v6 and protocol.step-execution.v2. It adds stable
step keys, bounded retries for process tasks, protected execution namespaces,
read-only task-attempt metadata and atomic successful exports/output completion.
Scalar retry: 3 permits four total executions. Retries share one step deadline,
retain the concurrency slot and never repeat host, protocol or logging failures.
Only manifest v6 executes; earlier manifests are rejected. This requires the
matching application API and artifact schema 3, and recompilation of saved YAML
before use. See the execution contract.

Publish and verify this immutable runner release before adopting its source pin
in the application or building an AWS image. Existing beta.7 instances, image
revisions and pipelines remain pinned until the coordinated application cutover.
Built-in packages retain their beta.4 minimum because their handler interfaces
remain compatible; the new application requires the execution-v2 capability.
Portable bundle schema 2 and the pinned Go/Node toolchains are unchanged.

Beta.7 rebuilds the worker and lifecycle manager with the supported Go 1.26.9
security toolchain. This includes the October 8 fixes for excessive HTTP/2
SETTINGS processing (CVE-2026-78669), HTTP Range parsing (CVE-2026-78667), and
TLS ECH extension memory amplification (CVE-2026-97031). The HTTP/2 advisory
includes clients, making the fix relevant to the runner's outbound HTTP use.
See Go's release notes and
HTTP/2 advisory.

Task protocols, manifest formats, bundled Node version, and built-in beta.4
minimum runner versions remain compatible. Rebuild all six portable targets,
run the canonical vulnerability gate, and import the immutable release pin into
the application. Build the pinned govulncheck v1.6.0 with Go 1.26 or newer so it
can load the new standard library. Existing version tags and published assets
remain unchanged.

Beta.7 also retries brief Windows sharing/locking errors and concurrent atomic
replacement when reading manager heartbeat files. Each retry reopens and
revalidates the file; malformed files and failures that persist through the
bounded retry window still fail closed. This prevents a valid heartbeat update
from intermittently stopping worker startup or triggering a drain.

Beta.6 gives every executed action a five-line Pool/Runner/Step/Task/Version
header, one succeeded/failed/cancelled result line, and a final Finished: <Task>
record. The JavaScript host and SDK expose ctx.setResult so handlers can supply
result detail without duplicating terminal output. Runner timeouts, cancellation
and output failures take precedence over a handler's reported success. Host health
is sampled at each task; persistent warning kinds are annotated once per job.

The manager now explains commands and maintenance outcomes, discovers its own
installation folder for everyday commands, and prints a readable update summary.
Scripts that consume check-update JSON must add --json. Install and uninstall
still require an explicit --target; services and PATH are managed separately.
Custom packages using `ctx.setR...

Conductor Runner 0.0.1-beta.11

Runner beta release

Version: 0.0.1-beta.11. Tag: v0.0.1-beta.11.
Public repository: https://github.com/ConductorCI/runner.

Beta.11 replays a frozen StartJob acknowledgement after narrowly classified
transient transport/status failures, within one ten-second budget clipped to
the initial claim lease. Task execution waits for affirmative acknowledgement;
cancellation or ownership loss still prevents admission. Retry identity includes
the original current-job count, session, attempt, claim and event fences.

Process tasks index their first 256 captured warning/error commands. Excess
masked raw lines remain in the bounded log capture; the exact omitted-index count
is reported through reserved diagnostic space and the task fails explicitly.
Ordinary error annotations still do not fail a task. Plain log coalescing fits
32 KiB raw UTF-8 and 48 KiB serialized JSON, using the existing single-record API.
The 32 MiB capture cap, fifteen-second log delivery budgets and server rate limits
remain unchanged. An annotation cannot precede acknowledgement of its raw line,
including when journal storage rejects that line. Log-lane 429 backoff respects
Retry-After without blocking ownership/control traffic or extending its budget.
Chunking also makes bounded forward progress for malformed UTF-8 retained in raw
environment exports and substituted into native artifact status messages. It
preserves the existing per-invalid-byte JSON replacement and valid rune boundaries.

Manifest v6, execution-v2, portable bundle schema 2, Go 1.26.10, Node 24.18.0 and
the compatible beta.4 built-in task minimums remain unchanged. This worker fix
adds no API capability or batch route and supports the existing API path. Publish
and independently verify the exact clean beta.11 release before changing the
application source pin. Beta.1 through beta.10 tags/assets remain immutable.
See the beta.11 validation boundary and
task log boundaries. Publication and latest-approved
promotion remain separate from image construction, guest acceptance and rollout.

Previous beta.10 release

Beta.10 pins Go 1.26.10 after the canonical
security gate reported GO-2026-6809
(CVE-2026-111943), published October 21, 2026. The patch distrusts compromised
intermediate certificates in crypto/x509; Go versions before 1.26.10 are
affected. All six distributions and the full canonical gate must use the patched
pin. Beta.1 through beta.9 tags and assets remain immutable. The application
adopts this source only after the exact beta.10 release and all 26 assets have
been published and independently verified. Historical release notes below retain
the versions used for those releases.

Beta.10 also observes cancellation when an
active task result reaches the scheduler. Eligible cancellation/always cleanup
waits for active tasks to settle; ownership loss and hard abort still prevent
pending execution. The protected rental allocation, task-scoped credentials and
fail-closed launcher remain in the same execution path. Linux protected rentals
require the matching application's enrollment, scoped task-credential, bootstrap
and network contracts. Portable publication alone does not accept a guest image
or activate those controls. See task isolation and the
beta.10 validation record.

Manifest v6, protocol.step-execution.v2, portable bundle schema 2 and the
Node 24.18.0 runtime remain unchanged. Built-in task packages retain their
compatible beta.4 minimum; their handler interfaces have not changed.

After independent download verification, only the established latest-approved
alias may advance to beta.10 with an explicit lease. No latest alias is created,
and the separate latest-vm-approved image/security hold remains unchanged.
Publishing a prerelease makes it eligible for existing self-hosted installations
already opted into automatic beta updates through the registered-server feed.
Updates default to off/stable; ephemeral VM runners remain pinned with updates off.

Beta.9 keeps single-execution step logs free of attempt records and writes
readable retry decisions only when automatic retries are in play. Retry starts,
outcomes and waits remain acknowledged in the same logical-step journal.
The obsolete built-in HashiCorp Vault task and its task-specific tests are removed.
Manifest v6, portable bundle schema 2, the pinned toolchains and the remaining
built-in task minimum runner versions are unchanged. Use this release with the
matching application changes; publish and verify it before updating the
application source pin or building its VM image.

Beta.8 requires manifest v6 and protocol.step-execution.v2. It adds stable
step keys, bounded retries for process tasks, protected execution namespaces,
read-only task-attempt metadata and atomic successful exports/output completion.
Scalar retry: 3 permits four total executions. Retries share one step deadline,
retain the concurrency slot and never repeat host, protocol or logging failures.
Only manifest v6 executes; earlier manifests are rejected. This requires the
matching application API and artifact schema 3, and recompilation of saved YAML
before use. See the execution contract.

Publish and verify this immutable runner release before adopting its source pin
in the application or building an AWS image. Existing beta.7 instances, image
revisions and pipelines remain pinned until the coordinated application cutover.
Built-in packages retain their beta.4 minimum because their handler interfaces
remain compatible; the new application requires the execution-v2 capability.
Portable bundle schema 2 and the pinned Go/Node toolchains are unchanged.

Beta.7 rebuilds the worker and lifecycle manager with the supported Go 1.26.9
security toolchain. This includes the October 8 fixes for excessive HTTP/2
SETTINGS processing (CVE-2026-78669), HTTP Range parsing (CVE-2026-78667), and
TLS ECH extension memory amplification (CVE-2026-97031). The HTTP/2 advisory
includes clients, making the fix relevant to the runner's outbound HTTP use.
See Go's release notes and
HTTP/2 advisory.

Task protocols, manifest formats, bundled Node version, and built-in beta.4
minimum runner versions remain compatible. Rebuild all six portable targets,
run the canonical vulnerability gate, and import the immutable release pin into
the application. Build the pinned govulncheck v1.6.0 with Go 1.26 or newer so it
can load the new standard library. Existing version tags and published assets
remain unchanged.

Beta.7 also retries brief Windows sharing/locking errors and concurrent atomic
replacement when reading manager heartbeat files. Each retry reopens and
revalidates the file; malformed files and failures that persist through the
bounded retry window still fail closed. This prevents a valid heartbeat update
from intermittently stopping worker startup or triggering a drain.

Beta.6 gives every executed action a five-line Pool/Runner/Step/Task/Version
header, one succeeded/failed/cancelled result line, and a final Finished: <Task>
record. The JavaScript host and SDK expose ctx.setResult so handlers can supply
result detail without duplicating terminal output. Runner timeouts, cancellation
and output failures take precedence over a handler's reported success. Host health
is sampled at each task; persistent warning kinds are annotated once per job.

The manager now explains commands and maintenance outcomes, discovers its own
installation folder for everyday commands, and prints a readable update summary.
Scripts that consume check-update JSON must add --json. Install and uninstall
still require an explicit --target; services and PATH are managed separately.
Custom packages using ctx.setResult must require runner beta.6 or later. Built-in
shell packages retain an older-host fallback and their beta.4 minimum requirement.

Beta.5 batches adjacent plain output, retries transient delivery failures during
execution, and preserves the observed child exit code when log delivery fails.
The service journal records the closing result even when the API cannot accept
the footer. The application companion change recovers missing closing summaries
from durable step status and refreshes an open log view when its job ends.
This is a compatible bug fix: built-in task minimum versions remain beta.4 and
the task log protocol and manifest schema versions do not change. Publish a new
immutable prerelease, reconcile the application pin, and upgrade the API/frontend
and runner before claiming the corrected behavior is live.

Beta.4 added runner-owned headers, author identity and final task messages for
all actions, with acknowledged attempt sequences and a sealed output drain.
Read task log boundaries for the protocol, failure
limits and coordinated API rollout.

Beta.3 changed the pre-release worker contract to runner throughout the CLI,
configuration, package metadata, API routes, services and SDK. Use it with the
matching Conductor API/database/frontend/MCP maintenance cutover. Existing beta
tags and assets remain immutable.

Worker and manager binaries are conductor-runner and
conductor-runner-manager. Sources live in cmd/conductor-runner/ and the other
matching command directories. The private Go module and packages use runner
names. Built-in task packages declare minRunnerVersion: 0.0.1-beta.4.

Coordinated upgrade

Stop old API admissions and workers after accepted work settles. Apply the
application runner-terminology migration, deploy its matching API, frontend and
MCP, then install this runner release. Update service commands, local config and
environment names. Re-register when an old identity/configuration layout remains.
The old manager cannot disco...

Conductor Runner 0.0.1-beta.10

Runner beta release

Version: 0.0.1-beta.10. Tag: v0.0.1-beta.10.
Public repository: https://github.com/ConductorCI/runner.

Beta.10 pins Go 1.26.10 after the canonical
security gate reported GO-2026-6809
(CVE-2026-111943), published October 21, 2026. The patch distrusts compromised
intermediate certificates in crypto/x509; Go versions before 1.26.10 are
affected. All six distributions and the full canonical gate must use the patched
pin. Beta.1 through beta.9 tags and assets remain immutable. The application
adopts this source only after the exact beta.10 release and all 26 assets have
been published and independently verified. Historical release notes below retain
the versions used for those releases.

Beta.10 also observes cancellation when an
active task result reaches the scheduler. Eligible cancellation/always cleanup
waits for active tasks to settle; ownership loss and hard abort still prevent
pending execution. The protected rental allocation, task-scoped credentials and
fail-closed launcher remain in the same execution path. Linux protected rentals
require the matching application's enrollment, scoped task-credential, bootstrap
and network contracts. Portable publication alone does not accept a guest image
or activate those controls. See task isolation and the
beta.10 validation record.

Manifest v6, protocol.step-execution.v2, portable bundle schema 2 and the
Node 24.18.0 runtime remain unchanged. Built-in task packages retain their
compatible beta.4 minimum; their handler interfaces have not changed.

After independent download verification, only the established latest-approved
alias may advance to beta.10 with an explicit lease. No latest alias is created,
and the separate latest-vm-approved image/security hold remains unchanged.
Publishing a prerelease makes it eligible for existing self-hosted installations
already opted into automatic beta updates through the registered-server feed.
Updates default to off/stable; ephemeral VM runners remain pinned with updates off.

Beta.9 keeps single-execution step logs free of attempt records and writes
readable retry decisions only when automatic retries are in play. Retry starts,
outcomes and waits remain acknowledged in the same logical-step journal.
The obsolete built-in HashiCorp Vault task and its task-specific tests are removed.
Manifest v6, portable bundle schema 2, the pinned toolchains and the remaining
built-in task minimum runner versions are unchanged. Use this release with the
matching application changes; publish and verify it before updating the
application source pin or building its VM image.

Beta.8 requires manifest v6 and protocol.step-execution.v2. It adds stable
step keys, bounded retries for process tasks, protected execution namespaces,
read-only task-attempt metadata and atomic successful exports/output completion.
Scalar retry: 3 permits four total executions. Retries share one step deadline,
retain the concurrency slot and never repeat host, protocol or logging failures.
Only manifest v6 executes; earlier manifests are rejected. This requires the
matching application API and artifact schema 3, and recompilation of saved YAML
before use. See the execution contract.

Publish and verify this immutable runner release before adopting its source pin
in the application or building an AWS image. Existing beta.7 instances, image
revisions and pipelines remain pinned until the coordinated application cutover.
Built-in packages retain their beta.4 minimum because their handler interfaces
remain compatible; the new application requires the execution-v2 capability.
Portable bundle schema 2 and the pinned Go/Node toolchains are unchanged.

Beta.7 rebuilds the worker and lifecycle manager with the supported Go 1.26.9
security toolchain. This includes the October 8 fixes for excessive HTTP/2
SETTINGS processing (CVE-2026-78669), HTTP Range parsing (CVE-2026-78667), and
TLS ECH extension memory amplification (CVE-2026-97031). The HTTP/2 advisory
includes clients, making the fix relevant to the runner's outbound HTTP use.
See Go's release notes and
HTTP/2 advisory.

Task protocols, manifest formats, bundled Node version, and built-in beta.4
minimum runner versions remain compatible. Rebuild all six portable targets,
run the canonical vulnerability gate, and import the immutable release pin into
the application. Build the pinned govulncheck v1.6.0 with Go 1.26 or newer so it
can load the new standard library. Existing version tags and published assets
remain unchanged.

Beta.7 also retries brief Windows sharing/locking errors and concurrent atomic
replacement when reading manager heartbeat files. Each retry reopens and
revalidates the file; malformed files and failures that persist through the
bounded retry window still fail closed. This prevents a valid heartbeat update
from intermittently stopping worker startup or triggering a drain.

Beta.6 gives every executed action a five-line Pool/Runner/Step/Task/Version
header, one succeeded/failed/cancelled result line, and a final Finished: <Task>
record. The JavaScript host and SDK expose ctx.setResult so handlers can supply
result detail without duplicating terminal output. Runner timeouts, cancellation
and output failures take precedence over a handler's reported success. Host health
is sampled at each task; persistent warning kinds are annotated once per job.

The manager now explains commands and maintenance outcomes, discovers its own
installation folder for everyday commands, and prints a readable update summary.
Scripts that consume check-update JSON must add --json. Install and uninstall
still require an explicit --target; services and PATH are managed separately.
Custom packages using ctx.setResult must require runner beta.6 or later. Built-in
shell packages retain an older-host fallback and their beta.4 minimum requirement.

Beta.5 batches adjacent plain output, retries transient delivery failures during
execution, and preserves the observed child exit code when log delivery fails.
The service journal records the closing result even when the API cannot accept
the footer. The application companion change recovers missing closing summaries
from durable step status and refreshes an open log view when its job ends.
This is a compatible bug fix: built-in task minimum versions remain beta.4 and
the task log protocol and manifest schema versions do not change. Publish a new
immutable prerelease, reconcile the application pin, and upgrade the API/frontend
and runner before claiming the corrected behavior is live.

Beta.4 added runner-owned headers, author identity and final task messages for
all actions, with acknowledged attempt sequences and a sealed output drain.
Read task log boundaries for the protocol, failure
limits and coordinated API rollout.

Beta.3 changed the pre-release worker contract to runner throughout the CLI,
configuration, package metadata, API routes, services and SDK. Use it with the
matching Conductor API/database/frontend/MCP maintenance cutover. Existing beta
tags and assets remain immutable.

Worker and manager binaries are conductor-runner and
conductor-runner-manager. Sources live in cmd/conductor-runner/ and the other
matching command directories. The private Go module and packages use runner
names. Built-in task packages declare minRunnerVersion: 0.0.1-beta.4.

Coordinated upgrade

Stop old API admissions and workers after accepted work settles. Apply the
application runner-terminology migration, deploy its matching API, frontend and
MCP, then install this runner release. Update service commands, local config and
environment names. Re-register when an old identity/configuration layout remains.
The old manager cannot discover the renamed /api/v1/runners/updates endpoint;
this release requires a manual cutover. Custom task archives must use
minRunnerVersion. User scripts that referenced previous worker environment
names need corresponding edits.

Beta.8 accepts only job manifest version 6; portable bundle schema 2 is unchanged.
Old API/worker pairs are not supported across this cutover. Do not weaken version,
signature, hash, or capability checks to mix incompatible releases.

Portable release

Run tools/scripts/ci/Invoke-RunnerUnitTests.ps1, then build from a clean commit
with tools/scripts/runner/Build-Distribution.ps1 -Target All. While developing,
use -AllowDirtySource and do not publish those dirty-source artifacts.

The release contains Windows ZIP bundles and Linux/macOS tar.gz bundles for
amd64 and arm64, six managers, twelve SHA-256 sidecars, SHA256SUMS and
release-manifest.json. Node and its license are included in every bundle.

Publish the 26 files directly under dist/ as GitHub prerelease assets. Verify
the manifest source commit is the tagged commit, sourceDirty is false, and all
asset digests match. Keep generated distributions and credentials out of Git.

Native MSI/pkg/deb/rpm packages require native validation and signing identities
from native-release-checklist.md; portable cross-builds do not prove them.

Approval and publication

Use ConductorCI for release orchestration. A release job requires a Windows
runner with the pinned Go and Node toolchains and vulnerability scanner. Run the
canonical runner gate, build all six targets from the exact clean source commit,
then invoke tools/scripts/runner/Publish-GitHubRelease.ps1. The publisher verifies
all 26 asset digests before publishing the prerelease. Pass PromoteLatestApproved
only after explicit approval. ConductorCI pipeline setup is deferred; no automatic
publication trigger is configured in this repository.

Version tags (such as v0.0.1-beta.3) and published assets are immutable.
The publisher preserves...

Conductor Runner 0.0.1-beta.9

Runner beta release

Version: 0.0.1-beta.9. Tag: v0.0.1-beta.9.
Public repository: https://github.com/ConductorCI/runner.

Beta.9 keeps single-execution step logs free of attempt records and writes
readable retry decisions only when automatic retries are in play. Retry starts,
outcomes and waits remain acknowledged in the same logical-step journal.
The obsolete built-in HashiCorp Vault task and its task-specific tests are removed.
Manifest v6, portable bundle schema 2, the pinned toolchains and the remaining
built-in task minimum runner versions are unchanged. Use this release with the
matching application changes; publish and verify it before updating the
application source pin or building its VM image.

Beta.8 requires manifest v6 and protocol.step-execution.v2. It adds stable
step keys, bounded retries for process tasks, protected execution namespaces,
read-only task-attempt metadata and atomic successful exports/output completion.
Scalar retry: 3 permits four total executions. Retries share one step deadline,
retain the concurrency slot and never repeat host, protocol or logging failures.
Only manifest v6 executes; earlier manifests are rejected. This requires the
matching application API and artifact schema 3, and recompilation of saved YAML
before use. See the execution contract.

Publish and verify this immutable runner release before adopting its source pin
in the application or building an AWS image. Existing beta.7 instances, image
revisions and pipelines remain pinned until the coordinated application cutover.
Built-in packages retain their beta.4 minimum because their handler interfaces
remain compatible; the new application requires the execution-v2 capability.
Portable bundle schema 2 and the pinned Go/Node toolchains are unchanged.

Beta.7 rebuilds the worker and lifecycle manager with the supported Go 1.26.9
security toolchain. This includes the October 8 fixes for excessive HTTP/2
SETTINGS processing (CVE-2026-78669), HTTP Range parsing (CVE-2026-78667), and
TLS ECH extension memory amplification (CVE-2026-97031). The HTTP/2 advisory
includes clients, making the fix relevant to the runner's outbound HTTP use.
See Go's release notes and
HTTP/2 advisory.

Task protocols, manifest formats, bundled Node version, and built-in beta.4
minimum runner versions remain compatible. Rebuild all six portable targets,
run the canonical vulnerability gate, and import the immutable release pin into
the application. Build the pinned govulncheck v1.6.0 with Go 1.26 or newer so it
can load the new standard library. Existing version tags and published assets
remain unchanged.

Beta.7 also retries brief Windows sharing/locking errors and concurrent atomic
replacement when reading manager heartbeat files. Each retry reopens and
revalidates the file; malformed files and failures that persist through the
bounded retry window still fail closed. This prevents a valid heartbeat update
from intermittently stopping worker startup or triggering a drain.

Beta.6 gives every executed action a five-line Pool/Runner/Step/Task/Version
header, one succeeded/failed/cancelled result line, and a final Finished: <Task>
record. The JavaScript host and SDK expose ctx.setResult so handlers can supply
result detail without duplicating terminal output. Runner timeouts, cancellation
and output failures take precedence over a handler's reported success. Host health
is sampled at each task; persistent warning kinds are annotated once per job.

The manager now explains commands and maintenance outcomes, discovers its own
installation folder for everyday commands, and prints a readable update summary.
Scripts that consume check-update JSON must add --json. Install and uninstall
still require an explicit --target; services and PATH are managed separately.
Custom packages using ctx.setResult must require runner beta.6 or later. Built-in
shell packages retain an older-host fallback and their beta.4 minimum requirement.

Beta.5 batches adjacent plain output, retries transient delivery failures during
execution, and preserves the observed child exit code when log delivery fails.
The service journal records the closing result even when the API cannot accept
the footer. The application companion change recovers missing closing summaries
from durable step status and refreshes an open log view when its job ends.
This is a compatible bug fix: built-in task minimum versions remain beta.4 and
the task log protocol and manifest schema versions do not change. Publish a new
immutable prerelease, reconcile the application pin, and upgrade the API/frontend
and runner before claiming the corrected behavior is live.

Beta.4 added runner-owned headers, author identity and final task messages for
all actions, with acknowledged attempt sequences and a sealed output drain.
Read task log boundaries for the protocol, failure
limits and coordinated API rollout.

Beta.3 changed the pre-release worker contract to runner throughout the CLI,
configuration, package metadata, API routes, services and SDK. Use it with the
matching Conductor API/database/frontend/MCP maintenance cutover. Existing beta
tags and assets remain immutable.

Worker and manager binaries are conductor-runner and
conductor-runner-manager. Sources live in cmd/conductor-runner/ and the other
matching command directories. The private Go module and packages use runner
names. Built-in task packages declare minRunnerVersion: 0.0.1-beta.4.

Coordinated upgrade

Stop old API admissions and workers after accepted work settles. Apply the
application runner-terminology migration, deploy its matching API, frontend and
MCP, then install this runner release. Update service commands, local config and
environment names. Re-register when an old identity/configuration layout remains.
The old manager cannot discover the renamed /api/v1/runners/updates endpoint;
this release requires a manual cutover. Custom task archives must use
minRunnerVersion. User scripts that referenced previous worker environment
names need corresponding edits.

Beta.8 accepts only job manifest version 6; portable bundle schema 2 is unchanged.
Old API/worker pairs are not supported across this cutover. Do not weaken version,
signature, hash, or capability checks to mix incompatible releases.

Portable release

Run tools/scripts/ci/Invoke-RunnerUnitTests.ps1, then build from a clean commit
with tools/scripts/runner/Build-Distribution.ps1 -Target All. While developing,
use -AllowDirtySource and do not publish those dirty-source artifacts.

The release contains Windows ZIP bundles and Linux/macOS tar.gz bundles for
amd64 and arm64, six managers, twelve SHA-256 sidecars, SHA256SUMS and
release-manifest.json. Node and its license are included in every bundle.

Publish the 26 files directly under dist/ as GitHub prerelease assets. Verify
the manifest source commit is the tagged commit, sourceDirty is false, and all
asset digests match. Keep generated distributions and credentials out of Git.

Native MSI/pkg/deb/rpm packages require native validation and signing identities
from native-release-checklist.md; portable cross-builds do not prove them.

Approval and publication

Use ConductorCI for release orchestration. A release job requires a Windows
runner with the pinned Go and Node toolchains and vulnerability scanner. Run the
canonical runner gate, build all six targets from the exact clean source commit,
then invoke tools/scripts/runner/Publish-GitHubRelease.ps1. The publisher verifies
all 26 asset digests before publishing the prerelease. Pass PromoteLatestApproved
only after explicit approval. ConductorCI pipeline setup is deferred; no automatic
publication trigger is configured in this repository.

Version tags (such as v0.0.1-beta.3) and published assets are immutable.
latest-approved is a lightweight, movable tag for the most recently approved
release commit. It moves only after verified publication, with an explicit lease
that prevents overwriting a concurrent promotion. An approved beta remains a
prerelease; the approval tag does not change its compatibility or channel.

Consumers should resolve latest-approved to the immutable version tag and use
that version's release assets. Source pins and installation manifests must
record the exact version/commit rather than pinning the movable alias.

The publisher uses GitHub REST release IDs for draft creation and binary uploads.
Interrupted draft uploads reuse assets with matching size and digest. Published
assets are immutable; CI-only fixes after a release require a new version for
a subsequent release from a different source commit.

Conductor Runner 0.0.1-beta.8

Runner beta release

Version: 0.0.1-beta.8. Tag: v0.0.1-beta.8.
Public repository: https://github.com/ConductorCI/runner.

Beta.8 requires manifest v6 and protocol.step-execution.v2. It adds stable
step keys, bounded retries for process tasks, protected execution namespaces,
read-only task-attempt metadata and atomic successful exports/output completion.
Scalar retry: 3 permits four total executions. Retries share one step deadline,
retain the concurrency slot and never repeat host, protocol or logging failures.
Only manifest v6 executes; earlier manifests are rejected. This requires the
matching application API and artifact schema 3, and recompilation of saved YAML
before use. See the execution contract.

Publish and verify this immutable runner release before adopting its source pin
in the application or building an AWS image. Existing beta.7 instances, image
revisions and pipelines remain pinned until the coordinated application cutover.
Built-in packages retain their beta.4 minimum because their handler interfaces
remain compatible; the new application requires the execution-v2 capability.
Portable bundle schema 2 and the pinned Go/Node toolchains are unchanged.

Beta.7 rebuilds the worker and lifecycle manager with the supported Go 1.26.9
security toolchain. This includes the October 8 fixes for excessive HTTP/2
SETTINGS processing (CVE-2026-78669), HTTP Range parsing (CVE-2026-78667), and
TLS ECH extension memory amplification (CVE-2026-97031). The HTTP/2 advisory
includes clients, making the fix relevant to the runner's outbound HTTP use.
See Go's release notes and
HTTP/2 advisory.

Task protocols, manifest formats, bundled Node version, and built-in beta.4
minimum runner versions remain compatible. Rebuild all six portable targets,
run the canonical vulnerability gate, and import the immutable release pin into
the application. Build the pinned govulncheck v1.6.0 with Go 1.26 or newer so it
can load the new standard library. Existing version tags and published assets
remain unchanged.

Beta.7 also retries brief Windows sharing/locking errors and concurrent atomic
replacement when reading manager heartbeat files. Each retry reopens and
revalidates the file; malformed files and failures that persist through the
bounded retry window still fail closed. This prevents a valid heartbeat update
from intermittently stopping worker startup or triggering a drain.

Beta.6 gives every executed action a five-line Pool/Runner/Step/Task/Version
header, one succeeded/failed/cancelled result line, and a final Finished: <Task>
record. The JavaScript host and SDK expose ctx.setResult so handlers can supply
result detail without duplicating terminal output. Runner timeouts, cancellation
and output failures take precedence over a handler's reported success. Host health
is sampled at each task; persistent warning kinds are annotated once per job.

The manager now explains commands and maintenance outcomes, discovers its own
installation folder for everyday commands, and prints a readable update summary.
Scripts that consume check-update JSON must add --json. Install and uninstall
still require an explicit --target; services and PATH are managed separately.
Custom packages using ctx.setResult must require runner beta.6 or later. Built-in
shell packages retain an older-host fallback and their beta.4 minimum requirement.

Beta.5 batches adjacent plain output, retries transient delivery failures during
execution, and preserves the observed child exit code when log delivery fails.
The service journal records the closing result even when the API cannot accept
the footer. The application companion change recovers missing closing summaries
from durable step status and refreshes an open log view when its job ends.
This is a compatible bug fix: built-in task minimum versions remain beta.4 and
the task log protocol and manifest schema versions do not change. Publish a new
immutable prerelease, reconcile the application pin, and upgrade the API/frontend
and runner before claiming the corrected behavior is live.

Beta.4 added runner-owned headers, author identity and final task messages for
all actions, with acknowledged attempt sequences and a sealed output drain.
Read task log boundaries for the protocol, failure
limits and coordinated API rollout.

Beta.3 changed the pre-release worker contract to runner throughout the CLI,
configuration, package metadata, API routes, services and SDK. Use it with the
matching Conductor API/database/frontend/MCP maintenance cutover. Existing beta
tags and assets remain immutable.

Worker and manager binaries are conductor-runner and
conductor-runner-manager. Sources live in cmd/conductor-runner/ and the other
matching command directories. The private Go module and packages use runner
names. Built-in task packages declare minRunnerVersion: 0.0.1-beta.4.

Coordinated upgrade

Stop old API admissions and workers after accepted work settles. Apply the
application runner-terminology migration, deploy its matching API, frontend and
MCP, then install this runner release. Update service commands, local config and
environment names. Re-register when an old identity/configuration layout remains.
The old manager cannot discover the renamed /api/v1/runners/updates endpoint;
this release requires a manual cutover. Custom task archives must use
minRunnerVersion. User scripts that referenced previous worker environment
names need corresponding edits.

Beta.8 accepts only job manifest version 6; portable bundle schema 2 is unchanged.
Old API/worker pairs are not supported across this cutover. Do not weaken version,
signature, hash, or capability checks to mix incompatible releases.

Portable release

Run tools/scripts/ci/Invoke-RunnerUnitTests.ps1, then build from a clean commit
with tools/scripts/runner/Build-Distribution.ps1 -Target All. While developing,
use -AllowDirtySource and do not publish those dirty-source artifacts.

The release contains Windows ZIP bundles and Linux/macOS tar.gz bundles for
amd64 and arm64, six managers, twelve SHA-256 sidecars, SHA256SUMS and
release-manifest.json. Node and its license are included in every bundle.

Publish the 26 files directly under dist/ as GitHub prerelease assets. Verify
the manifest source commit is the tagged commit, sourceDirty is false, and all
asset digests match. Keep generated distributions and credentials out of Git.

Native MSI/pkg/deb/rpm packages require native validation and signing identities
from native-release-checklist.md; portable cross-builds do not prove them.

Approval and publication

Use ConductorCI for release orchestration. A release job requires a Windows
runner with the pinned Go and Node toolchains and vulnerability scanner. Run the
canonical runner gate, build all six targets from the exact clean source commit,
then invoke tools/scripts/runner/Publish-GitHubRelease.ps1. The publisher verifies
all 26 asset digests before publishing the prerelease. Pass PromoteLatestApproved
only after explicit approval. ConductorCI pipeline setup is deferred; no automatic
publication trigger is configured in this repository.

Version tags (such as v0.0.1-beta.3) and published assets are immutable.
latest-approved is a lightweight, movable tag for the most recently approved
release commit. It moves only after verified publication, with an explicit lease
that prevents overwriting a concurrent promotion. An approved beta remains a
prerelease; the approval tag does not change its compatibility or channel.

Consumers should resolve latest-approved to the immutable version tag and use
that version's release assets. Source pins and installation manifests must
record the exact version/commit rather than pinning the movable alias.

The publisher uses GitHub REST release IDs for draft creation and binary uploads.
Interrupted draft uploads reuse assets with matching size and digest. Published
assets are immutable; CI-only fixes after a release require a new version for
a subsequent release from a different source commit.

Conductor Runner 0.0.1-beta.7

Runner beta release

Version: 0.0.1-beta.7. Tag: v0.0.1-beta.7.
Public repository: https://github.com/ConductorCI/runner.

Beta.7 rebuilds the worker and lifecycle manager with the supported Go 1.26.9
security toolchain. This includes the October 8 fixes for excessive HTTP/2
SETTINGS processing (CVE-2026-78669), HTTP Range parsing (CVE-2026-78667), and
TLS ECH extension memory amplification (CVE-2026-97031). The HTTP/2 advisory
includes clients, making the fix relevant to the runner's outbound HTTP use.
See Go's release notes and
HTTP/2 advisory.

Task protocols, manifest formats, bundled Node version, and built-in beta.4
minimum runner versions remain compatible. Rebuild all six portable targets,
run the canonical vulnerability gate, and import the immutable release pin into
the application. Build the pinned govulncheck v1.6.0 with Go 1.26 or newer so it
can load the new standard library. Existing version tags and published assets
remain unchanged.

Beta.7 also retries brief Windows sharing/locking errors and concurrent atomic
replacement when reading manager heartbeat files. Each retry reopens and
revalidates the file; malformed files and failures that persist through the
bounded retry window still fail closed. This prevents a valid heartbeat update
from intermittently stopping worker startup or triggering a drain.

Beta.6 gives every executed action a five-line Pool/Runner/Step/Task/Version
header, one succeeded/failed/cancelled result line, and a final Finished: <Task>
record. The JavaScript host and SDK expose ctx.setResult so handlers can supply
result detail without duplicating terminal output. Runner timeouts, cancellation
and output failures take precedence over a handler's reported success. Host health
is sampled at each task; persistent warning kinds are annotated once per job.

The manager now explains commands and maintenance outcomes, discovers its own
installation folder for everyday commands, and prints a readable update summary.
Scripts that consume check-update JSON must add --json. Install and uninstall
still require an explicit --target; services and PATH are managed separately.
Custom packages using ctx.setResult must require runner beta.6 or later. Built-in
shell packages retain an older-host fallback and their beta.4 minimum requirement.

Beta.5 batches adjacent plain output, retries transient delivery failures during
execution, and preserves the observed child exit code when log delivery fails.
The service journal records the closing result even when the API cannot accept
the footer. The application companion change recovers missing closing summaries
from durable step status and refreshes an open log view when its job ends.
This is a compatible bug fix: built-in task minimum versions remain beta.4 and
the task log protocol and manifest schema versions do not change. Publish a new
immutable prerelease, reconcile the application pin, and upgrade the API/frontend
and runner before claiming the corrected behavior is live.

Beta.4 added runner-owned headers, author identity and final task messages for
all actions, with acknowledged attempt sequences and a sealed output drain.
Read task log boundaries for the protocol, failure
limits and coordinated API rollout.

Beta.3 changed the pre-release worker contract to runner throughout the CLI,
configuration, package metadata, API routes, services and SDK. Use it with the
matching Conductor API/database/frontend/MCP maintenance cutover. Existing beta
tags and assets remain immutable.

Worker and manager binaries are conductor-runner and
conductor-runner-manager. Sources live in cmd/conductor-runner/ and the other
matching command directories. The private Go module and packages use runner
names. Built-in task packages declare minRunnerVersion: 0.0.1-beta.4.

Coordinated upgrade

Stop old API admissions and workers after accepted work settles. Apply the
application runner-terminology migration, deploy its matching API, frontend and
MCP, then install this runner release. Update service commands, local config and
environment names. Re-register when an old identity/configuration layout remains.
The old manager cannot discover the renamed /api/v1/runners/updates endpoint;
this release requires a manual cutover. Custom task archives must use
minRunnerVersion. User scripts that referenced previous worker environment
names need corresponding edits.

Job manifest formats 2 through 5 and portable bundle schema 2 retain their
structural versions. Their worker-named fields now use runner terminology; old
API/worker pairs are not supported across this cutover. Do not weaken version,
signature, hash, or capability checks to mix incompatible releases.

Portable release

Run tools/scripts/ci/Invoke-RunnerUnitTests.ps1, then build from a clean commit
with tools/scripts/runner/Build-Distribution.ps1 -Target All. While developing,
use -AllowDirtySource and do not publish those dirty-source artifacts.

The release contains Windows ZIP bundles and Linux/macOS tar.gz bundles for
amd64 and arm64, six managers, twelve SHA-256 sidecars, SHA256SUMS and
release-manifest.json. Node and its license are included in every bundle.

Publish the 26 files directly under dist/ as GitHub prerelease assets. Verify
the manifest source commit is the tagged commit, sourceDirty is false, and all
asset digests match. Keep generated distributions and credentials out of Git.

Native MSI/pkg/deb/rpm packages require native validation and signing identities
from native-release-checklist.md; portable cross-builds do not prove them.

Approval and publication

Use ConductorCI for release orchestration. A release job requires a Windows
runner with the pinned Go and Node toolchains and vulnerability scanner. Run the
canonical runner gate, build all six targets from the exact clean source commit,
then invoke tools/scripts/runner/Publish-GitHubRelease.ps1. The publisher verifies
all 26 asset digests before publishing the prerelease. Pass PromoteLatestApproved
only after explicit approval. ConductorCI pipeline setup is deferred; no automatic
publication trigger is configured in this repository.

Version tags (such as v0.0.1-beta.3) and published assets are immutable.
latest-approved is a lightweight, movable tag for the most recently approved
release commit. It moves only after verified publication, with an explicit lease
that prevents overwriting a concurrent promotion. An approved beta remains a
prerelease; the approval tag does not change its compatibility or channel.

Consumers should resolve latest-approved to the immutable version tag and use
that version's release assets. Source pins and installation manifests must
record the exact version/commit rather than pinning the movable alias.

The publisher uses GitHub REST release IDs for draft creation and binary uploads.
Interrupted draft uploads reuse assets with matching size and digest. Published
assets are immutable; CI-only fixes after a release require a new version for
a subsequent release from a different source commit.

Conductor Runner 0.0.1-beta.6

Runner beta release

Version: 0.0.1-beta.6. Tag: v0.0.1-beta.6.
Public repository: https://github.com/ConductorCI/runner.

Beta.6 gives every executed action a five-line Pool/Runner/Step/Task/Version
header, one succeeded/failed/cancelled result line, and a final Finished: <Task>
record. The JavaScript host and SDK expose ctx.setResult so handlers can supply
result detail without duplicating terminal output. Runner timeouts, cancellation
and output failures take precedence over a handler's reported success. Host health
is sampled at each task; persistent warning kinds are annotated once per job.

The manager now explains commands and maintenance outcomes, discovers its own
installation folder for everyday commands, and prints a readable update summary.
Scripts that consume check-update JSON must add --json. Install and uninstall
still require an explicit --target; services and PATH are managed separately.
Custom packages using ctx.setResult must require runner beta.6 or later. Built-in
shell packages retain an older-host fallback and their beta.4 minimum requirement.

Beta.5 batches adjacent plain output, retries transient delivery failures during
execution, and preserves the observed child exit code when log delivery fails.
The service journal records the closing result even when the API cannot accept
the footer. The application companion change recovers missing closing summaries
from durable step status and refreshes an open log view when its job ends.
This is a compatible bug fix: built-in task minimum versions remain beta.4 and
the task log protocol and manifest schema versions do not change. Publish a new
immutable prerelease, reconcile the application pin, and upgrade the API/frontend
and runner before claiming the corrected behavior is live.

Beta.4 added runner-owned headers, author identity and final task messages for
all actions, with acknowledged attempt sequences and a sealed output drain.
Read task log boundaries for the protocol, failure
limits and coordinated API rollout.

Beta.3 changed the pre-release worker contract to runner throughout the CLI,
configuration, package metadata, API routes, services and SDK. Use it with the
matching Conductor API/database/frontend/MCP maintenance cutover. Existing beta
tags and assets remain immutable.

Worker and manager binaries are conductor-runner and
conductor-runner-manager. Sources live in cmd/conductor-runner/ and the other
matching command directories. The private Go module and packages use runner
names. Built-in task packages declare minRunnerVersion: 0.0.1-beta.4.

Coordinated upgrade

Stop old API admissions and workers after accepted work settles. Apply the
application runner-terminology migration, deploy its matching API, frontend and
MCP, then install this runner release. Update service commands, local config and
environment names. Re-register when an old identity/configuration layout remains.
The old manager cannot discover the renamed /api/v1/runners/updates endpoint;
this release requires a manual cutover. Custom task archives must use
minRunnerVersion. User scripts that referenced previous worker environment
names need corresponding edits.

Job manifest formats 2 through 5 and portable bundle schema 2 retain their
structural versions. Their worker-named fields now use runner terminology; old
API/worker pairs are not supported across this cutover. Do not weaken version,
signature, hash, or capability checks to mix incompatible releases.

Portable release

Run tools/scripts/ci/Invoke-RunnerUnitTests.ps1, then build from a clean commit
with tools/scripts/runner/Build-Distribution.ps1 -Target All. While developing,
use -AllowDirtySource and do not publish those dirty-source artifacts.

The release contains Windows ZIP bundles and Linux/macOS tar.gz bundles for
amd64 and arm64, six managers, twelve SHA-256 sidecars, SHA256SUMS and
release-manifest.json. Node and its license are included in every bundle.

Publish the 26 files directly under dist/ as GitHub prerelease assets. Verify
the manifest source commit is the tagged commit, sourceDirty is false, and all
asset digests match. Keep generated distributions and credentials out of Git.

Native MSI/pkg/deb/rpm packages require native validation and signing identities
from native-release-checklist.md; portable cross-builds do not prove them.

Approval and publication

Use ConductorCI for release orchestration. A release job requires a Windows
runner with the pinned Go and Node toolchains and vulnerability scanner. Run the
canonical runner gate, build all six targets from the exact clean source commit,
then invoke tools/scripts/runner/Publish-GitHubRelease.ps1. The publisher verifies
all 26 asset digests before publishing the prerelease. Pass PromoteLatestApproved
only after explicit approval. ConductorCI pipeline setup is deferred; no automatic
publication trigger is configured in this repository.

Version tags (such as v0.0.1-beta.3) and published assets are immutable.
latest-approved is a lightweight, movable tag for the most recently approved
release commit. It moves only after verified publication, with an explicit lease
that prevents overwriting a concurrent promotion. An approved beta remains a
prerelease; the approval tag does not change its compatibility or channel.

Consumers should resolve latest-approved to the immutable version tag and use
that version's release assets. Source pins and installation manifests must
record the exact version/commit rather than pinning the movable alias.

The publisher uses GitHub REST release IDs for draft creation and binary uploads.
Interrupted draft uploads reuse assets with matching size and digest. Published
assets are immutable; CI-only fixes after a release require a new version for
a subsequent release from a different source commit.

Conductor Runner 0.0.1-beta.5

Runner beta release

Version: 0.0.1-beta.5. Tag: v0.0.1-beta.5.
Public repository: https://github.com/ConductorCI/runner.

Beta.5 batches adjacent plain output, retries transient delivery failures during
execution, and preserves the observed child exit code when log delivery fails.
The service journal records the closing result even when the API cannot accept
the footer. The application companion change recovers missing closing summaries
from durable step status and refreshes an open log view when its job ends.
This is a compatible bug fix: built-in task minimum versions remain beta.4 and
the task log protocol and manifest schema versions do not change. Publish a new
immutable prerelease, reconcile the application pin, and upgrade the API/frontend
and runner before claiming the corrected behavior is live.

Beta.4 added runner-owned headers, author identity and final task messages for
all actions, with acknowledged attempt sequences and a sealed output drain.
Read task log boundaries for the protocol, failure
limits and coordinated API rollout.

Beta.3 changed the pre-release worker contract to runner throughout the CLI,
configuration, package metadata, API routes, services and SDK. Use it with the
matching Conductor API/database/frontend/MCP maintenance cutover. Existing beta
tags and assets remain immutable.

Worker and manager binaries are conductor-runner and
conductor-runner-manager. Sources live in cmd/conductor-runner/ and the other
matching command directories. The private Go module and packages use runner
names. Built-in task packages declare minRunnerVersion: 0.0.1-beta.4.

Coordinated upgrade

Stop old API admissions and workers after accepted work settles. Apply the
application runner-terminology migration, deploy its matching API, frontend and
MCP, then install this runner release. Update service commands, local config and
environment names. Re-register when an old identity/configuration layout remains.
The old manager cannot discover the renamed /api/v1/runners/updates endpoint;
this release requires a manual cutover. Custom task archives must use
minRunnerVersion. User scripts that referenced previous worker environment
names need corresponding edits.

Job manifest formats 2 through 5 and portable bundle schema 2 retain their
structural versions. Their worker-named fields now use runner terminology; old
API/worker pairs are not supported across this cutover. Do not weaken version,
signature, hash, or capability checks to mix incompatible releases.

Portable release

Run tools/scripts/ci/Invoke-RunnerUnitTests.ps1, then build from a clean commit
with tools/scripts/runner/Build-Distribution.ps1 -Target All. While developing,
use -AllowDirtySource and do not publish those dirty-source artifacts.

The release contains Windows ZIP bundles and Linux/macOS tar.gz bundles for
amd64 and arm64, six managers, twelve SHA-256 sidecars, SHA256SUMS and
release-manifest.json. Node and its license are included in every bundle.

Publish the 26 files directly under dist/ as GitHub prerelease assets. Verify
the manifest source commit is the tagged commit, sourceDirty is false, and all
asset digests match. Keep generated distributions and credentials out of Git.

Native MSI/pkg/deb/rpm packages require native validation and signing identities
from native-release-checklist.md; portable cross-builds do not prove them.

Approval and publication

Use ConductorCI for release orchestration. A release job requires a Windows
runner with the pinned Go and Node toolchains and vulnerability scanner. Run the
canonical runner gate, build all six targets from the exact clean source commit,
then invoke tools/scripts/runner/Publish-GitHubRelease.ps1. The publisher verifies
all 26 asset digests before publishing the prerelease. Pass PromoteLatestApproved
only after explicit approval. ConductorCI pipeline setup is deferred; no automatic
publication trigger is configured in this repository.

Version tags (such as v0.0.1-beta.3) and published assets are immutable.
latest-approved is a lightweight, movable tag for the most recently approved
release commit. It moves only after verified publication, with an explicit lease
that prevents overwriting a concurrent promotion. An approved beta remains a
prerelease; the approval tag does not change its compatibility or channel.

Consumers should resolve latest-approved to the immutable version tag and use
that version's release assets. Source pins and installation manifests must
record the exact version/commit rather than pinning the movable alias.

The publisher uses GitHub REST release IDs for draft creation and binary uploads.
Interrupted draft uploads reuse assets with matching size and digest. Published
assets are immutable; CI-only fixes after a release require a new version for
a subsequent release from a different source commit.

Conductor Runner 0.0.1-beta.4

Runner beta release

Version: 0.0.1-beta.4. Tag: v0.0.1-beta.4.
Public repository: https://github.com/ConductorCI/runner.

Beta.4 adds runner-owned headers, author identity and final task messages for
all actions, with acknowledged attempt sequences and a sealed output drain.
Read task log boundaries for the protocol, failure
limits and coordinated API rollout.

Beta.3 changed the pre-release worker contract to runner throughout the CLI,
configuration, package metadata, API routes, services and SDK. Use it with the
matching Conductor API/database/frontend/MCP maintenance cutover. Existing beta
tags and assets remain immutable.

Worker and manager binaries are conductor-runner and
conductor-runner-manager. Sources live in cmd/conductor-runner/ and the other
matching command directories. The private Go module and packages use runner
names. Built-in task packages declare minRunnerVersion: 0.0.1-beta.4.

Coordinated upgrade

Stop old API admissions and workers after accepted work settles. Apply the
application runner-terminology migration, deploy its matching API, frontend and
MCP, then install this runner release. Update service commands, local config and
environment names. Re-register when an old identity/configuration layout remains.
The old manager cannot discover the renamed /api/v1/runners/updates endpoint;
this release requires a manual cutover. Custom task archives must use
minRunnerVersion. User scripts that referenced previous worker environment
names need corresponding edits.

Job manifest formats 2 through 5 and portable bundle schema 2 retain their
structural versions. Their worker-named fields now use runner terminology; old
API/worker pairs are not supported across this cutover. Do not weaken version,
signature, hash, or capability checks to mix incompatible releases.

Portable release

Run tools/scripts/ci/Invoke-RunnerUnitTests.ps1, then build from a clean commit
with tools/scripts/runner/Build-Distribution.ps1 -Target All. While developing,
use -AllowDirtySource and do not publish those dirty-source artifacts.

The release contains Windows ZIP bundles and Linux/macOS tar.gz bundles for
amd64 and arm64, six managers, twelve SHA-256 sidecars, SHA256SUMS and
release-manifest.json. Node and its license are included in every bundle.

Publish the 26 files directly under dist/ as GitHub prerelease assets. Verify
the manifest source commit is the tagged commit, sourceDirty is false, and all
asset digests match. Keep generated distributions and credentials out of Git.

Native MSI/pkg/deb/rpm packages require native validation and signing identities
from native-release-checklist.md; portable cross-builds do not prove them.

Approval and publication

The GitHub publication workflow uses a clean Windows checkout, the canonical
runner gate and all six release targets. It verifies source identity and all
26 uploaded asset digests before publishing the prerelease. The beta.3 bootstrap
is an explicitly approved workflow-path push on codex/runner-terminology-upload.
Subsequent manual runs expose an approve_latest checkbox, defaulting to false.

Version tags (such as v0.0.1-beta.3) and published assets are immutable.
latest-approved is a lightweight, movable tag for the most recently approved
release commit. It moves only after verified publication, with an explicit lease
that prevents overwriting a concurrent promotion. An approved beta remains a
prerelease; the approval tag does not change its compatibility or channel.

Consumers should resolve latest-approved to the immutable version tag and use
that version's release assets. Source pins and installation manifests must
record the exact version/commit rather than pinning the movable alias.

The publisher uses GitHub REST release IDs for draft creation and binary uploads.
Interrupted draft uploads reuse assets with matching size and digest. Published
assets are immutable; CI-only fixes after a release require a new version for
a subsequent release from a different source commit.