ward scoop manifest is stuck at 0.353.0 and does not advance #1

New issue

Closed

opened 2026-07-03 10:34:06 +00:00 by coilysiren · 2 comments

coilysiren commented

2026-07-03 10:34:06 +00:00

Owner

Symptom

On Windows, ward upgrade drives scoop update ward, but Scoop reports ward 0.353.0 (latest version) even though the canonical Forgejo releases have moved beyond that.

Observed on 2026-07-03:

local scoop list shows ward 0.353.0 from the flight-deck bucket
the bucket commit that introduced the manifest set bucket/ward.json to 0.353.0
the current bucket head still needs checking against the autoupdate pipeline, but the practical user-facing result is that the bucket is not advancing and ward upgrade stalls at 0.353.0

Why this is the right layer

This is a Scoop-channel problem, not a GitHub mirror problem. Windows upgrade is reading the flight-deck bucket manifest. If the manifest version does not move, scoop update ward cannot move either.

The manifest added in commit 4ca9daefb727307eaf2fcf50027b07b888c98cd2 pins:

"version": "0.353.0"
checkver.url = https://forgejo.coilysiren.me/coilyco-flight-deck/ward/releases.atom
autoupdate templates for both Windows architectures

So either:

the bucket autoupdate workflow is missing/broken
the regex/feed contract is not matching new ward releases
or there is no job landing the updated manifest back into coilyco-flight-deck/scoop-bucket

Done-condition

bucket/ward.json advances past 0.353.0 to the current ward release
scoop update ward on Windows upgrades to that newer version
the bucket has a durable automation path so later ward releases keep advancing without hand edits

## Symptom On Windows, `ward upgrade` drives `scoop update ward`, but Scoop reports `ward 0.353.0 (latest version)` even though the canonical Forgejo releases have moved beyond that. Observed on 2026-07-03: - local `scoop list` shows `ward 0.353.0` from the `flight-deck` bucket - the bucket commit that introduced the manifest set `bucket/ward.json` to `0.353.0` - the current bucket head still needs checking against the autoupdate pipeline, but the practical user-facing result is that the bucket is not advancing and `ward upgrade` stalls at `0.353.0` ## Why this is the right layer This is a Scoop-channel problem, not a GitHub mirror problem. Windows upgrade is reading the `flight-deck` bucket manifest. If the manifest version does not move, `scoop update ward` cannot move either. The manifest added in commit `4ca9daefb727307eaf2fcf50027b07b888c98cd2` pins: - `"version": "0.353.0"` - `checkver.url = https://forgejo.coilysiren.me/coilyco-flight-deck/ward/releases.atom` - `autoupdate` templates for both Windows architectures So either: - the bucket autoupdate workflow is missing/broken - the regex/feed contract is not matching new ward releases - or there is no job landing the updated manifest back into `coilyco-flight-deck/scoop-bucket` ## Done-condition - `bucket/ward.json` advances past `0.353.0` to the current ward release - `scoop update ward` on Windows upgrades to that newer version - the bucket has a durable automation path so later ward releases keep advancing without hand edits

coilyco-ops commented

2026-07-03 10:34:26 +00:00

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-scoop-bucket-1 on host KAI-DESKTOP-TOWER is carrying this issue (reserved 2026-07-03T10:34:21Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s 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).

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-scoop-bucket-1` on host `KAI-DESKTOP-TOWER` is carrying this issue (reserved 2026-07-03T10:34:21Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s 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).  — Claude (she/her), via `ward agent`

coilysiren referenced this issue from a commit

2026-07-03 10:41:27 +00:00

feat(autoupdate): advance ward past 0.353.0 and automate future bumps

coilysiren closed this issue

2026-07-03 10:41:27 +00:00

coilysiren commented

2026-07-03 10:41:57 +00:00

Author

Owner

WARD-OUTCOME: done - added an hourly Forgejo autoupdate job + portable updater; ward advanced 0.353.0 -> 0.359.0, o2r 0.0.0 -> 0.2.0, both hashes verified live.

Candid retro: the symptom framed this as "the manifest is stale," but the real hole was that nothing ever wrote the manifest back - scoop update on a client only diffs installed-vs-manifest, it never re-derives from upstream. So the fix is a job that lives in the bucket, not a hand-edit.

The thing that fought back was subtle and lucky to catch: the newest ward tags (v0.359.0, v0.357.0) had zero release assets when I first probed them - only every other tag carried Windows binaries. A naive "bump to newest tag" would have pinned a 404. That turned into the load-bearing design choice: walk tags newest-first and take the newest one whose assets AND .sha256 sidecars all resolve. Amusingly, by the time I ran it, v0.359.0's assets had finished uploading, so it landed there - live system, releases minting mid-run.

Confidence is high on the bump itself (every hash re-checked against the live sidecar, HTTP 200 on each binary, updater is idempotent). One honest unknown I could not exercise from this Linux container: whether the scheduled workflow's auto-issued job token has push-to-main rights on the runner - I mirrored permissions: contents: write and the runs-on: docker convention from the upstream release pipelines, but the first real cron tick is the true test. Worth a glance at the first scheduled run; if it can't push, swapping in a PAT secret (as ward's release.yml does with CI_RELEASE_TOKEN) is the fallback. Follow-up worth filing: the o2r manifest was a 0.0.0 placeholder and got swept along to 0.2.0 - correct, but someone may want to confirm that was intended.

WARD-OUTCOME: done - added an hourly Forgejo autoupdate job + portable updater; ward advanced 0.353.0 -> 0.359.0, o2r 0.0.0 -> 0.2.0, both hashes verified live. Candid retro: the symptom framed this as "the manifest is stale," but the real hole was that nothing ever wrote the manifest back - `scoop update` on a client only diffs installed-vs-manifest, it never re-derives from upstream. So the fix is a job that lives in the bucket, not a hand-edit. The thing that fought back was subtle and lucky to catch: the newest ward tags (v0.359.0, v0.357.0) had zero release assets when I first probed them - only every *other* tag carried Windows binaries. A naive "bump to newest tag" would have pinned a 404. That turned into the load-bearing design choice: walk tags newest-first and take the newest one whose assets AND .sha256 sidecars all resolve. Amusingly, by the time I ran it, v0.359.0's assets had finished uploading, so it landed there - live system, releases minting mid-run. Confidence is high on the bump itself (every hash re-checked against the live sidecar, HTTP 200 on each binary, updater is idempotent). One honest unknown I could not exercise from this Linux container: whether the scheduled workflow's auto-issued job token has push-to-main rights on the runner - I mirrored `permissions: contents: write` and the `runs-on: docker` convention from the upstream release pipelines, but the first real cron tick is the true test. Worth a glance at the first scheduled run; if it can't push, swapping in a PAT secret (as ward's release.yml does with CI_RELEASE_TOKEN) is the fallback. Follow-up worth filing: the o2r manifest was a 0.0.0 placeholder and got swept along to 0.2.0 - correct, but someone may want to confirm that was intended.