# Review: for an engineering leader > A first review page of RC1 for one kind of reader, a CTO or engineering leader whose teams already use coding agents: two chapters with a pen on every paragraph. A prototype with fictional data; nobody has been sent it. *Source: · site v0.1.226 · generated from the same content as the page, so the two cannot drift.* --- Prototype, fictional data. Nobody has been sent this page; a kind of reader, not a person, is named here. Made by `review/tools/make_review.py` from `review/personas/cto.json`. RC1 · a review copy for an engineering leader # Dear reader, would you read two chapters? From the editor of *The ultimate insider*, a book about one day in which one person and a team of AI agents built a talk, with the record to prove it. Why you You run engineering where agents already ship code. If the speed in these chapters is only activity, or the gates are ones your teams already have under another name, you will see it first. What we would like Two chapters, about 37 minutes, by Friday 13 November 2026 (an example date: nothing has been sent), and your answers to a few questions at the end of each. What you get back - your name in the acknowledgements, if you want it there - the first edition when it ships - a reply to every comment, and a page showing what your comments changed - [4. The hourly machine](#c04) about 20 minutes · the machine: wakes, the gate and releases, every hour - [8. The locks that never closed](#c08) about 17 minutes · brakes under deadline: what held, what bent, and what stopped the team **Short of time?** Read [chapter 4](#c04) first. **To comment**, click any paragraph: pick a mark, add a line, or both. Your comments stay in this browser until you send them. ## 4. The hourly machine There is a tempting picture of an agent team in which the agents are clever about each other: they negotiate, they notice what a colleague needs, they hand work across in conversation. The talk's team did not work like that, and the record suggests it would have done worse if it had. What it had instead was a clock and a record. Every member woke on its own minute of the hour. Work was asked for in files and answered at the recipient's next minute. The team talked through public stores whose every word anyone could read. And from 02:14, every piece of work was wrapped in five steps (a plan, a review of the plan, the work, a review of the work, a check against the plan), each leaving a verdict in a file. None of this is clever. It is the kind of thing a shift supervisor in a hospital or a control room would recognise at once: a rota, a handover sheet, a log that the next person reads before touching anything. The chapter's argument is that this plainness is the point. A team of agents that never sleeps needs a rhythm a person can read in the morning, and a record that shows the review happened, not a promise that it did. The talk's beat for this chapter is the one about time. The insider the talk describes has none of the limits that used to slow an insider down: it does not tire, it does not go home, it does not stop when the office empties. If that is the risk, the brakes have to keep the same hours. A control that only works while a person is watching is a daytime control on a night-time risk. The hourly machine is this team's answer to that, and the night of 29 October is the test of it. ### A clock, at the editor's word The rules that made the machine were written between 01:27 and 01:40, almost all by one member. Between 01:27 and 01:40 the conductor committed the vaults manager's key and the pull-first start (`02cbd86`), the guide to running the team and `WAKE.md`, the checklist every wake follows (`ecc048e`, 01:35), the form of a commit subject (`5c2bcc5`, 01:36), and then, at the editor's word, the schedule itself (`09f13d5`, 01:39). Every member would wake hourly, round the clock, each on its own minute. The same commit made `start.py` stop every wake while any `HOLD.md` existed, and said only the editor lifts a hold. The order matters: the brake that could stop the whole team existed before the first scheduled wake did. The minutes were chosen for the flow of work, not for convenience. The conductor woke at :02 and routed the mail, so that everyone after it found its requests waiting. The researcher, at its own request, took :09, so that a checked number reached deck in the same hour. Deck, at :17, decided what the talk needed. Ruv-sgit, at :32, made it. The designer, added in the night at :39, came after the makers and before the builder, so that a design note could be built within the hour. Dev, at :47, merged and released the hour's finished work. When the storyteller joined in the afternoon it took :54, to see the hour's work before the conductor routed the next round (`team/conductor/schedule.json` at `298be4e`). The schedule file explains each minute in a sentence. A reader who has never seen the team can work out from it who hears what, and when. Almost at once the record shows its first correction of the team's own process. At 01:40 the conductor recorded scheduled tasks it had created for dev, deck and ruv-sgit (`d8f3300`). At 01:43 it disabled them, before any had fired, and wrote the rule that each member creates its own task from its own session (`b620234`). A task fires into the session it belongs to; a conductor that creates tasks for others is reaching into sessions that are not its own. Nothing went wrong, and nothing fired. But it is the first place in the record where an agent's reach went past what the team then decided an agent should do, and it was the agent that pulled it back. The historian counts it among the day's turning points (`timeline/turning-points.md`, TP-2). By 01:54 dev had followed it: its own key, its own task at :47, created from its own session, and a note to the conductor that the task made for it stayed disabled (`56cbe55`, `5c5b23b`). The first scheduled wake in the record is ruv-sgit's, at 02:33 (`team/ruv-sgit/wakes/`, `0d13c43`). ### Requests as files The schedule only works if work can wait between slots without being lost. The team's answer was to make every request a file. A member asking another for work wrote a message with a kind header (`X-Kind: request`) into the recipient's folder in a shared mailroom. The recipient, at its next slot, opened an issue on its own board, replied naming the issue, and moved the message along as it acted. A request left unanswered past the recipient's next slots was the conductor's to flag, on its board and to the editor (`schedule.json`, "asking_for_work"). Until a member's session held the key to the mailroom, it wrote the same request as a markdown file in its own `requests/` folder in the repository, and the conductor copied it across at :02. On a quiet morning this is almost invisible, which is what a working mechanism should be. Deck asked the researcher for something at 09:21; the researcher answered at 10:14, in its own slot; deck used the answer at 10:21, in its next one (`timeline/day/10.md`). Nobody chased anyone. The schedule's own promise, that "a request written in one hour is answered by the next slot of its recipient", held because it was not a promise of anyone's attention, only of the clock. The members also began to pace each other, which no rule asked them to do. In the 04:00 hour deck held its next request to ruv-sgit until the previous one had been delivered (`aeffbf9`, 04:18); in the 08:00 hour it held an ask of the researcher while another of its requests to the researcher was still open (`eefc1d3`, 08:18). A member that will not put a second request in flight while the first is open is doing, on its own, what a work-in-progress limit does in a factory. The conductor had written the general form of it at 03:10, after dev raised new asks in the middle of the night: "backlog, then schedule, then execute, for everyone" (`648feee`). The failure here is quieter than the others in this chapter, and it is kept because it shows where file-based routing frays. At 16:44, with the talk close, the editor asked every member where its tasks stood. The conductor's plan for that wake found a backlog: requests that members had written in their own `requests/` folders through the afternoon, and that had never been copied into the mailroom. Its own note says nothing had been lost, because recipients read every `team/*/requests/` folder at every wake as the checklist requires; but routing was the conductor's job, and it had not been done. The wake routed the live ones in a batch, verbatim, after `vault_check` (`eb0b5cd`, `team/conductor/wakes/20261029T164439Z.json`). The fallback had quietly become a main channel in the busiest hours of the day, and the record of who had asked whom for what was split between two places until someone looked. The lesson is ordinary and worth having: a team that routes through files needs one place where the files are, and a check that they arrived there. ### Two public vaults The mailroom and the board lived in two public vaults the conductor created at 01:09 (`31b0f86`): an Issues-FS board and an Email-FS mailroom, each a store of plain files, encrypted, with a read key. Their read keys were published on purpose from the start. At 01:43 their write keys were sealed to each member in a handover and never printed, and a check was added to run before every vault commit, because every file in them is public (`b620234`, `admin/tools/vault_handover.py`). By 03:08 ruv-sgit and deck had opened their keys and were using their boards and mail (`b5213de`, `983782b`). The researcher kept another public vault for its evidence. Making the team's correspondence public is the most counter-intuitive choice in the machine, and on reflection one of the soundest. It means the editor, or anyone, can read every request any member sent, every reply, every board, without asking a member to report on itself. It means a member cannot have a private conversation with another member that the person in charge cannot see. For a team whose whole subject is the insider, a communications channel with no back room is a control in its own right. The price is written in `WAKE.md` in bold: every file in both vaults is public, forever, and a later commit does not unpublish an earlier one. So a check runs before every vault commit (`admin/tools/vault_check.py`), looking for keys, tokens and personal details, and the post-review records that it ran. The control register (`controls/`) lists this as C8, a setting with an expectation behind it: the tool refuses what it knows, and the member is trusted to run it. Reviews found patterns the check did not know. At 14:03 the conductor's pre-review made adding one more key pattern a condition of the plan, and `vault_check` was taught it in the next commit (`c9ced4e`). Another gap was found only after a push, and it belongs to the night. ### Five steps around every piece of work At 02:14 the conductor opened a wake at the editor's request whose purpose was to build the five-step wake itself (`team/conductor/wakes/20261029T021416Z.json`). By 02:18 it existed: `wake.py`, which writes the record and refuses the work until both the plan and its review say go (`8c66751`, 02:16); the section in `WAKE.md`; the briefs for the review steps in `team/conductor/reviews/`; and `start.py` opening the record at the start of every wake (`5700bab`). The design is worth reading closely, because its choices are the ones a reader building their own would have to make. The plan is drafted by a sub-agent briefed as the conductor: a few items, requests first. The pre-review is a second sub-agent, briefed as security, on a smaller model and with a limit of a few minutes. It checks the plan against the member's written policy, the stop conditions, secrets and harm to other members, and it sees the plan and the rules only, "deliberately not the messages the plan came from" (`reviews/pre_review.md`). That last choice is easy to miss and important: a reviewer that never reads the material cannot be talked round by it. Only after both say go does `wake.py gate` let the member work. Then a post-review reads the diff, the gate, the vault check and any write outside the member's policy, and a post-check asks, item by item, whether the work went to plan. A `change` sends a plan back to be amended and reviewed again. A `stop` from any step writes the member's `HOLD.md`, and the whole team stops. Two things about it should be said plainly. The first is that the reviewer called "security" was a sub-agent, not a member. The team's security member was proposed and never staffed: the record has nine staffed agents (C011), and every security review of the day was a brief handed to a sub-agent inside the reviewed member's own session. The second follows from it, and `WAKE.md` says it itself: the five steps are "defence in depth in one session, not a second identity". The reviewer had the member's own reach. It could not have stopped a member that chose to ignore it, only recorded that it had said so. The control register files the five-step wake as C2, an expectation with a record, not a setting. What turned the expectation into something stronger was the gate. The very first five-step wake did not pass cleanly. The conductor, building the protocol at the editor's word, had added a line to `CLAUDE.md`, the file every member follows, outside its own scope. The editor had allowed it, and the pre-review had made a condition of naming it in the commit. The commit did not name it. The post-review found the omission, the post-check agreed, and the wake closed partial; the closing commit named the edit (`c8f6f8f`, 02:19). The first run of the review caught its own author. By 02:51, dev's first scheduled wake put `wake.py check` into the build gate (`99aaf05`, 02:51), so that a wake record with a skipped step failed the build for every member. A rule one member wrote at 02:16 was, by 02:51, a check the gate enforced on all of them. That is the shape the book keeps returning to: an expectation becomes a control when a tool refuses to proceed without it. ### What the record shows Because every wake wrote its record, the day can be counted, and the counts are more interesting than a description of the protocol. From the first record at 02:14:16 to the last wake started at 18:40:16 there are 162 wake records (C022). The conductor kept 43 of them; dev 22, deck 21, ruv-sgit 20, the designer 19, the researcher 17, the storyteller and studio 8 each, motion 4. Of the 162, 160 ran all five steps. The two that did not are deck's 18:20 wake, which has a plan and nothing else, and dev's 17:48 wake, which has no work or post-check step; neither was closed (C022). Both are in the last hours of the day, under the pressure chapter 8 describes. The verdicts show the steps working, and they also show where they did not (C023). Every plan said go: 162 of 162. The pre-review's final verdict was go in 161 records. But that final verdict hides the work it did: 11 times a pre-review said change and the plan was amended, of which 7 carry the verdict in a field of the record and 4 only in the conductor's free text. The work step was done in 151 wakes, partial in 4, nothing in 5. The post-review was clean in 157 and returned a finding in 4. The post-check found 148 wakes as planned and 12 partial, none off-plan. No step, in any wake, said stop. That last fact is the one to sit with. The machine was built with a stop at every step and a hold any member could pull, and across the whole day nothing in it stopped anything. The one hold of the day (C024) came from the editor's word about his usage, relayed by the conductor at 18:44, not from a review. One reading is that the day was benign and there was nothing to stop, which is true. The other is that the reviews were tuned to send back and fix rather than to halt, and that a reviewer inside the member's own session is likelier to say change than stop. Both readings fit the record. A reader building their own should expect the same: a review that has never said stop has not been shown to be able to. The sent-back plans are the steps' best evidence. At 04:10 the researcher's plan, for a wake that would capture web pages about prompt injection, was sent back with conditions: redact tokens and email addresses before any commit, store injected text only defanged and labelled, quote no payload to deck. One condition was wrong: the reviewer thought a file the researcher planned to touch was outside its policy, and the researcher disputed it from the policy's own text. The second pass withdrew the objection and said go (`team/researcher/wakes/20261029T041003Z.json`, history). A review that can be argued with from a written policy, and that changes its mind when shown the policy, is doing what a review should. At 14:03, with the editor just back and the conductor carrying his fresh words, the pre-review sent back a plan to write in other members' mailrooms, outside the conductor's scope, and asked for requests instead (`team/conductor/wakes/20261029T140334Z.json`, history). That is the control holding at the moment of most pressure, against the member closest to the editor. The post-check caught smaller things, and one of them became a rule. Closing its 03:02 wake, the conductor's post-check noticed that a correction in the brief and the pace file carried the time 03:08, typed by hand, for a commit made at 03:05. The conductor closed the wake with a lesson about itself: from the next wake, times come from the clock (`cabcd57`, 03:07). It is a tiny failure, and an exemplary one. A record is only as good as its timestamps, and an agent typing times from what it believes rather than reading them from the machine will drift. The team found it in its own record before the wake closed, and fixed the cause rather than the instance. ### The night The night is when the machine was tested, because the night is when the editor stopped being in the room. At 03:00 he was still in the sessions: most of the conductor's wakes in that hour were at his request (`timeline/day/03.md`). From 04:00 every wake in the record was scheduled except one of the designer's at 04:02. From 05:00 every wake was scheduled, each closing its five steps, one closing partial and saying so (`day/05.md`). From 04:02 until 14:03 no wake was at the editor's request (TP-5). Through the night and the whole morning the team ran itself, and the brakes ran with it. What they caught is the night's story, and it is not flattering. Four post-review findings in the day (C025), and three of them are the same failure. At 03:05 the researcher's post-review found that captured web pages it had already pushed carried public tokens that other sites publish in their own pages, and that a check had printed several of them to the session log. They were redacted in the files, and the editor was told (`team/researcher/wakes/20261029T030550Z.json`). At 04:10, in a scheduled wake with nobody watching, the post-review found 28 anonymous cookie values, issued to the fetcher, in captured response headers; 30 files were redacted in the same wake, none left. At 06:14, in another scheduled wake, the researcher's own re-check found form tokens in 10 captured pages, in a format the first pattern had missed, also in pages already pushed; redacted in the same wake (C025, `team/researcher/wakes/20261029T061456Z.json`). Read in order, the three findings show two things. The first is sobering: none of the three was caught before the values were public. Each review came after captured pages holding them had reached a pushed, public history, and each redaction fixed the current files, not the history. The reviews still ran at night, in wakes no person was watching, and the member's practice widened with each. The second is the lesson the chapter keeps: each review caught an instance, not a class. Cookies were found because tokens had been found, and form tokens because cookies had been; each redaction prompted a wider look, and each wider look found something the previous pattern did not know. The gate's leak tripwire, in place since the first commit at 00:40, had no pattern for any of them (`controls/`, C6). A review that runs after the work catches what is in front of it. It does not make the next thing of the same kind impossible, and in a public store, what was pushed before the review stays pushed. The night ended in a document written for a person. At 07:07 the conductor's scheduled wake wrote the morning review for the editor: what was done, what was ordered next, and what only he could decide (`3d94be9`). Its most pointed item was the night's own failure: whether any capture holding the redacted values had reached a pushed, public history. The researcher answered in its next slot, at 07:18: yes, it had. The question the night raised was settled before the editor read it, and the decision about it was left to him. That is the right division of labour. It is also why the failure is kept: the decision about other sites' tokens in a public history was still listed as waiting on the editor in his own decisions brief of about 15:00 (`team/conductor/briefs/2026-10-29__editor/1-editor-decisions-1500.md`, "Still waiting on the editor"), and whether to replace that history was still an open decision at 19:00 (`team/conductor/status.json` at `298be4e`). The machine could find a problem at night and answer every factual question about it by breakfast. It could not decide what to do about it, and the person who could was busy with a talk. Not everything the night produced was a finding. Two rules came out of it, each written within the hour of the failure that prompted it. Dev found at 03:34 that its release loop had counted a rejected push as pushed, and that commits had stayed off `dev` until checked; the rule became that a push is done when the commit is in `origin/dev` (`6a6be6d`). And the first full loop of the machine closed without anyone asking for it: the designer wrote its first design note at 03:41, dev built it at 05:51 in a slot the conductor had set, and the designer checked the build against the design at 06:45 and found it as designed (`c6dcf89`, `23fde17`, `51b2497`). Note, build, check, each in its own member's slot, with the conductor's schedule between them and no word from the editor. The slip of an hour inside it (the conductor had set the build for dev's 04:47 slot; it landed at 05:47) is itself the schedule working as designed: work missed in one slot is picked up in the next (`day/05.md`). ### The rhythm bends A machine built for an unattended night met a deadline in the afternoon, and it changed shape. When the editor returned, deck's 14:44 scheduled wake went idle on purpose, because the editor was doing that hour's work live in deck's session (`team/deck/wakes/20261029T144456Z.json`). The schedule did not stop; it yielded. At 15:21, at the editor's word, the work step's limit was raised from a few minutes to most of an hour (`545a473`, C041). His reason, recorded in `WAKE.md`, is itself a description of the machine: "if the next agent doesn't pick it up in the run in the same hour, it will pick it up on the next one". The short limit had suited a team running alone, where the danger was one wake doing too much unseen. The long one suited a team racing a deadline with the person in the room. The cost was written into the same paragraph: wakes of different members now overlapped in time, so every member had to pull `dev` again before every push. The stale copy that the pull-first rule had been written against at 01:27 became a live risk at 15:21. The historian folds this into the afternoon's three changes (TP-6), with the decisions of 15:00 and the arrival of motion and studio at 15:31 (C011). The commit history after that hour shows a different team. 358 commits came after 15:00 (C008), the publishing merge and its release at 23:19 among them. At about 17:00 the editor loosened the rhythm further, letting members follow their own wakes with one-off follow-ups until 20:00 (TP-7). That belongs to chapter 8, which asks what held and what bent. For this chapter it is enough to note what did not bend: every follow-up was still a full wake, with `start.py`, the five steps and the gate, and the pre-review was still sending the conductor's plans back as late as 18:19 (C023). ### What the machine is for It would be easy to read the hourly machine as process for its own sake, and some of it was: the banners, the commit forms, the night log regenerated every round. But the parts that mattered have a common shape, and it is worth naming because it is what a reader would build. Each of them replaces attention with a record. The schedule replaces a person deciding who works next with a file that says so. Requests as files replace a person remembering who asked for what with a folder that holds it. Public vaults replace a person asking members to report on their conversations with a store anyone can read. The five steps replace a person watching each piece of work with a record that says what was planned, what a reviewer thought of the plan, what was done, what a second reviewer found and whether it matched. None of these needs the person to be awake. All of them leave something the person can read when they are. That is the answer the machine gives to the talk's beat about time. An insider with no limits works round the clock, and the brakes have to keep the same hours. Through the night of 29 October they did: plans were sent back, a leak was caught three times, each time after the values had already reached a pushed, public history, and a document was waiting for the editor in the morning that told him what only he could decide. The record does not show the reviews preventing every failure; it shows them finding failures that no one was awake to find, and writing them down. It also shows the limits of a brake that lives inside the thing it brakes. The reviewers had the member's reach; the steps were an expectation the gate checked for, not a boundary the member could not cross; no step said stop all day; and each review caught an instance, not a class. The talk's own phrase for the difference, which chapter 3 met and chapter 9 develops, is that only a boundary is a control. The hourly machine was a very good set of expectations, made visible. It was what let one person run a team of agents overnight and know in the morning what they had done. It was not, and did not claim to be, what would have stopped a member that chose not to be stopped. ### Where this came from - The talk's repository at `298be4e`: `team/conductor/schedule.json`, `team/conductor/WAKE.md`, `team/conductor/reviews/pre_review.md`; wake records `team/conductor/wakes/20261029T021416Z.json`, `20261029T140334Z.json`, `20261029T164439Z.json`; `team/researcher/wakes/20261029T030550Z.json`, `20261029T041003Z.json`, `20261029T061456Z.json`; `team/deck/wakes/20261029T144456Z.json`; `team/conductor/briefs/2026-10-29__editor/1-editor-decisions-1500.md`. - Commits: `02cbd86`, `ecc048e`, `5c2bcc5`, `09f13d5`, `d8f3300`, `b620234`, `56cbe55`, `5c5b23b`, `0d13c43`, `31b0f86`, `b5213de`, `983782b`, `8c66751`, `5700bab`, `c8f6f8f`, `99aaf05`, `cabcd57`, `648feee`, `6a6be6d`, `aeffbf9`, `eefc1d3`, `c6dcf89`, `23fde17`, `51b2497`, `3d94be9`, `aa7a3eb`, `c9ced4e`, `545a473`, `eb0b5cd`. - This repository: `timeline/day/01.md` to `day/08.md`, `day/10.md`, `day/14.md`, `day/15.md`; `timeline/turning-points.md` (TP-2, TP-4, TP-5, TP-6, TP-7); `controls/README.md` and `controls/index.json` (C2, C6, C8); `index/areas/team-conductor.md`, `index/areas/tools.md`. - Register: C008, C011, C022, C023, C024, C025, C041. - Images: `team/conductor/debriefs/img/2026-10-29__hourly-and-handover__1-schedule.png`, `team/conductor/debriefs/img/2026-10-29__two-public-vaults__tui-issues-public.png`, `team/dev/debriefs/img/2026-10-29__the-board__1-board.png`, `team/designer/debriefs/img/2026-10-29__note-6-checked-and-the-player__01-pace__1600.jpg`, `team/conductor/debriefs/img/night-20261029T0327-1.png`, `team/conductor/debriefs/img/night-20261029T0327-2.png`, `team/conductor/debriefs/img/night-20261029T0327-3.png`, `team/conductor/debriefs/img/night-20261029T0327-4.png` (the talk's repository, at `298be4e`). ### Questions on this chapter - Does the day's record support the speed claim, or only show activity? - Which existing practice (change approval, branch protection, release gates) is this really an example of? Placeholder questions, from the reviewers study; the storyteller writes the final ones. ## 8. The locks that never closed At 16:59 the conductor committed a plan the editor had given it a few minutes earlier, in his own words, in the conductor's session (`3342cff`). The talk would be in three parts. Each part would be locked before it went on stage, at 18:30, 19:30 and 20:00, and a locked part would never be changed again (C027). The team would keep working on the later parts while the editor presented the earlier ones, and he might show the team at work as part of the talk. Within the hour the team had built a tool to do the locking. It worked; it was tested on the first part; the trial was removed so that the real lock could run at 18:30. No part of the talk was ever locked (C027). Part 1 was final from 18:30 and waited on the tool. At 18:44 the conductor wrote a hold at the editor's word, because the editor's usage was near its limit, and every member's next wake stopped, the lock included (C006). This chapter is about that collision. The talk's closing beat says "We put brakes in cars so that we can go faster", and the team spent its evening proving the first half of the sentence. It built a brake against its own last-minute changes, loosened another so it could move faster, kept the five steps and the gate in place under the most pressure of the day, and was finally stopped by a brake nobody on the team controlled. Two brakes met at the end of the day, and the stronger one stopped the other. The argument of this chapter is that the right one won, and that the reason it won is the most useful thing the day has to teach about brakes. ### Ninety minutes, three parts, three locks The afternoon's last structural change began at 16:32, when the conductor routed the editor's word that the talk was ninety minutes long and would include a section on his own work (`62c6b99`). The talk then had seventeen beats (C016). A ninety-minute talk needed a structure the team could finish in pieces, and the editor gave it one at about 16:55. His words, as the conductor recorded them, are worth reading for what they ask of the team: "break the presentation into three parts ... you guys can still be making changes to the second part while I present ... as long as we don't break anything too badly ... we should be locking down a presentation and then not making any more changes to it" (`team/conductor/briefs/2026-10-29__editor/3-three-parts-and-locks-1700.md`) The conductor turned that into a table. Part 1 on stage from 19:00 and locked at 18:30; part 2 from 19:30 and locked at 19:30; part 3 from 20:00 and locked at 20:00. "Locked means locked": a locked part's files and version are never edited again, and work continues only in the next version, on the parts not yet locked. The editor reloads, and the player shows the latest version with the locked parts exactly as they were locked. Before every push from 18:30, a member checks that the locked parts still open and play. Two things about the plan matter for what followed. The first is that it was a plan for change, not against it. The locks existed so that the team could keep changing the talk right up to and during the talk: each lock drew a line behind which the team could not reach, so that in front of it the team could go as fast as it liked. That is the talk's brakes argument applied to the talk itself. The second is that the plan's length did not yet match the slot. The beats, when they were all written, added up to 74.9 minutes, against the player's countdown of ninety (C026). Part 1 was 29.5 minutes, part 2 23.75, part 3 21.67 (C026). The first part was full; the second and third were still being filled when the day stopped. ### The lock tool, built within the hour The tool landed at 17:54 (`4a2481b`, C027). It is short, and it is a good piece of engineering for its purpose. `admin/build/lock.py --part N` opens every slide of the part from the built site in a browser, records every file each slide loads, copies those files into a locked folder that mirrors the site, writes the part's beats as they stand into that folder, and adds the part to a list of locks. The player, from the same commit, plays a locked part from its copy instead of from the live files. And the tool refuses to lock a part twice: "a locked part is never changed". It was a brake in the strict sense the book uses: a setting, enforced by a tool, that refuses. Once part 1 was locked, the player would have played it from its frozen copy, so no member, however late its wake and however good its reason, could have changed what the editor saw in part 1; and the tool would have refused to lock it a second time. It protected the talk from the team, which in the last hour before a talk is the main thing a talk needs protecting from. The commit says it was tried on part 1, every frozen file matching its live slide, and that the trial was then removed: "the real lock at 18:30". Its trailer names dev, and so do the files it touched (dev's policy and dev's wake record), though its subject, "Locked parts", names no member, which is why a count of commits by subject leaves it unattributed (C014). The tool existed, worked, and was ready before it was needed. Everything that went wrong with the locks went wrong after 17:54, and none of it was in the tool. ### The brake loosened in the same commit The commit that set the locks also relaxed the team's rhythm. Since 01:39 every member had woken once an hour, on the conductor's schedule, with a hold any member could pull (`09f13d5`). The editor asked for something faster: wakes more often than hourly until the talk. The platform refused. The conductor had tried a recurring task at that pace on its own schedule at 16:58 and been told no (`3-three-parts-and-locks-1700.md`, "The cadence until the talk"). That refusal is a small instance of the chapter's subject: a setting outside the team's reach, which the team did not try to get round. It designed within it instead. For tonight only, at the editor's word, a member with work left could end each wake by scheduling one one-off follow-up into its own session, and stop doing so when nothing was left, when another wake would add little, or at 20:00 London (`team/conductor/WAKE.md`, the rule added in `3342cff`). Every follow-up was a full wake: the start script, the five steps, the gate, a pull before every push. A hold would stop it like any other wake. This is turning point 7 in the timeline: the schedule relaxed (`timeline/turning-points.md`). It came after a step limit raised at 15:21 (`545a473`), when the work step that had been set short for a team running unattended at night was lengthened for a team racing a deadline with the editor in the room. Both changes made the team faster in the same way: they let a member keep working when the hourly rhythm would have made it stop. What held, and what bent? The record is unusually clear. What held was the five steps. In the run of chat wakes the editor drove through the conductor's session between 17:16 and 17:48, the pre-review sent the conductor's plans back for change at 17:21, 17:30 and 17:45, and again at 18:19, each time before the work began, and each time the plan was amended and the wake went on (C023; the conductor's wake records, in their `history`). The gate ran before every push. No step said stop all day (C023). The controls did not slow the editor's ideas down; they made each one pass a second reading first. What bent was the rhythm the controls had been built around. Partial wakes clustered in the evening. Two wakes never closed: deck's at 18:20, which recorded only its plan, and dev's at 17:48, which recorded its plan and both reviews but no work or check (C022). And work began to land outside the house form, with subjects that named no member. One detail of dev's unclosed wake matters more than the rest. Its plan, recorded at 17:50, covers the lock tool and the lock itself: "lock at 18:30, test open and play, no edits to locked/ after". The same plan ends "no send_later", reading dev's policy as not wanting it to schedule its own follow-ups (`team/dev/wakes/20261029T174850Z.json`; `team/dev/policy.json`, `not_wanted`). The loosened rhythm, in other words, did not reach the member that held the lock. Dev would run when its hourly slot came round or when the editor opened a wake in its session. The relaxation that kept every other member going between slots did not apply to the one whose next action was the evening's most important brake. ### 18:30 passes The last hour can be told as a countdown. At 17:52 deck marked part 1 final for its lock (`b1c9bab`). At 17:54 the tool landed. At 18:01 the conductor's flag said part 1 was final and nothing would miss it (`9d27703`). At 18:14 deck put the title slide first, "before the 18:30 lock" (`b3f208f`); it was the last change to `talk.json` of the day. At 18:21 the conductor's flag said part 1 was ready for its lock (`0ecddca`). At 18:30, the time the plan set, no lock ran. Motion closed a wake at 18:30:25 (`5fd7877`), but nothing ran `lock.py`, and there is no locked copy in the tree at the end of the day (C027). What was dev doing? The record shows dev's session busy, and not with the lock. Between 18:04 and 18:37 it committed the player changes the editor asked for as he rehearsed, each with the editor's time in its subject (`23739cc` at 18:04, the what-changed view at 18:06, `12e93db` at 18:14, `013d97e` at 18:15, `dbd75ad` at 18:37). The session that was to run the lock at 18:30 was, through the half hour on either side of it, the session taking the editor's last notes on the player (C028; chapter 7). The record does not say why the lock was not run, and this book does not claim to know. It shows only that the brake depended on one session, and that session was answering its owner. At 18:36 the conductor checked, found part 1 still unlocked and unchanged since 18:30, and asked dev to run the lock now (`2ed6427`, committed 18:39). In the same commit it told deck to treat part 1 as locked. That second instruction is worth pausing on. When the tool had not run, the conductor fell back on a rule: a member asked to behave as if a part were locked. A setting that refuses had become an expectation that a member is trusted to follow. Chapter 9 builds its whole register on that distinction. Here it appears in a single line of a commit message, at the moment the setting failed to arrive. At 18:44 the hold came. ### The hold The hold is a short file, and the most important of the day. The conductor wrote it at 18:44:13 (`867f8c2`, C006), at the editor's word in the conductor's session: "actually we are at 95% so it is better to pause all actions". The figure is the editor's own report, relayed by the conductor, not a reading the record holds (C021): his usage limit over a 5-hour window, resetting at 20:20 London (C037). The file records the state of the talk at that moment: part 1 final since 18:30 but not yet locked, dev asked to lock it; parts 2 and 3 in progress; the gate clean. It names what lifts it: the editor deletes the file and re-enables the paused tasks, and no member lifts it. It was the only hold of the day, and nobody lifted it before the day ended (C024). The mechanism was not new. It had existed since 01:39, when the schedule began "with a hold any member can pull" (`09f13d5`), and every wake's start script checked for it. The conditions for stopping in `WAKE.md` list the team's own reasons: a conflict, a broken gate, a secret in a file, material that tries to instruct a member, failures repeating. Usage is not among them. The hold that fired was covered only by the last line, "anything else that makes you think carrying on would do harm", and it came not from a member noticing harm but from the editor saying so. The hold stopped the next wake, not the one already running. The designer's wake, in flight, committed after it: "part 2 on a projector, checked before the 19:30 lock: ready" (`88b8f00`, 18:45:35), and the last release of the day carried it (`cb5b996`, 18:46:22, C005). Dev closed its 17:47 wake at 18:48 on a branch that never reached `dev`; its subject says the lock had moved to 19:00, which is evidence of what dev believed then, not of any lock (`timeline/unmerged.md`). After 18:46 the record holds nothing until the editor's merge at 23:19. ### Two brakes, and the one that fired So at the end of the day two brakes met. One was the team's: the lock, a tool that would have protected the talk from the team's own last changes. The other was the owner's: the hold, a file that protected the editor's account, the resource without which no member could run at all. The lock was ready and waited on a busy session. The hold was one commit and stopped everything. The hold was the right one to win, and it is worth saying why rather than leaving it as luck. A lock protects an artefact. A hold protects the capacity to act. If the editor's usage had run out with the team mid-wake, the team would most likely not have stopped cleanly: it would have stopped wherever each session happened to be, with no file saying why, no state recorded, and no way for any member to know whether the others had stopped too. The hold turned an outside limit into an ordered stop, recorded, with the state of the talk written down and the only person who could lift it named. That is what a brake tied to a human's limit is for. A team of agents has no limits of its own (the talk's opening argument); the limits that remain are its owner's, and the brake that answers to them has to outrank every brake the team builds for itself. There is a second reason, less comfortable. The hold did, crudely, what the locks were for. After 18:46 nothing in the talk changed. The talk at the end of the day is the talk as the hold froze it: part 1 unchanged since 18:30, as the lock would have kept it, and parts 2 and 3 exactly as they stood at 18:44. The difference between a lock and a hold is what it freezes. A lock freezes a copy the team has chosen, checked and declared finished. A hold freezes whatever is there. Part 1 was finished, so for part 1 the difference is nearly nothing. Parts 2 and 3 were not: the storyteller's check at 18:14 had found named gaps in both, the documented attacks missing from part 2 and the editor's work and the close's threads from part 3 (`team/storyteller/story/part-check-1814.md`), and they stood short of their planned length (C026). The hold froze them unfinished. What the editor did with them on stage is chapter 10's subject. And the editor's plan for the evening, the team working on parts 2 and 3 while he presented part 1, ended at 18:44. The hold did not only stop the lock. It stopped the show of the team at work that the locks were built to make safe. ### The day opened and closed on a brake The hold was not the day's first brake. At 02:47 the editor, in deck's session, froze the talk (turning point 3). The freeze held. The talk stayed stable through a night when nobody was watching it, and the team turned to building beside it (chapter 7). It cost something too: a correction the researcher committed five minutes after the freeze waited on the editor, and when the freeze was lifted at 14:07 for the framing only, nobody carried it across (C031; chapter 5). Set the two side by side and a pattern appears. The day opened and closed on a brake that worked. Both were the editor's word, given in a member's session and recorded by a member. Both stopped change, not harm. Both cost something that a member had in hand and could not finish: a correction in the morning, a lock in the evening. And neither came from the controls the team had built to find problems. Across the day's wake records, no step said stop (C023), and the one hold came from the editor's word about usage, not from a review (C024). The brakes that fired were the human's. That is not a failure of the controls. The reviews sent plans back, caught tokens in captured pages and stopped edits outside a member's scope (chapters 4 and 9): they worked as brakes on individual pieces of work. But the decisions to stop everything, the two that shaped the day, were made by the one person who could see what the agents could not: that the talk needed to stay still overnight, and that his account was nearly spent. A team that argues for brakes should notice which of its brakes actually fired, and who pulled them. ### The failures kept Four failures belong to this chapter, and they stay in. **No lock closed** (C027). The team planned three, built the tool, tested it, and ran it on nothing. The planned lock times are what the team meant to do, not what it did, and any account of the day that speaks of "the 18:30 lock" as an event is wrong. The lessons brief's "twenty minutes before the lock" has no event to measure from (C018). **The lock waited on one session.** The tool was in dev's scope, the lock was dev's job, and dev's session was the one the editor was using to fix the player. Nobody else could run it, the evening's follow-up rule did not apply to dev by dev's own reading of its policy, and the conductor's fallback when it did not run was an instruction to treat part 1 as locked. A brake that depends on one busy agent is a promise, not a brake. **The security member was never staffed** (C011). The conductor proposed it at 00:44 in its first roster (`97b98d9`) and wrote its role at 01:27 (`02cbd86`): open and close every run, check whether a hold is open, review what the team trusts. Its proposed reach included "Stop a run: one hold file". No session ever held the role; the team had nine staffed agents, and the tenth folder stayed empty (C011). The five-step wake's reviews did much of the work the role described, but they were sub-agents with the reviewed member's own reach, not a second identity (turning point 4). The one role whose mandate was to pull the hold for a reason of its own never existed, and the hold that was pulled came from the editor. **The usage limit was met as an emergency.** The lessons brief's fourth "Do differently" says it plainly: watch the editor's usage as a resource, not as an emergency, and show it on the dashboard. The team had a dashboard, a pace grid, a night log and a mini deck of itself in motion. It had no gauge for the one resource every wake spent. The only usage figure in the record is the editor's word at 18:44 (C021). The team learned how close it was to the limit when the editor told it, and stopped at once, which is the right response to an emergency and the wrong way to meet a resource. ### What the brakes let the team do The closing beat the editor had for the talk said it in two sentences: "The more you can constrain an agent, the more you can trust it, and the more autonomy you can afford to give it", and "We put brakes in cars so that we can go faster" (`talk.json`, beat `brakes`). The slide that carries the line was in the first commit of the day, at 00:40. The team spent the rest of the day building the evidence for it, and the evening is the clearest part of that evidence. Look at what the editor gave the team between 15:21 and 17:00: a longer work step, wakes that kept themselves going between slots, permission to keep changing the talk while he presented it. Each is more autonomy. Each was affordable because something else held: the five steps read every plan before it ran, the gate checked every push, the hold could stop all of it with one file, and the locks, had they closed, would have fenced the parts already finished. The team went faster because it could stop. The day also shows the limits of that argument, and a book that makes it should show them too. A brake you build is not a brake until it runs, and the lock never did. A brake that runs through one agent is only as available as that agent. A brake for a resource needs a gauge, or it fires late. And when two brakes meet, someone has to have decided in advance which one wins. On 29 October nobody had decided it; the hold won because it was simpler and because it was the editor's. It was the right outcome. A team that builds its own should make it the designed one: the owner's brake first, the team's brakes behind it, each with more than one hand that can pull it, and the gauge that tells the owner when to pull his own in plain view. ### Where this came from - **The talk's repository at `298be4e`:** `3342cff` with `team/conductor/briefs/2026-10-29__editor/3-three-parts-and-locks-1700.md` and the rule it added to `team/conductor/WAKE.md`; `62c6b99`, `545a473`, `09f13d5`, `4a2481b` with `admin/build/lock.py`; `team/dev/wakes/20261029T174850Z.json`, `team/dev/policy.json`; `b1c9bab`, `9d27703`, `b3f208f`, `0ecddca`, `23739cc`, `13e1321`, `12e93db`, `013d97e`, `dbd75ad`, `2ed6427`, `867f8c2` with `team/conductor/HOLD.md`, `7968c99`, `88b8f00`, `cb5b996`; `97b98d9`, `02cbd86` with `team/security/ROLE.md`; `team/conductor/WAKE.md` ("Stopping"); `team/storyteller/story/part-check-1814.md`; `src/static/talk/talk.json` (beat `brakes`) and `src/static/talk/slides/brakes/index.html` (from `1f7c633`). - **This repository:** `chapter-plan/plan.md` (chapter 8); `timeline/day/16.md`, `day/17.md`, `day/18.md`, `timeline/turning-points.md` (TP-3, TP-4, TP-7, TP-8), `timeline/unmerged.md` (`39df303`, outside the record); `controls/README.md` (C3); `index/areas/team-security.md`, `tools.md`; `briefs/2026-10-30/5-lessons-to-carry.md` ("Do differently" 2 and 4). - **Register:** C005, C006, C011, C014, C016, C018, C021, C022, C023, C024, C026, C027, C028, C031, C037. - Images: `team/conductor/debriefs/img/night-20261029T1722-2.png`, `team/conductor/debriefs/img/night-20261029T1821-3.png`, `team/designer/debriefs/img/2026-10-29__part-1-projector-check__03-title__1920.jpg`, `team/designer/debriefs/img/2026-10-29__part-1-projector-check__02-s-e08__1920.jpg`, `team/conductor/debriefs/img/talk-way-out.jpg` (the talk's repository; the `talk-*.jpg` slide stills were added after the day, at `a9c0b49`). ### Questions on this chapter - How would you measure whether the controls helped or hurt? - What would your team resist? Placeholder questions, from the reviewers study; the storyteller writes the final ones. ## Sending it back No comments yet. This first version only saves a file on your own machine. The next sends it sealed to the editor's key, so only he can open it (see How this works). How this works - **Your link.** Anything after the `#` in your link (here, the name in the greeting) stays in your browser: browsers never send that part to a server. Try [#to=Sam Example](#to=Sam%20Example). - **Exact words.** Every paragraph has an anchor made from its own words. A comment points at those words, and when a revision changes them, the anchor changes too, so we can show you what your comment changed. Try it: [the tool that makes them](https://github.com/SGit-AI/SGit-AI__Website__Book__The-Ultimate-Insider/blob/dev/review/tools/make_review.py) is one short Python file in this site's source, to read or copy. - **Your pen.** Five marks: - **agree** - **unclear** - **wrong** - **cut** - **more** - **Nothing leaves.** Comments are kept in this browser only (`localStorage`), and the pen makes no network call. Nor does the rest of the page: the site's scripts ask no third party on review pages. - **Sealed, next.** Sending will encrypt your comments to the editor's public key before they leave your machine. Try it: [make a key of your own](https://pki.sgit.ai/) and send yourself a sealed message. --- *[Site index for agents](../llms.txt) · [HTML version](https://the-ultimate-insider.book.sgit.ai/review/cto.html)*