Code review

coilysiren commented

2026-07-22 20:30:12 +00:00

Owner

via docs/contract-review.md

agent compose owns

personality, mode, privacy scope, target repositories, source selection, and delivery

A lot of these only exist because the model inferred a constraint or component that I did not define. To itemize:

personality: yes, this is the core
mode: I see mode interactive - this is not necessary to define the composer should not care if a particular agent is interactive. I also see mode native skills which does seem load bearing in an obvious way on the other hand.
privacy scope: this is a personality engine we don't need a privacy scope. In fact, every single thing in this entire repository that thinks about a "repo" should be tossed out, aside from repos being (functionally by coincidence) a good place to store personality specs. Which is to say, a repo from the point of view of agent compose is at best a prose reference for where personality files sometimes live.
target repos: same as above
source selection: this looks like an alias for the place the personality files come from, which is fine
delivery: load bearing in an obvious way

via docs/person-contract.md

I don't see a need for the entire "invariants" section
I see "allows personality" when it should just be "personality". Unclear why "allows" is in there.
for the personality key - I'm not sure why I'm seeing presence / attention / tempo / voice. Is the idea that this is a schema? Because those values are supposed to be defined inside the skill. Where inside the skill, I'm not super opinionated yet. kdl? yaml? yaml but inside a metadata block of SKILL.md? There's flex there.

via docs/manifest-schema.md

agent / model / harness attributes are the realm of aos / ward. I see this file defining a bunch of things that don't belong in a personality engine. Such as model, model class, effort, distinguishing harness from agent (useful in general, but not for agent compose). At best I could see, maybe... model class being used to determine how much detail the agent is provided in its personality specs? Like codex can just get 1 sentence describing our framing for "energetic". But goose (via qwen, but the fact that it's Qwen isn't something agent compose is allowed to know) needs an one pager so it doesn't think the person thinks they are literally a Duracell AAA battery instead of a person who likes too many emojis (or however we end up defining energetic).
as described earlier in this prompt, modes / scopes / targets aren't something agent compose gets to know
do we really need versions and shas? It isn't really that deep, this is a personality engine not a security boundary

docs/kdl-contracts.md

see above

docs/decision-trace.md

I get the idea and goal here but it's written with the level of detail and prose style of a programming language or network protocol. Overkill.

via docs/contract-review.md agent compose owns > personality, mode, privacy scope, target repositories, source selection, and delivery A lot of these only exist because the model inferred a constraint or component that I did not define. To itemize: - personality: yes, this is the core - mode: I see `mode interactive` - this is not necessary to define the composer should not care if a particular agent is interactive. I also see `mode native skills` which does seem load bearing in an obvious way on the other hand. - privacy scope: this is a personality engine we don't need a privacy scope. In fact, every single thing in this entire repository that thinks about a "repo" should be tossed out, aside from repos being (functionally by coincidence) a good place to store personality specs. Which is to say, a repo from the point of view of agent compose is at best a prose reference for where personality files sometimes live. - target repos: same as above - source selection: this looks like an alias for the place the personality files come from, which is fine - delivery: load bearing in an obvious way via docs/person-contract.md - I don't see a need for the entire "invariants" section - I see "allows personality" when it should just be "personality". Unclear why "allows" is in there. - for the personality key - I'm not sure why I'm seeing presence / attention / tempo / voice. Is the idea that this is a schema? Because those values are supposed to be defined inside the skill. Where inside the skill, I'm not super opinionated yet. kdl? yaml? yaml but inside a metadata block of SKILL.md? There's flex there. via docs/manifest-schema.md - agent / model / harness attributes are the realm of aos / ward. I see this file defining a bunch of things that don't belong in a personality engine. Such as model, model class, effort, distinguishing harness from agent (useful in general, but not for agent compose). At best I could see, maybe... model class being used to determine how much detail the agent is provided in its personality specs? Like codex can just get 1 sentence describing our framing for "energetic". But goose (via qwen, but the fact that it's Qwen isn't something agent compose is allowed to know) needs an one pager so it doesn't think the person thinks they are literally a Duracell AAA battery instead of a person who likes too many emojis (or however we end up defining energetic). - as described earlier in this prompt, modes / scopes / targets aren't something agent compose gets to know - do we really need versions and shas? It isn't really that deep, this is a personality engine not a security boundary docs/kdl-contracts.md see above docs/decision-trace.md I get the idea and goal here but it's written with the level of detail and prose style of a programming language or network protocol. Overkill.

coilyco-ops referenced this issue from a commit

2026-07-22 21:04:47 +00:00

docs: apply the issue #13 contract review

coilyco-ops commented

2026-07-22 21:05:04 +00:00

Member

Applied in 5f9b5f4 (docs: apply the issue #13 contract review).

Removed privacy scopes, target repos, the repo declaration grammar, the cli-guard agent-claim block, mode interactive, schema-version fields, and all digest ceremony.
person-contract: invariants section dropped, allows-personality -> personality, presence/attention/tempo/voice moved out of the contract - a personality entry now binds a name to a skill, and the in-skill format (KDL / YAML / SKILL.md metadata block) is recorded as deliberately undecided in v0.1.
Compose request is now role + personality + delivery + density + sources. Density is the one harness-adjacent input, passed directly by the caller (typically derived from model class) so no model fact reaches agent-compose.
Manifest shrank to a format marker, role/personality/density, source ids, and delivery entry points. decision-trace rewritten as a plain ordered decision list with human-readable reasons.
contract-review.md now records these decisions as the review of record for #2.
Fixtures renamed to the axes agent-compose actually knows: native/compiled x brief/full; repo-agent-compose.kdl deleted.

Kept with reasoning stated in the docs: atomic staging-then-rename (AGENTS.md safety still forbids partial refresh) and a bare "format" string in the manifest so consumers know what they are reading.

Applied by Claude Code working the issue queue.

Applied in 5f9b5f4 (docs: apply the issue #13 contract review). - Removed privacy scopes, target repos, the repo declaration grammar, the cli-guard agent-claim block, `mode interactive`, schema-version fields, and all digest ceremony. - person-contract: invariants section dropped, `allows-personality` -> `personality`, presence/attention/tempo/voice moved out of the contract - a personality entry now binds a name to a skill, and the in-skill format (KDL / YAML / SKILL.md metadata block) is recorded as deliberately undecided in v0.1. - Compose request is now role + personality + delivery + density + sources. Density is the one harness-adjacent input, passed directly by the caller (typically derived from model class) so no model fact reaches agent-compose. - Manifest shrank to a format marker, role/personality/density, source ids, and delivery entry points. decision-trace rewritten as a plain ordered decision list with human-readable reasons. - contract-review.md now records these decisions as the review of record for #2. - Fixtures renamed to the axes agent-compose actually knows: native/compiled x brief/full; repo-agent-compose.kdl deleted. Kept with reasoning stated in the docs: atomic staging-then-rename (AGENTS.md safety still forbids partial refresh) and a bare "format" string in the manifest so consumers know what they are reading. Applied by Claude Code working the issue queue.

coilyco-ops closed this issue

2026-07-22 21:05:12 +00:00

coilyco-ops referenced this issue

2026-07-22 21:14:14 +00:00

Define the v0.1 input, policy, and bundle contracts #2

coilyco-ops referenced this issue

2026-07-22 21:27:01 +00:00

Compose one public profile into a deterministic bundle #3

coilyco-ops referenced this issue

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

Resolve repo capabilities into selected skills #4

coilyco-ops referenced this issue