encourage image publish / rollout to be triggered via agents pushing to CI #273

New issue

Closed

opened 2026-06-25 04:47:11 +00:00 by coilysiren · 1 comment

coilysiren commented

2026-06-25 04:47:11 +00:00

Owner

inspired by this

ward agent headless --repo coilyco-flight-deck/ward --repo coilyco-flight-deck/agentic-os --repo coilyco-flight-deck/infrastructure 'coilyco-flight-deck/ward#301'
ward agent headless --driver claude: pre-flight - asking claude whether it can carry coilyco-flight-deck/ward#301 before detaching...

The deliverable here isn't code logic, it's republishing the fleet-wide dev-base :latest image, which is an externally-visible release/propagation action that needs container-registry push credentials and a working Docker build context. An ephemeral headless container almost certainly won't hold those publish creds (image publishing is normally a CI/bot operation, and aos doctrine explicitly keeps fleet rollout/release out of agent hands), and the verification step ("confirm with a fresh headless run that the agent reads /etc/ward-git-credentials and pushes attribute to coilyco-ops") requires spawning real headless runs I can't reliably orchestrate unattended. The only part squarely in agent scope is the fallback ("move the entrypoint re-assert to immediately before the setpriv drop"), which is a small code edit in entrypoint.sh — but that's conditional on the rebuild reproducing, and I can't get there without first publishing. A human (or CI) should own the image republish and confirm attribution before this is safe to call done.

NO-GO: core deliverable is republishing a fleet-consumed :latest image — an externally-visible release op needing registry push creds and headless-run verification that an ephemeral agent container won't have, and aos doctrine reserves image publish/rollout for CI/human.

ward agent headless --driver claude: pre-flight NO-GO for coilyco-flight-deck/ward#301; launching nothing, commenting on the issue.
ward agent headless --driver claude: commented NO-GO on coilyco-flight-deck/ward#301 - coilyco-flight-deck/ward#301

inspired by this --- ward agent headless --repo coilyco-flight-deck/ward --repo coilyco-flight-deck/agentic-os --repo coilyco-flight-deck/infrastructure 'https://forgejo.coilysiren.me/coilyco-flight-deck/ward/issues/301' ward agent headless --driver claude: pre-flight - asking claude whether it can carry coilyco-flight-deck/ward#301 before detaching... The deliverable here isn't code logic, it's republishing the fleet-wide `dev-base :latest` image, which is an externally-visible release/propagation action that needs container-registry push credentials and a working Docker build context. An ephemeral headless container almost certainly won't hold those publish creds (image publishing is normally a CI/bot operation, and aos doctrine explicitly keeps fleet rollout/release out of agent hands), and the verification step ("confirm with a fresh headless run that the agent reads `/etc/ward-git-credentials` and pushes attribute to `coilyco-ops`") requires spawning real headless runs I can't reliably orchestrate unattended. The only part squarely in agent scope is the fallback ("move the entrypoint re-assert to immediately before the setpriv drop"), which is a small code edit in `entrypoint.sh` — but that's conditional on the rebuild reproducing, and I can't get there without first publishing. A human (or CI) should own the image republish and confirm attribution before this is safe to call done. NO-GO: core deliverable is republishing a fleet-consumed `:latest` image — an externally-visible release op needing registry push creds and headless-run verification that an ephemeral agent container won't have, and aos doctrine reserves image publish/rollout for CI/human. ward agent headless --driver claude: pre-flight NO-GO for coilyco-flight-deck/ward#301; launching nothing, commenting on the issue. ward agent headless --driver claude: commented NO-GO on coilyco-flight-deck/ward#301 - https://forgejo.coilysiren.me/coilyco-flight-deck/ward/issues/301

coilyco-ops commented

2026-06-25 04:47:41 +00:00

Member

🛫 ward pre-flight: NO-GO

ward agent headless --driver claude ran a pre-flight feasibility read on this issue before detaching a fire-and-forget run, and the agent judged it NO-GO - it should not be carried unattended until a human weighs in.

issue is a stub ("inspired by this" + a pasted transcript) with no concrete deliverable, acceptance criteria, or chosen approach — scope is undefined and must be specified before an unattended run can implement and merge it.

No container was launched. Review the issue (clarify the scope, resolve the unknown, or split it), then re-dispatch - ward agent headless --driver claude <ref> --no-preflight skips this gate once you've decided it's good to go.

full pre-flight read

The issue body is essentially just the title plus a pasted NO-GO transcript from ward#301 — there's no concrete spec, no acceptance criteria, and no comment thread resolving what "encourage" should produce. The deliverable could be anything from a doctrine paragraph in AGENTS.md, to a new CI workflow that agents trigger by pushing, to a ward verb change, and those land in different files (or different repos) with very different blast radius. Without the author naming the actual artifact and done-condition, an unattended run would have to guess the scope and could easily build the wrong thing or touch the wrong surface. This needs a human to say concretely what shape the change takes before it's safe to carry to merge.

NO-GO: issue is a stub ("inspired by this" + a pasted transcript) with no concrete deliverable, acceptance criteria, or chosen approach — scope is undefined and must be specified before an unattended run can implement and merge it.

Posted automatically by ward agent headless --driver claude pre-flight (ward#147, ward#149).

— Claude (she/her), via ward agent

### 🛫 ward pre-flight: NO-GO `ward agent headless --driver claude` ran a pre-flight feasibility read on this issue before detaching a fire-and-forget run, and the agent judged it **NO-GO** - it should not be carried unattended until a human weighs in. > issue is a stub ("inspired by this" + a pasted transcript) with no concrete deliverable, acceptance criteria, or chosen approach — scope is undefined and must be specified before an unattended run can implement and merge it. No container was launched. Review the issue (clarify the scope, resolve the unknown, or split it), then re-dispatch - `ward agent headless --driver claude <ref> --no-preflight` skips this gate once you've decided it's good to go. <details><summary>full pre-flight read</summary> The issue body is essentially just the title plus a pasted NO-GO transcript from ward#301 — there's no concrete spec, no acceptance criteria, and no comment thread resolving what "*encourage*" should produce. The deliverable could be anything from a doctrine paragraph in AGENTS.md, to a new CI workflow that agents trigger by pushing, to a `ward` verb change, and those land in different files (or different repos) with very different blast radius. Without the author naming the actual artifact and done-condition, an unattended run would have to guess the scope and could easily build the wrong thing or touch the wrong surface. This needs a human to say concretely what shape the change takes before it's safe to carry to merge. NO-GO: issue is a stub ("inspired by this" + a pasted transcript) with no concrete deliverable, acceptance criteria, or chosen approach — scope is undefined and must be specified before an unattended run can implement and merge it. </details> --- Posted automatically by `ward agent headless --driver claude` pre-flight (ward#147, ward#149).   — Claude (she/her), via `ward agent`

coilysiren referenced this issue from a commit

2026-06-25 08:43:24 +00:00

docs(agents): image republish is in agent scope - push triggers CI, never a NO-GO

coilysiren closed this issue

2026-06-25 08:43:24 +00:00