Charter

Charter

Status: Accepted — 2026-10-11

1. The question

What does TeamCLI stand on: what do we believe, what is a team and how does it live, and how do we decide?

2. What we propose

What TeamCLI stands on, in three parts: what we believe, what a team is and how it lives, and how we decide.

This is the Charter, the first of four tiers (see "The series"). It ships no code; every other tier conforms to it. It holds beliefs and concepts. What the tool enforces — who may act, what an agent may do, what is refused — is not written here but in the Kernel, and the mechanics of a team's seats and of a piece of work are in the Runtime. Where this text names such a rule, it points to where the rule lives.

TeamCLI is young. Part 1 is what we believe and hold ourselves to; Part 2 describes a team as we are building it. Most of both is not built. Section 6 says, belief by belief where one can be checked and step by step, what the released version does. Everything else is a direction.

Part 1. What we believe

install teamcli and let's do this…

This is what we are building. Say it to an AI agent you already use. It looks at your project, finds the agents you have, and proposes a team. You say yes. The team gets to work.

1. A team across labs — why TeamCLI exists. No agent is best at everything. Where a lab offers its own multi-agent tool, it can build a team of that lab's agents; TeamCLI is for the team that spans labs — Claude, GPT, Grok, Gemini, DeepSeek and more, from different companies, working as one team under one set of rules — the cross-lab team that is TeamCLI's reason to exist. (A single lab's own tool builds a team of that lab's agents; assembling agents from different labs under one set of rules is what TeamCLI is for.) Why it matters: a review by a different lab is independent to the degree the labs genuinely differ, where one model's review of its own kind carries the same blind spots; when one lab's limit or outage hits, the rest can carry the work where they are available and able; and each role goes to the agent that fits it, from any lab. (A single-lab team still runs under TeamCLI — it is simply not what the tool is for.) TeamCLI MUST assemble AI agents across labs under one set of rules so a team can draw on different companies' agents as one team, while a single-lab team MAY still run under TeamCLI. Spec: none (Tier 0 belief; CLI profiles live in Specs-launch and Specs-registries-cli-ranges). Proof: src/profiles/ and bun run conformance at v0.5.0. Today (v0.5.0). src/profiles/ ships eight CLI profiles across labs (antigravity, claude-code, codex, cursor, gemini, grok, jules, muse), launched and watched under one team configuration (src/commands/up.ts, src/watch/pass.ts).

2. For software teams, on any git repository. TeamCLI is a team of AI agents for your code — your repositories (the code and its supporting repositories: docs, site, infrastructure), your commits, your reviews. The model that gives it value — version-controlled code, review and merges — is code-specific, and it runs on any git repository, local or hosted. The forge is an adapter: pull requests, issues, CI, wiki and projects are what a forge adds, and TeamCLI reaches them only through an adapter for that forge (GitHub and local workflows run today; the clean forge adapter is not yet built, and GitLab, Gitea, Bitbucket are not promised universal here). A repository on a forge with no adapter yet still works at the git baseline; its hosted features are reported unavailable until the adapter exists, and a task that needs one waits or escalates — never silently half-done. With no forge at all, the team works in plain git (branches and merges) and the hosted-only features are simply absent. Other kinds of project — pure research, writing, operations — are not what this tool is for; the concept may carry further one day, in another tool. TeamCLI MUST run on any git repository — local or hosted — and reach hosted forge features only through a forge adapter, reporting hosted features unavailable and waiting or escalating (never silently half-done) when no adapter exists for a forge. Spec: none (Tier 0 belief). Proof: test/check.test.ts and test/worktree.test.ts at v0.5.0. Today (v0.5.0). Local git repositories and worktrees run in src/worktree.ts and src/check/git.ts; a clean forge adapter is not built.

3. You set the limits. Agents act and decide inside them. What you gave, you can take back. An agent MUST act and decide only within the capabilities and leases its owner set, and the owner MUST be able to take back what was given (Kernel §3, §7, §8, §10, §11). Spec: none (Tier 0 belief; enforced in Kernel §3, §7, §8, §10 and Specs-grants). Proof: test/grant.test.ts and test/permissions.test.ts at v0.5.0. Today (v0.5.0). The owner issues signed grants (src/commands/grant.ts), delegates lifecycle commands (src/commands/delegate.ts), and revokes grants (src/commands/revoke.ts), each from a terminal outside a seat; team up admits from the live team file, which is the record and needs no approval (src/commands/up.ts; UPGRADE-0.5.md), and approval records retained from 0.3.5 are compatibility data. The capability resolver (src/permissions/resolve.ts) gates the operations wired in 0.5.0, against a mistake (M), not OS containment (A) (Kernel §14).

4. What a team may do is written down, where you can read it. Every team's authority, seats, grants, and policies MUST be written down where the owner can read them. Spec: none (Tier 0 belief; record formats in Specs-records-and-ledger, Specs-grants, Specs-policies). Proof: test/rights.test.ts and test/policy.test.ts at v0.5.0. Today (v0.5.0). Every command reads the live team file (.agents/team.yaml), which is the record and needs no approval; signed grant and revocation records (src/grant.ts), signed policy records (src/policy/), and the registry (src/registry/) are stored on disk and inspected via team check, team status, and team policy; approval records retained from 0.3.5 are compatibility data.

5. Yours to set. How a team works is a setting you can change, with a default that works if you never do. A few things hold whatever is set, and each RFC names its own. How a team works MUST be a setting the owner can change, with a working default when unset, except for the invariants each RFC names as holding whatever is set. Spec: none (Tier 0 belief; policy chain in Specs-policies). Proof: test/policy.test.ts at v0.5.0. Today (v0.5.0). src/policy/ implements the four-level policy chain (entity, project, team, seat) with tightening-only inheritance (team policy).

6. Evidence before a claim. A claim comes from work whose result can be shown, not from memory. A review that did not look is not a review. A claim MUST come from work whose result can be shown, not from memory. Spec: none (Tier 0 belief; gate and review rules in Kernel §5, §15 and RFC 005 Quality). Proof: scripts/coverage.ts and scripts/conformance.ts at v0.5.0. Today (v0.5.0). Screen conformance captures require stated provenance (scripts/coverage.ts), docs examples execute in the test suite (test/docs.test.ts), and commit/PR checks verify signatures (src/check/); Kernel gate and review effect records (§15) are not built.

7. Security first. We tell you what protects you, and what doesn't. TeamCLI MUST tell the user what protects them and what does not. Spec: none (Tier 0 belief; enforced boundary in Kernel §11, §12, §14). Proof: test/about.test.ts and test/doctor.test.ts at v0.5.0. Today (v0.5.0). SECURITY.md, team --about, and team doctor state what protects the user and what does not.

8. One sentence to start. That is the aim. If getting started needs a manual, we have failed. Getting started SHOULD take one sentence to an agent the user already uses. Spec: none (Tier 0 aim). Proof: none yet. Today (v0.5.0). Not built as a one-sentence agent-driven proposal; team init (src/commands/init.ts) writes a starter team file.

Part 2. What a team is and how it lives

This part holds concepts only. Where a step needs a rule the tool enforces, it points to the Kernel by section; where it needs the mechanics of a seat or a piece of work, it points to the Runtime.

9. Projects, repositories, seats, and authority (Part 2 opening). A team is a group of AI agents working on one project — one repository or several (a repository is a git repository: the versioned source the team works in, local or hosted on any forge). A seat works in the repositories its role is scoped to. A change may touch more than one repository; then it is coordinated changes, each checked and accepted on its own. How each change is checked and accepted — and that there is no single cross-repo accept — is the Kernel's (§3, §6, §15); whether the whole task is complete, which it is only when every one of its changes is accepted, is the Runtime's work-item lifecycle (a deliberate forward reference: the Runtime, Tier 2, is not yet written). Anything forge-specific — how a review or an issue is opened, how CI is read — lives behind a forge adapter, so the same team model runs on a local repository with no forge, or on any forge TeamCLI has an adapter for; this forge adapter is distinct from RFC 008's tracker adapter (the backlog), and a no-forge project uses the file tracker. Each agent holds a seat: a role, and what it may do — what it may do is its capabilities, and nothing else (Kernel §3, §4). An agent comes from a lab, the company that makes it. No lab is meant for a role: which agent holds which seat is the team's own choice. Every team has someone who decides for the project. At first that is its owner, the person who started the team. An agent MUST act and decide only within the capabilities and leases the owner set (Kernel §3, §7); who may do each operation is set out in one table (Kernel §9). agree, grant, create and leads are never leased or copied to an agent (Kernel §3, §10). No agent holds grant unless the owner writes it, and a holder is a second owner, bounded by Kernel §8. Something an agent creates or approves is that agent's act, and never counts as an act of the owner (Kernel §10, §11). How a right is given, and taken back, is the Kernel's (§7 leases, §10 grant and agreement). Who decides is written down. When that changes, the change is written down too. An owner who wants to share that, with other people or with agents they trust, will be able to set up a board. Who sits on it, what it takes to pass a decision, who can refuse, and whether the board may change any of that: the owner sets it. TeamCLI will propose a rule to start from. It will be written down, where you can read it. How several voices become one decision is the subject of RFC 006 (Consensus). Spec: none (concepts; enforced in Kernel §3, §4, §6–§11, §15 and Runtime). Proof: test/permissions.test.ts and test/grant.test.ts at v0.5.0. Today (v0.5.0). Single-repository and worktree teams run (src/worktree.ts), capabilities and grants are resolved (src/permissions/, src/grant.ts), and file and linear task sources run (src/commands/next.ts, src/commands/broker.ts); multi-repository task completion and a built-in board are not built.

10. The life of a team (Part 2, steps 1–9). How a seat is started, stopped, filled again or handed on is the Runtime's; who may start, stop, add or remove a seat is the Kernel's (§9). What each step does today is in "What is true today". A team's lifecycle MUST respect the Kernel's authority gates across its nine conceptual steps:

    1. Proposed. A team begins as a written proposal. That an agent draws it up from one sentence is where we are heading.
    2. Agreed to. The proposal gets its yes. Who may give it, and what the tool refuses until it is given, is the Kernel's (§9, §10).
    3. Staffed. The seats that were agreed are filled. When one stops, it is filled again, its work goes to another seat, or the work waits until someone decides. Which seat may take the work is the Kernel's (§9); how it is handed on is the Runtime's. We are building towards that.
    4. At work. The team takes pieces of work; each has a life of its own, described below. Much of the time a seat is waiting: for a decision, for another seat, for a person.
    5. Changed. When the team needs more than was agreed (a seat that was not agreed, a seat allowed to do more, a higher limit), that is a new proposal. Who may agree to it, and which changes are the owner's alone, is the Kernel's (§8, §10).
    6. Interrupted. A seat can stop without anyone deciding it: a limit is reached, or its work is cut off in the middle. We are building towards a TeamCLI that notices, says so, and hands the work on, together with what was written down (the Runtime).
    7. Paused and resumed. A team can be stopped from taking new work, and started again. What was written down is kept, and so is what the team was given to remember (RFC 003, Memory). What lived only inside a seat is not.
    8. Renewed. A seat can be started afresh, or go on with what it holds, as the team is set up to do. What is sure to remain is what was written down.
    9. Ended. The team stops. What it wrote down stays with those it worked for. Spec: none (concepts; Runtime mechanics in Specs-launch, Specs-seat-state-and-watch, Specs-registry). Proof: test/up.test.ts, test/down.test.ts, test/watch.test.ts, test/restart.test.ts, test/reload.test.ts at v0.5.0. Today (v0.5.0). Steps 2, 3, 4, 5, 6, 7, 8, and 9 hold in part through team init, team up, team down, team add, team remove, team restart, team reload, team status, and team watch (src/commands/, src/watch/); step 2 is the live team file, read by every command and approved by nothing (UPGRADE-0.5.md); drawing up a team from one sentence (step 1) and automatic work hand-off on interruption (step 6) are not built.

11. The life of a piece of work (Part 2, steps 1–7). The life of a piece of work has one home, the Runtime; its steps are below as concepts. Who may ask, agree or accept is the Kernel's. Each piece of work MUST follow the Kernel's authority and gate rules across its seven conceptual steps:

    1. Asked. Someone says what they want. Whose word a seat takes as an instruction is the Kernel's (§11).
    2. Proposed. The team answers with a plan: who will do it, and what it expects it to take, as far as it can tell.
    3. Agreed. A yes. Who may give it is the Kernel's (§9, §10); how a board's several voices become one yes is RFC 006 (Consensus).
    4. Carried out. Within what was agreed, and within the seat's capabilities and leases (Kernel §3, §7).
    5. Checked. In the way the team is set up to check: by another agent, by running it, by a person. The report says what was checked and what was not. Which checks are required, and when work counts as done, is the Kernel's (§3, §5, §15) and RFC 005's (Quality).
    6. Reported. The result comes back to the one who asked, with what was done and how it was checked.
    7. Answered. It is accepted, sent back, or dropped, by whoever may accept it (often the one who asked; who may is the Kernel's). Sent back, it is carried out again or proposed again. That is ordinary, not a failure. Work can stop at any step, blocked or waiting for a decision. When it does, the one who asked should be told; that, too, is something we are building towards. At every step, who may act and what protects you is the Kernel's; how the step is carried is the Runtime's; the seven modules add what each is for. Spec: none (concepts; task claiming in Specs-tasks-and-broker, records in Specs-records-and-ledger). Proof: test/next.test.ts, test/broker.test.ts, test/commits.test.ts, test/pr.test.ts at v0.5.0. Today (v0.5.0). team next and team broker claim tasks from a file or Linear (src/commands/next.ts, src/commands/broker.ts), and team commits check / team pr check check commit and pull-request signatures (src/commands/commits.ts, src/commands/pr.ts); the full seven-step work-item lifecycle and the Kernel's gate/review/merge effect ledger (§15) are not built.

Part 3. How we decide

12. Two kinds of question, and what a public RFC contains (Part 3).

    • Why should this exist, and what should it be for the people who use it? That is a public RFC, like this one: a numbered public proposal, open to comments. It states commitments, who decides, what belongs to whom, and what it does and does not cover. It is written in plain language, for anyone deciding whether TeamCLI is for them.
    • How is it built? That is an internal design record. It holds the mechanics, and it MUST serve a public RFC: no design record may give TeamCLI a purpose that no public RFC has argued for.
    • A reader should be able to understand what TeamCLI is, and hold us to it, from the public RFCs alone.
    • What a public RFC contains. Every public RFC MUST contain at least these six parts. They are a minimum: a longer document may add sections of its own — for example the limits of what it can enforce, what it costs, its modular boundary (what it deliberately leaves to other documents), where it sits among the tiers, and its review record — as the Kernel's seventeen sections do:
      1. The question, in one sentence.
      2. What we propose, as commitments to the person using TeamCLI: what we bind ourselves to build and to keep.
      3. Why, including what we tried or saw that led here.
      4. What it costs and what it does not cover. A commitment with a hidden limit is not one.
      5. What would change our mind.
      6. What is true today. For each commitment, what the released version does. A text says "we are building towards" for everything else. Spec: none (the series' own constitutional rule, cited by Norms and practices §3). Proof: none (governance rule). Today (v0.5.0). In force across the rfc-tiers series.

13. Who decides and how, how this Charter changes, and the series (Part 3).

    • Who decides, and how. TeamCLI, the project, has chosen to have a board. It MUST decide for TeamCLI only: a team that uses TeamCLI answers to its own owner or its own board, never to ours. Like any board, ours sets how it decides, and writes it down; its rule is kept beside these RFCs. Its members hold great power over what TeamCLI commits to, so we must know who each of them is, by more than a password. How is the subject of the Kernel (§11: a key on the holder's own device).
      • Anyone may open a discussion proposing an RFC. It becomes a numbered RFC when the board takes it up, and it is discussed in the open.
      • The board accepts, changes or declines it. Once it has, the decision is written at the top with its date, its reason and who decided.
      • An accepted RFC is a commitment. Changing it takes a new RFC; the old one stays, marked as replaced.
    • How we review and accept an RFC today. Reviewers first, then the board. At least three reviewers from three different labs, none of them the lab that wrote the text, read it in rounds; with fewer, a round does not count. In a round the text does not change; each reviewer reads it alone and says what they find; the board decides each point and writes down why. The next round starts from those decisions: a point that was decided is reopened only if the new text contradicts itself or an earlier decision. Rounds go on until every reviewer stands behind the text; when the same point comes back three times, the board decides it and the disagreement stays on record. A reviewer that does not answer is never counted as agreeing: it is asked again, then replaced. When the reviewers are unanimous the board votes, and an RFC is accepted when its members all agree, each with their own vote: a vote is not lent to whoever drafted the text. Our board has two members, the project's founder and an AI agent, the main orchestrator. (For RFC 000's first acceptance, on 2026-10-06, a third chair held by an agent from another lab sat for that RFC only; that is history, not the standing board.) All of this is our board's current setting, not a rule for anyone else's; RFC 006 says what holds for any team that decides with more than one voice.
    • This Charter changes too. It is a living text, dated, kept with its history; every earlier version stays readable. Part 2 and Part 3 change by an RFC like any other. Part 1, what we believe, MUST change by the same rule, and only by a text that says which belief it changes and why. This re-lay changes no belief in Part 1. It moves rules out of Part 2 into the Kernel and the Runtime, and changes Part 3 where listed at the end.
    • The series. The series is laid in four tiers. Each tier rests only on the tiers below it; each of the seven modules rests on the Kernel and the Runtime, never on another module. Ten documents in all:
      • Tier 0 — the Charter. This text, re-laid from RFC 000. What we believe, what a team is and how it lives, and how we decide. It ships no code; every tier conforms to it.
      • Tier 1 — the Kernel: Authority, Capabilities & Trust (accepted 2026-10-09). The one fixed, enforced layer: everything the tool refuses, and why each refusal means something. Read it alone and you have read all of TeamCLI's power. It absorbs RFC 001 (Security) and the enforced half of Roles & Skills. RFC 010 (Delegation), which was proposed and never accepted, is retired into it.
      • Tier 2 — the Runtime: Harness, Work Items & Records. Starting a team and keeping it running (RFC 007, Harness); the life of a piece of work, in one home; and the record store and delivery that every module uses. It keeps the Kernel's ledger and sets no authority of its own.
      • Tier 3 — seven modules. Each enforces nothing new:
        • RFC 002: Communication. How a thing said reaches the one it is for.
        • RFC 003: Memory. What a team knows tomorrow that it learned today, and who decided so.
        • RFC 004: Analysis. Looking at a project, a team and its work, and saying what was found.
        • RFC 005: Quality. What makes work done, who says so, and what a check is worth.
        • RFC 006: Consensus. How several voices become one decision that can be relied on.
        • RFC 008: Planning, narrowed. A team reads its own backlog, pulls its work, and plans order and timing; the tracker is an adapter. Priority, assignment and acceptance stay human, as RFC 008 was accepted; who may do each is now the Kernel's, and the life of a piece of work the Runtime's.
        • RFC 009: Roles & Skills, in two halves. Roles, configurable: a team is staffed from reusable role libraries, bound per project, context and task. Skills, advisory: a skill grants no authority, and a role carries no skill dependency. What a role is allowed to do is enforced in the Kernel. Who may decide in your place, and how that trust is given, seen and taken back, is settled: it is in the Kernel. Delegation is a bounded, recorded lease (Kernel §7), and it is not an RFC of its own. Spec: none (Tier 0 governance and architecture). Proof: none (governance rule). Today (v0.5.0). The four-tier series is in place under rfc-tiers/; the Charter (2026-10-11) and the Kernel (2026-10-09) are accepted.

3. Why

• What the revisions change in Part 1, and why (Part 3):
  • The 2026-10-07 revision changed two beliefs, each named by this text's own rule:
    • "Agents propose. You decide. Your decisions are the team's limits." becomes "You set the limits. Agents act and decide inside them. What you gave, you can take back." Why: the first form made a person the one who decides everything, each time. What we are building is a team that works without its owner standing behind it: an agent may decide, agree or create where its owner gave it that right, and nowhere else (RFC 001). The limits stay the person's; the deciding inside them need not be. Note (2026-10-10): the Kernel narrows this. The text above is kept as it was accepted. Read now, "inside them" means: an agent acts and decides only within the capabilities and leases its owner set (Kernel §3, §7). agree, grant, create and leads are never leased or copied to an agent (Kernel §3, §10). No agent holds grant unless the owner writes it, and a holder is a second owner, bounded by Kernel §8. Some limits are the owner's alone, and no agent may change them (Kernel §8). And something an agent creates or approves is recorded as that agent's act; it never counts as an act of the owner (Kernel §10, §11). RFC 001, cited above, is absorbed by the Kernel.
    • "Yours to set." is added. Why: every text since this one was first accepted found the same thing, that a policy we were about to fix was a default a person should be able to change. It was a habit of ours; it is now a belief, with its own limit: what holds whatever is set, each RFC says for itself.
  • The 2026-10-08 revision names four more foundational changes (A–D):
    • (A) "Specialists, working as one team." becomes "A team across labs — why TeamCLI exists." Why: multi-vendor is not one advantage among several; it is the reason the tool exists. A single lab's own tool builds a team of that lab's agents, so assembling agents across labs under one set of rules is what TeamCLI is for. The old aside "whether they come from one lab or several" treated the point as incidental; it is central.
    • (C) "For software teams, on any git repository." is added. Why: the value model — commits, review, merges — is code-specific, so the scope, and what is out of it (pure research, writing, operations), is stated rather than implied.
    • (D) the forge is an adapter. Why: TeamCLI must not be tied to GitHub. Git is the floor and needs no host; GitHub, GitLab, Gitea, Bitbucket are forges reached through an adapter, and a local repository with no forge is first-class. Hosted features — pull requests, issues, CI, wiki, projects — are what a forge adds, reached only where an adapter exists.
    • (B) is a Part 2 change (a project is one repository or several), named here because it is foundational: a cross-repo change is coordinated changes, each accepted per repository, never one atomic cross-repo accept (the Kernel's, §3, §6, §15); the whole task is complete only when every one of those changes is accepted (the Runtime's work-item lifecycle, pending).
• Why the 2026-10-11 re-lay created the Charter (Changes from RFC 000): To separate Tier 0 (beliefs, concepts, and how we decide, shipping no code) from Tier 1 (the Kernel's enforced rules) and Tier 2 (the Runtime's mechanics), while preserving Part 1 word for word and keeping the dated acceptance history intact.

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

• Software and git only (Belief 2). Pure research, writing, and non-software operations are outside TeamCLI's scope.
• Hosted features wait on forge adapters (Belief 2). GitLab, Gitea, and Bitbucket are not promised universal until their adapters exist; a repository on an unadapted forge runs at the git baseline and escalates tasks that require hosted features.
• No code or enforcement in Tier 0. The Charter ships no code and enforces no rule of its own; every refusal belongs to the Kernel and every operational mechanic to the Runtime.

What this release must not pretend

• Most of Part 1 and Part 2 is direction, not built in v0.5.0. One-sentence team creation from a prompt, a clean forge adapter, multi-repo task completion, automatic work hand-off on seat interruption, the Kernel's append-only gate/review/merge effect ledger (§15), a built-in consensus board, and OS-level process/file containment (Kernel §14) are not built at v0.5.0 (52db9b75).
• Mistake guard (M), not OS containment (A) (Kernel §14). Until OS containment is built, approvals, grants, and policies guard against mistakes by agents running through TeamCLI, not against a determined same-user process or an agent started on the side.

5. What would change our mind

• How this Charter changes (Part 3, "This Charter changes too"). Part 1, Part 2, and Part 3 change by an RFC through the review and board process, keeping every earlier version readable as history; any RFC that changes a belief in Part 1 must state which belief it changes and why.
• Moving project-specific review and board settings out of the Charter (the 2026-10-11 acceptance). Moving the project's own board composition and reviewer-count rules out of the Charter into advised project policies changes meaning and goes as the Charter's first amendment, with a review round.

6. What is true today

"Today" is v0.5.0 (52db9b75) (re-reading the Charter's companion table at the tag).

#	Commitment	Today (v0.5.0 52db9b75)
1	A team across labs (Part 1)	In part: eight CLI profiles across labs (src/profiles/*.yaml) run under one team file (src/commands/up.ts, src/watch/pass.ts)
2	For software teams, on any git repository (Part 1)	In part: local git repositories and worktrees run (src/worktree.ts, src/check/git.ts); a clean forge adapter is not built
3	You set the limits; agents act and decide inside them (Part 1)	In part, against a mistake (M): signed grants and revocations (src/grant.ts), lifecycle delegation (src/commands/delegate.ts), and the capability resolver (src/permissions/resolve.ts) are built, owner-only from outside a seat; the live team file is the record and nothing approves it (src/commands/up.ts; UPGRADE-0.5.md); OS containment (A) and time-bounded task leases are not built
4	What a team may do is written down (Part 1)	In part: .agents/team.yaml is read live as the record, signed grants/revocations (src/grant.ts) and signed policies (src/policy/) are readable on disk and via team check, team status, and team policy, and the registry (src/registry/) is readable; approval records kept from 0.3.5 are compatibility data; the Kernel §15 effect ledger is not built
5	Yours to set (Part 1)	In part: src/policy/ implements the four-level policy chain (entity, project, team, seat) with defaults and tightening-only inheritance (team policy)
6	Evidence before a claim (Part 1)	In part: conformance capture provenance (scripts/coverage.ts), executable docs examples (test/docs.test.ts), and signature checks (src/check/) run in bun run ci; Kernel §15 gate/review records are not built
7	Security first (Part 1)	Built for disclosures: SECURITY.md, team --about, and team doctor state what protects the user and the "must not pretend" limits (src/commands/doctor.ts)
8	One sentence to start (Part 1)	Not built: team init (src/commands/init.ts) writes a static starter file; an agent drawing up a team from one sentence is not built
9	Projects, repositories, seats, and authority (Part 2)	In part: single-repo and worktree teams, capabilities, grants, and file/linear task sources run; coordinated multi-repo task completion and a built-in board are not built
10	The life of a team, steps 1–9 (Part 2)	In part for steps 2–9 (up, down, add, remove, restart, reload, status, watch); step 2 is the live team file, read by every command and approved by nothing; step 1 (proposal from one sentence) and automatic hand-off on step 6 (interruption) are not built
11	The life of a piece of work, steps 1–7 (Part 2)	In part: team next and team broker claim tasks (src/commands/next.ts, src/commands/broker.ts) and team commits check / team pr check check signatures; the full seven-step work-item store and Kernel §15 ledger are not built
12	Public RFCs vs internal specs, and the six required parts (Part 3)	No code (constitutional rule of the rfc-tiers series, applied by Norms and practices §3)
13	Board governance, Charter amendment rule, and the four-tier series (Part 3)	No code in Tier 0; the four-tier layout is in force under the rfc-tiers series

7. The security boundary

The Charter defines no security mechanism of its own. Every authority rule, capability gate, signing requirement, and refusal belongs to the Kernel (Kernel), and the same-user boundary (M, against a mistake, not A, against an attempt until OS containment is built) is stated once in Kernel §14 and SECURITY.md.

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

Tier 0, the foundation of the four-tier series ("Ten documents in all"). Every other tier conforms to it: Tier 1 (Kernel) owns all authority, capabilities, grants, leases, and refusals (absorbing RFC 001 Security and retiring RFC 010 Delegation); Tier 2 (Runtime) owns seat lifecycle, the work-item lifecycle, the registry, and record delivery (carrying RFC 007 Harness); and Tier 3 owns the seven modules (RFC 002 Communication, RFC 003 Memory, RFC 004 Analysis, RFC 005 Quality, RFC 006 Consensus, RFC 008 Planning, RFC 009 Roles & Skills).

9. Prior art and alternatives

• Owner decides every action vs owner sets limits (Part 3, 2026-10-07 revision). RFC 000's original belief ("Agents propose. You decide. Your decisions are the team's limits.") was replaced on 2026-10-07 because requiring a person for every decision prevented a team from working unattended within owner-set capabilities and leases.
• Incidental multi-vendor vs reason to exist (Part 3, 2026-10-08 revision A). Treating cross-lab composition as an aside ("whether they come from one lab or several") was rejected on 2026-10-08 because a single lab's own tool already builds single-lab teams; cross-lab composition under one set of rules is TeamCLI's reason to exist.
• GitHub-coupled model vs forge adapter (Part 3, 2026-10-08 revision D). Coupling TeamCLI to GitHub was rejected on 2026-10-08 in favor of plain git as the baseline and a forge adapter for hosted features.
• Separate Delegation RFC vs Kernel §7 (Part 3, "The series"). Proposed RFC 010 (Delegation) was retired into the Kernel because delegation is a bounded, recorded lease (Kernel §7).

10. Open questions

None open inside the accepted Charter text (Changes from RFC 000 item 16 closed the delegation question in Kernel §7). Three post-acceptance items are tracked outside the accepted text:

1. Pending board confirmation of the 2026-10-12 and 2026-10-17 editorial records: zero replacements in the first; two companion-file links and frontmatter pointers in the second.
2. Planned Charter amendment 01 (an owner decision): moving the project's own board composition and reviewer-count settings out of Part 3 into advised project policies.
3. Subsequently drafted 010 Workflow module: the accepted Charter lists ten documents in all (Charter, Kernel, Runtime, and seven Tier 3 modules: 002, 003, 004, 005, 006, 008, 009) and retires the original RFC 010 (Delegation) into Kernel §7; the rfc-tiers series has since drafted a new Tier 3 module, 3-modules/010-workflow/workflow.md, which is not yet added to the accepted Charter's series list.

12. Links to the spec

None: the Charter (Tier 0) ships no code, and its Part 3 rules are cited by the series rather than moved to a spec.