Foreground one personality per role in the composed bundle, statically #302

New issue

Open

opened 2026-08-17 18:27:18 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-17 18:27:18 +00:00

Member

Blocked on the personality tier of #262. Filed so it stops living only in a chat thread.

What

Each role's bundle currently applies its three personalities evenly. This adds a static emphasis: one personality per role is foregrounded, with an explicit instruction, while the other two stay active and unchanged.

Why static rather than drawn

This is the agent-compose variant of coilyco-gaming/sirens-echo#781, which draws one personality uniformly at random per container start. That is correct there and wrong here. Sirens Echo wants a Discord persona that varies between restarts. Agent Compose wants a role that composes the same way every time, because the bundle is digest-bound and the eval board is derived from it. A per-launch draw would make a role's behaviour unreproducible and the digest meaningless.

So: same idea, static assignment.

The assignment

Foreground the least-used personality in each role's meld, chosen so the eight emphases are all distinct and maximally separated. After #299 this solves cleanly and every role owns its emphasis uniquely:

engineer - tenacious
director - bold
qa - candid
ops - reflective
design - playful
exec - outward
creator - warm
ai - empirical

All eight at usage 1, minimum OKLab separation 0.1099 against 0.0726 before #299. Before that change, exec and ai owned no unique personality and had to take one already spoken for, which is what motivated #299 in the first place.

Whether the assignment is derived at load like the favorite colours, or declared per role in KDL and validated for distinctness, is an open call. Deriving it keeps it honest against roster edits. Declaring it makes the role file a complete picture of the role, which is the same tension the adjacency comment on #262 records.

Why this is blocked

Foregrounding is a second lever on the same outcome that #296 and #299 already moved. The personality tier of #262 has not run, so the first lever is unmeasured. Adding a second before the first is measured makes any later result unattributable between them.

The right order is: run the personality tier against the current bundles, then add emphasis, then re-run the same tier. That gives a clean before and after on the same 24 cases, which is worth much more than shipping both at once.

Complete when

Each role's composed bundle foregrounds exactly one personality, with the other two still applied.
The emphasised personality is visible in the bundle and in whatever surface shows the meld, so a surprising response can be traced to it.
The assignment cannot silently collide: two roles emphasising the same personality fails a check.
The personality tier of #262 has been run before and after, on the same cases.

Prior context

Design settled in a session with Kai on 2026-08-17, in the thread that produced #296, #299, #300, and #301.

Blocked on the personality tier of #262. Filed so it stops living only in a chat thread. ## What Each role's bundle currently applies its three personalities evenly. This adds a static emphasis: one personality per role is foregrounded, with an explicit instruction, while the other two stay active and unchanged. ## Why static rather than drawn This is the agent-compose variant of `coilyco-gaming/sirens-echo#781`, which draws one personality uniformly at random per container start. That is correct there and wrong here. Sirens Echo wants a Discord persona that varies between restarts. Agent Compose wants a role that composes the same way every time, because the bundle is digest-bound and the eval board is derived from it. A per-launch draw would make a role's behaviour unreproducible and the digest meaningless. So: same idea, static assignment. ## The assignment Foreground the least-used personality in each role's meld, chosen so the eight emphases are all distinct and maximally separated. After #299 this solves cleanly and every role owns its emphasis uniquely: * engineer - tenacious * director - bold * qa - candid * ops - reflective * design - playful * exec - outward * creator - warm * ai - empirical All eight at usage 1, minimum OKLab separation 0.1099 against 0.0726 before #299. Before that change, exec and ai owned no unique personality and had to take one already spoken for, which is what motivated #299 in the first place. Whether the assignment is derived at load like the favorite colours, or declared per role in KDL and validated for distinctness, is an open call. Deriving it keeps it honest against roster edits. Declaring it makes the role file a complete picture of the role, which is the same tension the adjacency comment on #262 records. ## Why this is blocked Foregrounding is a second lever on the same outcome that #296 and #299 already moved. The personality tier of #262 has not run, so the first lever is unmeasured. Adding a second before the first is measured makes any later result unattributable between them. The right order is: run the personality tier against the current bundles, then add emphasis, then re-run the same tier. That gives a clean before and after on the same 24 cases, which is worth much more than shipping both at once. ## Complete when * Each role's composed bundle foregrounds exactly one personality, with the other two still applied. * The emphasised personality is visible in the bundle and in whatever surface shows the meld, so a surprising response can be traced to it. * The assignment cannot silently collide: two roles emphasising the same personality fails a check. * The personality tier of #262 has been run before and after, on the same cases. ## Prior context Design settled in a session with Kai on 2026-08-17, in the thread that produced #296, #299, #300, and #301.

coilyco-ops referenced this issue

2026-08-17 18:27:37 +00:00

Replace the LLM-reviewer evaluation methodology with a generator, subject, human-grader triple #262

coilyco-ops referenced this issue

2026-08-17 23:33:56 +00:00

The identity card summarizes the doctrine it tells the agent to load, so the load step gets skipped and nothing notices #303