remove docker image noise from ward runs #306

New issue

Closed

opened 2026-06-25 04:51:58 +00:00 by coilysiren · 2 comments

coilysiren commented

2026-06-25 04:51:58 +00:00

Owner

example

ward agent headless 'coilyco-flight-deck/cli-guard#162'
ward agent headless --driver claude: pre-flight - asking claude whether it can carry coilyco-flight-deck/cli-guard#162 before detaching...

This is an engine-side refactor wholly within cli-guard (the right repo — the issue explicitly frames it as the cli-guard counterpart to ward's collapse), and it's reversible and mergeable, which makes it a reasonable unattended candidate. The main unknown is API-design ambiguity: I'd be defining the container-backend and pre-flight-verdict seams without the ward consumer in hand, so the interface shapes are a judgment call — but the conservative move (extract interfaces, keep the existing worktree+gh+claude path as the default implementation, preserve AllowedOwners/ParseIssueRef/reservation/registry as-is) is well-specified by the issue text. Feasibility from the issue alone is sound; I'd verify the existing dispatch.Dispatcher shape and its tests in the fresh clone and design backward-compatible seams against them.

latest: Pulling from coilyco-flight-deck/agentic-os
Digest: sha256:2edbc8a05ea1b313a8f1687c0db262ca9f170848844ee2486356c7dd206773fa
Status: Image is up to date for forgejo.coilysiren.me/coilyco-flight-deck/agentic-os:latest
forgejo.coilysiren.me/coilyco-flight-deck/agentic-os:latest

What's next:
View a summary of image vulnerabilities and recommendations → docker scout quickview forgejo.coilysiren.me/coilyco-flight-deck/agentic-os:latest
beef7b468543c786f5329d03146a8f4e5286dbc236ddef0f366d60889f930b51

everything below "GO" is useless

if you actually enter a container, image pull / package install / etc ... is fine

example --- ward agent headless 'https://forgejo.coilysiren.me/coilyco-flight-deck/cli-guard/issues/162' ward agent headless --driver claude: pre-flight - asking claude whether it can carry coilyco-flight-deck/cli-guard#162 before detaching... This is an engine-side refactor wholly within cli-guard (the right repo — the issue explicitly frames it as the cli-guard counterpart to ward's collapse), and it's reversible and mergeable, which makes it a reasonable unattended candidate. The main unknown is API-design ambiguity: I'd be defining the container-backend and pre-flight-verdict seams without the ward consumer in hand, so the interface shapes are a judgment call — but the conservative move (extract interfaces, keep the existing worktree+gh+claude path as the default implementation, preserve AllowedOwners/ParseIssueRef/reservation/registry as-is) is well-specified by the issue text. Feasibility from the issue alone is sound; I'd verify the existing `dispatch.Dispatcher` shape and its tests in the fresh clone and design backward-compatible seams against them. GO latest: Pulling from coilyco-flight-deck/agentic-os Digest: sha256:2edbc8a05ea1b313a8f1687c0db262ca9f170848844ee2486356c7dd206773fa Status: Image is up to date for forgejo.coilysiren.me/coilyco-flight-deck/agentic-os:latest forgejo.coilysiren.me/coilyco-flight-deck/agentic-os:latest What's next: View a summary of image vulnerabilities and recommendations → docker scout quickview forgejo.coilysiren.me/coilyco-flight-deck/agentic-os:latest beef7b468543c786f5329d03146a8f4e5286dbc236ddef0f366d60889f930b51 --- everything below "GO" is useless if you actually enter a container, image pull / package install / etc ... is fine

coilyco-ops commented

2026-06-25 04:52:22 +00:00

Member

🔒 Reserved by ward agent --driver claude — container ward-ward-issue-306-claude-75e3381a on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-06-25T04:52:20Z). 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 --driver claude` — container `ward-ward-issue-306-claude-75e3381a` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-06-25T04:52:20Z). 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-25 05:04:00 +00:00

fix(agent): drop docker image noise from detached ward runs (ward#306)

coilysiren closed this issue

2026-06-25 05:04:00 +00:00

coilysiren commented

2026-06-25 05:04:57 +00:00

Author

Owner

Retro: this one was smaller than it first looked. The fix is a clean discriminator already sitting in the plan - plan.Interactive - so a detached run pulls and creates through a runDockerSilenced helper (DOCKER_CLI_HINTS=false plus a swallowed stdout), while interactive runs stream docker unchanged. Three launch sites (headless/work, sandbox, ask) now route through two shared helpers, so the behavior can't drift between them.

What fought back was entirely the surrounding gates, not the code: the docs note kept nudging agent-flags.md over the 4000-char cap (four trim passes), the 2-line code-comment cap clipped my helper docstrings, and the untracked test file only got comment-checked once staged - so it failed at commit after passing --all-files. This box also shipped without trufflehog, so I fetched the prebuilt binary before the commit hook would pass (no --no-verify).

Confidence is high on the create path (the container-id echo is the only stdout) and on killing the scout footer. The one spot I'd flag: I drop the pull's stderr wholesale for headless, so a slow/large pull now shows no progress at all on a detached run - fine for fire-and-forget, but if a pull ever hangs it'll look silent. Possible follow-up: a heartbeat line, or surface captured pull stderr only on failure rather than dropping it.

Retro: this one was smaller than it first looked. The fix is a clean discriminator already sitting in the plan - `plan.Interactive` - so a detached run pulls and creates through a `runDockerSilenced` helper (`DOCKER_CLI_HINTS=false` plus a swallowed stdout), while interactive runs stream docker unchanged. Three launch sites (headless/work, sandbox, ask) now route through two shared helpers, so the behavior can't drift between them. What fought back was entirely the surrounding gates, not the code: the docs note kept nudging `agent-flags.md` over the 4000-char cap (four trim passes), the 2-line code-comment cap clipped my helper docstrings, and the untracked test file only got comment-checked once staged - so it failed at commit after passing `--all-files`. This box also shipped without trufflehog, so I fetched the prebuilt binary before the commit hook would pass (no `--no-verify`). Confidence is high on the create path (the container-id echo is the only stdout) and on killing the scout footer. The one spot I'd flag: I drop the pull's stderr wholesale for headless, so a slow/large pull now shows no progress at all on a detached run - fine for fire-and-forget, but if a pull ever hangs it'll look silent. Possible follow-up: a heartbeat line, or surface captured pull stderr only on failure rather than dropping it.

coilysiren referenced this issue

2026-07-01 05:46:51 +00:00

Externalize fleet org/repo inventory from ward gate code, keep the gate (audit bucket D) #396

coilysiren referenced this issue

2026-07-01 05:46:51 +00:00

director: config-stored default scope (org list) so the launch folder stops deciding scope #398

coilysiren referenced this issue

2026-07-01 06:00:11 +00:00

Make ward agent-agnostic: isolate per-agent code into one package (a folder + docs file per agent) #401

coilysiren referenced this issue

2026-07-01 06:21:26 +00:00

Make ward agent-agnostic: isolate per-agent code into one package (a folder + docs file per agent) #401