samagotchi 0.159.0 → 0.160.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: ab720ab347312f152fc99a03ca8cd423a640de2c9b4221ccc70803396a2d8c09
-  data.tar.gz: 313bbe5c7cce008df50c73de233557824723566db8449a8e3a04ff01e85343f9
+  metadata.gz: 9f4ca470372c140d0bcdc30583312ee1139b05b878a8e0f4688f9401a7af3700
+  data.tar.gz: dfd3b0bf49a29758ea645bdf4ac6614c9a93610f013e7517d75d8eefe4b3e3ab
 SHA512:
-  metadata.gz: 4c02cc469245adaa130c74b1e10978c11b51e85f7ff8c2fe9c27d0de68682d0452f07d9dec7f9100c032dac9cf7357bff81fc70586c9c6cb1e99ab0327c68d56
-  data.tar.gz: 7ffaacdca84dc1396e5f6edd1160b54e063daa38b71d9aa7c36d7619495d26271606efd277024f344e18043ed2112f3343ea127560438bea0f5480b98df617f3
+  metadata.gz: 18bd973f0dfffd58845df4341e41a2f3d32292a4d158e866cf76d907b64d9aac4539bacfc0a9cbc4a81a05b5a3bcc81cf8fec8413f52deb0a95c7141a6235082
+  data.tar.gz: 2c2aaf26b58566064737487ae20dfc7037a752f20e426c80375ca0068e14f31e85ac2bc5927522c500dd4622c17f7696e0e93aadf3697cb79cf6b7d08e00669d

data/CHANGELOG.md

@@ -8,6 +8,44 @@ and commands may change between minor versions. How releases are made:
 
 ## [Unreleased]
 
+## [0.160.0] - 2026-11-09
+
+### Added
+
+- A folder made a chi project with `chi project init` keeps its memories when you move or rename it (an `id:` in
+  .chi/project.yml); rerun `chi project init` in an older project to adopt one, `--new-id` to split a copied folder.
+
+### Changed
+
+- `schedules.json` keeps what a newer chi wrote (its format version, unknown fields, entries this chi can't read) when
+  an older chi rewrites it.
+- The `SessionManager.run_session_loop` forwarder for older boot strings is gone: a chi web or terminal still
+  running 0.158.0 or older must be restarted after updating, because a worker it spawns names that entry.
+
+### Fixed
+
+- A message that starts with `!` runs as a shell command only when a person sends it (a web tab, a chi TUI, `chi send`):
+  from a delegating parent, a schedule or a plugin it is refused and nothing runs, and a `/command` line from them is
+  plain text for the model. `chi answer`'s lines (a parent agent's `/continue yes`, `/parent-answers`) still run as
+  commands, with the same trust as `chi send`.
+- A delegate's task and a chain schedule's firing now start their session as their sender's turn, not yours: its
+  `last_turn` origin reads `delegate` or `schedule`, the turn counts as automatic in the session's metrics, and the
+  objectives audit skips it as it skips a delegate's follow-up; it no longer counts as your input either (it doesn't
+  unarchive the session or reset its wakes). Restart `chi web` (and any worker) after updating: one
+  still running the older chi starts chain links whose first message runs as yours.
+- `delegate`, `schedule_task` and `chi schedule add` refuse a task or prompt that starts with `!`, saying why, so the
+  model can write it as an instruction. A schedule stored with one before this fails when it fires (counted toward
+  its `max_failures`; nothing is started or delivered).
+- A command you allow "for this session" is allowed again only in the same worktree or folder, with the same `env:`
+  (kept as a digest); the same text run in another checkout asks again. Session approvals stored before this ask one
+  more time.
+- `chi bundle upgrade` and `chi update` report a replaced guardrail rule as Updated, like other bundle assets.
+- Bundle install, upgrade and dry runs now name the guardrail, plugin and script files a new version drops.
+- `chi bundle upgrade --dry-run` names edited files it would copy to the trash, including marked memories.
+- `chi bundle uninstall` names a plugin it removes even when the bundle has no memories or hooks.
+- `chi bundle status` labels retired hooks as present or missing; they are not loaded.
+- `chi update` plan rows name memory files a shipped bundle adds.
+
 ## [0.159.0] - 2026-11-09
 
 Update with `chi update`.
@@ -5884,7 +5922,8 @@ and long-lived sessions.
 - A macOS desktop helper (`chi desktop install`): a "Send to chi" Service and a
   hotkey panel that send selected text or the clipboard to your sessions.
 
-[Unreleased]: https://github.com/dm1try/samagotchi/compare/v0.159.0...HEAD
+[Unreleased]: https://github.com/dm1try/samagotchi/compare/v0.160.0...HEAD
+[0.160.0]: https://github.com/dm1try/samagotchi/compare/v0.159.0...v0.160.0
 [0.159.0]: https://github.com/dm1try/samagotchi/compare/v0.158.0...v0.159.0
 [0.158.0]: https://github.com/dm1try/samagotchi/compare/v0.157.0...v0.158.0
 [0.157.0]: https://github.com/dm1try/samagotchi/compare/v0.156.0...v0.157.0

data/docs/architecture.md

@@ -105,7 +105,7 @@ terminal renders the events it gets over the Bridge.
 | Adapters | `Samagotchi::Client`, `LLM::OpenAIChat`, `LLM::AnthropicMessages`, `LLM::HTTP` | Raw-prompt servers, the OpenAI chat API, Anthropic's Messages API, and the HTTP they share. |
 | Tools | `lib/samagotchi/tools/*` | Execute, read, edit, write, memory, task_*, web_fetch, delegate/delegate_result, ask_user_question, reminders, send_note, list_sessions, context_read, objectives, forget_outputs, find_tools/call_tool (the tool index), plus runtime/output-guardrails. |
 | Bundles | `lib/samagotchi/memory_bundle/*`, `BundleCommand` | `chi bundle`: install/upgrade (3-way, with a text merge of edited memories), build, uninstall; the install record under `.bundles/<name>/` that the guardrail and plugin loaders read ([internals/bundles.md](internals/bundles.md)). |
-| Background | `Samagotchi::Worker`, `Samagotchi::SessionManager` | `SessionManager` (`session_manager.rb`, its parts in `session_manager/`: spawn · worker_command · listing · delivery · lifecycle · removal · emptiness) forks/spawns one worker process per session. The worker process's main (owner lock, detach, signals, project env, what it does as it leaves) is `WorkerBoot` (`worker_boot.rb`), which the boot string loads directly; SessionManager's `run_session_loop` forwarder stays for older spawners' strings. Its `Worker` builds the `Engine` and `Bridge` (no terminal rendering) and runs queued turns. The spawned process (own process group) forks the worker, which `setsid`s and is reparented to init once its starter exits (it waits until the worker holds `owner.lock`, so the spawner's `Process.detach` waiter tells a starting worker): nothing that walks the spawner's process tree reaches it (`SAMAGOTCHI_WORKER_DETACH=1`, `detach_from_spawner`). The lock's pid is the worker's; `spawn`'s `child_pid` is its starter's. |
+| Background | `Samagotchi::Worker`, `Samagotchi::SessionManager` | `SessionManager` (`session_manager.rb`, its parts in `session_manager/`: spawn · worker_command · listing · delivery · lifecycle · removal · emptiness) forks/spawns one worker process per session. The worker process's main (owner lock, detach, signals, project env, what it does as it leaves) is `WorkerBoot` (`worker_boot.rb`), which the boot string loads directly. Its `Worker` builds the `Engine` and `Bridge` (no terminal rendering) and runs queued turns. The spawned process (own process group) forks the worker, which `setsid`s and is reparented to init once its starter exits (it waits until the worker holds `owner.lock`, so the spawner's `Process.detach` waiter tells a starting worker): nothing that walks the spawner's process tree reaches it (`SAMAGOTCHI_WORKER_DETACH=1`, `detach_from_spawner`). The lock's pid is the worker's; `spawn`'s `child_pid` is its starter's. |
 | Web | `Samagotchi::Web::App`, `Samagotchi::Web::Server`, `Samagotchi::Web::SessionHub` | Rack+WEBrick on one port, `127.0.0.1:4567` (index.html + `/api/*` + SSE); with `web.host: lan` also on this machine's LAN address, behind an access token (`Web::Lan`, `Web::Token`). The hub is chi web's projection of the session list, pushed to every tab over `GET /api/events`. |
 | Sessions | `Samagotchi::Session`, `SessionManager` | File `sessions/<uuid>.json` + sidecar `input/`/`output/`; retention 14d/500, `updated_at desc`, lazy sweep. |
 
@@ -162,9 +162,8 @@ Unchanged: `ContextProviders`' `{ruby}` (`RbConfig.ruby`: the home's ruby inside
 project env below, so a `mise env` that sets GEM_HOME reaches it), `chi bundle
 try/test/check` (`-I LIB_DIR`), hooks (in-process). The worker's boot string, `run_session_loop(id, state_dir:)` and
 `SAMAGOTCHI_BOOT_FALLBACK` stay the cross-version contract (`spec/worker_contract_spec.rb`): the home only adds the
-prelude in front. The string names `WorkerBoot.run_session_loop`, the worker's main; the SessionManager forwarder
-remains one more release for boot strings written by older spawners. An older chi that wakes a session doesn't read
-home.json and starts its worker as before.
+prelude in front. The string names `WorkerBoot.run_session_loop`, the worker's main. An older chi that wakes a
+session doesn't read home.json and starts its worker as before.
 
 **The tools a worker runs** follow the project, not the boot, and only they do: a spawned worker
 (`WORKER_PROCESS_ENV`; never an in-process loop) calls `ProjectEnv.compute` in `WorkerBoot.run_session_loop`, after the owner
@@ -471,7 +470,7 @@ model: [internals/remote-sessions.md](internals/remote-sessions.md).
 | `DELETE /api/sessions/:id/context/:name?own=1` | owner | | 200 `{status: detached}`: the session's own only | 409 `project_source` (chi context rm's words); 404 |
 | `POST /api/sessions/:id/stop` | owner | `wait?` (seconds, capped at `SessionManager::STOP_WAIT`, 10: `chi --remote NAME sessions stop` sends it) | 200 `{status: stopped, session_id, released}`: `released`, whether the worker let go within the wait (without one `STOP_WAIT_SECONDS`, 2 s: the page's Stop) | 409 `owned_by_tui` |
 | `DELETE /api/sessions/:id?force=` | owner | `force=true` stops a live worker first (the page sends it) | as before | 409 `worker_running` without it |
-| `GET /api/sessions/:id?brief=1` | participant (theirs: title, status, participants) | | 200 `{brief, session: {id, status (the file's), title, display_title, project_root, working_directory, model_name, model_typed, parent_answers, owner}, pending_question}` (the file's; no messages): `Remote#show` | 404 |
+| `GET /api/sessions/:id?brief=1` | participant (theirs: title, status, participants) | | 200 `{brief, session: {id, status (the file's), title, display_title, project_root, project_id, working_directory, model_name, model_typed, parent_answers, owner}, pending_question}` (the file's; no messages): `Remote#show` | 404 |
 | `POST /api/sessions/:id/turn` (its 202) | owner | | the ack with `via`: `bridge` or `file` (the input file: a remote `chi send --wait` follows that turn) | |
 | `GET /api/sessions/:id/context?full=1`, `…/context/:name?full=1` | owner | | each row with `source` (`Source#to_h`, its command too; the page's rows never carry one), `snapshot` (`Snapshot#to_h`, no text) and `shadowed`, shadowed project sources included | |
 | `POST /api/sessions/:id/wake` | owner | `wait` (seconds, default and most 10: `WAKE_MAX_WAIT`) | 200 `{session_id, woke, worker: {epoch, started_at, version, features}, model_name, default_model, parent_strategy, installed}`: the live worker as is (`woke: false`), else resumed and its Bridge waited for (`Local#wake`); `default_model` and `installed` are this machine's | 409 `owned_by_tui`, `scratch` (`Session::SCRATCH_REFUSED`); 504 `worker_timeout` (`LaunchMode::BRIDGE_LATE`); 400 `invalid_wait`; 404 |
@@ -655,7 +654,7 @@ A map of the parts the overview above doesn't name (paths under `lib/samagotchi/
 | Dialects | `llm/dialect.rb` (`LLM::Dialect`) | What an `api: anthropic` provider's `/v1/messages` does differently (`dialect: fireworks`) ([internals/anthropic.md](internals/anthropic.md)). |
 | Logging | `log.rb` (`Log`), `log_subscriber.rb` (`LogSubscriber`), `log_path.rb` (`LogPath`), `log_line.rb` | The debug log: tagged records, a session's event trail, where the file goes ([configuration.md](configuration.md#debug-log-file)). |
 | Stores | `reminder_store.rb` (`ReminderStore`), `recap_store.rb` (`RecapStore`) | A session's reminders, and its idle recap (`recap.json`). |
-| Schedules | `schedules.rb` (`Schedules`, its `Entry`, `Tick`, `Index`), `schedule_command.rb` (`ScheduleCommand`) | Durable schedules that outlive every worker: `<state dir>/schedules.json` and its `schedules.lock`, the tick's busy check (a live worker asked over the Bridge's `GET /activity`, the files when there is none), the chain prune. `chi schedule` is this machine only. See [Scheduling](scheduling.md). |
+| Schedules | `schedules.rb` (`Schedules`, its `Entry`, `Tick`, `Index`), `schedule_command.rb` (`ScheduleCommand`) | Durable schedules that outlive every worker: versioned `<state dir>/schedules.json` and its `schedules.lock`; rewrites preserve unknown keys and entries missing required members. The tick's busy check (a live worker asked over the Bridge's `GET /activity`, the files when there is none), the chain prune. `chi schedule` is this machine only. See [Scheduling](scheduling.md). |
 | Reply waits | `reply_wait.rb` (`ReplyWait`, `GONE_AFTER`: the one dead-worker rule), `reply_wait/poll.rb` (`ReplyWait::Poll`, one look per poll), `reply_wait/target.rb` (`ReplyWait::Target`: which turn a wait binds, cursor, baseline, `owner_grace`; `first_message`, `message`, `wait_only`, `answer`, `participant`, `from_cursor`), `reply_wait/liveness.rb` (`ReplyWait::Liveness`: one owner and link read per look; `#owner?` for gone, `#worker_owned?` for an open question) | `chi send --wait`, `chi answer`, a participant's wait, the delegate tools and delegate reports wait through `ReplyWait.call(id, **target.to_h, …)` ([sub-agent.md](sub-agent.md)). |
 | Session rows | `session_row.rb` (`SessionRow`) | A session as the lists see it: scalar facts only, built by `SessionManager.session_rows` (one owner, link, recap and analytics read each), `#to_summary_h` the summaries route's body and `.from_summary_h` a remote's rows read back, `#cli_line` the one `chi sessions list` line, `.running_or_starting?` the delegates' and Verify fresh's "running" (a 15 s grace for a worker on its way). A leaf: never session_manager or web. |
 | Setup and update | `bootstrap_command.rb`, `bootstrap/`, `update_command.rb`, `gem_update.rb` | `chi bootstrap` (first config.yml, system bundle, core profile) and `chi update` (the gem, shipped bundles, the macOS helper). |

data/docs/cli.md

@@ -36,7 +36,7 @@
 - `chi self` — print version, source dir (checkout or installed gem), config/memory/session paths, model/host and bundles. Run by a session's `execute`, the `model` row (and host, loop, profile, thinking, served model) is **that session's** model, labelled `(this session <id8>; default …)`; elsewhere it is the default, `(default)`. `model key` is the memory overlay key (`<name>.<key>.md`), and `big memories` the memories over `memory.entry_warn_tokens` ([Memory](memory.md#a-memorys-size)), and `model notes` the model notes a prompt of that model loads (`model_notes_deepseek (system, 612 chars)`, `none`; inside a session its `--mute` list is left out). `chi self --model` prints only the model a new session starts on, an alias resolved to its target (the desktop helper's hint)
 - `chi update [--dry-run] [--to VERSION] [--json] [--no-gem] [--no-bundles] [--no-desktop]` — update an installed chi: the gem, the system bundle, the shipped bundles you installed and the desktop helper, and check the bundles from elsewhere, in one table (see [Updating](#updating))
 - `chi home`, `chi home set [--ruby PATH]`, `chi home doctor` — the chi home: the one Ruby (and its gem path) every chi launch boots, whoever launches it. `chi home` shows it (its Ruby, the newest chi in it, gem home and path, `mise`, when and by which chi it was set, and the chi you ran when that is another one; exit 1 with the problem when it can't boot chi), `set` records this chi's Ruby and gem path (or `--ruby PATH`'s own; it must have samagotchi), `doctor` checks it and what should follow it, one row each with `ok`, `warn` or `fail` and what to run (exit 1 on a `fail`; see [Checking it](configuration.md#checking-it-chi-home-doctor)). At a terminal, a chi on another Ruby than the home's says so in one dim line a day. This machine only (see [The chi home](configuration.md#the-chi-home))
-- `chi project`, `chi project init [DIR]` — this folder's project, and making a folder in no git repository one. `chi project` prints how its project was found (`kind` `git`, `marker` or `none`), its `root` (what memories are keyed on), its `top` (where the AGENTS.md chain starts) and its project `memories` folder, with a `note` for a marker a repository makes ignored, or a `$HOME` that is a git repository. `init` writes `DIR/.chi/project.yml` (DIR defaults to this folder and is created when missing), so DIR and every subfolder share one memories folder, group their sessions and take `chi context --project`; it writes nothing in a git repository (the repository already is the project, exit 0), says so for a folder already marked, refuses `$HOME`, a folder above it and `/` (exit 1), and marks a folder inside another marked project as its own, nested one. It prints the root and the memories folder (with the memories already there: a folder chi ran in at its top keeps them), the running sessions in DIR to restart (`chi sessions restart ID`: their prompt keeps the old project) and, when DIR has saved sessions, that a running chi web groups them after its restart. This machine only. See [Projects without git](memory.md#projects-without-git)
+- `chi project`, `chi project init [--new-id] [DIR]` — this folder's project, and making a folder in no git repository one. `chi project` prints how its project was found (`kind` `git`, `marker` or `none`), its `root`, its `top` (where the AGENTS.md chain starts), a marked project's `id` (what its memories and project context are keyed on; else the root's path is) and its project `memories` folder, with a `note` for a marker a repository makes ignored, or a `$HOME` that is a git repository. `init` writes `DIR/.chi/project.yml` with a new `id:` (DIR defaults to this folder and is created when missing), so DIR and every subfolder share one memories folder (kept when DIR moves or is renamed), group their sessions and take `chi context --project`; it writes nothing in a git repository (the repository already is the project, exit 0), says so (with the id) for a folder already marked, refuses `$HOME`, a folder above it and `/` (exit 1), and marks a folder inside another marked project as its own, nested one. On a folder marked without an id (an older chi's marker) it adopts one: the folders keyed by its path move to the id, each leaving a link by its old name, and it says what moved and names memories an earlier path left (refused, exit 1, while a session of the project runs). `--new-id` gives a marked folder a fresh id with a copy of its memories and project context (a copied folder going its own way; refused elsewhere, exit 1). It prints the root, the id and the memories folder (with the memories already there: a folder chi ran in at its top keeps them, moved to the id), the running sessions in DIR to restart (`chi sessions restart ID`: their prompt keeps the old project) and, when DIR has saved sessions, that a running chi web groups them after its restart. This machine only. See [Projects without git](memory.md#projects-without-git)
 - `chi bundle install|upgrade|uninstall|status|diff|list|build|trash|new|test|check` — manage memory bundles (see [Plugins](plugins.md) and [Bundle hooks](hooks.md#bundle-hooks)); `list` shows the installed ones and the ones shipped with chi, which `install <name>` installs; `upgrade <name>` upgrades an installed bundle by name from the source it came from (its folder, archive or git URL), `upgrade <source>` from a new one; `core` and `dev` are profiles that install a set of them (see [Bundle profiles](memory.md#bundle-profiles-core-and-dev),  [Guardrails](guardrails.md), [Bundles](bundles.md#the-btw-bundle), [the mcp bundle](bundles.md#the-mcp-bundle) [the loop-guard bundle](bundles.md#the-loop-guard-bundle), [the check-in bundle](bundles.md#the-check-in-bundle) and [the skills bundle](bundles.md#the-skills-bundle)). `trash` lists and empties the bundle trash (moved files from uninstalls/upgrades). `install`/`upgrade` `--force` overwrites existing entries and also installs a bundle whose `requires_chi` this chi doesn't meet; without it such a bundle is refused (exit 1), nothing written. A plain `install` of a bundle that is already installed from the same source rewrites its rules, plugin, scripts and record: the summary lists a file that already holds the bundle's bytes as `Up to date: …`, one you wrote as `Skipped: …`, and ends with `NAME was already installed from SOURCE: its rules, plugin and scripts now match it and its record was rewritten` (plus, when a memory was kept, `your own copies of its memories were kept (chi bundle upgrade NAME merges the bundle's changes into them)`). A source with class-file hooks (`hooks/*.rb` or a manifest `hooks:` entry) is refused, `--dry-run` too; an older install's hooks are removed by the next install or upgrade (`Removed (chi no longer loads class-file bundle hooks): …`, an edited one copied to the trash first; see [Class-file hooks are retired](hooks.md#class-file-hooks-are-retired)). `status NAME` lists the bundle's guardrail rules and scripts beside its plugin, each `[ok]`, `[missing]` or `[modified]` (edited: the next install replaces it, its copy kept in the trash; an edited rule doesn't load, so it counts in `issues=`), and `diff NAME` names an edited rule or script with its recorded and current sha256 (chi keeps no base text for them). A usage error (an unknown subcommand or flag, a missing argument, a bad `build --scope`) exits 2, as for the other subcommands. Plain `chi` and `chi web` exit 1 on an unknown flag, a flag missing its value or a stray argument. `new`, `test` and `check` are for writing one: see [Writing a bundle](#writing-a-bundle-new-test-check)
 
 - `chi guardrails replay [--dry-run] [--threshold T] [--model M]` — seed System 1's record from the approvals this machine's sessions already answered: each ask is judged by the configured model and written to `guardrails/judgments.jsonl` with the answer the user gave, then a per-rule table prints (asks, allowed, denied, would-be auto-allows, false allows, asks with no judgment). A parent agent's answer is not the user's: only its deny is replayed, and only where the parent could have allowed. `--dry-run` judges without writing, `--threshold` overrides `guardrails.system_one.threshold` for the table, `--model` the configured model for this run. Exit 2 when `guardrails.system_one.mode` is off or no `host` is set; a usage error exits 2 (see [System 1](guardrails.md#system-1-experimental))

data/docs/guardrails.md

@@ -92,10 +92,13 @@ Allowing beyond "once" is stored in `$XDG_STATE_HOME/samagotchi/guardrails/appro
 
 | Scope | Allows |
 |---|---|
-| session | this exact call in this session: the tool + command, or for a file tool its paths, so its label names them (`Allow edits to config.yml for the session`) and a later edit of that file needs no ask |
+| session | this exact call in this session: the tool + command, or for a file tool its paths, so its label names them (`Allow edits to config.yml for the session`) and a later edit of that file needs no ask. A command's holds only where it was given: the same worktree or folder (`repo_root`, never the repository's other checkouts) and the same `env:` (a sha256 of it is stored as `env`, never the values) |
 | repo | this exact call in this repo (the cwd outside a repo), any session |
 | rule | anything this rule asks about in this repo |
 
+A session entry of a command from before chi kept its place (no `repo_root`) no longer matches: the call asks once
+more. `/guardrails` shows a session entry with its folder (`session 3fa2c1d0 in /work/app`, `with its env:`).
+
 "This repo" is the git repository, not the folder: an approval given in one
 worktree holds in the main checkout and every other worktree of it (it is
 stored with the repository's common git dir as `repo`, and the worktree as
@@ -294,6 +297,21 @@ by editing the session file, or by running `chi --attach` on a PTY with the
 markers cleared. chi's instructions for parents ([chi as a
 sub-agent](sub-agent.md)) tell them to use `chi answer` only.
 
+## Who may run a session command
+
+A message that is a session command (`/model x`, `!cmd`, `!rollback`) runs as the command only when a person sends
+it: a web tab, an attached chi TUI, `chi send` (yours, or one a model runs from `execute`: the trust model above), a
+message with no sender named, and `chi answer`'s lines (`cli:answer`: a parent agent's `/continue yes` and
+`/parent-answers`), which may send any session command, with the same trust as `chi send`.
+`!cmd` runs its shell line with no rule or ask (it is yours), so from anyone else it is refused: a delegating parent's
+task or follow-up, a schedule's firing (both modes), a plugin's message, a context or task wake. Chi web's Bridge answers
+`403 command_not_permitted` with one message, an input file's line shows as the command's error, and nothing runs.
+Their `/word` line is plain text: the model reads it. `delegate`, `schedule_task` and `chi schedule add` refuse a task
+or prompt that starts with `!` with the same message, so the model can rewrite it. A participant's command is refused
+as before ([their review boundary](#a-participants-review-boundary)). The rule is `CommandIntake`
+(`lib/samagotchi/command_intake.rb`), asked by `Bridge#handle_post_turn` and `WorkerInbound#queue_as_command`;
+`POST /command` (a UI's or a card's explicit command line) is not a message and is not covered.
+
 ## Protected paths
 
 Built in, for `write`, `edit` and `memory_write` (symlinks resolved; see
@@ -1508,6 +1526,7 @@ the text a rule sees, and a function or alias shadowing a reader in the same
 command isn't seen at all. `outside_repo` covers the file tools and git
 only: `sed -i`, `cp` or `cat > file` into another folder from the shell aren't
 asked about, and neither is git run through `sh -c`, a script, an alias, `make`
-or a folder in a variable. `!cmd` lines typed by you are not checked. The only
+or a folder in a variable. `!cmd` lines typed by you are not checked (see
+[Who may run a session command](#who-may-run-a-session-command)). The only
 real defence against an adversarial model is isolation (a sandbox, a git
 identity without push rights).

data/docs/internals/attached-context.md

@@ -51,8 +51,10 @@ comment is the file map and [../context.md](../context.md#storage) lists it for
   `Candidate`, `Left`, `Moved`/`Stayed`.
 - **Locations.** A `Location` is a folder of sources: a project's (`projects/<project_key>/`, shared by the
   project's workers) or a session's (`sessions/<id>/`, which also holds `subscriptions.json`, the `muted/` and
-  `declined/` markers, `candidates/`, `left.json`). `ContextSources.attached(session_id, project_root:)` is what a
-  session sees: its own, then the project's it doesn't shadow. Names are `NAME_RE`; `subscriptions` and `left` are
+  `declined/` markers, `candidates/`, `left.json`). `ContextSources.attached(session_id, project_root:, project_id:)`
+  is what a session sees: its own, then the project's it doesn't shadow. The project key is
+  `MemoryPaths.key_for(root:, id:)`, the memories folder's key: a marked project's id (`Session#project_id`, saved at
+  creation), else the root's path key; every caller holding a session passes both. Names are `NAME_RE`; `subscriptions` and `left` are
   reserved (`RESERVED_NAMES`) because their files share the folder.
 - **Writes are file replaces** (`AtomicFile`). `Location#locked(name)` takes `<name>.lock`, the lock a fetch holds
   for its whole command; `record_text` and `record_error` run under it, and `remove` leaves the lock file so a fetch

data/docs/internals/bridge.md

@@ -235,6 +235,13 @@ The Bridge exposes:
   sends its requests there (`worker_changed`); it gives up after ~12 s, or at once when the session
   was stopped.
 
+  **Adding an event type.** Assign every emitted type a lifetime in `Events::CLASSIFICATION`
+  (`row`, `state`, `transient` or `internal`); keep stream frames and synthetic replay types in
+  `Events::STREAM_FRAMES` and `Events::SYNTHETIC`. `spec/events_drift_spec.rb` checks event coverage
+  and names the live web/TUI handlers; for rows it also checks the reload owner (`TurnAccumulator`
+  or `CardStore`) and TUI join replay. Follow any documented exception there when a row reloads
+  through session messages or a fallback path instead.
+
   The wire chunk (the contract; the engine's own event keeps the provider's `payload` and the raw `content`):
 
   ```

data/docs/internals/engine.md

@@ -538,7 +538,13 @@ Where a participant's author (`"p:<id>"`; `Steer.participant_author?`) goes (the
 - **`Session#last_turn.author`** and the analytics record's `author` (`SessionMetrics`); a Continue keeps the offer
   turn's author (`ContinueOffer#run_continue_turn`).
 - **Never a command**: a participant's `/word` or `!line` is refused (`Bridge#handle_post_turn` 403,
-  `WorkerInbound#queue_as_command` drops it).
+  `WorkerInbound#queue_as_command` drops it). The same two intakes ask `CommandIntake.allowed?` for every other
+  sender: only a person's (`ClientId.human?`, not `review:`) and `cli:answer`'s line is a command; from a delegate, a
+  schedule, a plugin or a wake a `/word` line is a prompt and a `!` line is refused (the Bridge's 403
+  `command_not_permitted`; an input file's or a first prompt's is queued and `Worker#run_command_line` answers it with
+  the error `command_ran`). A session's first prompt carries its sender too: `WorkerInbound#initial_origin` reads
+  `Session#first_turn_client_id` (a delegate child without it: `ClientId.delegate` of its parent) and `first_turn_id`,
+  for `#initial_command?` and `Worker#run_initial_prompt`.
 - **Delivery**: a participant's input always waits for a turn of its own (`SessionInbox.waits_for_turn_end?`), so
   the drain never merges it; their turns count against chi web's `pending_limit` (429 `too_many_turns`).
   `Worker#run_prompt` checks their link and cap (`participant_refusal`) before the turn and after it.

data/docs/memory.md

@@ -2,10 +2,11 @@
 
 Samagotchi stores memories in two scopes:
 
-- Project scope: `$XDG_CONFIG_HOME/samagotchi/memories/projects/<name>_<hash>/`, one folder per
-  project (named and hashed by its root): a git repository, shared by all its worktrees and
-  subdirectories, or a folder marked by `chi project init` and its subfolders; outside both, one
-  per working directory
+- Project scope: `$XDG_CONFIG_HOME/samagotchi/memories/projects/<key>/`, one folder per project: a
+  git repository, shared by all its worktrees and subdirectories (`<name>_<hash>`, named and hashed
+  by its root), or a folder marked by `chi project init` and its subfolders (its id,
+  `<name>-<8 hex>`: see [Projects without git](#projects-without-git)); outside both, one per
+  working directory (`<name>_<hash>`)
 - System scope: `$XDG_CONFIG_HOME/samagotchi/memories`
 
 `$XDG_CONFIG_HOME` falls back to `~/.config` when unset.
@@ -13,8 +14,9 @@ Samagotchi stores memories in two scopes:
 ## Projects without git
 
 A folder in no git repository becomes a project with `chi project init [DIR]` (see
-[cli.md](cli.md#commands)): it writes `DIR/.chi/project.yml` (one comment line; the file, not a bare
-`.chi/` dir, is the marker), and DIR and every subfolder share one project memories folder, group their
+[cli.md](cli.md#commands)): it writes `DIR/.chi/project.yml` (a comment line and the project's
+`id:`; the file, not a bare `.chi/` dir, is the marker), and DIR and every subfolder share one
+project memories folder, group their
 sessions (`chi sessions list`, the web's project picker) and take `chi context --project`. Nothing
 chi-specific has to be committed anywhere: a repository never needs the file. It can also be created
 from chi web's project picker (a folder inside a git repository opens that repository's project, and
@@ -26,10 +28,34 @@ the folder is left as is: it is created when missing, nothing is marked).
   at `~` puts every folder under home in that repository, so markers there never apply.
 - **Not at home.** A marker in `$HOME`, in a folder above it, or in `/` is ignored (`chi project init`
   refuses them), so a marker in `~` never makes every folder under home one project.
-- **The key.** The marked root is the folder's real path (as git's root is), so a folder chi already ran
-  in at its top keeps its memories after `init`, and a later `git init` in the same folder keeps the same
-  key. Memories saved from a *subfolder* before `init` stay in that subfolder's own folder: move them by
-  hand if you want them in the project's.
+- **The key is the id.** A marked project's memories folder and its project context sources
+  (`chi context --project`) are named by the marker's `id:` (`<folder name>-<8 random hex>`), not
+  by its path, so moving or renaming the folder keeps them: a session started there after the move
+  finds them, and one saved before it (its file stores `project_id`) keys its context sources by the
+  id too. A folder chi already ran in at its top keeps its memories after `init`: they move to the
+  id. A later `git init` in the folder makes it a repository, keyed by its path again (git wins): its
+  memories stay in the id folder until you move them, and chi names the id folder at session start
+  (and under a `memory_read` miss) while the repository's own folder holds no memories. Memories saved from a *subfolder* before
+  `init` stay in that subfolder's own folder: move them by hand if you want them in the project's.
+  A hand-edited id must be letters, digits, `_`, `.` or `-` (up to 64, a letter or digit first);
+  anything else (or a broken file) is ignored and the project keyed by its path (a debug log line
+  says why, `chi project init` reports it).
+- **Older markers adopt an id** when you rerun `chi project init` in the folder: the folders keyed
+  by its path (memories, project context sources, the skills bundle's kept versions) move to the id,
+  each leaving a link by its old name (an older chi, keying by path, finds the same folder), then the
+  id is written. It refuses while a session of the project runs (stop it first, so nothing writes to
+  the old folder mid-move), and names memories an earlier path left (the same folder name with
+  another hash: a folder moved before it had an id), merging nothing. A link stays behind: a new
+  folder (or git repository) made later at the old path reaches the moved project's memories
+  through it; delete the link to stop that. chi web's project picker marks a new folder with an id
+  but never moves folders: a folder it marks that already has path-keyed memories gets no id until
+  `chi project init`.
+- **A copy shares memories.** A copied marked folder (`cp -R`) keeps the id, so the two share one
+  memories folder; at session start in the copy chi says so (a `memory>` load warning: "… share chi
+  project id … (a copied folder?)"; the id folder's `.root` names the folder that started a session
+  with it last, the original keeps it). `chi project init --new-id` in the copy gives it a fresh id,
+  with a copy of the memories and project context sources it had: each folder goes its own way.
+  After a move, the new path just takes `.root` over, with no warning.
 - **Restart what runs there.** A session running in the folder when it is marked keeps the old memories
   folder and AGENTS.md chain in its prompt until `chi sessions restart ID` (init names them); a running
   `chi web` groups the folder's older sessions under the project after its restart.
@@ -52,13 +78,15 @@ Tool behavior:
 
 ## Moving memories to another machine
 
-A project's folder is keyed by its root's absolute path (`<basename>_<8 hex of MD5(root)>`), so project
+A repository's folder is keyed by its root's absolute path (`<basename>_<8 hex of MD5(root)>`), so project
 memories copied to a machine (or a path) where the repository lives elsewhere sit in a folder chi no
 longer reads. Rename the folder to the new key, or move memories with a bundle zip (see
-[What a bundle owns](#what-a-bundle-owns)).
+[What a bundle owns](#what-a-bundle-owns)). A marked project with an id needs neither: copy its id
+folder along with the marked folder.
 
 Inside a project (a git repository or a marked folder), when this project's folder is missing or holds no `*.md` while the projects
-dir has a folder of the same basename with another hash, chi says so, naming both folders and the
+dir has a folder of the same basename with another hash (`<basename>_<hash>`, or a marked project's id folder
+`<basename>-<8 hex>`; links, an adopted project's old names, are skipped), chi says so, naming both folders and the
 `mv` that fixes it (a name match can't prove it's the same project, so nothing is renamed for you):
 
 - at session start, a `memory>` load warning (a `:guardrail_warning` with label `memory`; the attached

data/docs/scheduling.md

@@ -8,6 +8,11 @@ chi web's hub can never lose an update to each other). A **tick** — cron, syst
 launchd, `chi schedule tick`, or chi web's hub when `schedule.auto_tick` is on —
 walks the entries whose `next_due` has passed and runs the ones that are not busy.
 
+The file is versioned: each entry member is required or declares the format
+version and default that introduced it. Rewrites preserve unknown keys and
+entries missing required members; those entries are warned about and ignored by
+`list` and `tick`, never erased. A write never lowers the file's version.
+
 Each entry carries `id`, an optional `title`, `anchor` (the session it was made
 against, never rewritten: the chain's root and the id you remember), `head` (the
 chain's current link, re-anchored after every firing: the link a chain continue
@@ -30,9 +35,17 @@ depends on whether the worker has to be running.
 | Longest interval | 1440 minutes | unlimited (`every`, `weekday`, `date`) |
 | What it produces | a turn in the same session | a new chain link, or a queued turn in the same session |
 
-A schedule turn carries `client_id: "system:schedule:<id>"`, so `ClientId.origin`
-says `schedule` and the terminal and the web label it as such rather than as
-something you typed. Like `register_reminder`, the schedule tools are owner-voiced:
+A schedule turn carries `client_id: "system:schedule:<id>"` in both modes (a chain
+link's first turn through `Session#first_turn_client_id`, which `Schedules#fire_chain`
+passes to `SessionContinue.run`), so `ClientId.origin` says `schedule` and the terminal
+and the web label it as such rather than as something you typed. For the same reason a
+schedule's prompt is never a session command: a `/word` prompt reaches the model as
+text, and one that starts with `!` is refused by `chi schedule add` and `schedule_task`
+([guardrails.md, Who may run a session command](guardrails.md#who-may-run-a-session-command)).
+An entry stored with one before that fails when it fires (toward its `max_failures`),
+before anything is started or delivered. A chi web
+(or cron tick) still running an older chi starts chain links without the origin, so
+restart it after updating. Like `register_reminder`, the schedule tools are owner-voiced:
 a participant's review or pair turn is denied them ([guardrails.md](guardrails.md)).
 
 ## The two modes

data/docs/sessions.md

@@ -115,7 +115,7 @@ chi sessions clean --dry-run --days 7            # test sessions older than 7 da
 
 ## Session file
 
-`Session::FIELDS` is the table of `<uuid>.json`, in the order `Session#save` writes it (`Session.new`, `.from_h` and `#to_h` all go by it; 41 keys). Each key is one `SessionField` row (`session_field.rb`): its default for a file without it, how a value is cast when read and what the file gets, the codec being its type's own (`Toolkit.from_file`, `SessionReview.of`, `PromptNote.list`, `#to_file`…); the typed fields' writers cast through their row, and `#to_h` reads each field's instance variable, not its reader. A key a file lacks reads as the default below, a key present as `null` as `null` (then cast: `test_run` false, `toolkit_origin` chosen); `review`, `first_turn_id`, `verdicts` and `verify_fresh` are written only when set (`OPTIONAL_FIELDS`). A key this chi doesn't know is kept and written back as it was (see the rule above). `thinking`, `reasoning_history` and `llm_context` follow one Unread rule (`SessionField.level`): a value this chi can't read (a newer chi's level, a hand edit) reads as none and is kept and written back as it was, until the session sets its own; `llm_context` keeps the parts it can't read under the ones it can. So does `toolkit_origin`: an unknown one (a String) reads as `chosen` and is written back as it was, until the session sets its own. Where the file and the session's dir are, and which ids name a session, is `SessionPaths` (`session_paths.rb`, a leaf that `Session` extends: `Session.session_dir` is `SessionPaths.session_dir`). The bytes a save writes for each field and on each path that makes or rewrites a file are pinned in `spec/session_file_goldens_spec.rb`, with what a fork, a continue, a delegate child and a respawn keep of their source (`carry_matrix.json`). "Who writes it": the Engine runs in the session's worker (or a `--non-interactive` run); the rest are named.
+`Session::FIELDS` is the table of `<uuid>.json`, in the order `Session#save` writes it (`Session.new`, `.from_h` and `#to_h` all go by it; 43 keys). Each key is one `SessionField` row (`session_field.rb`): its default for a file without it, how a value is cast when read and what the file gets, the codec being its type's own (`Toolkit.from_file`, `SessionReview.of`, `PromptNote.list`, `#to_file`…); the typed fields' writers cast through their row, and `#to_h` reads each field's instance variable, not its reader. A key a file lacks reads as the default below, a key present as `null` as `null` (then cast: `test_run` false, `toolkit_origin` chosen); `review`, `first_turn_id`, `first_turn_client_id`, `verdicts` and `verify_fresh` are written only when set (`OPTIONAL_FIELDS`). A key this chi doesn't know is kept and written back as it was (see the rule above). `thinking`, `reasoning_history` and `llm_context` follow one Unread rule (`SessionField.level`): a value this chi can't read (a newer chi's level, a hand edit) reads as none and is kept and written back as it was, until the session sets its own; `llm_context` keeps the parts it can't read under the ones it can. So does `toolkit_origin`: an unknown one (a String) reads as `chosen` and is written back as it was, until the session sets its own. Where the file and the session's dir are, and which ids name a session, is `SessionPaths` (`session_paths.rb`, a leaf that `Session` extends: `Session.session_dir` is `SessionPaths.session_dir`). The bytes a save writes for each field and on each path that makes or rewrites a file are pinned in `spec/session_file_goldens_spec.rb`, with what a fork, a continue, a delegate child and a respawn keep of their source (`carry_matrix.json`). "Who writes it": the Engine runs in the session's worker (or a `--non-interactive` run); the rest are named.
 
 | Key | Meaning | Written by |
 |-----|---------|------------|
@@ -136,6 +136,7 @@ chi sessions clean --dry-run --days 7            # test sessions older than 7 da
 | `pending_question` | The question the worker waits on (`PendingQuestion`), `null` with none. | `QuestionDesk` |
 | `used_memory_names` | The memories the session read. | the Engine |
 | `project_root` | The project the session started in, stored because a worktree may be deleted later; `null` outside a repository or a marked folder (looked up again on read). | creation |
+| `project_id` | A marked project's id (its `.chi/project.yml`'s `id:`), saved beside `project_root`: the session's project context sources are keyed by it, so they follow a moved folder. Absent for any other project. | creation |
 | `preloaded_memory_names`, `muted_memory_names` | `--memory` and `--mute`, written before the worker starts so a respawn builds the same prompt. | creation |
 | `prompt_notes` | The model notes the system prompt carried at its last build (`[{name, scope, chars, digest}]`, see [Memory](memory.md#model-notes)). | the Engine, at each prompt build |
 | `parent_id` | The session that delegated this one or forked it (`ctx.sessions.fork`); `null` otherwise. See [Delegating](#delegating). | `SessionManager.spawn_session`; `ChildMove` writes a `parent.json` beside it instead of this file |
@@ -156,6 +157,7 @@ chi sessions clean --dry-run --days 7            # test sessions older than 7 da
 | `working_set_pins` | The working-set items the user pinned (`/working-set pin`); kept by a respawn, a continue and a fork. | the Engine's command |
 | `review` | A review session's subjects and source (`SessionReview`), see [Review sessions](#review-sessions). | `ReviewStart` |
 | `first_turn_id` | The id the creating prompt's turn gets, so a wait can name it (`chi send --new --wait`, `--wait --turn T ID`); `null` for a session created idle. | `SessionManager.spawn_session` |
+| `first_turn_client_id` | Who sent the creating prompt when no person did (`delegate:<parent8>` for a delegate's task, `system:schedule:<id>` for a chain schedule's link): that first turn's origin, so its line is no command of the owner's (docs/guardrails.md, Who may run a session command) and `last_turn` names the sender. Written only when set; not carried by a fork, a continue or a delegate. An older chi keeps it but runs the first prompt as a person's. | `SessionManager.spawn_session` (its `client_id:`) |
 | `verify_fresh` | A Verify fresh child's requester, rules and claim (`VerifyFreshOrigin`). | `VerifyFresh.start`, once |
 
 ## Context notes

data/lib/samagotchi/bridge.rb

@@ -9,6 +9,7 @@ require "openssl"
 require "time"
 require_relative "atomic_file"
 require_relative "bridge_secret"
+require_relative "command_intake"
 require_relative "degrade"
 require_relative "delivery"
 require_relative "session_inbox"
@@ -1195,9 +1196,17 @@ module Samagotchi
       # A session command sent as a message (chi send -m "/model x", chi -p,
       # a UI whose command list lags) runs as the command, as typed in a
       # TUI; an unknown /word stays a prompt. Not with images: those are
-      # for the model.
+      # for the model. Only from a sender that may send commands
+      # (CommandIntake.allowed?: a person, chi answer): a delegate's, a
+      # schedule's or a plugin's /word line is a prompt, its shell line
+      # refused (403, nothing queued).
       if images.empty? && @on_command && command_registry.command?(prompt.to_s)
-        return queue_command_request(sid, prompt.to_s.strip, client_id: client_id, deadline: deadline, author: author)
+        if CommandIntake.allowed?(client_id)
+          return queue_command_request(sid, prompt.to_s.strip, client_id: client_id, deadline: deadline, author: author)
+        elsif CommandIntake.shell_line?(prompt)
+          Log.warn(:bridge, "shell_line_refused", client_id: client_id)
+          return [{}, 403, { error: CommandIntake::REFUSED_ERROR, detail: CommandIntake::REFUSED }]
+        end
       end
 
       enqueued_id = SecureRandom.uuid

data/lib/samagotchi/broadcast/scope_card.rb

@@ -46,7 +46,8 @@ module Samagotchi
         session = Session.load(recipient.id, state_dir: state_dir)
         prompts = user_texts(session.messages)
         branch = GitHead.branch(session.working_directory)
-        sources = ContextSources.attached(session.id, project_root: session.project_root, state_dir: state_dir)
+        sources = ContextSources.attached(session.id, project_root: session.project_root, project_id: session.project_id,
+                                                      state_dir: state_dir)
                                 .map { |attached| [attached.name, attached.source.hint] }
         ScopeCard.new(id: session.id, project: recipient.project && File.basename(recipient.project),
                       folder: folder(session.working_directory, recipient.project), branch: branch,

data/lib/samagotchi/bundle_command.rb

@@ -266,6 +266,7 @@ module Samagotchi
     # @return [Array(MemoryBundle::PreparedSource, String), nil]
     def prepare_or_fail(expanded_source, word)
       prepared = Samagotchi::MemoryBundle::PreparedSource.prepare(expanded_source)
+      Samagotchi::MemoryBundle::Manifest::HooksRetired.refuse_source_files(prepared.dir)
       named = [prepared, Samagotchi::MemoryBundle::Manifest.read(dir: prepared.dir).name]
     rescue Samagotchi::MemoryBundle::SourceNormalizer::UnknownSourceError,
            Samagotchi::MemoryBundle::Manifest::ValidationError => e

data/lib/samagotchi/bundles/system/manifest.yml

@@ -1,11 +1,11 @@
 ---
 name: samagotchi-system
-version: 0.159.0
+version: 0.160.0
 scope: system
 description: Default system memories — identity, self map, config modification protocol, memory guide and the delegated-session rules
 files:
   identity.md: sha256:29c2f7df9f6c5acbc5ec17000a4490741e55e426af15ca0d81c8706edd9bd027
   self_map.md: sha256:750822b3488b302c6e32638e6224f270d8e06b50ea85cd6e0bb5a6ff12eed1d8
   config_modification_protocol.md: sha256:44cf7bdac8e526805bff36b76b54fefecd41db30ca525c2ed661d78fe9155dd8
-  memory_guide.md: sha256:91e8fd248a155afad6b825097d9ee0a0215ba0b79092c8ab25501c0fc19dedfc
+  memory_guide.md: sha256:bdd34f34063df1b4ae74f7cda7c31080986d155e535ee4526d673c70edac8292
   delegated.md: sha256:a0d6ddcd4a8be06526d964898611775fd251cfd9d145a9d16afaccaa503597bd

data/lib/samagotchi/bundles/system/memory_guide.md

@@ -13,7 +13,7 @@ This memory teaches you (the agent) how to use Samagotchi memories — persisten
 | Scope | Path | Use for |
 |-------|------|---------|
 | `system` | `$XDG_CONFIG_HOME/samagotchi/memories/`, default `~/.config/samagotchi/memories/` (`MemoryPaths.system_dir`) | User-wide preferences, identity, cross-project knowledge |
-| `project` | `<system dir>/projects/<basename>_<hash>/` (`MemoryPaths.project_dir`: `basename(root)` + 8-char `MD5(root)`, root = `MemoryPaths.project_root`) | Repo-specific conventions, workflow, stack decisions |
+| `project` | `<system dir>/projects/<key>/` (`MemoryPaths.project_dir`: a git project's `<basename>_<hash>`, `basename(root)` + 8-char `MD5(root)`, root = `MemoryPaths.project_root`; a marked project's id from its `.chi/project.yml`, `<basename>-<8 hex>`, kept when the folder moves) | Repo-specific conventions, workflow, stack decisions |
 
 - The project root is the git repository: its common git dir, which every linked worktree shares. All worktrees and subdirectories of one repository share one project folder; the system prompt shows that folder (not the root: in a linked worktree, work stays in the worktree). A separate clone is a different project. Outside a repository, a folder marked by `chi project init` (its `.chi/project.yml`) is the project for it and every subfolder; outside both, the root is the working directory.
 - `index.md` lives in each scope dir and contains auto-managed lines like `- **name** · scope · date · bytes — description`; a memory a bundle installed adds `· from <bundle>` before the description. Your free-form sections in `index.md` are preserved but managed lines are owned by `memory_write` (and refreshed when `write`/`edit` change a memory's file).
@@ -122,7 +122,7 @@ Bundles are versioned directories/zips/tar.gz/git URLs with a `manifest.yml` and
 | `build [--scope system\|project] [--name NAME] [--version VER] [--description DESC] [--out PATH] [FILES...]` | **Inverse of install** — builds a shareable bundle from local memories and an installed bundle's plugin, rules and scripts. Infers `zip` vs `dir`/`tar.gz` from `--out` extension; default `chi_system_memories.zip` (system) or `chi_<repo>_memories.zip` (project, named after the project root) v`1.0.0` in `Dir.pwd`. `FILES...` is an optional allowlist of memory basenames (`identity` or `identity.md`); if omitted, all `*.md` except `index.md`/hidden/non-md and the memories other installed bundles own (each named in a `Left out` line) are included. Computes `sha256:` checksums and writes `manifest.yml` via `Manifest.write`. No provenance write. |
 
 **Scope resolution for install/build:**
-- CLI `--scope` wins over `manifest.yml` `scope`. Default is `system` if none given (`Installer#run`). For `project`, target is the project folder `<system dir>/projects/<basename>_<hash>` of the project root (`MemoryPaths.scope_dir`).
+- CLI `--scope` wins over `manifest.yml` `scope`. Default is `system` if none given (`Installer#run`). For `project`, target is the project folder `<system dir>/projects/<key>` of the project (`MemoryPaths.scope_dir`).
 
 **Example flows:**
 ```bash

data/lib/samagotchi/client_id.rb

@@ -98,6 +98,10 @@ module Samagotchi
     # Whether +client_id+ is a participant's (review:).
     def review?(client_id) = client_id.to_s.start_with?(REVIEW_PREFIX)
 
+    # The client id a delegating parent's task and follow-ups carry:
+    # delegate:<parent8>.
+    def delegate(parent_id) = "#{DELEGATE_PREFIX}#{parent_id.to_s[0, 8]}"
+
     # The client id a durable schedule's turn carries: system:schedule:<id>.
     def schedule(schedule_id) = "#{SCHEDULE_PREFIX}#{schedule_id}"
 

data/lib/samagotchi/command_intake.rb

@@ -0,0 +1,56 @@
+# frozen_string_literal: true
+
+require_relative "client_id"
+
+module Samagotchi
+  # Who may send a session command as a message (a turn's text: chi send -m
+  # "/model x", a web page's first message, an input file, a session's
+  # first prompt), and what a line from anyone else is. The one rule the
+  # two intakes ask (WorkerInbound#queue_as_command, Bridge#handle_post_turn)
+  # and the senders that refuse up front (Tools::Delegate, Schedules#add).
+  # No Engine needed: a schedule's tick and the CLI have none.
+  #
+  # From a sender that may not, a /word line is plain prompt text (the
+  # model reads it) and a ! line (a shell command: SessionCommands#shell
+  # runs it with no Gate) is refused with REFUSED, never run.
+  module CommandIntake
+    # A shell line's prefix: !<cmd>, and !rollback (SessionCommands::
+    # SHELL_BANG_PREFIX, which a spec keeps the same: SessionCommands is too
+    # big a load for the bundle test kit's budget).
+    SHELL_PREFIX = "!"
+
+    # The one text a refused shell line gets: the Bridge's 403 detail, the
+    # worker's command_ran error, a delegate's or a schedule's refusal.
+    REFUSED = "a message that starts with ! is a shell command, which only a person runs as a message " \
+              "(a web tab, a chi TUI, chi send); from a delegate, a schedule or another automatic sender it is not run. " \
+              "Say what to run in words instead (\"run `ls`\"), or leave out the leading !"
+
+    # The Bridge's error code for it (403).
+    REFUSED_ERROR = "command_not_permitted"
+
+    # chi answer's marker (a parent agent's /continue yes and
+    # /parent-answers; Worker#as_parent? holds those to its own rules): any
+    # command, with chi send's trust.
+    ALLOWED_IDS = [ClientId::CLI_ANSWER].freeze
+
+    module_function
+
+    # Whether a message from +client_id+ may run as a session command: a
+    # human's input (ClientId.human?: a web tab, a chi TUI, chi send, no
+    # client) but a participant's (review:, refused on its own), and chi
+    # answer's. A delegate, a child's report, a context or task wake, a
+    # schedule, a reminder, a relay and a plugin may not (the bundles that
+    # send, coordinator and skills, send prose).
+    def allowed?(client_id)
+      ALLOWED_IDS.include?(client_id.to_s) || (ClientId.human?(client_id) && !ClientId.review?(client_id))
+    end
+
+    # Whether +text+ would be a shell line (!<cmd>, !rollback) if a command:
+    # what a delegate's task or a schedule's prompt may not start with.
+    def shell_line?(text) = text.to_s.lstrip.start_with?(SHELL_PREFIX)
+
+    # Whether the command line +line+ from +client_id+ is a shell line that
+    # must not run.
+    def refused?(line, client_id) = shell_line?(line) && !allowed?(client_id)
+  end
+end

data/lib/samagotchi/context_absorber.rb

@@ -59,17 +59,19 @@ module Samagotchi
     VERDICT = /\bVERDICT:?\s*([A-Z]+)(?![A-Za-z|])/
 
     # @param project_root [String, nil] Session#project_root
+    # @param project_id [String, nil] Session#project_id
     # @param peer_sources [PeerSources, nil] the peer bundles' declared sources
     # @param peer_turns [#call, nil] the peer wake turns in a row
     #   (WorkerWakes#peer_turns); 0 or nil: no source is a peer's
-    def initialize(session_id:, state_dir:, project_root:, peer_sources: nil, peer_turns: nil)
+    def initialize(session_id:, state_dir:, project_root:, project_id: nil, peer_sources: nil, peer_turns: nil)
       @session_id = session_id
       @peer_sources = peer_sources
       @peer_turns = peer_turns
       @state_dir = state_dir
       @own = ContextSources.session_location(session_id, state_dir: state_dir)
-      @project = ContextSources.project_location_for(project_root, state_dir: state_dir)
+      @project = ContextSources.project_location_for(project_root, project_id: project_id, state_dir: state_dir)
       @project_root = project_root
+      @project_id = project_id
       @signature = nil
     end
 
@@ -79,7 +81,8 @@ module Samagotchi
       return nil if signature == @signature
 
       subs = @own.subscriptions
-      visible = ContextSources.attached(@session_id, project_root: @project_root, state_dir: @state_dir)
+      visible = ContextSources.attached(@session_id, project_root: @project_root, project_id: @project_id,
+                                                  state_dir: @state_dir)
       deliveries = visible.filter_map do |attached|
         next if @own.muted?(attached.name)