History RFC 005 Quality

RFC 005: Quality

What makes work done, who says so, and what a check is worth.

Authors: the project's founder, with Claude (Opus 5.5)

Accepted 2026-10-07 by TeamCLI's board. Three reviewers from three labs (Grok, GPT, Gemini) stood behind this text unanimously, and both members of the board voted for it: the founder, and an AI agent. The founder first lent his vote to the other member, which had drafted the text; the reviewers of RFC 006 then said a vote should not be lent to whoever wrote the thing decided, and the founder gave his own vote the same day. It is not yet published.

Renumbered 2026-10-07. After acceptance, Consensus was added as 006 and Harness became 007. Only the number of the Harness RFC changed in this text; no commitment changed.

Draft 4, 2026-10-07, after round 2. Three reviewers from three labs read draft 3; two stood behind it and one did not, for one point. The board's decisions are applied here. Built from his direction of 2026-10-07 ("Quality should have its own RFC, and the review policy will be there") and of 2026-10-06 ("what makes the things very slow is the fact that we review each line of code. why don't review afterward?"), and from one night in which three kinds of check each found what the others had passed.

1. The question

A team of agents produces work faster than a person can read it. What has to be true before that work counts as done, who is allowed to say so, and how much is a "yes" worth?

Where we start from

An agent says its work is done. It usually believes it. It is also the one least able to see what it missed.

A check is an agent too. It reads, it runs, it says yes or no. It can be wrong the same way the first one was, and when both come from one lab they are often wrong together.

Checking everything is slow, and checking nothing is fast until it is not. We did both in one week: a release that waited fifty minutes for a third reading of a small change, and a fault in the most basic act of the tool that had been read five times and passed.

2. What we propose

Nine commitments to the person whose team it is. A commitment is what we bind ourselves to build and to keep. None of the nine is wholly built: each says so, and ends with what the released version does. Section 7 gives the same row by row.

What done means

1. Done has a definition, and it is yours. We are building towards this: for each project, what must be true before a piece of work counts as done: which checks, by whom, with what result. The items and their states are the harness's (RFC 007); this text says what an item must meet to be shown as checked and as done, and an item that has not met it is not shown so, whoever says it is. Today: a team's rules say in words what its agents should do before calling work finished, and nothing applies them.

2. Nobody's work is done on their own word. We are building towards this: the agent that did a piece of work is never the one that says it passed. Where you have agents from more than one lab, the check comes from another lab than the work, because a lab can be blind to its own kind of mistake. Where you have one lab, the check is by another agent and TeamCLI says that the check and the work share a lab. Where you have one agent, the work waits for you. Today: this is a rule we give our own teams in words.

The review policy

3. A check comes before or after, by what is at stake. We are building towards this. Work that gives a power, or that cannot be taken back once it is out, is checked before it lands. Other work may land when its automatic checks pass and be read afterwards, with what is found then held like any other finding. Always before, whatever is set: what RFC 001 names as a grant, an agreement or the creating of a team; what is published, deployed, deleted, spent, sent outside or written where others will read; what a person will run by hand; and any change to this policy itself. Beyond that list, where the line sits is yours to set, for everything you do or for one project. Work whose kind TeamCLI cannot tell is treated as the first kind. Moving the line is an act of whoever holds the right to set it, recorded with who and when, and it does not change how work already open is treated. Today: nothing in TeamCLI knows what kind of work a change is.

4. Trying it for real is a check of its own. We are building towards this: beside the reading and the automatic tests, a run of the real thing in a place made for it, and for work that changes what a person does by hand, a run of exactly that. No number of readings stands in for it, and a project says which of its work needs it. Today: one command checks a team's own setup before starting; nothing runs a team's work for real.

What a check is worth

5. A check says what it looked at. We are building towards this: every "yes" and every "no" names the exact state of the work it read, what it ran and with what, and what it did not cover. A yes on yesterday's state is not a yes on today's, and TeamCLI does not count it as one. Today: one command checks that commits, and the request to merge them, carry a seat's signature (the line saying which place in the team they come from, not which agent sat there) and no forbidden pattern; it reads what is there when it is run and records nothing.

6. What a check finds is held until it is closed. We are building towards this: a finding that blocks keeps the work from being done until it is closed, and it is closed only by you, by the one who found it, or by an agent of another lab than the work came from; never by the lab the work came from. Closing names the state it was closed on, and the finding opens again when that state changes. A finding is not lost in a conversation. Work that had already landed when a finding was raised is shown as not done from then on; taking it back is a decision of whoever may, never something TeamCLI does by itself (RFC 007). Today: findings live in the files and messages agents leave.

7. Accepting is a right. We are building towards this: saying that work is good enough to ship is an act on an agent's list (RFC 001), by default yours. An agent may check without being able to accept, and accept only where you said so. Accepting work with a blocking finding still open is another right, never part of the first: by default yours alone, an agent's only where you wrote it by name, and recorded each time with the finding it passed over. Until agents are contained, a missing check keeps TeamCLI from calling work done; it does not keep an agent that holds the keys from landing it (section 4). Today: who may merge or publish is decided by the accounts and keys an agent can reach, not by TeamCLI.

8. You see what checking costs, and what it found. We are building towards this: for each kind of check, how long it held work back, what it used of what you pay for, and what it found that the others did not. This text says what is to be known; measuring it, with its source and its time, is RFC 004's. So that the policy in commitment 3 is chosen on facts: a check that never finds anything is a cost, and a check that is skipped is a risk, and both should be visible. Today: nothing is counted.

9. All of it is yours to set, by project. We are building towards this: the definition of done, which labs check which, where the line of commitment 3 sits, which work needs a real run, who may accept, how many must agree. A setting for everything you do holds for each project until the project says otherwise; a project may always be stricter. The default when you set nothing is the careful one: checked before it lands, by another agent, from another lab where you have one. Today: none of these settings exists.

Three things are to hold whatever the settings say, and none is built: the agent that did the work never passes it; the lab the work came from never closes a finding against it; and the list of commitment 3 is checked before it lands.

3. Why

• Five readings and one. A fault in how the tool stops an agent (a key pressed without looking again at what would receive it) was read five times by one lab's agent and passed. An agent from a second lab found it on its first reading, with two ways to trigger it.
• Three rounds and one run. The same night, a real run on a small team made for the purpose found two more faults that three rounds of reading and several thousand tests had passed: one that let a team be started once and never again, and one in the very case the release existed to fix. The tests had been written from a question the program does not ask in that form.
• A yes on a state that was about to change. A third lab's agent read the release and said yes. It was right about what it read. The release then changed three times, and its yes named the state it had read: that is the only reason nobody mistook it for a yes on the release.
• Fifty minutes for a small change. A day earlier, a finished and small change waited fifty minutes for a third reading, then two hours for an agent that was busy. The founder asked why everything is read before, and why not after. For most work he was right.
• Work passed by its author. In our first week agents reported their own work as verified. Some of it was. We could not tell which.

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

These are the costs of what we are building, not of anything released.

• A check can let work pass. An agent asked to review, and counted on how fast work lands, has a reason to say yes. A second lab lowers that; it does not remove it.
• Two labs can share a blind spot. They read the same text and can make the same assumption. The real run exists for that, and it only finds what it was set up to try.
• Checking after means living with what was not found before. Work that landed and is found faulty a day later has already been built upon. The line of commitment 3 is a bet, and the text commits to showing how it turns out, not to its being right.
• It costs. Every check uses what you pay a lab for and holds work back. A careful default is a slow one.
• It is not taste. A check can say that work does what was asked and breaks nothing it was shown. Whether it is the right work, or good, is yours to say.
• Not a wall yet. An agent with the keys can still merge or publish without any check. Until agents are contained (RFC 001), TeamCLI can refuse to call that work done; it cannot prevent it.

5. What would change our mind

• Work read afterwards that is found faulty as often as work never read. Then reading after is ceremony, and the line belongs elsewhere.
• Second labs that find nothing the first did not, over months. Then commitment 2's preference for another lab is cost without return.
• Teams that set every line to "after" within a week. Then the default is wrong, or the cost of checking before is higher than we think.
• Projects whose own tools already hold all of this (what must pass, who may accept). Then TeamCLI should read theirs and keep only what it adds: the same rule for every lab, and which agent checked which.

6. Open, for reviewers

1. Where is the line? "Gives a power, or cannot be taken back" is ours. What else must always be checked before: what a person will run by hand; what touches money; what is sent outside?
2. Who closes a finding? Its finder; another agent; whoever leads? What if the finder is gone?
3. Accepting with a finding open. Should that ever be an agent's to do?
4. How many must agree? One other lab; two for some work? Is "unanimous" a rule or a habit?
5. A real run of what? How does a project say what "the real thing" is, when the real thing is a person at a terminal?
6. One lab only. What is a check worth when the work and the check share a lab, and what should TeamCLI say about it beyond that they do?
7. A check of the check. When a check that said yes is shown wrong, what follows for that agent's next yes?
8. When the author and the checker do not agree, and neither yields: whoever is above; you; a third lab?

7. What is true today

"Today" is TeamCLI 0.3.1. Each row restates what one agent checked against the released code on 2026-10-07, clause by clause; eight rows held and row 5 was corrected.

#	Commitment	Today
1	Done has a definition, and it is yours	No. A team's rules say it in words; nothing applies them
2	Nobody's work is done on their own word	No. A rule given to agents in words
3	A check before or after, by what is at stake	No. Nothing knows what kind of work a change is
4	Trying it for real	No. One command checks a team's own setup before starting; nothing runs a team's work
5	A check says what it looked at	In part. One command checks that commits, and the request to merge them, carry a seat's signature (which place in the team they come from) and no forbidden pattern, on what is there when it is run; it records nothing
6	What a check finds is held until closed	No. Findings live in files and messages
7	Accepting is a right	No. Who may merge or publish is decided by the accounts and keys an agent can reach
8	What checking costs and what it found	No. Nothing is counted
9	Yours to set, by project	No

One of nine is partly true. Quality today is our own practice, written in the rules we give our teams and in the tasks we hand them; the tool holds almost none of it.

What this RFC leaves to others

Who may accept, and what counts as a power: RFC 001. How a finding reaches the one who must act: RFC 002. Whether a lesson from a fault becomes something a team remembers: RFC 003. What is measured about checks and agents, and how: RFC 004. The items of work and the state "checked": RFC 007. Which tools run the checks: internal design records.