The web app10 of 12
The plan and the helpers
On this page
Two surfaces appear in the bottom corners of the screen while she is working, and only while there is something to show.
The plan tab
Screenshot placeholder: the collapsed plan tab in the bottom-right corner — a purple pill reading "言 Plan" with a "2/5" counter — and beside it the expanded card, a list of task rows with green ticks, one purple active disc and numbered pending discs.
The tab appears when a work run publishes a task list, and it opens itself the first time it sees a
new list — once per list, not once per update (lib/store.ts:261-272). With no list at all it renders
nothing: an empty-state decoration would be a panel claiming there is a plan
(components/panels/TaskTab.tsx:1-10, 94).
Each row has a status disc (TaskTab.tsx:30-62):
| Disc | Status |
|---|---|
| green tick | done |
| purple, spinning | active, and work is running |
| purple dot | active, but nothing is running |
grey ×, text struck through | dropped |
| grey number | pending, showing its position |
The tab and the card carry a done/total counter, and the tab is coloured by the list's own state:
purple while a step is active, green when the list is done, yellow when it was abandoned, white
otherwise (TaskTab.tsx:105-108).
A settled list never looks like work in progress. When a run stops short, the list is marked
abandoned and the word stopped early is written next to the counter — named, not implied by a
colour, because a count on its own reads as progress (TaskTab.tsx:225-235). A step left active on
a settled list shows the dot and not the spinner (TaskTab.tsx:277-278).
You can collapse and expand the tab. You cannot edit the plan from the browser: there is no add, reorder, tick or delete control anywhere in the component.
A late reload of the list from the REST endpoint cannot roll back a newer live frame, and it cannot
replace a different list — revision numbers only order updates within one list
(lib/store.ts:264-265).
The helper chibis
Screenshot placeholder: three small chibi heads in a row along the bottom-left corner, one with a speech bubble above it listing its steps, and a fourth head showing "+2".
When she delegates part of a job, each helper appears as a chibi in the bottom-left corner. Click one
to see what it is doing (components/SubagentChibis.tsx:1-5).
The row is one line that never wraps. Past the width of the viewport it caps itself at what fits and
spends its last slot on a counter head standing for the rest, so no head — and no dismiss control —
can end up off-screen (lib/subagent-row.ts:1-10, 30-45). Order is insertion order, because a head is
a click target and must never slide under the cursor.
A helper's steps are capped at the last 40 (lib/store.ts:281-284), and its goal, steps and summary are
all stripped of invisible and bidirectional characters on the way into state
(lib/store.ts:274-290).
The chibis are cleared when a work run starts, when it finishes, and when the call ends
(CompanionExperience.tsx:238, 299, lib/store.ts:293-296).
The work chip
While a run is live, a purple working… chip sits on the stage and the status pill under the controls
reads "Focused — working…", which outranks everything else it could say
(lib/call-status.ts:35).
One rule governs all of this: the newest work_started owns the work surface, and a later bracket
frame may only touch it if it names that same run (lib/store.ts:18-30). Without that rule a
superseded job's late teardown wiped the chip and the helpers belonging to the new job.
A separate repair pass runs when the events channel reconnects. It may only clear the working
flag, never set it — a REST read can be older than a live frame, so clearing removes a lie while
setting one would add one (CompanionExperience.tsx:329-344).
