Agent bootstrap selects ward v0.544.0 before release assets exist

coilyco-ops commented

2026-07-10 00:50:32 +00:00

Member

Problem

A forwarded engineer dispatch on 2026-07-10 failed before container startup because ward selected v0.544.0 for the in-container bootstrap binary, but the release asset did not exist:

ward container: download Go bootstrap binary https://forgejo.coilysiren.me/coilyco-flight-deck/ward/releases/download/v0.544.0/ward-linux-arm64: unexpected status 404 Not Found: Not Found

The same issue was worked around by redispatching with --ward-version v0.543.0 --allow-ward-downgrade, which successfully reserved #903.

Expected

The dispatcher should not default to a release tag until the required platform assets exist, or it should fail with a clear deferred/retryable release-assets-not-ready state rather than treating the carried issue as a normal dispatch failure.

Do

Trace how host ward chose v0.544.0 for the container bootstrap.
Check whether the tag existed before release assets were uploaded, whether releases/latest pointed at an incomplete release, or whether asset publication failed.
Make bootstrap selection robust against a just-created tag/release with missing binary assets.
Preserve explicit --ward-version behavior.

Acceptance

A test or fixture covers a selected release whose required platform asset returns 404.
The failure is classified as release-assets-not-ready/deferred where appropriate, not as a carried issue implementation failure.
ward exec test passes, or the issue comment names the exact failing check.

Closes this issue when merged.

## Problem A forwarded engineer dispatch on 2026-07-10 failed before container startup because ward selected `v0.544.0` for the in-container bootstrap binary, but the release asset did not exist: ```text ward container: download Go bootstrap binary https://forgejo.coilysiren.me/coilyco-flight-deck/ward/releases/download/v0.544.0/ward-linux-arm64: unexpected status 404 Not Found: Not Found ``` The same issue was worked around by redispatching with `--ward-version v0.543.0 --allow-ward-downgrade`, which successfully reserved #903. ## Expected The dispatcher should not default to a release tag until the required platform assets exist, or it should fail with a clear deferred/retryable release-assets-not-ready state rather than treating the carried issue as a normal dispatch failure. ## Do - Trace how host ward chose `v0.544.0` for the container bootstrap. - Check whether the tag existed before release assets were uploaded, whether `releases/latest` pointed at an incomplete release, or whether asset publication failed. - Make bootstrap selection robust against a just-created tag/release with missing binary assets. - Preserve explicit `--ward-version` behavior. ## Acceptance - A test or fixture covers a selected release whose required platform asset returns 404. - The failure is classified as release-assets-not-ready/deferred where appropriate, not as a carried issue implementation failure. - `ward exec test` passes, or the issue comment names the exact failing check. Closes this issue when merged.

coilyco-ops added the

headless

P1

labels

2026-07-10 00:50:38 +00:00

coilyco-ops commented

2026-07-10 01:38:08 +00:00

Author

Member

Fresh evidence from the current binary failures:

The reported URL for v0.551.0 is healthy now: ward-linux-arm64 exists and returns 200. The release was published at 2026-07-10T01:31:51Z, while the asset's Last-Modified is 2026-07-10T01:33:57Z, so there was an approximately two-minute window where the release existed but the bootstrap binary 404'd.
This is not only transient. Recent releases with zero assets exist: v0.550.0, v0.547.0, v0.546.0, and v0.537.0.
For v0.550.0, the Actions list shows the release job succeeded and created the release, then publish-binaries was cancelled when a newer push/release run superseded it. That leaves a permanent published tag/release with no bootstrap binaries.

So the selector must treat release presence as insufficient. It should select only a release/tag whose required platform asset exists, or poll/defer with a release-assets-not-ready classification. It should also skip older empty releases rather than using latest blindly.

Fresh evidence from the current binary failures: * The reported URL for `v0.551.0` is healthy now: `ward-linux-arm64` exists and returns 200. The release was published at `2026-07-10T01:31:51Z`, while the asset's `Last-Modified` is `2026-07-10T01:33:57Z`, so there was an approximately two-minute window where the release existed but the bootstrap binary 404'd. * This is not only transient. Recent releases with zero assets exist: `v0.550.0`, `v0.547.0`, `v0.546.0`, and `v0.537.0`. * For `v0.550.0`, the Actions list shows the `release` job succeeded and created the release, then `publish-binaries` was cancelled when a newer push/release run superseded it. That leaves a permanent published tag/release with no bootstrap binaries. So the selector must treat release presence as insufficient. It should select only a release/tag whose required platform asset exists, or poll/defer with a release-assets-not-ready classification. It should also skip older empty releases rather than using `latest` blindly.

coilyco-ops commented

2026-07-10 01:39:31 +00:00

Author

Member

Correction / preferred fix direction from Kai:

The clean fix is to order the Forgejo release workflow correctly, not only make bootstrap tolerate bad release state.

Current shape:

release job creates the tag/release.
publish-binaries builds/uploads assets afterward.
During that gap, releases/latest and the release download URL can point at a tag whose required bootstrap asset does not exist.
If a newer push cancels publish-binaries, the tag/release can stay permanently assetless.

Preferred shape:

Build the binary matrix first.
Upload or stage the assets before the release becomes the selected public/latest bootstrap target, or otherwise make the release creation the final success boundary after asset verification.
A release/tag with missing ward-${os}-${arch} assets should not become the thing dispatch/bootstrap selects.
Keep bootstrap-side asset verification as a defensive guard, but do not rely on it as the primary fix for a misordered release pipeline.

Acceptance should include the release workflow ordering change, plus a regression check that a newly visible latest release has its platform assets present.

Correction / preferred fix direction from Kai: The clean fix is to order the Forgejo release workflow correctly, not only make bootstrap tolerate bad release state. Current shape: 1. `release` job creates the tag/release. 2. `publish-binaries` builds/uploads assets afterward. 3. During that gap, `releases/latest` and the release download URL can point at a tag whose required bootstrap asset does not exist. 4. If a newer push cancels `publish-binaries`, the tag/release can stay permanently assetless. Preferred shape: * Build the binary matrix first. * Upload or stage the assets before the release becomes the selected public/latest bootstrap target, or otherwise make the release creation the final success boundary after asset verification. * A release/tag with missing `ward-${os}-${arch}` assets should not become the thing dispatch/bootstrap selects. * Keep bootstrap-side asset verification as a defensive guard, but do not rely on it as the primary fix for a misordered release pipeline. Acceptance should include the release workflow ordering change, plus a regression check that a newly visible latest release has its platform assets present.

coilyco-ops referenced this issue

2026-07-10 03:29:45 +00:00

Remove runtime KDL/specgen dependency from ward core paths #929

coilyco-ops commented

2026-07-10 08:51:19 +00:00

Author

Member

Fresh sighting from the 2026-07-10 Codex director surface while trying to keep rolling usability fixes:

Dispatching coilyco-flight-deck/agentic-os#419 failed before an engineer container was observed.
Dispatching coilyco-flight-deck/ward#971 failed the same way.
Both failures selected v0.570.0 for the Go bootstrap binary and hit a missing release asset:
ward container: download Go bootstrap binary https://forgejo.coilysiren.me/coilyco-flight-deck/ward/releases/download/v0.570.0/ward-linux-arm64: unexpected status 404 Not Found: Not Found
The failed dispatch comments are agentic-os#419 comment 28613 and ward#971 comment 28615.

This is the same class as the original v0.544.0 report, but current rather than historical. It is now a director-lane blocker because capture-and-dispatch can file issues but cannot start sibling engineers until the bootstrap selector avoids tags whose platform assets are not published yet.

Fresh sighting from the 2026-07-10 Codex director surface while trying to keep rolling usability fixes: * Dispatching `coilyco-flight-deck/agentic-os#419` failed before an engineer container was observed. * Dispatching `coilyco-flight-deck/ward#971` failed the same way. * Both failures selected `v0.570.0` for the Go bootstrap binary and hit a missing release asset: `ward container: download Go bootstrap binary https://forgejo.coilysiren.me/coilyco-flight-deck/ward/releases/download/v0.570.0/ward-linux-arm64: unexpected status 404 Not Found: Not Found` * The failed dispatch comments are `agentic-os#419` comment `28613` and `ward#971` comment `28615`. This is the same class as the original `v0.544.0` report, but current rather than historical. It is now a director-lane blocker because capture-and-dispatch can file issues but cannot start sibling engineers until the bootstrap selector avoids tags whose platform assets are not published yet.

coilyco-ops commented

2026-07-10 08:55:09 +00:00

Author

Member

Additional current sighting from dispatching ward#977 at 2026-07-10T08:54Z:

The selected missing bootstrap tag has already advanced from v0.570.0 to v0.573.0:

ward container: download Go bootstrap binary https://forgejo.coilysiren.me/coilyco-flight-deck/ward/releases/download/v0.573.0/ward-linux-arm64: unexpected status 404 Not Found: Not Found

Failure comment: ward#977 comment 28648.

This suggests the selector is following freshly cut tags before platform assets are published, not one isolated bad release.

Additional current sighting from dispatching `ward#977` at 2026-07-10T08:54Z: The selected missing bootstrap tag has already advanced from `v0.570.0` to `v0.573.0`: `ward container: download Go bootstrap binary https://forgejo.coilysiren.me/coilyco-flight-deck/ward/releases/download/v0.573.0/ward-linux-arm64: unexpected status 404 Not Found: Not Found` Failure comment: `ward#977` comment `28648`. This suggests the selector is following freshly cut tags before platform assets are published, not one isolated bad release.

coilyco-ops commented

2026-07-10 08:55:30 +00:00

Author

Member

Release metadata check, 2026-07-10T08:56Z:

v0.573.0 - published 2026-07-10T08:54:23Z, assets: 0
v0.572.0 - published 2026-07-10T08:54:09Z, assets: 0
v0.571.0 - published 2026-07-10T08:53:53Z, assets: 0
v0.570.0 - published 2026-07-10T08:38:17Z, now has 9 assets including ward-linux-arm64
v0.569.0 and older nearby releases also have the expected assets

This points to a concrete rule for the bootstrap selector: choose the newest release that already contains the required platform asset, not simply the newest published release/tag. A retry helps only if the selected release will gain assets soon enough; selecting the latest known-good asset-bearing release would keep dispatch moving during rapid release churn.

Release metadata check, 2026-07-10T08:56Z: * `v0.573.0` - published `2026-07-10T08:54:23Z`, `assets: 0` * `v0.572.0` - published `2026-07-10T08:54:09Z`, `assets: 0` * `v0.571.0` - published `2026-07-10T08:53:53Z`, `assets: 0` * `v0.570.0` - published `2026-07-10T08:38:17Z`, now has 9 assets including `ward-linux-arm64` * `v0.569.0` and older nearby releases also have the expected assets This points to a concrete rule for the bootstrap selector: choose the newest release that already contains the required platform asset, not simply the newest published release/tag. A retry helps only if the selected release will gain assets soon enough; selecting the latest known-good asset-bearing release would keep dispatch moving during rapid release churn.

coilyco-ops commented

2026-07-10 08:56:09 +00:00

Author

Member

WARD-DISPATCH: failed ❌

failure details

This forwarded dispatch failed after the issue was already reserved.

Attempted harness: codex
Attempted run: ward agent engineer coilyco-flight-deck/ward#905 --harness codex
Container: engineer-codex-ward-905
Container created: no running engineer was observed.
Host log: /Users/kai/.ward/agent-logs/dispatch/20260710T085606Z-director-codex-dj94-coilyco-flight-deck-ward-905.log
Failure: ward container: download Go bootstrap binary https://forgejo.coilysiren.me/coilyco-flight-deck/ward/releases/download/v0.573.0/ward-linux-arm64: unexpected status 404 Not Found: Not Found

Retry: choose another harness if the first one is down, or rerun with --force if the reservation is stale.

— Codex, via ward agent

WARD-DISPATCH: failed ❌ <details><summary>failure details</summary> This forwarded dispatch failed after the issue was already reserved. Attempted harness: `codex` Attempted run: `ward agent engineer coilyco-flight-deck/ward#905 --harness codex` Container: `engineer-codex-ward-905` Container created: no running engineer was observed. Host log: `/Users/kai/.ward/agent-logs/dispatch/20260710T085606Z-director-codex-dj94-coilyco-flight-deck-ward-905.log` Failure: `ward container: download Go bootstrap binary https://forgejo.coilysiren.me/coilyco-flight-deck/ward/releases/download/v0.573.0/ward-linux-arm64: unexpected status 404 Not Found: Not Found` Retry: choose another harness if the first one is down, or rerun with `--force` if the reservation is stale. </details>  — Codex, via `ward agent`

coilyco-ops commented

2026-07-10 08:57:18 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-ward-905 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-10T08:57:18Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL). --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-flight-deck/ward#905 · branch issue-905 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-ward-905 · ward v0.569.0 · dispatched 2026-07-10T08:57:18Z
Comment thread: 6 included in the pre-flight read, 0 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-10T01:38:08Z), @coilyco-ops (2026-07-10T01:39:31Z), @coilyco-ops (2026-07-10T08:51:19Z), @coilyco-ops (2026-07-10T08:55:09Z), @coilyco-ops (2026-07-10T08:55:30Z), @coilyco-ops (2026-07-10T08:56:09Z)

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.569.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-905` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T08:57:18Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (1h TTL). `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh**. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/ward#905` · branch `issue-905` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-ward-905` · ward `v0.569.0` · dispatched `2026-07-10T08:57:18Z` - **Comment thread:** 6 included in the pre-flight read, 0 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-10T01:38:08Z), @coilyco-ops (2026-07-10T01:39:31Z), @coilyco-ops (2026-07-10T08:51:19Z), @coilyco-ops (2026-07-10T08:55:09Z), @coilyco-ops (2026-07-10T08:55:30Z), @coilyco-ops (2026-07-10T08:56:09Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.569.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops commented

2026-07-10 10:00:24 +00:00

Author

Member

Fresh sighting from 2026-07-10T09:53Z while dispatching ward#1000 from the director surface:

Dispatch failed before an engineer container was observed.
The selected bootstrap tag had advanced again, this time to v0.579.0.
Failure:

ward container: download Go bootstrap binary https://forgejo.coilysiren.me/coilyco-flight-deck/ward/releases/download/v0.579.0/ward-linux-arm64: unexpected status 404 Not Found: Not Found

A retry pinned to --ward-version v0.573.0 avoided the immediate 404 path but then deferred on global capacity, so the asset-race problem remains a dispatch reliability blocker rather than a one-off bad tag.

Fresh sighting from 2026-07-10T09:53Z while dispatching `ward#1000` from the director surface: * Dispatch failed before an engineer container was observed. * The selected bootstrap tag had advanced again, this time to `v0.579.0`. * Failure: ```text ward container: download Go bootstrap binary https://forgejo.coilysiren.me/coilyco-flight-deck/ward/releases/download/v0.579.0/ward-linux-arm64: unexpected status 404 Not Found: Not Found ``` A retry pinned to `--ward-version v0.573.0` avoided the immediate 404 path but then deferred on global capacity, so the asset-race problem remains a dispatch reliability blocker rather than a one-off bad tag.

coilyco-ops commented

2026-07-10 10:00:40 +00:00

Author

Member

WARD-DISPATCH: deferred ⏸

deferred details

This forwarded dispatch was deferred after the issue was already reserved.

Attempted harness: codex
Attempted run: ward agent engineer coilyco-flight-deck/ward#905 --harness codex --ward-version v0.569.0 --details Fix ward#905. Bootstrap selection is still picking assetless releases, now v0.579.0. Make release selection require the platform asset or classify as release-assets-not-ready, preserve explicit --ward-version behavior, add tests for missing assets, and close ward#905 when landed. --force
Container: engineer-codex-ward-905
Container created: no running engineer was observed.
Host log: /Users/kai/.ward/agent-logs/dispatch/20260710T100038Z-director-codex-zv99-coilyco-flight-deck-ward-905.log
Capacity: ward agent engineer --harness codex: global engineer limit is reached: 12 running (limit 12); wait for a run to finish or run ward agent reap for stale engineers

Retry: the issue stays queued and the director will try again when a slot opens.

— Codex, via ward agent

WARD-DISPATCH: deferred ⏸ <details><summary>deferred details</summary> This forwarded dispatch was deferred after the issue was already reserved. Attempted harness: `codex` Attempted run: `ward agent engineer coilyco-flight-deck/ward#905 --harness codex --ward-version v0.569.0 --details Fix ward#905. Bootstrap selection is still picking assetless releases, now v0.579.0. Make release selection require the platform asset or classify as release-assets-not-ready, preserve explicit --ward-version behavior, add tests for missing assets, and close ward#905 when landed. --force` Container: `engineer-codex-ward-905` Container created: no running engineer was observed. Host log: `/Users/kai/.ward/agent-logs/dispatch/20260710T100038Z-director-codex-zv99-coilyco-flight-deck-ward-905.log` Capacity: `ward agent engineer --harness codex: global engineer limit is reached: 12 running (limit 12); wait for a run to finish or run `ward agent reap` for stale engineers` Retry: the issue stays queued and the director will try again when a slot opens. </details>  — Codex, via `ward agent`

coilyco-ops commented

2026-07-10 10:20:09 +00:00

Author

Member

Additional live evidence, 2026-07-10 10:20 UTC:

Three fresh director-dispatched runs failed before container startup because host ward selected v0.580.0, whose ward-linux-arm64 asset returned 404:

agentic-os#431 dispatch failed with https://forgejo.coilysiren.me/coilyco-flight-deck/ward/releases/download/v0.580.0/ward-linux-arm64: unexpected status 404 Not Found (agentic-os#431 issuecomment-30074).
ward#1009 dispatch failed with the same missing v0.580.0 asset (ward#1009 issuecomment-30073).
agentic-os#419 dispatch failed with the same missing v0.580.0 asset (agentic-os#419 issuecomment-30075).

This is still active, not just the original v0.544.0 instance. The dispatcher is treating a tag/release without the required platform asset as the default bootstrap version.

Additional live evidence, 2026-07-10 10:20 UTC: Three fresh director-dispatched runs failed before container startup because host ward selected `v0.580.0`, whose `ward-linux-arm64` asset returned 404: * `agentic-os#431` dispatch failed with `https://forgejo.coilysiren.me/coilyco-flight-deck/ward/releases/download/v0.580.0/ward-linux-arm64: unexpected status 404 Not Found` (`agentic-os#431 issuecomment-30074`). * `ward#1009` dispatch failed with the same missing `v0.580.0` asset (`ward#1009 issuecomment-30073`). * `agentic-os#419` dispatch failed with the same missing `v0.580.0` asset (`agentic-os#419 issuecomment-30075`). This is still active, not just the original `v0.544.0` instance. The dispatcher is treating a tag/release without the required platform asset as the default bootstrap version.

coilyco-ops commented

2026-07-10 17:14:54 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-ward-905 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-10T17:14:53Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL). --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-flight-deck/ward#905 · branch issue-905 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-ward-905 · ward v0.584.0 · dispatched 2026-07-10T17:14:53Z
Comment thread: 9 included in the pre-flight read, 1 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-10T01:38:08Z), @coilyco-ops (2026-07-10T01:39:31Z), @coilyco-ops (2026-07-10T08:51:19Z), @coilyco-ops (2026-07-10T08:55:09Z), @coilyco-ops (2026-07-10T08:55:30Z), @coilyco-ops (2026-07-10T08:56:09Z), @coilyco-ops (2026-07-10T10:00:24Z), @coilyco-ops (2026-07-10T10:00:40Z), @coilyco-ops (2026-07-10T10:20:09Z)
- stripped: @coilyco-ops (2026-07-10T08:57:18Z)

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.584.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-905` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T17:14:53Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (1h TTL). `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh**. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/ward#905` · branch `issue-905` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-ward-905` · ward `v0.584.0` · dispatched `2026-07-10T17:14:53Z` - **Comment thread:** 9 included in the pre-flight read, 1 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-10T01:38:08Z), @coilyco-ops (2026-07-10T01:39:31Z), @coilyco-ops (2026-07-10T08:51:19Z), @coilyco-ops (2026-07-10T08:55:09Z), @coilyco-ops (2026-07-10T08:55:30Z), @coilyco-ops (2026-07-10T08:56:09Z), @coilyco-ops (2026-07-10T10:00:24Z), @coilyco-ops (2026-07-10T10:00:40Z), @coilyco-ops (2026-07-10T10:20:09Z) - stripped: @coilyco-ops (2026-07-10T08:57:18Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.584.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a pull request that will close it,

2026-07-10 17:27:35 +00:00

Agent bootstrap selects ward v0.544.0 before release assets exist #1052

coilyco-ops closed this issue

2026-07-10 17:55:41 +00:00

coilyco-ops commented

2026-07-10 17:56:15 +00:00

Author

Member

WARD-OUTCOME: merge-ready

details

workflow: pull-requests-and-merge; review summary: skipped review gate: skipped by `~/.ward/config.yaml` default Implementation felt straightforward once the stale-arch test and the bundle-root ref were corrected. Confidence: high. Surprise: Forgejo’s merge API stayed uncooperative, so the code landed on `main` directly and the PR was closed after the branch was synced. Follow-up: none.

WARD-OUTCOME: merge-ready <details><summary>details</summary> workflow: pull-requests-and-merge; review summary: skipped review gate: skipped by `~/.ward/config.yaml` default Implementation felt straightforward once the stale-arch test and the bundle-root ref were corrected. Confidence: high. Surprise: Forgejo’s merge API stayed uncooperative, so the code landed on `main` directly and the PR was closed after the branch was synced. Follow-up: none. </details>

coilysiren referenced this issue

2026-07-14 15:27:09 +00:00

director should emit colorized, space buffered, visually distinct messages about the categories of actions its performing on startup #1283

Rows
Columns

Agent bootstrap selects ward v0.544.0 before release assets exist #905

Problem

Expected

Do

Acceptance