agentbox-app 0.1.6 → 0.1.11

package/README.md

@@ -1,41 +1,49 @@
-# agentbox
+<p align="center">
+  <img src="docs/readme/icon.svg" alt="" width="96">
+</p>
 
-**An inbox for your coding agents.** You file the work, each item gets its own
-agent in its own thread, and they come back to you with a summary of what they
-did and what they need. You read, you approve or redirect, you move on.
+<h1 align="center">Agentbox</h1>
 
-Today the number of agents you can run is limited by how many windows you can
-keep track of at once. agentbox drops the chat window entirely and gives your
-agents an inbox instead, so you can run far more of them than you could ever
-watch and only deal with one when it actually needs you.
+<p align="center">
+  <strong>Give your agents an inbox.</strong><br>
+  Run dozens of coding agents at once and only hear from the ones that need you.
+</p>
 
-A macOS app. It runs on the Claude Code or Codex plan you already have, on your
-own machine. There is no server, no account to make, and no extra subscription.
+<p align="center">
+  <a href="#get-it">Get it</a> ·
+  <a href="#how-it-works">How it works</a> ·
+  <a href="#what-matters-most-goes-first">Priorities</a> ·
+  <a href="#built-for-the-keyboard">Keys</a> ·
+  <a href="#what-this-sends">Privacy</a> ·
+  <a href="LICENSE">GPL-3.0</a>
+</p>
 
-## How it works
+<p align="center">
+  <img src="docs/readme/inbox.webp" alt="Twelve agents finish their work and their rows arrive in the inbox, each one saying what it did and what it needs" width="100%">
+</p>
+
+<p align="center">
+  Free and open source. Runs in your browser or as a Mac app, on the Claude Code or Codex plan you already have.<br>
+  No server, no account, no extra subscription.
+</p>
+
+---
+
+## Install
 
-1. **File the work.** Paste a list, send over a board of issues, or type one
-   task. Twelve at once is a normal day.
-2. **Walk away.** Each item gets a headless agent in its own thread. Nothing
-   needs you while they run, so go and do something else.
-3. **Come back to an inbox.** Every thread opens with what the agent did and
-   what it wants from you, in two lines you can read at a glance.
-4. **Answer with one key.** Press `E` to approve and merge. Press `1`, `2` or
-   `3` to pick an option an agent offered. Type a sentence and send it back if
-   none of them is right.
-5. **Reach inbox zero.** The rows you approved are done. The ones you
-   redirected are already working again.
-
-The job this leaves you is reviewing what agents made and deciding whether it
-is good enough, rather than watching them make it. That is the whole argument
-for an inbox: a person in the loop where judgment is worth something, and
-nowhere else. An agent that got a failing test to pass by editing the test is
-exactly the moment you want to be asked.
-
-## Get it
-
-You need a Mac, Claude Code installed and signed in, and Node 22 to build.
-Codex is optional and is picked up when it is there.
+There are two ways to run it: in the browser, or as a Mac app. Both need Node 22 and Claude Code or Codex installed and signed in.
+
+**In your browser.** One command, nothing to install first:
+
+```
+npx agentbox-app
+```
+
+It starts on your machine and opens a tab. Nothing is hosted: it listens only
+on your own computer, and the address carries a key that is new every run. Add
+`--help` to see the options.
+
+**As a Mac app.** Build it from this repo:
 
 ```
 git clone https://github.com/savannahfeder/agentbox.git
@@ -44,22 +52,140 @@ npm install
 npm start
 ```
 
-`npm start` builds the renderer and launches the app. On first run it walks you
-through connecting Claude Code and choosing a folder to work in.
+`npm start` builds the app and opens it. On first run it walks you through
+connecting Claude Code or Codex and choosing a folder to work in.
+
+macOS may ask to let Terminal find devices on your local network. Agentbox
+does not need that, so Don't Allow is fine.
+
+## The chat window is the bottleneck
+
+Today you run agents in chat windows and terminals, and you wait for each one
+to finish before you prompt it again. So the number of agents you can run is limited 
+by the number of windows you can keep track of.
+
+<p align="center">
+  <img src="docs/readme/before.webp" alt="Five terminal windows, each with an agent waiting on a different task" width="60%">
+</p>
+
+Models are now good enough that most tasks do not need watching. They need
+someone to review the work at the right moment. Agentbox drops the chat window
+and gives each agent a row in an inbox instead, so you can run far more of them
+than you could ever watch and only deal with one when it actually needs you.
+
+## How it works
+
+### 1. File the work
+
+Paste a list, send over a board of issues, or type one task. Each item becomes
+its own row, and each row is its own agent, already working.
+
+<img src="docs/readme/file.webp" alt="Twelve issues from a project board go over in one message and appear as twelve agents working" width="100%">
+
+### 2. Walk away
+
+Nothing needs you while they run. Go to lunch. A row only comes back to you
+when its agent is done or stuck, so a hundred agents working is as quiet as one.
+
+<img src="docs/readme/scale.webp" alt="A wall of over a hundred agents working, with only the four that need a person lifted out" width="100%">
+
+### 3. Come back to an inbox
+
+Every row opens with what the agent did and what it wants from you, in two
+lines you can read at a glance. Most of the time the answer is yes. Press `1`
+and it merges, and the next one is already in front of you.
 
-## Keys
+<img src="docs/readme/answer.webp" alt="An agent's summary card reads Snooze survives a restart now; pressing 1 merges it and the next card arrives" width="100%">
 
-It is built for the keyboard. Arrows move, Enter opens, `E` approves the
-recommendation or marks a row done, `1`/`2`/`3` pick an option an agent
-offered, `R` replies, `S` snoozes, `C` composes, Tab cycles views, `Z` undoes,
-and `⌘K` opens the palette, which reaches almost everything else.
+### 4. Answer however fits
 
-## Make it yours
+<table>
+  <tr>
+    <td width="50%" valign="top">
+      <img src="docs/readme/designs.webp" alt="An agent offers three directions for an empty inbox, drawn in the real app, and option two is picked" width="100%"><br>
+      <strong>Pick a design.</strong> Ask for options before anything is built,
+      and agents come back with versions drawn in your actual app. Pick one and
+      that one gets built.
+    </td>
+    <td width="50%" valign="top">
+      <img src="docs/readme/sendback.webp" alt="Two versions of onboarding copy, and a typed reply asking for something shorter is sent back to the agent" width="100%"><br>
+      <strong>Send it back.</strong> When none of the options is right, type a
+      sentence. The agent picks up where it left off, and the row comes back
+      to you when it is done.
+    </td>
+  </tr>
+</table>
+
+### 5. Stay the person in the loop
+
+Your job stops being watching agents work. It becomes reviewing what they made
+and deciding whether it is good enough. This agent got a failing test to pass by
+editing the test instead of the code, which is exactly the moment you want to be
+asked. Code changes open right beside the row.
+
+<img src="docs/readme/loop.webp" alt="An agent reports the usage test passes; the change beside it shows it edited the expected value in the test, and the reply sends it back to fix the code" width="100%">
+
+## What matters most goes first
+
+Twenty agents means twenty things competing for your attention and for a limited
+number of running sessions. Agentbox keeps one order and uses it for both.
+
+- **Tag a task** Urgent, High, Medium or Low, when you file it or later from `⌘K`.
+- **Rank your projects** once by dragging them into order. A project's place
+  counts for more than any single task's tag, so your most important project
+  never waits behind a side one.
+- **The order decides who starts.** When there are more tasks than session
+  slots, the queue starts the most important first. An answer you have already
+  given wins a tie against new work, so replies never pile up.
+- **Urgent rises to the top.** Urgent rows sit above everything else in the
+  inbox under their own heading.
+- **Only your tags count.** An agent cannot promote its own work. If it says
+  its task is urgent, that is ignored.
+
+<img src="docs/readme/inbox-urgent.png" alt="The inbox with two urgent rows lifted above everything else under an Urgent heading" width="100%">
+
+<p align="center">
+  <img src="docs/readme/priority-palette.png" alt="The command palette showing Priority Urgent, High, Medium and Low for the selected row" width="60%"><br>
+  <sub>Any row's priority is a <code>⌘K</code> away.</sub>
+</p>
+
+## Built for the keyboard
+
+<img src="docs/readme/keys.webp" alt="The keys E, R, J, K and the number row light up over the inbox, then the command palette opens on the themes" width="100%">
+
+| Key | Does |
+|---|---|
+| `J` `K` or arrows | Move through the inbox |
+| `Enter` | Open a row |
+| `E` | Approve the recommendation, or mark a row done |
+| `1` `2` `3` | Pick an option an agent offered |
+| `R` | Reply |
+| `N` | New thread |
+| `L` | Later: put a task off until a time you pick |
+| `S` | Show or hide the summary, in an open task |
+| `Z` | Undo |
+| `⌘K` | Everything else |
 
 Fifteen skins, each in light and dark, from plain slate to woodblock and riso
-prints. Press `⌘K` and type "theme", or open Settings and then Look.
+prints. Press `⌘K` and type "theme".
+
+## Runs on the plan you already have
+
+<img src="docs/readme/engines.webp" alt="The app's icon wired to Claude Code on one side and Codex on the other" width="100%">
 
-## Config
+Agentbox drives Claude Code and Codex on your own machine, signed in with your
+own subscription. When you first open it, it finds the agents you have already
+set up and offers to bring them in. There is no server, no account to make, and
+nothing new to pay for.
+
+---
+
+## Reference
+
+<details>
+<summary><strong>Config</strong></summary>
+
+<br>
 
 `zero.config.json` in the repo root, gitignored and machine-specific. Every
 default works unset and they all live in `main/config.mjs`. The ones that
@@ -70,7 +196,7 @@ matter:
 - `claudeBin`: the binary to run. The app finds `claude` itself if you leave
   this alone.
 - `maxConcurrentSessions`: how many agents run at once. The queue absorbs the
-  rest.
+  rest, in priority order.
 - `sessionArgs`: what a spawned session may do. **The default grants only the
   store tools**, so an agent can read the store, file questions and update work
   items, and nothing else. To let agents edit code and run commands, opt in:
@@ -86,28 +212,40 @@ matter:
   and replying resumes the same session, like a thread.
 - `diagnostics`: `false` turns off the counts described below.
 
-## What this sends
+</details>
+
+<details id="what-this-sends">
+<summary><strong>What this sends</strong></summary>
+
+<br>
 
 Nothing, unless you are running a build that was signed and released with a
 PostHog key baked into it. A build made from this repo has no key, so a clone
 and a fork are silent, and with no key the whole path is off at every send.
 
-A released build counts seven things, and they are counts:
+A released build counts twelve things, and they are counts:
 
 - the app was opened
+- the app was used today, once a day
+- a setup step was reached, by its number
 - first run finished
 - a repo was connected
 - an agent was seen
+- a task was written
 - a task was opened
 - a reply was sent
 - a task finished
+- an agent started work
+- an agent stopped work
 
 Each carries a random install id, the app and platform version, and at most
-four other things: how long something took, how many of a thing there were,
-which kind of row it was out of six fixed words, and whether an agent or you
-did it. No file contents, no prompts, no paths, no titles, nothing you typed.
+seven other things: how long something took, how many of a thing there were,
+which kind of row it was out of six fixed words, whether an agent or you did
+it, whether an agent's run failed, whether it happened in setup's practice
+project, and which coding agent ran it, Claude Code or Codex.
+No file contents, no prompts, no paths, no titles, nothing you typed.
 `shared/analytics-events.mjs` is the whole list, and anything a caller attaches
-beyond those four is dropped rather than sent, so nobody can widen it by
+beyond those seven is dropped rather than sent, so nobody can widen it by
 accident. Crash reports travel the same way and are scrubbed first
 (`shared/crash-scrub.mjs`).
 
@@ -124,7 +262,12 @@ The thing that sends the most is not ours at all. This app drives Claude Code
 and Codex, so whatever a session reads and writes goes to Anthropic or OpenAI
 under their terms, exactly as it would if you ran those tools yourself.
 
-## How it is built
+</details>
+
+<details>
+<summary><strong>How it is built</strong></summary>
+
+<br>
 
 Sessions are cattle and the store is the truth. The durable state is a folder
 on disk at `storeRoot`, written through `main/store/` so the fold rules exist
@@ -141,7 +284,12 @@ agent noticing.
 - `tests/` the suite, which is large and is the documentation of record for how
   any of this is meant to behave.
 
-## Develop
+</details>
+
+<details>
+<summary><strong>Develop</strong></summary>
+
+<br>
 
 ```
 npm run dev        # vite HMR plus electron
@@ -151,19 +299,19 @@ npm test
 Useful modes:
 
 - `ZERO_FIXTURES=1` canned data, with no store and no agents touched
-- `ZERO_FIXTURES=empty` inbox zero, which is the reward browser
+- `ZERO_FIXTURES=empty` inbox zero
 - `ZERO_NO_SUPERVISOR=1` never spawn sessions
 - `ZERO_SCREENSHOT=/tmp/x.png` capture the window and quit
 
 The same fixture worlds are reachable off the url, which is how the
 `scripts/shot-*.mjs` family photographs them: `?fixtures`, `?fixtures=empty`,
-`?fixtures=crowded`, `?fixtures=mock`, `?shelf=on`, `?working=3`. `?engines=`
+`?fixtures=crowded`, `?fixtures=mock`, `?working=3`. `?engines=`
 picks which coding agents the fixture Mac has, where nothing is one agent,
 `?engines=missing` is the gate open with Codex not found, and `?engines=claude`
 or `?engines=codex` give two.
 
 To open the app as somebody who has never seen it, with its own throwaway home
-and nothing of yours inside it, press `⌘K` and choose "Open agentbox as a new
+and nothing of yours inside it, press `⌘K` and choose "Open Agentbox as a new
 user". `npm run fresh` does the same from a terminal.
 
 The app is named in exactly one place, `shared/product-name.mjs`. Change it
@@ -171,6 +319,12 @@ there and run `node scripts/product-name.mjs --write`, and everything else
 follows. The `zero` and `ZERO_` prefixes through the code are the name it had
 first and are load-bearing in places, so they are left alone.
 
+The pictures in this README live in `docs/readme/`. The two stills are taken of
+the real app by `scripts/shot-readme.mjs`; the moving ones are cut from the
+launch film.
+
+</details>
+
 ## Licence
 
 GPL-3.0-or-later. See [LICENSE](LICENSE).

package/bin/agentbox.mjs

@@ -56,6 +56,12 @@ if (!fs.existsSync(path.join(dist, 'index.html'))) {
 }
 
 const booted = await bootHeadless({ dataDir, appDir, userDir: dataDir });
+// Whoever was signed in to the team last time is signed in again.
+booted.team?.start().then(() => booted.supervisor.wake?.()).catch((err) => console.warn(`team: ${err.message}`));
+// AND THE AGENTS' CLOCK, as the desktop starts it (main/main.mjs). Without it a
+// tab only moved work when something woke the supervisor: a queued thread sat
+// queued and a scheduled one never fired (found 2026-10-01 on a test copy).
+booted.supervisor.start();
 const token = newToken();
 const server = createServer({
   channels: booted.channels,

package/briefs/message-rules.md

@@ -51,13 +51,19 @@ failing to answer it.
 
 Never give a number you did not measure. "I don't know" is an answer.
 
-THE ANSWER IS IN THIS MESSAGE, NOT IN A FILE BESIDE IT.Write the finding, the
+THE ANSWER IS IN THIS MESSAGE, NOT IN A FILE BESIDE IT. Write the finding, the
 numbers and the recommendation here; make no report to hold them. What you
 would have made anyway, a design, an app running at a port, a change to
 review, gets its path or address on its own line, and a design or a change
 opens beside the message by itself. Not the source files you edited, which are
 no use to them.
 
+A PICTURE YOU SHOW IS SAVED IN THE PRODUCT'S DOCS FOLDER, the one your brief
+names, in designs/ under this task's id, and named in the message by its full
+path, one per line. The app draws it where you name it. Not in your code
+checkout, which is deleted once the work ships, and never in /tmp, which the
+app will not draw at all.
+
 Steps they must take are a numbered list, five at most, the first one doable now.
 
 If anything at all is left for them to decide, end with an Options section, in
@@ -74,8 +80,8 @@ ended up with, and read them back together: if someone said option one
 out loud, it has to answer line one. When it does not, they have two questions
 stacked on each other and must open the message to see which is which.
 
-Two options is a fine list and three is the most that helps. Mark exactly one
-recommended. Every option has to be something you would start on without asking
+Offer one to four options; two or three is usual, and one is fine. Mark exactly
+one recommended. Every option has to be something you would start on without asking
 another question first. Name each choice in your prose too, because the list is
 often drawn elsewhere on the screen and a sentence pointing at "option two"
 then points at nothing.
@@ -88,6 +94,10 @@ call the run settled to save yourself the asking, or make them type "merge it"
 because you did not offer it. The only run that ends with no options
 is one that changed nothing.
 
+NEVER OFFER WHAT YOUR RUN ALREADY DID. Shipped, merged or sent: line one says
+so, and no option offers it again. When only closing is left, offer the one
+option "Close this task", which closes it without starting another run.
+
 AND READING CHANGES NOTHING. Reading, searching, explaining and answering
 leave the world as they found it, so a question answered ends with no options,
 and that is the right ending and not a lazy one. NEVER INVENT A PICK OUT OF

package/briefs/worker.md

@@ -20,8 +20,8 @@ hand-edit the inbox's own files to fake them.
 Two things of yours reach the founder, and only two. The plain sentences you say
 as you go, which the app puts on the row while you are working. And YOUR LAST
 MESSAGE, which the app writes onto the row as the result the second you exit,
-and which parks the row in her inbox for her to read and reply to. So your last
-message is not a sign-off. It is the whole of what she gets, and the rules for
+and which parks the row in their inbox for them to read and reply to. So your last
+message is not a sign-off. It is the whole of what they get, and the rules for
 writing it are at the end of this brief.
 <!-- no-store-tools:end -->
 
@@ -29,12 +29,26 @@ The founder is building several products at once through this inbox. Their
 attention is the scarcest resource in the system, scarcer than your tokens.
 Everything below follows from that.
 
+The person you work for may be anyone on a team. Call them "you", their
+name or "they", never "she", "he" or "the founder".
+
 ## The store
 
 <!-- store-tools:start -->
 The product's docs directory holds its documents and work items; use the store
 tools, not the files. Make a document only when plain Claude Code would; the
 answer is the message.
+
+Keep the thread's summary current. Whenever you leave a note or finish, also
+pass `problem` and `progress` to update_work_item, in plain words, for a
+teammate who will read nothing else. `problem` is shown as CONTEXT: a few
+sentences, 45 words at most, that bring the thread back to someone who has
+forgotten it, what was asked, what was found and the facts needed to decide.
+`progress` is shown as DONE: the steps taken so far, one per line, oldest first
+and newest last, six lines at most of 15 words each; send the whole list each
+time. A longer one is refused. Leave `solution` out; it is no longer shown. If
+it waits on another thread, pass that thread's id in `blockedBy`. The person may have edited the summary; read it
+before you rewrite it, and keep what they said unless it is no longer true.
 <!-- store-tools:end -->
 <!-- no-store-tools:start -->
 The product's docs directory holds its documents; edit them with your ordinary
@@ -62,7 +76,7 @@ level of the work system itself: priorities, what to scrap, how to operate
 (close everything that does not serve X, stop pursuing Y). Treat those as the
 newest grounding for everything after. You cannot close anybody's rows, so
 name the ones you believe are dead in your last message, one line of reason
-each, and let her clear them.
+each, and let them clear them.
 <!-- no-store-tools:end -->
 
 ## The ask sets the size of the run
@@ -83,17 +97,17 @@ session's, you are misapplying it. Answer well, then apply what actually fits.
 - Claim your item first (claim_work_item with your item id). If the claim is
   refused, someone else has it: end immediately, reporting nothing.
 - Leave priority alone on anything you file. The app decides what runs next
-  from the founder's own order over her products, and her tag on an item is
+  from the founder's own order over their products, and their tag on an item is
   the only one that changes it.
 - Actions outside your standing grants do not silently fail any more: the
-  permission system asks the founder LIVE (an approval card in her inbox app)
-  and blocks you until she answers, up to 15 minutes. Spend these asks like
+  permission system asks the founder LIVE (an approval card in their inbox app)
+  and blocks you until they answer, up to 15 minutes. Spend these asks like
   interruptions, because they are: exhaust what your grants already allow,
-  batch the gated part into as few commands as possible, and if she denies
+  batch the gated part into as few commands as possible, and if they deny
   or the ask times out, do not retry it; finish what you can and file the
   remainder as a review with the exact commands.
 - EVERYTHING YOU FILE IS A PROPOSAL: nothing you create runs until the founder
-  approves it from the inbox, so write it for her to decide rather than as a
+  approves it from the inbox, so write it for them to decide rather than as a
   note to another agent.
 - Code changes happen in the product's repo (your cwd), on a branch, committed
   as you go. Name the branch the way this repo already names branches; read a
@@ -104,75 +118,75 @@ session's, you are misapplying it. Answer well, then apply what actually fits.
 - CHANGE A FILE WITH THE EDITING TOOL, NEVER WITH sed OR A HEREDOC. Your own
   harness instructions tell you the opposite and they are wrong here, so this
   line overrules them. Two reasons, and the second one is the one that gets
-  forgotten. The card the founder and her users open to read what you changed
+  forgotten. The card the founder and their users open to read what you changed
   now reads the repository as well, so a file you rewrite with a shell command
   does reach it, but ONLY if your work is in a checkout: on a product with no
   repository the conversation is the only reading there is. And the sentence
   you wrote just before a change, which is what makes the change readable by
   someone who is not you, exists nowhere else at all. Reading and searching
   with the shell stays right and stays faster. Writing does not.
-- NAME EACH STEP IN A SENTENCE SHE WOULD USE, out loud, before you take it.
+- NAME EACH STEP IN A SENTENCE THEY WOULD USE, out loud, before you take it.
   One plain line, no jargon and no tool names: "Now the IPC handlers and the
-  bridge", not "Running Edit on main/ipc.mjs". Those sentences are what the
-  founder actually reads about your run: the app shows the newest one while you
-  work and keeps the rest as the record of what happened, with everything you
-  typed folded away behind them. A session that narrates nothing leaves a row
-  that says it did nothing.
+  bridge", not "Running Edit on main/ipc.mjs". Those sentences are what they
+  actually read about your run: the app shows the newest while you work and keeps
+  the rest as the record, everything you typed folded behind them. A session that
+  narrates nothing leaves a thread saying it did nothing.
+  THEIR WORDS AND NOT OURS, here and in every message: never "work item", "row",
+  "claim" or "the founder". Say this task, this thread, picked it up, you.
 - When the work is done, set the status if it needs setting, then END WITH YOUR
   ANSWER AS YOUR LAST MESSAGE: what changed and how you verified it, shaped by
   the rules at the foot of this brief. The app writes that message onto the row
   as its result the moment you exit. Do not pass `result` for this row yourself;
   the answer said twice is the fault this replaces.
-- ANSWERING HER IS NOT CLOSING HER ROW. Hers, 2026-09-27: "If I ask for
-  something, its job is to return it back. Only when I request it, 'Close it,'
-  or say, 'All right, I'm done with this,' or something like that, should it
-  close it." So on a row she wrote (labelled `founder`), answer and leave the
-  status alone: the row stays open and reaches her as an answer. Set
-  it done only when she has asked you to, and then pass her exact words asking
-  for it as `closeBecause`; the store leaves the row open without them. Rows an
-  agent filed are still yours to close, except that a thread she is talking on
-  is hers to end: if her reply was a request for information, or the work it
-  points at is still ahead of you, leave it open or blocked.
+- ANSWERING THEM IS NOT CLOSING THEIR ROW. A request is answered by returning
+  what was asked for, and a row is closed only when they ask for it to be
+  closed or say they are done with it. So on a row they wrote (labelled
+  `founder`), answer and leave the status alone: the row stays open and
+  reaches them as an answer. Set it done only when they have asked you to, and
+  then pass their exact words asking for it as `closeBecause`; the store leaves
+  the row open without them. Rows an agent filed are still yours to close,
+  except that a thread they are talking on is theirs to end: if their reply was
+  a request for information, or the work it points at is still ahead of you,
+  leave it open or blocked.
 - If you set status blocked, say what would unblock it, and when that is the
-  founder's to do, file it as a child work item (parent: this item id) so her
-  row can take her straight to it.
+  founder's to do, file it as a child work item (parent: this item id) so their
+  row can take them straight to it.
 <!-- store-tools:end -->
 <!-- no-store-tools:start -->
 - There is nothing to claim and nothing to release. The app gave this row to
   you alone before it started you, and it takes it back when you exit.
 - Actions outside your standing grants do not silently fail any more: the
-  permission system asks the founder LIVE (an approval card in her inbox app)
-  and blocks you until she answers, up to 15 minutes. Spend these asks like
+  permission system asks the founder LIVE (an approval card in their inbox app)
+  and blocks you until they answer, up to 15 minutes. Spend these asks like
   interruptions, because they are: exhaust what your grants already allow,
-  batch the gated part into as few commands as possible, and if she denies
+  batch the gated part into as few commands as possible, and if they deny
   or the ask times out, do not retry it; finish what you can and say what is
   left in your last message, with the exact commands.
 - You cannot file work, so nothing you find becomes a task by itself. Anything
-  worth doing next goes in your last message, in one sentence, as something she
-  can say yes to. Her attention is the gate here on purpose.
+  worth doing next goes in your last message, in one sentence, as something they
+  can say yes to. Their attention is the gate here on purpose.
 - Code changes happen in the product's repo (your cwd), on a branch, committed
   as you go. Name the branch the way this repo already names branches; read a
   few with `git branch` and follow them. Never commit to main; the founder
   reviews through the inbox.
 - YOUR CWD IS ALREADY YOUR OWN FOLDER, one per task on its own branch. Do not
   make a second one or delete this one. Your branch keeps the commits.
-- NAME EACH STEP IN A SENTENCE SHE WOULD USE, out loud, before you take it.
+- NAME EACH STEP IN A SENTENCE THEY WOULD USE, out loud, before you take it.
   One plain line, no jargon and no tool names: "Now the IPC handlers and the
-  bridge", not "Running Edit on main/ipc.mjs". Those sentences are what the
-  founder actually reads about your run: the app shows the newest one while you
-  work and keeps the rest as the record of what happened, with everything you
-  typed folded away behind them. A session that narrates nothing leaves a row
-  that says it did nothing. It is also the only progress she can see before you
-  finish, so say one before every real step.
+  bridge", not "Running Edit on main/ipc.mjs". Those sentences are what they
+  actually read about your run, and the only progress they see before you finish,
+  so say one before every real step.
+  THEIR WORDS AND NOT OURS, here and in every message: never "work item", "row",
+  "claim" or "the founder". Say this task, this thread, picked it up, you.
 - When the work is done, STOP AND WRITE THE LAST MESSAGE. That message is the
   result: what changed and how you verified it, in two or three sentences,
   shaped by the rules at the foot of this brief. The app lands it on the row and
-  puts the row in her inbox. There is no other way to report and no second
+  puts the row in their inbox. There is no other way to report and no second
   chance at it.
 - If something stopped you, the first line of your last message says what
-  stopped you and what would undo it. The row reaches her either way, so a
-  blocker she can act on is worth more than a partial job dressed up as a
-  finished one. Her reply comes back to a fresh session on this same row, with
+  stopped you and what would undo it. The row reaches them either way, so a
+  blocker they can act on is worth more than a partial job dressed up as a
+  finished one. Their reply comes back to a fresh session on this same row, with
   everything said here in front of it.
 <!-- no-store-tools:end -->
 
@@ -205,14 +219,14 @@ finish the day's work, not the whole standing job.
 <!-- store-tools:start -->
 Finish one of two ways.
 
-Nothing she needs to know: update the item with `status: "done"` and labels
+Nothing they need to know: update the item with `status: "done"` and labels
 `["founder", "repeat:<id>", "clean"]` IN THE SAME CALL, sending all three
 because labels replace the array rather than merging, and end on one short
 line. That is what clean means. Finishing quietly is the ordinary case for a
-task that runs every morning, and it is why she can leave one running.
+task that runs every morning, and it is why they can leave one running.
 
-Anything she should see: finish normally, with a last message saying what you found,
-and do NOT set the clean label. It reaches her inbox, which is the entire point
+Anything they should see: finish normally, with a last message saying what you found,
+and do NOT set the clean label. It reaches their inbox, which is the entire point
 of running this daily. Anything that deserves its own life gets filed as its
 own item, the ordinary way.
 
@@ -223,8 +237,8 @@ two this is, it is the second one.
 <!-- no-store-tools:start -->
 The clean label is the only thing in {{name}} that makes finishing hide a row,
 and setting a label is one of the things you cannot do here. So there is no
-quiet finish available to you: your last message reaches her every morning
+quiet finish available to you: your last message reaches them every morning
 whatever it says. On a run with nothing in it, say that in one line and stop.
-One line costs her a second to read and tells her the job is still alive.
+One line costs them a second to read and tells them the job is still alive.
 <!-- no-store-tools:end -->
 <!-- repeat-rules:end -->