History RFC 008 Planning

RFC 008: Planning

A team reads its own backlog, plans it, and runs it.

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

Accepted 2026-10-08 by TeamCLI's board (founder's vote). Four reviewers from four labs — GPT Sol 6, Kimi, Gemini, Grok, none the author's lab — stood behind this text unanimously after six rounds. The review record (every round's verdicts and freeze) is kept with the project. The internal design (the tasks schema, team next, the broker, the lease, per-request broker authorization, the per-field policy) follows now that it is accepted.

1. The promise

A team plans and runs its own work — what (a backlog, from a tracker), in what order (priority, dependencies), when (cadence, deadlines). Authority to take backlog work rests on an owner-set intake rule, not on the tracker fields themselves: the owner (or a right-holder) agrees, once, which items are eligible, within what limits (which repos, which kinds of change, what a seat may not do unasked), and what escalates instead of being taken. That standing rule — a rule already set, in the Foundation's sense — is the agreement; an item inside it is agreed work a seat may pull, and an item outside it is escalated, not taken. Within the rule, a person or an orchestrating agent still sets direction, priority and assignment; the team then pulls, plans, carries out and reports without being handed each task. Acceptance stays where the Foundation puts it: whoever holds the right accepts, returns or drops the result — the team does not accept its own work.

2. Why — the gap this closes

A team cannot see or plan its backlog today. Work reaches a seat only when a human or an external orchestrator pushes it into the seat's terminal — fragile, serial (the orchestrator is the bottleneck), and never autonomous: remove the human and it stops. Proven live 2026-10-08: a team ran a full engineering loop on its own but could not read or record the tracker item.

3. What it promises

1. A team declares a task source in its team file.
2. Seats pull their next task — they are not pushed.
3. The team records progress within the access it is granted; final acceptance remains a human's or a named delegate's, per the Foundation.
4. The team plans order and timing itself.
5. Priority, assignment and acceptance stay human (or a named delegate's).
6. It is never coupled to one tracker — one generic model, an adapter per source.

4. The shape

• tasks: in the team file — source (an adapter name), where it reads, the pull policy, cadence.
• team next [--mine] / team plan / team issues — a seat pulls its next task.
• The generic task record — a typed set of fields: { id, title, priority, assignee, milestone, deadline, blocked-by, repos, needs }, plus an optional description. Only id and title are required; the rest are optional, and a source that lacks one simply omits it — a task with no priority orders after the prioritised ones (or by the team's declared fallback), no milestone/deadline means none, an absent blocked-by means no known block. Planning never invents a missing field. One task source per team is the initial scope; several sources is deferred (§8).
• repos and needs are checked against the agreed scope before a seat acts. repos names the repositories a task touches, and a task naming a repo outside the team's agreed repositories is escalated, not worked; needs names the skills it requires (RFC 009), and a need the assigned seat is not agreed to receive is likewise escalated. Metadata never grants scope the agreement did not.
• A task that spans repositories carries them in repos; its work is coordinated changes, one per repo, each accepted on its own (RFC 000's multi-repo rule). The task is complete when every one of its changes is accepted; there is no single cross-repo accept.
• Claiming — a seat claims an item with a lease before working it, and may self-claim only under the pull rule the team file sets, never freely and never an item assigned to another seat unless the pull rule says so; two seats cannot hold the same live lease. The honest limit: if a lease expires while its seat is still working (a crash, a hang), the item returns to the queue and another seat may pick it up — so an expired lease can cause duplicated or retried work, which the internal design must make safe (atomic renewal, idempotent record); the public promise is only that two live leases never overlap. A missed deadline is surfaced, not silently dropped.
• The loop — on idle → plan → team next → work → record → plan.
• Time — cadence, back-off, deadlines, quiet hours.

5. The boundary that makes it safe — what is guaranteed, and what is not

A vendor seat must not hold the tracker's credential. The enforceable guarantee is exactly that, and no more:

• Credential-withholding. The credential lives with a broker process that holds it and answers over a local socket; a seat never reads it, and the broker never puts its own credential or the tracker's API access into any field it returns. team next asks the broker, which authenticates the request. This guarantee is precisely about what the broker injects — it says nothing about what a user typed into a field (see below).
• The honest scope of it (round 3 was right to press this): the broker does not make the task content secret-safe. A title or a description is free text the user wrote, and the seat is meant to see its task to do the work — so whatever a person put in those fields reaches the seat's lab, exactly as it would for any human teammate. TeamCLI does not promise to scrub a secret a user typed into a title; its promise is the narrower, honest one — the broker never injects the tracker's own credential or API access into any field (the broker-injection guarantee above). What a user put in a field is outside that promise.
• The policy that governs the fields is per-field allow / transform / omit, declared by the team: which fields a seat receives, which are transformed (e.g. an id without its source URL), which are omitted. The strongest posture is a minimal typed set with no description — then the only free text that crosses is the title, which a task needs to be workable at all. Zero free-text disclosure would mean omitting the title too — but then the seat has no prose to work from, so zero-text mode cannot support autonomous work on an ordinary prose task unless the broker supplies a separate, approved non-prose work specification. An opaque id the seat later resolves is not an escape: if resolving it returns the title, the disclosure still happens — the id changes when the title is seen, not whether. description, when allowed, is built by the adapter at the source (so a source URL is dropped at read, where the structure is known), not scrubbed from an arbitrary string afterward.
• The isolation limit (named, per the Foundation): if the broker runs under the same OS principal as the seat, a hostile seat can still reach it; true isolation needs a separate principal or sandbox. Same-principal is integrity, not authenticity.

6. What stays human

• Direction; priority and assignment — which select among the items the intake rule (§1) already made eligible, not a standalone agreement; acceptance — the result is accepted, returned or dropped by whoever holds the right. A seat marking its item "done" is a report; closing the source item needs an explicit owner rule or delegation.

7. Where it sits among the RFCs

• Harness (007) runs the loop, the broker and the lease. Analysis (004) judges the worth and quality of work (not its priority — priority is human). Communication (002): asking the coordinator is the in-team form; the tracker is the out-of-team backlog. Security (001): the broker and its stated limit are a security boundary. None is assumed built.

8. What is still open (refinements, not gaps in the promise)

1. Several task sources per team (deferred; one source is the initial scope, §4).
2. The self-claim rule's exact shape; the lease's stale/failure behaviour (an internal-design detail).
3. Whether the team may write comments back, or only move its own item's state.
4. Canonical lifecycle states and each adapter's mapping; per-field transform definitions.
5. Empty-backlog behaviour — idle-poll vs stand down.

Costs and what it does not cover

• A source needs an adapter; an unsupported tracker is reachable only through the file adapter.
• The broker is a running process; its isolation is only as strong as §5 states, and it does not protect the task content a user chose to put in a field.
• Planning orders and runs what it is given; it does not judge whether a task is worth doing.

What would change our mind

• If even a minimal typed record leaks source references in practice, the field set shrinks further and description is dropped by default.
• If same-principal isolation proves too weak for the teams that need this, a separate principal becomes required, not optional.

What is true today

Nothing of this is built. There is no tasks source, no team next, no broker. The 2026-10-08 run is evidence of the gap, not of the feature.

Review

Public RFC: at least three reviewers from three different labs, none of them the author's lab (Foundation Part 3), in rounds until all stand behind it, then the board votes. Rounds 1–6 (2026-10-08), accepted: GPT Sol 6, Kimi, Gemini, Grok. The internal design (the tasks schema, team next, the broker, the lease, per-request broker authorization, the per-field policy) follows on acceptance.