Fail closed when aos acompose silently bypasses requested Ward launch #810

New issue

Closed

opened 2026-07-30 12:09:30 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-07-30 12:09:30 +00:00

Member

Problem

The following command appears to request the integrated Ward, Agent Compose, and AOSguard launch:

aos acompose --warded --guarded --composed --role director --agent codex -- codex

With installed AOS v0.138.0, it instead selects the legacy acompose subcommand and starts the standalone _container-acompose path. It does not invoke ward agent director, and it silently drops the requested Ward lifecycle, broker boundary, and guarded capability.

This is materially different execution under a command that exits successfully. The operator can believe a director is Ward-brokered when it is actually a standalone AOS container.

The canonical integrated form works as intended:

aos --warded --guarded --composed --role director --agent codex

Cause

The acompose subcommand selects runAcompose.
Root capability flags remain accepted and readable after subcommand selection.
runAcompose calls the standalone composed-container launcher and does not honor --warded, --guarded, or --agent as integrated-launch selectors.
Ward routing exists only in the root runIntegratedLaunch action.

Outcome

Fail closed before Docker or Ward starts when the legacy aos acompose path receives integrated capability flags it does not honor. The error should identify the ignored or incompatible flag and show the canonical root launch shape.

Preserve the documented standalone form:

aos --role engineer acompose -- codex

Acceptance criteria

The exact reproduction exits nonzero before materialization or container launch.
aos acompose never silently ignores --warded, --guarded, or --agent.
The error points to aos --warded --guarded --composed --role <role> --agent <agent>.
The canonical integrated director command still renders a context bundle followed by ward agent director.
The documented standalone acompose command continues to work.
Tests cover capability flags both before and after the acompose token so parser ordering cannot reopen the bypass.
CLI help and the AOS launch documentation make the root-action versus legacy-subcommand boundary explicit.

## Problem The following command appears to request the integrated Ward, Agent Compose, and AOSguard launch: ```text aos acompose --warded --guarded --composed --role director --agent codex -- codex ``` With installed AOS v0.138.0, it instead selects the legacy `acompose` subcommand and starts the standalone `_container-acompose` path. It does not invoke `ward agent director`, and it silently drops the requested Ward lifecycle, broker boundary, and guarded capability. This is materially different execution under a command that exits successfully. The operator can believe a director is Ward-brokered when it is actually a standalone AOS container. The canonical integrated form works as intended: ```text aos --warded --guarded --composed --role director --agent codex ``` ## Cause * The `acompose` subcommand selects `runAcompose`. * Root capability flags remain accepted and readable after subcommand selection. * `runAcompose` calls the standalone composed-container launcher and does not honor `--warded`, `--guarded`, or `--agent` as integrated-launch selectors. * Ward routing exists only in the root `runIntegratedLaunch` action. ## Outcome Fail closed before Docker or Ward starts when the legacy `aos acompose` path receives integrated capability flags it does not honor. The error should identify the ignored or incompatible flag and show the canonical root launch shape. Preserve the documented standalone form: ```text aos --role engineer acompose -- codex ``` ## Acceptance criteria * The exact reproduction exits nonzero before materialization or container launch. * `aos acompose` never silently ignores `--warded`, `--guarded`, or `--agent`. * The error points to `aos --warded --guarded --composed --role <role> --agent <agent>`. * The canonical integrated director command still renders a context bundle followed by `ward agent director`. * The documented standalone `acompose` command continues to work. * Tests cover capability flags both before and after the `acompose` token so parser ordering cannot reopen the bypass. * CLI help and the AOS launch documentation make the root-action versus legacy-subcommand boundary explicit.

coilyco-ops added the

autonomy

headless

priority

labels

2026-07-30 12:09:30 +00:00

coilyco-ops referenced this issue

2026-07-31 09:51:24 +00:00

Make AOS guarded and composed by default, ship aoscompose and aosward #828

coilyco-ops referenced this issue

2026-08-02 04:43:27 +00:00

Attach composed agents to repo-free Ward collaboration clusters #851