010 Workflow

010 Workflow

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

Discussed with the owner on 2026-10-12 and 2026-10-17. This module defines no gate (Kernel §13): it uses the Kernel's authority and the Runtime's item lifecycle, and only selects among settings. Where a rule below gates, it is written as a policy in the catalogue form of the Kernel's Policies section, and the refusal is the Kernel's, not this module's.

1. The question

When the owner wants something done, who takes it, who does it, who checks it, and how does the owner learn it is finished, without telling each seat himself? And, since 2026-10-17: how does a team's building day run as a round that starts, integrates, watches itself, closes and reports, so that the owner is needed only for decisions?

2. What we propose

1. A task enters through a team's orchestrator. The owner, or an operator acting for him (for example his first assistant), MUST give the task to the orchestrator of the team that owns the project. The orchestrator MAY also take a task from the tracker itself. Spec: none yet. Proof: none. Today (v0.5.0). Practice: the Runtime's dispatch (team next) exists (contract/cli.json), and no chain-of-command section exists in the team configuration.
2. The tracker shows it started, before anyone builds. First, the item MUST be moved to In Progress in the team's tracker: by the orchestrator itself if it has read and write access to the tracker, otherwise by the operator at the orchestrator's request. Only then does the orchestrator delegate. This keeps the tracker in near real-time step with the work, so progress is visible there without opening each builder's pane. The module is tool-neutral; Linear is today's example. Spec: none yet. Proof: none. Today (v0.5.0). Practice: agents have no tracker accounts of their own, so orchestrators and operators update the tracker through the owner's connector.
3. The orchestrator staffs, it does not build. Once the item is In Progress, the orchestrator MUST pick a builder from its own team, paired with a tester, and assign the task. It never does the work itself and never staffs from another team. [Earlier proposal, owner pending:] "… and never staffs from another project. Within a project, a team lead may borrow a seat from a sister team when the project's setting borrow-seat allows it (default: off), with the sister team's lead told." [Earlier proposal, owner pending:] "The tester or reviewer of a piece of work is from a lab other than its author's, by default. A lab is the company behind the model, not the tool: two products of one company count as one lab. A project or team may require more (two labs), never less, without the owner." [Earlier proposal, owner pending:] "Builders push their branches and open pull requests freely" holds only under pr-per-change (§2b); under local-fast builders commit locally and the integrator merges locally. Merging to the trunk and publishing a release stay with the owner (owner decision, 2026-10-12). Spec: none yet. Proof: none. Today (v0.5.0). Practice, each team's written rules; the borrow, lab and push proposals are pending with the owner.
4. One holder, written down. Right after the assignment, a tracker comment MUST record who holds the task (builder and tester) and the ETA. The orchestrator writes it if it has tracker access; otherwise it asks the operator, since agents usually have no tracker accounts. One holder per item, as in the Runtime lifecycle. Since an earlier revision, "right after the assignment" means right after the seat's acknowledgement (commitment 13). Spec: none yet. Proof: none. Today (v0.5.0). Practice: the holder comment is written by hand.
5. An estimate in minutes. The builder MUST give an ETA in minutes when it accepts, recorded in the holder comment (commitment 4); a missed ETA is reported, not hidden. Spec: none yet. Proof: none. Today (v0.5.0). Practice: the ETA is given by hand.
6. Reports flow up the same path. Builder to orchestrator, orchestrator to operator, operator to owner. Each level MUST tell only the next. [Earlier proposal, owner pending:] "A blocker is the exception: a seat that is blocked tells, at once, whoever can unblock it (a seat, a lead, the entity orchestrator or the owner), and copies the levels in between. Ordinary reports keep the path." This matches the notifications draft (002, an event kind may skip intermediaries). Spec: none yet. Proof: none. Today (v0.5.0). Practice; the blocker exception is pending with the owner.
7. Closing leaves a trace. When the work is done and tested, the orchestrator (if it has tracker access) or the operator MUST close the item with a summary comment: what was done, by whom, where the result is. Spec: none yet. Proof: none. Today (v0.5.0). Practice: the item is closed by hand with its summary comment.
8. A chain-of-command schema decides the workflows. Each entity, team and project MUST declare who may hand work to whom and who reports to whom. A project inherits from its team, a team from its entity, and each may override. A handover or report outside the declared chain is not refused (a module adds no refusal, Kernel §13); it goes through and is shown to the owner, who decides. Spec: none yet. Proof: none. Today (v0.5.0). Not built: no chain-of-command section exists in the team configuration at v0.5.0.
9. The workflow is the owner's setting, not a rule. The owner MAY edit it at any time: shorten the path, lengthen it, or let a kind of event skip a level, as 002's notifications draft §3 already allows for the reporting path. The schema lives in the team's configuration; this document does not name the file. Spec: none yet. Proof: none. Today (v0.5.0). Practice; the schema's file is unnamed here and none exists at v0.5.0.
10. The chief architect sits outside the chain. On the Floor team the chief architect conceives with the owner, but MUST sit outside the path tasks or reports follow and does not relay to teams. The owner, or his first assistant, speaks to each team's orchestrator directly. [Earlier proposal, owner pending; it describes the chief architect's role, so it is the owner's call. Proposed replacement:]

    10. The chain runs owner → entity orchestrator → project lead → team lead → seats. The entity orchestrator holds the picture across the entity's projects, sets priorities and brings the owner what needs him. A project lead coordinates its project's team leads. A team lead staffs and runs its team. The architect sits outside the chain: it conceives with the owner and is consulted, but tasks and reports do not pass through it. The owner may speak to any level directly; a level he skips is copied. Where an entity, project or team has one level fewer (a project with one team), that level is simply absent. Spec: none yet. Proof: none. Today (v0.5.0). Practice; the replacement is pending with the owner.

2b. Development mode (owner decision, 2026-10-16: the default from now on)

The owner, 2026-10-16: "Why do we even push, we are in a dev local env? … no review, no push. we will push when the work is done. we can merge locally." Then: "remember this as very important and the default mode as now. This will be defined by project, team."

How building work moves from a builder to the trunk is a setting, declared per entity, project and team, inherited downwards like the chain of command (commitment 8); a lower level may choose another mode. It is the development-mode policy of the catalogue (the Kernel's Policies section), advised until the tool runs the steps itself.

local-fast (the default).

1. Builders commit to their own local branch in their worktree. No push, no pull request, no per-commit CI, no per-commit review.
2. One integrator (the orchestrator or a seat it names) merges the builders' branches locally into the integration branch, batch by batch. Worktrees share one repository, so nothing is pushed to hand work over. One quick local check per batch: an incremental typecheck and the touched tests.
3. When the work is done: one review of the whole by a lab other than the authors', the full test suite once locally, the docs; then one push, one pull request, CI once, the merge (a merge commit, an owner decision), the install. Releases, publishes and deploys stay with the owner.

pr-per-change (opt-in). Each builder pushes its branch and opens its own pull request, reviewed and merged one by one (the behaviour commitment 3 described before this decision). For projects or teams that need it, for example outside contributors on a public repository.

Why: on 2026-10-16 a sprint run with a push per seat through a shared check took about 3.5 minutes per push, plus lost push races. Merging locally removes both.

2c. The round (owner, 2026-10-17: "all this should be handled by the workflow")

The owner, 2026-10-17, 00:55: "We did very well together today. We have accelerated the development rhythm significantly … But all this should be handled by the workflow that does not exist yet."

A round is the unit of a team's building work under a development mode. It opens with round start, runs while builders commit and the integrator merges, watches its own liveness, and ends with round close, a fixed sequence that leaves a report. Every threshold and step below is a setting per entity, project and team, with its default and at-the-tag state in the round specification (Specs-round §3.2), which this text does not repeat; a step that gates is a policy in the catalogue form (the Kernel's Policies section), and the gate is the Kernel's. Section 3 records how the same round was run by hand on 2026-10-16 and 2026-10-17, which is where each commitment comes from.

11. round start opens a round and writes it down. It MUST write the round's record, whose fields the specification lists (§3.1): the development mode (§2b), the integration branch, the worktrees, the integrator, the seats, the tracker items and the start time. Who may open a round is the Kernel's row for starting work (Kernel §9; the who-may-start policy proposed for the Kernel); by default the team's lead. Spec: Specs-round §3.1. Proof: none. Today (v0.5.0). Not a command at v0.5.0; the round is a playbook run by hand (contract/cli.json names no round command).
12. Integration and the light check are automatic. Under local-fast the integrator MUST merge the builders' local branches into the integration branch per commit or per batch (batch-interval) and run the light check on each batch (light-check); both settings' defaults and recipes are the specification's (§3.2). The dependency depth of the check is what a batch needs: a change can break a test it does not name, and the tests of the files that import it are the cheap part of the answer the full suite confirms (commitment 20). A failed batch goes back to its builder with the failure while the round goes on for the others. Nothing is merged silently, nothing fails silently, and no seat merges by hand. Spec: Specs-round §3.2, §5 rule 3. Proof: none. Today (v0.5.0). Not built at v0.5.0; batch-interval and light-check are not settings in src/policy/types.ts.
13. A task is taken only on the seat's acknowledgement. A dispatch MUST become an assignment only when the seat acknowledges it: a receipt (002 Communication's receipt). Until then the item stays open, the holder is not written (commitment 4), and the round's liveness clock (commitment 14) keeps counting. A delivery outcome is not a receipt: "delivered" says the message reached the seat's program, not that the seat read it. A dispatch not acknowledged within ack-timeout is sent once more, then dispatched to another seat, and both are recorded (§3.2). Spec: Specs-round §3.2 (ack-timeout), §5 rule 1. Proof: none. Today (v0.5.0). Receipts are not built at v0.5.0 — the socket layer records that there is no acknowledgement on the socket (src/send/uds.ts) — so the commitment cannot hold; acknowledgement is the seat's pull through team next, which exists (contract/cli.json).
14. Liveness: a round with no seat working is told to someone, by thresholds. Whether a seat is working is a state TeamCLI keeps, not a guess from a pane. The Runtime keeps one state per seat (working, idle, done, blocked, held, unreachable, unknown), its seat lifecycle (Runtime, commitment 8; built at v0.5.0 with the live labels), read from ranked sources: the CLI's own signal first (hooks, notify); herdr's screen status next; TeamCLI's own traces last (the last acknowledgement, commit, tool call or message within seat-idle); otherwise unknown. A seat unknown for longer than unknown-threshold counts as not working for liveness and is flagged blind, a must-fix the lead is told of. (Owner, 2026-10-17: "it is a state … teamcli should be aware of this status.") When no seat of an open round is working for idle-to-lead, the lead MUST be told; for idle-to-owner, the owner is told; each telling is recorded. The thresholds are the owner's decision (an owner decision); their defaults and the policy names they became are the specification's (§3.2). The integrator re-dispatches on its own (commitment 15): nobody has to notice first. Spec: Specs-round §3.2, §5 rule 4. Proof: none. Today (v0.5.0). The seat state is built at v0.5.0 (one state per seat, the seven labels, ranked sources; src/state.ts (the seat record), src/labels/state.ts (the labels and the ranking)); the thresholds are enforced policy names: the lead rule 300 s, the owner rule 900 s, blindness 300 s (the owner decision's numbers), and the trace window 120 s (src/settings/inherit.ts; question 10).
15. No idle seats: a seat that finishes pulls the next item. [Earlier proposal, owner pending; carried here as the round's rule.] When its task is done, a seat MUST take the next unassigned item of the round that its role can do, acknowledge it (commitment 13) and start, without waiting to be asked. A seat with nothing it can take says so once to the integrator and stops; it never ends a turn "standing by". The lead sets priorities; it does not hand out every task. Re-dispatch is the tool's (team next), never a hand-typed message. Spec: Specs-round §5 rule 2. Proof: none. Today (v0.5.0). Discipline plus team next at v0.5.0: the pull itself is not enforced (contract/cli.json).
16. Installs go forward only. An install MUST replace the running version with a newer one. Going back is a rollback: declared as such, recorded with the two versions and the reason, told to the owner and to the open round. An install that would run an older version without that declaration is refused: the forward-only-install policy (section 2d), whose gate is the install step the Runtime runs, not this module. Spec: Specs-round §3.5, §5 rule 5. Proof: none. Today (v0.5.0). Not built at v0.5.0: forward-only-install is a planned policy row, not in the code (src/policy/types.ts); the install step does not compare versions.
17. round close is one fixed, scripted sequence. The sequence MUST be the specification's, in order there (§3.3): the freeze of the integration branch; the review of the whole by a reviewer from a lab other than the authors' (review-lab); the full test suite, once, locally; the docs; one push; one pull request; CI, once; the merge, as a merge commit (an owner decision); the install (commitment 16); the round report (commitment 18). No step is skipped and none is reordered; a failed step stops the sequence, names the step and the reason, and the round stays open until the step passes or the lead reopens the round. Under pr-per-change the per-change steps run per change and the close runs the rest once. The sequence is the round-close-sequence policy (section 2d). Spec: Specs-round §3.3, §5 rule 6. Proof: none. Today (v0.5.0). Not a command at v0.5.0; round-close-sequence is a planned policy row, not in the code (src/policy/types.ts); the close runs by hand as ten typed steps.
18. Every step is timed, and the day is reported. The round MUST record the duration of each step, and a daily report per team says what the day did and what it cost; what is timed and what the report lists are the specification's (§3.4), and the budgets it compares against are settings (push-gate-budget, daily-report; §3.2). The report goes up the chain (commitment 6); the owner reads the report, not the panes. Spec: Specs-round §3.4, §5 rule 7. Proof: none. Today (v0.5.0). Not built at v0.5.0: nothing times a round's steps and no daily report is produced; daily-report is a planned policy row, not in the code (src/policy/types.ts).
19. The owner decides; the round runs. What reaches the owner from a round: a liveness telling at idle-to-owner, a rollback, a blocker he alone can lift, the round report, and the decisions that are his: priorities, releases, publishes, deploys and policies (Kernel §8, §9; the Kernel's Policies section). Everything else MUST run without him, and a round never waits on the owner for a step that is not his. Spec: Specs-round §5 rule 9. Proof: none. Today (v0.5.0). Practice; holds in the by-hand rounds.
20. An hourly full suite covers what the light check cannot see. The light check runs the tests a batch touches and the tests of the files that import what it changed; a failure in a test the round never touches is invisible to it. While a round is open, one seat MUST run the full suite on the integration tip at the hourly-suite interval (§3.2): a pass is skipped when the tip is the sha the last pass ran, when another pass holds the lock, or when a heavy slot is held; otherwise it takes one heavy slot, runs on a dedicated worktree, records the counts and the failures by file, and tells the lead in one line. A red result on the integration tip stops the round's merges: nothing is merged into the integration branch until the lead has understood the failure and cleared the shared marker (red-stops-merges). A red on any other branch — a feature branch's sweep or a pass against another ref — writes a marker named for that branch (the marker's form is the specification's) and blocks only that branch's merge into the integration branch, never the shared one, so one branch's red never holds another branch's merge. A pass that cannot start (no integration tip, worktree update or install failed) is reported as an error and is not a red tip. The rule comes from the full suite of 2026-10-17 morning, which found 32 failing tests in 6 files while every light check was green. Spec: Specs-round §3.2, §5 rule 8. Proof: none. Today (v0.5.0). Not built at v0.5.0: no hourly suite runs from the round; red-stops-merges is the integrator's discipline and the lead's clearing of the shared marker, and hourly-suite is a planned policy row, not in the code (src/policy/types.ts).

2d. Policies this module defines (catalogue form)

Two of the round's rules gate, so they are policies, written in the headed format of the catalogue of the Kernel's Policies section and listed there. A module cannot add a refusal (Kernel §13): each is proposed as enforced, with the refusal at a gate the Runtime runs under the Kernel's rows; until the Kernel names that gate, each is advised, shown and logged.

forward-only-install. Scope: entity, project, team. Values: on, off; on is tighter. Default: on. Kind: proposed enforced, the install step refuses a version older than the running one unless a rollback is declared (reason, the two versions) and recorded; the refusal and the rollback are told to the owner. Set by: the owner; a holder named by grant. Since: 2026-10-17, the owner's direction of 00:55, after the silent rollback of 2026-10-17. Home: this module, commitment 16.

round-close-sequence. Scope: entity, project, team. Values: the ordered list of commitment 17; a level may add a step, never remove or reorder one. Default: the ten steps of commitment 17. Kind: proposed enforced, round close refuses to skip or reorder a step and stops at the first failure, naming it. Set by: the owner; a holder named by grant. Since: 2026-10-17. Home: this module, commitment 17.

The liveness thresholds and the other settings of §2c tell and record; they do not gate, so they are settings, not policies. red-stops-merges (commitment 20) is a rule the integrator keeps from the round's records, not a refusal the tool makes: until the round is a command, it is as strong as the integrator's discipline and the lead's clearing of the marker. A red on a feature branch is recorded against that branch (a per-branch marker beside the report, its form the specification's), so the shared stop is reserved for the integration tip.

The settings table of the current text's §2c — every setting, default, levels and using commitment — is now the round specification's §3.2 (Specs-round), which also records which of the liveness thresholds exist at the tag as enforced policy names. A lower level inherits each setting and may tighten it (a shorter interval, a stricter lab rule); it may loosen only where the setting's text allows it, as the Kernel's Policies section §2.3 says.

2e. The workflow graph (the owner's fold of 2026-10-19, from an earlier internal proposal)

The owner decided on 2026-10-13 that a workflow is a declarative state graph, and narrowed the fold to the mechanics on 2026-10-19. On 2026-10-19 the owner also set the graph's reach (an owner decision): a workflow's domain is not only code — research, purchases, bookings and documents travel as workflows of the same shape, and the states, guards and hooks never assume git, pull requests or CI. As everywhere in this module, the refusal below is a policy at a gate the Runtime runs under the Kernel's rows (Kernel §13; §2d), not a gate this module adds. What the owner called a journey on 2026-10-19 is, in this series' words, a plan (008 Planning) or a workflow run of this graph; the texts use those words, and "journey" names no term of them.

21. A workflow is a declarative state graph, and the orchestrator enforces it. A workflow is a graph of states and transitions; each transition carries its guard (what must hold for the move) and its role (who may make it). The orchestrator MUST refuse a move the graph does not allow, and MUST record the refusal with the state, the transition and the guard that failed. The round of §2c (Specs-round) is the graph's first instance, not a separate fixed sequence kept beside the mechanism: its close steps, liveness rules and dispatch rules read as the states, transitions, guards and hooks of one graph. A guard MAY read any setting of the round (the spec's §3.2), among them a work in flight limit — a count of open work (pull requests, branches, tasks) per team — which is a setting a guard uses, never a rule of this module. The task boundary — the point at which a seat's current task ends and the next may begin — is a state of the graph; a seat's queued model swap waits for it (two owner decisions). For work whose product is an answer rather than a change — research above all — the quality the graph requires comes from several labs answering separately and reconciled: the disagreement is shown, never averaged away, and the sources are cited, a claim no source supports marked as such (an owner decision). Spec: Specs-round §3.1–§3.3 (the round as the graph's first instance); the graph's syntax is question 12. Proof: none. Today (v0.5.0). Not built at v0.5.0: no graph is parsed or enforced and no transition is refused (contract/cli.json names no graph command); the round of §2c runs as a by-hand playbook.
22. An effect is never fire-and-forget. Effects ride hooks on entering a state. When an effect fails, a reconciler MUST compare the expected state with the actual state and repair the difference, and the repair MUST be recorded. This reconciler is the workflow's own, kept apart from the bus reconciler already carried (Specs-events — the reconcile pass over the durable message and seat records, built at int/0.5.1 (8acb470b), unreleased, not in v0.5.0): the bus reconciler repairs the team's message records, the workflow reconciler repairs the effects of a transition, and neither silently takes over the other's work. An effect with a reach outside the machine — pay, book, send, sign — MUST wait at its guard for the owner's explicit confirmation, or for a grant that names it and carries a limit; the firing is logged, and the effect is never skipped at night (an owner decision). Spec: none yet for the workflow reconciler; Specs-events holds the bus reconciler it stays apart from. Proof: none. Today (v0.5.0). Not built at v0.5.0: effects are fire-and-forget; the bus reconciler of the events spec is built at int/0.5.1 (8acb470b), unreleased, not in v0.5.0 (Specs-events).
23. Reusable workflows. A workflow library holds entries whose mechanics are fixed — set the goals, execute autonomously, review and adapt — and whose timings, pace and cycles are settings, inherited and tightened as every setting of the round is (§2c). A team MAY run any entry as its workflow with its own settings; the library MUST NOT fix what a setting can change. The first entry is evening–morning, the owner's definition of 2026-10-12 and 2026-10-13: in the evening the owner and the seats set the goals together; at night the seats execute autonomously and, when they disagree, decide in the most honest direction, with no blocker accepted; in the morning the owner reviews, and whatever diverged is refactored and adapted. Beside it the library holds entries for work that is not code — research with cross-lab verification, purchase with owner confirmation (an owner decision) — the mechanics fixed, the timings, pace and limits settings. Spec: none yet. Proof: none. Today (v0.5.0). Not built at v0.5.0: no workflow library exists; evening–morning is a written definition.

3. Why

The round was run by hand before it was written: one integration branch in local-fast mode on 2026-10-16 (evening) and 2026-10-17 (night); builders committed locally; the integrator merged batches about every 10 minutes with a light check of about 30 seconds; seats were re-dispatched by hand after answering "standing by"; the close ran as cross-lab review, full suite, docs, one push, one pull request, CI once, merge, install, each step typed by a person. What went wrong, and which commitment answers it: the owner noticed the team idle for about 20 minutes before anyone else (commitment 14); team send reported "delivered (socket)" while no seat had read anything, every message sitting in a held dialog (commitment 13; the delivery-order policy of 002); the install went back from 0.4.27 to 0.4.26 without a word (commitment 16); the push gate was measured by hand, 5 to 9 minutes before the change and about 30 seconds after (commitment 18). The full suite of 2026-10-17 morning found 32 failing tests in 6 files while every light check was green (commitment 20). Each commitment in §2c is the answer to one of those findings.

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

• An operator on every task adds a step and some latency, until orchestrators have tracker access.
• Moving the item before delegating delays the start slightly, in exchange for an accurate tracker.
• A declared schema is one more thing to keep in step with who is actually on the team.
• Taking the chief architect off the path means each orchestrator must hold its own picture of its team.
• A round adds bookkeeping: round start and round close, timings, a report. The timings are what pays for it: a step that costs more than it saves shows up in the report and can be cut.
• Commitment 13 needs receipts before it can hold; until Phase 2 of 002, acknowledgement is the seat's pull through team next.
• forward-only-install needs the tool to compare versions, and a declared rollback path.

5. What would change our mind

• If agents get their own tracker accounts, commitment 4 becomes the holder updating the tracker itself, and the operator step may go.
• If orchestrators routinely lose track without a central relay, a coordinating seat could return, as a setting the owner turns on.
• If out-of-chain handovers shown to the owner become noise, they could be grouped in a summary; if they cause real harm, the owner can ask for a Kernel-level gate, which this module cannot add.
• If the round's timings show the ceremony costs more than the by-hand playbook saved, the close sequence shrinks; if a lab's seats cannot give receipts, acknowledgement by pull replaces them for that lab.

6. What is true today

"Today" is v0.5.0 (52db9b75).

#	Rule	Today
1	A task enters through the orchestrator	Practice; the Runtime's dispatch (team next) exists; no chain-of-command section exists in the team configuration at v0.5.0
2	The tracker shows it started	Practice; agents have no tracker accounts of their own, so orchestrators and operators update the tracker through the owner's connector
3	The orchestrator staffs, it does not build	Practice, each team's written rules; three proposals pending with the owner
4	One holder, written down	Practice; the holder comment is written by hand
5	An estimate in minutes	Practice
6	Reports flow up the same path	Practice; the blocker exception pending with the owner
7	Closing leaves a trace	Practice
8	The chain-of-command schema	Not built: no chain-of-command section exists in the team configuration at v0.5.0
9	The workflow is the owner's setting	Practice; the schema's file is unnamed here and none exists at v0.5.0
10	The chief architect sits outside the chain	Practice; the replacement pending with the owner
§2b	The development mode	Built as the advised development-mode policy name, default local-fast, entity/project/team levels with a lower level choosing; the tool runs none of the mode's steps itself
11	round start	Not a command at v0.5.0; the round is a playbook run by hand
12	Integration, the light check	Not built; batch-interval and light-check are not settings in the code
13	Acknowledgement, receipts	Receipts not built — the socket layer records that there is no acknowledgement on the socket — so the commitment cannot hold; acknowledgement is the seat's pull through team next, which exists (team next [--mine | --release] [--wait] [--json])
14	Liveness, the seat state, the thresholds	The seat state is built (one state per seat, the seven labels, ranked sources); the thresholds are enforced policy names at v0.5.0: the lead rule 300 s, the owner rule 900 s, blindness 300 s (the owner decision's numbers), and the trace window 120 s — see question 10
15	A seat that finishes pulls	Discipline plus team next; the pull itself is not enforced
16	Forward-only installs	forward-only-install is a planned policy row, not in the code at v0.5.0 (src/policy/types.ts); the install step does not compare versions
17	round close	Not a command; round-close-sequence is a planned policy row, not in the code (src/policy/types.ts); the close runs by hand as ten typed steps
18	Timings, the daily report	Not built
19	The owner decides; the round runs	Practice; holds in the by-hand rounds
20	The hourly suite, red stops merges	Not built; red-stops-merges is the integrator's discipline and the lead's clearing of the marker
21	The workflow graph, enforced by the orchestrator	Not built at v0.5.0: no graph is parsed or enforced and no transition is refused; the round of §2c runs as a by-hand playbook
22	Effects never fire-and-forget: hooks, the workflow reconciler	Not built at v0.5.0: effects are fire-and-forget; the bus reconciler of the events spec is built at int/0.5.1 (8acb470b), unreleased
23	The reusable-workflow library	Not built at v0.5.0: no workflow library exists; evening–morning is a written definition (docs/workflows/evening-morning.md)
§2d	The two policies	Both proposed as enforced, planned rows of the policy catalogue, not in src/policy/types.ts at v0.5.0 — advised in intent until the Kernel names their gate
—	team send	Delivers between seats with a sender header and an outcome; at v0.5.0 the socket leg is not opened and the typed leg delivers (the delivery-order policy of 002)
—	The close's review aids	team commits check <ref> [--since <ref>] [--file <path>] [--json] exists, the commit and range check against the team file's seat list
—	Earlier proposals	Seven points from an earlier revision await the owner point by point

7. The security boundary

This module adds no gate and no refusal (Kernel §13): every refusal named above — the forward-only install, the close that will not skip a step — is the Kernel's at a gate the Runtime runs, and until the Kernel names that gate the policies are advised. What the module holds is the shape of the work: who hands what to whom, and what a round records, so that a person or a seat cannot quietly reshape either without the owner seeing it in a report.

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

Module 010, rank 8: it uses the Kernel's authority (§5, §9, §13, §15) and the Runtime's item lifecycle and seat state (runtime.md commitments 8 and 24), and only selects among settings; the seat state's ranked sources and labels are the Runtime's, the receipt is 002's, the thresholds' enforced names and defaults are the policy catalogue's, and the machine's heavy-slot rules the round's hourly suite obeys are the operations texts'. The formats of the round — the record, the settings, the close sequence, the timings, the report, the markers — are the round specification's (Specs-round).

9. Prior art and alternatives

The by-hand playbook of 2026-10-16 and 2026-10-17 is the prior art §3 records; the module is that playbook written down with thresholds, not a new design. The alternative is a chain that runs owner → entity orchestrator → project lead → team lead → seats with the architect consulted but off the path, against this text's flatter owner → orchestrator → seats with the architect wholly outside; the owner has not decided. pr-per-change is the mode the team ran before an owner decision, kept as opt-in for outside contributors. An earlier internal proposal proposed the same graph with roles, merge approval, pull-request-count limits and tracker chains; the owner's narrowing of 2026-10-19 carries the mechanics as §2e and lets the rest lapse where other texts answer it — merge approval to grants (the Kernel's Grants section), the pull-request count to local-fast (an owner decision), the tracker chains to the round and the Quality module.

10. Open questions

1. Who is the operator when the first assistant is down: the orchestrator, or nobody until it returns?
2. Must the tester always differ from the builder's lab? (Proposed: yes, by default.)
3. What happens when an ETA is missed twice: reassign, or only report?
4. Does an out-of-chain handover belong in the ledger, or only in the module's own records?
5. The default schema for a new team with no declaration.
6. Settled by the owner on 2026-10-17: a seat's working state is TeamCLI's own seat state, from ranked sources, with unknown past a threshold counting as not working (commitment 14). The state model is the Runtime's.
7. Under pr-per-change, is the round's close per pull request, per day, or both?
8. Which channel carries the daily report and the liveness tellings: the reporting path of 002's notifications draft, or the round's own record?
9. Is the forward-only-install gate a Kernel row (an install as a deploy-class operation) or a Runtime check under an existing row?
10. For the build: seat-idle (§2c, default 5 minutes) and the code's trace-window policy name (default 120 s at v0.5.0) govern the same ranked source — TeamCLI's own traces. Is seat-idle that policy name with its default to be raised, or a fourth threshold beside it? The round spec's §7.3 holds the same question.
11. An earlier proposal's workflow beyond one round: carried and lapsed, as an earlier coverage audit records. Carried as commitments 21–23: the enforced declarative state graph with its transition guards and roles, the round its first instance (21); the hooks on entering a state with the workflow reconciler, kept apart from the bus reconciler (22); the reusable-workflow library with fixed mechanics and configurable timings, pace and cycles (23) — the graph's syntax staying open as question 12 (an earlier proposal's question 6). Lapsed with the decisions that replaced them, and not missing obligations of the new graph: the pull-request-count WIP and backpressure framing (local-fast, an owner decision; a work-in-flight limit stays a setting a guard MAY use, commitment 21); the all-linked-pull-requests completion predicate (the round and the Quality module); its named roles, the owner's representative and merge approval (grants, the Kernel's Grants section); and its questions 1–5 and 7 (1, 4 and 7 to grants, the Kernel's constraints and Quality; 2 and 5 to local-fast; 3 to the round and Quality). Its illustrative YAML was never normative.
12. The syntax of the state graph (an earlier proposal's question 6): its YAML sketch was illustrative, never accepted; whether a graph is written in the team file's format extended, another data format, or a small dedicated language is open.
13. Commitment 10's unmarked MUST. It states the flat chain — the chief architect outside it, the owner or his first assistant speaking to each team's orchestrator directly — as a MUST, while §7 says the owner has not decided between it and the multi-level chain, and an earlier source records the other chain. Cite the owner's decision behind the flat path, or mark commitment 10 owner-pending as the replacement is, the source's chain named in the marker? The owner to decide.
14. Commitment 14's ranked list against the Runtime's semantics. Its simplified ranking — the CLI's own signal first, herdr's screen status next, TeamCLI's own traces last ("the last acknowledgement, commit, tool call or message within seat-idle") — restates the Runtime's state model in this module's words; the code gives blocked screens priority over clocks, lets a fresh trace outrank idle, and counts an unclocked tool row as not a trace. Should the commitment's clause defer to the Runtime's actual semantics (a link, not a redefinition)? The round to decide.
15. Commitment 15's pull beside the queued swap. Its unconditional take-next-item sits beside an owner decision already cited by commitment 21: a healthy seat with a queued model swap takes no new task and yields at its boundary. Add that exception to the pull rule and the spec's §5.2, with the Runtime's bounded wait and broken-seat rules referenced? The round to decide.
16. The per-PR review before merge under pr-per-change. The spec runs steps 5 to 8 per change and leaves the review of the whole (its step 2) to the close, so read literally each pull request merges before its independent review, against §2b's "reviewed and merged one by one". Give the mode an explicit per-PR path — review of the exact change and its required checks before merge, the aggregate report and the release checks at the close, commitment 17's shorthand pointing to that mapping? The round to decide.
17. Commitment 22's repair under the Kernel's record contract. Its reconciler repairs whenever an effect fails, now including pay, book, send and sign; Kernel §15 requires durable intent and outcome, blocks an unknown target or request, prohibits redispatch under the same request id, and requires owner-signed recovery when the external result cannot be determined. Subordinate workflow repair to that contract — observe and reconcile first, retry only where outcome and authority permit, unknowns and reservations preserved — and read the night rule as "the confirmation guard is never skipped at night" (an owner decision)? The round to decide.
18. Commitment 8's inheritance direction. It says a project inherits from its team and a team from its entity; §2b and the policies spec establish the other direction, entity → project → team → seat. Correct the schema's inheritance sentence to the established direction, stating which reporting-path overrides the higher levels permit? The round to decide.
19. The round spec's decided labels on owner-pending proposals. The spec's §3.2 header calls the round's settings decided and §5.2 states the pull rule unqualified, while this text marks the pull rule and borrow-seat owner-pending. Mark the pending proposals consistently in the spec rather than reading as accepted? The round to decide.

12. Links to the spec

• Specs-round — the round's formats: the record (§3.1), the settings with defaults and what exists at the tag (§3.2), the close sequence (§3.3), the timings and the daily report (§3.4), the install and the rollback (§3.5), and the rules as BCP-14 lines (§5).
• Specs-policies — the policy entry, the four level sources and the catalogue; this module's two policies are rows of registries/policy-names.md (forward-only-install, round-close-sequence, both proposed as enforced, planned rows of the policy catalogue, not in src/policy/types.ts at v0.5.0 — advised in intent until the Kernel names their gate) and the liveness thresholds are the enforced names listed there.
• Registries contributed: none beyond those policy-names rows; this module adds no event kind, exit code or capability.