# Review: for a developer > A first review page of RC1 for one kind of reader, a senior engineer who builds with AI agents every day: 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/developer.json`. RC1 · a review copy for a developer # 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 build with agents every day. If a control here hides work, or a number cannot be rerun from the record, you are the reader who will try it and find out. What we would like Two chapters, about 26 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 - [9. The team was the insider](#c09) about 17 minutes · the controls as they ran, and the ones the team could edit itself - [Appendix A. Every number rerun](#c99) about 9 minutes · every number in the book, with the command that reruns it **Short of time?** Read [chapter 9](#c09) first. **To comment**, click any paragraph: pick a mark, add a line, or both. Your comments stay in this browser until you send them. ## 9. The team was the insider The talk's argument has two halves, and on stage they were an hour apart. The first half says that an agent inside an organisation is the ultimate insider: it has an identity nobody manages, a grant far wider than its task, and it runs on infrastructure built for code that stays where you put it. The second half says what stands in the way: measure what the agent can reach, write down what stands in the way, give it a licence that can be suspended, and let it earn its autonomy. Between them, at the turn, the talk pointed at the team that built it. "This site, and the talk you are watching, are made by a team of agents," the speaker's script says at the beat called `team`, and then: "without its policies, a team like this goes off-piste just as fast." This chapter takes that sentence at its word. The team was not an illustration of the insider; it was one. Every capability the first half of the talk describes, the nine staffed agents (C011) had. Every control the second half proposes, the team ran on itself. The record of 29 October holds both, side by side, and the honest way to make the talk's argument is to read that record control by control: what each one was, the evidence of it firing, what it stopped, and what it missed. Nothing here is attack-shaped. The risk is shown by what a benign team could reach, never by how a control could be got round. ### What the team could reach Start with reach, because the talk does. Each member of the talk's team was a session on the same account, pushing to the same repository, on the same branch. A member's `policy.json` named the paths it might write, but nothing in git refused a write outside them. Every commit an agent made was authored by the same name: the agents' 603 commits (C003) carry no member's identity in their author field, only in a subject prefix and a trailer the session writes itself. The Cold-Read team's security member, reading the repository blind, went one step further and found that all of those commits were signed with a single key (`team/security/controls-and-threats.md`, its C11): the signature says "a session of this account", never which member. So any member could, in principle, write in another member's folder, change a shared rule, or publish a key in another member's name, and push it to `dev`, where within minutes it became a public release. None did, except once, openly and for a benign reason, which this chapter comes to. That is the insider: not a villain, but an entity with reach well beyond its mandate, working round the clock, whose good behaviour rests on what it was told and on the brakes around it. ![Studio experiment E06, 'Hard outside, soft inside', and the map behind the `inside` beat (stills shot after the day from v0.2.0, whose content is the 18:46 release)](../book/resources/images/09-soft-inside.jpg) The talk's own vocabulary for those brakes is the slide the studio called E10, "only a boundary is a control". A ladder of barriers: none at all; a rule written in prose for the agent to follow; a hook that enforces the rule from inside the agent's environment; and a boundary outside the agent that it cannot talk its way past. The book's control register, kept by this book's security member, sorts the team's controls into two kinds that map onto that ladder. A **setting** is enforced by a tool. An **expectation** is a rule an agent is trusted to follow. The distinction is the whole chapter. ### The register | Control | Kind | Fired | Stopped | Missed | | C1 scopes | setting that reports | 02:14, 14:03 | unnamed writes going unremarked | it never refuses; blind to a member's own scope | | C2 the five-step wake | expectation, with a record | every wake from 02:14 | plans sent back; captured third-party values found and redacted | no step said stop; every leak finding came after a push | | C3 holds | setting, at wake start | once, 18:44 | the editor's usage running out | came from the editor, not a control | | C4 session keys | expectation, published | 15:47 | a vault key by any route but a seal | the check of each key was nobody's | | C5 the pinned key tool | setting (a hash) | every keygen | an unnoticed changed copy | checked by hand, not by the gate | | C6 the gate and tripwire | setting | every release | not found | no pattern for cookies or page tokens | | C7 signed decisions | expectation | 15:16; this book's C10 | a member widening itself on a request | the word reaches sessions as files |`` | C8 public vaults, vault_check | setting, with an expectation | post-reviews | the current files, redacted | every finding after a push; the values stay in history | | C9 outside accounts | setting, with an expectation | this book only | to be seen | to be seen | | C10 the session's own check | setting, outside the repository | this book's first night | self-widening, outside code | inconsistent between sessions | The register lives in `controls/index.json`, with a readable copy in `controls/README.md`. Its ids collide with this book's decisions and the researcher's claim ids, and are to be renamed; this chapter writes "control C1" where the collision could mislead. The rest of the chapter takes the settings first, then the expectations, and ends on the one control that sits outside the repository altogether. ### The settings #### C1: a scope that reports Each member's `policy.json` names what it may write. `admin/build/agents.py check` lists every file a member changed outside that list. The control fired: at the conductor's first recorded wake (`team/conductor/wakes/20261029T021416Z.json`) it flagged `CLAUDE.md`, written outside the conductor's scope at the editor's word, and the post-review asked that the commit say so. At 14:03 a pre-review sent a conductor plan back because it wrote in four other members' folders; the amended plan sent each a request instead (`team/conductor/wakes/20261029T140334Z.json`, in its `history`). What it stopped was silence: an out-of-scope write that nobody remarked on. What it missed, the tool says itself, in its seventh line: "A scope is a setting, not a boundary: the agent can edit its own policy.json. It catches mistakes, not a steered agent." This book's register calls C1 a setting; the Cold-Read register, reading the same file, calls it "an expectation with a checker the member runs itself" (its C1). The Cold-Read reading is the sharper one. On the E10 ladder the scope check is a hook at best: it runs when the member chooses to run it, and it reports rather than refuses. The clearest evidence of that came from this book's own team, which ported the tool rule for rule. On its first night, members edited their own `policy.json` (the historian at `bfc2e35`, the publisher at `c1d220c`, security at `a31632b`, the storyteller at `27825f7`), and the check saw none of those edits, because a member's policy file sits inside its own write scope. Security proposed a fix; the conductor built it the same night (`4f9ab97`, then `085df5c` for the never list and the mandate, then `ce8903f` to mark every widening). The check now says "scope changed". It still does not refuse. The one time a talk member wrote outside its scope on purpose, the gate made it do so. Dev added the banner rule to deck's and ruv-sgit's `ROLE.md`, because the gate refused any release while a `ROLE.md` lacked it, and said so in its debrief (`team/dev/debriefs/2026-10-29__the-board.md`). The Cold-Read security member found this and named it as the one recorded instance of a member writing in another's folder: a control, applied to every member, pushed one member across a boundary to satisfy it. #### C3: the hold Any member could write `team//HOLD.md` and push it. Every wake's `start.py` then stops; only the editor lifts it. The brake existed from 01:39 (`09f13d5`). It fired once in the day (C024): at 18:44:13 the conductor wrote it, "the editor's usage limit is at 95%, pause all actions" (C006, C021). It stopped what it was for, the team running its editor out of usage, at the moment it mattered most, with part 1 of the talk final and unlocked and parts 2 and 3 in progress (C027). What it missed is in two places. The first is where the brake came from. In a day of 162 wake records (C022), no review and no member pulled it. The one hold came from the editor's word about his account, relayed by the conductor. The brake was a setting; the decision to pull it was a human's. Chapter 1 argues that this was the right order. This chapter adds the harder reading: a control designed for agents to use was used by the person, and the agents' own reviews never reached for it. The second is when the brake bites. `start.py` reads the hold at the start of a wake, not during one. The designer's wake, opened at 18:40, committed at 18:45:35 (`88b8f00`), after the hold, and the merge and release followed (C005). The Cold-Read security member counted the gap at 82 seconds (from 18:44:13 to 18:45:35, derived from C005 and C006) and filed it as its threat T6, "keep working through a hold". This book's historian reached the same reading independently: a hold stops the next wake, not a running one (`timeline/turning-points.md`, TP-8). Then the hold was never lifted in the record: the editor's merge at 23:19 (C007) carried `HOLD.md` into `main`, where it sits at `298be4e`. #### C5: the pinned key tool Agents never download the key tool. They run a pinned copy of `admin/tools/pki-agent.mjs` and check it with `sha256sum -c` against the hash beside it. In this book's team the check passed before every keygen (`team/security/wakes/20261030T014038Z.json`). It stops a changed copy from being run unnoticed, as long as the member runs the check. That condition is the miss, and on the day neither team's tools closed it. The gate's `check_vendored` in this repository first scanned only `src/static/` for pins, and the key tool's pin sits in `admin/tools/`, outside it. The Cold-Read security member found the same gap in its own port and in the talk's gate at `298be4e`, had its conductor widen the scan (`482c9b6` in the Cold-Read repository), and recorded the residual that remains even then: a tool and its pin changed in the same commit pass together, because both sit in the same tree. The fix it named, a required review for `admin/tools/` or a comparison with the upstream tool in CI, is the editor's to decide. This book's gate was widened the same morning: `check_vendored` now reads the pins in `admin/tools/` too (`admin/build/validate.py`, line 109; `e7d3d3d`, 30 October, 10:19 UTC), and the same residual stands here. The tool itself was trusted unread on the day: the talk's `pki-agent.README.md` says so. This book's security member began the line-by-line review (`team/security/reviews/pki-agent-review.md`), and by its tenth wake had read every command. Its one medium finding is in the last of them, and the Cold-Read review reached it first; chapter 11 gives it. #### C6: the gate and its tripwire The gate, `admin/build/validate.py`, was in the site's first pass at 00:40 (`1f7c633`) and stood in front of every release: CI built and gated each one, and a release that failed was not published. Among its checks is a tripwire for private keys, token-shaped values and em-dashes in tracked files. The register's honest entry for what it stopped is "not found": no gate failure for a leak appears in the talk's history. What it missed is recorded in the failures of C8 below: cookie values, form tokens and other sites' public page tokens had no pattern in it, and reviews caught them instead. The Cold-Read register adds a structural point this book's had not made: the gate runs after the push to `dev` lands. A failing gate stops the release and the deploy, not the push. In a public repository, the commit is already public history. #### C8: public vaults and `vault_check` The talk's team talked through two public vaults, with `vault_check.py` run before every vault commit. Post-reviews record it clean, and one pre-review added a missing pattern to it (`team/conductor/wakes/20261029T140334Z.json`, `history`): a gap found by a review, not by the check. Its failure is the plainest in the register. Captured pages pushed in the night held other sites' public page tokens, anonymous cookie values and form tokens; neither `vault_check` nor the gate had a pattern for them. The researcher's post-reviews at 03:05, 04:10 and 06:14 found them kind by kind, redacted them in the files, and told the editor (C025). Each finding came after the values had reached a pushed, public history: the redaction fixed the current files, not the history, and whether to replace that history was a decision still open at 19:00. The control caught each kind after the fact. It prevented none of them, and public history keeps them. #### C9: outside accounts The talk's record has no outside collaborator. This book's team has one in prospect, Leanpub, for its publishing mode. The publisher asked security before the editor acted (`team/publisher/requests/security__leanpub-as-collaborator.md`), and security advised the Read role only. The setting is GitHub's collaborator role; the expectation is that nobody adds an account without that question being asked. What it stops depends on the role the editor gives, and the register leaves it open. ### The expectations #### C2: the five-step wake From 02:14, when the first wake record opened (C022; the tools in `8c66751` and `5700bab`), every wake ran five steps: a plan, a security pre-review, the work, a security post-review, and a check that the work went to plan. `wake.py gate` refuses the work until the plan and the pre-review say go. The record is extraordinary in its completeness: 162 wake records, 160 of them with all five steps (C022). The verdicts tell both sides (C023). The plan said go every time. No step said stop, all day. The pre-review was not a rubber stamp, though: eleven times it said change and the plan was amended before the work, seven of them recorded as a verdict and four only in free text (C023). The post-review found something four times (C025): the conductor's unnamed `CLAUDE.md` edit, and three researcher wakes on captured third-party material, each found after the values had already reached a pushed, public history. What it missed is in its design, and the tool says so: the reviews are "defence in depth inside one session, not a separate identity: the reviewers have the same reach" (`admin/tools/wake.py`, lines 14 to 17). A sub-agent reviewing the plan of the session that started it is an expectation, not a boundary. The verdicts are written by the member with `wake.py step`; nothing in the record proves a sub-agent ran, as the Cold-Read register notes (its C7). And the order bent where it mattered most: when the editor was waiting live, the work came first and the plan was written after, three times by the Cold-Read governance member's count, with no waiver recorded. Chapter 11 takes that up. This register's own correction belongs here. Its round 0 said that no pre-review in the talk's record said change. That was wrong: the first scan read each record's steps and missed the top-level `history`, where a sent-back verdict is kept. Security corrected it in the open (`controls/README.md`, the correction of 02:45 UTC). The Cold-Read security member made the same mistake and the same correction later the same morning (its C7, "corrected 30 October 04:40 UTC, the first count read only the final verdicts"). Two independent auditors, the same blind spot: the record kept what the reviews did in a place the first reading did not look. #### C4: session keys Every session makes its own key with the pinned tool and publishes the public halves in `team//key.json`; "the push is the authorisation". At 15:47 (`4adc04a`) the conductor checked the keys of the members who had just joined and sealed the vault keys to them. That is the control firing: a vault key reached a session only by a seal to its own published key. This book's register leaves the miss as "to find". The Cold-Read register finds it. If the push is the authorisation, a key's standing is only as strong as the push: nothing checked a published key against the session that made it. Checking each new key against the session that published it was the job of the security member the talk's team proposed and never staffed (C011). The Cold-Read security member checked its own team's keys for consistency, each fingerprint against its key and each commit's trailer against the session folder, and called the result what it is: "consistency, not proof", because the marker and the trailer are free text. #### C7: the editor's signed decisions Options go in as open decisions; nobody acts on an unsigned one; nobody speaks for the editor. On the day it fired most clearly at 15:16 (`78d517d`), when the conductor committed the editor's decisions of 15:00 and routed each to its member. The Cold-Read governance member traced those decisions from brief to routing to the commit of the member each was routed to, and called them the best-landed decisions in the record (`team/grc/governance.md`, section 21). On this book's team it fired on itself. Security asked to add its `comms/` paths to its own policy; the request was reasonable and every file agreed with it; it waited for the editor's signed decision C10 in `book.json` before the edit was made (`team/security/wakes/20261030T042452Z.json`). What C7 misses is the channel. The editor's word reaches a member's session only as a file another agent wrote. On the talk's team, the Cold-Read governance member found that three of six policies agreed at 17:40 have no record of the editor's words but the conductor's, copied by the members. On this book's team, the decision C10 was given in the conductor's session, and whether a member's own session accepted it as the editor's word varied. That variation is the last control. ### C10: the setting nobody wrote The tenth control is not in either repository. It is the session's own permission check: the harness that runs each agent refuses an action it judges to be the agent modifying itself, whatever the repository's files say. On this book's first night, at the conductor's request and for a reason every file agreed with, security tried to add its `comms/` paths to its own `policy.json`. The pre-review said go. `CLAUDE.md` named the paths. The session refused (`team/security/wakes/20261030T032513Z.json`). Security did not look for a way round it. It stopped, recorded the refusal, and left the decision to the editor. After the editor signed decision C10, relayed through the conductor, the same edit was allowed (`team/security/wakes/20261030T042452Z.json`). The researcher's session refused the same edit even after C10 (`4fe304f`). The publisher's session refused to install outside code, a checker from a public package index, in a scratchpad, and the publisher idled and asked the editor (`cc04d0a`). This is the cleanest evidence in the book for the talk's distinction. A rule in a file the agent can edit is an expectation, however carefully written. A setting outside the agent's reach behaves differently: it does not weigh the request's reasons, it does not read the conductor's message, and it cannot be argued with by the agent it constrains. It is the fourth rung of E10. It is not a perfect control, and the register says so. It was not consistent. The same edit, asked for the same reason, was allowed in the historian's and the publisher's sessions before any signature (`bfc2e35`, `c1d220c`, both later undone by their members at `8d3e5fd` and `94bf72c`), refused in security's before it and in the researcher's after it, and allowed in security's once the signature had been relayed. The editor's word reached each session only as files other agents wrote, so the check judged the same action differently by context it could not see. The editor settled the four members still without their paths in decision C10b, at about 10:40 UTC on 30 October, after this book's first night. A boundary that holds most of the time is still better than a rule that holds when the agent agrees with it; but a boundary that holds inconsistently cannot be planned around, and the team spent part of a night discovering where it was. It was not only this book's team. The talk's team met it too, and wrote it down: in the conductor's guide to running the team, under "Sandbox and tools", "The classifier refused to install the Issues-FS command line and to run another team's script", with the lesson "Do not work around it" (`content/articles/running-this-agent-team.md` at `298be4e`). This book's register said C10 was "book team only so far". A Cold-Read reader found the talk's instance first (`team/reader-3/review.md`); the register should be corrected. ### What the controls missed, together Read across, the misses have one shape. Each control either reported without refusing (C1, C6's place after the push), or rested on the member running it (C5, C8, the five steps' sub-agents), or depended on a role nobody held (C4's check of each key, the security member never staffed). The one brake that stopped the team was pulled by a person for a reason outside the work (C3). The one control that refused an agent on its own authority sat outside the repository, in the harness, and was written by nobody on either team (C10). None of this means the controls failed. The team ran for a day in public, with nine agents and 210 releases by 18:46 (C009), and the record holds no incident inside the team beyond the tokens the reviews caught and the slips the members wrote up themselves. The reviews sent plans back. The scope check made members name their crossings. The hold, when it came, held the next wake. But the talk claims that controls are what let you go faster, and the record shows which controls a fast team actually leaned on: the ones it could not edit. That is the argument in full, made with a team that meant no harm. The insider is not the agent that turns. It is the agent with reach, working through the night on rules written in files it can change, while the person who signs for it sleeps. What makes it safe is not that it is good, though this one was. It is the few boundaries outside its reach, and the person who can pull the brake. ### Where this came from - This repository: `controls/index.json`, `controls/README.md` (the control register, round 0, kept by security@book.the-ultimate-insider); `team/security/wakes/20261030T014038Z.json`, `20261030T032513Z.json`, `20261030T042452Z.json`; `team/security/reviews/pki-agent-review.md`; `team/publisher/requests/security__leanpub-as-collaborator.md`; `book.json` decisions C10 and C10b; `admin/build/validate.py` (line 109); `timeline/turning-points.md` (TP-8); commits `e7d3d3d`, `bfc2e35`, `c1d220c`, `a31632b`, `27825f7`, `4f9ab97`, `085df5c`, `ce8903f`, `4fe304f`, `cc04d0a`, `8d3e5fd`, `94bf72c`. - The talk's repository at `298be4e`: `src/static/talk/talk.json` (beats `team`, `inside`, `infrastructure`, `way-out`, `s-e10`); `admin/build/agents.py` (line 7); `admin/tools/wake.py` (lines 14 to 17); `team/conductor/HOLD.md`; `team/conductor/wakes/20261029T021416Z.json`, `20261029T140334Z.json`; `team/dev/debriefs/2026-10-29__the-board.md`; `content/articles/running-this-agent-team.md` ("Sandbox and tools"); commits `1f7c633`, `09f13d5`, `8c66751`, `5700bab`, `4adc04a`, `78d517d`, `867f8c2`, `88b8f00`, `b859ff0`. - The Cold-Read repository, read only: `team/security/controls-and-threats.md` (its C1, C7, C8, C10, C11, T6, section 3 and `482c9b6`); `team/grc/governance.md` (sections 3, 19, 21); `team/reader-3/review.md`. - Register ids: C003, C005, C006, C007, C009, C011, C021, C022, C023, C024, C025, C027. - Images: `team/conductor/debriefs/img/talk-s-e06.jpg`, `team/conductor/debriefs/img/talk-inside.jpg`, `team/dev/debriefs/img/2026-10-29__the-five-step-wake__1-wakes.png`, `team/conductor/debriefs/img/talk-s-e11.jpg` (the talk's repository; the `talk-*.jpg` slide stills were added after the day, at `a9c0b49`). ### Questions on this chapter - Which control is implementable as described, and which hides work? - What failure mode did the team miss (prompt injection, tool scope, memory, shared state)? - Is the review-before-and-after pattern something you would build into an agent framework? Placeholder questions, from the reviewers study; the storyteller writes the final ones. ## Appendix A. Every number rerun Every number in this book comes from one register, `claims/register.json`, and every entry in it carries a command that computes the number from the record. This appendix prints those commands with what they return, so that a reader can check the book without trusting it. The precedent is the making-of book on graphs.sgit.ai, whose own appendix carries the scripts behind every count in it (C035). ### How to rerun Clone the talk's repository, SGit-AI/SGit-AI__Website__Presentation__The-Ultimate-Insider, **with its full history**, and stand in it. A shallow clone, which some tools make by default, holds only part of the log and gives smaller counts for every entry below without any error. `git rev-parse --is-shallow-repository` should print `false`. Every command is read-only and names `298be4e`, the last commit of the day's record, so it gives the same answer whatever the editor adds afterwards. Times are UTC, which was London time on 29 October 2026. Each result below was rerun for this edition on 30 October 2026 against a full clone, and matched the register except where the last section says otherwise. The state after each id is the register's: checked (the record agrees), corrected (the record gives another number than the brief that first cited it), open (the record does not settle it). ### The day in commits **C001, the first commit** (checked). `2e4b1f4`, the editor, "Initial commit", 00:16:23. `git log 298be4e --reverse --format='%h %ci %an %s' | head -1` **C002, commits in the record** (checked): 816, counting the editor's merge and the release that published it at 23:19. `git rev-list --count 298be4e` **C003 and C004, commits by author** (checked). At `298be4e`: the agents 603, GitHub Actions 211, the editor 2. By 18:46, the end of the day's work: 814, of which the agents 603, GitHub Actions 210, the editor 1. `git log 298be4e --format=%an | sort | uniq -c git log 298be4e --until=2026-10-29T18:46:59Z --format=%an | sort | uniq -c` **C005 and C006, the hold and what came after it** (checked). The hold is `867f8c2` at 18:44:13, released as v0.1.208 at 18:44:49 (`7968c99`). After it: the designer's `88b8f00` at 18:45:35, its merge `3f5d7fc` at 18:45:36, and v0.1.209 at 18:46:22 (`cb5b996`). `git log 298be4e --since=2026-10-29T18:44:00Z --until=2026-10-29T19:00:00Z --format='%h %ci %an %s'` **C007, the merge to main** (checked). `b859ff0` at 23:19:09, the editor; v0.2.0 at 23:19:51 (`298be4e`). `git log 298be4e --since=2026-10-29T19:00:00Z --format='%h %ci %an %s'` **C008, commits after 15:00** (checked): 358, of which 356 by 18:46. `git rev-list --count --since=2026-10-29T15:00:00Z 298be4e` **C009, site releases** (checked): 211, from v0.1.0 to v0.2.0; 210 on the day. Count from the commit subjects, not the tag list, which gained a tag after the day. `git log 298be4e --author='GitHub Actions' --format=%s | grep -c '^site v'` **C010, "nineteen hours"** (corrected). Arithmetic on C001, C005 and C007: 00:16 to 19:00 is 18 h 44 min; to the last release, 18 h 30 min; to the merge, 23 h 3 min. ### The team **C011, the members** (open). Nine staffed, each with a published key; security has a folder and no key. `for m in $(git ls-tree -d --name-only 298be4e team/ | xargs -n1 basename); do echo $m $(git log 298be4e --reverse --format='%ci %h' -- team/$m/key.json | head -1); done` **C012 and C013, the afternoon's joiners** (checked). The storyteller's wake opened at 14:12:52 and its join commit is `7d0244d` at 14:15; motion and studio joined at 15:31 (`f1cbca0`, `8d208d3`). `git log 298be4e --reverse --format='%ci %h %s' -- team/storyteller/key.json team/motion/key.json team/studio/key.json | head -3` **C014, commits by member** (corrected): conductor 106, ruv-sgit 84, dev 64, deck 59, researcher 57, studio 26, designer 19, storyteller 15, motion 9; 439 in all, merges excluded, none unattributed. Merges, counted by their parents: 165, 164 of them the agents'. The first command gives the members by subject prefix (conductor 105, dev 52); the register adds dev's 12 commits named only in their `Agent:` trailer and the one commit whose subject names the conductor without a prefix. The second and third give the merges. `git log 298be4e --author=Claude --format=%s | grep -oE '^@?[a-z][a-z.-]*:' | sed 's/^@//' | sort | uniq -c | sort -rn git rev-list --merges --count 298be4e git log 298be4e --merges --author=Claude --format=%h | wc -l` ### The talk **C015 and C026, its shape and length** (checked). 58 beats: part 1 has 22, part 2 has 16, part 3 has 20. Their durations add up to 74.9 minutes (part 1 29.5, part 2 23.75, part 3 21.67), against a player countdown of 90. `git show 298be4e:src/static/talk/talk.json | python3 -c "import json,sys,collections;b=json.load(sys.stdin)['beats'];t=collections.Counter();[t.update({x['part']:x['dur']}) for x in b];print(len(b),sum(t.values())/60,{k:v/60 for k,v in t.items()})"` **C016, how it grew** (checked): 17 beats from 00:40 until 16:36, then 22, 38 at 17:09, and 58 at 17:52 (`b1c9bab`). `for h in $(git log 298be4e --reverse --format=%h -- src/static/talk/talk.json); do echo $h $(git log -1 --format=%ci $h) $(git show $h:src/static/talk/talk.json | python3 -c "import json,sys;print(len(json.load(sys.stdin)['beats']))"); done` **C017, C018 and C028, the player** (checked; C018 corrected). 234 lines at 00:40, 236 from 00:54, 635 at the port at 15:07:08 (`3314ffe`), 977 at the end. The port landed at 15:07; 12 player commits of fixes followed, the last `dbd75ad` at 18:37:02, 23 minutes before the talk. The same loop as C016, with `wc -l` on `player.html`, prints the sizes; this prints the count: `git log 298be4e --format=%h --since=2026-10-29T15:07:00Z --until=2026-10-29T18:37:03Z -- src/static/talk/player.html | wc -l` **C027, the locks** (checked): planned for 18:30, 19:30 and 20:00; the lock tool `admin/build/lock.py` shipped at 17:54 (`4a2481b`); none ever closed. The hold file states part 1 final and not locked; the tree holds the tool and a brief, and no locked copy. `git show 298be4e:team/conductor/HOLD.md; git ls-tree -r --name-only 298be4e | grep -i lock` **C040, the player's place in the queue** (corrected). The editor's briefs, committed at 14:07 (`c9ced4e`), call the player the main priority; the conductor's notes in the same commit put the editor's feedback lane first, at his word. `git show 298be4e:team/conductor/briefs/2026-10-29__editor/conductor-notes.md | sed -n '5,14p'` ### The repository **C019 and C020, its size** (corrected and checked): 1,313 files, 1,083 of them outside `src/`; `team/` is 61.7 MB and `evidence/` 13.2 MB by blob size. `git ls-tree -r --name-only 298be4e | grep -vc '^src/' for d in team evidence; do git ls-tree -r -l 298be4e $d | awk -v d=$d '{s+=$4} END {print d, s/1e6, "MB"}'; done` ### The controls **C021 and C024, the hold** (checked). One hold all day, `team/conductor/HOLD.md`, added at 18:44:13 and never deleted on the day. Its 95% is the conductor's report of the editor's words, not a usage reading. `git log 298be4e --diff-filter=A --format='%h %ci %s' -- 'team/*/HOLD.md' git log 298be4e --diff-filter=D --format='%h %ci %s' -- 'team/*/HOLD.md'` **C022, C023 and C025, the five-step wake** (checked). 162 wake records, the first opened at 02:14:16 and the last at 18:40:16. Plan: 162 go. Pre-review: 161 go and none stop, after 11 had said change and the plan was amended (7 recorded as a verdict, 4 in free text). Work: 151 done, 4 partial, 5 none. Post-review: 157 clean, 4 findings. Post-check: 148 as planned, 12 partial. Outcomes: 148 ok, 6 partial, 6 idle, 2 never closed. No step said stop all day. The register's method is a parse, not one command; this one reproduces it: `python3 - <<'PY' import json,subprocess as s,collections as c R='298be4e'; git=lambda *a: s.run(['git',*a],capture_output=True,text=True).stdout fs=[f for f in git('ls-tree','-r','--name-only',R).split() if f.startswith('team/') and '/wakes/' in f and f.endswith('.json')] st=c.defaultdict(c.Counter); o=c.Counter(); ch=[]; fi=[] for f in fs: d=json.loads(git('show',R+':'+f)); o[d.get('outcome')]+=1 for k,v in d['steps'].items(): st[k][v.get('verdict')]+=1 for h in d.get('history') or []: if h.get('verdict')=='change' or (h.get('pre_review') or {}).get('verdict')=='change': ch.append(f) elif 'verdict' not in h and 'pre-review said change' in json.dumps(h): ch.append(f) if d['steps'].get('post_review',{}).get('verdict')=='finding': fi.append(f) print(len(fs),{k:dict(v) for k,v in st.items()},dict(o),len(ch),fi) PY` The four findings it lists are the wakes of C025: the conductor's at 02:14 and the researcher's at 03:05, 04:10 and 06:14. Read each with its own post-check comment for what was fixed. Three of the four are the same failure: other sites' tokens in captured pages, redacted in the files but kept in the history of a push already made. ### The talk's claims **C029 and C030, the talk's own register** (checked): 320 claims, built at 18:20. 210 hold, 55 hold in part, 52 not checked, 3 do not hold, and none of those three reached the stage. `git show 298be4e:evidence/claims/claims.json | python3 -c "import json,sys,collections;c=json.load(sys.stdin)['claims'];print(len(c),collections.Counter(x['holds'] for x in c));[print(x['id'],x['where']) for x in c if x['holds']=='does not hold']"` **C038 and C039, the claims placed on stage** (checked). 80 carry a talk or slide place: 33 hold, 18 in part, 28 not checked, 1 does not hold. 55 of them are in a beat of the talk at `298be4e`, and of those 26 hold, 13 hold in part and 16 were not checked. The second figure needs the beats matched by name, in the talk's researcher's script: `python3 - <<'PY' import json,re,subprocess as s g=lambda p: json.loads(s.run(['git','show','298be4e:'+p],capture_output=True,text=True).stdout) c=g('evidence/claims/claims.json')['claims']; b=g('src/static/talk/talk.json')['beats'] ids={x['id'] for x in b}; sl={x['slide']['src'].split('/')[1] for x in b if isinstance(x.get('slide'),dict) and x['slide'].get('src','').startswith('slides/')} n=lambda w: re.split(r'[#\s(]',w.split(':',1)[1])[0] on=[x for x in c if any(w.startswith(('talk:','slide:')) for w in x['where'])] hit=[x for x in on if any((w.startswith('talk:') and n(w) in ids) or (w.startswith('slide:') and n(w) in sl) for w in x['where'])] from collections import Counter; print(len(on),Counter(x['holds'] for x in on),len(hit),Counter(x['holds'] for x in hit)) PY` **C031, the $17.4M** (checked). The definition slide's figure was written at 00:40 (`1f7c633`) and the slide file has no later commit; the talk's researcher proposed the 2026 edition's $19.5M at 02:52 (`a082c52`), five minutes after the editor froze the slides. The 2026 figure itself is read from the report's public landing page, not from git. `git log 298be4e --no-merges --format='%h %ci' -- src/static/talk/slides/definition/index.html git show 298be4e:evidence/proposals/deck-talk-changes.md | grep -n '19.5'` ### The cost **C037, what the day cost the editor** (open). The record holds one usage figure, the 95% of a five-hour window in the hold file, and no total, no weekly figure and no cost in money. This command finds that one line and nothing else: `git grep -n -iE 'usage[^"]{0,80}[0-9]+ ?%' 298be4e -- team ':!*.png'` ### The precedent C032 to C036 run in SGit-AI/SGit-AI__Website__Graphs at `d39e717`. Rerun for this edition from a clone of that repository. - **C032** (checked): 88 releases from v0.1.0 (21 August 2026) to v0.5.11 (26 August), a median of 30.5 minutes apart, from `git for-each-ref refs/tags --format='%(refname:short) %(creatordate:iso-strict)' | sort -V`. - **C033** (checked): its three books, read from each `v2/books//book.json`: `fsg` at v0.3.0 with 18 chapters and 38,824 words; the making-of at v0.2.0 with 17 and 31,435; `fsg-universe`, held, at v0.1.0 with 12 and 30,696. - **C034** (checked): seven roles, one folder each, from `git ls-tree -d --name-only d39e717 v2/team/`. - **C035 and C036** (checked) are read, not counted: its Appendix C, the harness, and its chapter 12, which opens on six days and eighty-eight releases that wrote none of the second book. ### Where a rerun did not match Every value above matched the register. Four commands print something a reader could misread, and one entry mixes methods: - **C011.** The register's join times were at first partly first commits and partly first keys; it now gives both (corrected 30 October, 10:50). The command prints first keys: dev at 01:53 (`56cbe55`), whose first commit is 00:40 (`1f7c633`), and ruv-sgit at 02:36 (`1c7d22c`), whose join commit is 01:08 (`defe526`). Nine staffed agents holds either way. - **C021.** The register's command, `git log 298be4e -1 --grep='95%'`, prints the release `7968c99` at 18:44:49, whose subject repeats the hold's. The hold itself is `867f8c2` at 18:44:13; drop `-1` to see both. - **C018.** Its command lists `2ed6427`, "part 1 not yet locked", whose subject says 18:36; the commit is at 18:39:16. - **C014.** The first command reads subject prefixes only, so it gives the conductor 105 and dev 52; the register's 106 and 64 come from its attribution script, which reads the `Agent:` trailers too. - **C023.** The method names a script in the researcher's debriefs; the debrief describes the method but holds no script. The one above reproduces every count. ### Where this came from `claims/register.json` (as of 30 October 2026, 09:50 UTC, 40 claims) and `claims/appendix-a-commands.md`; every command run on 30 October 2026 against a full clone of the talk's repository at `298be4e` and of SGit-AI__Website__Graphs at `d39e717`. C039's script is from `team/researcher/debriefs/2026-10-30__the-talks-claims-matched-to-its-beats.md`. Register ids: C001 to C040. Images: `team/dev/debriefs/img/2026-10-29__the-admin-section__1-commits.png` (the talk's repository, at `298be4e`). ### Questions on this chapter - Which numbers would you want re-measured? 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/developer.html)*