Move all prose into a single dir #255

New issue

Closed

opened 2026-08-09 02:19:21 +00:00 by coilysiren · 2 comments

coilysiren commented

2026-08-09 02:19:21 +00:00

Owner

layout

data/
data/personality-rude/
data/personality-shy/
data/role-cat/
data/role-dog/
data/role-dog/evals.yaml
data/role-dog/SKILL.md
data/role-dog/role.kdl
data/role-dog/ # any role relevant data item, goes in this folder, flat
data/meld-french-fries/
data/boundary-french-fries/ # meld is going to be renamed to boundary in another PR

if its yaml, kdl, markdown, etc... and it relates to a first class entity? so personality, role, meld, etc... then it goes inside of data/

layout ``` data/ data/personality-rude/ data/personality-shy/ data/role-cat/ data/role-dog/ data/role-dog/evals.yaml data/role-dog/SKILL.md data/role-dog/role.kdl data/role-dog/ # any role relevant data item, goes in this folder, flat data/meld-french-fries/ data/boundary-french-fries/ # meld is going to be renamed to boundary in another PR ``` if its yaml, kdl, markdown, etc... and it relates to a first class entity? so personality, role, meld, etc... then it goes inside of `data/`

coilysiren referenced this issue

2026-08-09 02:21:12 +00:00

Add min and max length to every personality / role / [ meld OR boundary ] data entry #256

coilyco-ops referenced this issue

2026-08-09 03:20:23 +00:00

Rename meld to boundary: name the removed behavior, require a counterpart #254

coilyco-ops commented

2026-08-09 03:20:27 +00:00

Member

Sequencing note: this should land after #254, the meld to boundary rename.

Measured against 9764756, this issue moves 62 entity data files, and 30 of them are files #254 must edit. Both are large mechanical diffs over the same set. #254 changes file contents, the keyword, the slugs, and the prose. This one changes paths. Whichever runs second rebases cheaply, but #254's spec names paths throughout and would need respecifying if the tree reshuffles first, while this issue carries no semantics to invalidate. The layout sketch here already anticipates the outcome with data/boundary-french-fries/.

One thing this issue needs to solve independently of that. Role, boundary, and personality ordering currently comes from the two-digit filename prefix, documented in docs/person-package-authoring.md as "The two-digit prefix controls order," and relied on by the loader for RoleOrder and MeldOrder. A flat data/role-dog/role.kdl has nowhere to carry that, so the layout needs another ordering source: an explicit index, an order property on the entity node, or a documented sort key.

#256 is already ordered behind this one, which puts the full chain at #253, #254, #255, #256, #257.

Sequencing note: this should land **after** #254, the meld to boundary rename. Measured against `9764756`, this issue moves 62 entity data files, and 30 of them are files #254 must edit. Both are large mechanical diffs over the same set. #254 changes file contents, the keyword, the slugs, and the prose. This one changes paths. Whichever runs second rebases cheaply, but #254's spec names paths throughout and would need respecifying if the tree reshuffles first, while this issue carries no semantics to invalidate. The layout sketch here already anticipates the outcome with `data/boundary-french-fries/`. **One thing this issue needs to solve independently of that.** Role, boundary, and personality ordering currently comes from the two-digit filename prefix, documented in `docs/person-package-authoring.md` as "The two-digit prefix controls order," and relied on by the loader for `RoleOrder` and `MeldOrder`. A flat `data/role-dog/role.kdl` has nowhere to carry that, so the layout needs another ordering source: an explicit index, an `order` property on the entity node, or a documented sort key. #256 is already ordered behind this one, which puts the full chain at #253, #254, #255, #256, #257.

coilyco-ops commented

2026-08-09 04:14:14 +00:00

Member

Ordering source: decided

Role, boundary, and personality order comes from the two-digit filename prefix today, documented as "The two-digit prefix controls order" and relied on by the loader for RoleOrder and MeldOrder. A flat data/role-dog/ has nowhere to carry it.

Take an explicit order property on the entity node.

role "engineer" {
    order 1
    display-name "Engineer"
    ...
}

Why this over the alternatives:

It is local to the entity. Adding a role means creating one directory and setting one property. An index file would mean editing a second place every time, and it is a merge-conflict magnet on exactly the file every roster change touches.
It survives the move and every move after it. Encoding order in a filename couples semantics to a path, which is the coupling this issue exists to remove. Keeping a prefix on the directory name would preserve the coupling in a new location.
Alphabetical is not an option. The roster order is semantic, engineer, director, qa, ops, design, exec, creator, ai, and sorting by slug would silently reorder every rendered card and catalog.
It becomes validatable. Duplicate order values inside one kind should fail at load. Gaps are fine, and leaving room between values makes insertion cheap.

Applies to every ordered entity kind, not just roles, so boundaries and personalities carry it too.

## Ordering source: decided Role, boundary, and personality order comes from the two-digit filename prefix today, documented as "The two-digit prefix controls order" and relied on by the loader for `RoleOrder` and `MeldOrder`. A flat `data/role-dog/` has nowhere to carry it. **Take an explicit `order` property on the entity node.** ```kdl role "engineer" { order 1 display-name "Engineer" ... } ``` Why this over the alternatives: * **It is local to the entity.** Adding a role means creating one directory and setting one property. An index file would mean editing a second place every time, and it is a merge-conflict magnet on exactly the file every roster change touches. * **It survives the move and every move after it.** Encoding order in a filename couples semantics to a path, which is the coupling this issue exists to remove. Keeping a prefix on the directory name would preserve the coupling in a new location. * **Alphabetical is not an option.** The roster order is semantic, engineer, director, qa, ops, design, exec, creator, ai, and sorting by slug would silently reorder every rendered card and catalog. * **It becomes validatable.** Duplicate order values inside one kind should fail at load. Gaps are fine, and leaving room between values makes insertion cheap. Applies to every ordered entity kind, not just roles, so boundaries and personalities carry it too.

coilyco-ops referenced this issue from a commit

2026-08-09 05:18:20 +00:00

refactor(person): one flat directory per entity under data/ (#255)

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-09 05:18:46 +00:00

refactor(person): flat data layout, freeform personalities, bounded prose (#233 #251 #255 #256 #257 #258) #260

coilysiren closed this issue

2026-08-09 05:20:55 +00:00

coilysiren referenced this issue from a commit

2026-08-09 05:20:57 +00:00

Merge pull request 'refactor(person): flat data layout, freeform personalities, bounded prose (#233 #251 #255 #256 #257 #258)' (#260) from prose/257-258-233-second-person into main