Migrate AOS composition and publish personal v0.1 #9

Closed
opened 2026-07-16 08:01:09 +00:00 by coilyco-ops · 1 comment
Member

Parent

#1

What to build

Move the live composition engine and Kai's company/personality configuration out of agentic-os, migrate existing YAML-era sources and load points to the reviewed KDL and bundle contracts, and publish the first independently installable personal agent-compose release. Leave AOS as content and policy, not a second implementation.

Acceptance criteria

  • Existing public and private source overlays have a documented migration path.
  • The old context-level concept is replaced by the reviewed model-class and profile schema.
  • AOS invokes or configures the released agent-compose binary and contains no duplicate composer implementation.
  • The implementation scope from agentic-os#602 lands through #10, leaving AOS with reusable knowledge rather than the personal company source.
  • Existing Claude, Codex, and OpenCode global load points migrate without dropping required context.
  • Generated bundles, manifests, and references remain outside git.
  • CI builds, tests, versions, and publishes the v0.1 artifact reproducibly.
  • Upgrade and rollback behavior preserve a last-known-good installed version and bundle.
  • README, AGENTS, and FEATURES describe the shipped boundary rather than the bootstrap state.
  • Infrastructure rollout and fleet acceptance issues are filed with exact artifact and config inputs.
  • The v0.1 milestone closes only after every child issue has verifiable acceptance evidence.

Blocked by

  • Blocked by #5
  • Blocked by #6
  • Blocked by #7
  • Blocked by #8
  • Blocked by #10

Execution type

HITL for migration cutover and release approval. Preparation and tests are AFK.

## Parent #1 ## What to build Move the live composition engine and Kai's company/personality configuration out of agentic-os, migrate existing YAML-era sources and load points to the reviewed KDL and bundle contracts, and publish the first independently installable personal agent-compose release. Leave AOS as content and policy, not a second implementation. ## Acceptance criteria - [ ] Existing public and private source overlays have a documented migration path. - [ ] The old `context-level` concept is replaced by the reviewed model-class and profile schema. - [ ] AOS invokes or configures the released agent-compose binary and contains no duplicate composer implementation. - [ ] The implementation scope from agentic-os#602 lands through #10, leaving AOS with reusable knowledge rather than the personal company source. - [ ] Existing Claude, Codex, and OpenCode global load points migrate without dropping required context. - [ ] Generated bundles, manifests, and references remain outside git. - [ ] CI builds, tests, versions, and publishes the v0.1 artifact reproducibly. - [ ] Upgrade and rollback behavior preserve a last-known-good installed version and bundle. - [ ] README, AGENTS, and FEATURES describe the shipped boundary rather than the bootstrap state. - [ ] Infrastructure rollout and fleet acceptance issues are filed with exact artifact and config inputs. - [ ] The v0.1 milestone closes only after every child issue has verifiable acceptance evidence. ## Blocked by - Blocked by #5 - Blocked by #6 - Blocked by #7 - Blocked by #8 - Blocked by #10 ## Execution type HITL for migration cutover and release approval. Preparation and tests are AFK.
coilyco-ops changed title from Migrate AOS composition and publish agent-compose v0.1 to Migrate AOS composition and publish personal v0.1 2026-07-16 08:16:33 +00:00
Author
Member

Closing as superseded, per docs/integration.md (4207b4a) and the decomposition it defines.

The premise of this issue - migrating AOS composition into this repo - predates the v1/v2 seam design. Nothing moves out of v1 in v0.1: v1 (generate-agent-compose in agentic-os) keeps global doctrine, the load-point symlinks, and the mount-eligibility manifest ward reads. The v0.1 'migration' is additive and now tracked as:

  • #18 render the seat roster artifact (in-repo, AFK)
  • #19 publish it into the v1 cascade via the sources/ root v1 already walks - zero v1 code changes (AFK after one HITL decision about this workstation's dormant snapshot)
  • #20 release v0.1: versioning and binary publication (in-repo, AFK)

Retirement of v1, and inheritance of its mount-eligibility obligation, is explicitly deferred to a future contract.

Closed by Claude Code on Kai's direction from the planning discussion.

Closing as superseded, per docs/integration.md (4207b4a) and the decomposition it defines. The premise of this issue - migrating AOS composition into this repo - predates the v1/v2 seam design. Nothing moves out of v1 in v0.1: v1 (generate-agent-compose in agentic-os) keeps global doctrine, the load-point symlinks, and the mount-eligibility manifest ward reads. The v0.1 'migration' is additive and now tracked as: - #18 render the seat roster artifact (in-repo, AFK) - #19 publish it into the v1 cascade via the sources/ root v1 already walks - zero v1 code changes (AFK after one HITL decision about this workstation's dormant snapshot) - #20 release v0.1: versioning and binary publication (in-repo, AFK) Retirement of v1, and inheritance of its mount-eligibility obligation, is explicitly deferred to a future contract. Closed by Claude Code on Kai's direction from the planning discussion.
Sign in to join this conversation.
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/agent-compose#9
No description provided.