@alphacoder-v0/pi-loops 0.22.8 → 0.24.0

package/CHANGELOG.md

@@ -5,6 +5,670 @@ All notable changes to pi-loops are documented here. The format follows
 
 ## [Unreleased]
 
+## [0.24.0] - 2026-11-09
+
+### Upgrade notes
+
+Read these before you upgrade from 0.22.x. 0.23.0 was tagged but never published to npm, so read its
+notes below too: everything in it ships in 0.24.0.
+
+- **Pair each browser again, once.** The first start of 0.24 replaces the page token that 0.22.8
+  wrote: 0.22.8 kept it in a cookie that every port on 127.0.0.1 receives. Old `?token=` bookmarks
+  stop working. Open the page with `pi-loops`, or enter a pairing code, once on each browser. If
+  you go back to 0.22.8 afterwards, it puts the token in that cookie again; delete `web-token` and
+  `web-token.v024` before you upgrade again to get a fresh one.
+- **One page, served by pi-loops in the background, at `127.0.0.1:4173`.** It replaces the page that
+  `pi-loops --web` served and the status page on 4174, whose content is now the page's Background
+  view. `pi-loops` opens the page and exits; Ctrl-C no longer ends anything. `--no-auth` is gone.
+  When `pi-loops` opens the page, `--port`, `--host`, `--allow-host` and `--resume` exit 2 with the
+  `[page]` lines in `config.toml` that replace them; with `--tui` they go to pi as before.
+  `PI_LOOPS_PAGE_PORT` overrides the port.
+- **Each conversation open in the page is one `pi --mode rpc` that pi-loops in the background runs.**
+  It stops when idle or at the cap, and uses about 116 MB while idle. `pi-loops restart` and an
+  upgrade wait up to two minutes for a turn in the page to finish; `pi-loops stop`, or pi-loops in
+  the background crashing, ends it at once. `[page] port` now applies to any loops directory, not
+  only the default one.
+- **A loop's runs no longer write into the conversation.** A loop's first three runs and every failed
+  run still put a one-line card in the conversation that made it; the others are in the terminal's
+  Runs panel, the page's activity strip and `/cron runs`. A loop carried over from 0.22.8 keeps its
+  run count, so one that has already run three times shows cards for failures only. A run you ask
+  for (`/cron run <loop>`, or the run button in the page) always puts a card, with the first line of
+  its reply, in the conversation you asked from.
+- **Every matched rule's result is a finding in the inbox, except a repeat.** In 0.22.8 a result kept
+  out of the conversation (`promote_to_chat = false`) went only to the audit log. Now every match is
+  one finding, and a result shown in the conversation is a finding too until you dismiss it. A result
+  with the same text as the newest finding from the same rule that is still new is not filed again. The choice
+  "Keep it out of this conversation" is now called "Put it in my inbox".
+- **Stop pi-loops before you uninstall.** Run `pi-loops stop` before `pi remove`. pi-loops runs in
+  the background, and removing the extension does not stop it: its loops keep running, and each run
+  costs a model turn. The README's Uninstall section has the steps.
+- **A project's `hooks.toml` runs for loops only where pi has saved trust.** Loops run in the
+  background, and there a project's own hooks load only for a directory pi trusts (`/trust` in a pi
+  opened there), as its settings, extensions and `.pi/mcp.toml` already do.
+- **New files in the loops directory:** `pages/<session>.json`, `pages/open/` (0600), and
+  `web-token.v024`. `seen.json` moves to one cursor per project; its old cursors are folded in once.
+  A job installed before its conversation was saved carries `owner: "project"` in `jobs.json`.
+- **An unattended run that really runs `pi-loops stop`, `abort` or `restart` is refused.** That
+  includes running it through `sh -c`, `ssh` or `docker exec`. A quoted message that only mentions
+  it, such as a `git commit -m`, is allowed.
+- **`PI_WEB_TOKEN` is gone.** pi-loops in the background serves the page and reads its token from
+  `web-token` in the loops directory only; the variable is ignored. To keep a token you chose, write
+  it into that file (letters, digits, `-` and `_`, at least 8 of them) and run `pi-loops restart`;
+  a new token signs every paired device out.
+
+- **A scheduled prompt in an open window asks before a dangerous command or an undeclared tool.**
+  Until now a plain job's prompt ran under the job's `--tools` and the dangerous-command policy only
+  in the background; in an open window it ran as your own message would. Now the same turn in a
+  window asks, with a 60-second countdown, before a command the policy refuses (`rm -rf` on an
+  absolute path, `sudo`, `git push --force` on main, and the rest of the corpus) or a tool outside
+  the job's `--tools`. The question has two answers, `No, refuse it` focused and `Yes, run it once`
+  under it, so Enter refuses: pi's Yes/No confirm starts on Yes, and a reflexive Enter ran the
+  command. The yes answer runs it this once; anything else, Escape or no answer refuses it with the
+  wording the background uses, and the model is told to do the safe part, and whether you refused
+  or nobody answered. pi-loops' own tools are asked about once at most: `cron_create` in such a turn
+  makes a job capped to the turn's tools, as a job a background run makes is capped to that run's,
+  and `new_trigger`, the trigger tools, `cron_remove` and `set_cron_job_state` ask through their own
+  confirm, with the same two answers and the same minute, where the background would refuse. A
+  message you send into that turn makes the rest of it yours. The turn an MCP server's
+  `inject_and_run` push starts is capped the same way, under the dangerous-command policy alone: in
+  0.22.8 it ran as your own message would. `[engine] window_guard = false` in `config.toml` restores
+  the uncapped window.
+- **`cron_create` and `new_trigger` ask you first, in a terminal too.** With you present, in your own
+  turn, both tools show one question before they create anything: pi's selector in a terminal, a
+  card in the browser page. It says what would run and offers where the result goes, and, for a
+  rule, whether it repeats; for a loop, whether a checker reviews each finding. The tool returns
+  `created …` or `cancelled: …` in the same call. In 0.22.8 `cron_create` created at once and
+  `new_trigger` asked a `Control-plane approval required` confirm; that confirm is replaced, not
+  added to. The turn waits for your answer up to thirty minutes, then nothing is created. A
+  scheduled turn, a sub-agent and pi-loops in the background ask nobody, as before. A `cwd` outside
+  the project is refused before the question; `/cron add --cwd` still sets one up elsewhere.
+- **`pi-loops host stop` now pauses everything until `pi-loops start`.** In 0.22.8 it stopped the
+  running process and recorded nothing, and with nothing running it exited 1. Since 0.23 it is
+  `pi-loops stop`: it exits 0, records the stop, and every loop, every rule and the plain jobs of
+  closed conversations wait until `pi-loops start`. The command now says so when you use this
+  spelling.
+- **`PI_LOOPS_HOST=1` no longer makes a `pi -p` run the timer.** In 0.22.8 it let a `pi -p` run
+  host the timer for as long as it lived. Loops now run in pi-loops in the background; with the
+  variable set, a `pi -p` run only starts pi-loops in the background when it is not running, and that
+  process outlives the run. The `pi -p` run's own clock still runs its conversation's plain jobs'
+  slots, but it delivers no scheduled prompt itself: the prompts wait in the queue for a window or
+  pi-loops in the background.
+- **`--tools` naming a built-in tool this chat does not have says so.** 0.22 stored the list as
+  typed; a loop made in a chat without `bash` then ran with `bash` in the background. Since 0.23
+  the undeclared tool was dropped without a word, and `/cron add` could print `the tools ` with
+  nothing after it. The tool is still dropped, so a job never gets more than its chat has and a
+  recipe's install does not fail on it, and `/cron add` and `/recipe add` now print
+  `dropped from --tools: bash (this chat does not have it)`.
+
+### Fixed
+
+- **`pi-loops` finds a pi that pi's own installer manages.** pi 1.5 installs itself under
+  `~/.pi/agent/install/`; `pi-loops` and pi-loops in the background looked only beside node and in
+  npm's global directory, and stopped with "no pi package is there at all".
+- **`--help` and `-h` never run a command.** `pi-loops <command> --help` prints that command's
+  usage and changes nothing: `upgrade --help` used to run the upgrade, and `install-launcher --help`
+  wrote the launcher. `pi-loops -h` is `pi-loops --help`.
+- **`[page] port` applies to any loops directory,** and `pi-loops` no longer names port 4173 for a
+  directory whose page is on another.
+- **Set it up or Cancel closes the Watch for… box,** so the composer is free again, and the page
+  shows the new loop or rule at once.
+- **A finished run is carded once.** Run records with mixed time-zone offsets were carded again on
+  every restart.
+- **Two claims of one finding at the same moment no longer both succeed.**
+- **A reason you are typing on a decision card keeps its text across the page's redraw.**
+Found by a review of this release against 0.22.8 and 0.23.0; none of these had shipped.
+
+- **A question in the browser closes when its countdown ends.** pi refuses a timed dialog on its own
+  and tells the page nothing, so the page kept the question open, held the next one back, and
+  printed "approved" for an answer nobody read. Now the dialog closes at the end of its time with
+  `… → timed out with no answer: refused`, a page that attaches later is not offered it, one offered
+  again carries only the time it has left, and an approve after the time is up is neither sent nor
+  reported as approved.
+- **"queued N ✕" in the browser clears all N.** It cancelled only your own messages and pi's queue,
+  so with two scheduled prompts queued the count stayed 2. Each row's ✕ is unchanged.
+- **A dead letter in the inbox says why it was not delivered.** A plain job's prompt, a claim, a
+  goal continuation or a push that could not be delivered became a finding with the prompt alone,
+  and `/inbox claim` ran it again with nobody told it had failed. Now it reads
+  `could not be delivered (<why>): <prompt>`. A rule's result is the finding it always was.
+- **A window standing aside no longer names its own pid as another window.** `/cron` marked its jobs
+  `open in pid <this pid>` and `/cron run` said to run the job there. Both now say that this window
+  shows an older copy of the conversation and to `/resume` it.
+- **`cron_create` tells the agent what a plain job's turns may do.** Its result, and the skill, said
+  only that the job runs in the background. They now say that the turns run with the chat's
+  built-in tools under the dangerous-command guard, ask in an open window and are refused in the
+  background, and run there without the window's `-e` extensions or flags.
+- **A hand-over pi refused no longer stops a plain job until your next turn.** pi swallows a
+  refused `sendUserMessage` (no credentials, no model, another extension's input handler taking
+  the text) and starts no turn, so the queued prompt stayed "handed to pi" for ever and every later
+  slot was skipped onto it. Now a prompt handed to an idle pi that starts no run within ten seconds
+  of pi's last input event counts a failed attempt, backs off a minute, then five, and is a finding
+  in the inbox at the third refusal, like any failed row; a slot due while a refused prompt waits
+  replaces it rather than being skipped onto it, so one refusal costs one slot, as it did in 0.22.8.
+  `/cron` shows the reason (`pi did not start a turn for it; backing off until …`). The same holds
+  for a `/goal` continuation, a claim and an `inject_and_run` push. A message you sent from the
+  browser keeps its behaviour: judged once, handed back to the composer.
+- **A `/cron run` left queued when you quit no longer stops the job's background schedule.** The
+  background runs no attended row, and it used to wait for that one instead of running the clock's
+  slots behind it. Now it runs them as if the row were not there; your `/cron run` waits for a
+  window.
+- **A damaged `jobs.json` costs only the plain-job rows, not the whole queue.** A `jobs.json` that
+  cannot be read (empty after a torn write, written by a newer pi-loops) made every drain of the
+  conversation throw, so your browser messages and rule results were not delivered either. Now the
+  rows that name a job wait, with `cannot read the jobs: …` as the reason, and the rest drain.
+- **`/cron run` is your own turn.** Its row was capped as a scheduled turn, so the window asked
+  before `git push --force` or `sudo` in a prompt you typed the command for, and after Esc it
+  waited out the minute like the clock's rows. Now the row is recorded as this window's, runs
+  attended, and goes before the clock's rows, as a typed message does.
+- **A disabled job's queued prompt no longer runs when a window opens the conversation.** The
+  background clock already skipped a disabled job; the window handed its waiting prompt over anyway,
+  including a job parked after three interrupted held turns. Now a `cron:` row of a disabled job
+  waits (`its job is disabled`) until the job is enabled again; a `/cron run` row of a job disabled
+  since still runs, because you asked for it.
+- **A recipe's merge-conflict hand-off is no longer dropped while its tracker description waits.**
+  Both collapsed on one key per recipe, so `/recipe update` said "handed to the agent to resolve
+  with you" and nothing was queued. Each kind of hand-off now has its own key, and when one does
+  collapse onto an earlier one of the same kind the line says the agent is already queued for it.
+- **A prompt an input extension rewrites runs at most three times.** An `input` handler that
+  prepends text to extension-sourced messages removed the `[Trigger <id>] ` proof, so the row was
+  never done and ran again at every settle, uncapped, for ever. Each re-offer of a row pi dropped
+  unwritten now counts an attempt (the third is a dead letter), and a prefix-less user message that
+  starts right after this window handed a pi-loops row over is that row's turn, capped as the row;
+  your own pending input still wins.
+- **A send pi refused comes back to the browser composer when the page rings, not up to 30 s
+  later.** The drain the page's follow-up ring causes may now judge a refused send, as the tick may.
+- **A refused judgement counts idle time from pi's last `input` or `message_start`, not from the
+  hand-over, and the grace is ten seconds.** pi's pre-run phase (other extensions' input handlers,
+  the credential check, which can go to the network) reports nothing to an extension; five seconds
+  from the hand-over could fail a send pi then ran, so the person saw an error and an answer.
+- **A window no longer remembers every row it ever produced.** The record is pruned with the request
+  file; a 1-minute job in a window open for a month kept 43k entries.
+- **The background process never files a browser message in the inbox.** A person row for a
+  conversation it cannot find is removed and audited `stale`; design §5 says a person row never
+  goes to the inbox, and this one did.
+- **The window guard judges self-scheduling playbooks as the background does.** `cron_create`
+  inside a scheduled turn is not asked about; the job it makes is capped to the turn's tools.
+  `new_trigger`, `remove_trigger`, `set_trigger_state`, `cron_remove` and `set_cron_job_state`
+  are not asked a second time by the guard: they confirm themselves, once. The model is told
+  "nobody answered" only when nobody did; your No says you refused.
+- **The upgrade notice counts the plain jobs `/cron` says run in the background.** It counted
+  every plain job with a conversation, while `/cron` marked those of never-reopened conversations
+  `resume it to run`.
+- **A browser message is answered when the pi holding the session cannot answer it.** A terminal
+  that held the session but stood aside (its copy of the conversation behind the file), or a one-shot
+  `pi -p` run, kept the lease and handed nothing over; the page said "answered there" and the message
+  waited for ever. Such a holder now says so on its lease, the page's own pi runs the page's message
+  in its place, and the page does not call it answered elsewhere. Whatever the cause (a terminal
+  suspended with Ctrl-Z, a pi that is not draining), a message of yours nobody took in fifteen
+  seconds while pi is idle is listed as `not taken by pi N (why)` with `send it here instead`, which
+  takes it out of the queue and sends it to the page's pi over rpc, as 0.22 did. When the page's own
+  pi stands aside, the page says so and `/resume`, and offers nothing that would branch the
+  conversation. A terminal that holds the session and delivers, but has not taken the message, is not
+  called unanswering: the row says `pi N holds this conversation and has not taken it yet (it may be
+  busy)`, and its one offer reads `answer here instead (a branch pi N will not see)`. Send-here takes
+  the row out under the queue's lock only while no holder has stamped it handed over, and a drain
+  whose stamp finds no row hands nothing over, so a message is never answered twice; a row pi
+  already has answers `already handed to pi`.
+- **A page whose pi has no pi-loops in it chats as before.** With the extension not loaded (a pi
+  older than the floor, a load error, extensions off) the page wrote a row nobody would drain and
+  sent `/pi-loops ring <id> <fingerprint>`, which pi handed to the model as your message. Chat text
+  now goes to pi over rpc, no row is written, and the queue the page shows is pi's own.
+- **One request lock per conversation.** One `requests.lock` served every session, and a process
+  killed inside a rewrite left it for the ten-second stale wait, during which every writer of every
+  session (each window, the page, the background process) spun with its event loop blocked. Each
+  session's queue has its own lock now, so a lock left behind costs that one conversation's writers,
+  and nobody else. A `requests.lock` an older version left is ignored.
+- **Image bytes stay out of the queue file.** A browser message's images were written into the
+  row, so three screenshots made a 90 MB queue file, parsed at every listing and rewritten and synced
+  under the lock at every update (3 s on a fast disk). The bytes are a file beside the queue now, one
+  per row, removed with the row; the row carries each image's type and digest, the fingerprint
+  covers the digests, and bytes that do not match are refused rather than sent. An append that fails
+  takes its image file back, and pi-loops sweeps image files no row names once they are a minute old.
+- **A page whose pi reloaded its extensions routes on the command list as it is now.** `/reload` in
+  the page can unload pi-loops; the page routed chat on the list it fetched at startup. The list is
+  asked for again after every slash command, and when the cached one is older than thirty seconds.
+- **A queued row the background cannot run no longer costs a read of the conversation every tick.**
+  An attended row waiting for a window made pi-loops parse the whole session file (58 ms for 20 MB,
+  event loop blocked) on every tick to decide again that nothing had changed. It remembers the
+  file's size and mtime, jobs.json's, and the queue's content at the last such decision, and reads
+  again only when one of them changes or a backoff ends. A window drains once per burst of request
+  file events instead of once per event.
+- **A plain job's slot lost to another process leaves no row behind.** The row is written before
+  the stamps' compare-and-swap; when the swap lost (a pi-loops 0.22.8 window firing the same slot
+  during an upgrade), the row stayed and the prompt ran twice. The row this call appended is removed.
+
+Found by a four-angle review of this release's user journeys against 0.22.8 and 0.23.0 (owner
+decisions of 2026-11-02); none of these had shipped either.
+
+- **A rule's result reaches the window you are working in, as in 0.22.8.** 0.23 appended it to the
+  closed conversation that created the rule, so in a new conversation of the same project the agent
+  never saw it. Now it goes to the creating conversation while a window holds it; else to the
+  conversation a window holds in the rule's project (lowest pid first, as 0.22.8 chose its owner);
+  else to the closed creating conversation; and to the inbox only when no conversation can take it.
+  A rule with no creating conversation (imported, or made by a loop's run) starts at the project's
+  open window.
+- **`[host] auto = false` means what it meant in 0.22.8.** Loops run only while a pi window is open:
+  the first window starts pi-loops, `/cron run <loop>` and rule checks work in that window, and
+  pi-loops leaves once the last window has closed, unless you started it by name (`pi-loops start`,
+  `/pi-loops start`), which keeps it until `pi-loops stop`. 0.23 read the setting as "never start", which
+  paused every loop until `/pi-loops start` ([configuration.md](docs/configuration.md#host-auto)).
+- **A slot collapsed onto a queued prompt sets no `last error`.** `skipped overlaps` counts it; the
+  error outlived the prompt it was about and made `cron_list` read a healthy job as failing.
+- **A plain job's turn in a closed conversation is the conversation's own.** It runs on the
+  conversation's model (a `model` a 0.22 chat stored on the job was never used, and is ignored), its
+  tools act for the conversation (`cron_create stateful:false` binds to it, `cron_list all_projects`
+  lists the machine), and a control-plane confirm there is refused with a sentence that says the turn
+  ran in the background with nobody to ask, not "sub-agent".
+- **A 0.22 plain job's `--tools` can be cleared.** The list was inert then and caps the job's turns
+  now; `/cron set <job> --tools -` clears it (`--tools a,b` sets one), and the first session start
+  names such jobs once, with that command.
+- **The first-run notice counts every conversation's plain jobs, and leaving a conversation says
+  what goes on running.** The notice counted this conversation's jobs alone and was then spent;
+  `/new` and `/resume` said nothing, where in 0.22.8 leaving a conversation was how you stopped its
+  jobs. The next session start now says what the conversation you left has running, and how to stop one.
+
+### Added
+
+- **A conversation list on the page.** A project switcher, `All / Needs you / Unread`, who holds each
+  conversation (`terminal`, `open`, `pi-loops`), a loops rail and a status bar; on a phone, Inbox,
+  Chat and Loops tabs. "+ New" starts a conversation in the project the list shows.
+- **Inbox cards with actions.** A decision has `Yes, do it`, `No…` with reasons, and `See the run`; a
+  piece of news has `Look into it`, `Dismiss…` and `See the run`. A decision from another project
+  runs in a new conversation in that project. The terminal's `/inbox` and `pi-loops inbox list` show
+  the same split.
+- **Watch for something from one sentence.** The agent's `cron_create` and `new_trigger` ask you
+  first, as a card in the page and pi's selector in a terminal, and only your answer creates the loop
+  or rule. The card asks where the result goes and, for a rule, whether it repeats. A question
+  nobody answers is cancelled after 30 minutes.
+- **An away card.** "Since … · N runs (M failed) · K findings · $X", with `Show what needs me` and
+  `Mark all seen`, counted per project; the terminal's session-start line uses the same numbers.
+- **Starters in an empty project.** daily-digest, pr-watch and changelog-draft, each one click, each
+  installed at `--level report`.
+- **A loop activity strip, counts in the tab title, and notifications you opt into.** Notifications
+  come only while the tab is hidden: a new decision, a third failure in a row, the daily budget.
+- **Stop a running loop from the page, and one tuning suggestion per loop** ("Run hourly instead" or
+  "Pause", or keep it as it is).
+- **Rules that only wait for a path cost nothing until the path exists.** A rule made in 0.24 that
+  waits for a file checks the file first and calls the model only when it is there; the rule's row
+  says so. Rules made before keep the model check.
+- **The page from a phone.** `pi-loops` prints a one-use address valid for 10 minutes, never the
+  token; a phone on your tailnet opens the same page.
+- **`/cron queue [cancel <n|id>|clear]`, and `queued N` on the status line.** What waits for this
+  conversation (a plain job's prompt, a claim, a rule's result), numbered, with its source, age and
+  text; cancel one by number or id, or clear them all, each cancel audited as a `request` row.
+
+- **`/cron` and `cron_list` say when a plain job's prompt is waiting in its conversation's queue.**
+  A job whose prompt sits in `requests/<session>.jsonl` (pi busy, after Esc, behind another turn)
+  looked exactly like one that is not queued. `/cron` now marks it `[queued <how long>]`, with the
+  reason when the queue knows one (`backing off until <when>` after a failed hand-over), and
+  `cron_list` adds a `queued` field (`since`, and `reason` when there is one) to such a job and a
+  `queued:` line to its text. Every other line and field is as it was.
+- **`pi-loops status` and the status page list the request queues.** After its usual lines, `status`
+  prints `requests: N queued in M session(s)` and one line per conversation: the session id, the
+  count, how long the oldest row has waited, `dead: K` for rows at the dead-letter limit, and who
+  would run them (`in pi <pid>`, `in the background`, `nobody holds it`). It reads the files, so it
+  says this with pi-loops down too, where it used to say only that nothing was running. The status
+  page shows the same lines under "Requests". No row text is printed.
+
+### Changed
+
+- **Text the layout already says is gone.**
+  - The page: the empty conversation's tagline, the hint row under the composer (the conversation's
+    id is the last line of the ⋯ sheet, and ⋯ shows at every width), a starter's meta line and "or
+    describe a loop" (a starter is its name, a `≈ $N/day` chip, the sentence its recipe's new `line`
+    key gives, whole, and Add), the Watch for…
+    box's label and caption (title *Watch for…*, three examples), the plan card's "Not right?" line
+    (its notes are rows), and on an inbox card the `not said` rows, a greyed See the run, the loop's
+    name when only one loop is listed, and where a claim runs unless that is not here.
+  - The terminal: `/inbox` says `inbox: empty` and has no footer; the widget drops `Runtime` and
+    shows `Hooks` only when there are hooks.
+  - The command line: `pi-loops --help` is one line and one sentence per command (545 words to under
+    200); the launch line "the page stays open when this terminal closes" is gone; `pi-loops status`
+    says `started by …` and drops its two parentheticals.
+- **Words a person was never meant to meet are gone.** The Background view says conversation, where
+  it is open (a terminal, this page, the background), loops, rules and waiting, in the page's own
+  time format, with no pid, "spawned", "held by" or "mailbox"; `background.json` is unchanged. A
+  message or a Watch for… sentence that a terminal answers, or that waits for this page to read the
+  conversation again, says so with no pid. The
+  status bar says "1 conversation open in a terminal". `/cron` says a plain job's conversation is
+  "open in a terminal", "in the page" or "in the background", with no pid, and `/cron scheduler`,
+  `/cron queue` and a claim's card no longer say lease, held by pid, request or page slot.
+  `pi-loops status` says "3 messages waiting for 2 conversations, 1 could not be delivered".
+  `/cron host` still works and is no longer listed. The README says it in plain words. The
+  terminal's notices and `/cron run`'s refusal say where a conversation is open in the same words
+  and name no pid; only `/cron scheduler`, `/pi-loops status` and `pi-loops status` do. They count
+  "1 loop", "2 loops" or "2 plain jobs", never "job(s)", and so does the badge ("2 loops failing").
+- **One fact in one place.** The status bar is the one place that says pi-loops runs (or why loops
+  are paused) and the one link to the Background view, under the Loops pane on a phone; the Loops
+  pane's pi-loops line and link and the rail's Background icon are gone. The activity strip is the
+  one place for runs: the Loops pane's "last run" line and the away card's run count are gone, and
+  the away card shows when something was found. It, and the terminal's line at session start, say
+  "N from this conversation" only when that is not every finding. The Loops pane drops its summary line and says
+  "loops", not "job(s)". A loop row keeps ▸, its name and run on its first line, says `runs N` only
+  once it has run, and shows its 30-day numbers only when one is not zero, and then only those
+  (`3 findings in 30 days · 1 claimed`); `/cron` keeps its `30d:` text. A project with no loop
+  has an empty Loops pane and no loop count in the status bar. The away card's Show what needs me is gone (the Needs you tab and heading
+  do it), and the list is called Inbox on the desktop rail as on the phone. Every time on the page
+  is in one format, the away card's 24-hour words. A loop is labelled the same everywhere but
+  `/cron`, `cron_list` and `inbox --json` (its name, else `cron-` and 8 hex digits), the terminal's
+  `/inbox` included; a run card
+  drops its leading `cron`. The page says a schedule as the terminal does (`every 1d`). The page
+  server asks `src/paths.ts`, `src/schedule.ts` and `src/job-owner.ts` instead of keeping copies.
+- **The README's picture is the 0.24 page:** a decision and two findings beside a conversation.
+- **A stop you make spends the run's slot.** A stopped one-shot loop is turned off. Stops for quit,
+  budget or preemption still give the slot back.
+- **"Since you looked" is counted per project,** and includes findings from loops a recipe made.
+- **"Last run" shows 24-hour time.**
+- **A chat message from the browser page is a request, in one queue with what pi-loops addressed to
+  the conversation.** Sending from the page writes a `person` row to `requests/<session>.jsonl` and
+  rings the pi behind the page (`/pi-loops ring <id> <fingerprint>`, over its own rpc stdin, which is
+  how the row is believed to be yours and runs uncapped); the pi holding the session hands it over
+  when it is idle. While pi is busy the page lists everything queued, in the order it runs, each row
+  with its source ("you", "cron nightly", "rule 3f2a…") and a ✕, then what pi itself still holds (a
+  command typed while busy) as "pi"; "queued N ✕" counts both, and clear cancels every row it
+  counts, pi-loops' included, and what pi holds, as 0.22.8's clear emptied pi's whole queue. A
+  message queued when pi exits is kept and offered by the next page as "not sent before pi stopped",
+  with send and discard, where it used to be lost. After Stop what is queued runs once pi is idle, as
+  Esc leaves a terminal's queue (owner decision 2026-11-02); each row keeps its ✕, and nothing waits
+  on a clock or for your next send. A send pi refuses (compaction in progress, no
+  credentials) comes back to the composer with the error. When the same session is open in a
+  terminal pi that holds it, that terminal answers the page's message and the page says "open in a
+  terminal (pid N): answered there; /resume to see it", where the page used to fork a branch the
+  terminal never saw; such a row, and any person row nobody rang for, runs capped as unattended, so
+  the terminal asks before a dangerous command. Slash commands, steers and Stop still go over rpc.
+- **A request runs as its source, nowhere wider.** The process that runs a row recomputes its
+  `mode` from its source, and a row that says otherwise is removed and audited `refused`
+  (`/triggers audit`). pi-loops in the background runs no attended row (what you typed, a `/goal`
+  continuation, a claim): it waits for a window. In a window, a plain job's turn runs under the job's
+  declared tools and the dangerous-command policy and asks you first (see the upgrade notes); a
+  control-plane approval (`new_trigger`, the trigger tools) asked for in such a turn waits a minute at
+  most.
+- **A rule's result is a request addressed to its conversation.** It is one row in
+  `requests/<session>.jsonl` (`deliveries/` and the mailbox are gone), kept until
+  `[Trigger <id>]` is in the conversation, whoever delivers it: the window holding the conversation,
+  or pi-loops in the background for a closed one. A row whose delivery fails waits a minute, then
+  five, and no longer holds up the rows behind it; at the third failure, or when the conversation's
+  file is gone, it becomes a finding in the inbox, marked for the conversation, with a `request`
+  audit row (`dead`), and only then leaves the queue, so a crash in between loses nothing.
+  `/triggers audit` shows the promotion as `to: "chat"` or `to: "queued"`.
+- **A plain job's prompt is a request too, written before its slot is spent.** The window's clock
+  writes a `turn` row to `requests/<session>.jsonl` (its id derived from the job and the slot, so a
+  crash between the row and the stamps costs nothing) and the window hands it to pi only while pi
+  is idle: Esc has nothing of pi-loops' to drop, a window that quits leaves the prompt for the next
+  one, and after a turn you stopped it runs once pi is idle, as a message you queued would; while it
+  waits the window says `queued: cron <name> runs after the current turn`, the status line shows
+  `queued N`, and `/cron queue` lists and cancels it. A
+  one-shot is removed once its prompt is in the conversation, not when it fires. While a job's
+  prompt is still queued a later slot is spent without a second one (`skipped overlaps`). pi-loops
+  in the background runs a row a window left as a held turn under the row's id, and a held turn
+  handed back after its prompt landed leaves a fresh row for the window to run.
+- **Every prompt pi-loops has for your chat is a request now.** A `/goal` continuation, `/inbox
+  claim`, a recipe's tracker or merge-conflict hand-off, `/new-trigger` and an `inject_and_run` push
+  are rows in `requests/<session>.jsonl` like a plain job's prompt, handed to pi only while it is
+  idle (a plain job's prompt and a push keep their `[Trigger <id>] ` prefix; what you hand over
+  yourself, and a goal continuation, go in their own words, as in 0.22.8, and are proved by their
+  text after the stamp they were handed over at): Esc and a window that quits lose none of them, except a goal
+  continuation, which Esc drops with the goal it pauses. A claim queues
+  its hand-off before the finding is marked claimed, so a crash between leaves it `new` with the
+  hand-off waiting, not claimed with nobody told. While a goal
+  continuation is queued or on its way the evaluator does not run, so the budget is charged once per
+  continuation; Esc pauses the goal and drops the continuation queued for it. What you type runs in
+  the window you typed it in, lease or not, and before any turn the clock or a server queued; a
+  window that is busy says `queued: /inbox claim runs after the current turn` (a recipe's, `/new-trigger`'s and a plain job's lines name their source the same way). `/goal clear` and a new `/goal` drop a continuation still queued for the goal they replace.
+- **A stop is a request too, and `pi-loops abort <session-id>` stops a conversation's turn from
+  outside.** `pi-loops abort` takes a session id (or a unique prefix of one pi-loops knows) and stops
+  the turn running in that conversation in a terminal's pi, in the browser's pi or in pi-loops in the
+  background (not in a `pi -p` or `--mode json` run, which reads no requests); it waits up to 5
+  seconds and says `stopped the turn in session <id>`, `nothing was running in session <id>` (exit 1)
+  or `stop queued for session <id>`. A held turn a person stops is done: no fresh prompt is queued
+  for it and its slot is spent. The stop is a `stop` row in
+  `requests/<session>.jsonl`, read by whichever process holds the conversation, so it works with the
+  socket closed, and `pi-loops abort <run-id>` of a turn in a closed conversation goes the same way
+  when pi-loops does not answer. `/triggers abort <run-id>` of such a turn writes the row instead of
+  asking the socket and says `requested stop for <run-id> (session <id>)`, where it used to answer
+  `pi-loops did not abort …`. A stop names the turn it was asked about, so one that arrives after that
+  turn ended never stops the next one; a stop for a prompt pi has queued but not started aborts it as
+  it starts, and a `cancel` row takes a queued prompt out before it runs. Stops and cancels end in
+  `/triggers audit` as `request` rows, `done` or `stale`.
+- **A row for a closed conversation lands within moments, not on the next tick.** pi-loops in the
+  background watches `requests/` and `leases/`: a rule's result written for a closed conversation,
+  or a row a window left when it quit or gave the conversation back, is appended as soon as the file
+  changes, unless the conversation was written in the last two minutes: then it waits for the first
+  tick after that, as before. A window that writes a row for a conversation it does not hold also rings pi-loops over
+  the control socket (`ring`, `request:<session>` or `lease:<session>`). The 30-second tick stays as
+  the floor: a ring that is lost delays a row by at most one tick and never loses or repeats one.
+- **The agent's tools say each thing once, and say it truly.**
+  - Only `cron_create` explains a `Watch for:` message; `new_trigger` and the skill no longer repeat it.
+  - `promote_to_chat` and `stateful` state their real defaults: with a person present the question
+    starts at this conversation (a rule) or the inbox (a schedule); with nobody to ask, both are false.
+  - Each refusal and each id a tool cannot find ends with the next step: `cron_list shows the ids and
+    names`, `list_triggers shows the ids`, `report what you would have done, so a person can do it`
+    (a sub-agent) and `a person can do it with the slash command` (no UI). `set_cron_job_state` no
+    longer ends every refusal, a disable's included, with `; use /cron enable <id>`.
+  - `cron_list` counts this project's new findings (`inbox: 1 new finding`); `all_projects` counts the
+    machine's.
+- **The page says each thing in one place.**
+  - The list has no All / Needs you / Unread tabs: the cards are what needs you, and each row keeps
+    its `⚑ N` and unread dot. The `Today` heading shows only when an `Earlier` group does too.
+  - The away card no longer says `· N needs you`; the terminal's sentence still does.
+  - The status bar says only whether pi-loops runs: no loop count, no terminal count.
+  - The status chip is empty while idle (no `ready`).
+  - A loop row has no `runs N` and no ` · loop`; a plain job's schedule ends ` · in its conversation`.
+  - The project switcher names a project by its folder, with the whole path as its title; the
+    header has no path chip.
+  - The Loops pane shows Goal only while a goal is set, and has no This conversation section.
+  - Controls whose title repeated their label lose the title; the theme and notifications are
+    `theme: system|light|dark` and `notifications: on|off`. A row's holder tag has no title, with
+    one exception: a `terminal` tag whose terminal answers nothing sent to it keeps a title that
+    says so.
+  - The door is one heading, one line and the code field.
+  - A card whose conversation is gone says `its conversation is gone; runs here` (or `runs in a new
+    conversation in <project>`), not which button to press.
+  - Other projects' loops, rules and findings are counted (`+ 2 loops in other projects`) with no
+    terminal command; more new findings than the cards show is `+ N more`.
+  - The Watch card has no command box, no `Model` row and no `WATCH` tag; the terminal's question
+    keeps its `Command` line.
+  - An untitled conversation is named by its id's first 13 characters (`01a1c183-7467`), as
+    elsewhere.
+- **The terminal and the command line say each thing once, in one form.**
+  - A conversation is named by its id's first 13 characters on every surface; the first 8 were
+    shared by conversations started about a minute apart. `pi-loops sessions` keeps 16.
+  - `pi-loops status` and the Background view list a loop as failing only after three failures in
+    a row, as `/cron` and the badge do, and name it by its label, never its whole id.
+  - The widget lists Rules (`condition → action`, marked only `[disabled]` or `[every time]`),
+    Loops, Runs and MCP; the inbox count is the footer's, and a check is shown only when it went
+    wrong.
+  - `/cron` says `disabled` but not `enabled`, marks catch-up only where it differs from the
+    default, prints the last fired time in local time, and the path only in `/cron all`.
+  - Bare `/triggers` lists the rules; `/triggers status` says in plain words what checks them.
+    A rule row has no `fire_once` or `promote_to_chat`.
+  - `pi-loops inbox list` names the loop by its label in local time, and a dismiss tells the loop
+    by its label. `pi-loops status` prints the start once, and every time in local time.
+  - `/pi-loops`, `/recipe` and `/goal` drop their taglines; both recipe lists show each recipe's
+    one line, with no `—` column.
+  - `/cron runs` says `stopped` for a run that a quit or restart ended, not `FAILED: ?`.
+  - An error prints `pi-loops: <message>`, and the usage of that command only when it was typed
+    wrong (exit 2); an unknown command points at `pi-loops --help`. A flag or a word a command
+    does not read is refused (`status does not take --json`) instead of being ignored.
+  - With HOME `/home/al`, `/home/alice/x` is no longer written `~ice/x`.
+
+## [0.23.0] - 2026-10-30
+
+Tagged, never published to npm. Everything below ships in 0.24.0.
+
+### Upgrade notes
+
+Read these before you upgrade from 0.22.x. Each one changes what runs, what it costs, or what a run
+can see.
+
+- **The commands that start and stop it are new.** `pi-loops status|stop|abort` and
+  `/pi-loops status|start|stop` replace `pi-loops host status|stop|abort` and `/cron host`. The old
+  spellings still work, but `/cron host stop` means something new: in 0.22 it only kept the last
+  window from handing loops on as it quit; now it stops pi-loops in the background, and every loop
+  pauses until `/pi-loops start`.
+- **Plain jobs of closed conversations now run, and each run costs a turn.** In 0.22 they waited
+  until you resumed the conversation. Now pi-loops runs them inside the closed conversation. The
+  daily budget has no cap unless you set one: `[limits] daily_budget_usd` in `config.toml`. The
+  first start of 0.23 says how many of your plain jobs this affects; `/cron all` lists them.
+- **Loops and rule checks run in the background.** A run there does not get these from
+  the window:
+  - extensions given with `-e`, `--skill`, `--prompt-template`, `--system-prompt` and
+    `--append-system-prompt` (creating a loop says so);
+  - a key given with `--api-key`. When a service manager runs pi-loops, keys that are only
+    exported in your shell do not reach it either. Keys saved with pi's `/login` always do;
+  - the window's current model. A loop whose model you cleared with `/cron set --model -` uses
+    pi's default model;
+  - the window's trust. A loop or rule check loads a project's own settings, extensions and
+    `.pi/mcp.toml` only when pi has saved trust for that exact directory, read at each run; `/trust`
+    in a pi opened there saves it, and the window says so when a loop needs it. A plain job's run
+    in its closed conversation uses pi's saved trust for that directory or a parent of it, as the
+    conversation's owner would get on resume; "this session only" trust is not carried;
+  - the window's live MCP connections. A run connects its own from `mcp.toml` and the project.
+- **`--trigger-poll-secs` no longer has an effect.** Rule checks run in the background, and pi-loops
+  reads `[triggers] poll_interval_secs` from `config.toml` there. Passing the flag warns at session start.
+- **A loop keeps the built-in tools of the chat it was made in.** A loop made in `pi --tools read,ls`
+  runs with `read` and `ls`, not with pi's default `bash`, `edit` and `write`. Loops made before this
+  version run with pi's defaults; to restrict one, remove it and add it again in such a chat, or
+  give it `--tools`.
+- **`[host] auto = false` now means that loops do not run until `/pi-loops start`.** In 0.22 it
+  only stopped the hand-off when the last window quit, and loops still ran while a window was open.
+  The session-start line says when loops are paused for this reason.
+- **pi-loops keeps running after the last window closes.** To stop it, run `/pi-loops stop` or
+  `pi-loops stop`. It stays stopped until `/pi-loops start` or `pi-loops start`.
+- **pi-loops needs node.** Under bun, pi-loops runs on the `node` on your PATH. If there is none,
+  loops pause and the status line says why.
+- **A pi-loops 0.22 window can report that pi-loops failed to start when you quit it.** pi-loops 0.23
+  is already running, so the one the old window starts exits at once. Nothing is wrong;
+  restart your 0.22 windows after you upgrade.
+- **To go back to 0.22.8,** follow the steps under "Uninstall" in the README before you install it.
+
+### Added
+- **`pi-loops start`, `stop`, `restart`, `status` and `abort`, and `/pi-loops start|stop|restart|status`
+  in pi.** They control the part of pi-loops that runs loops and rule checks in the background.
+  `stop` keeps it stopped until `start`; `restart` waits for the old process to exit before it starts
+  the new one. `pi-loops start --foreground` runs it in the terminal, for a systemd unit or a
+  LaunchAgent that you write: `docs/cli.md` has a systemd example. pi-loops itself installs no unit.
+- **A loop's results come back to the conversation that created it.** A loop's findings went to
+  the machine-wide inbox and nothing told the conversation that started the loop. Each finding now
+  names that conversation and its run's transcript, and a run record names the conversation too.
+  When the conversation starts, one line says how many runs (and how many failed) and how many new
+  findings its loops produced since `/inbox` was last listed there; listing `/inbox` clears it.
+- **`/inbox open <n>` starts a new conversation from the run that filed a finding.** pi forks the
+  run's transcript into a new session file and switches to it; the run's own transcript is not
+  written. A transcript that a new finding points at is no longer pruned with the oldest runs
+  (at most 100 such transcripts per loop).
+
+### Changed
+- **Loops run in the background.** Windows used to elect one of themselves to run the loops,
+  and the last to quit handed them to a background process that went away again when a window
+  opened. Now a window starts pi-loops in the background when there is a loop, a rule or a push
+  server to run, it never yields to a window, and windows run only the plain jobs of the
+  conversations they hold. `/pi-loops stop` stops it until `/pi-loops start`. A loop no longer shares
+  a window's live MCP connections: it connects its own from `mcp.toml` and the project, as it always
+  did in the background.
+- **A background process that stops answering is replaced, one that keeps crashing is paused, and
+  one that cannot start says so.** A window whose three ticks in a row get no answer from its socket,
+  and whose heartbeat has stopped, kills it and starts another; one still ticking with a broken socket
+  is reported instead. An uncaught error is logged first, then the process exits; three crashes
+  within five minutes pause it for half an hour (`loops paused: pi-loops keeps crashing`), twice as
+  long each time it crashes again as soon as it is back, at most a day; `/pi-loops start` ends a
+  pause at once. A loop whose runs die with it three times in a row, each time the only run in
+  flight, is parked. One that dies at startup is retried
+  after 1, 5 and 30 minutes, and the status line says `loops paused: pi-loops could not start`. Under bun, pi-loops
+  runs on the `node` on your PATH.
+- **A rule's result goes to the conversation that created it, also when two conversations in one
+  repository match in the same check.** One check covers a project's rules, and its result used to
+  land in the inbox when the matched rules came from two conversations. Now each of those
+  conversations gets the result. The result is the check's whole summary, not only the part about
+  that conversation's rules.
+- **A closed conversation's plain jobs run in it.** They used to sleep until the conversation was
+  resumed. pi-loops now takes the conversation for the one turn and gives it back, so the answer is
+  there on resume; `/cron` marks the job `[session … — runs in the background]`. It leaves
+  alone a file written by someone else in the last two minutes, and a window that opens the conversation mid-turn
+  takes it back at once and runs the job itself, however late. Each turn is a run in `/cron runs`
+  with its own cost, counted by the daily budget; a failed turn is a failed run (error, backoff, one
+  retry for a one-shot), and a turn pi-loops stops itself runs again on its next tick. A rule's
+  result for a closed conversation is appended to it too, instead of going to the inbox.
+- **A rule's result reaches a closed conversation however busy it is, and you are told.** A result
+  for a conversation pi-loops cannot take that instant waits in its queue and is appended on a later
+  tick, instead of landing in the inbox; a queued result is kept until it is in the conversation,
+  so a window quitting before it read one loses nothing. The `[inbox] since you last looked` line
+  counts rule results appended while you were away, and findings in other projects apart.
+- **A project's own push servers trigger its rules again.** pi-loops connects the push servers of
+  trusted projects that have rules (a regression in the earlier releases of this redesign).
+- **When pi-loops is stopped or disabled, every surface says its work is paused.** With pi-loops stopped by hand,
+  `[host] auto = false` or `PI_LOOPS_HOST=off`, no loop runs. The status line, `/cron`, the
+  session-start line and `pi-loops status` now say so and why, instead of promising next runs.
+- **pi-loops picks up edits without a restart.** It rereads `mcp.toml` every minute and starts or
+  stops only the servers that changed, and a project's AGENTS.md, skills, extensions and settings
+  reach the next run after they are edited. `pi-loops status` names the process whose environment
+  the background process has.
+- **A plain job runs on its conversation's model.** It is no longer pinned to the model of the chat
+  it was made in, so it uses the same model whether its conversation is open or closed.
+- **The window tells you what happens in the background.** The status line, the panel and the run
+  cards follow the background process's runs as they start and finish, not a tick later. A rule
+  check that matched or failed shows its card as in 0.22, and the browser panel's "last check" line
+  is back. When a rule's result is added to one of this project's closed conversations, the open
+  windows of the project say which one. A loop disabled or parked there, a state write that failed, an untrusted project, an
+  extension that did not load and the budget pause are said once in the windows of that project, as
+  they were when loops ran in a window. Quitting says whether loops keep running in the background,
+  or why they are paused. The since-you-looked line and the session-start lines come after a
+  resumed conversation's history, where a long one no longer pushes them off the screen.
+- **A window shows and stops what pi-loops runs.** The running badge, `/triggers running`,
+  `/triggers status`, the panel and the browser panel include pi-loops' runs and checks, and
+  `/triggers abort` can stop a loop running in the background again. The browser panel reads
+  whether pi-loops is running on every refresh, so it no longer says `pi-loops is not running`
+  while it runs, and the last rule check it shows is this project's.
+- **pi-loops has a read-only status page** on `http://127.0.0.1:4174/`: which process holds each
+  conversation, what is running, budget, failing jobs and MCP servers. `pi-loops status --url`
+  prints its address with the token. It takes no action; abort, run and stop stay on the socket.
+  The token survives a restart; `docs/cli.md` says how to retire one.
+- **During an upgrade, pi-loops 0.22 windows stand by for loops.** pi-loops writes the file those
+  windows elect through, so they do not run loops beside it. They still fire their own
+  conversations' plain jobs; restart them.
+
+### Fixed
+- **The browser window follows `/inbox open`.** Opening a finding forked the run into a new
+  conversation and switched pi to it, but the page kept showing the old conversation until it was
+  reloaded by hand. It now reloads onto the new one, as `/session import --resume` does too.
+- **A conversation open in two windows no longer fires its plain jobs in both.** One window holds
+  the conversation; the other is a viewer and `/cron` there says `[session … — open in pid N]`.
+  The holder changes only when its process is gone, so a window that is quiet for hours keeps it.
+  A window that shares its conversation with a pi-loops 0.22 window says so once, because that
+  window still fires the jobs on its own. A viewer no longer writes pi-loops' views into the
+  conversation (`/cron`, `/inbox`, run cards). A window whose copy is older than the file (the
+  other window added turns, or pi-loops appended a rule result) fires nothing into it: it says to
+  `/resume` the conversation, and its plain jobs and rule results wait until then. Before, its turns
+  forked the conversation and hid the other window's answers on a dead branch.
+- **A project's `.pi/mcp.toml` no longer starts its servers before you trust the project.** pi
+  does not ask about a directory that has none of its own settings, skills or extensions, and
+  treats it as trusted; pi-loops took that answer, so opening a cloned repository started the
+  command its `.pi/mcp.toml` names. There, the file now loads only once `/trust` has saved trust
+  (pi applies it at its next start) or with `pi --approve`, and the window says it ignored the file
+  until then.
+- **The lines a session starts with are all on the screen.** pi shows back-to-back notices on one
+  line, so only the last one stayed: "since you last looked", the viewer line and the one-time
+  notice that plain jobs now cost turns were replaced before anyone saw them. They are now one
+  notice, and the one-time notice counts as said only once it is shown.
+- **A rule's result lands in the conversation that created it.** A check that ran in a different
+  window than the rule's conversation now queues the result for the window holding that
+  conversation; a closed conversation gets it appended by pi-loops (see "Changed").
+- **Removing a loop stops its run.** A loop removed while it ran in the background went on to its
+  deadline; pi-loops now stops that run on its next tick, wherever the removal was made.
+- **A damaged `triggers.json` costs its rules, not every loop.** The window counted no work and
+  started nothing, and pi-loops itself exited at start. The store's error now names its file.
+- **The background process starts where pi's packages are hoisted.** It looked for pi's
+  dependencies only inside pi's own `node_modules`; a hoisted npm install or pnpm put them beside pi.
+- **Smaller fixes for a long-running background process.** A loop's extension set that a newer
+  one replaces (any `/model` rewrites `settings.json`) shuts down when its runs end, not under them,
+  and an unused one after an hour. A rule result that pi dropped from its queue (Esc while it
+  answered) is offered again. A clock set back no longer holds every plain job of a closed
+  conversation. A lease left held by a failed release is given back. One failed `ps` no longer
+  counts a healthy process as gone. Several windows replacing one wedged process count one crash.
+  A `pi-loops stop` that lands while a window starts pi-loops is kept. `cron_create` and
+  `new_trigger` say when pi-loops is paused. `pi-loops start|stop|restart --help` prints the usage
+  instead of acting. The browser front end answers a malformed request line with 400 instead of
+  exiting, and a relative `PI_LOOPS_DIR` reaches the background process as an absolute path.
+
 ## [0.22.8] - 2026-10-28
 
 ### Fixed