pastilhasandClaude Opus 5
530e5880e1
Closed: - fleet/an-orchestrator-that-acts-on-every-server-at — built, and as none of the three shapes it proposed. Not a script, not a screen, not a chat capability: an agent handed a written procedure and a server list it has to read rather than one baked into it. All three verified facts in the item earned their place; two things it did not anticipate are now new items. - fleet/a-way-to-mark-a-commit-this-one-ships-so-a — built as a TAG, which the item explicitly ruled out. The owner reversed it, and the argument that changed his mind is recorded: a codeword can be written by accident, because every document about deploying contains it, so the trigger needs rules about where in a subject line it sits and a rule like that is one somebody eventually gets wrong. Opened, all from tonight and all with the evidence attached: - a deploy verifies pm2 and not that the app serves anything — the commander raised this against itself - the commander cannot finish its own host, so one machine is always a build behind - the watcher loop is rewritten by an agent every arming, so its correctness is re-rolled each time - plugins:update restarts every sidecar, so a report naming only officer understates what moved - an agent spawned by a background job is invisible in the UI while being perfectly readable - AskUserQuestion can fail to parse its own call - a commander opened from /chat loses its commander controls, because isCommander comes from the screen rather than the session Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1.6 KiB
id, title, theme, status, created, date_source, order
| id | title | theme | status | created | date_source | order |
|---|---|---|---|---|---|---|
| mobile-apps/the-live-chat-swipe-order-should-exclude | The live-chat swipe order should exclude commanders | mobile-apps | open | 2026-08-21 | stated | 3 |
The iPhone app swipes left and right between live chats, and commanders should not be in that order.
The reason it needs the server's help is that the phone has nowhere to put a tab. The web app solved the
same problem on 2026-08-21 with two tabs inside Live — Agents (n) / Commanders (n) — and a phone
swiping through a flat sequence cannot do that, so it can only filter if the payload says which rows are
commanders.
The server side is done and shipped in 2026.08.21.02. GET /chat/live rows now carry
isCommander: boolean, derived server-side from the session's cwd rather than from a database lookup:
every commander shares one directory, so the directory is the answer, it costs no query, and it is already
correct during a commander's first turn before any row exists. GET /chat/sessions carries it too.
So the app work is: read the field, drop isCommander rows from the swipe sequence, and decide whether
they are reachable at all on mobile or simply absent. A deploy commander appearing between two
conversations you are having is the thing to prevent.
Owed: a short document for the mobile developer — the field, where it comes from, and the one caveat
worth stating, which is that a row is isCommander from its first turn even before it has a title. The
owner asked for this on 2026-08-21 and said explicitly it should be written against a shipped version
rather than an intended one; that version is 2026.08.21.02.