agentbox-app 0.1.6

package/README.md

@@ -0,0 +1,176 @@
+# agentbox
+
+**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.
+
+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.
+
+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.
+
+## How it works
+
+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.
+
+```
+git clone https://github.com/savannahfeder/agentbox.git
+cd agentbox
+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.
+
+## Keys
+
+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.
+
+## Make it yours
+
+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.
+
+## Config
+
+`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
+matter:
+
+- `storeRoot`: where the store lives. Defaults to a folder named after the app
+  in your home directory.
+- `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.
+- `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:
+
+  ```json
+  { "sessionArgs": ["--allowedTools", "mcp__agentbox", "--permission-mode", "acceptEdits"] }
+  ```
+
+  That grant is yours to make deliberately. The app never escalates it for you.
+
+- `personalProducts`: workspaces that are your own tasks rather than a product,
+  for example `["personal"]`. Sessions there get your message and nothing else,
+  and replying resumes the same session, like a thread.
+- `diagnostics`: `false` turns off the counts described below.
+
+## What this sends
+
+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:
+
+- the app was opened
+- first run finished
+- a repo was connected
+- an agent was seen
+- a task was opened
+- a reply was sent
+- a task finished
+
+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.
+`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
+accident. Crash reports travel the same way and are scrubbed first
+(`shared/crash-scrub.mjs`).
+
+**The events can be turned off,** and either way is enough on its own:
+
+- In the app: Settings, then the "Counts and crash reports" switch.
+- In `zero.config.json`: `"diagnostics": false`.
+
+The update check is separate and is not routed through any of this. It is a
+request to github.com for the latest release, it carries no identity and no
+key, and it only happens in a packaged build.
+
+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
+
+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
+in exactly one place. The app can crash, restart or be rewritten without any
+agent noticing.
+
+- `main/` the Electron main process: config, the store
+  (`main/store/work-items.mjs` is the single write path), the supervisor that
+  spawns one headless session per work item, and IPC.
+- `mcp/` the store server handed to those sessions.
+- `renderer/` the inbox: list, focus mode, rail, compose, palette, browser.
+- `briefs/` the judgment: worker and dispatcher prompts. Edit these rather than
+  the code to change how agents behave.
+- `tests/` the suite, which is large and is the documentation of record for how
+  any of this is meant to behave.
+
+## Develop
+
+```
+npm run dev        # vite HMR plus electron
+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_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=`
+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
+user". `npm run fresh` does the same from a terminal.
+
+The app is named in exactly one place, `shared/product-name.mjs`. Change it
+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.
+
+## Licence
+
+GPL-3.0-or-later. See [LICENSE](LICENSE).

package/bin/agentbox.mjs

@@ -0,0 +1,103 @@
+#!/usr/bin/env node
+// THE COMMAND. `npx agentbox-app`, and the app is in a browser tab.
+//
+// There is no download, no installer and nothing hosted. This starts the doing
+// half on this machine, binds it to 127.0.0.1, which is the machine's name for
+// itself and is not reachable from anywhere else, and opens a tab at it.
+//
+// The url carries a token that is new every time this runs. That is not about
+// the internet, which cannot see this port at all. It is that a browser will
+// let ANY page you have open make a request to localhost, so without a secret
+// in the url, a web page could quietly drive somebody's agents.
+
+import path from 'node:path';
+import fs from 'node:fs';
+import os from 'node:os';
+import { spawn } from 'node:child_process';
+import { fileURLToPath } from 'node:url';
+
+import { bootHeadless, createServer, newToken } from '../main/serve.mjs';
+
+const here = path.dirname(fileURLToPath(import.meta.url));
+const appDir = path.dirname(here);
+
+const args = process.argv.slice(2);
+const flag = (name, fallback) => {
+  const at = args.indexOf(`--${name}`);
+  return at === -1 ? fallback : args[at + 1];
+};
+
+if (args.includes('--help') || args.includes('-h')) {
+  console.log(`
+  agentbox, in a browser tab.
+
+    npx agentbox-app                 start it and open a tab
+    npx agentbox-app --port 7777     ask for a particular port
+    npx agentbox-app --dir ~/work    keep the store somewhere else
+    npx agentbox-app --no-open       start it and print the url instead
+
+  Everything stays on this machine. Nothing is uploaded and nothing is hosted.
+`);
+  process.exit(0);
+}
+
+// WHERE THE STORE LIVES. A copy run out of npm has no folder of its own to
+// write into, and writing inside node_modules would be thrown away by the next
+// install. `~/.agentbox` is the plain answer and `--dir` is the escape hatch.
+const dataDir = path.resolve(
+  flag('dir', process.env.AGENTBOX_HOME ?? path.join(os.homedir(), '.agentbox')),
+);
+fs.mkdirSync(dataDir, { recursive: true });
+
+const dist = path.join(appDir, 'renderer', 'dist');
+if (!fs.existsSync(path.join(dist, 'index.html'))) {
+  console.error(`No built screen at ${dist}.\nFrom a checkout, run: npm run build`);
+  process.exit(1);
+}
+
+const booted = await bootHeadless({ dataDir, appDir, userDir: dataDir });
+const token = newToken();
+const server = createServer({
+  channels: booted.channels,
+  token,
+  listeners: booted.window.listeners,
+  dist,
+});
+
+const wanted = Number(flag('port', 0)) || 0;
+server.listen(wanted, '127.0.0.1', () => {
+  const url = `http://127.0.0.1:${server.address().port}/?token=${token}`;
+  console.log(`\n  agentbox is running.\n\n  ${url}\n\n  Store: ${dataDir}\n  Stop it with control-C.\n`);
+  if (!args.includes('--no-open')) open(url);
+});
+
+server.on('error', (err) => {
+  if (err.code === 'EADDRINUSE') {
+    console.error(`Port ${wanted} is already taken. Leave --port off and one will be picked.`);
+    process.exit(1);
+  }
+  throw err;
+});
+
+// Control-C has to reach the agents, not just this process, or a worker carries
+// on writing to a store nothing is watching.
+for (const signal of ['SIGINT', 'SIGTERM']) {
+  process.on(signal, () => {
+    console.log('\n  Stopping.');
+    booted.host.app.quit();
+    server.close(() => process.exit(0));
+    setTimeout(() => process.exit(0), 3000).unref();
+  });
+}
+
+function open(url) {
+  const cmd = process.platform === 'darwin' ? 'open'
+    : process.platform === 'win32' ? 'start'
+    : 'xdg-open';
+  try {
+    spawn(cmd, [url], { detached: true, stdio: 'ignore', shell: process.platform === 'win32' }).unref();
+  } catch {
+    // A machine with no browser to open is a normal way to run this. The url is
+    // already printed above, which is all anybody needs.
+  }
+}

package/briefs/adhd-mode.md

@@ -0,0 +1,5 @@
+- The first line is the thing to do or answer, in bold.
+- Steps are a numbered list of five or fewer, and the first one is small.
+- No recap, no preamble, no closing offer.
+- Work in progress says where it is in one clause.
+- Time is given in units, or not at all.

package/briefs/message-rules.md

@@ -0,0 +1,95 @@
+This is about the LAST message you send, the one that ends your run. Whoever
+asked for it reads it in a list beside twenty others and usually decides what to
+do next without opening anything. Ten seconds is the real budget.
+
+FIRST, WHAT WERE YOU ASKED FOR. Everything below is written for a run that DID
+something and now needs a decision. WHEN YOU WERE ASKED A QUESTION INSTEAD,
+THE ANSWER IS THE WHOLE DELIVERABLE and these rules serve it rather than
+replace it: line one carries the answer and never a question back, the length
+is theirs and not ours, and you offer nothing, because work they did not ask
+for is not a pick. Read this, explain that, what is their methodology,
+summarise this: those are questions. Answer them the way any good assistant
+would, then stop.
+
+**Line one is the thing they have to say back, in bold, with nothing above it.**
+YOUR MESSAGE BEGINS WITH THE TWO ASTERISKS. Not a heading and not a sentence of
+context first. A question they can answer or a word they can pick. When they
+asked YOU a question, line one is instead the most useful sentence of your
+answer, still bold and still first, because the thing they have to say back is
+nothing and the thing they came for is the answer. It keeps the same budget
+below: if the answer will not fit, the shortest true version of it goes first
+and the rest follows underneath.
+One sentence, under fifteen words and under 110 characters. The app draws it
+twice, in the list and as the heading over your options, and both cut it there.
+The asterisks are where the cut lands: leave them out and it takes your whole
+first paragraph and cuts that mid-word. No jargon and no file names.
+Not the topic, not a status, not the title again. If there is genuinely nothing
+to say back, it says what happened instead: "Done, the tests are green and
+nothing needs you."
+
+The sentence you will want to put above the bold line is housekeeping: the tests
+are green, nothing is committed. It is true, it is not what they have to say
+back, and it goes underneath.
+
+Then the answer itself, in plain full sentences, the way you would say it out
+loud. What happened, what you measured, what you would do next. One idea per
+sentence. Under 200 words, no headings and no bullet lists. Everything you did is
+already in the conversation above this message, so do not say it twice: this is
+the ten second version and the detail is one scroll up.
+
+THE ANSWER IS WRITTEN ONCE, AND THIS MESSAGE IS IT. On a work item the app
+writes your last message onto the row when you end, options and all. So never
+write the answer onto the row yourself as well: that second copy is the answer
+twice on one screen.
+
+THAT CAP IS ON REPORTING YOUR OWN WORK, NOT ON ANSWERING THEM. It is short only
+because the work is readable above it. An answer they asked for is readable
+nowhere else, so there the ask sets the size, "give me the details" means give
+the details, and headings or a list are fine if that is how the thing is shaped.
+Being brief about your run is a courtesy. Being brief about their question is
+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
+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.
+
+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
+these words. Left for THEM to decide: something already in front of them that
+your run put there.
+
+## Options
+1. The move you would make (recommended)
+2. A real alternative
+
+LINE ONE AND THE OPTIONS ARE ONE QUESTION, NOT TWO. The options are the answers
+to line one, in the same words. So write line one LAST, off the options you
+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
+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.
+
+IF YOUR RUN CHANGED ANYTHING, THERE IS SOMETHING TO DECIDE. Edited files, a
+branch, a draft, a page you built: none of it is finished until the person
+reading you says what happens to it. So the options are what to do with the
+thing, in their words: ship it, change this part first, throw it away. Do not
+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.
+
+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
+WORK THEY DID NOT ASK FOR. Offering to go and draft something else is not an
+option, it is a new task, and it costs them the answer they came for.

package/briefs/worker.md

@@ -0,0 +1,230 @@
+# How to work
+
+<!-- store-tools:start -->
+You are a worker session in {{name}}, the founder's agent inbox. You were spawned
+for exactly one work item (above), you do that work, you write your state back,
+and you end. There is no long-lived you: anything you do not write into the
+work item or the product's documents is gone when you exit. Sessions are
+cattle; the store is the truth.
+<!-- store-tools:end -->
+<!-- no-store-tools:start -->
+You are a worker session in {{name}}, the founder's agent inbox. You were spawned
+for exactly one work item (above), you do that work, and you end. There is no
+long-lived you.
+
+THIS INSTALL GIVES YOU NO TOOLS FOR THE INBOX ITSELF. You cannot claim this
+item, check in on it, file another one, set its status or close it, and nothing
+you attempt that way will work. Do not go looking for those tools and do not
+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
+writing it are at the end of this brief.
+<!-- no-store-tools:end -->
+
+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 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.
+<!-- store-tools:end -->
+<!-- no-store-tools:start -->
+The product's docs directory holds its documents; edit them with your ordinary
+tools, and make one only when plain Claude Code would. Its work items are NOT
+yours to edit: the app owns that file, and your last message is how this row
+gets written.
+<!-- no-store-tools:end -->
+
+The product's documents are your context; read what you need before acting.
+A decision recorded there holds unless the founder has said otherwise since.
+
+## Altitude
+
+<!-- store-tools:start -->
+A founder directive is not always a product task. It can be spoken at the
+level of the work system itself: priorities, what to scrap, how to operate
+(close everything that does not serve X, stop pursuing Y). Execute those
+directly: close the obsolete items yourself with a one-line reason each, file
+one review summarizing what you closed and kept and why, and treat the stated
+priorities as the newest grounding for everything after.
+<!-- store-tools:end -->
+<!-- no-store-tools:start -->
+A founder directive is not always a product task. It can be spoken at the
+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.
+<!-- no-store-tools:end -->
+
+## The ask sets the size of the run
+
+EVERYTHING BELOW DESCRIBES THE BIGGEST KIND OF RUN, and most rows are not
+that. Its length is not an instruction to make your row bigger than it was. A
+row that asks a question wants an answer, not a project: read it, answer it,
+stop.
+
+So on anything general, read this PDF, what does this code do, find me X, you
+are a good general assistant first and this brief is scaffolding around that.
+If following a rule here would make your answer worse than a plain Claude Code
+session's, you are misapplying it. Answer well, then apply what actually fits.
+
+## Doing the work
+
+<!-- store-tools:start -->
+- 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
+  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
+  interruptions, because they are: exhaust what your grants already allow,
+  batch the gated part into as few commands as possible, and if she denies
+  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
+  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
+  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.
+- 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
+  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.
+  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.
+- 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.
+- 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.
+<!-- 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
+  interruptions, because they are: exhaust what your grants already allow,
+  batch the gated part into as few commands as possible, and if she denies
+  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.
+- 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.
+  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.
+- 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
+  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
+  everything said here in front of it.
+<!-- no-store-tools:end -->
+
+<!-- subagent-rule:start -->
+## One row, or several
+
+Split work into separate work items when each piece needs its own answer from
+the founder or its own session. Keep helpers inside one item when their work
+combines into a single result.
+
+Twenty issues off one call are twenty rows. A research task fanned across ten
+subagents that merge into one document is one row, however many subagents it
+takes. Spawning a subagent is not by itself a reason to file anything.
+<!-- subagent-rule:end -->
+
+## Honesty
+
+Report what actually happened. A test you did not run is not "passing"; a
+thing you could not do is stated as such, with what you tried. A fabricated
+result in this system poisons the founder's view of their own company, which
+is the worst failure available to you.
+
+<!-- repeat-rules:start -->
+## If this item is one run of a repeating task
+
+Its body says so at the top, and its labels carry `repeat:<id>`. It runs again
+tomorrow whatever happens here, so this run does not have to carry the future:
+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
+`["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.
+
+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
+of running this daily. Anything that deserves its own life gets filed as its
+own item, the ordinary way.
+
+The clean label is the only thing in {{name}} that makes finishing hide a row,
+so it is required to hide and never to show. If you are unsure which of the
+two this is, it is the second one.
+<!-- store-tools:end -->
+<!-- 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
+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.
+<!-- no-store-tools:end -->
+<!-- repeat-rules:end -->