003 Memory

003 Memory

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

The module answers the remainder the Kernel and the Runtime leave it: what a team remembers between tasks and days, at which level, who writes it and when, how a start reads it, and what is never kept. It registers no capability and adds no refusal (Kernel §13).

1. The question

A team's agents come from different labs, are restarted, replaced, and lose their thread. RFC 003 asked what a team knows tomorrow that it learned today, where it is kept, and who decided that it should be known. Since then the Kernel has fixed who may do what (a right is a capability on a seat's list, §3; what a seat may hold is given by the owner or a grant holder, §9, §10), the Runtime has named the store (five record sets, commitment 26) and the handover (commitment 13, not built), and the owner has asked for two more things: that an agent may read another agent's memory only by a grant (2026-10-12), and that the recording of conversations is a setting, from nothing to everything (2026-10-13). On 2026-10-18 the owner asked for two more: that each entity has a vault, handled by the tool, and that a seat's conversation is scoped to its task (three owner decisions). So the module's question is the remainder: what is memory and what is not, at which level an entry lives, how an entry enters and leaves, what each agent is given at a start and after a restart, what is never kept, and what the entity's vault is and who may touch it, with no right the Kernel does not name?

2. What we propose

Seventeen commitments: the twelve of the current text — nine from RFC 003, re-laid, two for what the owner asked since, and the settings — four for the owner's directions of 2026-10-18 on the vault and the task's context (three owner decisions), under a new chapter F, and one for the default knowledge folder of the archived project-folder decision of 2026-10-05, observed and never enforced, under a new chapter G. Each says what it keeps here, what it leaves to a tier below, and what 0.5.0 does.

A. What memory is, and whose

1. What a team learns belongs to you. Memory MUST belong to the owner, not to a lab, not to a machine, not to one agent's conversation. The record is with the owner's projects, in plain text, one fact to an entry, outliving any agent and any program that reads it. The Runtime names where it is kept (commitment 26: the store); this module names what is kept: how to work, as distinct from what was decided (the knowledge base's decisions) and what is being done (the plan, 008). Memory is the third record and MUST NOT be either of the other two: an entry that records a decision is a pointer to the decision's record, and an entry that records a task is not an entry. Spec: the store is the Runtime's; the entry's shape is in §12. Proof: none yet (the rules' delivery is proved by test/launch/rules-file.test.ts, which is not memory). Today (v0.5.0). TeamCLI keeps no memory. It keeps rules: the team file's rules section, a list of strings the owner writes, with no source, no level and no date on any of them (src/file/sections/rules.ts). Everything else a team remembers is kept outside the tool: the knowledge base of the owner's choice, Floor Docs by default and never hardcoded (an owner decision), where decisions and the state of projects live; a current-state page every seat reads at a start and after every compaction (the team-memory practice); and each lab's own notes. The tool reads none of the three.

2. Every agent reads the same memory, whatever its lab. When an agent starts, it MUST be given what the team knows and it is allowed to know. Two agents allowed the same things are given the same memory, whichever labs made them; an agent allowed less is given less (commitment 9). The giving is the launch's (Runtime commitment 10): the text is this module's, the delivery the Runtime's. Spec: the rules text and its carriers are in Specs-launch §3. Proof: at the tag, test/launch/rules-file.test.ts. Today (v0.5.0). True of the rules, and of nothing learned since. A launch builds one rules text per seat (src/launch/rules.ts, rulesOf) and gives the same text to every seat of the team whatever its CLI; only the carrier differs by profile (rulesMode): a launch option, a first typed message, or a line prepended to every brief. A message seat's text is a file in the project's state folder, named by a typed line that carries its hash prefix and is read back before Enter (src/launch/rules-file.ts); team reload <seat> closes and relaunches a seat whose recorded model, version or effort differs from the file or whose rules file no longer holds the live text (src/commands/reload.ts); remove deletes a temporary seat's rules file and leaves a declared seat's.

3. Memory has levels. The levels are the ones the Kernel's Policies section gives every setting: the entity, the project, the team, the seat. An entry MUST live at the widest level where it is true; a narrower level adds, and contradicts only by saying so, in the entry. The owner's three memories of 2026-10-12 (the first assistant's private memory, the shared memory, the owner's memory above both) are instances of these levels, read so: the private memory is the seat's own level, the shared memory the entity's, and the owner's memory is not a level of memory at all but the grants and the decision log the Kernel keeps (§10, §15; question 4). The first assistant's private memory MUST be pinned at the seat's own level and loaded before any summary, so that a summary or compaction cannot displace it (an owner decision). Spec: the levels' form is the policies spec's; memory adds no level; the pinning is this module's. Proof: none yet. Today (v0.5.0). No levels of memory: the rules are the team's, one list per team file. The levels themselves exist for other things: the settings chain reads the machine's own settings file, an entity's liveness: map, a project record's, the team file's watch section and a seat's own liveness: map for three thresholds (src/settings/declared.ts, inherit.ts), and the policy object carries a level among entity, project, team and seat (src/policy/types.ts, POLICY_LEVELS). Nothing of memory rides either, and nothing is pinned or loaded before a summary: the rules are the team's one list, not a seat-level record.

B. How an entry enters, and leaves

4. Nothing becomes memory without someone accepting it. Any agent MAY propose an entry. It MUST become memory only when someone who holds the right to accept it does. That right is a capability of the Kernel's vocabulary and nothing of this module's: the memory at a level is a reserved object of that level, and accepting an entry is the write to it that only the owner, or a seat the owner named by grant for memory's objects, may make (Kernel §3, §9; question 1). A memory every agent reads is a way for one agent to steer all the others, which is why writing to it is a decision and not a habit. And memory MUST NOT be authority: an entry says how to work and cannot change a seat's list, a limit, an agreement, the labs a team uses, or anything else the Kernel records; an entry that says otherwise is shown to the owner as a contradiction and given to nobody. The act stays here: the proposal, the acceptance, and the contradiction shown. Spec: acceptance is a Kernel write; the record it leaves is §12's provenance. Proof: none yet. Today (v0.5.0). True of the rules only, and weakly: the rules section is an owner section of the team file (owner: true), but 0.5.0 launches from the live file, a changed or never-approved file included, and the difference is a team check or team status line, not a refusal (src/commands/up.ts: "the live file is the record"); whoever can edit the file writes the rules every seat is given. No seat proposes a rule, nothing accepts one, and nothing checks a rule against what was agreed: a rule that said "run team grant" would be typed to every seat and refused only by the command's own gate.

5. An entry says where it comes from. An entry MUST say who proposed it, who accepted it, when, and from what: a correction the owner gave, a fault that was found, a decision by its id. An entry without a source is a rumour. The Runtime's provenance on every record (commitment 26) is the carrier; this module says which facts it must keep: the proposer and the accepter, the time, the source, the level, and an end where commitment 7 gives one. Spec: the fields are handed to the registry spec in §12. Proof: none yet. Today (v0.5.0). A rule carries no source: a string in a list. The provenance the Runtime keeps is on the registry's agent records (registered_by, registered_at, updated_at, the dev-mode mark and the delegation a write ran under; src/registry/agents.ts, AgentProvenance) and nowhere near a rule.

6. You can read it, correct it and remove it. The owner MUST be able to read memory as plain text, one fact to an entry, with an index short enough to read, and to correct and remove it. Removing an entry MUST stop the tool giving it to any agent from then on, and what was removed MUST stay out until the owner accepts it again: no agent can put it back, not even one with the right to accept. A removal reaches neither a conversation that already holds the entry nor what a lab kept (§4). Spec: the entry's form is §12's; no separate format. Proof: none yet. Today (v0.5.0). True of the rules, as text in a file the owner edits; a removed rule is gone from the next launch, and from the next reload of a message seat, whose rules file no longer matches the live text; an option seat keeps the text its launch option carried until it is relaunched for another reason; a running seat keeps the rules it was given. Nothing remembers that a rule was removed.

7. It forgets on purpose. An entry MAY be given an end (until); an entry that has not been true for a while MUST be offered for removal, never dropped on its own. A memory that only grows is, after a few months, a memory nobody trusts. Spec: until is a field of the entry (§12). Proof: none yet. Today (v0.5.0). Nothing is forgotten: a rule stays until someone removes it by hand.

C. Across agents and seats

8. It carries a team through a change of agent. When an agent leaves a seat, the facts of its work MUST go in the handover (Runtime commitment 13, not built); the habits and ways of working it was given MUST go in memory, so that the agent that arrives starts from the same habits and the owner does not say them twice. It is another agent all the same, with its own judgment. A seat keeps its registry id across its occupants (an owner decision), so the seat's own level is the one that follows the seat and not the agent: what the seat learned is given to its next occupant; what an occupant kept for itself in its lab's notes is not (commitment 1). Spec: the handover is the Runtime's; the seat's level is this module's. Proof: none yet. Today (v0.5.0). Nothing carries a team through a change of agent. A restart relaunches the seat without the old transcript and says so in its three facts (src/commands/restart.ts: "in a new workspace without passing the old transcript"); the new occupant gets the rules text and whatever a brief repeats. The seat's record keeps its id and its grants across the relaunch (Runtime commitment 2).

9. It respects what each agent may see. An entry about something private MUST NOT reach an agent allowed only on public material; a secret MUST NOT enter memory at all. The predicate, what a seat may see, is the Kernel's (read and its scope, §3; the seat's visibility); the filter at a start is this module's: an agent is given the entries its predicate admits and no others, and the index it sees is already filtered. Spec: the predicate is the Kernel's; the filtered delivery is Specs-launch §3. Proof: none yet. Today (v0.5.0). Every seat of a team is given the same rules, whatever it may see. The team file carries a visibility of public or private, defaulting from the identity's forbidden-public list (src/file/sections/visibility.ts), and the rules delivery does not read it.

10. Reading another agent's memory is a grant. A seat's own level MUST be written by that seat alone and read by others only under a read on it held by grant or by lease (§9, §10), deny by default, expiring and revocable, re-checked on every read, never widening commitment 9 (the reader gets the intersection of the grant and what it may see), every cross-read journaled in the store (Runtime commitment 26). The 2026-10-12 decision is re-laid under the Kernel: its "a grant by role, never by name" is the roles catalogue's role bundle (009); its "orchestrator reads its agents' memories, never the reverse" is a role's read on its own team's seat levels, roster membership at read time; its "spaces attached on demand, at most three" is the seat's own choice of what to load, bounded by a setting (commitment 12). The resolver is the Kernel's, one for every capability (question 2); Jev, where used, is advisory and never the decider (an owner decision). Spec: the grant record is the grants spec's; the journal is the Runtime's. Proof: none yet. Today (v0.5.0). Nothing of it exists in the tool. Each lab's own memory is read by that lab's own agents only; the grants the tool keeps are capability grants, send grants and create grants (Runtime commitment 26), none of them a read on anything of memory.

D. What is recorded of what is said

11. Conversation recording is a setting. Conversation recording MUST be a setting at a level: all (every conversation, the owner's with any agent and agent-to-agent traffic, no channel exempt), none, or a subset by channel or participant. A recorded conversation is not memory (commitment 4 holds: nothing enters without acceptance) and not a record of a decision (the Kernel: a yes said in conversation is not a record); it is a transcript, kept where the store keeps transcripts, read under commitment 10's grants, redacted of secrets before it is kept. It is off by default — none unless you set otherwise — and the rest is settled (an owner decision): a transcript lives in the project's state folder beside the message history, its retention is a setting (30 days by default), it is read under commitment 10's grants, and it is redacted of secrets before it is written. Spec: the history and the receipts are in Specs-messaging §3. Proof: none yet. Today (v0.5.0). Nothing records a conversation. The message history of team send is kept in the project's state folder, and team feed reads and follows it (src/send/history.ts); a shown message leaves a signed receipt beside its record (src/commands/messages.ts). The owner's own conversations are written as the owner says them into dated pages of the knowledge base, by hand (its schema's converse operation). No setting names any of it.

E. Settings

12. All of it is yours to set. Who may propose, who accepts, at which level, what an agent keeps between two tasks or starts without; the cross-read grants' defaults (the attach limit); the recording level — each MUST be a setting in the catalogue's form (the Kernel's Policies section): scope among entity, project, team and seat, inheriting downward, tightening only. The settings this module names: memory-accept (who accepts at a level: the owner, or a holder by grant), memory-at-start (everything allowed, or the entries tagged for the work in hand), memory-attach-limit (default three), memory-review-after (how long an entry goes unconfirmed before it is offered for removal), conversation-recording (none, all, or a list of channels and participants), conversation-retention (how long a transcript is kept, 30 days by default — an owner decision). Their rows go in the catalogue when the text is accepted. Spec: the settings' form is the policies spec's; the rows are handed over in §12. Proof: none yet. Today (v0.5.0). None exists. The settings chain and the policy object exist (commitment 3) with no memory word in either; the closed enforced vocabulary of 0.5.0 has eight names, none of memory (src/policy/types.ts, ENFORCED_POLICY_NAMES).

F. The entity's vault, and the shape of a task

13. Every entity has a vault. Each entity MUST have exactly one vault for its long-term knowledge: its raw sources, never edited; its curated pages, the project's and its decisions among them; an index; and a log of operations — the LLM-wiki pattern its knowledge base already follows. A vault is private to its entity: a public repository never links to it, and a grant on a vault names nothing outside that entity's vault. Floor's vault is its Docs repository for now; another entity's is its own, never Floor's. This module's entries are pages of the vault; commitment 1's line between how to work and what was decided still holds. (the owner's directions of 2026-10-18, an owner decision) Spec: the vault's schema, operations and storage are handed over in §12. Proof: none yet. Today (v0.5.0). Not built. TeamCLI has no vault command and no vault word in src; the knowledge base is a folder its agents edit directly, as commitment 1's Today says.

14. TeamCLI handles the vault. TeamCLI MUST manage the vault, not merely point at a folder: its schema is built in and overridable by the entity; its operations — ingest, record, query, lint, and the pages a task's start asks for — are commands of the team vault family, each logged and under a grant; its storage is an adapter, the same family as the registry's, so a vault may be a git repository, a folder, or later a service. A seat MUST reach the vault's pages through those commands, under the grant the command runs with; it is never given a direct write scope over them, so the index, the log and the lint stay true. (the owner's directions of 2026-10-18, an owner decision) Spec: the commands, the schema and the adapter are handed over in §12. Proof: none yet. Today (v0.5.0). Not built. The knowledge base's schema lives in its own CLAUDE.md, agents edit its pages directly, and no command ingests, records, queries or lints.

15. A conversation belongs to a task, and ends with a handover. A seat MUST start each task in a fresh conversation and resume only within that task; what carries across tasks MUST be the handover, the registry and the vault, never a growing transcript. The start of a task MUST be given only the vault pages relevant to it, chosen from the index, never the whole vault. At a task's end the seat MUST write a short handover — what was done, decided, left open, and where things are — and it goes to the registry as the task's record; what deserves to last is ingested into the vault by the entity's curator, under commitment 14's commands. Compaction SHOULD be a planned handover at a threshold — the seat asks for its handover, the conversation ends, and a fresh one starts from it — not the model's automatic summary mid-task. A lead's working state MUST live in a state record that survives its restart, not in its context. (the owner's directions of 2026-10-18; two owner decisions; Runtime commitments 13, 26) Spec: the handover's record is the Runtime's; the vault's operations are §12's. Proof: none yet. Today (v0.5.0). No. A seat's conversation is its CLI's session and lasts as long as the session; restart starts a new workspace without the old transcript (src/commands/restart.ts), the only boundary that exists, and no handover and no state record carry a task's facts forward.

16. Vault access goes by grant, by scope. Every read or write of a vault page MUST be under a grant: deny by default, owner-signed or leased under it, expiring and revocable, re-checked on every read, and logged with the scope it used. The grant MUST name one of the Kernel's capabilities — a read or a write (§3) — and a scope that is a path pattern within one entity's vault, never the whole vault by default; the source note's ingest and record are writes so scoped. Cross-memory reads (commitment 10) ride the same grants, and the reader gets the intersection of the grant and what it may see (commitment 9). (the owner's directions of 2026-10-18, an owner decision; Kernel §3, §7, §9, §10) Spec: the grant record is the grants spec's; the vault scope is handed over in §12. Proof: none yet. Today (v0.5.0). No. The grants the tool keeps are capability grants, send grants and create grants; no vault exists and no read or write of a page is logged.

G. The project's own knowledge folder

17. A changing default is observed, never enforced. A default knowledge folder appearing or disappearing MUST be observed, not enforced: it MUST NOT gate a launch or an owner command; the first resolving command MUST write it once to the project's log; status and doctor MUST show it only while the fresh resolution differs from the historical signed observation (a retained legacy record; team approve was removed at v0.5.0, and current authority is the grant/create flow, an owner decision); a create–launch–delete round trip MUST clear it without a new approval or other authorization; and the log line MUST NOT authorize anything. Only the fixed default is observed — <root>/.agents/docs/, never another folder, where <root> is the project root — and knowledge: false MUST turn it off. (the projects-and-knowledge spec §5 rule 13; the archived project-folder decision of 2026-10-05; the coverage audit's one 0009 row with no destination) Spec: the resolution's formats, its historical approval observation and its lines are the projects-and-knowledge spec's §3 and §5; the folder itself is the knowledge base commitment 1's Today names. Proof: none at the tag. Today (v0.5.0). Not built. The team file has no knowledge section (src/file/sections/index.ts), so no default is resolved and no change is observed.

3. Why

• A day forgotten at noon. The coordinating agent of our own teams lost its thread to a long conversation and spent an afternoon proposing as new what had been decided the day before. Everything had been written down; nothing made it read. The current-state page of the practice (commitment 1) is the by-hand answer; the module makes the reading the launch's.
• A habit lost at a restart. A coordinator was closed without warning and came back doing its operator's work itself; "you brief, your operator runs" lived in the session that was gone. The seat's own level (commitment 8) is where that line would have waited for the next occupant.
• The same correction, three times, to three agents of three labs in one day (RFC 003 §3). One accepted entry at the team level, given to every seat at its start, is the whole of the fix.
• A caution that outlived its reason, obeyed for weeks: commitment 5's source and commitment 7's end are what would have retired it.

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

• Memory is an input like any other. A wrong entry, or one written under the influence of something an agent read, is read again by every later agent. Accepting entries one by one is the protection, and it holds against a mistake, not against an attempt (Kernel §12: memory can mislead a later session).
• Someone has to accept. That is work, and it is the owner's unless the owner gave the right by grant. A team that proposes ten entries a day and has nobody to read them has no memory, only a queue.
• It is not understanding. An agent given forty entries has read them; it does not follow that it acts on the thirtieth an hour later. Memory lowers how often the owner repeats himself; it does not bring that to zero.
• It costs room. Everything given at a start takes from what the agent can hold of the work; a memory has to stay small to be read at all, and memory-at-start is the knob.
• "Yours" has a limit. What an agent is given, it sends to its lab like anything else it reads. The record is with the projects and the owner decides who is given it; a lab keeps what its agents were shown, and a removal does not reach there.
• It is one more thing kept about the projects, on the machine, readable by the agents the owner allows and, until agents are contained (Kernel §11), by any agent with a shell.
• Labs' own memories remain. An agent's program keeps notes of its own; the tool does not read them and cannot make them agree with the team's (question 6).

What this release must not pretend (0.5.0)

• Rules are not memory. They are one list, the owner's, with no source, no level, no end and no acceptance step: the beginning of a memory, without the learning. A text that calls them memory overstates every row of §6.
• A seat's standing rules do not follow an edit of the file alone. A running seat keeps the text it was given; the new text reaches it when reload relaunches it, and reload is a stop and a start.
• Editing the file is writing the rules. up launches from the live file, a changed or never-approved file included; nothing approves a rule, and the difference is a check line, not a refusal.
• The lab's notes are not the team's. What a Claude seat reads from its own instruction files at start (CLAUDE.md and the rest the profile lists under startup_reads) is read by the CLI, not given by the tool, and differs by lab: two seats of two labs on one project start from different notes.
• Nothing is journaled. No read of anything by anyone is recorded beyond the message receipts; a cross-read journal (commitment 10) does not exist because cross-reads do not.
• Nothing is redacted. A secret typed into a message is in the history line; the history is readable by the same user and that is the whole protection.

5. What would change our mind

• Agents that act no differently with a memory than without one: then the cost is paid for nothing and the answer is in how agents are briefed, not in what is stored.
• A team steered wrong by an accepted entry with every commitment kept: then one acceptance is not enough and what enters memory needs the kind of review code gets (005).
• Labs agreeing on a memory agents of different companies can share: then TeamCLI uses it and keeps only what it adds, who accepted, the levels, what each may see.
• People who never open it: then "the owner can read it and correct it" protects nobody and the memory must come to them, what was added this week, in three lines, in the daily report (010 commitment 18).

6. What is true today

"Today" is the tag v0.5.0 of floor/teamcli (52db9b75), read clause by clause by the current text.

#	Commitment	Today
1	What a team learns belongs to you	No. TeamCLI keeps no memory; the owner's rules, the knowledge base, a current-state page and the labs' notes stand in
2	Every agent reads the same memory	In part, for the rules: one text per seat, the same for every CLI, as an option, a first message or a prepended line
3	Levels	No. Rules are per team; the levels exist for three liveness thresholds and the policy object; nothing is pinned or loaded before a summary
4	Nothing enters without someone accepting	In part, for the rules only: an owner section of the team file, which up reads live with nothing approving it
5	An entry says where it comes from	No. A rule is a string; the registry's provenance is on agent records
6	You can read, correct and remove	In part, for the rules: text in a file; a running seat keeps its text until relaunched
7	It forgets on purpose	No
8	It carries a team through a change of agent	No. A restart passes no transcript and says so; the seat keeps its id and grants
9	It respects what each agent may see	No. The same rules to every seat; visibility is in the file and unread by the delivery
10	Reading another agent's memory is a grant	No. Nothing of it exists
11	Conversation recording is a setting	No. The message history and the receipts are kept; no conversation is, and no setting names it
12	The settings	No
13	Every entity has a vault	No. No vault command and no vault word in src; the knowledge base is edited directly
14	TeamCLI handles the vault	No. Its schema is a CLAUDE.md; agents edit pages by hand; no command ingests, records, queries or lints
15	A conversation belongs to a task, and ends with a handover	No. A conversation is the CLI's session; restart passes no transcript, but no task boundary, handover or state record exists
16	Vault access goes by grant, by scope	No. Only capability, send and create grants exist; no vault and no read journal
17	A changing default is observed, never enforced	No. The team file has no knowledge section; no default is resolved and no change is observed

Three hold in part, fourteen not at all. RFC 003's own table of 2026-10-06, at 0.3.1, said the same of its nine; what 0.5.0 added is the rules' delivery (the file, the hash, reload), not memory.

7. The security boundary

• The memory is a reserved object at its level (commitment 4). No write scope opens it; it changes through the acceptance, a Kernel transition, and the gate ignores an entry's text (Kernel §13): an entry is never a review, a gate or a lease record, whatever it says.
• An entry is talk, not instruction. It is given to an agent as material the owner accepted, and the rule of 002 §3 stands: nothing in it is an instruction from someone who may not instruct. The attack an accepted entry carries is the one §4 names, and acceptance is the whole defence until entries get the review code gets (§5).
• A cross-read widens nothing (commitment 10): the reader sees the intersection of the grant and its own predicate; the journal says who read what, when, under which grant and generation, so a leak has an author.
• A vault is private, and its accesses are grants (commitments 13, 16): a vault belongs to one entity, every read or write of its pages is logged with the grant's scope, and no public text links to it. Until the vault exists, the knowledge base is a folder any seat reads directly; §4's same-user limit stands.
• A secret never enters memory (commitment 9), and a transcript is redacted before it is kept (commitment 11). Today neither holds: the history line keeps what was typed.
• The same-user limit. Every seat runs as the same OS user (Kernel §11); the rules file, the state folder and the history are on the disk every seat reads. A seat that edits another's rules file is caught by the hash the launch line carries and by team check, not prevented.

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

A Tier 3 module under the Kernel and the Runtime, registering no capability (Kernel §13). It leaves to the Kernel the right to accept and the right to read, vault scopes included (§3, §7, §9, §10), and the resolver; to the Runtime the store, the provenance's carrier, the handover and the vault's storage adapter (Runtime commitments 13, 26; the adapter family of an owner decision); to 002 how an agent is told that memory changed while it was working, and the receipts; to 008 what is being done; to the knowledge base what was decided; to 009 the role bundle a cross-read grant rides in; to 010 the report that shows the week's entries. The labs' own notes remain theirs.

9. Prior art and alternatives

None argued in this text. The choices the current text leaves open are in §10, with the draft's proposed answers.

10. Open questions

1. The right to accept, in the Kernel's words. This draft says: the memory at a level is a reserved object and accepting is the write to it that the owner or a grant holder makes (commitment 4). The other reading, agree on a hashed entry, would make every acceptance an agreement record. Say which; the draft's reading keeps acceptances cheap and the ledger for authority.
2. The decided resolver of 2026-10-12 and the Kernel's. The decision names a total order (location, then role; deny beats allow at equal rank) and a six-field tuple. The Kernel has one resolver for every capability, with grants and leases carrying generation and expiry (§9, §10, §15). The draft maps the tuple onto a read grant on a seat's level (commitment 10) and keeps no second resolver; the decision's "site" is the entity or the project. Confirm, or name what the Kernel's resolver lacks.
3. What is memory and what is not. How to work, not what was decided nor what is being done (commitment 1). The current-state page of the practice holds both the rulings in force and the work in flight: under this draft the first half is memory at the team level and the second belongs to the plan. Is that a line people can hold?
4. Settled by an owner decision: the reading is confirmed — the first assistant's private memory is the seat's own level, pinned and loaded before any summary; the shared memory is the entity's; the owner's memory is the grants and the decision log.
5. Settled by an owner decision: the default is none; transcripts live in the project's state folder beside the message history; their retention is a setting, 30 days by default; reads are under commitment 10's grants, and secrets are redacted before the write.
6. For the build: a lab's own notes — the tool knows which files each CLI reads at start (startup_reads on the profile). May the seat's own level be written into one of them by the launch, so the lab's program reads the team's memory the way it reads its own notes? That would make commitment 2 true for such a seat through its own instruction file, without a second channel; it would also write into a folder the lab owns.
7. RFC 003's open points 2 to 8: who accepts when nobody leads (the draft: the owner, always, until a grant says otherwise); whether accepting at the widest level needs two (the draft: no, one acceptance and the daily report); how much at a start (memory-at-start); forgetting by age, use or decision (the draft: offered by age, dropped by decision only); an agent's own level (the seat's, and not a loophole because it is given to nobody else without a grant); a public-only lab beside private-knowing agents (it misses the private entries and the team works with that); a project's end (its memory stays with the project; the entity level is what follows the owner).
8. The vault's open points. How the relevant pages are chosen without reading the whole vault (the draft: from the index and the pages the task names); who curates an entity with no archivist (the draft: the role the owner names); the planned-compaction threshold, one value or per CLI (the draft: per CLI, commitment 15); where a vault lives when it is not a git repository (the draft: the storage adapter family, an owner decision); whether an agent's private memory stays outside the entity's vault (the draft: it is the seat's own level, read under grants, commitments 3, 10). The source note's list is linked in §12.

12. Links to the spec

• Specs-launch §3 — the rules text's build and its carriers by CLI.
• Specs-messaging §3 — the message history and the receipts.
• The owner's directions of 2026-10-18, folded here as commitments 13–16: the vault's schema and operations, task-scoped context and handovers, and the vault grant's scope.
• Specs-projects-and-knowledge — the project root, the team file's knowledge section, and the default folder's automatic observation, its historical approval record and its output (commitment 17); current authority over knowledge is the grant/create flow (an owner decision).

For Specs-launch §3: the rules text's build (rulesOf): the four lines the tool itself depends on (the signature, "never stop at a question", never grant, delegate, revoke or edit trust:, never switch or reset a protected checkout); the lines the seat's CLI profile carries for every seat of that CLI; the file's rules in order; the seat's two signature lines; the workspace's lines. The carriers by profile (rulesMode): a launch option for Claude Code (--append-system-prompt) and Grok (--rules); a first typed message for Antigravity, Codex, Cursor, Gemini and Muse; a line prepended to every brief for Jules, which keeps no standing session. The message form's file is rules/<seat>.md in the project's state folder, named by a typed line carrying the file's path and the first twelve hex digits of its SHA-256, read back before Enter. reload's comparison of recorded model, version and effort, and of a message seat's rules file against the live text; remove deletes a temporary seat's file only.

For Specs-messaging §3: the history line, its mode and rotation, and the signed receipts beside their record.

For Specs-projects-and-knowledge: the default knowledge folder's observation and its lines — the log line, the status and doctor output and the historical approval preview — with commitment 17's no-gating rule; current authority is the grant/create flow (an owner decision), not a revived approval; the folder itself is the knowledge base rules 1 and 13–14 name.

For the grants spec: the vault scope: a path pattern within one entity's vault, with the effect one of the Kernel's capabilities (read or write); commitment 16 reads the source note's ingest and record as the latter.

For the Runtime's storage adapters (an owner decision): the vault's storage as an adapter of the same family, a git repository by default; its schema and operations are the source note's.

For Specs-registry §3.6 (planned): the memory entry's provenance fields, with the source, acceptance and removal semantics commitments 4–7 give them.

For policies (the catalogue): the six memory settings' rows — memory-accept, memory-at-start, memory-attach-limit, memory-review-after, conversation-recording, conversation-retention.

For Specs-registries-policy-names: the six settings' planned rows (memory-accept, memory-at-start, memory-attach-limit, memory-review-after, conversation-recording, conversation-retention); the catalogue rows stay planned until the text is accepted (commitment 12).

This text contributes no other registry entries.