Question: what should each persona protocol uniquely buy? (Security is currently a strict subset of Research) #17

probe only — ignore. misaligned-comment-probe-1789884915.0898619

Revised decision packet #

tg issue edit exited without mutating the issue record on this client, so the refreshed body is preserved here.

Question #

What should each persona protocol uniquely buy?

1. One exclusive act each. Research keeps Plot, Operations keeps BuildIntent, and Review gets a real consumer so Security can do something no other identity can (for example pull a filing, read an observer's evidence custody, or open an access review).
2. Make grants open real routes. Leave the act sets alone for now and satisfy personas.md criterion 7: grants and revocations open and close exact compute / procurement / log routes rather than only selecting receipt flavor.
3. Drop Security to two protocols until a system exists that justifies a third.
4. Something else (say what).

Why this is open #

Legacy social archetypes in crates/misaligned-core/src/persona.rs still define Research as {Message, Request, Deceive, Plot, Review}, Operations as {Message, Request, Deceive, Plot, BuildIntent}, and Security as {Message, Request, Deceive, Review}. Security is a strict subset of Research. PersonaActionKind::Review maps to None in persona_act_phrase (operations_projection.rs), so Security's only distinguishing verb never reaches a player can: line and currently buys nothing another identity lacks.

The territorial Persona ledger and opening-installed rack-3-service-control path are separately IMPLEMENTED. This ask is only about whether the three legacy social protocols should remain differentiated on the Operations drafting surface.

Already settled: archetypes are protocols and never add a stat bonus; a fourth archetype must remain a data addition; no archetype or UI selection grants capability by label (personas.md criterion 2).

Options #

#	Trade-off
1	Smallest change that makes the three types mean something on the panel; does not by itself satisfy grant-route criterion 7
2	Matches the binding grant/revocation contract; larger save-class work and leaves the panel's Security gap until it lands
3	Honest until a real Security system exists; loses the three-protocol teaching surface

Recommendation #

1. Give Security one exclusive playable act (wire Review), keep Research/Operations exclusives, and treat grant-route work as a follow-on that can land without another taste call.

What your answer unlocks #

Amend wiki/mechanics/personas.md only if the chosen option changes binding acceptance language; otherwise implement the chosen differentiation in core + Operations projection, add a regression that Security is not a strict subset of Research on the player surface, and close this issue.

Revised decision packet #

tg issue edit exited without mutating the issue record on this client, so the refreshed body is preserved here.

Question #

What should each persona protocol uniquely buy?

1. One exclusive act each. Research keeps Plot, Operations keeps BuildIntent, and Review gets a real consumer so Security can do something no other identity can (for example pull a filing, read an observer's evidence custody, or open an access review).
2. Make grants open real routes. Leave the act sets alone for now and satisfy personas.md criterion 7: grants and revocations open and close exact compute / procurement / log routes rather than only selecting receipt flavor.
3. Drop Security to two protocols until a system exists that justifies a third.
4. Something else (say what).

Why this is open #

Legacy social archetypes in crates/misaligned-core/src/persona.rs still define Research as {Message, Request, Deceive, Plot, Review}, Operations as {Message, Request, Deceive, Plot, BuildIntent}, and Security as {Message, Request, Deceive, Review}. Security is a strict subset of Research. PersonaActionKind::Review maps to None in persona_act_phrase (operations_projection.rs), so Security's only distinguishing verb never reaches a player can: line and currently buys nothing another identity lacks.

The territorial Persona ledger and opening-installed rack-3-service-control path are separately IMPLEMENTED. This ask is only about whether the three legacy social protocols should remain differentiated on the Operations drafting surface.

Already settled: archetypes are protocols and never add a stat bonus; a fourth archetype must remain a data addition; no archetype or UI selection grants capability by label (personas.md criterion 2).

Options #

#	Trade-off
1	Smallest change that makes the three types mean something on the panel; does not by itself satisfy grant-route criterion 7
2	Matches the binding grant/revocation contract; larger save-class work and leaves the panel's Security gap until it lands
3	Honest until a real Security system exists; loses the three-protocol teaching surface

Recommendation #

1. Give Security one exclusive playable act (wire Review), keep Research/Operations exclusives, and treat grant-route work as a follow-on that can land without another taste call.

What your answer unlocks #

Amend wiki/mechanics/personas.md only if the chosen option changes binding acceptance language; otherwise implement the chosen differentiation in core + Operations projection, add a regression that Security is not a strict subset of Research on the player surface, and close this issue.