@alphacoder-v0/pi-loops 0.18.0 → 0.19.2

package/CHANGELOG.md

@@ -3,6 +3,58 @@
 All notable changes to pi-loops are documented here. The format follows
 [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); versions follow SemVer.
 
+## [0.19.2] - 2026-09-14
+
+### Fixed
+- **A plain job of another session was promised a next run, could be run into the wrong chat, and
+  was called dormant as if that were a fault** (#15). A plain job belongs to the session that
+  created it — its result is a message in that conversation — and dispatch has always honoured
+  that; the lists did not. `cron_list` printed a `next_run` for a job this process would never
+  dispatch (the same class the `[other host]` fix closed for the machine half of the predicate),
+  the browser panel showed the time it read from `next-runs.json`, and `/cron run` injected the job
+  into whatever chat was open. On 2026-09-14 a daily digest missed its slot exactly this way, and
+  the only surface that knew was the terminal's `[dormant …]` marker. Now one predicate
+  (`src/job-owner.ts`) answers "does it run here" for dispatch, `/cron`, `cron_list`, the panel and
+  `/cron run`: another session lists it as `[session <id> — resume it to run]` with no next run,
+  `cron_list` says the same and sets `owner_session` / `asleep`, the panel says what would wake it,
+  and `/cron run` refuses it with the same sentence. "Asleep" replaces "dormant" in the vocabulary:
+  it is waiting for its conversation, not broken. The `catch_up` description now says when a
+  plain job's missed slot is honoured (when its session is next opened); the skill tells the model
+  that anything meant to run unattended is a loop. Parking stays what it was and is now documented
+  as such: a plain job is disabled once its session's file has been deleted, not before.
+
+## [0.19.1] - 2026-09-14
+
+### Changed
+- **`pi-loops sessions` says what a session is, not only which.** It printed the id, the mtime and
+  the cwd, so telling two sessions apart meant opening them. It now prints one line a person can
+  tell them apart by: the short id, when the session started, the automation it has
+  (`[2 cron, 1 trigger]`, `[automation off]`), and what was first said in it — the name it was
+  given, or the first message cut at eighty characters, by characters and never inside one.
+  `--all` puts the cwd after the id. `src/session-head.ts` reads the head of a session file for
+  it; the browser front end's own copy of that reading is unchanged.
+- **The session commands are two words in the browser front end.** `/sessions` lists this
+  project's sessions in the feed, and `/session export [path]` / `/session import <path>` are the
+  archive commands, delivered as `/session-export` / `/session-import`. pi's built-in `/session` is
+  a terminal command that does not exist over rpc — that is why the extension's commands are
+  hyphenated in the terminal, and why the page can spell them plainly.
+
+## [0.19.0] - 2026-09-14
+
+### Removed
+- **The machine, as a concept.** Every job and rule used to carry the hostname that created it;
+  another machine sharing the `$HOME` ignored it and listed it as `[other host: <name>]`,
+  `/cron set <ref> --host here|-` and `/triggers set --host` re-homed it, `cron_list` printed
+  `other_host:`, the leader and next-runs files were named `scheduler.<host>.json` and
+  `next-runs.<host>.json`, and an imported archive was re-stamped for the importing machine. None
+  of it matches the way pi-loops is used: pi runs on one machine, the loops run
+  there, and a phone or a laptop reaches the browser front end over a tailnet without moving the
+  execution anywhere. All of it is gone. A `host` field an older build left in `jobs.json`,
+  `triggers.json` or a `.pisession` archive is ignored when read and dropped on the next write; the
+  leader file is `scheduler.json`, the next-runs file `next-runs.json`. Two machines syncing one
+  `$HOME` now both run every job — not supported, and said so rather than half-handled
+  (`docs/design.md` §19). "Host" means one thing here now: the headless process.
+
 ## [0.18.0] - 2026-09-14
 
 ### Added

package/README.md

@@ -38,7 +38,7 @@ the first sign of credentials that do not work should not be an empty inbox tomo
 
 ```bash
 pi install npm:@alphacoder-v0/pi-loops                      # from npm, following new releases
-pi install git:github.com/alphacoder-v0/pi-loops@v0.18.0    # or from GitHub, at a pinned tag
+pi install git:github.com/alphacoder-v0/pi-loops@v0.19.2    # or from GitHub, at a pinned tag
 pi install /path/to/pi-loops                                # or a local checkout — `pi install .` in this repo
 pi -e /path/to/pi-loops                                     # or none of them: try it for one run, installing nothing
 ```
@@ -268,7 +268,7 @@ State stays in `~/.pi/agent/loops` until you delete it.
 
 | Command | What it does |
 |---|---|
-| `/cron add [--stateful] [--verify] "<schedule>" <prompt>` | Schedule a job: plain jobs inject their result into this chat, `--stateful` makes a loop with memory and inbox routing, `--verify` adds the checker |
+| `/cron add [--stateful] [--verify] "<schedule>" <prompt>` | Schedule a job: a plain job belongs to this chat and injects its result here (it sleeps while this session is not open), `--stateful` makes a loop that runs wherever the clock is, with memory and inbox routing, `--verify` adds the checker |
 | `/cron`, `/cron all` | This project's jobs, or every project on this machine |
 | `/cron enable\|disable\|remove <ref>` | Pause, resume or delete one job — and write an audit entry into the session, as `add` does |
 | `/cron disable --all` | Pause every job in this project (`--all-projects` for the machine); `/cron enable --all` resumes |
@@ -289,10 +289,10 @@ State stays in `~/.pi/agent/loops` until you delete it.
 | `/new-trigger <natural language>` | Create a condition-based rule ("when ~/build.done exists, run cargo test") |
 | `/triggers [status\|rules\|enable\|disable\|remove\|running\|audit [N]\|abort]` | Dynamic rules: what exists, what is running, what happened |
 | `/triggers run <id>` | Check one rule now instead of waiting for its poll slot |
-| `/triggers set <id> --model\|--thinking\|--timeout\|--host` | Change what a rule runs with — the settings that decide how an unattended action behaves |
+| `/triggers set <id> --model\|--thinking\|--timeout` | Change what a rule runs with — the settings that decide how an unattended action behaves |
 | `/triggers sources`, `/triggers hooks` | Every source feeding the trigger runtime: each connected MCP server, whose notifications can fire a rule; the local crontab; the dynamic checker |
 | `/triggers panel [on\|off]` | The same panel, toggled from the trigger side |
-| `/session-export [path]`, `/session-import <path>` | Portable `.pisession` archive: transcript + jobs + rules + loop state |
+| `/session-export [path]`, `/session-import <path>` | Portable `.pisession` archive: transcript + jobs + rules + loop state (in the browser front end, `/session export` and `/session import` too; `/sessions` lists) |
 | `/session-share [--public]` | Upload a redacted transcript as a GitHub gist via `gh`, after showing you what it contains. (pi has its own `/share`, which sends the raw session elsewhere first — see [docs/session-archive.md](docs/session-archive.md)) |
 | `/recipe [list\|show\|add\|update\|remove <name>]` | Install a packaged way of running this project on loops — the issue tracker as a state machine, or one research experiment per run — with one question and one confirmation ([docs/recipes.md](docs/recipes.md)) |
 | `/pi-loops [install-launcher]` | Version and paths; `install-launcher` puts the `pi-loops` command on your `PATH` |
@@ -344,7 +344,7 @@ notifications, and lifecycle hooks — each has a page here.
 | `~/.pi/agent/loops/logs/pi-<pid>.log` | what each pi process's automation did |
 | `~/.pi/agent/loops/triggers.json`, `triggers-audit.jsonl` | dynamic rules and trigger audit |
 | `~/.pi/agent/loops/{config,mcp,hooks}.toml` | configuration |
-| `~/.pi/agent/loops/scheduler.<host>.json` | which pi process currently owns the timer |
+| `~/.pi/agent/loops/scheduler.json` | which pi process currently owns the timer |
 
 Set `PI_LOOPS_DIR` to relocate all of it. The notes are yours to edit when the agent got something
 wrong, and `logs/pi-<pid>.log` is the file to read after an overnight failure.
@@ -354,7 +354,7 @@ wrong, and `logs/pi-<pid>.log` is the file to read after an overnight failure.
 Scheduled work is only worth trusting if it survives you closing the editor. So "pi was restarted"
 is treated here as the normal case rather than the exception.
 
-Jobs are machine-global, recorded per host, and never expire. Any open pi can own the timer:
+Jobs are machine-global and never expire. Any open pi can own the timer:
 leadership is a file with a heartbeat, and when the process holding it exits or dies, the next tick
 in another window picks it up. A project's trigger checks run in a pi that is open in that project,
 so a result that belongs in a conversation lands in the right one. A tick a loop missed while

package/README.zh-CN.md

@@ -45,7 +45,7 @@ pi-loops 自己没有任何运行时依赖。
 
 ```bash
 pi install npm:@alphacoder-v0/pi-loops                      # 从 npm 装，跟着新版本走
-pi install git:github.com/alphacoder-v0/pi-loops@v0.18.0    # 或者从 GitHub 装，钉住一个 tag
+pi install git:github.com/alphacoder-v0/pi-loops@v0.19.2    # 或者从 GitHub 装，钉住一个 tag
 pi install /path/to/pi-loops                                # 或者本地检出；本仓库里就是 pi install .
 ```
 
@@ -241,7 +241,7 @@ playbook 拷到 `.agents/skills/<name>/`，通过 `.git/info/exclude` 排除在
 /cron  ·  /cron list|ls|status      本项目的任务，[stateful] 标记；/cron all 看整台机器
 /cron enable|resume|disable|pause|remove <n|id|name>
 /cron set <ref> …                   改已有任务而不换 id（笔记因此留着）：--prompt、--schedule，
-                                    以及 --model、--thinking、--timeout、--name、--host 这几个钉子（`-` 解掉）
+                                    以及 --model、--thinking、--timeout、--name 这几个钉子（`-` 解掉）
 /cron run 1                         立刻跑一次（once 跑完即删，every 的间隔从现在重算，cron 的下次不变；停用的普通任务会被拒绝）
 /cron state ci                      loop 的笔记（状态脊柱）
 /cron runs [ci]                     最近运行，最新在前
@@ -312,7 +312,7 @@ at 2026-09-08          → UTC 零点   ← 只给日期按 UTC，在北京就
 
 要表示时间就把时间写出来。另外 `in 10m` / `at` 在**创建那一刻**就被算成一个绝对时刻存下来，之后改时区不影响它；`every 30m` 是纯间隔，和时区、夏令时都无关。
 
-**跨机器的 loop**：没有 `host` 的任务会在任何共享这个 `$HOME` 的机器上跑——`/cron set <ref> --host -` 干的就是把 `host` 这个键从任务上摘掉。stateful loop 的笔记是模型自己写的自由文本，里面常有 watermark（「看到这里为止」），所以 prompt 会要求模型写时间时带上偏移。0.14.1 之前写下的笔记没有这个保障，跨时区又带 watermark 的 loop 值得用 `/cron state <id>` 看一眼。
+**一台机器**：pi-loops 在运行 pi 的那台机器上跑，没有跨机器的概念（0.19.0 去掉了任务上的主机名戳；两台机器同步一个 `$HOME` 会各跑一遍，不支持）。要在别处看它，走 tailnet 开浏览器前端。stateful loop 的笔记是模型自己写的自由文本，里面常有 watermark（「看到这里为止」），而机器的时区会变（设了 `TZ`、带着笔记本出差、容器重建成 UTC），所以 prompt 会要求模型写时间时带上偏移。0.14.1 之前写下的笔记没有这个保障，时区变过又带 watermark 的 loop 值得用 `/cron state <id>` 看一眼。
 
 ## Maker/checker：先质疑每条 finding，再给你看
 
@@ -486,8 +486,8 @@ Output protocol (mandatory):
 
 定时任务值不值得信，取决于你关掉编辑器之后会发生什么。所以这里把「pi 重启过」当成常态：
 
-1. **任务是机器全局的（按主机）**，存在 `~/.pi/agent/loops/jobs.json`，不绑会话、不绑目录（每个任务记住自己的 `cwd` 与 `host`，子代理在那里跑；共享 $HOME 的另一台机器会忽略它）。任何目录里打开的任何 pi 都能看到并执行 stateful 任务；普通任务因为要注入对话，只在创建它的那个会话里触发（`--resume` 回来就继续），会话没了，leader 会把它停用，`/cron gc` 清掉；子代理创建的普通任务归它所服务的那个父会话。
-2. **loop 归本机唯一的 leader 跑；动态检查归「开在那个项目里的那个 pi」跑。** `scheduler.<host>.json` 里放 pid 加心跳，30 秒一 tick；leader 退出或者崩了，其它 pi 在下一 tick 接手。
+1. **任务是机器全局的**，存在 `~/.pi/agent/loops/jobs.json`，不绑会话、不绑目录（每个任务记住自己的 `cwd`，子代理在那里跑）。任何目录里打开的任何 pi 都能看到并执行 stateful 任务；普通任务因为要注入对话，只在创建它的那个会话里触发（`--resume` 回来就继续），会话没了，leader 会把它停用，`/cron gc` 清掉；子代理创建的普通任务归它所服务的那个父会话。
+2. **loop 归本机唯一的 leader 跑；动态检查归「开在那个项目里的那个 pi」跑。** `scheduler.json` 里放 pid 加心跳，30 秒一 tick；leader 退出或者崩了，其它 pi 在下一 tick 接手。
 
    每个进程每 tick 往 `presence/` 登记自己的 pid、会话和 cwd。一个项目的规则检查和推送评估，就交给开在那个项目里的 pi——优先创建规则的那个会话，其次 pid 最小的那个——所以 promote_to_chat 一定落在对的对话里。项目里一个 pi 都没开，才轮到 leader 代跑，结果进 inbox。
 
@@ -516,7 +516,7 @@ Output protocol (mandatory):
 | `~/.pi/agent/loops/spend.json` | 轮转掉的那部分花费按天留一份，预算上限不会因为 run log 被截断而失效 |
 | `~/.pi/agent/loops/logs/pi-<pid>.log` | 每个 pi 进程的自动化诊断，超 2 MB 保留后半，只留最近五个进程（进程还活着的那份不算） |
 | `~/.pi/agent/loops/sessions/<id>/*.jsonl` | 子代理完整 transcript，每个 loop 保留最近 20 份 |
-| `~/.pi/agent/loops/scheduler.<host>.json` | 当前 leader 的 pid / 心跳（每台机器一份） |
+| `~/.pi/agent/loops/scheduler.json` | 当前 leader 的 pid / 心跳 |
 | `~/.pi/agent/loops/triggers.json` | 动态 trigger 规则（全局，带 cwd） |
 | `~/.pi/agent/loops/triggers-audit.jsonl` | trigger audit，超 2 MB 保留后半 |
 | `~/.pi/agent/loops/sessions/triggers-<项目>-<哈希>/*.jsonl` | 动态检查子代理的 transcript，每个项目一个目录（目录名带项目路径的哈希，同名的两个项目不会共用），保留最近 40 份 |

package/docs/cli.md

@@ -213,8 +213,12 @@ pi-loops host status | abort <run-id|trace-id> | stop
 
 ## sessions, inspect
 
-`sessions` lists the ids `export --session` accepts, newest first — without it an unknown id was
-the only error you could get. `inspect` prints an archive's schedules, prompts and rules without
+`sessions` lists this project's sessions newest first, one line each: the first sixteen
+characters of the id, when the session started, the automation it
+has (`[2 cron, 1 trigger]`, or `[automation off]` when all of it is disabled), and what was first
+said in it — the session's name if it was given one, otherwise the first message, cut at eighty
+characters. `--all` lists every project and puts the cwd after the id. The id is what
+`export --session` accepts; a unique prefix will do. `inspect` prints an archive's schedules, prompts and rules without
 writing anything, which is what you want before restoring on a machine you care about.
 
 ## export

package/docs/configuration.md

@@ -15,7 +15,7 @@ Everything lives under `~/.pi/agent/loops/` (override: `PI_LOOPS_DIR`).
 | `runs.jsonl`, `triggers-audit.jsonl` | run log (halved past 1 MB) and trigger audit (2 MB) |
 | `spend.json` | per-day totals of what rotation dropped from the run log, so a daily budget still counts it |
 | `sessions/<job-id>/`, `sessions/triggers-<project>-<hash>/` | sub-agent transcripts (20 per job, 40 per project's checks; the hash of the project's path keeps two projects named alike apart) |
-| `scheduler.<host>.json` | timer owner on this host: pid, heartbeat |
+| `scheduler.json` | timer owner on this machine: pid, heartbeat |
 | `presence/` | one file per live pi process: pid, session, cwd (who acts for which project) |
 | `host.json`, `host.log` | the headless host that keeps the clock while no pi is open: pid, and its log |
 | `polls.json` | last dynamic check per project (shared, so a hand-over never double-checks) |

package/docs/design.md

@@ -24,19 +24,21 @@ The premise is that **"pi was restarted" is the normal case**. Automation that d
 it was configured in is automation you cannot rely on, so jobs and rules live on disk for the whole
 machine. Everything here follows from that, and each one has a price.
 
-1. **Machine-global jobs and rules, each carrying a `cwd` and a `host`.** `/cron` and
+1. **Machine-global jobs and rules, each carrying a `cwd`.** `/cron` and
    `/triggers rules` show the current project by default, and say how many are elsewhere. A plain
-   (inject) job belongs to the session that created it: listed as `[dormant …]` while that session
-   is not open, parked as disabled once the session no longer exists (`/cron gc` removes it). A loop
+   (inject) job belongs to the session that created it — its result is a message in that
+   conversation — and everything that lists it agrees with dispatch about that: another session
+   shows it as `[session <id> — resume it to run]` with no next run, `cron_list` says the same to
+   the model, `/cron run` refuses it. Asleep is not broken. It is parked as disabled only once its
+   session's file has been deleted (`/cron gc` removes it). A loop
    whose `cwd` disappeared waits half an hour — a mount can be late at boot — and is disabled after
-   that. Jobs and rules stamped with another host (a shared `$HOME`) are ignored here and listed
-   with whose they are; leader election is per host.
+   that.
 
    The cost: a list has to be scoped, and a job you cannot see reads as a job that is gone. Hence
    the counts, the markers, and `/cron all`.
 
 2. **Who runs what.** Every process ticks. Loops run in the machine leader
-   (`scheduler.<host>.json`, a pid and a heartbeat). A project's dynamic checks and push
+   (`scheduler.json`, a pid and a heartbeat). A project's dynamic checks and push
    evaluations run in a pi that is *open in that project* — preferring the session that created the
    rules, lowest pid otherwise (`presence/`) — so a promotion lands in the conversation it belongs
    to. Only a project with no pi open falls to the leader, and its results go to the inbox
@@ -160,6 +162,18 @@ machine. Everything here follows from that, and each one has a price.
     not a permission, and the permissions that exist (the danger policy, the daily budget, branch
     protection on the remote) are the ones that hold.
 
+19. **One machine.** Until 0.19.0 every job and rule carried the hostname that created it, another
+    machine sharing the `$HOME` ignored it and listed it as `[other host]`, `/cron set --host`
+    re-homed it, and the leader file was named per host. None of it matched the way pi-loops is
+    used: pi runs on one machine, the loops run there, and a phone or a
+    laptop reaches the browser front end over a tailnet (`tailscale serve`) without moving the
+    execution anywhere. So the concept is gone: no `host` on a job or a rule (a stamp an older
+    build left is dropped when the file is read), no `--host`, no marker, `scheduler.json` and
+    `next-runs.json` plain. "Host" now means one thing here, the headless process.
+
+    The cost: two machines syncing one `$HOME` both run every job. That is not supported, and it
+    is said rather than half-handled.
+
 ## Where the browser front end came from
 
 pi owns the `pi` command and its terminal, so a second front end cannot replace the first one. It

package/docs/loops.md

@@ -10,8 +10,14 @@ Everything here is `/cron`; `/crontab` and `/loop` are the same command under ot
 
 When due, the prompt is injected into the session that created the job as a user message with the
 engine prefix `[Trigger <run-id>] `, and the agent runs one turn (an *inject-and-run* job). If the agent
-is busy the message is queued as a follow-up. Plain jobs fire only from the process whose current
-session created them; `--resume` brings that back.
+is busy the message is queued as a follow-up. A plain job belongs to the session that created it:
+its result is a message in that conversation, so it fires only in the process holding that session.
+Open another session and `/cron` lists it as `[session <id> — resume it to run]` with no next run,
+`cron_list` says the same to the model, and `/cron run` refuses it; `--resume` the session it
+belongs to and it wakes, catching up a missed slot if it was created with `--catchup`. It is not
+broken while it sleeps — it is waiting for its conversation. Something that should run whether or
+not a window is open (a nightly digest, a watch) is a loop: `--stateful`, with the inbox as its
+outlet.
 
 Schedules are local time: 5-field cron (`*/n`, ranges, lists, `mon-fri`, `jan`), the aliases
 (`hourly` / `every hour` / `once an hour` → `0 * * * *`; `daily` / `every day` → `0 9 * * *`;
@@ -106,8 +112,8 @@ and answer with one `<verdict n="i">keep|drop — reason</verdict>` per finding
 
 ## Restart behavior
 
-Jobs live in `~/.pi/agent/loops/jobs.json` and survive pi restarts. Exactly one pi process per
-host owns the timer (`scheduler.<host>.json`, 30-second ticks, 90-second heartbeat); when it exits
+Jobs live in `~/.pi/agent/loops/jobs.json` and survive pi restarts. Exactly one pi process on the
+machine owns the timer (`scheduler.json`, 30-second ticks, 90-second heartbeat); when it exits
 or dies another open pi takes over on its next tick. A tick that was missed while no pi was running
 is fired once at startup (collapsed, not replayed) for stateful loops unless `[cron] catch_up = false`;
 plain inject jobs do not catch up unless created with `--catchup` (`--no-catchup` turns it off for
@@ -116,12 +122,15 @@ loops). A run that died with its process is retried on the next tick; at most
 a server pushing many distinct events cannot open one sub-agent per event.
 Jobs run with the model and thinking level recorded
 on them (`/cron set <id> --model … --thinking … --timeout …`, `-` to follow the running session).
-`/cron scheduler` shows who owns the timer; `/cron` marks jobs as `[dormant …]` when their session
-is not open here, parks them as disabled once that session no longer exists (`/cron gc` removes
-them), and `[orphan: cwd missing]` when their checkout is gone — disabled half an hour later, since a
-mount can be late at boot. A job created by a sub-agent belongs to the session that ran it. A job
-stamped with another machine's hostname (a synced `$HOME`, a renamed machine, a rebuilt container) is listed as
-`[other host: <name>]` with no next run; `/cron set <ref> --host here` re-homes it.
+`/cron scheduler` shows who owns the timer; `/cron` marks a plain job as `[session <id> — resume it
+to run]` when its session is not open here, parks it as disabled once that session's file has been
+deleted (`/cron gc` removes it), and marks a loop `[orphan: cwd missing]` when their checkout is gone — disabled half an hour later, since a
+mount can be late at boot. A job created by a sub-agent belongs to the session that ran it.
+
+pi-loops runs on one machine. Two machines syncing one `$HOME` would both run every job; that is
+not supported (until 0.19.0 a hostname stamp on each job half-handled it, and is now ignored). To
+reach a running pi from elsewhere, use the browser front end over your tailnet ([cli.md](cli.md));
+the loops keep running where pi runs.
 
 ## Time, and which clock it is
 
@@ -147,14 +156,13 @@ Two things are deliberately still UTC, because neither is a time anybody reads:
 session file, which cannot hold the `+` and `:` an offset brings, and pi's own session header, whose
 format is pi's to decide.
 
-The offset in the run line above is the offset of **the machine that ran it**, not a fixed part of
-the prompt. That matters for one case in particular: a job with no `host` runs on any machine
-sharing the `$HOME` (`/cron set <ref> --host -` asks for that), so a stateful loop can alternate
-between machines in different timezones. Its notes are free text the model writes — watermarks,
+The offset in the run line above is the offset of the machine **at the time it ran**, not a fixed
+part of the prompt. A machine's clock is not a constant: `TZ` gets set, a laptop travels, a
+container is rebuilt in UTC. A loop's notes are free text the model writes — watermarks,
 "everything up to here has been seen" — and a watermark without an offset is a watermark the next
-machine cannot read. The prompt asks for the offset for that reason. Notes written before this
-version do not have it; a loop that crosses timezones and keeps a watermark is worth one look at
-`/cron state <id>`.
+run cannot read once the clock has moved. The prompt asks for the offset for that reason. Notes
+written before 0.14.1 do not have it; a loop that keeps a watermark on a machine whose timezone has
+changed is worth one look at `/cron state <id>`.
 
 ### Daylight saving
 

package/docs/triggers.md

@@ -97,7 +97,7 @@ rule evaluation, per window for injected pushes).
 /triggers sources     local checker + each MCP server: state, queued/dropped/deduped, tools
                       (/triggers hooks is the same view)
 /triggers enable <id> /triggers disable <id> /triggers remove <id>   also --all | --all-projects
-/triggers set <id>    --model | --thinking | --timeout | --host: what the action runs with
+/triggers set <id>    --model | --thinking | --timeout: what the action runs with
 /triggers run <id>    check one rule now, without waiting for its poll slot
 /triggers running     sub-agents in flight (dynamic checks and cron runs)   /triggers abort <trace>|--all
 /triggers audit [N]

package/docs/troubleshooting.md

@@ -1,8 +1,9 @@
 # Troubleshooting
 
 **Nothing fires.** `/cron scheduler`: is this process the timer owner or standby? If the owner died
-without cleanup, a standby takes over within 90 seconds. Jobs show `next …` when enabled. A plain
-job marked `[dormant …]` only fires in the session that created it (`--resume` it); a loop marked
+without cleanup, a standby takes over within 90 seconds. A job shows `next …` when it will run
+*here*. A plain job marked `[session <id> — resume it to run]` belongs to another session and fires
+only there (`--resume` it, or `/cron add` it again in this chat); a loop marked
 `[orphan: cwd missing]` was disabled because its checkout is gone.
 
 **A run failed.** `/cron runs` shows the error; `/cron trace <job> 1` shows the sub-agent's

package/docs/web-ui-parity.md

@@ -116,9 +116,7 @@ weaker, and worth converting whenever one of them breaks.
       says so as a count — without it, a job somewhere else is indistinguishable from a job that is
       gone. Jobs and rules are counted and labelled apart, each line naming the command that lists
       them (`/cron all`, `/triggers rules --all`): one number covering both agrees with neither
-      command, and the line exists to send you to the command. A job stamped with a hostname this
-      machine no longer has (a rebuilt container, a rename) is listed and marked, the way `/cron`
-      lists it, rather than filtered out of sight.
+      command, and the line exists to send you to the command.
       What counts as "this project" is what the extension says it is — symlinks resolved, `$HOME`
       too broad to be one — because a panel that disagrees with the command is worse than either.
       `test/web.test.ts`: *the panel and /cron agree about what this project is*.
@@ -215,6 +213,12 @@ weaker, and worth converting whenever one of them breaks.
       left is a file that `resume` lists, labelled by what was said in it rather than by a filename.
       `test/web.test.ts`: *a new session is a path pi has not written yet, and going back is one it
       has*. `test/web-page.test.ts`: *the session you are in is not offered as one to go back to*.
+- [x] **The session commands are two words here.** `/sessions` prints this project's sessions into
+      the feed — short id, when, what was first said — and `/session export [path]` / `/session
+      import <path>` are the archive commands, sent as `/session-export` / `/session-import`. pi's
+      own `/session` is a terminal command that does not exist over rpc, which is why the extension
+      had to hyphenate its names in the terminal and why the page is free to spell them plainly.
+      `test/web-page.test.ts`: */sessions and /session export are typed here*.
 - [x] A session started here is a session pi-loops recognises. pi names the sessions it starts after
       their id and the front end cannot know that id in time, so anything identifying a session by
       its file name is wrong about this one — which parked every inject-and-run cron job made in a

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@alphacoder-v0/pi-loops",
-  "version": "0.18.0",
+  "version": "0.19.2",
   "description": "An automation layer for pi: cron + stateful loops with a triage inbox, maker/checker verification, dynamic triggers, MCP notifications and tools, lifecycle hooks, session archives. A non-invasive pi extension.",
   "type": "module",
   "license": "MIT",

package/skills/pi-loops/SKILL.md

@@ -11,7 +11,8 @@ The user's pi has pi-loops installed. Prefer its tools over ad-hoc `sleep` loops
 
 | The user wants… | Use |
 |---|---|
-| "every day at 9 / hourly / 每小时 …" run something, result in this chat | `cron_create` with `stateful: false` |
+| "every day at 9 / hourly / 每小时 …" and the result belongs in this chat (a reminder, a question to answer here) | `cron_create` with `stateful: false` — it belongs to this session and runs only while this session is open; the user leaving the window means it sleeps |
+| anything that must run whether or not a window is open — a nightly digest, a report, a watch | `cron_create` with `stateful: true`, even when the user did not say "loop": a plain job cannot run unattended |
 | recurring watch/triage: "check X and tell me what changed", "report new issues" | `cron_create` with `stateful: true` — the loop keeps notes between runs and reports findings to `/inbox` instead of interrupting the chat |
 | the findings must be double-checked before the user sees them | `cron_create` with `stateful: true, verify: true` (a second adversarial sub-agent reviews each finding) |
 | "when <condition> happens, do <action>" (a file appears, a PR merges, a build finishes) | `new_trigger` — condition + action, fires once unless the user asks for repeating |

package/src/archive.ts

@@ -362,15 +362,14 @@ export function importSession(input: ImportInput): ImportSummary {
 			}
 			if (!SAFE_ID.test(raw.id)) throw new Error("cron sidecar contains an invalid job id");
 			// Automation off unless activated, stale run bookkeeping cleared.
-			// `host` is a hard run-time filter (scheduler.ts), so an archive restored on another
-			// machine must be re-stamped or every job would look enabled and never fire.
+			// A `host` stamp from a pre-0.19.0 archive is dropped: pi-loops runs on one machine.
 			// `createdBy` is left as the archive carries it: it names the session that created the job,
 			// which is what lets a second import of the same archive recognise itself. Re-stamping it
 			// with the fresh import session would make every import look new and double the automation.
+			const { host: _legacyHost, ...rawJob } = raw as typeof raw & { host?: unknown };
 			const job: LoopJob = {
-				...raw,
+				...rawJob,
 				cwd: input.targetCwd,
-				host: os.hostname(),
 				enabled: raw.enabled && input.activate,
 				running: undefined,
 				lastDueAt: undefined,
@@ -396,7 +395,8 @@ export function importSession(input: ImportInput): ImportSummary {
 		for (const raw of file.rules as DynamicTriggerRule[]) {
 			if (!raw || typeof raw.id !== "string" || typeof raw.condition !== "string" || typeof raw.action !== "string") throw new Error("trigger sidecar contains an invalid rule");
 			if (!SAFE_ID.test(raw.id)) throw new Error("trigger sidecar contains an invalid rule id");
-			const rule: DynamicTriggerRule = { ...raw, cwd: input.targetCwd, host: os.hostname(), enabled: raw.enabled && input.activate, createdBy: raw.createdBy ?? { sessionId: parsed.header.id } };
+			const { host: _legacyRuleHost, ...rawRule } = raw as typeof raw & { host?: unknown };
+			const rule: DynamicTriggerRule = { ...rawRule, cwd: input.targetCwd, enabled: raw.enabled && input.activate, createdBy: raw.createdBy ?? { sessionId: parsed.header.id } };
 			if (dedup.hasRule(rule)) continue;
 			if (input.existingRuleIds.has(rule.id)) rule.id = newRuleId();
 			if (raw.enabled) originallyEnabledRules.push(rule.id);

package/src/args.ts

@@ -145,7 +145,6 @@ export interface SetArgs {
 	timeoutMs?: number | null;
 	name?: string | null;
 	/** `"here"` = this machine; `null` = any machine. */
-	host?: string | null;
 	/** Jobs only: the new prompt, verbatim. A loop's notes live under its id, so rewording it here keeps them. */
 	prompt?: string;
 	/** Jobs only: already parsed, so a typo is rejected before it can be stored. */
@@ -163,7 +162,7 @@ export interface SetOptions {
  * `--model -` (or `current`) removes the pin.
  */
 export function parseSetArgs(input: string, opts: SetOptions = {}): SetArgs {
-	const usage = `usage: /cron|/triggers set <id> [--model <provider/id>|-] [--thinking <level>|-] [--timeout <dur>|-] [--name <n>|-] [--host here|-]${opts.job ? ' [--prompt "<text>"] [--schedule "<expr>"]' : ""}`;
+	const usage = `usage: /cron|/triggers set <id> [--model <provider/id>|-] [--thinking <level>|-] [--timeout <dur>|-] [--name <n>|-]${opts.job ? ' [--prompt "<text>"] [--schedule "<expr>"]' : ""}`;
 	const tokens = tokenize(input);
 	const out: SetArgs = { ref: "" };
 	let touched = 0;
@@ -186,12 +185,6 @@ export function parseSetArgs(input: string, opts: SetOptions = {}): SetArgs {
 		else if (t === "--thinking") out.thinking = clear ? null : requireThinkingLevel(val);
 		else if (t === "--timeout") out.timeoutMs = clear ? null : parseDuration(val);
 		else if (t === "--name") out.name = clear ? null : val;
-		// `--host here` re-homes a job stamped with a machine that no longer exists (a renamed box,
-		// a rebuilt container, or one half of a synced $HOME); `-` unpins it for any machine.
-		else if (t === "--host") {
-			if (!clear && val !== "here") throw new Error("--host takes `here` (this machine) or `-` (any machine)");
-			out.host = clear ? null : "here";
-		}
 		// Rewording a loop or moving it to another hour used to mean remove-and-re-add, which mints a
 		// new id — and the notes a stateful loop has been accumulating live at `state/<id>.md`.
 		else if (opts.job && (t === "--prompt" || t === "--schedule")) {

package/src/cli.ts

@@ -20,6 +20,7 @@ import { askHost, renderHostSnapshot } from "./host-control-channel.ts";
 import { liveHost, stopHost } from "./host-control.ts";
 import { type UiPrefs, readUiPrefs } from "./ui-prefs.ts";
 import { JobStore, defaultLoopsDir } from "./store.ts";
+import { automationBadge, previewText, readSessionHead } from "./session-head.ts";
 import { AUTONOMY_LEVELS, type AutonomyLevel, INSTALL_ROOT, TRACKER_FILE, addLineFor, ensureExcluded, installDirFor, installFiles, installedRecipes, listRecipes, loadRecipe, planInstall, playbookFiles, readRecord, resolveRecipeRef } from "./recipe.ts";
 import { TriggerStore } from "./triggers.ts";
 import { PI_LOOPS_VERSION } from "./version.ts";
@@ -98,7 +99,7 @@ export const CLI_USAGE = [
 	"    Imported automation stays disabled unless --activate-triggers=on (ask: prompt on a terminal).",
 	"",
 	"pi-loops sessions [--all] [--limit <n>]",
-	"    List session ids you can export, newest first.",
+	"    List sessions, newest first: short id, when it started, its automation, what was first said in it.",
 	"",
 	"pi-loops inspect <file>",
 	"    Show what an archive contains without writing anything.",
@@ -128,6 +129,10 @@ interface SessionFile {
 	file: string;
 	cwd: string;
 	mtimeMs: number;
+	/** The header's timestamp. */
+	startedAt?: string;
+	/** `/name`, or the first thing the person said — what tells two sessions apart. */
+	preview?: string;
 }
 
 /** pi keeps `<agentDir>/sessions/<encoded cwd>/<timestamp>_<uuid>.jsonl`; the header names the cwd. */
@@ -151,9 +156,9 @@ export function listSessions(sessionsRoot: string): SessionFile[] {
 			if (!name.endsWith(".jsonl")) continue;
 			const file = path.join(dir, name);
 			try {
-				const header = JSON.parse(fs.readFileSync(file, "utf8").split("\n", 1)[0] ?? "{}");
-				if (typeof header?.id !== "string") continue;
-				out.push({ id: header.id, file, cwd: typeof header.cwd === "string" ? header.cwd : "", mtimeMs: fs.statSync(file).mtimeMs });
+				const head = readSessionHead(file);
+				if (!head) continue;
+				out.push({ id: head.id, file, cwd: head.cwd, mtimeMs: fs.statSync(file).mtimeMs, startedAt: head.startedAt, preview: head.name ?? head.first });
 			} catch {
 				/* not a readable session */
 			}
@@ -254,7 +259,14 @@ export async function runCli(argv: string[], out: (line: string) => void = conso
 			out(flags.has("all") ? "no sessions recorded" : `no sessions recorded for ${cwd} (use --all)`);
 			return 1;
 		}
-		for (const s of here.slice(0, Number(str("limit") ?? 20))) out(`${s.id}  ${stamp(s.mtimeMs)}  ${s.cwd}`);
+		// One line a person can tell sessions apart by: short id, when it started, the automation the
+		// session has, what was first said in it. With --all the cwd sits after the id.
+		const jobs = new JobStore(loopsDir).load();
+		const rules = new TriggerStore(loopsDir).load();
+		for (const s of here.slice(0, Number(str("limit") ?? 20))) {
+			const badge = automationBadge(s.id, jobs, rules);
+			out(`${s.id.slice(0, 16)}  ${flags.has("all") ? `${s.cwd}  ` : ""}${(s.startedAt ?? stamp(s.mtimeMs)).slice(0, 16)}${badge ? `  [${badge}]` : ""}  ${s.preview ? previewText(s.preview) : ""}`.trimEnd());
+		}
 		return 0;
 	}
 

package/src/job-edit.ts

@@ -20,7 +20,6 @@ export interface JobEdit {
 	timeoutMs?: number | null;
 	name?: string | null;
 	/** "here" pins the job to this machine; null lets any machine run it. */
-	host?: string | null;
 	prompt?: string;
 	schedule?: Schedule;
 }
@@ -38,7 +37,6 @@ export interface AppliedJobEdit {
 
 export interface JobEditContext {
 	now: number;
-	hostName: string;
 	maxPromptBytes: number;
 	/** Called with the requested name and the other jobs; throws if it is not usable as a reference. */
 	checkName: (name: string, others: LoopJob[]) => void;
@@ -66,7 +64,6 @@ export function applyJobEdit(job: LoopJob, edit: JobEdit, ctx: JobEditContext):
 	if (edit.thinking !== undefined) patch.thinking = edit.thinking ?? undefined;
 	if (edit.timeoutMs !== undefined) patch.timeoutMs = edit.timeoutMs ?? undefined;
 	if (edit.name !== undefined) patch.name = edit.name ?? undefined;
-	if (edit.host !== undefined) patch.host = edit.host === "here" ? ctx.hostName : undefined;
 	if (edit.prompt !== undefined) {
 		patch.prompt = edit.prompt;
 		// The old wording is otherwise unrecoverable, and it is what ties "this loop started

package/src/job-health.ts

@@ -10,18 +10,17 @@ import { FAILURE_BACKOFF_AFTER } from "./scheduler.ts";
 import type { LoopJob } from "./store.ts";
 
 /**
- * Jobs failing on `hostName`, worst first. The threshold is the scheduler's backoff threshold, which
+ * Jobs failing, worst first. The threshold is the scheduler's backoff threshold, which
  * is the honest place to draw the line: below it a failure is a bad night, at it the scheduler has
- * already started widening the gap. A job pinned to another host (a shared $HOME) is that host's to
- * report, not ours.
+ * already started widening the gap.
  */
-export function failingJobs(jobs: LoopJob[], hostName: string): LoopJob[] {
-	return jobs.filter((j) => j.enabled && (!j.host || j.host === hostName) && (j.consecutiveFailures ?? 0) >= FAILURE_BACKOFF_AFTER).sort((a, b) => (b.consecutiveFailures ?? 0) - (a.consecutiveFailures ?? 0));
+export function failingJobs(jobs: LoopJob[]): LoopJob[] {
+	return jobs.filter((j) => j.enabled && (j.consecutiveFailures ?? 0) >= FAILURE_BACKOFF_AFTER).sort((a, b) => (b.consecutiveFailures ?? 0) - (a.consecutiveFailures ?? 0));
 }
 
 /** `2 job(s) failing (check-issues ×7)` — one clause, the worst one named, whatever the count. */
-export function failingSummary(jobs: LoopJob[], hostName: string): string | undefined {
-	const failing = failingJobs(jobs, hostName);
+export function failingSummary(jobs: LoopJob[]): string | undefined {
+	const failing = failingJobs(jobs);
 	const worst = failing[0];
 	if (!worst) return undefined;
 	const label = worst.name ?? worst.id;

package/src/job-owner.ts

@@ -0,0 +1,29 @@
+/**
+ * Where a job runs, as one question the scheduler, the lists and `/cron run` all ask the same way.
+ *
+ * A stateful loop belongs to the machine: whichever process holds the clock runs it. A plain job
+ * belongs to the session that created it — its result is a message in that conversation, so it
+ * fires only in the process holding that session. Another session sees it, and sees that it is
+ * asleep; it is not broken, and nothing here promises it a next run it will not get.
+ */
+import type { LoopJob } from "./store.ts";
+
+/** Would the process holding `sessionId` dispatch this job? (For a loop, only if it is also the leader.) */
+export function runsIn(job: Pick<LoopJob, "stateful" | "sessionId">, sessionId: string | undefined): boolean {
+	if (job.stateful) return true;
+	return !!sessionId && job.sessionId === sessionId;
+}
+
+/** The short form of the session a plain job belongs to. */
+export function ownerSession(job: Pick<LoopJob, "stateful" | "sessionId">): string | undefined {
+	return job.stateful ? undefined : (job.sessionId ?? "?").slice(0, 8);
+}
+
+/**
+ * The line a list shows for a plain job that will not run here — worded as what to do, because
+ * "not open here" was read as an error. Undefined when the job runs here.
+ */
+export function asleepNote(job: Pick<LoopJob, "stateful" | "sessionId">, sessionId: string | undefined): string | undefined {
+	if (runsIn(job, sessionId)) return undefined;
+	return `session ${ownerSession(job)} — resume it to run`;
+}