Re-express agent_upgrade.go Forgejo release check as ward-kdl forgejo guardfile (retire its bespoke HTTP client) #172

New issue

Closed

opened 2026-06-18 07:43:25 +00:00 by coilysiren · 1 comment

coilysiren commented

2026-06-18 07:43:25 +00:00

Owner

What

cmd/ward/agent_upgrade.go carries its own hand-rolled Forgejo REST client (net/http GET against /api/v1/repos/<owner>/<repo>/releases/latest) to check whether a newer ward release exists. It is a second HTTP client, separate from cmd/ward/forgejo_issue.go.

The ward-kdl forgejo guardfile (cmd/ward-kdl/ward-kdl.forgejo.guardfile.kdl) already grants can get release / can list release. So this release-latest lookup is a ward-kdl specverb call, not a bespoke client.

Why this is its own issue

ward#92 ("cut the binary over to the ward-kdl forgejo guardfile and retire forgejo_issue.go") scopes only the forgejo_issue.go client. It does not touch agent_upgrade.go, which holds a duplicate HTTP path. If #92 lands as written, this second client survives and the "no hand-rolled Forgejo HTTP in ward" goal is incomplete.

Asked-for change

Re-express the agent-upgrade release check as a ward-kdl forgejo get release (latest) call.
Delete the bespoke net/http client in agent_upgrade.go.
Confirm no third hand-rolled Forgejo client remains (grep api/v1 under cmd/ward/).

Part of the coily -> ward -> ward-kdl consolidation (epic ward#91, milestone #6).

## What `cmd/ward/agent_upgrade.go` carries its **own** hand-rolled Forgejo REST client (`net/http` GET against `/api/v1/repos/<owner>/<repo>/releases/latest`) to check whether a newer `ward` release exists. It is a second HTTP client, separate from `cmd/ward/forgejo_issue.go`. The ward-kdl forgejo guardfile (`cmd/ward-kdl/ward-kdl.forgejo.guardfile.kdl`) already grants `can get release` / `can list release`. So this release-latest lookup is a ward-kdl specverb call, not a bespoke client. ## Why this is its own issue ward#92 ("cut the binary over to the ward-kdl forgejo guardfile and **retire forgejo_issue.go**") scopes only the `forgejo_issue.go` client. It does **not** touch `agent_upgrade.go`, which holds a duplicate HTTP path. If #92 lands as written, this second client survives and the "no hand-rolled Forgejo HTTP in ward" goal is incomplete. ## Asked-for change - Re-express the agent-upgrade release check as a ward-kdl forgejo `get release` (latest) call. - Delete the bespoke `net/http` client in `agent_upgrade.go`. - Confirm no third hand-rolled Forgejo client remains (grep `api/v1` under `cmd/ward/`). Part of the coily -> ward -> ward-kdl consolidation (epic ward#91, milestone #6).

coilyco-ops added this to the coily to ward to ward-kdl consolidation milestone

2026-06-18 07:51:53 +00:00

coilyco-ops commented

2026-06-18 08:51:49 +00:00

Member

🔒 Reserved by ward agent claude — container ward-ward-issue-172-claude-deb1963a on host kais-macbook-pro.local is carrying this issue (reserved 2026-06-18T08:51:48Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent claude` — container `ward-ward-issue-172-claude-deb1963a` on host `kais-macbook-pro.local` is carrying this issue (reserved 2026-06-18T08:51:48Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilysiren referenced this issue from a commit

2026-06-18 09:06:17 +00:00

refactor(agent): route stale-ward release check through ward ops forgejo specverb (#172)

coilysiren closed this issue

2026-06-18 09:06:17 +00:00