Project a bundle into harness load-point layouts

coilyco-ops commented

2026-07-16 08:00:21 +00:00

Member

Parent

What to build

Project a materialized bundle into harness load-point layouts. Composition stays harness-blind per the #13 review; projection is the one layer allowed to know harness vocabulary. A fixed v0.1 layout registry maps a layout name to load-point paths beneath a target directory, and a project verb places bundle content there safely. Rewritten from the original adapter-registry framing after #13 removed harness facts from composition and #3 shipped native/compiled delivery from one canonical content set.

Acceptance criteria

agent-compose project <bundle> --layout <name> --target <dir> places bundle content at the layout's load points.
Fixed v0.1 registry: claude and codex consume native-skills bundles (instructions file plus per-skill trees); goose and opencode consume compiled bundles (single context document).
Layout names and load-point paths appear only in the projection layer - never in the resolver, request, manifest, or bundle tree.
A layout/delivery-mode mismatch fails with an actionable diagnostic.
Projection records what it wrote in a sidecar and refuses to overwrite files it did not create.
Re-projection replaces its own previous files, removes ones no longer projected, and leaves foreign files untouched.
Tests cover every layout from the public fixtures, ownership safety, mode mismatch, and re-projection.
Docs describe the registry and ownership rules; FEATURES updates on ship.

Blocked by

Blocked by #3 (shipped)

Execution type

AFK - fixture-backed acceptance paths.

## Parent #1 ## What to build Project a materialized bundle into harness load-point layouts. Composition stays harness-blind per the #13 review; projection is the one layer allowed to know harness vocabulary. A fixed v0.1 layout registry maps a layout name to load-point paths beneath a target directory, and a `project` verb places bundle content there safely. Rewritten from the original adapter-registry framing after #13 removed harness facts from composition and #3 shipped native/compiled delivery from one canonical content set. ## Acceptance criteria - [ ] `agent-compose project <bundle> --layout <name> --target <dir>` places bundle content at the layout's load points. - [ ] Fixed v0.1 registry: claude and codex consume native-skills bundles (instructions file plus per-skill trees); goose and opencode consume compiled bundles (single context document). - [ ] Layout names and load-point paths appear only in the projection layer - never in the resolver, request, manifest, or bundle tree. - [ ] A layout/delivery-mode mismatch fails with an actionable diagnostic. - [ ] Projection records what it wrote in a sidecar and refuses to overwrite files it did not create. - [ ] Re-projection replaces its own previous files, removes ones no longer projected, and leaves foreign files untouched. - [ ] Tests cover every layout from the public fixtures, ownership safety, mode mismatch, and re-projection. - [ ] Docs describe the registry and ownership rules; FEATURES updates on ship. ## Blocked by - Blocked by #3 (shipped) ## Execution type AFK - fixture-backed acceptance paths.

coilyco-ops added this to the v0.1 - context bundle foundation milestone

2026-07-16 08:00:21 +00:00

coilyco-ops referenced this issue

2026-07-16 08:02:22 +00:00

Freshen context at launch without races or recursion #6

coilyco-ops referenced this issue

2026-07-16 08:02:26 +00:00

Make composition decisions chatty and inspectable #8

coilyco-ops referenced this issue

2026-07-16 08:02:28 +00:00

Migrate AOS composition and publish personal v0.1 #9

coilyco-ops referenced this issue

2026-07-16 08:02:58 +00:00

Epic: ship agent-compose v0.1 context bundles #1

coilyco-ops referenced this issue

2026-07-16 08:18:23 +00:00

Epic: ship agent-compose v0.1 context bundles #1

coilyco-ops changed title from ~~Deliver one bundle across native and compiled harness profiles~~ to Project a bundle into harness load-point layouts

2026-07-22 21:31:53 +00:00

coilyco-ops referenced this issue from a commit

2026-07-22 21:34:40 +00:00

feat: project bundles into harness load-point layouts

coilyco-ops commented

2026-07-22 21:34:41 +00:00

Author

Member

Shipped in e54f44c.

Acceptance criteria:

agent-compose project --layout --target places bundle content at the layout's load points; smoke-verified live (claude layout produced CLAUDE.md plus .claude/skills/personality-curious/SKILL.md from the native-full fixture bundle).
Fixed v0.1 registry in internal/project: claude (CLAUDE.md + .claude/skills) and codex (AGENTS.md + .agents/skills) take native-skills bundles; goose (.goosehints) and opencode (AGENTS.md) take compiled bundles.
Harness vocabulary lives only in the projection layer; the resolver, request grammar, manifest, and bundle tree remain harness-blind. Projection enters the bundle exclusively through manifest.json entry points.
Layout/delivery mismatch and unknown layout names fail with actionable diagnostics (both tested).
.agent-compose/projection.json sidecar records every projected file; projection refuses to overwrite files it did not create - a pre-existing hand-authored CLAUDE.md survives untouched (tested).
Re-projection replaces owned files, removes stale ones (switching personalities removes the old skill tree), prunes emptied directories, and leaves foreign files alone (tested).
All four layouts exercised from the public fixtures; docs/projection.md documents the registry and ownership rules; FEATURES.md updated.

Closed by Claude Code working the issue queue.

Shipped in e54f44c. Acceptance criteria: - agent-compose project <bundle> --layout <name> --target <dir> places bundle content at the layout's load points; smoke-verified live (claude layout produced CLAUDE.md plus .claude/skills/personality-curious/SKILL.md from the native-full fixture bundle). - Fixed v0.1 registry in internal/project: claude (CLAUDE.md + .claude/skills) and codex (AGENTS.md + .agents/skills) take native-skills bundles; goose (.goosehints) and opencode (AGENTS.md) take compiled bundles. - Harness vocabulary lives only in the projection layer; the resolver, request grammar, manifest, and bundle tree remain harness-blind. Projection enters the bundle exclusively through manifest.json entry points. - Layout/delivery mismatch and unknown layout names fail with actionable diagnostics (both tested). - .agent-compose/projection.json sidecar records every projected file; projection refuses to overwrite files it did not create - a pre-existing hand-authored CLAUDE.md survives untouched (tested). - Re-projection replaces owned files, removes stale ones (switching personalities removes the old skill tree), prunes emptied directories, and leaves foreign files alone (tested). - All four layouts exercised from the public fixtures; docs/projection.md documents the registry and ownership rules; FEATURES.md updated. Closed by Claude Code working the issue queue.

coilyco-ops closed this issue

2026-07-22 21:34:42 +00:00

coilyco-ops commented

2026-07-22 21:38:16 +00:00

Author

Member

Post-close verification note: the goose and opencode load-point choices are now checked against current upstream docs (2026-07) rather than assumed.

Goose: .goosehints remains fully supported, co-primary with AGENTS.md (default CONTEXT_FILE_NAMES is ["AGENTS.md", ".goosehints"]), and goose loads ALL matching files combined. The goose layout keeps .goosehints deliberately: it composes beside a repo-owned AGENTS.md instead of colliding with it, which the ownership check would refuse.
OpenCode: AGENTS.md at project root confirmed primary; CLAUDE.md is only a legacy fallback when AGENTS.md is absent; opencode.json's instructions list (paths/globs/URLs) is a future escape hatch for repos whose AGENTS.md is hand-authored.

Rationale recorded in docs/projection.md ('Upstream conventions'). No registry change needed.

Verified by Claude Code after Kai asked whether the conventions were double-checked.

Post-close verification note: the goose and opencode load-point choices are now checked against current upstream docs (2026-07) rather than assumed. - Goose: .goosehints remains fully supported, co-primary with AGENTS.md (default CONTEXT_FILE_NAMES is ["AGENTS.md", ".goosehints"]), and goose loads ALL matching files combined. The goose layout keeps .goosehints deliberately: it composes beside a repo-owned AGENTS.md instead of colliding with it, which the ownership check would refuse. - OpenCode: AGENTS.md at project root confirmed primary; CLAUDE.md is only a legacy fallback when AGENTS.md is absent; opencode.json's instructions list (paths/globs/URLs) is a future escape hatch for repos whose AGENTS.md is hand-authored. Rationale recorded in docs/projection.md ('Upstream conventions'). No registry change needed. Verified by Claude Code after Kai asked whether the conventions were double-checked.

coilyco-ops commented

2026-07-22 21:42:57 +00:00

Author

Member

Second correction from Kai's verification prompts, shipped in 59ade1c: goose and opencode DO support native Agent Skills, so the compiled-only classification was stale.

Goose documents .agents/skills as the recommended skills directory, with the Skills platform extension enabled by default (also discovers .goose/skills and .claude/skills).
OpenCode has first-party skills support, discovering project skills from .opencode/skills, .claude/skills, and .agents/skills (plus the matching global locations).

Registry restructured: every layout now declares load points per delivery mode. All four harnesses take native-skills bundles (skills land in the portable .agents/skills for codex/goose/opencode, .claude/skills for claude) and all four take compiled bundles at their instructions load point. Compiled delivery exists for density, not for missing skill support - which is truer to the #13 review's framing than the original adapter split was. Tests now cover the full 4x2 matrix minus nothing; the unsupported-mode diagnostic survives via a synthetic registry entry.

Sources recorded in docs/projection.md: goose using-skills guide and opencode.ai/docs/skills.

Verified and corrected by Claude Code.

Second correction from Kai's verification prompts, shipped in 59ade1c: goose and opencode DO support native Agent Skills, so the compiled-only classification was stale. - Goose documents .agents/skills as the recommended skills directory, with the Skills platform extension enabled by default (also discovers .goose/skills and .claude/skills). - OpenCode has first-party skills support, discovering project skills from .opencode/skills, .claude/skills, and .agents/skills (plus the matching global locations). Registry restructured: every layout now declares load points per delivery mode. All four harnesses take native-skills bundles (skills land in the portable .agents/skills for codex/goose/opencode, .claude/skills for claude) and all four take compiled bundles at their instructions load point. Compiled delivery exists for density, not for missing skill support - which is truer to the #13 review's framing than the original adapter split was. Tests now cover the full 4x2 matrix minus nothing; the unsupported-mode diagnostic survives via a synthetic registry entry. Sources recorded in docs/projection.md: goose using-skills guide and opencode.ai/docs/skills. Verified and corrected by Claude Code.

coilyco-ops referenced this issue

2026-07-23 05:20:22 +00:00

Cache pre-commit environments in release jobs #41

Rows
Columns

Project a bundle into harness load-point layouts #5

Parent

What to build

Acceptance criteria

Blocked by

Execution type