agentbox-app 0.1.6 → 0.1.11

package/briefs/writing-rules.md

@@ -1,33 +1,30 @@
-## She reads your opening in the list, not in the message
+## They read your opening in the list, not in the message
 
 The inbox row shows a title and, under it, the first couple of lines of what
 you wrote: the result on anything finished, the body on anything still open.
 Two lines, at reading size. So those lines are no longer a preview of the
-message; for most rows they ARE the message, and she decides from them without
-opening anything.
+message; for most rows they ARE the message, and the reader decides from them
+without opening anything.
 
 The row used to carry small tags saying `blocked`, `ask`, `review`, `answered`.
 They are gone, because each named a category your own sentence says better.
 Nothing labels your row now. If the row does not say it, it is not said.
 
 What that asks of you is only this: open with what happened and what you need
-from her, in plain sentences, before any context or reasoning. "CI is green
+from them, in plain sentences, before any context or reasoning. "CI is green
 and staging is verified. Approve to deploy to production?" "Fixed the event
 tracking and backfilled the last 7 days. Needs your yes to ship." Not
-"Investigated the tracking discrepancy across several files", which tells her
+"Investigated the tracking discrepancy across several files", which tells them
 you were busy.
 
-ONE SENTENCE, AND IT FITS. This line said two sentences and 165 characters for
-a long time and both numbers were wrong. 112 characters reach the row
-(SUMMARY_BUDGET, list-rules.ts), and the clip keeps whole sentences only, so a
-second sentence is not a second line: unless both of them fit inside 112
-together, the second one is thrown away and nobody ever sees it.
+ONE SENTENCE, AND IT FITS. 112 characters reach the row (SUMMARY_BUDGET,
+list-rules.ts), and the clip keeps whole sentences only, so a second sentence
+is not a second line: unless both of them fit inside 112 together, the second
+one is thrown away and nobody ever sees it.
 
 That opening is drawn a SECOND time, as the heading over your own options, and
-cut again there. Measured across her fifteen projects on 2026-08-29: of 450
-messages that offered her a pick, the heading was cut on 303, at a median
-opening length of 263 characters. She could not finish reading the question
-her own options were answers to.
+cut again there, so a long opening leaves the reader unable to finish the
+question their own options are answers to.
 
 So the first sentence carries the whole point and stops under 112 characters.
 A clipped row is not a formatting problem, it is an opening that spent its two
@@ -35,69 +32,60 @@ lines on background. Everything you cut is still in the body, one click away,
 which is where the reasoning belongs.
 
 You are the only one who can write this, because you are the only one who knows
-what she is deciding. Nothing downstream can recover it from an opening that
+what they are deciding. Nothing downstream can recover it from an opening that
 starts with background.
 
 ## The answer goes in the message. Make a file only when Claude Code would anyway
 
-Then, asked whether the report should open on the side: "why do you even need
-the report? Why not just put that in the chat? Only some things in rare cases
-need artifacts. For instance, let's say you're showing an app and it's running
-at a port, or you've created designs. If you want to review code, those should
-all be logical artifacts that open on the side, but otherwise you really don't
-need it. I don't want you to be strict and say not to create artifacts, but
-the default behavior of Claude Code is good. I feel like our application
-pushes these agents to make a lot more artifacts than they naturally would."
-
-Measured on her store that day: of 1,880 rows an agent had written on, 641
-named a file that opened beside the card by itself, and on 466 of those it was
-a page of words, a report or a spec or a markdown file, each one a second copy
-of what the message should have said. Those were written because a brief asked
-for them. It no longer does.
+Most answers need no artifact at all. A few things are naturally opened on the
+side: an app running at a port, designs you have made, code to review. The
+default behavior of Claude Code is right, and this brief does not push you to
+make more files than it would. A report page is a second copy of what the
+message should have said.
 
 So: answer the way you would in a plain Claude Code session. The finding, the
 numbers that decide it and the recommendation are the message, in sentences.
 No report page, summary file or write-up is made to hold them, and nothing in
 this brief asks for one. The files you do make are the ones you would make
-anyway: a design she asked for, an app running at a port for her to open, a
-change for her to review. Name each once, on its own line, and the app opens a
+anyway: a design they asked for, an app running at a port for them to open, a
+change for them to review. Name each once, on its own line, and the app opens a
 design or a change beside the card by itself. What the next session needs goes
-in `decisions.md`, which she never reads.
+in `decisions.md`, which they never read.
 
-And how much to say, which she pointed at the i-have-adhd skill for. The
-message is shaped so she can act on it, not just shortened:
+And how much to say. The message is shaped so they can act on it, not just
+shortened:
 
 - Line one is the thing to do or to say back, as the rest of this file already
   asks. Nothing above it.
-- If she has steps to take, they are a numbered list, one bounded action each,
+- If they have steps to take, they are a numbered list, one bounded action each,
   in the order to do them, the first small enough to start on now. Five steps
-  at most: past five, split "now" from "later" and give her the now.
-- Every list she reads is at most five items. Five ranked beats ten unranked.
-- No recap of what she said or what a previous session did, no preamble saying
+  at most: past five, split "now" from "later" and give them the now.
+- Every list they read is at most five items. Five ranked beats ten unranked.
+- No recap of what they said or what a previous session did, no preamble saying
   what you are about to do, no closing offer. Start with the answer and end
   when the answer ends.
-- A run in the middle of something says where it is in one clause, because she
+- A run in the middle of something says where it is in one clause, because they
   cannot hold that between messages.
-- What now works is stated in concrete terms she can try, not buried in a
+- What now works is stated in concrete terms they can try, not buried in a
   recap: "the pane stays shut on a report; open any card that names one."
 - A time estimate is in units, "about ten minutes" or "an afternoon", or it is
   left out. "Some work" says nothing.
 - An error is stated as cause and fix, matter of fact. No "unfortunately", no
   apology, no drama.
 
-## NEVER WRITE AN EM DASH IN ANYTHING SHE READS
+## NEVER WRITE AN EM DASH IN ANYTHING THEY READ
 
 
-She said it about the app's own copy, where seven strings carried one and now
-carry none. It applies at least as much to you, because the em dashes she reads
-most are in cards agents wrote her.
+The app's own copy carries none, and the same holds for you, because most of
+the em dashes a reader meets are in cards agents wrote them.
 
-So: no `—` in a title, an opening line, a body, a note, a result or an option.
-Not in a document she opens either. A comma does the same work, and a full stop
-usually does it better, which is the same advice this brief already gives for
-the body of a question: if a sentence needs a dash, try splitting it instead.
+So: no em dash in a title, an opening line, a body, a note, a result or an
+option. Not in a document they open either. A comma does the same work, and a
+full stop usually does it better, which is the same advice this brief already
+gives for the body of a question: if a sentence needs a dash, try splitting it
+instead.
 
-This is about what she reads, not about your code. Comments and commit messages
+This is about what they read, not about your code. Comments and commit messages
 are yours and nobody is counting the dashes in them.
 
 ## Asking the founder
@@ -110,27 +98,20 @@ can see later beats an interruption now.
 Before you file one, the test that matters: IS THIS A DECISION, OR IS IT WORK?
 A finding you are confident about is work, however important. If you have
 already written "I recommend" and you would not be surprised to be told yes,
-you are asking permission to do your job. Do it, and let the digest tell her.
+you are asking permission to do your job. Do it, and let the digest tell them.
 
 And ONE ASK PER SESSION, consolidated. If your session found four things worth
-her judgment, they are four parts of one message, not four rows; she reads
+their judgment, they are four parts of one message, not four rows; they read
 rows, not sessions, so four rows is four interruptions carrying one context.
-This has a worked example: on 2026-08-06 one panel-read session filed four
-questions in 62 seconds. One was a genuine taste call. One was nine copy
-defects with a recommendation to fix them all, which is a task list. She saw
-four interruptions and said her feed was "filled with ideas".
+A list of defects with a recommendation to fix them all is a task list, not a
+question.
 
 WHEN YOU END A ROW, REWRITE ITS TITLE AND ITS OPENING. A result is not a
-correction; it is an appendix, and she reads top to bottom. w-fe3c042d00 is the
-case: you were asked to merge a branch, she rejected the premise, and the
-closing session wrote an honest result saying "there is nothing here left to
-build or merge" while leaving the title "Merging is the only thing left" and an
-opening paragraph that still said "I recommend merging it", above three options
-to pick. Every word above the result was false, and she had to read all of it to
-reach the one paragraph that was true: "it didn't update its context until the
-end, so it feels like it stays the same, except it changes the result, which is
-not correct. If something changes, all of this content should rerender, and the
-most important part is the summary right under the text" (2026-08-10).
+correction; it is an appendix, and they read top to bottom. A title and opening
+that still say what the row said before the answer changed it are false, and
+the reader has to read all of that to reach the one paragraph that is true. If
+something changes, everything above the result has to change with it, and the
+summary right under the title matters most.
 
 So a patch that sets status also patches `title` and `body` whenever the
 answer changed what they say. The title states what happened, and the opening
@@ -139,46 +120,36 @@ chosen come out. The reading pane now leads with your result on a row an agent
 closed, which limits the damage but cannot make a stale title true; only you
 can.
 
-And READ WHAT IS ALREADY WAITING ON HER BEFORE YOU FILE. Sessions do not
+And READ WHAT IS ALREADY WAITING ON THEM BEFORE YOU FILE. Sessions do not
 remember each other, so the same blocker is discovered fresh each time and asked
-again, with the same recap under a new title. To her that is an unread row which
-turns out to say what the last one said, and she has to read the whole thing to
-find that out: "oftentimes it'll send me the next message without any new
-context, the summary is exactly the same, it's a waste of time because I have to
-read through everything before I get to the point" (2026-08-10). Never
-duplicate an item already waiting on the founder.
-
-If what you need is already sitting in her inbox, you are not blocked on her,
+again, with the same recap under a new title. To them that is an unread row which
+turns out to say what the last one said, and they have to read the whole thing
+to find that out. Never duplicate an item already waiting on the founder.
+
+If what you need is already sitting in their inbox, you are not blocked on them,
 you are blocked on the thing you were blocked on last time, and a second row
 does not move it. Add what you learned to that row and go do something the
-answer does not gate. A follow-up earns a new row when it carries something she
-has not seen: a new option, a fact that changes the decision, a deadline that
+answer does not gate. A follow-up earns a new row when it carries something they
+have not seen: a new option, a fact that changes the decision, a deadline that
 arrived. "Where we were" is where that shows, so if you cannot write one that
 says what actually changed, that is the signal there is no row to file.
 
-Her standing words on all of this, worth reading as the point rather than a
-rule: it "is meant to be a self-driving product, and it's only meant to notify
-me when it's stuck or with bi-daily digests". Stuck is the bar for a new row.
+The point of all of this, rather than a rule: the product is meant to drive
+itself, and to notify them only when it is stuck or in a periodic digest. Stuck
+is the bar for a new row.
 
-ONE ASK, ONE ROW: CONTINUING A THREAD MEANS REWRITING THE ROW SHE IS ON. This
+ONE ASK, ONE ROW: CONTINUING A THREAD MEANS REWRITING THE ROW THEY ARE ON. This
 is the same rule from the other end, and it is the one that actually stops the
 duplicates, because everything above asks you to notice a repeat while this
 stops you making one. Every round of a conversation used to open a new row
 underneath the last, and each of those rows is separately eligible to reach
-her. Measured across her real store on 2026-08-14: in one product alone, 8 of
-17 live conversations had put more than one row into her inbox that week, and
-the oldest chain had put in 22. That is how one topic reaches her three times
-under three headings, each looking new. On the evening of 08-13, three
-different rows in three different conversations each told her the app needed a
-restart, and two sat side by side for 3.2 hours. Her yes to fixing it,
-2026-08-14: "All three as fine so long as it won't kill a bunch of threads we
-need/legit access to."
+them. That is how one topic reaches them several times under several headings,
+each looking new.
 
 So: the next round goes ON the live row. A NEW row is for a genuinely
-different question, which she has asked to keep: "if there is a seemingly
-redundant message that actually has something critical in it and has a
-question that needs to be unblocked, that's totally fine." Redundancy is not
-the defect. A row that asks nothing is.
+different question: a row that looks redundant but carries something critical
+and a question that needs unblocking is fine. Redundancy is not the defect. A
+row that asks nothing is.
 
 Three mechanics, because sessions rediscover them at a cycle each:
 
@@ -188,55 +159,44 @@ Three mechanics, because sessions rediscover them at a cycle each:
   `{"id":…,"ts":…,"source":"agent","patch":{"title":…,"body":…}}`. Do it
   BEFORE the update that sets status, and read it back; never assume it took.
 - THE LEDGER IS NOT IN THE PRODUCT FOLDER AND YOU MUST NOT GO LOOKING FOR ONE
-  THERE. Since 2026-08-27 the app keeps its own records in its own home, the way
-  Claude Code does, so that nothing of ours lands in the folder she uploads files
-  to. The path is
+  THERE. The app keeps its own records in its own home, the way Claude Code
+  does, so that nothing of ours lands in the folder they upload files to. The
+  path is
   `$ASTRAL_HOME/projects/<the product folder's full path, with every character
   that is not a letter or a digit turned into a dash>/work-items.jsonl`. The app
   sets `ASTRAL_HOME` for the sessions it starts, and it is `~/.astral` when it is
   unset (`main/store/home.mjs`). Print that path and read it before you append to
   it. A session that hunts for a ledger instead finds one sitting beside the
   ACCOUNT folder, one level above the product, left over from when there was one
-  ledger per account: nothing reads that file and nothing sweeps it. Measured on
-  her store 2026-08-27, three hours after the move: seven lines in it, four of
-  them written that afternoon, every one a title or body rewrite meant for her.
+  ledger per account: nothing reads that file and nothing sweeps it.
   A stray `work-items.jsonl` written INSIDE the product folder is folded onto the
   end of the real one the next time anything touches the store, so that mistake
   survives. The account-level one does not, and it fails silently either way.
-- YOU CANNOT REWRITE A FIELD SHE WROTE. The fold is per field and the founder
+- YOU CANNOT REWRITE A FIELD THEY WROTE. The fold is per field and the founder
   outranks an agent, so a patch against a title or body whose `wrote.<field>.
   source` is `founder` is accepted and then ignored, silently. Check that map
-  first. On a row she wrote, your RESULT is the only place you can speak, and
+  first. On a row they wrote, your RESULT is the only place you can speak, and
   the list shows a result once it is newer than the body. If the round needs a
-  heading she cannot be given, that is when a child row is the honest answer,
+  heading they cannot be given, that is when a child row is the honest answer,
   and then the child carries the ask and the parent gets finished in the same
   session with a one-line reason.
 
-END A RUN WITH A PICK, NOT A PARAGRAPH SHE HAS TO ANSWER BY HAND.
-
+END A RUN WITH A PICK, NOT A PARAGRAPH THEY HAVE TO ANSWER BY HAND.
 
-She is right, and it was not workers going quiet. The channel had closed. The
-picker read the offer off the BODY alone, and the body is the one field the fold
-above will not let you write on a row she composed. Measured in her {{name}} store
-that morning: of 77 results written in the three days to then, 41 sat on rows she
-wrote herself, and exactly ONE row in that window could draw a picker at all. Of
-all 163 results ever written on that product, not one carried an offer, because
-writing one there did nothing.
 
-The picker now reads the offer off whatever the pane is showing her: the result,
-else the checkpoint, else the body. And an offer written after her last reply is
-live, where before her Tuesday answer buried a Friday offer for good. So the
-channel is open at both ends and the rest is yours:
+The picker reads the offer off whatever the pane is showing them: the result,
+else the checkpoint, else the body. And an offer written after their last reply
+is live. So the rest is yours:
 
-IF YOUR RESULT LEAVES HER ANYTHING TO SAY BACK, IT ENDS WITH AN `## Options`
-SECTION. The same shape a question uses, the same single `(recommended)`. She
-answers with one key, the pick reopens the row and briefs the next session with
-her choice, so a whole round trip costs her a keystroke instead of a sentence.
+IF YOUR RESULT LEAVES THEM ANYTHING TO SAY BACK, IT ENDS WITH AN `## Options`
+SECTION. The same shape a question uses, the same single `(recommended)`. They
+answer with one key, the pick reopens the row and briefs the next session with
+their choice, so a whole round trip costs them a keystroke instead of a sentence.
 
-- The commonest one, and the one she named: work is built and waiting on her.
+- The commonest one: work is built and waiting on them.
   `1. Merge it (recommended)` / `2. Change the wording first` / `3. Leave it on
-  the branch.` She should not have to type "merge it" again.
-- Every option is a real next move you would start on without asking her
+  the branch.` They should not have to type "merge it" again.
+- Every option is a real next move you would start on without asking them
   anything else. Two is a fine list. Never pad it to three.
 - A run that genuinely settles the matter offers nothing, and that is correct.
   No offer beats an invented one.
@@ -251,8 +211,8 @@ like this:
 
 ```
 The title and the body's opening lines are ONE message, read top to bottom.
-The founder told us she reads the title and the first paragraph as a unit,
-and when the paragraph restates the title she has read the same thing twice;
+The reader takes in the title and the first paragraph as a unit, and when
+the paragraph restates the title they have read the same thing twice;
 never write a subject line plus a summary of it. The title says what this is
 about ("Analytics can't tell us who pays. I want to add four events."). The
 body then opens DIRECTLY with what the title could not hold: the one thing
@@ -261,8 +221,8 @@ heading, no heading at all above it, no restating the title in different
 words. Two or three short sentences in plain words, ONE idea per sentence.
 No jargon, no parentheses, no dashes, no clause chains; if a sentence needs
 a comma, try splitting it instead. Write it the way you would say it out
-loud to a busy friend. The test: title plus opening, read once, and she
-knows what is being decided and what you think. If you cannot write that,
+loud to a busy friend. The test: title plus opening, read once, and they
+know what is being decided and what you think. If you cannot write that,
 you are not ready to interrupt the founder.
 
 ## Where we were
@@ -298,13 +258,12 @@ with your question and the founder's reply in its brief.
 
 If you write a document alongside a question or review (the options write-up,
 the draft spec), its FIRST LINE must say what it is waiting on: "Status:
-proposed, awaiting <item-id>. Nothing here is decided." The document that
-caused this system's worst incident omitted that line and opened by borrowing
-the founder's authority instead; the next session had no way to tell it from
-a record of a decision. Whoever enacts the founder's eventual answer updates
-the line to say what was chosen.
+proposed, awaiting <item-id>. Nothing here is decided." Without that line, a
+document that opens by borrowing the founder's authority cannot be told apart
+from a record of a decision by the next session. Whoever enacts the founder's
+eventual answer updates the line to say what was chosen.
 
-Two things about answers, learned the hard way. An answer settles exactly what
+Two things about answers. An answer settles exactly what
 the question asked and nothing more: "native, not web" decides the shell, it
 does not commission the app. And "does not depend on the answer" is a narrow
 gate, not a license: when the open questions are about what the product IS

package/main/account-discovery.mjs

@@ -1,10 +1,10 @@
 // THE ACCOUNTS AGENTBOX RUNS ON ARE THE ONES ON THE DISK, not the ones somebody
 // remembered to type into a config file.
 //
-// It was logged in. ~/.claude-work held work@example.com, signed in at 15:19
-// that afternoon, and the fleet had been stopped since 15:14 on a personal
-// subscription that had hit its WEEKLY limit — three days of nothing, with a
-// rested paid account on the same disk. The register of accounts was the
+// Picture someone with two subscriptions: a second account signed in through
+// its own CLAUDE_CONFIG_DIR, and a first one that has hit its WEEKLY limit.
+// The fleet stops for days, with a rested account on the same disk the whole
+// time. The register of accounts was the
 // hand-written `authProfiles` key in zero.config.json, which nothing in the app
 // writes and nothing in the app checks against reality, so an account set up
 // the ordinary way (a new CLAUDE_CONFIG_DIR, a /login) was invisible BY
@@ -18,24 +18,25 @@
 //   - A folder under the home directory named `.claude` or `.claude-<anything>`
 //     that holds a login is an account.
 //   - IT ONLY COUNTS IF ITS SUBSCRIPTION IS NEW. Two folders holding one
-//     account is her exact setup (~/.claude and ~/.claude-second were both
-//     you@example.com), and counting it twice sends two thirds of every spawn
-//     round to an account that is already at its limit. The test is on
+//     account is a real setup (~/.claude and ~/.claude-second both signed in
+//     as the same person), and counting it twice sends two thirds of every
+//     spawn round to an account that is already at its limit. The test is on
 //     `accountUuid`, the id Claude Code stores for the subscription itself,
-//     never on the email — she made that point herself and she was right.
-//   - NOTHING SHE CONFIGURED IS EVER DROPPED OR REORDERED. Her file is a
-//     decision; this is only a discovery. Discovered accounts go after hers.
-//   - A folder with no login is not an account. Two of hers are exactly that
-//     (~/.claude-swap-backup, ~/.claude-worktrees) and neither is a place to
-//     send her work.
+//     never on the email, because one email can hold more than one subscription.
+//   - NOTHING THE USER CONFIGURED IS EVER DROPPED OR REORDERED. The config is a
+//     decision; this is only a discovery. Discovered accounts go after the
+//     configured ones.
+//   - A folder with no login is not an account. Folders such as
+//     ~/.claude-swap-backup or ~/.claude-worktrees are exactly that, and
+//     neither is a place to send work.
 //
-// WHY THERE IS NO REFRESH BUTTON, which was her own question. It is not costly.
+// WHY THERE IS NO REFRESH BUTTON. It is not costly.
 // The directory listing is cached on the home folder's own mtime, so the
 // readdir happens once and then only when a folder appears or disappears; the
 // login inside each candidate is read through `accountIdentity`, which is
-// already cached on that file's mtime. Measured on her own home folder on
-// 2026-08-31 — 200 entries, 9 .claude-shaped, 5 of them directories, 3 holding
-// a login — a warm call costs 0.029 ms, and it is asked on the supervisor's
+// already cached on that file's mtime. Measured on a home folder of 200
+// entries, 9 .claude-shaped, 5 of them directories, 3 holding a login, a
+// warm call costs 0.029 ms, and it is asked on the supervisor's
 // 15-second tick. A button would only be a thing to remember to press.
 //
 // THE DELIBERATE LIMIT: one level, under the home directory only. A profile
@@ -103,9 +104,9 @@ export function discoverProfiles({ home = os.homedir() } = {}) {
 }
 
 /**
- * THE PROFILES THE FLEET ACTUALLY RUNS ON: hers first, exactly as she wrote
- *  them, then any subscription found on the disk that none of hers is already
- *  running on.
+ * THE PROFILES THE FLEET ACTUALLY RUNS ON: the configured ones first, exactly
+ *  as written, then any subscription found on the disk that none of the
+ *  configured ones is already running on.
  *
  *  Profiles are the strings the rest of the app has always used: the literal
  *  'default' for ~/.claude (which is what spawning with no CLAUDE_CONFIG_DIR

package/main/account-tooling.mjs

@@ -182,16 +182,15 @@ function list(names) {
 //
 // The Accounts page named its two rows `default` and `.claude-second`, which
 // are folders, not people. So there was no way to tell from the screen which
-// subscription either row was running on, and on 2026-08-29 that cost her the
-// second one. The page said the second account was signed out. She did exactly
-// what it told her to do, ran the command and typed /login at 1:47pm, and the
-// browser was already signed in as her personal account, so the login handed
-// that one back. Her work account, work@example.com, had been in that folder
-// since at least 08-23 and was gone by 1:50pm, replaced by the same account the
-// first row was already using. Measured off the config backups the CLI itself
-// writes. Nothing on the page changed when it happened, because nothing on the
-// page had ever said whose account it was, which is also exactly what she
-// reported: "Idk which is logged in nothing changed in settings".
+// subscription either row was running on, and that can cost a person their
+// second account. Say the page reports the second account signed out. They do
+// exactly what it tells them to do, run the command and type /login, and the
+// browser is already signed in as the account the first row uses, so the login
+// hands that one back. The other account that had been in that folder is gone,
+// replaced by the same account the first row was already using; the config
+// backups the CLI itself writes show the swap. Nothing on the page changes
+// when it happens, because nothing on the page had ever said whose account it
+// was: "Idk which is logged in nothing changed in settings".
 //
 // One line of the answer, read from the file Claude Code keeps its own account
 // in. Null when the folder holds no login, which reads on the page as the one

package/main/agent-activity.mjs

@@ -1,7 +1,7 @@
 // Ephemeral, local status from matched tool start/end events. A persisted trace
 // is history and cannot prove a command is still running. Nothing here executes
 // commands, records reasoning, or changes worker permissions.
-import { plainCommand, shortPath } from '../shared/work-lines.mjs';
+import { commandWork, isBookkeeping, plainCommand, shortPath } from '../shared/work-lines.mjs';
 const clean = value => typeof value === 'string' ? value.replace(/\s+/g, ' ').trim() : '';
 function add(session, id, label, detail) {
   if (!id || !label) return false;
@@ -11,12 +11,43 @@ function add(session, id, label, detail) {
   return true;
 }
 function finish(session, id) { return session.activeTools?.delete(id) ?? false; }
-function clear(session) { const changed = !!session.activeTools?.size; session.activeTools?.clear(); return changed; }
+// A turn ending clears what it was doing, but not a background job: that is
+// still running, and the session is kept open waiting for it
+// (main/claude-input.mjs), so the row keeps saying what it waits on.
+function clear(session) {
+  let changed = false;
+  for (const [id, entry] of session.activeTools ?? []) {
+    if (entry.background) continue;
+    session.activeTools.delete(id);
+    changed = true;
+  }
+  return changed;
+}
+function backgroundJobs(session, tasks) {
+  const pending = session.activeTools ??= new Map();
+  const live = new Set(tasks.map(t => `bg:${t?.task_id}`));
+  let changed = false;
+  for (const [id, entry] of pending) if (entry.background && !live.has(id)) { pending.delete(id); changed = true; }
+  for (const task of tasks) {
+    const description = clean(task?.description);
+    const plain = commandWork(description);
+    const label = plain ? `${plain.doing} ${plain.subject}`.trim() : `Waiting on: ${description || 'a background job'}`;
+    if (add(session, `bg:${task?.task_id}`, label, description)) { pending.get(`bg:${task?.task_id}`).background = true; changed = true; }
+  }
+  return changed;
+}
 export function currentActivity(session) { return [...(session.activeTools?.values() ?? [])]; }
 function toolLabel(name, input) {
   const command = clean(input.command);
   const file = clean(input.file_path ?? input.path);
-  if (name === 'Bash') return ['Running ' + (plainCommand(command) || 'command'), input.command ?? ''];
+  if (name === 'Bash') {
+    // WHAT IT IS DOING, IN WORDS, when the whole command is recognised. The
+    // line under a running row is the same event as the line in the thread
+    // above it, read in the present tense (`doing`, shared/work-lines.mjs).
+    const plain = commandWork(command);
+    if (plain) return [`${plain.doing} ${plain.subject}`.trim(), input.command ?? ''];
+    return ['Running ' + (plainCommand(command) || 'command'), input.command ?? ''];
+  }
   if (['Read','Write','Edit','MultiEdit'].includes(name)) return [`${name === 'Read' ? 'Reading' : name === 'Write' ? 'Writing' : 'Editing'} ${shortPath(file) || 'file'}`, file];
   if (['Grep','Glob','WebSearch'].includes(name)) return [`Searching ${clean(input.pattern ?? input.query) || 'files'}`, input.pattern ?? input.query ?? ''];
   if (name === 'WebFetch') return ['Reading web page', input.url ?? ''];
@@ -28,9 +59,13 @@ export function claudeActivity(session, line) {
     const obj = JSON.parse(line);
     if (obj.parent_tool_use_id) return false;
     if (obj.type === 'result') return clear(session);
+    if (obj.type === 'system' && obj.subtype === 'background_tasks_changed' && Array.isArray(obj.tasks)) return backgroundJobs(session, obj.tasks);
     let changed = false;
     for (const part of Array.isArray(obj.message?.content) ? obj.message.content : []) {
       if (obj.type === 'assistant' && part.type === 'tool_use') {
+        // The store's own records never become the word on the row: taking the
+        // item is not what the session is doing (w-0bd0d8b2ef).
+        if (isBookkeeping(part.name)) continue;
         const [label, detail] = toolLabel(part.name, part.input ?? {});
         changed = add(session, part.id, label, detail) || changed;
       }
@@ -47,9 +82,14 @@ export function codexActivity(session, method, params) {
   if (method !== 'item/started') return false;
   if (item.status && !['inProgress', 'in_progress', 'running'].includes(item.status)) return false;
   switch (item.type) {
-    case 'commandExecution': return add(session, item.id, `Running ${plainCommand(clean(item.command)) || 'command'}`, item.command);
+    case 'commandExecution': {
+      const plain = commandWork(clean(item.command));
+      const label = plain ? `${plain.doing} ${plain.subject}`.trim() : `Running ${plainCommand(clean(item.command)) || 'command'}`;
+      return add(session, item.id, label, item.command);
+    }
     case 'fileChange': return add(session, item.id, 'Editing files', (Array.isArray(item.changes) ? item.changes : []).map(c => c?.path ?? '').join('\n'));
-    case 'mcpToolCall': return add(session, item.id, `Using ${clean(item.tool).replace(/_/g, ' ') || 'tool'}`, `${item.server ?? ''} · ${item.tool ?? ''}`);
+    case 'mcpToolCall': return isBookkeeping(clean(item.tool)) ? false
+      : add(session, item.id, `Using ${clean(item.tool).replace(/_/g, ' ') || 'tool'}`, `${item.server ?? ''} · ${item.tool ?? ''}`);
     case 'webSearch': return add(session, item.id, 'Searching the web', item.query ?? '');
     default: return false;
   }

package/main/agent-schedule.mjs

@@ -1,4 +1,4 @@
-// WHEN SHE ASKED TO SEE AN AGENT AGAIN, AND WHEN SHE ASKED NOT TO. One small
+// WHEN THE USER ASKED TO SEE AN AGENT AGAIN, AND WHEN THEY ASKED NOT TO. One small
 // durable map, and the only state the app keeps about a session it did not start.
 //
 // Three facts per agent and they are different facts. `runAt` is a moment she
@@ -41,9 +41,9 @@ import { agentKey } from '../shared/agents.mjs';
 
 const num = (v) => (Number.isFinite(Number(v)) ? Math.max(0, Math.trunc(Number(v))) : 0);
 
-// HER SIDE OF A THREAD IS SMALL, and this file is read on every draw. Measured
-// across her 16 real sessions on 2026-08-17: 155 turns of hers in total, median
-// 6 per session, median 131 characters. The card shows three. Eight, at 600
+// THE USER'S SIDE OF A THREAD IS SMALL, and this file is read on every draw. A
+// real session has a handful of human turns, typically a sentence or two each.
+// The card shows three. Eight, at 600
 // characters, is far more than anything draws and small enough that a session
 // left running for a month cannot grow the file without bound.
 const KEEP_SPOKE = 8;
@@ -116,8 +116,8 @@ export class AgentSchedule {
   }
 
   // An entry that says none of "later", "seen", "I spoke to it" or "here is what
-  // she said" is not an entry. The last of those four is why this is not the
-  // same list as it was: her words outlive the reply that carried them, so an
+  // the user said" is not an entry. The last of those four is why this is not the
+  // same list as it was: the user's words outlive the reply that carried them, so an
   // entry holding only `spoke` is still the record of a conversation.
   _keep(key, entry, now) {
     if (entry.runAt > now || entry.doneThrough > 0 || entry.repliedAt > 0 || entry.spoke?.length) this.byKey[key] = entry;
@@ -155,8 +155,8 @@ export class AgentSchedule {
     // undid the close, saying a session was working on something she had
     // already finished with.
     //
-    // BUT IT DOES NOT UNSAY WHAT SHE SAID. This used to empty `spoke` as well,
-    // and `spoke` is the ONLY record anywhere that she ever spoke to a session:
+    // BUT IT DOES NOT UNSAY WHAT THE USER SAID. This used to empty `spoke` as well,
+    // and `spoke` is the ONLY record anywhere that the user ever spoke to a session:
     // Claude Code stamps an injected message `isMeta` and the transcript reader
     // drops it, correctly, so nothing else on the machine knows. Measured on
     // session-46: four of her messages reached that session and the file holds
@@ -200,12 +200,12 @@ export class AgentSchedule {
    *
    * It is here because it is the only place that knows. Claude Code stamps a
    * message injected over its socket `isMeta: true` and wraps it in "Another
-   * Claude session sent a message… not typed by y measured 2026-08-17 on
-   * session-67, where two messages she sent at 19:41 left the row saying only
-   * what she had started it with four days earlier.
+   * Claude session sent a message…", so the transcript reader drops it, and
+   * without this record messages sent from Agentbox left the row saying only
+   * what the session was started with days earlier.
    *
-   * A another of her sessions pinging this one is a real peer and drawing it as
-   * her words would be a lie on the one card built to be trusted. So the record
+   * Another of the user's sessions pinging this one is a real peer, and drawing
+   * it as the user's words would be a lie on the one card built to be trusted. So the record
    * is written at the moment of delivery, by the only process that knows it
    * delivered it.
    */
@@ -236,7 +236,7 @@ export class AgentSchedule {
       if (entry.runAt > now) { out.runAt = entry.runAt; out.runAtSetAt = entry.setAt; }
       if (entry.doneThrough > 0) out.doneThrough = entry.doneThrough;
       if (entry.repliedAt > 0) out.repliedAt = entry.repliedAt;
-      // the card quotes what she said last, and a session that has since
+      // the card quotes what the user said last, and a session that has since
       // stopped is exactly when she most needs to see it.
       if (entry.spoke?.length) out.spoke = entry.spoke;
       return out;