009 Roles and skills

009 Roles and skills

Status: Draft — may change (2026-10-19)

1. The question

How does a team staff itself from shared, versioned role and skill libraries, without a library, a skill or an overlay ever widening what a seat may do?

2. What we propose

Twenty commitments. The enforced half of the module is the Kernel's — capabilities, the composition grammar, constraints, scope, the ceiling and deny, leads, delegation (Kernel §3 to §9) — and is not restated here. This module carries only what the Kernel leaves to it (Kernel §4, §13): the owner-facing side of roles (which roles exist, their names, templates, inheritance, the libraries, team roles mapped to base functions, and a team's universe, entries, seat names, titles and standing role names) and skills. It registers no capability and adds no refusal of authority; the two launch-resolution failures it names (duty-conflict and required-skill-delivery) are written as the two policies of the spec and proposed to be hosted under an explicit Kernel launch-resolution contract at the Runtime's launch step, with that hosting open in §10 (question 7).

1. Two libraries. A roles library and a skills library MUST exist: generic, versioned, reusable, naming no person, path or company. A library is what gives access to the roles and skills. Where a team's definition lives is settled by an owner decision: a team's roles and its briefs — the role-and-trade briefs, the general brief and the start briefs — are records in the registry, not new files in a project. The general brief is the first such record: general, shipping in 0.5.1 as the built-in default, delivered by team up by drop, never typed; under an owner decision it is a briefs registry record, overridable by an entity or a project (roles.md §6). How a library is distributed stays outside this text. Spec: Specs-roles §3.2. Proof: none at int/0.5.1 8acb470b. Today (int/0.5.1 8acb470b, unreleased). Not built: no roles or skills library exists, and no file section declares roles or skills; a seat's role is a required string recorded on its line (src/file/sections/seats.ts), and nothing reads a definition behind it. At int/0.5.1 8acb470b, scripts/brief.ts and drop delivery of the general brief are absent; the registry holds no role or brief record (src/registry/), and no entity or project override exists.

2. Layered by level. Each level MUST inherit the one above and tighten it — add a limit, narrow a scope, bind a skill — and loosen it only where this text says so. The levels, most general first, are the defaults shipped with TeamCLI, the entity's library, the project's library, the team's overlay and the seat's identity (the four levels an owner decision stacks for its policies: entity, project, team, seat). A role may inherit from another role, so a senior role is a parent plus more; the libraries are shareable, so an entity or a team can import or fork another's roles instead of hand-rolling them (inheritance and the library are this module's by Kernel §13). An inherited role is agreed as its resolved content (Kernel §4, §10), so inheritance can never silently widen a seat. The standing rules compose in the same order: the role's rules (with what it inherits), then the entity's, the project's and the team's overlay rules, each level tightening the one above, and a limit against a looser rule resolves to the more restrictive. Two positive duties that cannot both hold are not resolved by "more restrictive": the composition fails visibly, naming both rules, and the seat does not launch or the task is refused, rather than silently honouring one (duty-conflict; proposed Kernel launch-resolution hosting, §10 question 7). Spec: Specs-roles §3.3, §3.6. Proof: none at int/0.5.1 8acb470b. Today (int/0.5.1 8acb470b, unreleased). Not built: no level declares a library, an overlay or a role reference, and no role inherits. The four levels exist as records — the entity is a name on the team's record, and projects and teams have records of their own — but the role bundle the resolver intersects is empty (src/permissions/who.ts).

3. Reference, don't restate. A seat MUST reference a role rather than restate it, and the library's text is pulled in; skills bind by the seat's line or by a task's needs (commitment 5). The level's own rules and the seat's identity are an overlay on top; the identity supplies the name and signature only and adds and removes nothing (Kernel §4). A seat's name is configuration read at every start, never something the seat remembers. Three words are the owner's (an owner decision): the role is the job and carries the capabilities and the skills; the seat is a position in a team, named after its role, and it keeps its registry id, its list and its leases when its occupant — the program and session filling it — changes; the nickname is a name for humans, unique within the team, conferring nothing. A seat's list is its role's bundle plus its own seat-level grants, inside the team's envelope (the Kernel's Grants section, record point c); the occupant signs and holds nothing of its own (Kernel §4). Spec: Specs-roles §3.1, §3.2. Proof: test/rename.test.ts. Today (int/0.5.1 8acb470b, unreleased). In part: a seat's name, its required role and its optional nickname are built (src/file/sections/seats.ts), and team rename carries the seat's registry id, grants, task leases (src/tasks/lease.ts), pending drops, mailbox messages, rules and queue files across a rename (src/commands/rename.ts), while Kernel operational capability leases are not built. The library's text is not pulled in, and a seat's list is its grants alone, because the bundle is empty (src/permissions/who.ts).

4. Binding per level, context or task. Skills MUST attach to a seat by the entity, the project or the team, by a context, or by a task, never baked into a role. A context is a declared trigger — a phase, a file kind the work touches, or a label — named in the configuration of the level that declares it, never inferred. Spec: Specs-roles §3.4. Proof: none at int/0.5.1 8acb470b. Today (int/0.5.1 8acb470b, unreleased). Not built: nothing binds a skill and no context trigger is declared. A task record reads and prints needs (src/tasks/format.ts), and team next does not take any record that carries one (src/commands/next.ts).

5. Per-task needs stay inside what the owner agreed. A task's needs MUST name only skills the owner agreed that seat may receive. A need outside that set is escalated, not silently granted: up the chain of command of 010 Workflow (a blocker goes straight to whoever can lift it), and what ends the escalation is an agreement that adds the skill to the agreed set (Kernel §10; granting is the approval, the Kernel's Policies section §2.10), recorded. The task record's needs grants nothing the agreement did not. On a harness with a skills mechanism, agreed skills load live. On a rules-file-only harness the seat launches with an allow-list; a task, or a mid-session context change, needing an agreed skill outside the allow-list makes the seat restart with it, or refuse the task and say so, never proceed without it. Spec: Specs-roles §3.4; the escalation chain is handed to Specs-round through §12. Proof: test/next.test.ts. Today (int/0.5.1 8acb470b, unreleased). Not built: a task's needs is recorded and its record is skipped by team next (test/next.test.ts); no agreed set, escalation, live load or allow-list exists at this tag.

6. One source of truth, pinned together. The library revisions and each level's own configuration MUST be pinned together by content in the agreement record (Kernel §10). The generated per-seat file is throwaway output. An upgrade of a library is reviewed and re-agreed like any change. Spec: Specs-roles §3.5. Proof: none at int/0.5.1 8acb470b. Today (int/0.5.1 8acb470b, unreleased). Not built: there is no library to pin and no agreement record that names one. The owner's signed records that do exist — capability grants — are pinned by a signature over their bytes, and a revocation is its own appended record (src/permissions/grants.ts).

7. Deliverability: required refuses, optional reports. A skill the agreed seat or task binding requires that cannot be delivered MUST stop the seat's launch, or refuse the task, and say why; an explicitly optional skill a harness cannot take is reported as undelivered, and work continues. "Required" is a property of the binding, never of the role: a role carries no skill dependency. The same split holds for a skill carrying a script the harness cannot run. Never "role only, silently", never a silent no-op. This is a launch-resolution failure, not an authority gate: the required-skill-delivery policy (§3.6 of the spec), proposed to be enforced at the Runtime's launch step under an explicit Kernel launch-resolution contract (§10 question 7). Spec: Specs-roles §3.6, §5 rule 7. Proof: none at int/0.5.1 8acb470b. Today (int/0.5.1 8acb470b, unreleased). Not built: required-skill-delivery is not in the policy object at this tag (src/policy/types.ts names no such policy), and no skill is delivered, so neither refusal nor report is reached.

8. Harness-agnostic, through one observable contract. Roles and skills MUST be written once in a neutral format, with no lab's own, and reached through a harness adapter per tool that renders them natively. Every adapter answers the same four questions: what the seat is shown, where it is written, how the team verifies the seat received it, and, when the harness cannot take a binding, that it says so and refuses where commitment 7 requires, never dropping it silently. Verification is the receipt the Runtime records (002 Communication, phase 2), read into the seat state the Runtime keeps (runtime.md commitment 8): a seat whose state is unknown past its threshold is blind, and a required binding on a blind seat counts as not verified. Capability enforcement does not depend on the adapter; it is the tool's (Kernel §3). Spec: Specs-roles §3.4; the seat state and its threshold are Specs-seat-state-and-watch §3.9, §5 rule 14. Proof: none at int/0.5.1 8acb470b. Today (int/0.5.1 8acb470b, unreleased). Not built: no neutral format, no adapter and no delivery report. The seat state exists (src/state.ts, src/watch/), and no adapter writes a receipt into it.

9. De-identified definitions. A role or skill definition MUST name no person, local path, operating-system folder or company; where an entity's roots are is configuration, never a path in a text (the owner's rule of 2026-10-17). A definition refers to identity.owner, identity.leads and the project's trunk. identity.leads resolves by capability: the seat whose role holds leads (commitment 11); when the team has none, it resolves to nobody and the owner is the team-level address (Kernel §9). It never resolves by a role name. Spec: Specs-roles §3.2, §5 rule 2. Proof: none at int/0.5.1 8acb470b. Today (int/0.5.1 8acb470b, unreleased). No definition exists to carry a name. The one resolution the promise touches at this tag is lead@<team>, which addresses the seat its file marks leads, never a seat by a role's name (src/send/resolve.ts); identity.owner and identity.leads are not expressions the code reads.

10. Bindings are recorded constraints, never a new object. A binding MUST be a recorded constraint expressed through grants (Kernel §5), never a second object: a role may be bound to an orchestrator, a lab or model, or a name or persona, and the matrix of roles × orchestrators is a computed read view over the configuration plus grants, never a matrix object. The kinds come from the delegated role-binding decision (an owner decision): allowed, required, forbidden; their mapping onto the Kernel's §5 constraints is open (§10, question 13); a role bound to a lab is an optional required lab. One resolver decides bindings, grants and policies together, by level: the shipped default, then the entity's, the project's, the team's and the seat's binding, most specific winning while it tightens; then a grant; then the grant rules (specificity, deny wins at equal rank; absent is deny for a grant and the shipped default for a binding; the Kernel's Policies section §2.3). A binding names an agent-registry identity — a team by its team id, a seat by its registry id, the seat's own across its occupants (an owner decision) — never a session, pane, runner or process name, so renames, reboots and CLI changes do not break it. A capability granted to a team is an envelope: it bounds what the team may be granted and reaches a seat, present or future, only where that seat's role holds the capability; a seat's effective authority is its own list (role bundle plus seat grants) intersected with the envelope, never a union; it is exercised through the role that holds it, never through a role name; a seat-level grant reaches one seat and only narrows the envelope for it (two owner decisions). An unsatisfiable binding fails closed: team check reports it and the launch is refused with a clear message, never a silent fallback. The constraint is recorded through the role-binding decision (2026-10-12) and its Kernel §5 mapping is open (§10, question 13); the refusal is proposed as the Kernel's own (§10, question 7). Spec: Specs-roles §3.3, §5 rule 4; the envelope and the grant rules are handed to Specs-grants through §12. Proof: test/policy.test.ts, test/settings-as-policies.test.ts. Today (int/0.5.1 8acb470b, unreleased). In part: the intersection is built exactly as the promise says — a seat's effective authority is its role's bundle plus its seat grants, intersected with the team grant's envelope, never a union (src/permissions/resolve.ts) — and the bundle is empty, so capabilities come from grants alone. Grants are owner-signed records keyed by an agent id for a seat and a team id for a team grant, never by a pane or a process, carrying a closed vocabulary and a scope inside the declared roots, with an expiry checked at every use and a revocation appended rather than edited (src/permissions/grants.ts); a team grant refuses grant, create, agree and leads. Bindings of a role to a lab, a model or a persona are not built, and nothing in the file declares a capability.

11. leads travels in a role, and nothing resolves by a role's name. A seat MUST hold leads only because its role's bundle names that capability (Kernel §3, §4, §9); there is no seat marker and no name that confers it. The shipped library carries one template role that holds it; its name is the owner's to change, in any language, and two teams may call it two different things. Zero or one leads per team is the Kernel's constraint (§5, §9). Everything that needs "the lead" — the team-level address, identity.leads, a team-level grant, the chain of command of 010 Workflow — resolves to the seat whose role holds the capability, never to a seat called by a word (an owner decision). A seat named after its role is still found by the capability its role holds; the name is the position's label, and the nickname beside it a name for humans (an owner decision). Spec: Specs-roles §3.1, §5 rules 5 and 6, §6. Proof: test/check-lead-role-note.test.ts, test/leads-at-most-one.test.ts. Today (int/0.5.1 8acb470b, unreleased). In part: leads is a per-seat mark in the file, read as the team's lead (src/file/sections/lead.ts), and a second mark is refused at its line naming both seats (test/leads-at-most-one.test.ts); lead@<team> resolves to the marked seat, and a new seat or nickname may not take the name lead while a seat already named so keeps loading (src/file/sections/seats.ts, src/commands/add.ts). A file with no lead is also refused at this tag ("the file has no seat that leads"), where this commitment and the Kernel allow zero; the code is stricter. No role holds the capability yet, because the bundle is empty.

12. The universe as a setting, and names drawn from it. A team's universe — the world from which it draws its seat names, titles and team-role words (mythology, history, astronomy, a film saga, a director's films, a series or a book) — MUST be a configurable setting (universe, set through team config) at entity, project or team level, inherited downwards (an owner decision). team add MUST take the next free name from the team's universe (while a name MAY still be chosen by hand, and a universe MAY suggest names by role), and when the universe's entries run out, names MUST be numbered (<name>-2) with a warning (an owner decision). team universes add adds a universe from a list or package (or fetches it from the universe library API, where every package carries its version, its sourced canon file, its team roles and its review record; three owner decisions). Built-in universes shipped in the public TeamCLI MUST be public-domain only (Greek, Roman, Norse or Egyptian mythology, history, stars, planets); universes from trademarked franchises or authors' works MUST stay user-made and private to their owner unless licensed (three owner decisions). Changing a team's universe setting MUST NEVER rename existing seats; existing seats keep their names and history unless explicitly renamed or re-cast (an owner decision). The naming method and its vocabulary — universe, entry (a sourced name with its titles, relations and traits in canon.md, where any unsupported claim is marked unverified and never guessed), name, title, role, team role and role name (while reserving "character" for another scope) — follow the written naming method (three owner decisions). Spec: Specs-roles §3.7, §4, §5 rules 15 and 16, §6. Proof: none at int/0.5.1 8acb470b. Today (int/0.5.1 8acb470b, unreleased). Not built at v0.5.0 (nor at int/0.5.1 8acb470b): no universe setting, no team universes add command, no automatic name selection on team add, and no numbered exhaustion warning exist; seat names and nicknames are written by hand in the team file.

13. A seat's name is the entry it plays and changes with a re-cast, the identity underneath the agent id. A seat's name (in lowercase with hyphens) and its title (on its label Name · Title at the stated story point) MUST come from the universe entry it plays, chosen for its function by a reviewed casting (008 Planning; the written naming method §3–§5; an owner decision), never left as an arbitrary leftover from an earlier cast. On a reviewed re-cast to a different entry, the seat's name MUST change with the entry it plays, while the stable identity underneath MUST remain the registry's agent id (agt_…), never the name, so routing, grants, leases, history and the session registry stay intact across the rename (an owner decision). Spec: Specs-roles §3.1, §3.7, §5 rules 13 and 17. Proof: test/rename.test.ts (for team rename preserving the registry id, grants and task leases); none at int/0.5.1 8acb470b for casting-driven rename or Kernel capability leases. Today (int/0.5.1 8acb470b, unreleased). Not built at v0.5.0 (nor at int/0.5.1 8acb470b) for entry casting, re-cast renames or Kernel capability leases; team rename is built and carries the seat's registry id (agt_…), grants, task leases (src/tasks/lease.ts), pending drops, mailbox messages, rules and queue files across a manual rename (src/commands/rename.ts).

14. Names are unique within a team, name@team across the entity. Seat names MUST be unique within a team, and two teams in the same entity MAY use the same name (amending the owner decision's entity-wide uniqueness rule); across the entity, a seat MUST be addressed as name@team (002 Communication), while its canonical identity in the registry remains its agent id (an owner decision, the written naming method §3). Spec: Specs-roles §3.1, §3.7, §5 rules 11, 12 and 18, and Specs-messaging. Proof: test/rename.test.ts, test/route.test.ts. Today (int/0.5.1 8acb470b, unreleased). Not built at v0.5.0 for universe entries; in part at int/0.5.1 8acb470b for seat names and nicknames: the team file enforces team-local uniqueness of seat names and nicknames (src/file/sections/seats.ts), and src/send/resolve.ts resolves <seat|nickname>@<team> and @<nickname> (refusing an ambiguous cross-team @<nickname> match with the candidate list).

15. A team's own roles mapped to the base functions, with their own grants, capabilities and skills. A team or universe MAY define its own team roles in its universe's words (for example astromech, bot or jedi; an owner decision, the written naming method §1–§2); each team role MUST map onto one of TeamCLI's base functions (orchestrator, operator, builder, reviewer, tester, documentarist, communication, architect) so admission rules and permissions stay checkable underneath, and MAY declare its own grants, capabilities and skills within the Kernel's rules and the team envelope (an owner decision). Compared with Annex A's catalogue (§A.4), the base functions are orchestrator, operator, builder, reviewer, tester, documentarist, communication and architect (communication was added to §A.4 under an owner decision, while architect joins the base functions under an owner decision); the catalogue's archivist and recorder map onto documentarist, and first assistant onto operator, as team roles in the universe's words (commitment 19). Spec: Specs-roles §3.2, §3.7, §5 rule 19. Proof: none at int/0.5.1 8acb470b. Today (int/0.5.1 8acb470b, unreleased). Not built at v0.5.0 (nor at int/0.5.1 8acb470b): a seat's role is a free string (src/file/sections/seats.ts), and nothing maps a team role onto a base function or reads a universe's roles.md.

16. A universe's standing role names. A universe MAY define standing role names in its roles.md file — a sourced, reviewed entry name assigned to a role and reused across every team that uses that universe (for example, the communication role named from the universe's messenger or protocol entry; an owner decision, the written naming method §1–§2) — kept distinct from the team-role word (commitment 15) and conferring no capability or authority of its own (commitment 11). Spec: Specs-roles §3.7, §5 rule 20, and Specs-casting. Proof: none at int/0.5.1 8acb470b. Today (int/0.5.1 8acb470b, unreleased). Not built at v0.5.0 (nor at int/0.5.1 8acb470b): no universe roles.md file or standing role-name definition is read by the tool.

17. Role-based, validated team models with explicit fit requirements. Team models MUST name roles (never hardcoded labs or models) and explicit fit requirements, report an unmet requirement before proposing a model, and pass the tool's validation on every model change; an offline packaged core and browsable library MUST preserve each model's assumptions, seat and plan cost, and actual-use lessons across the project, review, autonomy, availability and visibility dimensions, with later contributions held to those checks and no model granting authority. Spec: Specs-setup-and-team-models §§3.2, 5.5–5.8, §7. Proof: none at v0.5.0 (nor at int/0.5.1 8acb470b) for the model library. Today (int/0.5.1 8acb470b, unreleased). Not built at v0.5.0 (nor at int/0.5.1 8acb470b): examples/team.yaml validation exists, but is not the model library.

18. A project lead may set required-skill-delivery: report for a listed harness; duty-conflict: report stays the owner's. A project lead MAY set required-skill-delivery: report for a harness listed as unable to deliver skills, while nobody below the owner MAY set duty-conflict: report (an owner decision; qualifies commitments 2 and 7). Spec: Specs-roles §3.6, §5 rules 7 and 8. Proof: none at int/0.5.1 8acb470b. Today (int/0.5.1 8acb470b, unreleased). Not built at v0.5.0 (nor at int/0.5.1 8acb470b): neither policy is in src/policy/types.ts.

19. architect joins the base functions; archivist, recorder and first assistant map as team roles. architect MUST join TeamCLI's base functions alongside orchestrator, operator, builder, reviewer, tester, documentarist and communication (because its admission rules differ: it rules on texts and dispatches nothing), while archivist and recorder MUST map onto documentarist, and first assistant onto operator, as team roles in the universe's words (an owner decision; settles commitment 15's §10 question 10). Spec: Specs-roles §3.2, §3.7, §5 rule 19. Proof: none at int/0.5.1 8acb470b. Today (int/0.5.1 8acb470b, unreleased). Not built at v0.5.0 (nor at int/0.5.1 8acb470b): a seat's role is a free string (src/file/sections/seats.ts), and no base-function list or team-role mapping is read by the tool.

20. Accepted texts, decision records and source copies in a knowledge base are protected like a trunk. In a knowledge base, a change or push to an accepted text, a decision record or a source copy MUST be protected like a product trunk under the gate-pass and author-inequality rules, whereas drafts and work files MAY be committed directly by seats whose write scope covers them (an owner decision; settles Annex A §A.6 question 1). Spec: Specs-roles §3.2, §5 rule 1. Proof: none at int/0.5.1 8acb470b. Today (int/0.5.1 8acb470b, unreleased). Not built at v0.5.0 (nor at int/0.5.1 8acb470b): write scopes and trunk protection for accepted texts, decision records and source copies are followed in practice and not enforced by the tool.

3. Why

Today every team re-writes each role inline, in its own configuration. That duplicates text, leaks names of people and paths, has no single source of truth, and never tells a reviewer how to review. Shared, versioned libraries fix that only if the answer also holds the bound: nothing a library, a skill or an overlay says may widen what a seat may do. That is the whole question this text answers.

4. What it costs, and what it does not cover

• A harness that cannot deliver a required skill cannot run that seat, unless a project lead has set required-skill-delivery: report for that listed incapable harness under commitment 18. Optional skills it cannot take are reported undelivered.
• Pinning means no library improvement reaches a team until it re-agrees an upgrade.
• Inheritance and shared libraries make a role's text depend on text elsewhere; agreeing the resolved content (Kernel §4) is the answer, and it means a re-agreement whenever a parent role changes.
• Four levels of library and overlay are four places a rule can come from; the resolver's trace (which level set what) is what keeps that readable, and it is a Runtime view, not a promise here.
• Skills raise competence, not authority. Doing more means changing the role's capabilities, a reviewed and re-agreed change (Kernel §10), not a skill.
• This module does not judge whether a skill is good, or whether a seat followed it.

What this release must not pretend

• No roles or skills library, no layering across the levels, no inheritance and no shared library exists at int/0.5.1 8acb470b.
• No role references a definition, no overlay composes rules, no skill binds, no task's needs delivers anything, and the library check that would reject a skill carrying a rule does not exist.
• leads is a file mark, not a role capability; the role's bundle is empty and capabilities come from grants alone.
• The two launch policies, required-skill-delivery and duty-conflict, are decided in this text and are not in the policy object.
• No universe setting, team universes add command, sourced universe canon.md or roles.md package, team-role to base-function mapping, standing role name, or casting-driven seat rename is built at v0.5.0 or at int/0.5.1 8acb470b.
• What is built is the other half: owner-signed grants keyed by registry identity, the envelope-and-intersection resolver, the nickname's team-local uniqueness with lead reserved, the seat rename that keeps the id, the grants and the task leases (src/tasks/lease.ts; Kernel operational capability leases are not built), and the lead@<team> address.

5. What would change our mind

• If the rule-vs-skill test proves ambiguous in practice, skills become a typed, capability-free format the library checks mechanically, with no free text.
• If no neutral format survives translation to every harness, the canonical form drops to a plain rules file.
• If inheritance makes agreed roles hard to read or to re-agree, roles go back to flat bundles and the library ships copies instead of parents.
• If four levels of overlay prove more than teams use, the entity and project levels collapse into one library level, the resolver unchanged.

6. What is true today

Today is int/0.5.1 8acb470b, unreleased. A role is a required string on a seat and nothing else; no team-file section declares roles or skills, and the resolver fills the role's bundle with nothing. Capability grants are built as owner-signed records keyed by an agent id or a team id, and their intersection with the team envelope is built. The catalogue of Annex A re-reads its own "today" in its §5.

#	Commitment	Today
1	Two libraries	Not built. No library, no roles or skills section, no definition read.
2	Layered by level	Not built. The four levels exist as records; no level declares a library or an overlay, and no role inherits.
3	Reference, don't restate	In part. Name, role and nickname are fields; the rename carries the id, grants and task leases (src/tasks/lease.ts; Kernel capability leases are not built); no library text is pulled in and the bundle is empty.
4	Binding per level, context or task	Not built. A task's needs is printed and such a record is skipped.
5	Needs inside the agreed set	Not built. No agreed set, escalation, live load or allow-list.
6	One source of truth, pinned	Not built. Grants are pinned by signature; no agreement record pins a library.
7	Required refuses, optional reports	Not built. The policy is absent and no skill is delivered.
8	Harness-agnostic contract	Not built. No neutral format, adapter or receipt; the seat state exists.
9	De-identified definitions	Not built. No definition exists; the lead address resolves by the file's mark.
10	Bindings are recorded constraints	In part. The envelope intersection and grants by registry identity are built; role bindings are not, and the bundle is empty.
11	leads in a role, nothing by name	In part. The mark, its at-most-one refusal and lead@<team> are built; no role carries the capability.
12	Universe setting and names drawn from it	Not built at v0.5.0 (nor at int/0.5.1 8acb470b). No universe setting, team universes add, automatic next-free name on team add, or numbered exhaustion warning.
13	Seat name is the cast entry, agent id underneath	Not built at v0.5.0 (nor at int/0.5.1 8acb470b) for casting or Kernel capability leases; team rename preserves the registry id (agt_…), grants and task leases (src/commands/rename.ts, src/tasks/lease.ts).
14	Names unique within a team, name@team across the entity	Not built at v0.5.0 for universe entries; built in part for seat names and nicknames (src/file/sections/seats.ts, src/send/resolve.ts).
15	Team roles mapped to base functions	Not built at v0.5.0 (nor at int/0.5.1 8acb470b). role is a free string; no base-function mapping or universe roles.md is read.
16	A universe's standing role names	Not built at v0.5.0 (nor at int/0.5.1 8acb470b). No universe roles.md or standing role-name definition is read.
17	Role-based, validated team models with fit requirements	Not built at v0.5.0 (nor at int/0.5.1 8acb470b). examples/team.yaml validation exists, but is not the model library (an earlier internal proposal).
18	Project lead sets required-skill-delivery: report for listed harnesses; duty-conflict: report owner-only	Not built at v0.5.0 (nor at int/0.5.1 8acb470b). Neither policy is in src/policy/types.ts (an owner decision).
19	architect joins base functions; archivist, recorder and first assistant map as team roles	Not built at v0.5.0 (nor at int/0.5.1 8acb470b). role is a free string (an owner decision).
20	Accepted texts, decision records and source copies protected like a trunk	Not built at v0.5.0 (nor at int/0.5.1 8acb470b). Followed in practice; write scopes and trunk protection are not enforced by the tool (an owner decision).

7. The security boundary

This module adds no gate. A skill never gates (Kernel §3, §13), and nothing here grants, waives or blocks a capability. The two failures it names — an undeliverable required skill and two incompatible positive duties — are launch-resolution failures written as the two policies of the spec (required-skill-delivery and duty-conflict), proposed to be hosted under an explicit Kernel launch-resolution contract and enforced at the Runtime's launch step under the start row (§4, §9, §11; §10 question 7). The library's check refuses no seat: it runs when a skill enters a library and simply does not accept what carries a rule or a permission. The unsatisfiable binding of commitment 10 is a recorded constraint from the role-binding decision, whose mapping onto the Kernel's §5 constraints is open (§10 question 13). The same-user limit is the Kernel's (§11): a seat's gates hold against a mistake, not an attempt.

8. Where it sits, and what it leaves to others

This module depends only on the Kernel and the Runtime, never on another module. The Kernel resolves and enforces roles (§3 to §10). The Runtime (Tier 2, draft-2) launches seats, hosts the harness adapters and keeps the seat state (source: RFC 007; runtime.md commitment 8). Per-task needs meet the task path of 010 Workflow (the chain of command, the round): capabilities say who may; the workflow says when and to whom; 008 Planning keeps the backlog and the intake rule, and owns casting — choosing which lab, model, version and effort fills a seat (team cast, reviewed across labs under 005 Quality; three owner decisions) — while this module owns the universe setting, entries, seat names and titles, team roles mapped onto base functions, and standing role names (the written naming method). A team model — roles, default skill bindings and configuration — is the layer above.

9. Prior art and alternatives

None argued in this text.

10. Open questions

1. For the build: Library distribution and layering, in detail: how an entity's or a project's library is pointed to, how a shared library is published and imported, and how an overlay names what it overrides.
2. For the build: The neutral format and each adapter's translation; the full set of declared context triggers. (The delivery receipt is settled: the Runtime's record, commitment 8.)
3. How inheritance is written and how deep it may go; whether a child may narrow a parent's capabilities (it can never widen them past the parent plus what the owner agrees).
4. Open: whether this module may restate the Kernel's vocabulary and constraint language at all, rather than only name them (Kernel §3, §5). Scope grammar remains the Kernel's (§6).
5. Settled by the owner on 2026-10-17: the first assistant is just a role. It is an ordinary role, a named capability bundle like any other, under any name and in any language. It has no special class of rights: what it may do is its role's capabilities plus any grant the owner gives it, exactly as for every seat, and the Kernel's rules apply unchanged (agree, grant, create and leads never by lease, only by an owner grant, Kernel §7, §9, §10). TeamCLI may ship it as an optional default role template. A seat holds the role: its identity is its registry id (the seat's, an owner decision), its nickname is configuration, its grants bind to the seat's id and never to a runner or an occupant, its launcher, guard and brief are a seat's launch like any seat's, and another seat may hold the role tomorrow (owner, 2026-10-17: "it is a seat"). That answers what the first draft asked as questions 5 to 8: its default rights are its role's; a team has one when a seat holds that role and none otherwise, and nothing holds its rights in its absence; the assistants it opens are seats like any other, under the ceiling and stopped as the Kernel's §9 table says; it hands on nothing a seat cannot (§7). The notes of 2026-10-10 and the owner's input of 2026-10-12 are background.
6. Setting required-skill-delivery or duty-conflict to report below the owner: settled by an owner decision: a project lead may set required-skill-delivery: report for a harness listed as unable to deliver skills; nobody below the owner sets duty-conflict: report (commitment 18).
7. Kernel reconciliation (the current text's Q1): proposed in an earlier draft, one question left. Kernel §13: module policy may select among Kernel-defined settings and cannot add a refusal, and a skill never gates (§3). The undeliverable required skill (commitment 7) and the incompatible duties (commitment 2) are launch-resolution failures written as the two policies of the spec, proposed to be hosted under an explicit Kernel launch-resolution contract and enforced at the Runtime's launch step under the start row (§4, §9, §11); the library check refuses no seat; the unsatisfiable binding (commitment 10) is a recorded constraint from the role-binding decision, whose mapping onto the Kernel's §5 constraints is open (question 13). Left for the round: whether the Kernel should say in its own words that an unresolvable composition is refused at launch as its act, so that the policies need no hosting argument.
8. Kernel reconciliation (the current text's Q2): settled by the owner. The owner's decision: the lead is the seat whose role holds leads, and a role is never matched by its name, in any language. This text uses identity.leads, resolved by capability (commitments 9 and 11); the accepted 009's identity.orchestrator is superseded.
9. For the build: Zero leads. The Kernel and this text allow a team with no lead; the file at int/0.5.1 8acb470b refuses one ("the file has no seat that leads"). The Kernel is right and the code is stricter; whether the code should be relaxed is open, and this text decides nothing.
10. Base functions and the catalogue's roles (an owner decision): architect joins the base functions (its admission rules differ: it rules on texts and dispatches nothing); archivist and recorder map onto documentarist, and first assistant onto operator, as team roles in the universe's words (commitment 19).
11. A role's default skill set versus a binding: commitment 4 says skills attach by a binding and are never baked into a role, while commitment 3 says the role carries the skills, commitments 15 and Annex A rule 8 name a role's skill set, and roles.md §3.2's skills field says the library must resolve them for the role. The verdict asks for one meaning: a role may name a reusable or default skill set under an owner decision, while the agreed seat, context or task binding determines actual delivery and requiredness, and a role's reference alone never becomes an undeclared required dependency. Open: how the later decision qualifies the accepted wording, so the commitment, the field description and the annex agree; the accepted mandatory-step discriminator is unchanged (the obligation is a rule, the skill supplies how).
12. Protected records in the knowledge base: commitment 20 and Annex A §A.6 question 1 protect accepted texts, decision records and source copies like a trunk, but commitment 20's cited spec sections (roles.md §3.2 and §5 rule 1) describe role bundles and supply no protection contract, and Annex A §A.4's architect and main-orchestrator rows still include knowledge-base "records" in their write scope while excluding only accepted texts. Open: where the protection contract belongs, and how those rows and the linked roles-spec rules distinguish authority to draft a proposed record from applying a protected record change under the gate-pass and author-inequality rules.
13. The role-binding constraints' Kernel mapping: the allowed, required and forbidden kinds in commitment 10 and roles.md §3.2 come from the delegated role-binding decision of 2026-10-12, whose scope is role bindings; Kernel §5 defines cardinality, exclusion and review constraints. Open: how those kinds map onto the Kernel's §5 constraints, and where the mapping is recorded, before the text claims Kernel enforcement of an unsatisfiable binding.
14. A direct seat grant may add to a seat's list: a round-1 review proposes the equation (resolved role bundle plus valid seat grants) intersected with the team envelope, with a direct seat grant allowed to add a capability to that seat's own list but never to widen the envelope or reach another seat. That contradicts roles.md §5 rule 4's "a seat grant only narrows", this text's commitment 10 (line 196) and the code comment, and it changes the rule's meaning; it is carried here rather than applied. Open: whether rule 4 and commitment 10 should adopt the equation, or keep the narrow-only wording.
15. An audit line for Annex A rule 6's widening: Annex A rule 6 widens the catalogue's rule 6 with its "when no universe is selected" scope, and the series records only that the numbers were kept; the verdict suggests one line in Annex A's revision log naming the widening so an auditor sees it without diffing. Open: whether that line should be added, and where the widening is recorded.
16. The earlier draft's question number map: that draft's §10 question 11, the team-models dependency waiting on the setup spec, is folded into commitment 17 and §12's setup link rather than kept as a question, so the map (questions 1–10 kept, 11 folded) is not stated in this text. Open: whether the map should be stated explicitly for a reader moving from the draft to this text.

12. Links to the spec

• Specs-roles §3.1 — the seat line's role and nickname (built).
• §3.2 — the role definition, including base_function, communication and architect (planned); §3.3 — a level's reference and overlay (planned).
• §3.4 — a skill binding, a task's needs, and the adapter's four questions (planned).
• §3.5 — the agreement's pin (planned); §3.6 — the two launch policies and their setters (planned).
• §3.7 — the universe setting, universe entries, team roles and standing role names (planned).
• §4 — team universes add, team config set … universe, and team add next-free-name selection (planned).
• §5 — rules 1 to 20 with their source and proof at the tag.
• Specs-setup-and-team-models §§3.2, 5.5–5.8, §7 — team-model dimensions, the four role-based presets, explicit fit requirements and preflight reporting, validation on every model change, and the offline core and browsable model library (planned; from an earlier internal proposal).
• Specs-casting — the universe package (canon.md, casting.md, review.md, roles.md), sourced entries, cast and casting-review records, universe setting, team universes add, and team cast (planned).

Registries this text contributes to, in the row shape, in that spec's §6: policy-names (required-skill-delivery, duty-conflict — planned), capabilities (leads), operations (start, stop, restart, reload, add, remove, never a capability, a lease or a role's; and universes add — planned under an owner decision), config (universe — planned at entity, project and team level under two owner decisions, handed to Specs-config), and briefs (general — the general seat brief, shipped in 0.5.1 as the built-in default, delivered by drop and never typed; the registry record under an owner decision).

Handed to other specs through this section, not copied here:

• for messaging: the address grammar @<nickname>, <seat|nickname>@<team> (name@team across the entity, an owner decision) and lead@<team>, and the nickname's resolution order with the candidates listed on an ambiguous match.
• for grants: the team envelope, the seat list as bundle plus seat grants, the grant rules (specificity, deny at equal rank, absent is deny) and the fail-closed unsatisfiable binding.
• for policies: the two policy rows, their scopes, values, default refuse and setters.
• for tasks-and-broker: the task record's needs field and that a record carrying it is not claimable.
• for round: the escalation chain a need outside the agreed set travels.
• for seat-state-and-watch: the delivery receipt read into the seat state, and the blind threshold a required binding meets.

Annex A — A roles catalogue for 0.5.1

From the catalogue of 2026-10-17, re-read at int/0.5.1 8acb470b. Its rule and question numbers are its own and are kept.

This v2 is private and keeps the catalogue whole, seats and nicknames included; a published version of the catalogue carries roles only.

A.1 What this is

One table per team, as the owner named the seats on 2026-10-17: for each role, the capabilities it carries (the Kernel's closed vocabulary, with the scope each is bounded to), the skill set it names, and what no role ever carries. It is a catalogue, not a library format: how a role is stored and delivered is 009 commitments 1, 6 and 8. §A.5 says what the tag has, and what 0.5.1 still has to build for the catalogue to be read by the tool rather than by people.

A.2 The rules the catalogue follows

The owner's decision, with the findings of the reviews folded in.

1. A role carries capability words and a skill set; four words are never in a role. grant, agree and create reach a seat only by the owner's own grant (Kernel §10: never copied, by default nobody). leads is the exception the Kernel makes: it travels in a role's bundle (009 commitment 11), one per team (§5, §9).
2. A role edit is an owner act, and a role carries nothing until its content is signed. Editing a bundle widens every seat holding the role at once: it is a configuration change that is not a same-copy (§9 table), a grant, by the owner or a grant holder bounded by §8; an editor may not widen a role its own seat references, nor any seat holding grant, agree or leads (the symmetry of the removal row). Before any role carries a capability, the role's resolved content is hashed and the hash agreed and checked at launch (§4, §10); until then the signed grant in the registry is the carrier, and the catalogue is read by people.
3. A seat's list is its role's bundle plus its own seat-level grants, inside the team envelope, deny winning (the Kernel's Grants section, point c). A seat grant may add a capability within the envelope; it reaches no other seat and never widens the envelope. It is a rare exception, dated and reasoned; the same exception on two seats of one role is a new role, by inheritance (009 commitment 2), and team check reports a seat grant repeated across a role's seats. The signed team grant stays required beside a roles section: the roles are reusable definitions, the team grant is the per-team ceiling.
4. A narrowed role revokes. Narrowing a bundle revokes every live lease that the seat's new list no longer covers, fail-closed as §8 does for a removed declared-set name, and a same-copy agreement resting on the old hash is re-agreed.
5. The seat keeps its id, list, leases and address; program-bound facts are re-attested. A relaunch of the same binding keeps everything. Any other change of occupant revokes the seat's live leases (the rule of §8 made explicit for every occupant change); a change of lab, CLI or account is a rebind, the owner's act (§8), which also invalidates agreements until agreed again, and the lab binding reads as stale in team check meanwhile (§5: a missing or unsigned binding refuses the cross-lab predicate). The ledger keeps the signing triple beside the seat id, and the author-inequality of §5 checks both the seat and the occupant's signature: a program that moves from a builder seat to a reviewer seat may not gate or merge the work it authored in the first.
6. When no universe is selected (the earlier and default scheme), a seat is named after its role, with a two-digit ordinal when the role repeats, fixed at creation and never renamed by a role rename; when a universe is selected, universe-entry naming and re-cast renaming follow 009 commitments 12 and 13 (keeping the seat's stable registry id and never renaming existing seats on a universe-setting change); this catalogue gives each seat one role (the Kernel allows more, §4; the reviews keep one for 0.5.1). Nothing resolves by a role's or a seat's name: the lead is the seat whose bundle holds leads (009 commitment 11), reached by lead@<team> (an owner decision; 002); lead is reserved as a seat name and as a nickname.
7. A nickname is unique within the team, two teams may share one, and it confers nothing (two owner decisions: the owner settled on question 5 that two teams can have the same nickname; at the 0.5.0 line a seat field in the file's digest is unique in its team). It is never equal to a seat name of its team; @<nickname> resolves in the caller's team first, then across the entity, and is refused with the candidates listed when two teams match; a human surface that spans teams prints <nickname>@<team>; the registry id is the canonical form (002, the address).
8. A role names its skill set; a seat binding delivers it. required is the binding's, never the role's (009 commitments 4 and 7): a role that names a skill the harness cannot deliver is reported or refused by the required-skill-delivery policy at launch, not by the role.
9. Lifecycle operations are never a capability, never leased, never a role's. start, stop, restart, reload, add and remove have one principal each in the §9 table, the owner or leads for its own team; a grant carries none of them (the Kernel's Grants section, point f) and a lease carries only operational capabilities (§7). A seat that runs another team's lifecycle, or its own team's on the lead's line, does so under a lifecycle delegation record (the Kernel's Lifecycle delegation section): the signer is the principal, the seat the actor, one act per team.
10. The team file is a reserved object (Kernel §3): no role holds write on it, in whole or "outside its sovereign sections", since a path scope cannot carve a section. It changes through the tool's commands under the owner's approval over the file's digest; write names only the file effect of an approved command.
11. A gate pass comes from a gate holder distinct from every author (§5), and merge consumes it (§3, §15). The catalogue says which role holds gate; where today's scripts stamp a pass, the stamp is the practice's and the Kernel's record is to build (005).

A.3 Never in any role

The owner's list, with where each power lives instead:

Power	Where it lives
grant, delegating a grant, revoking a grant	the owner; a grant holder is a second owner by the owner's signed grant to a seat, never by a role (Kernel §10)
setting a policy (the policy catalogue)	the owner; a holder named by grant, per policy
remove --abandon	the owner only, dev mode included (an owner decision)
check --repair	the owner: the repair rewrites registry records, reserved objects (§3)
editing the team file by hand	nobody: the file is a reserved object, changed by the tool's commands under the owner's approval over its digest (rule 10)
a lifecycle operation on another team, or on one's own team without being its lead	a lifecycle delegation record signed by the owner or the lead (the Kernel's Lifecycle delegation section), never a capability
pushing a product trunk, merging main	nobody by role: a trunk merge needs a gate pass and the author-inequality (§5, §15); the owner's go for a release (an owner decision)
publishing a package, a tag or a release	the owner's go (two owner decisions); act-as on the publish account is in no role
deploy, any environment	in no role of either team; the capability exists for a seat the owner grants it to, consuming a gate pass

A.4 The catalogue

Capabilities are the Kernel's words; the scope in brackets is where the capability is bounded (§6), always inside the entity's declared roots. A skill set is named, not defined: the names are proposals for the library (009 commitment 1), and a skill never gates.

The entity's own team

Seat	Role	Capabilities	Skills	Never
architect	architect	read [entity roots]; write [the knowledge base's drafts, work files and records of the RFC series; never an accepted text, which changes only by an amendment's acceptance]; review [texts of the series, as a reviewer of wording and claims]	rfc-tiers process; read-only code trace against a named commit; docs lint, link check and the generated indexes; verification record before a commit	merge, gate, act-as, any lifecycle operation, any code change, any edit of an accepted text or a team file
main-orchestrator	main orchestrator	leads [the entity team]; read [entity roots]; write [the knowledge base's drafts, work files and records; the briefs; never an accepted text, never a team file]; review [the series' commits before push]; use-broker [the entity's task resources]; plus one lifecycle delegation record (below)	orchestration across teams; the owner's channel and decisions log; release flow and the acceptance plan; quota and pace	grant, agree, create; policy set; remove --abandon; check --repair; a product trunk merge; publish; deploy; an edit of a team file by hand
communication	communication	read [entity roots and team state across the entity]; plus send/route grants to address leads and seats across the entity through the communication module (two owner decisions)	read state; route asks; confirm commands; speak on every channel (an owner decision)	grant, agree, create, leads; policy set; merge, gate, deploy, act-as on a publish account; any lifecycle operation; any code change or edit of an accepted text or a team file

The communication role (an owner decision). Three things are kept apart: the communication module (002 Communication: channel adapters, one envelope, one inbox and one router), the communication seat (communication, the role that converses with the owner on every channel through that module, reading state, routing asks, confirming commands and speaking on every channel), and the seat's nickname or universe name, which a universe may give it.

The main orchestrator's reach. "Main orchestrator" is not a new capability word (the vocabulary is closed, Kernel §3), and its reach is not a grant (a grant carries no lifecycle operation, the Kernel's Grants section, point f, and a seat grant never widens the team envelope). It is the entity team's leads, the lead of the team whose project is the entity, which the send admission already reaches from every team lead of the entity, plus one owner-signed lifecycle delegation record (the Kernel's Lifecycle delegation section) naming the seat by its registry id, carrying start, stop, restart, reload, add-same-copy (authorized by the owner's standing agreement to the copies each file declares) and remove-ordinary (never a seat holding grant, agree or leads), for every team of the entity, one act per team: a stop of one team never reaches another (§9). It replaces the pane-keyed delegates entries in each team file with one record on the seat, surviving a pane change and an occupant change within the seat's binding. Sending to any seat of the entity is not part of it: the lead-to-lead rule reaches every team lead, and any further pair is the owner's send grant, a setting (002). It gives no owner power: the sovereign sections of a team file (delegates, leads, budgets, limits, identity, trust) stay the owner's.

The other seats of the entity's team (operator, recorder, two reviewers, first assistant; the communication seat is catalogued above per an owner decision) keep their roles and are catalogued in a later revision.

TeamCLI

Seat	Role	Capabilities	Skills	Never
orchestrator	orchestrator	leads [TeamCLI]; read [the repository, the notes folder]; write [the notes folder; never the team file]; review [branches]; merge [the integration branch only, consuming the reviewer's gate pass; never main]; use-broker	the release flow (candidates, the suite at three paces, the acceptance plan); the gates; the queue and briefs	a trunk merge; gate or merge on work its own occupant authored (§5); act-as; publish; deploy; an edit of the team file by hand
builder-01 … builder-07	builder	read [the repository]; write [feature and fix branches of the repository, never a trunk, never a reserved object]; use-broker [claim and lease a task]	the code's conventions; tests with the code; the commit signature; the light check before a push	merge, gate, review, act-as, any lifecycle operation
tester-01 … tester-03	tester	read [the repository]; write [test files and scratch homes; a report in the notes folder]; review [a branch, as a report to the lead: the verdict record of the ledger is the reviewer's]; use-broker	the acceptance harness; probes in a scratch home, never on a live team; the suite's parsers and reports	merge, gate, act-as, any lifecycle operation
operator-01 … operator-03	operator	read [the repository]; use-broker; merge [the integration branch] by lease from the orchestrator per line (§7: an operational capability, leasable, bounded and expiring), never standing; lifecycle acts under a lead-signed lifecycle delegation record (the Kernel's Lifecycle delegation section), on the lead's line	the merge train and the gate stamps; the lifecycle commands on the lead's line; the machine's heavy slots	a standing merge; a trunk merge; gate; review; publish; deploy; any lifecycle operation on its own initiative
documentarist	documentarist	read [the repository]; write [the repository's docs, readmes and changelog, on a branch]	the readme check; the changelog; the command reference	merge, gate, review, act-as
archivist	archivist	read [the repository, the notes folder]; write [the notes folder's archive and history paths]	filing and history folders; the queue's hygiene	merge, gate, review, act-as, any code change
reviewer	reviewer	read [the repository]; review [a branch, a verdict record]; gate [the integration branch, after a green light check and suite; never on work its occupant authored]; write [its review folder only]	the review terms; the cross-lab predicate (its lab binding differs from the authors')	write to the repository, merge, act-as, any lifecycle operation

The gate pass the orchestrator's and the operator's merge consume is the reviewer's gate record (rule 11); the light check and the hourly suite are the evidence it reads, not the pass. Lifecycle operations run by an operator are not leases and not role capabilities (rule 9): the orchestrator is the principal, the operator the actor, under a record the orchestrator signs for its own team.

A.5 What is true at int/0.5.1 8acb470b, and what is still to build

A role is a required string on a seat and nothing else; no team-file section declares roles or skills, and the resolver fills the role's bundle with nothing (src/permissions/who.ts). Capability grants are built as owner-signed records keyed by the seat's registry id or the team id, with the closed vocabulary write, read, review, gate, merge, deploy, act-as, use-broker, a scope inside the declared roots and an expiry checked at every use; a team grant is the envelope and refuses grant, create, agree and leads (src/permissions/grants.ts). The nickname is a seat field, unique in its team, lead reserved for new names and nicknames. A seat rename keeps the id, the grants, the task leases (src/tasks/lease.ts), the pending drops, the mailbox messages, the rules file and the queue files (src/commands/rename.ts); Kernel operational capability leases are not built; the catalogue's earlier reading that a rename mints a new id and leaves the grants on the old one is false at this tag. delegates is still a third mechanism, keyed by pane (src/file/sections/delegate.ts); the catalogue's dev-mode reading of a lifecycle act was not re-checked here and is left to the operations spec.

For the catalogue to be read by the tool, in the order rule 2 requires:

• (i) Not built. The role's resolved content hashed, agreed and checked at launch; no roles section exists to hash.
• (ii) Not built. A roles section carrying capability words and a skill set, filling the bundle the resolver already intersects with the envelope; the signed team grant is already built and stays required beside it.
• (iii) Built. The seat rename keeps the id, the grants and the task leases, and the registry reads the stable handle (src/commands/rename.ts, src/tasks/lease.ts); Kernel operational capability leases are not built.
• (iv) In part. The nickname's collision with another seat's nickname or name is refused where names are written; entity-wide uniqueness is not ruled and not built.
• (v) Not built. The lifecycle delegation record of the Kernel's Lifecycle delegation section; the pane-keyed delegates section and the dev-mode dependence stand until it exists.
• (vi) Not built. The reviewer's gate record that a merge consumes (005); gate is a grantable capability word, not a record of its own.

A.6 Open, for the round

1. A push to the knowledge base's main: settled by an owner decision: not for drafts and work files; yes for a change to an accepted text, a decision record or a source copy, which are protected like a trunk (commitment 20).
2. Settled, pending the round: the signed team grant stays required beside a roles section (rule 3).
3. Settled: operator lifecycle operations are neither leases nor role capabilities; the lead is the principal and the operator the actor under the Kernel's Lifecycle delegation section's record (rule 9).
4. Settled for 0.5.1: one role per seat.
5. Settled by the owner (an owner decision): nicknames are unique per team and two teams may share one; @<nickname> looks in the caller's team first, then across the entity, and refuses an ambiguous match listing the candidates (rule 7).
6. For the build: Who stamps the gate pass in 0.5.1: the reviewer's gate record as rule 11 says, or the scripts' stamp read as the pass until 005's record exists? Still open at this tag: gate is a grantable word and no gate record exists.
7. the Kernel's Lifecycle delegation section's own questions (re-delegation, the two-granter, the notice, register).