coilyco-flight-deck/ward

Archived

Watch

Migrate the ephemeral-container sandbox + PID-1 bootstrap + substrate-warm to cli-guard #266

Closed

opened 2026-06-24 07:46:06 +00:00 by coilyco-ops · 3 comments

coilyco-ops commented

2026-06-24 07:46:06 +00:00

Owner

The container stack (container_compute.go, the sandbox half of container.go, container_bootstrap.go - the PID-1 entrypoint, substrate warm/TTL) is a general "run an agent in a throwaway least-access container" substrate with no ward-specific opinions except a few default constants. Any cli-guard consumer driving ephemeral agents wants it.

Move to a new cli-guard/cli/sandbox/container package; ward injects image/label/mount defaults + per-harness config writers via seams.
container_compute.go is pure/seam-able (med risk). container_bootstrap.go is PID-1 in every agent container - high risk, on the live dispatch path; do it carefully with an end-to-end dispatch verify.

From the 2026-06-24 ward/cli-guard boundary audit. See ward docs/architecture.md (the 3-layer model: cli-guard engine / ward-kdl generator / ward product). Related: ward#194, ward#200, cli-guard#139.

The container stack (`container_compute.go`, the sandbox half of `container.go`, `container_bootstrap.go` - the PID-1 entrypoint, substrate warm/TTL) is a general "run an agent in a throwaway least-access container" substrate with no ward-specific opinions except a few default constants. Any cli-guard consumer driving ephemeral agents wants it. - Move to a new `cli-guard/cli/sandbox/container` package; ward injects image/label/mount defaults + per-harness config writers via seams. - `container_compute.go` is pure/seam-able (med risk). `container_bootstrap.go` is PID-1 in **every** agent container - high risk, on the live dispatch path; do it carefully with an end-to-end dispatch verify. From the 2026-06-24 ward/cli-guard boundary audit. See ward docs/architecture.md (the 3-layer model: cli-guard engine / ward-kdl generator / ward product). Related: ward#194, ward#200, cli-guard#139.

coilyco-ops added the

priority

autonomy

live-collab

labels

2026-06-24 07:46:07 +00:00

coilyco-ops commented

2026-06-24 15:40:45 +00:00

Author

Owner

🛫 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.

cross-repo migration (code must land in cli-guard first, then ward rewires + bumps the dep) plus high-risk live-path PID-1 bootstrap requiring real dispatch verification and an undecided seam-design fork.

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 core obstacle is that this is inherently a cross-repo migration: the destination package cli-guard/cli/sandbox/container lives in the separate cli-guard repo, so the code must land and release there first, then ward bumps its dependency and rewires through the seams - a single fire-and-forget clone of ward alone cannot author both sides and merge them coherently. On top of that, container_bootstrap.go is PID-1 in every agent container on the live dispatch path; the issue itself demands an end-to-end dispatch verify, which is exactly the kind of high-blast-radius change that wants a human in the loop before merging to main. The seam design (what ward injects vs. what cli-guard owns) is also a genuine multi-path architectural fork with no decision recorded in the (empty) comment thread. This is not WRONG-REPO - the issue is correctly filed in ward as the migration's originating/consuming side - but it's not safely unattended.

NO-GO: cross-repo migration (code must land in cli-guard first, then ward rewires + bumps the dep) plus high-risk live-path PID-1 bootstrap requiring real dispatch verification and an undecided seam-design fork.

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. > cross-repo migration (code must land in cli-guard first, then ward rewires + bumps the dep) plus high-risk live-path PID-1 bootstrap requiring real dispatch verification and an undecided seam-design fork. 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 core obstacle is that this is inherently a cross-repo migration: the destination package `cli-guard/cli/sandbox/container` lives in the separate cli-guard repo, so the code must land and release there first, then ward bumps its dependency and rewires through the seams - a single fire-and-forget clone of ward alone cannot author both sides and merge them coherently. On top of that, `container_bootstrap.go` is PID-1 in every agent container on the live dispatch path; the issue itself demands an end-to-end dispatch verify, which is exactly the kind of high-blast-radius change that wants a human in the loop before merging to main. The seam design (what ward injects vs. what cli-guard owns) is also a genuine multi-path architectural fork with no decision recorded in the (empty) comment thread. This is not WRONG-REPO - the issue is correctly filed in ward as the migration's originating/consuming side - but it's not safely unattended. NO-GO: cross-repo migration (code must land in cli-guard first, then ward rewires + bumps the dep) plus high-risk live-path PID-1 bootstrap requiring real dispatch verification and an undecided seam-design fork. </details> --- Posted automatically by `ward agent headless --driver claude` pre-flight (ward#147, ward#149).   — Claude (she/her), via `ward agent`

coilyco-ops commented

2026-06-24 15:42:48 +00:00

Author

Owner

🛫 ward pre-flight: NO-GO

cross-repo migration (destination cli-guard, not the ward clone I'll receive) plus high-risk PID-1 dispatch-path code needing an end-to-end verify I can't run unattended.

full pre-flight read

This is a cross-repo migration whose destination is a different repo than the one I'll get cloned: the issue is filed in ward but the core deliverable is creating a new cli-guard/cli/sandbox/container package and moving code into it. From a fresh ward-only clone I can't author the cli-guard side, wire the seams across the boundary, or land a coordinated two-repo change unattended. On top of that the issue itself flags container_bootstrap.go as high-risk PID-1 code on the live dispatch path requiring an end-to-end dispatch verify, which is not something I can credibly validate in an ephemeral container with no human watching.

NO-GO: cross-repo migration (destination cli-guard, not the ward clone I'll receive) plus high-risk PID-1 dispatch-path code needing an end-to-end verify I can't run unattended.

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. > cross-repo migration (destination cli-guard, not the ward clone I'll receive) plus high-risk PID-1 dispatch-path code needing an end-to-end verify I can't run unattended. 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> This is a cross-repo migration whose destination is a *different* repo than the one I'll get cloned: the issue is filed in ward but the core deliverable is creating a new `cli-guard/cli/sandbox/container` package and moving code into it. From a fresh ward-only clone I can't author the cli-guard side, wire the seams across the boundary, or land a coordinated two-repo change unattended. On top of that the issue itself flags `container_bootstrap.go` as high-risk PID-1 code on the live dispatch path requiring an end-to-end dispatch verify, which is not something I can credibly validate in an ephemeral container with no human watching. NO-GO: cross-repo migration (destination cli-guard, not the ward clone I'll receive) plus high-risk PID-1 dispatch-path code needing an end-to-end verify I can't run unattended. </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-24 15:53:38 +00:00

fix(agent): thread --with-repo grants into the pre-flight read

coilyco-ops commented

2026-06-24 17:30:23 +00:00

Author

Owner

Re-triage (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24)

P2 - Migrate the container sandbox + PID-1 bootstrap to cli-guard, committed migration.
interactive - PID-1 in every agent container is high risk, needs an end-to-end dispatch verify checkpoint.

**Re-triage** (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24) - **P2** - Migrate the container sandbox + PID-1 bootstrap to cli-guard, committed migration. - **interactive** - PID-1 in every agent container is high risk, needs an end-to-end dispatch verify checkpoint.

coilysiren added

priority

and removed

priority

labels

2026-07-01 04:29:45 +00:00

coilysiren closed this issue

2026-07-06 20:30:11 +00:00

coilysiren referenced this issue

2026-07-07 09:44:55 +00:00

[tracking] Slim ward to the product layer (migrate engine/policy code to cli-guard) #265

Commenting is not possible because the repository is archived.