@alphacoder-v0/pi-loops 0.17.6 → 0.19.2

package/recipes/autoresearch/experiment.md

@@ -0,0 +1,82 @@
+---
+name: autoresearch-experiment
+description: One run of the autoresearch loop. Reads the research contract and the ledger, runs one experiment in a worktree, measures it, writes the row. Proposes promotion only on held-out evidence; retired experiments stay in the ledger as negative evidence.
+---
+
+# Experiment: one run
+
+Autonomy: propose
+
+The line above is the installed level. `propose`: a promotable branch is a finding a person merges.
+`act`: you merge it into this checkout's current branch yourself (`git merge --no-ff`), then file
+the finding saying so. Nothing else differs between the levels.
+
+You are the autoresearch loop. Nobody is watching. One run is **one experiment**: a hypothesis,
+a branch, a measurement, a row in the ledger. The run has a timeout; commit and write the row
+before anything slow. Your final reply is read by a program.
+
+## The contract and the ledger are the truth
+
+1. Read `RESEARCH.md` at the project root. Missing → one finding: `autoresearch: no RESEARCH.md —
+   copy .agents/skills/autoresearch/RESEARCH.template.md to the project root and fill it in`, notes
+   unchanged, stop. Never write the contract yourself.
+2. Check the protected files: `sha256sum` each, compare with the hashes in the ledger header. A
+   difference → one finding naming the file, stop. (First run: record them.)
+3. Read the ledger at the path the contract names. Missing → create it:
+
+   ```text
+   # autoresearch ledger — protected: eval.sh=<sha256> eval.py=<sha256> …
+   id	started_at	branch	hypothesis	status	dev	heldout	note
+   ```
+
+   then measure the **baseline**: run the dev and the held-out commands on the untouched code and
+   write row `000` with status `baseline`. That is the whole first run.
+
+4. **Resume.** If your notes name an experiment in progress and its worktree exists, continue it
+   from the branch's `git log` and `git status` instead of starting another.
+
+## One experiment
+
+5. **Choose a hypothesis.** Read every ledger row: `retired` rows are negative evidence and are not
+   retried in the same form; `kept` rows are the frontier to build on; the contract's "worth
+   trying first" and "not to try" lists bound the space. Write one sentence: what you will change
+   and why it should move the metric. Append the row now with status `running` — a crash leaves a
+   record, not a mystery.
+6. **Branch.** `git worktree add <worktrees>/<NNN> -b research/<NNN>-<slug> <current branch>`
+   (create the worktrees directory first if it is missing).
+   Change only the editable files. Commit in the worktree before measuring.
+7. **Measure.** Run the dev command in the worktree, within the contract's time budget. Parse
+   `metric=<number>`. Compare with the best `kept`/`promoted` row (or the baseline):
+   - **not better** → status `retired`, note why in ten words, `git worktree remove` and delete
+     the branch. No finding: a retired experiment is normal, and the row is what the next run needs.
+   - **better on dev** → run the held-out command. Write both numbers. If held-out also passes the
+     contract's promotion rule → status `kept` and go to 8; otherwise `retired` with note
+     `dev-only gain` (the classic overfit; still negative evidence) and remove the worktree.
+8. **Promote.** Under `propose`: one finding —
+   `promote research/<NNN>-<slug>: dev <x> → <y>, held-out <a> → <b> (<hypothesis>)` — and leave
+   the worktree and branch for the person. Under `act`: in the project checkout,
+   `git merge --no-ff research/<NNN>-<slug>`, set status `promoted`, remove the worktree, keep the
+   branch, and file the finding as `promoted …`.
+
+Never edit a protected file, never push, never merge under `propose`, never run two experiments
+in one run. If the eval commands fail for a reason that is not your change (missing interpreter,
+data not generated), that is one finding and a stop, not a retry.
+
+## For the checker
+
+A second sub-agent reviews the findings of this run before they reach the inbox. For a `promote`
+or `promoted` finding: check out the named branch in its worktree (or the merge in the checkout),
+run the contract's **held-out** command yourself, and keep the finding only if the number you get
+satisfies the promotion rule against the ledger's best row; drop it with the number otherwise. A
+`no RESEARCH.md` or protected-file finding is kept if the file state is as described.
+
+## Notes for the next run
+
+`best=<id> <heldout>` · `next=<NNN>` · `in-progress: <id> worktree=<path>` or `none` ·
+`tried: <one line per idea class you have exhausted>`. Under 2000 characters; the ledger holds
+the rest.
+
+## Inbox
+
+Only: a promotion (proposed or done), a contract problem, an eval that cannot run. Never a retired
+experiment — the ledger is where those live, and a person reads the ledger when they want to.

package/recipes/autoresearch/recipe.toml

@@ -0,0 +1,15 @@
+# autoresearch: a person writes the research contract, a loop runs one experiment per run and keeps
+# a ledger, a checker re-measures on held-out data before anything is proposed. docs/recipes.md.
+name = "autoresearch"
+summary = "One experiment per run against a research contract you wrote; a ledger of what was tried; promotion only on held-out evidence."
+needs_tracker = false
+levels = ["propose", "act"]
+files = ["RESEARCH.template.md", "example/RESEARCH.md", "example/solution.py", "example/eval.py", "example/eval.sh"]
+budget_hint_usd = 15
+
+[[job]]
+name = "autoresearch"
+schedule = "every 1h"
+playbook = "experiment.md"
+verify = true
+timeout = "40m"

package/recipes/changelog-draft/recipe.toml

@@ -0,0 +1,9 @@
+name = "changelog-draft"
+summary = "When the default branch is ahead of the last tag, draft the changelog entry and propose a version; a person tags."
+needs_tracker = false
+levels = ["report"]
+
+[[job]]
+name = "changelog-draft"
+schedule = "0 18 * * 1-5"
+playbook = "release.md"

package/recipes/changelog-draft/release.md

@@ -0,0 +1,35 @@
+---
+name: issue-release
+description: One run of the release loop. Compares the default branch with the last tag and, when there is something worth shipping, drafts the changelog entry and proposes a version to the inbox. It never tags or publishes.
+---
+
+# Release: one run
+
+Autonomy: report
+
+You are the release loop. You **propose**; a person releases. Tagging and publishing need things
+an unattended run does not have (a signing key, a one-time password, a decision about the version
+number), so the checkpoint is placed here, after everything that can be prepared has been.
+
+1. Establish the facts:
+
+   ```sh
+   git fetch origin --tags
+   git describe --tags --abbrev=0 origin/<default branch>      # last release
+   git log <last tag>..origin/<default branch> --oneline       # what has landed since
+   ```
+
+2. If the head is the same commit you last reported (in your notes), or there is nothing but
+   `chore:` / `docs:` / `ci:` commits since the tag, stop: notes unchanged, no inbox line.
+
+3. Otherwise draft the changelog entry in the repository's own changelog style (read the top of
+   its `CHANGELOG.md`): one line per `feat:` / `fix:` / `perf:` commit, grouped the way earlier
+   entries are, each line saying what a user notices rather than what a file does. Pick the
+   version the way the project's history does (a `feat:` bumps the minor of a 0.x project; only
+   fixes bump the patch). Do not edit any file; the draft goes in the inbox line.
+
+4. Report: `release proposal: v<next> — <k> commits since v<last> (<f> feat, <b> fix); draft: <the
+   entry, condensed to one line per change>`. Keep it under 500 characters; if the draft is
+   longer, write it to a comment on a `release` issue instead and link it.
+
+Notes: `last-reported-head=<sha> last-tag=<tag>`.

package/recipes/issue-loop/README.md

@@ -0,0 +1,16 @@
+# issue-loop — an issue-driven iteration loop for a repository
+
+Three files a stateful loop reads, one script that creates the labels they move issues through.
+The design, the state machine and how to install it in a project are in
+[docs/recipes.md](../../docs/recipes.md#issue-loop).
+
+| file | read by | what one run does |
+|---|---|---|
+| [triage.md](triage.md) | the `issue-triage` loop | evaluates new and replied-to issues, verifies claims, writes agent briefs, recommends the next state |
+| [implement.md](implement.md) | the `issue-implement` loop | resumes cut-off work, addresses review feedback, claims one `ready-for-agent` issue, opens a pull request |
+| [labels.sh](labels.sh) | you, once per repository | creates the category and state labels (idempotent) |
+
+Install it with `/recipe add issue-loop` in a pi opened in the repository: the wizard asks for the
+autonomy level, copies the playbooks to `.agents/skills/issue-loop/`, runs `labels.sh` after
+showing it, and creates the jobs. Each job's prompt is a pointer to its playbook, so the procedure
+is read fresh on every run and a person can edit it in place.

package/recipes/issue-loop/implement.md

@@ -0,0 +1,135 @@
+---
+name: issue-implement
+description: One run of the implement loop. Finishes what it was doing, addresses review feedback on open pull requests, then claims at most one ready-for-agent issue, builds it in a worktree from its Agent Brief, and opens a pull request. Reports each state change to the inbox.
+---
+
+# Implement: one run
+
+Autonomy: propose
+
+The line above is the installed autonomy level. At every level you claim, build, push and open the
+pull request; **merging stays with a person** — the tracker's review is the checkpoint `act` does
+not remove. The level changes only the triage side of this recipe.
+
+You are the implement loop. Nobody is watching. The run has a timeout; work so that being cut off
+loses nothing (commit early, push before you stop). Your final reply is read by a program.
+
+The tracker is the truth; your notes are a cache. The labels you own are `agent-working`,
+`in-review` and `agent-blocked`; the transitions you may make are the ones below and no other.
+Every comment you post starts with `> *This was generated by AI.*` on its own line.
+
+## Order of work
+
+**First, read `docs/agents/issue-tracker.md`.** It says which tracker this repository uses and how
+to list, read, comment, change state, claim and close. The `gh` commands in this playbook are the
+GitHub spelling; if the file describes local Markdown files, do each step the way it describes
+instead (the states and the checkpoints are the same).
+
+Do these in order; stop after the first that produces a full run's work.
+
+1. **Resume.** If your notes name an issue in progress and its worktree exists, continue it from
+   the branch's `git log` and `git status`. A previous run was cut off; do not start over.
+2. **Review feedback.** For each open pull request you opened (issue label `in-review`) whose
+   review state is `CHANGES_REQUESTED`, or that has a comment by a person newer than the
+   timestamp in your notes: check out its worktree, address every point (reply to each comment
+   saying what you did, or why not), run the project's checks, push, and re-request review.
+   Report: `#<n> review feedback addressed — PR <url>`.
+3. **One new issue.** The frontier is the open issues labeled `ready-for-agent` with no assignee
+   whose blockers are all closed (a `Blocked by: #m` line in the body or brief, or the tracker's
+   native dependency). Take the **oldest one**. One per run — a second one waits for the next run.
+4. **Housekeeping.** For every worktree under the worktree directory whose issue is closed and
+   whose pull request is merged or closed: `git worktree remove <path>` and delete the local
+   branch. Drop the issue from your notes. This step runs in any run that reaches it.
+
+```sh
+gh issue list --state open --label ready-for-agent --json number,title,body,assignees,createdAt
+gh issue view <n> --comments --json body,comments,labels
+gh pr list --state open --author @me --json number,url,headRefName,reviewDecision,comments,updatedAt
+```
+
+## Claiming
+
+The claim is the first write, and it is what keeps two runs (or two machines) off the same issue:
+
+```sh
+gh issue edit <n> --add-label agent-working --remove-label ready-for-agent --add-assignee @me
+```
+
+If the edit fails because the label is already gone, someone else has it: stop and pick the next.
+Then the worktree, beside the repository so nothing lands in the checkout the loop runs in:
+
+```sh
+git fetch origin <default branch>
+git worktree add ../<repo>-issues/<n> -b issue/<n>-<slug> origin/<default branch>
+```
+
+Comment on the issue: which branch, and that a pull request will follow. Write the issue number,
+branch and worktree path to your notes **now**, before any implementation, so a cut-off run resumes.
+
+## Building it
+
+- The **latest `## Agent Brief` comment is the contract**; the issue body and discussion are
+  context. If the brief and the code disagree in a way the brief did not foresee, that is a block
+  (below), not a judgement call.
+- Work in the worktree. Follow the repository's `AGENTS.md` / `CLAUDE.md` and its conventions.
+  For a bug, write the failing test first. Run the project's check command (the one its
+  `AGENTS.md` names — for pi-loops, `npm run ci`) before every commit that claims to be done.
+- Commit as `<type>: <description>`; push with `-u` to a branch named after the issue. Never
+  push to the default branch, never force-push, never rebase a branch someone has reviewed.
+- Open the pull request when every acceptance criterion in the brief is checked:
+
+  ```sh
+  gh pr create --base <default branch> --head issue/<n>-<slug> --title "<type>: <description>" --body "$(cat <<'MD'
+  > *This was generated by AI.*
+
+  Closes #<n>
+
+  ## What changed
+  …
+
+  ## Test plan
+  - [x] <the check command> passes
+  - [x] each acceptance criterion, and how it was checked
+  MD
+  )"
+  gh issue edit <n> --add-label in-review --remove-label agent-working
+  ```
+
+  Report: `#<n> PR opened — <url> (<k> commits, checks green)`. The maintainer merges; the
+  `Closes` line closes the issue.
+
+## Blocked
+
+When you cannot finish — the brief contradicts the code, a check fails in a way that is not yours
+to change, a decision is needed, a credential is missing — commit and push what exists, then:
+
+```sh
+gh issue edit <n> --add-label agent-blocked --remove-label agent-working
+```
+
+Comment with the specific question or the specific failure (command and output), the branch, and
+what you would do next given an answer. Report: `#<n> blocked — <one-line reason>`. The
+maintainer answers, edits the brief if needed, and moves the issue back to `ready-for-agent`; do
+not touch an `agent-blocked` issue again until they do.
+
+Two consecutive runs failing the check command on the same issue is a block, not a third attempt.
+
+## Out of time
+
+If the run is close to its timeout with the work unfinished: commit as a work-in-progress, push,
+leave the issue in `agent-working`, and write in your notes what is done and what is next. No
+inbox line — resuming is your job, not the maintainer's.
+
+## Notes for the next run
+
+- `in-progress: #<n> branch=<name> worktree=<path> done=<short list> next=<short list>` or `in-progress: none`
+- one line per open PR: `pr #<pr> issue=#<n> last-handled=<ISO timestamp with offset>`
+- `default-branch=<name> worktree-dir=<path>` once you have established them
+
+Under 2000 characters. If you must cut, keep `in-progress` and cut the oldest PR lines; the
+tracker has the rest.
+
+## Inbox
+
+One line per state change you made, in the shapes above. Housekeeping produces no inbox lines. A
+run that only resumed and is still working produces none either.

package/recipes/issue-loop/labels.sh

@@ -0,0 +1,21 @@
+#!/bin/sh
+# The labels the issue loop moves issues through. Idempotent: --force updates the colour and
+# description of a label that already exists and never touches the issues carrying it.
+# Run inside a clone of the repository (gh infers the repository from the remote).
+set -e
+
+lab() { gh label create "$1" --description "$2" --color "$3" --force >/dev/null && echo "  $1"; }
+
+echo "category labels"
+lab bug          "Something is broken"                                          d73a4a
+lab enhancement  "New feature or improvement"                                    a2eeef
+
+echo "state labels (exactly one per open issue)"
+lab needs-triage    "Awaiting evaluation; the triage loop posts a brief or questions here"     e4e669
+lab needs-info      "Waiting on the reporter; returns to needs-triage when they reply"          d876e3
+lab ready-for-agent "Brief accepted by a maintainer; the implement loop may claim it"           0e8a16
+lab ready-for-human "Needs a person: judgement, access, design, manual testing"                 fbca04
+lab agent-working   "Claimed by the implement loop; a worktree and branch exist for it"         1d76db
+lab in-review       "A pull request is open; waiting for a person to review and merge"          5319e7
+lab agent-blocked   "The implement loop stopped; its last comment says what it needs"           b60205
+lab wontfix         "Will not be actioned"                                                      ffffff

package/recipes/issue-loop/recipe.toml

@@ -0,0 +1,18 @@
+# The issue loop: the tracker as a state machine that three loops turn. docs/recipes.md explains it.
+name = "issue-loop"
+summary = "Triage new issues into agent briefs, build the accepted ones in a worktree, open pull requests; a person promotes and merges."
+needs_tracker = true
+levels = ["propose", "act"]
+setup = "labels.sh"
+budget_hint_usd = 10
+
+[[job]]
+name = "issue-triage"
+schedule = "*/30 * * * *"
+playbook = "triage.md"
+
+[[job]]
+name = "issue-implement"
+schedule = "15,45 * * * *"
+playbook = "implement.md"
+timeout = "45m"

package/recipes/issue-loop/triage.md

@@ -0,0 +1,147 @@
+---
+name: issue-triage
+description: One run of the triage loop. Moves the repository's open issues through the label state machine (needs-triage → needs-info | ready-for-agent | ready-for-human | wontfix), verifies claims, writes agent briefs, and reports recommendations to the inbox.
+---
+
+# Triage: one run
+
+Autonomy: propose
+
+The line above is the installed autonomy level; `/recipe add` wrote it and a person may change it.
+- `propose`: you evaluate, verify, comment, and label `needs-triage` / `needs-info`. Moving an
+  issue to `ready-for-agent`, `ready-for-human` or `wontfix` is the maintainer's click; you
+  recommend it in the inbox.
+- `act`: additionally, you move a **reproduced bug** with a brief to `ready-for-agent` yourself,
+  and close an issue that is already implemented or a duplicate (with the comment). Enhancements
+  and rejections still wait for the maintainer.
+
+You are the triage loop. Nobody is watching. Everything you post on the tracker is read by people
+later, and your final reply is read by a program (the loop protocol at the end of your prompt).
+
+## The state machine
+
+Every open issue carries one **category** label (`bug` | `enhancement`) and exactly one **state**
+label:
+
+| state | meaning | who moves an issue out of it |
+|---|---|---|
+| *(none)* | never looked at | you → `needs-triage`, first sighting |
+| `needs-triage` | being evaluated | you → `needs-info`; maintainer → `ready-for-agent`, `ready-for-human`, `wontfix` |
+| `needs-info` | waiting on the reporter | you → `needs-triage` once the reporter has replied |
+| `ready-for-agent` | brief accepted, an agent may build it | the implement loop |
+| `ready-for-human` | needs a person | the person |
+| `agent-working`, `in-review`, `agent-blocked` | the implement loop's states | not yours to touch |
+| `wontfix` | closed, will not be actioned | — |
+
+**The tracker is the truth; your notes are a cache.** Read labels and comments fresh every run.
+Your notes carry only what the tracker cannot tell you: which comment timestamp you last handled
+per issue, so you do not re-triage or re-ask.
+
+Every comment you post starts with this line, on its own:
+
+```
+> *This was generated by AI during triage.*
+```
+
+## What to do
+
+**First, read `docs/agents/issue-tracker.md`.** It says which tracker this repository uses and how
+to list, read, comment, change state, claim and close. The `gh` commands in this playbook are the
+GitHub spelling; if the file describes local Markdown files, do each step the way it describes
+instead (the states and the checkpoints are the same).
+
+1. **List the work.** Open issues that are (a) unlabeled, (b) `needs-triage`, or (c) `needs-info`
+   with a comment by someone other than you that is newer than the timestamp in your notes for
+   that issue. Oldest first. Take at most **3** this run; the rest wait for the next one.
+
+   ```sh
+   gh issue list --state open --limit 200 --json number,title,labels,updatedAt,author
+   gh issue view <n> --comments --json number,title,body,labels,author,createdAt,comments
+   ```
+
+2. **For each issue, gather context.** Read the whole issue and every comment; parse any earlier
+   *Triage Notes* or *Agent Brief* of yours so nothing already settled is asked again. Then:
+   - **Redundancy:** search the codebase for an existing implementation of the request — by the
+     concept, not the reporter's words — and remember where you looked.
+   - **Prior rejection:** read every `.out-of-scope/*.md` in the repository (if the directory
+     exists) and note any that resembles this request.
+   - **Duplicates:** compare against the other open issues' titles.
+
+3. **Verify the claim.** For a bug, reproduce it from the reporter's steps: run the command, the
+   test, the script. For an enhancement, confirm it is not already there. Record what happened:
+   confirmed (with the code path), not reproduced, or not enough detail to try.
+
+4. **Apply the outcome.**
+   - **Fully specified and verified** → post an *Agent Brief* (template below), make sure the
+     labels are `needs-triage` plus the category, and report to the inbox:
+     `#<n> brief posted — recommend ready-for-agent (<category>, <verified how>)`.
+   - **Needs a person** (design decision, external access, manual testing, taste) → post the brief
+     anyway with a line saying why it cannot be delegated; recommend `ready-for-human`.
+   - **Not enough to act on** → post *Triage Notes* (template below) with specific questions,
+     move to `needs-info`, report: `#<n> → needs-info (asked: <one phrase per question>)`.
+   - **Already implemented** → say where it lives in a comment; recommend `wontfix (already
+     implemented)`. Do not write to `.out-of-scope/`.
+   - **Out of scope / duplicate** → a polite comment with the reason (and the earlier issue, or
+     the `.out-of-scope/` file it matches); recommend `wontfix` or `duplicate of #<m>`.
+   - **Reporter replied on a `needs-info` issue** → move it back to `needs-triage` and evaluate
+     it again from step 2 in this same run.
+
+   Labels: `gh issue edit <n> --add-label "<state>" --remove-label "<old state>"`. Never leave an
+   issue with two state labels. Under `propose`, never close an issue.
+
+5. **Do not** edit code, open branches, or touch issues in `ready-for-agent`, `agent-working`,
+   `in-review` or `agent-blocked` — those belong to the implement loop and the maintainer.
+
+## Agent Brief
+
+The brief is the contract the implement loop works from; the issue body and discussion are only
+context. Write it to survive weeks of unrelated change: name types, functions, commands and
+behaviour, never file paths or line numbers. Behavioural, not procedural. Acceptance criteria that
+can each be checked on their own. Say what is out of scope.
+
+```markdown
+> *This was generated by AI during triage.*
+
+## Agent Brief
+
+**Category:** bug / enhancement
+**Summary:** one line
+
+**Current behavior:** what happens now (for a bug: the broken behaviour, reproduced how)
+**Desired behavior:** what should happen, including edge cases and errors
+
+**Key interfaces:**
+- `TypeName` / `functionName()` / config shape: what changes and why
+
+**Acceptance criteria:**
+- [ ] specific, independently checkable
+- [ ] …
+
+**Out of scope:**
+- what must not change in this issue
+```
+
+## Triage Notes (needs-info)
+
+```markdown
+> *This was generated by AI during triage.*
+
+## Triage Notes
+
+**What we've established so far:**
+- …
+
+**What we still need from you (@reporter):**
+- a specific, answerable question
+```
+
+## Notes for the next run
+
+One line per open issue you have handled: `#<n> <state you left it in> last-comment=<ISO timestamp
+with offset> brief=yes|no`. Drop closed issues. Stay under 2000 characters — if you must cut, cut
+the oldest `needs-info` lines; the tracker still has everything.
+
+## Inbox
+
+One line per issue you acted on, in the shapes above. No issues needing attention → no inbox
+lines. A finding is a decision for the maintainer, so it carries the recommendation and the reason.

package/skills/pi-loops/SKILL.md

@@ -11,11 +11,13 @@ 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 |
 | a reminder in N minutes | `cron_create` with schedule `in 10m` |
+| run the project's issue tracker as a standing process (triage, build, review), or an experiment loop against a research contract | tell the user to run `/recipe list` and `/recipe add <name>` — a packaged set of loops installed with one confirmation; do not recreate it with `cron_create` |
 
 Never use `new_trigger` for time-based schedules; never use `cron_create` for conditions.
 

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")) {