Use ACompose's temporary shadow workspace model for standalone AOS #926

New issue

Closed

opened 2026-08-06 03:50:48 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-08-06 03:50:48 +00:00

Owner

Problem

aoscompose is meant to run closely to the operating model of acompose, but standalone launch currently follows a different workspace shape. Native AOS creates the temporary, fleet-shaped shadow workspace driven by Agent Compose's residency plan. Standalone AOS instead mounts the caller's CWD directly.

That divergence makes capability loss visible to Kai and means the two launch modes cannot be treated as operationally equivalent.

Desired outcome

Layer standalone AOS on the same temporary ACompose shadow-workspace projection used by native launches, then apply the standalone container boundary around that projected workspace.

Acceptance signals

Standalone and native launches derive their workspace topology from the same composed residency plan.
The standalone container receives the temporary shadow workspace rather than a direct CWD-only mount.
Lease, cleanup, recoverability, and dirty-worktree protections remain intact.
The selected repository and working directory agree across acompose and aoscompose for equivalent inputs.
Documentation explains the shared model and any unavoidable container-specific difference.

## Problem `aoscompose` is meant to run closely to the operating model of `acompose`, but standalone launch currently follows a different workspace shape. Native AOS creates the temporary, fleet-shaped shadow workspace driven by Agent Compose's residency plan. Standalone AOS instead mounts the caller's CWD directly. That divergence makes capability loss visible to Kai and means the two launch modes cannot be treated as operationally equivalent. ## Desired outcome Layer standalone AOS on the same temporary ACompose shadow-workspace projection used by native launches, then apply the standalone container boundary around that projected workspace. ## Acceptance signals * Standalone and native launches derive their workspace topology from the same composed residency plan. * The standalone container receives the temporary shadow workspace rather than a direct CWD-only mount. * Lease, cleanup, recoverability, and dirty-worktree protections remain intact. * The selected repository and working directory agree across `acompose` and `aoscompose` for equivalent inputs. * Documentation explains the shared model and any unavoidable container-specific difference.

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-06 06:19:27 +00:00

Use native shadow workspaces for standalone AOS #942

coilyco-ops commented

2026-08-06 06:55:38 +00:00

Author

Owner

Landed on main in coilyco-flight-deck/agentic-os@53b035bbb9.

Validation passed locally through ward exec aos-test, ward exec aos-build, ward exec aos-lint, ward exec test, ward exec pre-commit-all, and the AOS release build/package/check verbs. Pull request #942 was green before landing.

Landed on main in coilyco-flight-deck/agentic-os@53b035bbb969995bc2780e6971f2b95b30fe9bb2. Validation passed locally through ward exec aos-test, ward exec aos-build, ward exec aos-lint, ward exec test, ward exec pre-commit-all, and the AOS release build/package/check verbs. Pull request #942 was green before landing.

coilyco-ops closed this issue

2026-08-06 06:55:39 +00:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

coilyco-flight-deck/agentic-os#926

No description provided.

Rows
Columns