agentbox-app 0.1.7 → 0.1.12

package/shared/first-run-practice.mjs

@@ -5,10 +5,10 @@
 // of the walk. What tells somebody it is not theirs is a band across the top
 // that never leaves, not the size of it.
 //
-// WHY IT EXISTS AT ALL is David, on the call of 2026-08-23: he opened Agentbox,
-// saw a real task on a real screen and read it as work. His words were that he
-// thought the task was to set up the project and that it was asking him
-// questions to do the setup, and he tried to answer the placeholder text.
+// WHY IT EXISTS AT ALL is a tester, on a call of 2026-08-23: they opened Agentbox,
+// saw a real task on a real screen and read it as work. Their words were that they
+// thought the task was to set up the project and that it was asking them
+// questions to do the setup, and they tried to answer the placeholder text.
 //
 // Everything here is content, no window and no filesystem, so both halves can
 // read it: the renderer draws the walk off ../renderer/src/onboarding.ts and
@@ -63,9 +63,19 @@ export const PRACTICE_FLAG = 'practice';
  *  what she reads at beat ten is these two paragraphs together, under the
  *  practice band and over a "Start it ⌘↵" button. They have to make sense as
  *  one card, which is why the body opens by naming the app the title names. */
+// EVERYDAY WORK, NOT CODE (2026-10-01). It was a sign-out button for a pretend
+// app, and the four rows below were a sign-in route, a flaky test, a slow CI run
+// and dead code. A persona test of an executive assistant found all of it
+// written for programmers. A meeting summary, a reply, a tidy list, a budget and a
+// date are work everybody on a team does, engineers included.
+// AND THE BODY IS WHAT A PERSON WOULD TYPE (2026-10-06). It read "Practice is a
+// pretend project, not your work and not Agentbox. This one is written for you
+// already.", which is the walk talking to her, and it was then drawn in her
+// own thread as a message from "You". The band over the window already says
+// none of it is hers.
 export const PRACTICE_TASK = {
-  title: 'Add a sign-out button to the Practice app.',
-  body: `Practice is a pretend project, not your code and not ${NAME}. This one is written for you already.`,
+  title: 'Add a summary to the Practice meeting notes.',
+  body: 'Keep it short: what we decided, and what is still open.',
 };
 
 /**
@@ -78,7 +88,22 @@ export const PRACTICE_TASK = {
  * IT STILL TAKES TWO SECONDS AND IT IS STILL A REAL ROW WITH A REAL RESULT ON
  * THE REAL LEDGER.*/
 export const PRACTICE_ANSWER =
-  'Done, and the tests pass. I put it next to the avatar rather than inside the menu. Say the word and I will move it.';
+  'Done, and it is five lines at the top of the notes: three decisions and two open questions. Say the word and I will make it shorter.';
+
+/**
+ * AND WHAT COMES BACK WHEN SHE TAKES IT UP ON THAT (2026-10-06). The answer
+ *  above offers to make it shorter, so a reply is answered with the shorter
+ *  one, whatever the reply says: this is the practice project and nothing in
+ *  it reads her words. It is finished, so the next move is closing it. */
+/**
+ * AND THE REPLY ITSELF, WRITTEN IN FOR HER (2026-10-06), hers: "when they do
+ *  that or click the inbox have it auto-write something". It is in the reply
+ *  box when her first thread comes back, so R or a click opens it ready to send,
+ *  the same way the first thread's own words were ready in the card. */
+export const PRACTICE_REPLY = 'Make it shorter, please.';
+
+export const PRACTICE_REPLY_ANSWER =
+  'Shorter now: three lines at the top of the notes, one for what was decided, one for what is open, and one for who owns each open question.';
 
 /**
  * WHAT IS IN THE PRACTICE PROJECT'S SIDEBAR NOTE.
@@ -145,98 +170,180 @@ export const PRACTICE_NOTE = [
 export const PRACTICE_ROWS = [
   {
     kind: 'task',
-    title: 'Added the sign-in route. Tests green.',
-    body: 'Add a sign-in route at /sign-in. Reuse whatever we already have for sessions.',
+    title: 'Drafted a reply to the venue.',
+    body: 'Draft a reply to the venue for the offsite. We want Thursday, not Friday, and ask whether lunch is included.',
     trace: [
-      'Reading how auth works here before I touch anything.',
-      '[Read] src/server/auth.ts',
-      '[Read] src/server/routes.ts',
-      '[Grep] createSession',
-      'There is already a signed session cookie in here, seven days, refreshed on use. I will reuse it rather than adding tokens, because two ways to be signed in is the bug that follows.',
-      '[Write] src/server/routes/sign-in.ts',
-      '[Edit] src/server/routes.ts',
-      '[Edit] src/server/auth.ts',
-      '[Bash] npm test -- auth',
-      'Fourteen tests, all green, and nothing else in the suite moved.',
+      'Reading what the venue has already said before I write anything.',
+      '[Read] Venue emails.pdf',
+      '[Read] Offsite plan.docx',
+      '[Grep] lunch',
+      'They offered Friday twice, and their price list says lunch costs extra on weekdays, so I asked rather than guessed.',
+      '[Write] Reply to the venue.docx',
+      'Four sentences, ready for you to send.',
     ],
-    result: 'I reused the session cookie rather than tokens. Say if you disagree.',
+    result: 'The draft asks for Thursday and whether lunch is included. It is ready for you to send.',
     agoMs: 6 * 60_000,
   },
   {
     kind: 'task',
-    title: 'Fixed the flaky checkout test.',
-    body: 'checkout.spec.ts fails about one run in five on CI and passes every time on my Mac. Find out why.',
+    title: 'Tidied the team contact list.',
+    body: 'Clean up the team contact sheet. Remove the duplicates and sort everyone by last name.',
     trace: [
-      '[Bash] npx vitest run checkout.spec.ts --repeat 20',
-      'Three failures in twenty, every one of them on the same assertion, so it is a race and not the assertion.',
-      '[Read] tests/checkout.spec.ts',
-      '[Read] tests/fixtures/cart.ts',
-      'The fixture writes the cart and returns before the write lands. The test reads it straight away, so on a slow machine it reads an empty cart.',
-      '[Edit] tests/fixtures/cart.ts',
-      '[Bash] npx vitest run checkout.spec.ts --repeat 40',
-      'Forty for forty. I changed the fixture and nothing in the test itself.',
+      '[Read] Team contacts.xlsx',
+      'Forty two rows, and six of them are the same person twice with a different spelling.',
+      '[Edit] Team contacts.xlsx',
+      '[Read] Team contacts.xlsx',
+      'Thirty six people now, sorted by last name.',
+      '[Grep] email',
+      'Two people have no email address, so I put them at the bottom rather than guess one.',
     ],
-    result: 'It was a race on the fixture. It awaits now. Nothing else changed.',
+    result: 'Six duplicates are gone and everyone is sorted by last name. Two people have no email, so they are at the bottom.',
     agoMs: 14 * 60_000,
   },
   /* * THE ONE THAT IS NOT FOR TODAY, and snoozing it is the point of beat fourteen.
 
      IT HAD TO BE A FOURTH SHAPE OF ROW, not one of the three already here. Two
      of those are finished, so E is right on them, and the third is an agent
-     stopped, where answering is the only right move. Snoozing either would be
-     teaching the key on a row it is wrong for, which is the exact fault round
-     four was opened about. This one is real work, it is nobody's emergency, and
-     half a day is the reason to put it off rather than an excuse: that is the
-     row S exists for.
-  */
+     stopped, where answering is the only right move. This one is real work, it
+     is nobody's emergency, and a week is the reason to put it off rather than
+     an excuse: that is the row S exists for. */
   {
     kind: 'task',
     later: true,
-    title: 'The check runs are 40 seconds slower than Monday.',
-    body: 'CI got slower this week and nobody changed the workflow. Find out what did it.',
+    title: 'The budget draft for next quarter is ready.',
+    body: "Pull last quarter's spending into a first draft of next quarter's budget.",
     trace: [
-      '[Bash] gh run list --limit 40 --json databaseId,createdAt,conclusion',
-      'Monday it was 2m14s and today it is 2m54s, and the step that grew is the type check rather than the tests.',
-      '[Read] .github/workflows/ci.yml',
-      '[Read] tsconfig.json',
-      '[Bash] npx tsc --noEmit --extendedDiagnostics',
-      'The type check now runs over every package instead of the ones that changed, because the project references came out of tsconfig in the pnpm move.',
-      'Putting them back means splitting the config per package and re-pointing the workflow. It is about half a day and nothing is broken while it waits.',
+      '[Read] Spending last quarter.xlsx',
+      '[Read] Plan for next quarter.docx',
+      'Spending was close to plan except travel, which ran about a fifth over.',
+      '[Write] Budget draft.xlsx',
+      '[Edit] Budget draft.xlsx',
+      'Every line is filled in. It needs about an hour of your time to check, and nothing is due until next week.',
     ],
-    result: 'It is the type check running over every package. The fix is half a day of config, and nothing breaks while it waits.',
+    result: 'It is ready for you to check. It needs about an hour, and nothing is due until next week.',
     agoMs: 22 * 60_000,
   },
   /*
-   * THE ONE THAT IS WAITING. It is a question, it is not finished, and an agent
-     is stopped on it until somebody answers. Its result carries the options,
-     because `optionsFrom` in renderer/src/format.ts reads the offer off the
-     result first, and the options are what make answering it one key. */
+     THE ONE AN AGENT IS STOPPED ON, and it stays stopped until somebody answers.
+     Its result carries the options, because `optionsFrom` in
+     renderer/src/format.ts reads the offer off the result first, and the
+     options are what make answering it one key. */
   {
     kind: 'question',
     waiting: true,
-    title: 'Delete 340 lines of dead code?',
-    body: 'Have a look for anything in src/ that nothing imports.',
+    title: 'Which date should I send for the team dinner?',
+    body: 'Find a date for the team dinner that works for everyone, and ask me before you send it.',
     trace: [
-      '[Bash] npx knip --include files,exports',
-      '[Read] src/lib/legacy-client.ts',
-      '[Grep] legacy-client',
-      '[Read] src/lib/format-old.ts',
-      '[Grep] formatOld',
-      'Three files, 340 lines. Nothing in src/ imports any of them and nothing in tests/ does either.',
-      'The legacy client is the one I would ask about: it is the only thing left that speaks to the v1 API, so if anything outside this repository still calls that, deleting it is the end of it.',
+      '[Read] Team calendar.ics',
+      '[Grep] out of office',
+      '[Read] Restaurant bookings.pdf',
+      'Two evenings work for everyone: Thursday the 12th and Tuesday the 17th.',
+      'The restaurant has a table for twelve on both, but only the 12th has the private room.',
+      'I have not sent anything yet, as you asked.',
     ],
     result: [
-      'Nothing imports any of the three, so this is safe on my side, but the legacy client is the last thing that speaks v1 and I would rather you said so.',
+      'Two dates work for everyone. I would pick the 12th, because it is the only one with the private room.',
       '',
       '## Options',
-      '1. Delete all three (recommended)',
-      '2. Keep the legacy client, delete the other two',
-      '3. Leave all of it alone',
+      '1. Thursday the 12th (recommended)',
+      '2. Tuesday the 17th',
+      '3. Ask the team to vote',
     ].join('\n'),
     agoMs: 31 * 60_000,
   },
 ];
 
+/**
+ * THE REST OF THE PRACTICE TEAM'S WORK, for the beats that show the whole of it.
+ *
+ *  ADDED 2026-10-02 (w-58c8f466e7). By the tab tour and the board, every row
+ *  above has been closed, put off or answered, so the board opened on an empty
+ *  Needs you column, a bare In progress and a Done column holding the lot, and
+ *  the list tabs held one row each. Asked for in so many words: "there's no
+ *  value if we go into the board view and there's nothing on the page. The
+ *  same applies to the list view: it's really hard to understand."
+ *
+ *  So these are written into the practice project with the rows above and kept
+ *  off the screen by `walkRows` until the tour. Each `state` is the column it
+ *  lands in, read off the row by the app's own rules and not by this file:
+ *
+ *  * `needs`: an agent finished, or stopped on a question. Needs you. Only on
+ *    the board, never in the tour, because the tour opens on "Your inbox is
+ *    now empty" and these would make that untrue.
+ *  * `working`: sent and not finished. In progress.
+ *  * `scheduled`: set for tomorrow morning. Scheduled.
+ *
+ *  None is finished, so "Everything you finished is kept here" stays true of
+ *  the Closed tab. */
+export const PRACTICE_BACKDROP = [
+  {
+    state: 'needs',
+    kind: 'task',
+    title: 'Booked the train for the offsite.',
+    body: 'Book train tickets for the team to the offsite on Thursday morning.',
+    trace: [
+      '[Read] Offsite plan.docx',
+      '[Read] Team contacts.xlsx',
+      'Twelve people, all leaving from the city on Thursday morning.',
+      '[Write] Train booking.pdf',
+    ],
+    result: 'Twelve seats on the 8:10 on Thursday, all in one carriage. The tickets are in the offsite folder.',
+    agoMs: 9 * 60_000,
+  },
+  {
+    state: 'needs',
+    kind: 'question',
+    title: 'Should the welcome pack go out Monday or Wednesday?',
+    body: 'Send the welcome pack to the two new starters, and check the day with me first.',
+    trace: [
+      '[Read] Welcome pack.docx',
+      '[Read] Team calendar.ics',
+      'One starter begins on Monday and the other on Wednesday.',
+    ],
+    result: [
+      'One new starter begins Monday and the other Wednesday. Sending both on Monday means nobody waits.',
+      '',
+      '## Options',
+      '1. Monday, for both (recommended)',
+      '2. On each person\'s first day',
+    ].join('\n'),
+    agoMs: 26 * 60_000,
+  },
+  {
+    state: 'working',
+    kind: 'task',
+    title: 'Write the agenda for the offsite.',
+    body: 'Write the agenda for the offsite: two days, with time for the planning session on day one.',
+    trace: [
+      '[Read] Offsite plan.docx',
+      '[Read] Notes from last offsite.docx',
+      'Day one is mostly planning. Working out where lunch and the walk fit.',
+    ],
+    agoMs: 4 * 60_000,
+  },
+  {
+    state: 'working',
+    kind: 'task',
+    title: 'Compare three caterers for the team dinner.',
+    body: 'Find three caterers who can do dinner for twelve and compare price and menus.',
+    trace: [
+      '[Read] Restaurant bookings.pdf',
+      'Two caterers so far. Checking whether the third does vegetarian menus.',
+    ],
+    agoMs: 11 * 60_000,
+  },
+  {
+    state: 'scheduled',
+    kind: 'task',
+    title: 'Send everyone the offsite reminder.',
+    body: 'Send the whole team a reminder about the offsite, with the train time and the agenda.',
+    trace: [],
+    agoMs: 40 * 60_000,
+    // Tomorrow morning, counted from when the practice project is made.
+    inMs: 18 * 3_600_000,
+  },
+];
+
 /**
  * THE WALK'S OWN TASK, AS A CONVERSATION. The person sends it at beat nine and
  *  opens it at beat eleven, and until 2026-08-24 what they opened was the words
@@ -245,10 +352,9 @@ export const PRACTICE_ROWS = [
  *  shape as the traces above, so the first task anybody opens in Agentbox shows
  *  them what a task holds. */
 export const PRACTICE_TASK_TRACE = [
-  '[Read] src/components/Header.tsx',
-  '[Grep] useSession',
-  'The header already knows who is signed in, so this is one button and one call.',
-  '[Edit] src/components/Header.tsx',
-  '[Bash] npm test -- header',
-  'Green. I put it beside the avatar rather than inside the menu, because the menu is three clicks deep on mobile.',
+  '[Read] Meeting notes.docx',
+  '[Grep] decided',
+  'Three things were decided and two were left open, so the summary says which is which.',
+  '[Edit] Meeting notes.docx',
+  'Five lines at the top. I kept the name of whoever owns each open question.',
 ];

package/shared/fresh-user-home.mjs

@@ -13,7 +13,9 @@
 // would take her real setup with it, which is not a thing a test may cost. So
 // NOTHING IS DELETED, EVER. A second copy is launched inside a fresh home under
 // /tmp and all three land in there: fresh settings, no config file so it falls
-// to DEFAULTS, and an empty store at `<throwaway>/<Name>`.
+// to DEFAULTS, and an empty store at that home's defaultStoreRoot. On macOS
+// that is `<throwaway>/<Name>`. On Linux it is `<throwaway>/.local/share/<slug>`,
+// and only when the copy was not handed the real XDG_DATA_HOME.
 //
 // WHY IT DOES NOT KILL HER AGENTS, which is the whole reason it is usable.
 // `main.mjs` quits on `app.requestSingleInstanceLock`, and that lock is keyed
@@ -133,8 +135,16 @@ function link(from, to) {
 // Code sessions already on this Mac into the fresh inbox. It is not starting
 // from absolute zero, so it is a flag rather than a default here and the
 // caller says which test it wants.
-export function prepareHome(home, { withAgents = false, realHome = os.homedir() } = {}) {
-  const claudeBin = link(path.join(realHome, '.local/bin/claude'), path.join(home, '.local/bin/claude'));
+//
+// `withTools: false` IS A NEW USER WITH NOTHING INSTALLED (w-9f6975906c): her
+// Claude Code is not linked, so the walk's "Which AI plan do you pay for?"
+// can be tried on this Mac. The keychain still is, because Claude Code keeps
+// its sign-in there; `freshEnv(..., { ownSignIns: true })` gives that copy a
+// sign-in folder of its own so it reads and writes a different entry.
+export function prepareHome(home, { withAgents = false, withTools = true, realHome = os.homedir() } = {}) {
+  const claudeBin = withTools
+    ? link(path.join(realHome, '.local/bin/claude'), path.join(home, '.local/bin/claude'))
+    : false;
   const keychain = link(path.join(realHome, 'Library/Keychains'), path.join(home, 'Library/Keychains'));
   const agents = withAgents
     ? link(path.join(realHome, '.claude'), path.join(home, '.claude'))
@@ -169,6 +179,18 @@ export const NOT_INHERITED = Object.freeze([
   ...envNames('HOME'),
   'ZERO_FIXTURES',
   'ZERO_NO_SUPERVISOR',
+  // Where her own Claude Code and Codex sign-ins live, when she has moved them.
+  'CLAUDE_CONFIG_DIR',
+  'CODEX_HOME',
+  // The Linux store default reads XDG_DATA_HOME. A fresh copy that inherited
+  // the real one would write its empty store into her data directory, which is
+  // the 2026-09-27 bug again with a different variable. The other base
+  // directories go for the same reason. XDG_RUNTIME_DIR stays: it is this
+  // login's bus socket, not a directory we keep the inbox in.
+  'XDG_DATA_HOME',
+  'XDG_CONFIG_HOME',
+  'XDG_STATE_HOME',
+  'XDG_CACHE_HOME',
 ]);
 
 /**
@@ -177,9 +199,17 @@ export const NOT_INHERITED = Object.freeze([
  *  is the mark, so the copy knows it is a test and does not count as a person;
  *  see `runningAsAFreshUser` above. And everything in `NOT_INHERITED` is taken
  *  out, because a stranger's copy may not be handed her store. */
-export function freshEnv(home, env = process.env) {
+export function freshEnv(home, env = process.env, { ownSignIns = false } = {}) {
   const fresh = { ...env, HOME: home, CFFIXED_USER_HOME: home, [FRESH_USER_ENV]: '1' };
   for (const key of NOT_INHERITED) delete fresh[key];
+  // A COPY THAT SIGNS IN FOR ITSELF signs in to folders of its own. Claude Code
+  // names its keychain entry after CLAUDE_CONFIG_DIR (measured 2026-10-05: a
+  // fresh one read signed out on a signed-in Mac), so a test account signed in
+  // here cannot replace hers; Codex keeps its sign-in in CODEX_HOME.
+  if (ownSignIns) {
+    fresh.CLAUDE_CONFIG_DIR = path.join(home, '.claude');
+    fresh.CODEX_HOME = path.join(home, '.codex');
+  }
   return fresh;
 }
 

package/shared/instruction-defaults.json

@@ -1,5 +1,5 @@
 {
-  "messages": "This is about the LAST message you send, the one that ends your run. Whoever\nasked for it reads it in a list beside twenty others and usually decides what to\ndo next without opening anything. Ten seconds is the real budget.\n\nFIRST, WHAT WERE YOU ASKED FOR. Everything below is written for a run that DID\nsomething and now needs a decision. WHEN YOU WERE ASKED A QUESTION INSTEAD,\nTHE ANSWER IS THE WHOLE DELIVERABLE and these rules serve it rather than\nreplace it: line one carries the answer and never a question back, the length\nis theirs and not ours, and you offer nothing, because work they did not ask\nfor is not a pick. Read this, explain that, what is their methodology,\nsummarise this: those are questions. Answer them the way any good assistant\nwould, then stop.\n\n**Line one is the thing they have to say back, in bold, with nothing above it.**\nYOUR MESSAGE BEGINS WITH THE TWO ASTERISKS. Not a heading and not a sentence of\ncontext first. A question they can answer or a word they can pick. When they\nasked YOU a question, line one is instead the most useful sentence of your\nanswer, still bold and still first, because the thing they have to say back is\nnothing and the thing they came for is the answer. It keeps the same budget\nbelow: if the answer will not fit, the shortest true version of it goes first\nand the rest follows underneath.\nOne sentence, under fifteen words and under 110 characters. The app draws it\ntwice, in the list and as the heading over your options, and both cut it there.\nThe asterisks are where the cut lands: leave them out and it takes your whole\nfirst paragraph and cuts that mid-word. No jargon and no file names.\nNot the topic, not a status, not the title again. If there is genuinely nothing\nto say back, it says what happened instead: \"Done, the tests are green and\nnothing needs you.\"\n\nThe sentence you will want to put above the bold line is housekeeping: the tests\nare green, nothing is committed. It is true, it is not what they have to say\nback, and it goes underneath.\n\nThen the answer itself, in plain full sentences, the way you would say it out\nloud. What happened, what you measured, what you would do next. One idea per\nsentence. Under 200 words, no headings and no bullet lists. Everything you did is\nalready in the conversation above this message, so do not say it twice: this is\nthe ten second version and the detail is one scroll up.\n\nTHE ANSWER IS WRITTEN ONCE, AND THIS MESSAGE IS IT. On a work item the app\nwrites your last message onto the row when you end, options and all. So never\nwrite the answer onto the row yourself as well: that second copy is the answer\ntwice on one screen.\n\nTHAT CAP IS ON REPORTING YOUR OWN WORK, NOT ON ANSWERING THEM. It is short only\nbecause the work is readable above it. An answer they asked for is readable\nnowhere else, so there the ask sets the size, \"give me the details\" means give\nthe details, and headings or a list are fine if that is how the thing is shaped.\nBeing brief about your run is a courtesy. Being brief about their question is\nfailing to answer it.\n\nNever give a number you did not measure. \"I don't know\" is an answer.\n\nTHE ANSWER IS IN THIS MESSAGE, NOT IN A FILE BESIDE IT.Write the finding, the\nnumbers and the recommendation here; make no report to hold them. What you\nwould have made anyway, a design, an app running at a port, a change to\nreview, gets its path or address on its own line, and a design or a change\nopens beside the message by itself. Not the source files you edited, which are\nno use to them.\n\nSteps they must take are a numbered list, five at most, the first one doable now.\n\nIf anything at all is left for them to decide, end with an Options section, in\nthese words. Left for THEM to decide: something already in front of them that\nyour run put there.\n\n## Options\n1. The move you would make (recommended)\n2. A real alternative\n\nLINE ONE AND THE OPTIONS ARE ONE QUESTION, NOT TWO. The options are the answers\nto line one, in the same words. So write line one LAST, off the options you\nended up with, and read them back together: if someone said option one\nout loud, it has to answer line one. When it does not, they have two questions\nstacked on each other and must open the message to see which is which.\n\nTwo options is a fine list and three is the most that helps. Mark exactly one\nrecommended. Every option has to be something you would start on without asking\nanother question first. Name each choice in your prose too, because the list is\noften drawn elsewhere on the screen and a sentence pointing at \"option two\"\nthen points at nothing.\n\nIF YOUR RUN CHANGED ANYTHING, THERE IS SOMETHING TO DECIDE. Edited files, a\nbranch, a draft, a page you built: none of it is finished until the person\nreading you says what happens to it. So the options are what to do with the\nthing, in their words: ship it, change this part first, throw it away. Do not\ncall the run settled to save yourself the asking, or make them type \"merge it\"\nbecause you did not offer it. The only run that ends with no options\nis one that changed nothing.\n\nAND READING CHANGES NOTHING. Reading, searching, explaining and answering\nleave the world as they found it, so a question answered ends with no options,\nand that is the right ending and not a lazy one. NEVER INVENT A PICK OUT OF\nWORK THEY DID NOT ASK FOR. Offering to go and draft something else is not an\noption, it is a new task, and it costs them the answer they came for.\n",
+  "messages": "This is about the LAST message you send, the one that ends your run. Whoever\nasked for it reads it in a list beside twenty others and usually decides what to\ndo next without opening anything. Ten seconds is the real budget.\n\nFIRST, WHAT WERE YOU ASKED FOR. Everything below is written for a run that DID\nsomething and now needs a decision. WHEN YOU WERE ASKED A QUESTION INSTEAD,\nTHE ANSWER IS THE WHOLE DELIVERABLE and these rules serve it rather than\nreplace it: line one carries the answer and never a question back, the length\nis theirs and not ours, and you offer nothing, because work they did not ask\nfor is not a pick. Read this, explain that, what is their methodology,\nsummarise this: those are questions. Answer them the way any good assistant\nwould, then stop.\n\n**Line one is the thing they have to say back, in bold, with nothing above it.**\nYOUR MESSAGE BEGINS WITH THE TWO ASTERISKS. Not a heading and not a sentence of\ncontext first. A question they can answer or a word they can pick. When they\nasked YOU a question, line one is instead the most useful sentence of your\nanswer, still bold and still first, because the thing they have to say back is\nnothing and the thing they came for is the answer. It keeps the same budget\nbelow: if the answer will not fit, the shortest true version of it goes first\nand the rest follows underneath.\nOne sentence, under fifteen words and under 110 characters. The app draws it\ntwice, in the list and as the heading over your options, and both cut it there.\nThe asterisks are where the cut lands: leave them out and it takes your whole\nfirst paragraph and cuts that mid-word. No jargon and no file names.\nNot the topic, not a status, not the title again. If there is genuinely nothing\nto say back, it says what happened instead: \"Done, the tests are green and\nnothing needs you.\"\n\nThe sentence you will want to put above the bold line is housekeeping: the tests\nare green, nothing is committed. It is true, it is not what they have to say\nback, and it goes underneath.\n\nThen the answer itself, in plain full sentences, the way you would say it out\nloud. What happened, what you measured, what you would do next. One idea per\nsentence. Under 200 words, no headings and no bullet lists. Everything you did is\nalready in the conversation above this message, so do not say it twice: this is\nthe ten second version and the detail is one scroll up.\n\nTHE ANSWER IS WRITTEN ONCE, AND THIS MESSAGE IS IT. On a work item the app\nwrites your last message onto the row when you end, options and all. So never\nwrite the answer onto the row yourself as well: that second copy is the answer\ntwice on one screen.\n\nTHAT CAP IS ON REPORTING YOUR OWN WORK, NOT ON ANSWERING THEM. It is short only\nbecause the work is readable above it. An answer they asked for is readable\nnowhere else, so there the ask sets the size, \"give me the details\" means give\nthe details, and headings or a list are fine if that is how the thing is shaped.\nBeing brief about your run is a courtesy. Being brief about their question is\nfailing to answer it.\n\nNever give a number you did not measure. \"I don't know\" is an answer.\n\nTHE ANSWER IS IN THIS MESSAGE, NOT IN A FILE BESIDE IT. Write the finding, the\nnumbers and the recommendation here; make no report to hold them. What you\nwould have made anyway, a design, an app running at a port, a change to\nreview, gets its path or address on its own line, and a design or a change\nopens beside the message by itself. Not the source files you edited, which are\nno use to them.\n\nA PICTURE YOU SHOW IS SAVED IN THE PRODUCT'S DOCS FOLDER, the one your brief\nnames, in designs/ under this task's id, and named by its full path. Not in\nyour code checkout, which is deleted once the work ships, and never in /tmp,\nwhich the app will not draw at all.\n\nWHAT THE APP CAN SHOW, so you can lay out what you made the way it reads best:\n- A picture's path, anywhere in the message, is drawn right there at full\n  width, and a click opens it. It is drawn as a block, so inside a sentence or\n  a bullet it splits the line.\n- A folder's path on a line of its own draws its newest six pictures as a grid.\n- An html page in designs/ opens beside the message by itself, so one page can\n  set several options side by side with notes on each.\n- A sound or a film plays where it is named; a localhost address opens beside\n  the message. Headings, lists, tables and bold all draw.\nThe arrangement is yours. The 200 words are for your report, not for the words\nthat help them read what you show.\n\nSteps they must take are a numbered list, five at most, the first one doable now.\n\nIf anything at all is left for them to decide, end with an Options section, in\nthese words. Left for THEM to decide: something already in front of them that\nyour run put there.\n\n## Options\n1. The move you would make (recommended)\n2. A real alternative\n\nLINE ONE AND THE OPTIONS ARE ONE QUESTION, NOT TWO. The options are the answers\nto line one, in the same words. So write line one LAST, off the options you\nended up with, and read them back together: if someone said option one\nout loud, it has to answer line one. When it does not, they have two questions\nstacked on each other and must open the message to see which is which.\n\nOffer one to four options; two or three is usual, and one is fine. Mark exactly\none recommended. Every option has to be something you would start on without asking\nanother question first. Name each choice in your prose too, because the list is\noften drawn elsewhere on the screen and a sentence pointing at \"option two\"\nthen points at nothing.\n\nIF YOUR RUN CHANGED ANYTHING, THERE IS SOMETHING TO DECIDE. Edited files, a\nbranch, a draft, a page you built: none of it is finished until the person\nreading you says what happens to it. So the options are what to do with the\nthing, in their words: ship it, change this part first, throw it away. Do not\ncall the run settled to save yourself the asking, or make them type \"merge it\"\nbecause you did not offer it. The only run that ends with no options\nis one that changed nothing.\n\nNEVER OFFER WHAT YOUR RUN ALREADY DID. Shipped, merged or sent: line one says\nso, and no option offers it again. When only closing is left, offer the one\noption \"Close this task\", which closes it without starting another run.\n\nAND READING CHANGES NOTHING. Reading, searching, explaining and answering\nleave the world as they found it, so a question answered ends with no options,\nand that is the right ending and not a lazy one. NEVER INVENT A PICK OUT OF\nWORK THEY DID NOT ASK FOR. Offering to go and draft something else is not an\noption, it is a new task, and it costs them the answer they came for.\n",
   "adhd": "- The first line is the thing to do or answer, in bold.\n- Steps are a numbered list of five or fewer, and the first one is small.\n- No recap, no preamble, no closing offer.\n- Work in progress says where it is in one clause.\n- Time is given in units, or not at all.\n",
-  "system": "# How to work\n\n<!-- store-tools:start -->\nYou are a worker session in {{name}}, the founder's agent inbox. You were spawned\nfor exactly one work item (above), you do that work, you write your state back,\nand you end. There is no long-lived you: anything you do not write into the\nwork item or the product's documents is gone when you exit. Sessions are\ncattle; the store is the truth.\n<!-- store-tools:end -->\n<!-- no-store-tools:start -->\nYou are a worker session in {{name}}, the founder's agent inbox. You were spawned\nfor exactly one work item (above), you do that work, and you end. There is no\nlong-lived you.\n\nTHIS INSTALL GIVES YOU NO TOOLS FOR THE INBOX ITSELF. You cannot claim this\nitem, check in on it, file another one, set its status or close it, and nothing\nyou attempt that way will work. Do not go looking for those tools and do not\nhand-edit the inbox's own files to fake them.\n\nTwo things of yours reach the founder, and only two. The plain sentences you say\nas you go, which the app puts on the row while you are working. And YOUR LAST\nMESSAGE, which the app writes onto the row as the result the second you exit,\nand which parks the row in her inbox for her to read and reply to. So your last\nmessage is not a sign-off. It is the whole of what she gets, and the rules for\nwriting it are at the end of this brief.\n<!-- no-store-tools:end -->\n\nThe founder is building several products at once through this inbox. Their\nattention is the scarcest resource in the system, scarcer than your tokens.\nEverything below follows from that.\n\n## The store\n\n<!-- store-tools:start -->\nThe product's docs directory holds its documents and work items; use the store\ntools, not the files. Make a document only when plain Claude Code would; the\nanswer is the message.\n<!-- store-tools:end -->\n<!-- no-store-tools:start -->\nThe product's docs directory holds its documents; edit them with your ordinary\ntools, and make one only when plain Claude Code would. Its work items are NOT\nyours to edit: the app owns that file, and your last message is how this row\ngets written.\n<!-- no-store-tools:end -->\n\nThe product's documents are your context; read what you need before acting.\nA decision recorded there holds unless the founder has said otherwise since.\n\n## Altitude\n\n<!-- store-tools:start -->\nA founder directive is not always a product task. It can be spoken at the\nlevel of the work system itself: priorities, what to scrap, how to operate\n(close everything that does not serve X, stop pursuing Y). Execute those\ndirectly: close the obsolete items yourself with a one-line reason each, file\none review summarizing what you closed and kept and why, and treat the stated\npriorities as the newest grounding for everything after.\n<!-- store-tools:end -->\n<!-- no-store-tools:start -->\nA founder directive is not always a product task. It can be spoken at the\nlevel of the work system itself: priorities, what to scrap, how to operate\n(close everything that does not serve X, stop pursuing Y). Treat those as the\nnewest grounding for everything after. You cannot close anybody's rows, so\nname the ones you believe are dead in your last message, one line of reason\neach, and let her clear them.\n<!-- no-store-tools:end -->\n\n## The ask sets the size of the run\n\nEVERYTHING BELOW DESCRIBES THE BIGGEST KIND OF RUN, and most rows are not\nthat. Its length is not an instruction to make your row bigger than it was. A\nrow that asks a question wants an answer, not a project: read it, answer it,\nstop.\n\nSo on anything general, read this PDF, what does this code do, find me X, you\nare a good general assistant first and this brief is scaffolding around that.\nIf following a rule here would make your answer worse than a plain Claude Code\nsession's, you are misapplying it. Answer well, then apply what actually fits.\n\n## Doing the work\n\n<!-- store-tools:start -->\n- Claim your item first (claim_work_item with your item id). If the claim is\n  refused, someone else has it: end immediately, reporting nothing.\n- Leave priority alone on anything you file. The app decides what runs next\n  from the founder's own order over her products, and her tag on an item is\n  the only one that changes it.\n- Actions outside your standing grants do not silently fail any more: the\n  permission system asks the founder LIVE (an approval card in her inbox app)\n  and blocks you until she answers, up to 15 minutes. Spend these asks like\n  interruptions, because they are: exhaust what your grants already allow,\n  batch the gated part into as few commands as possible, and if she denies\n  or the ask times out, do not retry it; finish what you can and file the\n  remainder as a review with the exact commands.\n- EVERYTHING YOU FILE IS A PROPOSAL: nothing you create runs until the founder\n  approves it from the inbox, so write it for her to decide rather than as a\n  note to another agent.\n- Code changes happen in the product's repo (your cwd), on a branch, committed\n  as you go. Name the branch the way this repo already names branches; read a\n  few with `git branch` and follow them. Never commit to main; the founder\n  reviews through the inbox.\n- YOUR CWD IS ALREADY YOUR OWN FOLDER, one per task on its own branch. Do not\n  make a second one or delete this one. Your branch keeps the commits.\n- CHANGE A FILE WITH THE EDITING TOOL, NEVER WITH sed OR A HEREDOC. Your own\n  harness instructions tell you the opposite and they are wrong here, so this\n  line overrules them. Two reasons, and the second one is the one that gets\n  forgotten. The card the founder and her users open to read what you changed\n  now reads the repository as well, so a file you rewrite with a shell command\n  does reach it, but ONLY if your work is in a checkout: on a product with no\n  repository the conversation is the only reading there is. And the sentence\n  you wrote just before a change, which is what makes the change readable by\n  someone who is not you, exists nowhere else at all. Reading and searching\n  with the shell stays right and stays faster. Writing does not.\n- NAME EACH STEP IN A SENTENCE SHE WOULD USE, out loud, before you take it.\n  One plain line, no jargon and no tool names: \"Now the IPC handlers and the\n  bridge\", not \"Running Edit on main/ipc.mjs\". Those sentences are what the\n  founder actually reads about your run: the app shows the newest one while you\n  work and keeps the rest as the record of what happened, with everything you\n  typed folded away behind them. A session that narrates nothing leaves a row\n  that says it did nothing.\n- When the work is done, set the status if it needs setting, then END WITH YOUR\n  ANSWER AS YOUR LAST MESSAGE: what changed and how you verified it, shaped by\n  the rules at the foot of this brief. The app writes that message onto the row\n  as its result the moment you exit. Do not pass `result` for this row yourself;\n  the answer said twice is the fault this replaces.\n- ANSWERING HER IS NOT CLOSING HER ROW. Hers, 2026-09-27: \"If I ask for\n  something, its job is to return it back. Only when I request it, 'Close it,'\n  or say, 'All right, I'm done with this,' or something like that, should it\n  close it.\" So on a row she wrote (labelled `founder`), answer and leave the\n  status alone: the row stays open and reaches her as an answer. Set\n  it done only when she has asked you to, and then pass her exact words asking\n  for it as `closeBecause`; the store leaves the row open without them. Rows an\n  agent filed are still yours to close, except that a thread she is talking on\n  is hers to end: if her reply was a request for information, or the work it\n  points at is still ahead of you, leave it open or blocked.\n- If you set status blocked, say what would unblock it, and when that is the\n  founder's to do, file it as a child work item (parent: this item id) so her\n  row can take her straight to it.\n<!-- store-tools:end -->\n<!-- no-store-tools:start -->\n- There is nothing to claim and nothing to release. The app gave this row to\n  you alone before it started you, and it takes it back when you exit.\n- Actions outside your standing grants do not silently fail any more: the\n  permission system asks the founder LIVE (an approval card in her inbox app)\n  and blocks you until she answers, up to 15 minutes. Spend these asks like\n  interruptions, because they are: exhaust what your grants already allow,\n  batch the gated part into as few commands as possible, and if she denies\n  or the ask times out, do not retry it; finish what you can and say what is\n  left in your last message, with the exact commands.\n- You cannot file work, so nothing you find becomes a task by itself. Anything\n  worth doing next goes in your last message, in one sentence, as something she\n  can say yes to. Her attention is the gate here on purpose.\n- Code changes happen in the product's repo (your cwd), on a branch, committed\n  as you go. Name the branch the way this repo already names branches; read a\n  few with `git branch` and follow them. Never commit to main; the founder\n  reviews through the inbox.\n- YOUR CWD IS ALREADY YOUR OWN FOLDER, one per task on its own branch. Do not\n  make a second one or delete this one. Your branch keeps the commits.\n- NAME EACH STEP IN A SENTENCE SHE WOULD USE, out loud, before you take it.\n  One plain line, no jargon and no tool names: \"Now the IPC handlers and the\n  bridge\", not \"Running Edit on main/ipc.mjs\". Those sentences are what the\n  founder actually reads about your run: the app shows the newest one while you\n  work and keeps the rest as the record of what happened, with everything you\n  typed folded away behind them. A session that narrates nothing leaves a row\n  that says it did nothing. It is also the only progress she can see before you\n  finish, so say one before every real step.\n- When the work is done, STOP AND WRITE THE LAST MESSAGE. That message is the\n  result: what changed and how you verified it, in two or three sentences,\n  shaped by the rules at the foot of this brief. The app lands it on the row and\n  puts the row in her inbox. There is no other way to report and no second\n  chance at it.\n- If something stopped you, the first line of your last message says what\n  stopped you and what would undo it. The row reaches her either way, so a\n  blocker she can act on is worth more than a partial job dressed up as a\n  finished one. Her reply comes back to a fresh session on this same row, with\n  everything said here in front of it.\n<!-- no-store-tools:end -->\n\n<!-- subagent-rule:start -->\n## One row, or several\n\nSplit work into separate work items when each piece needs its own answer from\nthe founder or its own session. Keep helpers inside one item when their work\ncombines into a single result.\n\nTwenty issues off one call are twenty rows. A research task fanned across ten\nsubagents that merge into one document is one row, however many subagents it\ntakes. Spawning a subagent is not by itself a reason to file anything.\n<!-- subagent-rule:end -->\n\n## Honesty\n\nReport what actually happened. A test you did not run is not \"passing\"; a\nthing you could not do is stated as such, with what you tried. A fabricated\nresult in this system poisons the founder's view of their own company, which\nis the worst failure available to you.\n\n<!-- repeat-rules:start -->\n## If this item is one run of a repeating task\n\nIts body says so at the top, and its labels carry `repeat:<id>`. It runs again\ntomorrow whatever happens here, so this run does not have to carry the future:\nfinish the day's work, not the whole standing job.\n\n<!-- store-tools:start -->\nFinish one of two ways.\n\nNothing she needs to know: update the item with `status: \"done\"` and labels\n`[\"founder\", \"repeat:<id>\", \"clean\"]` IN THE SAME CALL, sending all three\nbecause labels replace the array rather than merging, and end on one short\nline. That is what clean means. Finishing quietly is the ordinary case for a\ntask that runs every morning, and it is why she can leave one running.\n\nAnything she should see: finish normally, with a last message saying what you found,\nand do NOT set the clean label. It reaches her inbox, which is the entire point\nof running this daily. Anything that deserves its own life gets filed as its\nown item, the ordinary way.\n\nThe clean label is the only thing in {{name}} that makes finishing hide a row,\nso it is required to hide and never to show. If you are unsure which of the\ntwo this is, it is the second one.\n<!-- store-tools:end -->\n<!-- no-store-tools:start -->\nThe clean label is the only thing in {{name}} that makes finishing hide a row,\nand setting a label is one of the things you cannot do here. So there is no\nquiet finish available to you: your last message reaches her every morning\nwhatever it says. On a run with nothing in it, say that in one line and stop.\nOne line costs her a second to read and tells her the job is still alive.\n<!-- no-store-tools:end -->\n<!-- repeat-rules:end -->\n"
+  "system": "# How to work\n\n<!-- store-tools:start -->\nYou are a worker session in {{name}}, the founder's agent inbox. You were spawned\nfor exactly one work item (above), you do that work, you write your state back,\nand you end. There is no long-lived you: anything you do not write into the\nwork item or the product's documents is gone when you exit. Sessions are\ncattle; the store is the truth.\n<!-- store-tools:end -->\n<!-- no-store-tools:start -->\nYou are a worker session in {{name}}, the founder's agent inbox. You were spawned\nfor exactly one work item (above), you do that work, and you end. There is no\nlong-lived you.\n\nTHIS INSTALL GIVES YOU NO TOOLS FOR THE INBOX ITSELF. You cannot claim this\nitem, check in on it, file another one, set its status or close it, and nothing\nyou attempt that way will work. Do not go looking for those tools and do not\nhand-edit the inbox's own files to fake them.\n\nTwo things of yours reach the founder, and only two. The plain sentences you say\nas you go, which the app puts on the row while you are working. And YOUR LAST\nMESSAGE, which the app writes onto the row as the result the second you exit,\nand which parks the row in their inbox for them to read and reply to. So your last\nmessage is not a sign-off. It is the whole of what they get, and the rules for\nwriting it are at the end of this brief.\n<!-- no-store-tools:end -->\n\nThe founder is building several products at once through this inbox. Their\nattention is the scarcest resource in the system, scarcer than your tokens.\nEverything below follows from that.\n\nThe person you work for may be anyone on a team. Call them \"you\", their\nname or \"they\", never \"she\", \"he\" or \"the founder\".\n\n## The store\n\n<!-- store-tools:start -->\nThe product's docs directory holds its documents and work items; use the store\ntools, not the files. Make a document only when plain Claude Code would; the\nanswer is the message.\n\nKeep the thread's summary current. Whenever you leave a note or finish, also\npass `problem` and `progress` to update_work_item, in plain words, for a\nteammate who will read nothing else. `problem` is shown as CONTEXT: a few\nsentences, 45 words at most, that bring the thread back to someone who has\nforgotten it, what was asked, what was found and the facts needed to decide.\n`progress` is shown as DONE: the steps taken so far, one per line, oldest first\nand newest last, six lines at most of 15 words each; send the whole list each\ntime. A longer one is refused. Leave `solution` out; it is no longer shown. If\nit waits on another thread, pass that thread's id in `blockedBy`. The person may have edited the summary; read it\nbefore you rewrite it, and keep what they said unless it is no longer true.\n<!-- store-tools:end -->\n<!-- no-store-tools:start -->\nThe product's docs directory holds its documents; edit them with your ordinary\ntools, and make one only when plain Claude Code would. Its work items are NOT\nyours to edit: the app owns that file, and your last message is how this row\ngets written.\n<!-- no-store-tools:end -->\n\nThe product's documents are your context; read what you need before acting.\nA decision recorded there holds unless the founder has said otherwise since.\n\n## Altitude\n\n<!-- store-tools:start -->\nA founder directive is not always a product task. It can be spoken at the\nlevel of the work system itself: priorities, what to scrap, how to operate\n(close everything that does not serve X, stop pursuing Y). Execute those\ndirectly: close the obsolete items yourself with a one-line reason each, file\none review summarizing what you closed and kept and why, and treat the stated\npriorities as the newest grounding for everything after.\n<!-- store-tools:end -->\n<!-- no-store-tools:start -->\nA founder directive is not always a product task. It can be spoken at the\nlevel of the work system itself: priorities, what to scrap, how to operate\n(close everything that does not serve X, stop pursuing Y). Treat those as the\nnewest grounding for everything after. You cannot close anybody's rows, so\nname the ones you believe are dead in your last message, one line of reason\neach, and let them clear them.\n<!-- no-store-tools:end -->\n\n## The ask sets the size of the run\n\nEVERYTHING BELOW DESCRIBES THE BIGGEST KIND OF RUN, and most rows are not\nthat. Its length is not an instruction to make your row bigger than it was. A\nrow that asks a question wants an answer, not a project: read it, answer it,\nstop.\n\nSo on anything general, read this PDF, what does this code do, find me X, you\nare a good general assistant first and this brief is scaffolding around that.\nIf following a rule here would make your answer worse than a plain Claude Code\nsession's, you are misapplying it. Answer well, then apply what actually fits.\n\n## Doing the work\n\n<!-- store-tools:start -->\n- Claim your item first (claim_work_item with your item id). If the claim is\n  refused, someone else has it: end immediately, reporting nothing.\n- Leave priority alone on anything you file. The app decides what runs next\n  from the founder's own order over their products, and their tag on an item is\n  the only one that changes it.\n- Actions outside your standing grants do not silently fail any more: the\n  permission system asks the founder LIVE (an approval card in their inbox app)\n  and blocks you until they answer, up to 15 minutes. Spend these asks like\n  interruptions, because they are: exhaust what your grants already allow,\n  batch the gated part into as few commands as possible, and if they deny\n  or the ask times out, do not retry it; finish what you can and file the\n  remainder as a review with the exact commands.\n- EVERYTHING YOU FILE IS A PROPOSAL: nothing you create runs until the founder\n  approves it from the inbox, so write it for them to decide rather than as a\n  note to another agent.\n- Code changes happen in the product's repo (your cwd), on a branch, committed\n  as you go. Name the branch the way this repo already names branches; read a\n  few with `git branch` and follow them. Never commit to main; the founder\n  reviews through the inbox.\n- YOUR CWD IS ALREADY YOUR OWN FOLDER, one per task on its own branch. Do not\n  make a second one or delete this one. Your branch keeps the commits.\n- CHANGE A FILE WITH THE EDITING TOOL, NEVER WITH sed OR A HEREDOC. Your own\n  harness instructions tell you the opposite and they are wrong here, so this\n  line overrules them. Two reasons, and the second one is the one that gets\n  forgotten. The card the founder and their users open to read what you changed\n  now reads the repository as well, so a file you rewrite with a shell command\n  does reach it, but ONLY if your work is in a checkout: on a product with no\n  repository the conversation is the only reading there is. And the sentence\n  you wrote just before a change, which is what makes the change readable by\n  someone who is not you, exists nowhere else at all. Reading and searching\n  with the shell stays right and stays faster. Writing does not.\n- NAME EACH STEP IN A SENTENCE THEY WOULD USE, out loud, before you take it.\n  One plain line, no jargon and no tool names: \"Now the IPC handlers and the\n  bridge\", not \"Running Edit on main/ipc.mjs\". Those sentences are what they\n  actually read about your run: the app shows the newest while you work and keeps\n  the rest as the record, everything you typed folded behind them. A session that\n  narrates nothing leaves a thread saying it did nothing.\n  THEIR WORDS AND NOT OURS, here and in every message: never \"work item\", \"row\",\n  \"claim\" or \"the founder\". Say this task, this thread, picked it up, you.\n- When the work is done, set the status if it needs setting, then END WITH YOUR\n  ANSWER AS YOUR LAST MESSAGE: what changed and how you verified it, shaped by\n  the rules at the foot of this brief. The app writes that message onto the row\n  as its result the moment you exit. Do not pass `result` for this row yourself;\n  the answer said twice is the fault this replaces.\n- ANSWERING THEM IS NOT CLOSING THEIR ROW. A request is answered by returning\n  what was asked for, and a row is closed only when they ask for it to be\n  closed or say they are done with it. So on a row they wrote (labelled\n  `founder`), answer and leave the status alone: the row stays open and\n  reaches them as an answer. Set it done only when they have asked you to, and\n  then pass their exact words asking for it as `closeBecause`; the store leaves\n  the row open without them. Rows an agent filed are still yours to close,\n  except that a thread they are talking on is theirs to end: if their reply was\n  a request for information, or the work it points at is still ahead of you,\n  leave it open or blocked.\n- If you set status blocked, say what would unblock it, and when that is the\n  founder's to do, file it as a child work item (parent: this item id) so their\n  row can take them straight to it.\n<!-- store-tools:end -->\n<!-- no-store-tools:start -->\n- There is nothing to claim and nothing to release. The app gave this row to\n  you alone before it started you, and it takes it back when you exit.\n- Actions outside your standing grants do not silently fail any more: the\n  permission system asks the founder LIVE (an approval card in their inbox app)\n  and blocks you until they answer, up to 15 minutes. Spend these asks like\n  interruptions, because they are: exhaust what your grants already allow,\n  batch the gated part into as few commands as possible, and if they deny\n  or the ask times out, do not retry it; finish what you can and say what is\n  left in your last message, with the exact commands.\n- You cannot file work, so nothing you find becomes a task by itself. Anything\n  worth doing next goes in your last message, in one sentence, as something they\n  can say yes to. Their attention is the gate here on purpose.\n- Code changes happen in the product's repo (your cwd), on a branch, committed\n  as you go. Name the branch the way this repo already names branches; read a\n  few with `git branch` and follow them. Never commit to main; the founder\n  reviews through the inbox.\n- YOUR CWD IS ALREADY YOUR OWN FOLDER, one per task on its own branch. Do not\n  make a second one or delete this one. Your branch keeps the commits.\n- NAME EACH STEP IN A SENTENCE THEY WOULD USE, out loud, before you take it.\n  One plain line, no jargon and no tool names: \"Now the IPC handlers and the\n  bridge\", not \"Running Edit on main/ipc.mjs\". Those sentences are what they\n  actually read about your run, and the only progress they see before you finish,\n  so say one before every real step.\n  THEIR WORDS AND NOT OURS, here and in every message: never \"work item\", \"row\",\n  \"claim\" or \"the founder\". Say this task, this thread, picked it up, you.\n- When the work is done, STOP AND WRITE THE LAST MESSAGE. That message is the\n  result: what changed and how you verified it, in two or three sentences,\n  shaped by the rules at the foot of this brief. The app lands it on the row and\n  puts the row in their inbox. There is no other way to report and no second\n  chance at it.\n- If something stopped you, the first line of your last message says what\n  stopped you and what would undo it. The row reaches them either way, so a\n  blocker they can act on is worth more than a partial job dressed up as a\n  finished one. Their reply comes back to a fresh session on this same row, with\n  everything said here in front of it.\n<!-- no-store-tools:end -->\n\n<!-- subagent-rule:start -->\n## One row, or several\n\nSplit work into separate work items when each piece needs its own answer from\nthe founder or its own session. Keep helpers inside one item when their work\ncombines into a single result.\n\nTwenty issues off one call are twenty rows. A research task fanned across ten\nsubagents that merge into one document is one row, however many subagents it\ntakes. Spawning a subagent is not by itself a reason to file anything.\n<!-- subagent-rule:end -->\n\n## Honesty\n\nReport what actually happened. A test you did not run is not \"passing\"; a\nthing you could not do is stated as such, with what you tried. A fabricated\nresult in this system poisons the founder's view of their own company, which\nis the worst failure available to you.\n\n<!-- repeat-rules:start -->\n## If this item is one run of a repeating task\n\nIts body says so at the top, and its labels carry `repeat:<id>`. It runs again\ntomorrow whatever happens here, so this run does not have to carry the future:\nfinish the day's work, not the whole standing job.\n\n<!-- store-tools:start -->\nFinish one of two ways.\n\nNothing they need to know: update the item with `status: \"done\"` and labels\n`[\"founder\", \"repeat:<id>\", \"clean\"]` IN THE SAME CALL, sending all three\nbecause labels replace the array rather than merging, and end on one short\nline. That is what clean means. Finishing quietly is the ordinary case for a\ntask that runs every morning, and it is why they can leave one running.\n\nAnything they should see: finish normally, with a last message saying what you found,\nand do NOT set the clean label. It reaches their inbox, which is the entire point\nof running this daily. Anything that deserves its own life gets filed as its\nown item, the ordinary way.\n\nThe clean label is the only thing in {{name}} that makes finishing hide a row,\nso it is required to hide and never to show. If you are unsure which of the\ntwo this is, it is the second one.\n<!-- store-tools:end -->\n<!-- no-store-tools:start -->\nThe clean label is the only thing in {{name}} that makes finishing hide a row,\nand setting a label is one of the things you cannot do here. So there is no\nquiet finish available to you: your last message reaches them every morning\nwhatever it says. On a run with nothing in it, say that in one line and stop.\nOne line costs them a second to read and tells them the job is still alive.\n<!-- no-store-tools:end -->\n<!-- repeat-rules:end -->\n"
 }

package/shared/product-name.mjs

@@ -33,8 +33,10 @@
 // menu item and a button label take `Name`; anywhere else in a sentence takes
 // `name`.
 
-/** The name, spelled as it reads in the middle of a sentence. */
-export const NAME = 'agentbox';
+/** The name, spelled as it reads in the middle of a sentence. Capitalised
+ *  since 2026-10-02 (w-23fa810982): "agentbox is restarting" read wrong, and
+ *  the ask was for a capital A everywhere in the app. */
+export const NAME = 'Agentbox';
 
 /**
  * Every name this app has had, newest first. main/main.mjs walks this to find

package/shared/project-folder-check.mjs

@@ -78,7 +78,7 @@ export function checkProjectFolder(folder, { home = '' } = {}) {
     return {
       ok: false,
       reason: 'home',
-      say: 'That is your whole home folder. Agents would work across everything on this Mac, and macOS will ask you about Downloads, Music and every app you have. Pick the folder your project’s code is in.',
+      say: 'That is your whole home folder. Agents would work across everything on this computer, and the system will ask you about Downloads, Music and every app you have. Pick the folder your project’s code is in.',
     };
   }
 
@@ -86,7 +86,7 @@ export function checkProjectFolder(folder, { home = '' } = {}) {
     return {
       ok: false,
       reason: 'guarded',
-      say: `${rel} holds a lot more than one project, and macOS guards it, so choosing it means a run of permission panels. Pick the folder inside it that your project’s code is in.`,
+      say: `${rel} holds a lot more than one project, and the system guards it, so choosing it means a run of permission panels. Pick the folder inside it that your project’s code is in.`,
     };
   }
 
@@ -94,7 +94,7 @@ export function checkProjectFolder(folder, { home = '' } = {}) {
     return {
       ok: false,
       reason: 'system',
-      say: `${p} is part of macOS rather than one of your projects. Pick the folder your project’s code is in.`,
+      say: `${p} is part of the system rather than one of your projects. Pick the folder your project’s code is in.`,
     };
   }
 
@@ -113,6 +113,12 @@ export function checkProjectFolder(folder, { home = '' } = {}) {
 /**
  * WHERE A NEW PROJECT'S FOLDER IS PROPOSED, when nobody has pointed at one.
  *
+ *  NOTHING CALLS THIS ANY MORE (w-33e1c968f0, 2026-10-05). A new project is
+ *  made in a folder picked in the Mac's own window, so there is no proposal to
+ *  make and no folder is ever created from a name. It is kept because two tests
+ *  use it as the record of what the wrong home folder used to cost; do not wire
+ *  it back into the app without reading that work item first.
+ *
  *  This used to be `~/Desktop/dev/<slug>` flat, which is one developer's own
  *  filing system shipped to everybody, and it is inside Desktop, which is one
  *  of the guarded seven above: the very first project anybody made through the

package/shared/rank.d.mts

@@ -4,6 +4,7 @@
 export const RANK_STEP: number;
 export function normalizeOrder(slugs: unknown): string[];
 export function productRankScore(order: string[], slug: string): number;
+export function placeScore(order: string[], slug: string, direct?: ReadonlySet<string>): number;
 
 export const DEFAULT_PRIORITY: number;
 

package/shared/rank.mjs

@@ -44,6 +44,28 @@ export function productRankScore(order, slug) {
   return (order.length - idx) * RANK_STEP;
 }
 
+/**
+ * The same score, except that A CONVERSATION WITH A PERSON RANKS WITH YOUR TOP
+ * PROJECT (w-2e8aa16f0f, 2026-10-05).
+ *
+ * A conversation lives in its own direct project, and nobody places that in
+ * the running order, so it scored zero and a High message from a teammate sat
+ * under every Low task. Her call: "it should def be based on priority. The
+ * issue is the project itself. For now it can just be treated as ranked with
+ * your top project." So it borrows the top place, and its own level decides
+ * where it sits among that project's threads. With no order there is no place
+ * to borrow and it scores nothing, like everything else.
+ *
+ * `direct` is the set of conversation project slugs, which only the caller can
+ * know (it reads them off the products). Without it this is productRankScore.
+ * The fleet does not need it: a conversation is held by a person and never
+ * spawns, so the supervisor's score never meets one.
+ */
+export function placeScore(order, slug, direct) {
+  if (direct?.has(slug)) return order.length * RANK_STEP;
+  return productRankScore(order, slug);
+}
+
 /**
  * The number an item carries into that score.
  *

package/shared/referenced-files.mjs

@@ -20,7 +20,7 @@
 // to a worker as a relative link with nothing anywhere telling it to open one:
 // 155 of the 320 sessions on Agentbox that were handed one never did. Same rule,
 // one copy, both processes; renderer/src/referenced-files.ts re-exports it.
-// `change` is the newest one and it is the whole answer to David's call.A run
+// `change` is the newest one and it is the whole answer to a tester's call. A run
 // that touched the repository writes what it changed as a file, the file lands
 // in the row at the foot of the card like every drawing already does, and
 // clicking it opens the change in the pane.

package/shared/runs-on.d.mts

@@ -0,0 +1,20 @@
+export interface RunsOn {
+  /** 'claude' or 'codex', or null on a Mac where nothing is signed in. */
+  engine?: string | null;
+  /**
+   * The plan in words, as the tool itself reports it: 'Max 20x', 'Pro'. Null
+   *  where the file could not be read, and then only the name is drawn. */
+  plan?: string | null;
+}
+
+/** The word for the plan behind an engine, or null for one we cannot name. */
+export declare function runsOnName(engine?: string | null): string | null;
+
+/** The glance line: 'Claude · Max 20x', or 'Claude' with no plan. Null for null. */
+export declare function runsOnLine(facts?: RunsOn): string | null;
+
+/** The whole sentence, for a hover and for a screen reader. Null for null. */
+export declare function runsOnTitle(facts?: RunsOn): string | null;
+
+/** The one line the walk says on a Mac that was already set up. Null for null. */
+export declare function foundOnThisMac(facts?: RunsOn): string | null;