@zenera/cli 1.1.24 → 1.1.26

package/templates/editor/.github/skills/zen-memory/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: zen-memory
-description: How agent memory is organised and how to configure it in `agents.yaml` - the `memory:` block, per-agent `access`/`sees`/`writes`/`autoRecall`, the five `memory_*` tools, kinds and relations, how recall ranks and stitches a subgraph, when an agent should reach for `memory_grep` instead of `memory_search`, how to inspect a graph with `zen memory search`/`grep`/`export`, and how to design a memory strategy for a project. Includes the default usage rules every memory-enabled project must carry in `agents/memory-instructions.md` (references/memory-instructions.md), the script that says whether that copy is still current (scripts/check-instructions.sh), where a project's own customisations go instead (`agents/memory-policy-instructions.md`, under `requires: [memory]`), what to commit and what never to, how to keep a working file under `/memory` and re-run it later, and how to put memory in front of a `zen rag schema` or `zen rag docs` index so a search that already succeeded once is not paid for again.
+description: Agent memory in Zenera projects - the `memory:` block and per-agent `access`/`sees`/`writes`/`autoRecall`, the five `memory_*` tools (when to use `memory_grep` instead of `memory_search`), kinds, relations and how recall ranks, inspecting a graph with `zen memory`, designing a memory strategy, `agents/memory-instructions.md` vs `agents/memory-policy-instructions.md`, remembering files under `/memory`, and putting memory in front of a `zen rag` index.
 ---
 
 # Memory
@@ -142,8 +142,8 @@ node. It is house rules under `requires: [memory]`, so it reaches exactly the
 agents that have the store and no others, and it gates its own advice on the
 tools the reader actually holds. The runtime adds the preference block and
 nothing else. Do not restate any of it in a prompt; state project-specific
-policy instead, and keep the copy byte-identical to the reference so
-`check-instructions.sh` stays meaningful.
+policy instead, and leave the file exactly as `zen` wrote it - `zen check`
+reports any byte that differs as `rules.stale`.
 
 ## How it is organised
 
@@ -556,38 +556,20 @@ gets whether it loads the skill or not.
 
 ## The house rules
 
-**Every project that enables memory carries `references/memory-instructions.md`
-in its own `agents/memory-instructions.md`**, as part of turning memory on. That
-file is how the agent is told to use the store: read and search it only through
-the tools, never through `/memory` itself, and what a node must carry to still be
-worth having.
+**Every project that enables memory carries `agents/memory-instructions.md`**,
+as shipped by `zen`. That file is how the agent is told to use the store: read
+and search it only through the tools, never through `/memory` itself, and what a
+node must carry to still be worth having.
 
 `zen init` writes it, because the projects it scaffolds have memory on from the
-first run. Two cases are left to check by hand: a project that turned memory on
-afterwards, and one whose copy has drifted from the reference or was deleted.
+first run. `zen check` covers the two cases left over:
 
-Neither is checked by eye. The skill ships the check, and it is one command:
+- `memory.uninstructed` - memory is on and the file is missing or empty.
+- `rules.stale` - any byte differs from what this `zen` ships. The usual drift
+  is trailing whitespace inside a table, invisible on screen.
 
-```sh
-.github/skills/zen-memory/scripts/check-instructions.sh        # the verdict
-.github/skills/zen-memory/scripts/check-instructions.sh diff   # every differing line
-.github/skills/zen-memory/scripts/check-instructions.sh fix    # copy the reference over
-```
-
-It says whether this project turns memory on at all, exits non-zero on a copy
-that is missing or stale, and prints the `cp` that repairs it. When the only
-difference is trailing whitespace it says so - that is the usual drift, it is
-invisible on screen, and it is the reason reading the two files side by side
-never caught it.
-
-It is a copy, not a transcription - this reference already sits in the project,
-because `zen init` and `zen open` write the whole `.github/` tree, and they write
-it from the same file the project's copy came from. What `fix` runs, from the
-project root, is exactly:
-
-```sh
-cp .github/skills/zen-memory/references/memory-instructions.md agents/memory-instructions.md
-```
+`zen check --fix` repairs both, writing the file from the version of `zen` in
+hand. Never write or patch it by hand.
 
 Everything the project keeps under `agents/` named `<topic>-instructions.md` is
 prepended to every agent, in filename order, so this belongs in its own document
@@ -598,19 +580,55 @@ memory and it leaves with it.
 
 | File                                   | Is                                                                 | Owned by    |
 | -------------------------------------- | ------------------------------------------------------------------ | ----------- |
-| `agents/memory-instructions.md`        | the DEFAULT rules - how the store works, and how any agent uses it | this skill  |
+| `agents/memory-instructions.md`        | the DEFAULT rules - how the store works, and how any agent uses it | `zen`       |
 | `agents/memory-policy-instructions.md` | this PROJECT's customisations on top of them                       | the project |
 
-**Keep the first a pure copy.** It is predefined: it describes this version of
-the runtime, not this project, and `check-instructions.sh` compares it byte for
-byte. Anything edited into it is lost the next time the reference changes.
+### Keep project policy additive
+
+`agents/memory-policy-instructions.md` is not a second memory manual and is not
+the default destination for every memory finding. A rule belongs there only
+when it changes how **every memory-enabled agent in this project** uses memory
+and the default rules do not already say it.
+
+| The rule is about                                                   | Owner                                                   |
+| ------------------------------------------------------------------- | ------------------------------------------------------- |
+| How the memory tools and graph work in every Zenera project         | the upstream default; never repeat it in project policy |
+| A project-wide restriction or obligation for every memory agent     | `agents/memory-policy-instructions.md`                  |
+| One agent's job, finish condition, recall timing or commit behavior | that agent's prompt                                     |
+| One workflow, index, API or body of domain knowledge                | the skill that teaches that workflow or knowledge       |
+| One observed case with no repeated pattern yet                      | the tuning findings, not an instruction                 |
+
+Before adding or changing a project memory rule:
+
+1. Write the intended obligation in one sentence without naming a file.
+2. Choose its owner from the table above and name the agents that must receive
+   it. If that set is smaller than every memory-enabled agent, policy is the
+   wrong owner.
+3. Search the default memory rules, every project policy file, the affected
+   prompts and the affected skills for the obligation. Search distinctive
+   verbs and nouns plus obvious alternate wording; an exact-text search alone
+   does not find semantic duplicates.
+4. Record one disposition: `edit existing`, `move and delete`, `delete
+  contradiction`, or `add because absent`. An addition without this record is
+   not ready to apply.
+5. Make one source authoritative in the same change. Remove weaker copies and
+   rewrite a conflicting rule as one complete rule; never preserve the old rule
+   and append an exception beneath it.
+
+The narrowest source that reliably reaches every intended agent owns the rule.
+Several cases supporting one pattern do not make that pattern global; scope is
+decided by who must obey it, not by how often it failed.
+
+**Keep the first untouched.** It is predefined: it describes this version of
+the runtime, not this project, and `zen check` compares it byte for byte.
+Anything edited into it is lost the next time `zen check --fix` runs.
 
 Everything a project decides for itself goes in the second - audiences, what
 must never be written down, what an agent commits at the end of a job, which
 index a recalled route is checked against. Filename order puts it directly
 after the defaults, so it reads as the exceptions to them. Then keeping up with
-a changed reference is the same one command again, rather than a hand-patch
-around prose that has to be preserved.
+a newer `zen` is `zen check --fix` again, rather than a hand-patch around prose
+that has to be preserved.
 
 **It must open with the same frontmatter**, or it is prepended to every agent in
 the project, including the ones with no store to apply it to:
@@ -648,20 +666,24 @@ ranker, the same walk, the same block a model would have been given, scores and
 all. It is the only one that embeds, and the only one that can distinguish a
 memory that is missing from a memory that is merely ranked sixth.
 
-| Question                                 | Command                              |
-| ---------------------------------------- | ------------------------------------ |
-| Is memory even on, and is it embedded?   | `zen memory stats`                   |
-| What has this project learned?           | `zen memory export --open`           |
-| Is this host/flag/path in there at all?  | `zen memory grep <pattern>`          |
-| Everywhere a thing is mentioned          | `zen memory grep <pattern> --all`    |
-| What would an agent recall for this?     | `zen memory search <query>`          |
-| Why did it _not_ recall that?            | `zen memory search <q> --audience a` |
-| What is in one private slice?            | `zen memory ls --audience audit`     |
-| What has been corrected?                 | `zen memory ls --stale`              |
-| What files are being kept?               | `zen memory ls --files`              |
-| One node in full, with what it links to  | `zen memory show <id>`               |
-| Fold parallel warmup graphs into one     | `zen memory merge <dir...>`          |
-| That should never have been written down | `zen memory forget <id>`             |
+| Question                                 | Command                               |
+| ---------------------------------------- | ------------------------------------- |
+| Is memory even on, and is it embedded?   | `zen memory stats`                    |
+| What has this project learned?           | `zen memory export --open`            |
+| Is this host/flag/path in there at all?  | `zen memory grep <pattern>`           |
+| Everywhere a thing is mentioned          | `zen memory grep <pattern> --all`     |
+| What would an agent recall for this?     | `zen memory search <query>`           |
+| Why did it _not_ recall that?            | `zen memory search <q> --audience a`  |
+| What is in one private slice?            | `zen memory ls --audience audit`      |
+| What has been corrected?                 | `zen memory ls --stale`               |
+| What files are being kept?               | `zen memory ls --files`               |
+| One node in full, with what it links to  | `zen memory show <id>`                |
+| What did a run add to its copy, or read? | `zen memory diff <base> --dir <copy>` |
+| Fold parallel warmup graphs into one     | `zen memory merge <dir...>`           |
+| That should never have been written down | `zen memory forget <id>`              |
+
+Never read a memory's `graph.json` or `manifest.json` with code: every question
+above has a command, and `--json` on any of them is the stable shape.
 
 The directory is not fixed. `zen run --memory <dir>` sends one run's memory
 somewhere else - a scratch graph for a trial, one per branch, or a shared one
@@ -716,10 +738,17 @@ agents:
 
 ## Review checklist
 
-- [ ] `.github/skills/zen-memory/scripts/check-instructions.sh` exits zero, so
-      `agents/memory-instructions.md` is the reference byte for byte - and
+- [ ] `zen check` reports neither `memory.uninstructed` nor `rules.stale`, so
+      `agents/memory-instructions.md` is what `zen` ships byte for byte - and
       project policy lives in `agents/memory-policy-instructions.md`, opening
       with `requires: [memory]`.
+- [ ] Every project memory-policy rule applies to every memory-enabled agent;
+      role-specific rules are in prompts and workflow-specific rules are in
+      skills.
+- [ ] For every added or changed policy rule, the review records its one-sentence
+      obligation, owner, semantic searches, existing locations and disposition.
+- [ ] No project policy rule restates a default memory rule, and no equivalent
+      or softer copy remains in another loaded prompt, skill or policy file.
 - [ ] `memory.embedding` is set, and was set before the graph had content.
 - [ ] Every agent that should learn has a `memory:` binding - the top-level
       block alone enables nothing.

package/templates/editor/.github/skills/zen-rag-docs/SKILL.md

@@ -387,6 +387,7 @@ outline and the copies on disk.
 zen rag docs list <files|sections|tables> [-d <dir>] [filters…]
 zen rag docs grep <pattern> [-d <dir>] [filters…]
 zen rag docs show <file> [--section <name>] [--lines <from-to>]
+zen rag docs show <target>... [--max-lines <n>]
 zen rag docs stats
 ```
 
@@ -411,6 +412,7 @@ zen rag docs grep "Retry-After"               # every matching line, and its sec
 zen rag docs grep "X-RateLimit-\w+" --regex --file "api/**"
 zen rag docs show api/routing.md --section "Rate limits"
 zen rag docs show api/routing.md --lines 40-80
+zen rag docs show "api/routing.md:24-31" "api/errors.md#Retries"   # several, one call
 zen rag docs stats
 ```
 
@@ -431,6 +433,14 @@ the whole point of it.
 line-number gutter (`--no-numbers` to drop it). It is the natural follow-up to
 every search: find the passage, then read what is actually around it.
 
+**Read every passage you will cite in one `show`.** It takes any number of
+targets written the way a citation is - `<document>:<a>-<b>`, `<document>:<a>`,
+`<document>#<heading>`, or a bare name - and prints each under a header that is
+itself a target, in the order given. Overlapping ranges print once; a missing
+document or heading is reported in place while the rest still print. The
+`--max-lines` budget (default 400) is shared fairly, and a cut block ends with
+the target that continues it. One call per passage costs a whole turn each.
+
 `stats` says what is in an index and what built it - the documents, the counts,
 the embedding model. It is the fastest way to answer "is this index the one I
 think it is?".
@@ -443,6 +453,7 @@ think it is?".
 | _anything you would have run `grep` for_          | `grep` / `list` - never the shell               |
 | "does `X-Request-Id` appear anywhere?"            | `grep X-Request-Id`                             |
 | "what does the rate-limits section actually say?" | `show <file> --section "Rate limits"`           |
+| "read the four passages the search turned up"     | `show <doc>:<a>-<b> <doc>:<a>-<b> ...` - once   |
 | "which documents are even in here?"               | `list files`                                    |
 | "what is the shape of this manual?"               | `list sections --depth 2`                       |
 | "where is the table of per-route limits?"         | `list tables --file "api/**"`                   |
@@ -470,6 +481,7 @@ Add `-d <dir>` when the index is not the nearest one, or name it once with
 | `grep '^#' file.md`                 | `zen rag docs list sections --file file.md`           |
 | `sed -n '40,80p' file.md`           | `zen rag docs show file.md --lines 40-80`             |
 | `cat file.md` (to find one section) | `zen rag docs show file.md --section "Rate limits"`   |
+| a `sed`/`show` per passage          | `zen rag docs show a.md:40-80 b.md:12-30`             |
 | `ls` the index directory            | `zen rag docs stats`                                  |
 
 ```sh
@@ -497,12 +509,12 @@ const index = await docs.DocsIndex.open(
 const project = await loadProject('./my-project', { tools: docs.docsTools(index) });
 ```
 
-| Tool          | For                                                          |
-| ------------- | ------------------------------------------------------------ |
-| `search_docs` | the passages that match, quoted with their line numbers      |
-| `list_docs`   | the documents, their headings, or their tables - no search   |
-| `grep_docs`   | every matching line, counted in full - no search             |
-| `read_docs`   | a section or a line range, verbatim and with nothing omitted |
+| Tool          | For                                                                                        |
+| ------------- | ------------------------------------------------------------------------------------------ |
+| `search_docs` | the passages that match, quoted with their line numbers                                    |
+| `list_docs`   | the documents, their headings, or their tables - no search                                 |
+| `grep_docs`   | every matching line, counted in full - no search                                           |
+| `read_docs`   | a section or a line range, verbatim and with nothing omitted; several at once with `reads` |
 
 Only `search_docs` ranks; the other three are exact, because a model told "no
 results" by a vector search has learned nothing - a ranking returns the top of a
@@ -602,8 +614,8 @@ reference and `guides/` for the task documentation.
 - Does X exist, how is it spelled, how many are there → `grep_docs`. It is
   complete; a search is not, and cannot prove absence.
 - Limits and defaults are in tables → add `kind: ["table_row"]`.
-- Then `read_docs` the lines around the hit before answering. Never answer from
-  the excerpt alone.
+- Then `read_docs` the lines around every hit before answering, all of them in
+  one call with `reads`. Never answer from the excerpt alone.
 - Never `grep`/`rg`/`cat` the tree - the tools above are local and exact.
 
 Worked: per-route rate limits are the table under "Rate limits" in

package/templates/editor/.github/skills/zen-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: zen-review
-description: Checking a project before committing - the four mechanical checks `/project-review` makes before any judgement (`zen check`, the §2.5 path sweep, the memory house-rules copy, the spec-sync record), what each one owns, what their exit codes mean, which findings hand off to `zen-instructions`, and what deliberately has no check because no tool can make it. Load before running `/project-review`, before saying a project is ready, and whenever a review finding needs verifying rather than restating.
+description: Checking a project before committing - the three mechanical checks `/project-review` makes before any judgement (`zen check`, the §2.5 path sweep, the spec-sync record), what each one owns, what their exit codes mean, which findings hand off to `zen-instructions`, and what deliberately has no check because no tool can make it. Load before running `/project-review`, before saying a project is ready, and whenever a review finding needs verifying rather than restating.
 ---
 
 # Reviewing a project
@@ -22,17 +22,16 @@ From the project root, or anywhere at all:
 .github/skills/zen-review/scripts/review.sh
 ```
 
-It runs four checks in the order a reviewer needs them and prints a summary:
+It runs three checks in the order a reviewer needs them and prints a summary:
 
 | Step        | Runs                                       | Owns                                         |
 | ----------- | ------------------------------------------ | -------------------------------------------- |
 | `zen check` | the CLI                                    | everything decidable about the configuration |
 | `paths`     | `zen-review/scripts/check-paths.sh`        | paths a running agent cannot open - §2.5     |
-| `memory`    | `zen-memory/scripts/check-instructions.sh` | the house-rules copy, byte for byte - §5.3   |
 | `spec-sync` | `zen-spec-sync/scripts/snapshot.sh status` | whether the record of the last pass is sound |
 
 Every step runs even when an earlier one fails, because a review that stops at
-the first problem is one somebody has to run four times. The exit code is `1` if
+the first problem is one somebody has to run three times. The exit code is `1` if
 any step wants attention and `0` if none does. `review.sh fast` passes
 `--no-models --no-sandbox` to `zen check`, which is the right call while
 iterating and the wrong one before committing - a key that authenticates says
@@ -41,7 +40,7 @@ nothing about the model id it is spent on.
 Nothing below matters while `zen check` fails. Report what it said and fix that
 first.
 
-## The two scripts this skill ships
+## The script this skill ships
 
 ### `check-paths.sh` - the §2.5 sweep
 
@@ -58,9 +57,10 @@ to open a file that is not there.
 
 It exits `1` whenever it prints a candidate, because the list is meant to be
 emptied or explained rather than skimmed. It strips urls before tokenising, skips
-a handful of English constructions that contain a slash, and leaves
-`agents/memory-instructions.md` out entirely - that file is worked examples by
-design, and `check-instructions.sh` is the check it actually needs.
+a handful of English constructions that contain a slash, and leaves the four
+copies `zen` ships (`agents/{files,fork,memory,tools}-instructions.md`) out
+entirely - they are worked examples by design, and `zen check` keeps them
+byte-identical (`rules.stale`).
 
 Everything it does print is either noise the script has not learned yet or a
 real finding. There is no third case. A candidate that is genuinely noise is a
@@ -69,29 +69,6 @@ copy sitting in this project.
 
 `raw` is the sweep with nothing filtered, for when you suspect the filter.
 
-### `check-instructions.sh` - the memory house rules
-
-Lives in the `zen-memory` skill, because it is about memory and it is read at
-the moment that skill is:
-
-```sh
-.github/skills/zen-memory/scripts/check-instructions.sh        # the verdict
-.github/skills/zen-memory/scripts/check-instructions.sh diff   # and every differing line
-.github/skills/zen-memory/scripts/check-instructions.sh fix    # copy the reference over
-```
-
-`agents/memory-instructions.md` must be a byte-identical copy of the `zen-memory`
-skill's `references/memory-instructions.md`, and the reference is rewritten by
-every `zen init` and `zen open`, so the copy goes stale without anyone touching
-it. It drifts by **trailing whitespace inside tables**, which is invisible on
-screen - this is the check no one should be asked to make by eye. When the
-difference is whitespace alone the script says so, because that is the usual
-cause and the least believable finding.
-
-`fix` is the one-line `cp` and nothing else. Project policy belongs in
-`agents/memory-policy-instructions.md`, which filename order puts directly after
-the copy - see the `zen-memory` skill.
-
 ## Findings that are not yours to fix in place
 
 `zen check` reports `rules.stale`, `files.uninstructed`, `memory.uninstructed`,

package/templates/editor/.github/skills/zen-review/scripts/check-paths.sh

@@ -43,10 +43,10 @@ strip_urls() {
 # The three trees §2.5 names, prose only: a skill's own script is code the
 # sandbox runs, not text rendered into a prompt, and its paths are its own.
 #
-# `agents/memory-instructions.md` is left out on purpose. It is a copy of the
-# reference, full of worked examples, so it fails this sweep by design and
-# every run of it — and it has a check of its own that a sweep cannot make:
-# .github/skills/zen-memory/scripts/check-instructions.sh
+# The four copies `zen` ships (files-, fork-, memory-, tools-instructions.md)
+# are left out on purpose. They are full of worked examples, so they fail this
+# sweep by design, and the project cannot edit them anyway: `zen check` reports
+# any byte that differs as `rules.stale`.
 files() {
     {
         if [ -d agents/prompts ]; then find agents/prompts -type f -name '*.md'; fi
@@ -54,7 +54,7 @@ files() {
         for file in agents/*instructions.md; do
             if [ -f "$file" ]; then echo "$file"; fi
         done
-    } | grep -v '^agents/memory-instructions\.md$' | sort -u
+    } | grep -Ev '^agents/(files|fork|memory|tools)-instructions\.md$' | sort -u
 }
 
 # Every token in those files, urls removed first, and a sentence's full stop

package/templates/editor/.github/skills/zen-review/scripts/review.sh

@@ -2,7 +2,7 @@
 #
 # Every check a review can make without judgement, in the order it makes them.
 #
-#   review.sh            zen check, then paths, memory, and the spec-sync record
+#   review.sh            zen check, then paths and the spec-sync record
 #   review.sh fast       the same, with `zen check --no-models --no-sandbox`
 #
 # What it prints is findings. What it cannot see — whether an agent has one job,
@@ -10,7 +10,7 @@
 # the rest of /project-review, and the reason that prompt still exists.
 #
 # Every step runs even when an earlier one fails: a review that stops at the
-# first problem is one somebody has to run four times. The exit code is 1 if
+# first problem is one somebody has to run three times. The exit code is 1 if
 # anything wants attention, 0 if nothing does.
 #
 # Run it from anywhere; it finds the project root from its own location.
@@ -58,7 +58,7 @@ if command -v zen >/dev/null 2>&1; then
         verdict 'zen check' "exit $rc — nothing below matters until this passes" 1
     fi
 else
-    echo "zen is not on PATH — install it, or run the other three alone"
+    echo "zen is not on PATH — install it, or run the other two alone"
     verdict 'zen check' 'not run' 1
 fi
 
@@ -71,15 +71,6 @@ else
     verdict 'paths' 'candidates to explain or fix' 1
 fi
 
-step 'memory'
-"$SKILLS/zen-memory/scripts/check-instructions.sh"
-rc=$?
-if [ "$rc" -eq 0 ]; then
-    verdict 'memory' 'ok' 0
-else
-    verdict 'memory' 'the house rules are missing or stale' 1
-fi
-
 step 'spec-sync'
 if [ -f SPECIFICATION.md ]; then
     # `status` reports a tampered baseline rather than failing on one, so the

package/templates/editor/.github/skills/zen-sandbox/SKILL.md

@@ -18,7 +18,7 @@ and no argv length to overflow.
 
 The container engine is **Podman** (rootless by default).
 
-For the CLI subcommands (`zen sandbox status`, `up`, `pull`, `clean`, `disk`)
+For the CLI subcommands (`zen sandbox status`, `top`, `up`, `pull`, `clean`, `disk`)
 and command-line options, see the [zen-cli skill](../zen-cli/SKILL.md) and its
 dedicated reference document [sandbox.md](../zen-cli/references/sandbox.md).
 
@@ -195,7 +195,8 @@ an exit 124 that looks like a slow index.
 One container is rarely the problem. Before running several at once — a
 `zen run batch` with `--concurrency` above 1 — load **zen-sandbox-capacity** and
 run its `preflight_sandbox.sh`, which measures the VM, the container cap and the
-index and says whether the arithmetic fits.
+index and says whether the arithmetic fits. A `zen-finetune` run is the
+exception: it starts at `min(maxBatch + recheck, 16)` and halves on OOM instead.
 
 ---
 
@@ -259,9 +260,11 @@ Use the `zen sandbox` commands via terminal to inspect and manage container stat
 
 ```sh
 zen sandbox status          # Check podman version, machine status, and active containers
+zen sandbox top --once      # Memory and cpu of the machine and every running container
 zen sandbox up              # Start VM (macOS) and pull or build the required image
 zen sandbox pull            # Re-pull base image or force build of sandbox/Dockerfile
-zen sandbox clean           # Force remove all zn-* containers created by this project
+zen sandbox clean           # Force remove all zn-* containers created by this CLI
+zen sandbox clean --idle    # Only what no live run uses: stopped and orphaned ones
 zen sandbox disk            # Inspect disk space consumed by images, containers, and volumes
 ```
 
@@ -273,4 +276,6 @@ zen sandbox disk            # Inspect disk space consumed by images, containers,
 - **Permission Denied in `/workspace`:**
     - In `strict` mode without `user:`, rootless Podman uses `keep-id` to preserve host UID. If using custom `user:`, verify host directory permissions allow that UID.
 - **Disk Space Pressure:**
-    - Run `zen sandbox clean` to prune stopped session containers.
+    - Run `zen sandbox clean --idle` to prune stopped and orphaned session containers.
+- **`could not create container … exceeded num_locks`:**
+    - Every container holds one engine lock (2048 by default), stopped ones included. Run `zen sandbox clean --idle`.

package/templates/editor/.github/skills/zen-sandbox-capacity/SKILL.md

@@ -240,14 +240,14 @@ do with the machine.
 
 ## A machine spec is part of a round
 
-Record it into the round directory, next to the findings:
+Record it into the run directory, next to the findings:
 
 ```sh
 {
     echo "host      $(($(sysctl -n hw.memsize) / 1073741824)) GiB"
     podman info --format json | jq -r '.host | "vm        \(.memTotal / 1073741824 | floor) GiB · swap \(.swapTotal) · \(.cpus) cpus"'
     echo "batch     --concurrency 8"
-} > .finetune/rounds/r5/machine.txt
+} > finetune/runs/batch01-nomem-run1/machine.txt
 ```
 
 The consequence is not bookkeeping, it is validity: **token counts and

package/templates/editor/.github/skills/zen-spec-sync/SKILL.md

@@ -120,10 +120,8 @@ However small the diff:
 3. **§9 of the copilot instructions, worked as a checklist**, group by group.
 4. **The capability obligations in §0.1.** For every capability the project has
    turned on, load that capability's skill and re-check what it requires - in
-   particular that `agents/memory-instructions.md` is still byte-identical to
-   `.github/skills/zen-memory/references/memory-instructions.md`. `zen init` and
-   `zen open` rewrite the reference, so this drifts without anybody editing the
-   project.
+   particular that `zen check` reports no `rules.stale`: a newer `zen` ships
+   newer house rules, so they drift without anybody editing the project.
 5. **`zen-instructions` is loaded before any house rule is touched.** A pass
    whose scope reaches `agents/*instructions.md` - and input 4 puts it there
    whenever one of them moved - has to know that `tools-instructions.md`,