Split person profiles from composable personality libraries #111

Closed
opened 2026-07-27 21:01:37 +00:00 by coilysiren · 1 comment
Owner

External person packages currently replace the embedded default as one complete unit and must carry every role, seat, personality binding, definition, invariant, and evaluation asset they use. The engine also assumes every role has exactly two or three personalities and contains behavior paths coupled to the built-in personal profile.

That blocks a portable corporate profile from defining a manager role with one unique personality while reusing shared personalities from another library.

Goal

Keep exactly one selected person profile for role and identity policy, while allowing that profile to compose personalities from any number of admitted libraries.

Ownership

  • A person profile owns its name, roles, seats, role skills, ordered melds, invariant, role inspirations, compatibility, and profile-specific evaluation assets.
  • A personality library owns personality slugs, stable skill bindings, definitions, aliases, identity primitives, personality inspirations, and related assets.
  • Engine code owns schema, parsing, validation, deterministic resolution, rendering, and conflict behavior.
  • The built-in default may remain shipped data, but engine behavior must not branch on a personal name or encode its role-specific prose in Go.

Resolution

  • Roles reference ordered personality slugs only. They do not name the library supplying each personality.
  • A compose request, host config, or package-local discovery admits zero or more local personality-library roots.
  • Agent-compose performs no network fetch and contains no repository URL, branch, tag, release, or external filesystem path.
  • Missing referenced personalities fail before materialization.
  • Byte-identical duplicate definitions deduplicate. Non-identical duplicate slugs or skill bindings fail closed.
  • Alias collisions remain representable as multiple candidates rather than redefining a personality.
  • Generated artifacts record logical source provenance and content digests without exposing local paths.

Melds

  • The engine accepts any nonempty ordered personality meld.
  • Remove the engine-level two-or-three-personality restriction.
  • A specific profile may retain a narrower convention through profile-owned validation without imposing it on external users.
  • Colors and every other derived surface operate on the effective meld without fixed cardinality assumptions.

Compatibility and migration

  • Split the shipped default into a person profile and at least one personality library using the same public contract available to external users.
  • Existing external package layouts remain readable as one profile with an implicit package-local personality library during a documented compatibility window.
  • No runtime behavior depends on canonical role names, personality names, counts, or the selected person's literal name.
  • Issue #110 moves authored evaluation and roster prose directly into the final profile/library-oriented asset layout.

Acceptance

  • A fixture profile defines one manager role whose meld combines one package-local personality with personalities from a separately admitted shared library.
  • A fixture demonstrates a valid single-personality meld.
  • The default profile produces equivalent role, personality, identity, and bundle output after migration.
  • Native roster, compose, evaluation, palette, overlay, and person-snapshot paths all consume the resolved profile plus libraries.
  • Missing libraries, missing personalities, duplicate definitions, conflicting bindings, and invalid provenance fail with focused diagnostics.
  • Documentation defines authoring, discovery, precedence, compatibility, and the no-fetch boundary.
  • ward exec test and ward exec smoke pass.

Follow-up: the structured alias and affinity-sphere projection should depend on this effective profile/library graph rather than the current built-in roster.

Execution contract for Terra medium

Release posture

The goal agent records current canonical main and its latest verified v1.x release as the pre-migration baseline. Every change in this issue lands as an additive v1.x change. The v1.x line keeps the current package input, --person-source, agent seat syntax, and existing generated compatibility artifacts readable. A later v2 issue may remove them, but this batch does not.

New source contract

Exactly one person profile remains selected. The profile root retains person.kdl and owns:

  • roles/<slug>/SKILL.md plus structured role metadata
  • evaluations/
  • definitions/INVARIANT.md
  • profile-owned instructions and copy contracts
  • role inspirations
  • optional package-local libraries/

Each personality-library root contains a stable library.kdl logical ID and owns:

  • personalities/
  • definitions/skills/<skill>/SKILL.md
  • personality inspirations
  • personality aliases and identity assets

The current complete-person layout loads through a compatibility adapter as one profile plus one implicit package-local personality library. The adapter records logical provenance and never exposes its local path.

Admission surfaces

  • --person-source continues selecting the profile root.
  • A repeatable --personality-library flag admits additional local library roots for direct commands.
  • Compose KDL accepts repeatable personality-library "<path>" locator nodes.
  • Host YAML accepts an ordered personality_libraries list.
  • A profile may ship local libraries beneath libraries/, discovered in lexical order.
  • Agent-compose performs no clone, pull, release lookup, URL fetch, or git-ref resolution. A launcher, repository checkout, or host convergence step materializes every root before invocation.

The effective library order is package-local lexical order, then host-config order, then request or direct-flag order. The order controls deterministic catalogue and alias presentation only. It never permits a later library to override a conflict.

Resolution and provenance

  • Roles reference ordered personality slugs without naming a library.
  • Every library has a stable logical ID.
  • Every resolved personality records its library ID and SHA-256 content digest.
  • Byte-identical duplicate logical definitions deduplicate to the first admitted source.
  • A non-identical duplicate personality slug fails.
  • A non-identical duplicate skill binding fails.
  • Missing personalities, missing definitions, missing libraries, invalid logical IDs, path escapes, and symlinks fail before materialization.
  • Alias collisions do not redefine a personality and remain visible for issue 112 to project.

Meld cardinality

The engine accepts any nonempty ordered role meld. Personality definitions remain atomic. Roles compose personalities into melds, but one personality definition does not inherit from or expand into other personalities. A profile may impose a narrower profile-owned authoring rule, but engine code carries no two-or-three limit.

Compatibility outputs

The goal agent keeps person.json schema v3 available throughout v1.x. The resolved graph exposes the provenance needed for issue 112's parallel next-generation snapshot and human-readable personality index. Existing overlay, palette, roster, bundle, and evaluation outputs retain their current compatibility surfaces while consuming the new resolved graph internally.

Required fixtures

  • One profile defines a single-personality role.
  • One profile defines a manager role that combines one package-local personality with personalities from a separately admitted shared library.
  • One legacy complete-person package proves compatibility adaptation.
  • Negative fixtures cover missing roots, missing slugs, duplicate IDs, duplicate skills, divergent definitions, path escapes, symlinks, and invalid provenance.

Done condition

  • The shipped default uses the same profile and library contract available to external users.
  • No runtime path branches on Kai's name, a canonical role slug, a canonical personality slug, catalogue size, or meld size.
  • Native roster, compose, evaluation, palette, overlay, bundle, and snapshot code consume one resolved profile-plus-libraries graph.
  • Documentation specifies layout, admission, ordering, conflict behavior, compatibility, provenance, and the no-fetch boundary.
  • ward exec test and ward exec smoke pass.
  • The implementation lands on canonical main and closes this issue.

Reconciliation with role skills

#121 defines each profile role as one canonical role-<slug> skill under the final roles/ layout. Structured profile data continues to own slug, purpose, seats, ordered meld, inspirations, identity primitives, and the stable role-skill binding. The compatibility adapter exposes legacy inline briefings as logical role skills without writing a second mutable source tree.

External person packages currently replace the embedded default as one complete unit and must carry every role, seat, personality binding, definition, invariant, and evaluation asset they use. The engine also assumes every role has exactly two or three personalities and contains behavior paths coupled to the built-in personal profile. That blocks a portable corporate profile from defining a manager role with one unique personality while reusing shared personalities from another library. ## Goal Keep exactly one selected person profile for role and identity policy, while allowing that profile to compose personalities from any number of admitted libraries. ## Ownership * A person profile owns its name, roles, seats, role skills, ordered melds, invariant, role inspirations, compatibility, and profile-specific evaluation assets. * A personality library owns personality slugs, stable skill bindings, definitions, aliases, identity primitives, personality inspirations, and related assets. * Engine code owns schema, parsing, validation, deterministic resolution, rendering, and conflict behavior. * The built-in default may remain shipped data, but engine behavior must not branch on a personal name or encode its role-specific prose in Go. ## Resolution * Roles reference ordered personality slugs only. They do not name the library supplying each personality. * A compose request, host config, or package-local discovery admits zero or more local personality-library roots. * Agent-compose performs no network fetch and contains no repository URL, branch, tag, release, or external filesystem path. * Missing referenced personalities fail before materialization. * Byte-identical duplicate definitions deduplicate. Non-identical duplicate slugs or skill bindings fail closed. * Alias collisions remain representable as multiple candidates rather than redefining a personality. * Generated artifacts record logical source provenance and content digests without exposing local paths. ## Melds * The engine accepts any nonempty ordered personality meld. * Remove the engine-level two-or-three-personality restriction. * A specific profile may retain a narrower convention through profile-owned validation without imposing it on external users. * Colors and every other derived surface operate on the effective meld without fixed cardinality assumptions. ## Compatibility and migration * Split the shipped default into a person profile and at least one personality library using the same public contract available to external users. * Existing external package layouts remain readable as one profile with an implicit package-local personality library during a documented compatibility window. * No runtime behavior depends on canonical role names, personality names, counts, or the selected person's literal name. * Issue #110 moves authored evaluation and roster prose directly into the final profile/library-oriented asset layout. ## Acceptance * A fixture profile defines one manager role whose meld combines one package-local personality with personalities from a separately admitted shared library. * A fixture demonstrates a valid single-personality meld. * The default profile produces equivalent role, personality, identity, and bundle output after migration. * Native roster, compose, evaluation, palette, overlay, and person-snapshot paths all consume the resolved profile plus libraries. * Missing libraries, missing personalities, duplicate definitions, conflicting bindings, and invalid provenance fail with focused diagnostics. * Documentation defines authoring, discovery, precedence, compatibility, and the no-fetch boundary. * `ward exec test` and `ward exec smoke` pass. Follow-up: the structured alias and affinity-sphere projection should depend on this effective profile/library graph rather than the current built-in roster. ## Execution contract for Terra medium ### Release posture The goal agent records current canonical `main` and its latest verified v1.x release as the pre-migration baseline. Every change in this issue lands as an additive v1.x change. The v1.x line keeps the current package input, `--person-source`, `agent` seat syntax, and existing generated compatibility artifacts readable. A later v2 issue may remove them, but this batch does not. ### New source contract Exactly one person profile remains selected. The profile root retains `person.kdl` and owns: * `roles/<slug>/SKILL.md` plus structured role metadata * `evaluations/` * `definitions/INVARIANT.md` * profile-owned instructions and copy contracts * role inspirations * optional package-local `libraries/` Each personality-library root contains a stable `library.kdl` logical ID and owns: * `personalities/` * `definitions/skills/<skill>/SKILL.md` * personality inspirations * personality aliases and identity assets The current complete-person layout loads through a compatibility adapter as one profile plus one implicit package-local personality library. The adapter records logical provenance and never exposes its local path. ### Admission surfaces * `--person-source` continues selecting the profile root. * A repeatable `--personality-library` flag admits additional local library roots for direct commands. * Compose KDL accepts repeatable `personality-library "<path>"` locator nodes. * Host YAML accepts an ordered `personality_libraries` list. * A profile may ship local libraries beneath `libraries/`, discovered in lexical order. * Agent-compose performs no clone, pull, release lookup, URL fetch, or git-ref resolution. A launcher, repository checkout, or host convergence step materializes every root before invocation. The effective library order is package-local lexical order, then host-config order, then request or direct-flag order. The order controls deterministic catalogue and alias presentation only. It never permits a later library to override a conflict. ### Resolution and provenance * Roles reference ordered personality slugs without naming a library. * Every library has a stable logical ID. * Every resolved personality records its library ID and SHA-256 content digest. * Byte-identical duplicate logical definitions deduplicate to the first admitted source. * A non-identical duplicate personality slug fails. * A non-identical duplicate skill binding fails. * Missing personalities, missing definitions, missing libraries, invalid logical IDs, path escapes, and symlinks fail before materialization. * Alias collisions do not redefine a personality and remain visible for issue 112 to project. ### Meld cardinality The engine accepts any nonempty ordered role meld. Personality definitions remain atomic. Roles compose personalities into melds, but one personality definition does not inherit from or expand into other personalities. A profile may impose a narrower profile-owned authoring rule, but engine code carries no two-or-three limit. ### Compatibility outputs The goal agent keeps `person.json` schema v3 available throughout v1.x. The resolved graph exposes the provenance needed for issue 112's parallel next-generation snapshot and human-readable personality index. Existing overlay, palette, roster, bundle, and evaluation outputs retain their current compatibility surfaces while consuming the new resolved graph internally. ### Required fixtures * One profile defines a single-personality role. * One profile defines a manager role that combines one package-local personality with personalities from a separately admitted shared library. * One legacy complete-person package proves compatibility adaptation. * Negative fixtures cover missing roots, missing slugs, duplicate IDs, duplicate skills, divergent definitions, path escapes, symlinks, and invalid provenance. ### Done condition * The shipped default uses the same profile and library contract available to external users. * No runtime path branches on Kai's name, a canonical role slug, a canonical personality slug, catalogue size, or meld size. * Native roster, compose, evaluation, palette, overlay, bundle, and snapshot code consume one resolved profile-plus-libraries graph. * Documentation specifies layout, admission, ordering, conflict behavior, compatibility, provenance, and the no-fetch boundary. * `ward exec test` and `ward exec smoke` pass. * The implementation lands on canonical `main` and closes this issue. ## Reconciliation with role skills #121 defines each profile role as one canonical `role-<slug>` skill under the final `roles/` layout. Structured profile data continues to own slug, purpose, seats, ordered meld, inspirations, identity primitives, and the stable role-skill binding. The compatibility adapter exposes legacy inline briefings as logical role skills without writing a second mutable source tree.
coilyco-ops changed title from Remove Kai encoded highly personal defaults from codebase to Split person profiles from composable personality libraries 2026-07-27 21:13:19 +00:00
Member

Landed on canonical main through daa9996. One selected profile now composes package-local and repeatable admitted personality libraries with stable logical provenance, deterministic order, byte-identical deduplication, conflict failure, no fetch behavior, symlink rejection, arbitrary nonempty melds, and legacy complete-package adaptation. The executable example proves a single-personality role and a local-plus-shared meld across every person surface. ward exec test and ward exec smoke passed.

Landed on canonical main through daa9996. One selected profile now composes package-local and repeatable admitted personality libraries with stable logical provenance, deterministic order, byte-identical deduplication, conflict failure, no fetch behavior, symlink rejection, arbitrary nonempty melds, and legacy complete-package adaptation. The executable example proves a single-personality role and a local-plus-shared meld across every person surface. ward exec test and ward exec smoke passed.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
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#111
No description provided.