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>
31 lines
1.6 KiB
Markdown
31 lines
1.6 KiB
Markdown
---
|
|
id: mobile-apps/the-live-chat-swipe-order-should-exclude
|
|
title: 'The live-chat swipe order should exclude commanders'
|
|
theme: mobile-apps
|
|
status: open
|
|
created: 2026-08-21
|
|
date_source: stated
|
|
order: 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`.
|