Work mode from the terminal · Terminal and platforms

A long job is a background worker that is the same Kotoba, briefed with one goal, running with a bigger tool budget and no turn around it. From the terminal you start one by asking for it, watch it from the prompt while you keep talking, and stop it with /stop.

Starting one

There is no /work start. start_work is a tool she has, so you ask:

› look into what changed between the last two releases and write it up

She decides. The tool is described to her as the thing to use for anything that needs several steps, the browser, the code sandbox, or a new capability. It returns immediately, so she keeps talking to you while the worker runs. The turn commits an opening bracket and then lets go:

▸ ▏WORK ▕ 01  look into what changed between the last two releases     started

The closing bracket lands later, and says which of the three endings it was:

✓  WORK   01  4m 12s                                                      done
×  WORK   01  1m 03s                                                    failed
◇  WORK   01  38s in · nothing kept                                    stopped

One job at a time. Starting a second while the first is still running closes the first as interrupted — otherwise it would sit in /work N as a phantom forever and its receipt would never print.

Watching it

Once the turn ends, the band and the bar are the job's only surface. Neither prints into the transcript, because the transcript is scrollback and a job that moves cannot live there.

At the prompt, with a job running:

▸ on it…                                                                 1m 13s
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃› talk to her · @ a file · / for commands                                    ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
 ○ WORKING   ( ･ω･ )     the long job — on it…           /stop stops it   1m 13s

The chip reads WORKING instead of LIVE, and its mark is the one moving thing on the screen.
The band's first row is the job: a mark, her current step's verb, and the clock. The verb is derived from the steps every time it is drawn, never latched when a step started, so a four-second search does not still read looking that up… ninety seconds later.
The band's second row is the open plan, if there is one.
The right slot names the gesture that actually works from where you are standing: /stop stops it at the prompt, esc stops it inside a turn. The prompt does not bind esc to anything that stops a job, so saying esc there would be telling you to press something inert.

While helpers are out, the phrase becomes the count and where to read them:

the long job — 2 helpers out, 1 back · /helpers shows them

Three commands open it up, and none of them interrupts anything:

/work — the whole receipt so far: every tool step, every helper, drawn still.
/helpers — the full log of the line-up, including each helper's own steps and summary.
ctrl-r — the line-up drawn over the transcript, on rows it gives back. Press again to close.

You can keep talking while it runs. A turn of yours takes the screen, and the job keeps its row in the band underneath.

Its approvals arrive at the prompt

The worker runs detached, so a command it wants to run cannot interrupt a turn. The card opens at the prompt instead, on your next Enter or when the idle prompt wakes for it, with a 180-second window. See The approval card.

When it ends

The bar carries the ending until there is news, because at rest nothing repaints the transcript:

State	What the bar says
finished	`the long job is done — she's telling you now`
failed	`the long job didn't work out — she'll say why`
stopped	`stopped the long job — nothing of it was kept`

The receipt — the closing bracket, her words about it, and anything she filed for you — lands in the transcript on your next Enter. enter on an empty line is the free gesture that asks for it.

A finished job's summary is printed whole. The wire frame carries only its first 500 characters, a cap sized for a client that never draws it; the terminal runs the engine in process, so it reads the whole record instead and a comparison table is not cut mid-cell.

Stopping it

› /stop

It names what would die before it asks:

█   NEEDS YOU  stop the long job? 3m 34s in
█  2 steps so far, on: compare the three release notes. None of
█  it is kept if you stop it now
█  y stop it   n let it run

y calls cancel_work and stamps every open row on the way out, so nothing in the transcript is left as a spinner that stopped moving.

Nothing of a stopped job is kept. That is why the rail says it rather than asking "are you sure", and why /stop refuses an argument: /stop 2 reads as "stop job 2", /work N has already established that jobs are numbered, and the job running need not be job 2.

Inside a turn, esc reaches the same cancellation — and with more than one thing running, the first esc arms and the bar names what the second one would take down.

Leaving stops it too. There is no daemon behind this prompt, so ctrl-d or /quit with a job running cuts it and prints its row on the way out, summarised it goes when the session does.

What is not kept

/work says it at the bottom of every listing:

what she's thinking isn't kept — this is what she's done, not how she got there

There is no reasoning trace to read back. What the job leaves behind is its steps, its helpers' summaries, its own summary, and the files it wrote.