Let an external person package reference embedded core personalities instead of vendoring their bodies #311

New issue

Closed

opened 2026-08-19 08:28:00 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-08-19 08:28:00 +00:00

Member

The gap

An external person package that wants a core personality meld (say meticulous, skeptical, editorial) has no way to reference those entities. The chain, each link verified against v2.32.0:

Every bound personality must be defined on disk, in the package or an admitted personality-library root.
Package selection is exclusive by design: entities never merge across roster:core and an external package.
The core personality bodies exist only embedded in the binary. roster emits their metadata (color, emblem, aliases, verbs in person.json and personality-index.md) but not the SKILL.md prose. bundle export exports baked bundles, not package entities.

So the only path today is copying the SKILL.md bodies into the external package. coilyco-gaming/sirens-echo did exactly that for its community person package (sirens-echo#1065): three core bodies vendored verbatim, plus a build-time drift check that compares each copy against the same skill as delivered in a baked core-role bundle and fails the bake on a byte difference. That works, but it is a workaround: every consumer repeats the copies, the drift check only holds while some core role still delivers the body, and a deliberate upstream rewording ripples as a red bake in every vendoring consumer.

Asks, either shape works

Reference by name: let an external package bind a core personality without defining it, e.g. personality "core:meticulous" or a request/package node admitting the embedded library as a personality-library source. Exclusivity for roles, seats, and identity can stay exactly as documented; personalities are already a shared-disposition axis rather than identity.
Or an export: a command that materializes the embedded entity sources (personality KDL fragment plus SKILL.md body) as a valid personality-library root, so a build can generate the library instead of tracking copies.

Option 1 is the better end state (no copies anywhere). Option 2 is smaller and composes with the existing personality-library mechanics.

Context

Filed from the sirens-echo librarian work: coilyco-gaming/sirens-echo#1063 tracks the consuming lane, and docs/sirens-echo-person.md in that repo records the vendoring trade this feature would retire.

🤖 Generated with Claude Code

## The gap An external person package that wants a core personality meld (say meticulous, skeptical, editorial) has no way to reference those entities. The chain, each link verified against v2.32.0: * Every bound personality must be defined on disk, in the package or an admitted `personality-library` root. * Package selection is exclusive by design: entities never merge across `roster:core` and an external package. * The core personality bodies exist only embedded in the binary. `roster` emits their metadata (color, emblem, aliases, verbs in person.json and personality-index.md) but not the SKILL.md prose. `bundle export` exports baked bundles, not package entities. So the only path today is copying the SKILL.md bodies into the external package. coilyco-gaming/sirens-echo did exactly that for its community person package (sirens-echo#1065): three core bodies vendored verbatim, plus a build-time drift check that compares each copy against the same skill as delivered in a baked core-role bundle and fails the bake on a byte difference. That works, but it is a workaround: every consumer repeats the copies, the drift check only holds while some core role still delivers the body, and a deliberate upstream rewording ripples as a red bake in every vendoring consumer. ## Asks, either shape works 1. **Reference by name**: let an external package bind a core personality without defining it, e.g. `personality "core:meticulous"` or a request/package node admitting the embedded library as a personality-library source. Exclusivity for roles, seats, and identity can stay exactly as documented; personalities are already a shared-disposition axis rather than identity. 2. **Or an export**: a command that materializes the embedded entity sources (personality KDL fragment plus SKILL.md body) as a valid personality-library root, so a build can generate the library instead of tracking copies. Option 1 is the better end state (no copies anywhere). Option 2 is smaller and composes with the existing `personality-library` mechanics. ## Context Filed from the sirens-echo librarian work: coilyco-gaming/sirens-echo#1063 tracks the consuming lane, and docs/sirens-echo-person.md in that repo records the vendoring trade this feature would retire. 🤖 Generated with [Claude Code](https://claude.com/claude-code)