@zenera/cli 1.1.25 → 1.1.26

package/dist/tui/sandbox.js

@@ -0,0 +1,131 @@
+import { jsx as _jsx, jsxs as _jsxs } from "react/jsx-runtime";
+// ---------------------------------------------------------------------------
+// zen sandbox top
+//
+// The resource report, redrawn on a timer. Nothing here measures anything or
+// decides what a figure means: resources.ts samples and lays out, and this
+// file only colours the lines it is handed and owns the keys.
+//
+// The frame is cut to the terminal's height before Ink sees it — a frame
+// taller than the screen scrolls its own top away and every repaint leaves a
+// copy of it behind (see tui/app.tsx).
+// ---------------------------------------------------------------------------
+import { Box, render, Text, useApp, useInput, useStdout } from 'ink';
+import React, { useEffect, useState } from 'react';
+import { layout, SORTS, } from "../resources.js";
+import { resolveTheme } from "./theme.js";
+const message = (err) => (err instanceof Error ? err.message : String(err));
+function styleOf(tone, theme) {
+    switch (tone) {
+        case 'strong':
+            return { bold: true };
+        case 'heading':
+            return { bold: true, color: theme.accent };
+        case 'dim':
+            return { color: theme.chrome.color };
+        case 'good':
+            return { color: theme.code.color };
+        case 'warn':
+            return { color: theme.warn };
+        case 'bad':
+            return { color: theme.line.error.color };
+        case 'accent':
+            return { color: theme.accent };
+        default:
+            return {};
+    }
+}
+function Painted({ line, theme }) {
+    if (line.length === 0) {
+        return _jsx(Text, { children: " " });
+    }
+    return (_jsx(Text, { wrap: "truncate-end", children: line.map((span, i) => (_jsx(Text, { ...styleOf(span.tone, theme), children: span.text }, i))) }));
+}
+function Top({ sampler, intervalMs, explain: start, palette }) {
+    const { exit } = useApp();
+    const { stdout } = useStdout();
+    const [size, setSize] = useState({ columns: stdout.columns || 80, rows: stdout.rows || 24 });
+    useEffect(() => {
+        const resized = () => setSize({ columns: stdout.columns || 80, rows: stdout.rows || 24 });
+        stdout.on('resize', resized);
+        return () => {
+            stdout.off('resize', resized);
+        };
+    }, [stdout]);
+    const [view, setView] = useState();
+    const [failure, setFailure] = useState();
+    const [explain, setExplain] = useState(start);
+    const [sort, setSort] = useState('memory');
+    const [paused, setPaused] = useState(false);
+    useEffect(() => {
+        if (paused) {
+            return;
+        }
+        let stopped = false;
+        let timer;
+        const tick = async () => {
+            try {
+                const next = await sampler.next();
+                if (!stopped) {
+                    setView(next);
+                    setFailure(undefined);
+                }
+            }
+            catch (err) {
+                if (!stopped) {
+                    setFailure(message(err));
+                }
+            }
+            if (!stopped) {
+                timer = setTimeout(() => void tick(), intervalMs);
+            }
+        };
+        void tick();
+        return () => {
+            stopped = true;
+            clearTimeout(timer);
+        };
+    }, [sampler, intervalMs, paused]);
+    useInput((input, key) => {
+        // A pasted or piped key can arrive with a newline behind it.
+        const k = input.trim()[0];
+        if (k === 'q' || key.escape) {
+            exit();
+        }
+        else if (k === 'e' || k === '?') {
+            setExplain((on) => !on);
+        }
+        else if (k === 's') {
+            setSort((now) => SORTS[(SORTS.indexOf(now) + 1) % SORTS.length]);
+        }
+        else if (k === 'p' || input === ' ') {
+            setPaused((on) => !on);
+        }
+    });
+    // One row for the keys, one spare so the frame never reaches the bottom.
+    const rows = Math.max(4, size.rows - 2);
+    const lines = view
+        ? layout(view, {
+            width: size.columns - 1,
+            rows: failure ? rows - 1 : rows,
+            explain,
+            sort,
+            live: intervalMs / 1000,
+        })
+        : [[{ text: 'asking podman…', tone: 'dim' }]];
+    const keys = [
+        `e notes ${explain ? 'off' : 'on'}`,
+        `s sort: ${sort}`,
+        paused ? 'p resume' : 'p pause',
+        'q quit',
+    ].join(' · ');
+    return (_jsxs(Box, { flexDirection: "column", children: [lines.map((line, i) => (_jsx(Painted, { line: line, theme: palette }, i))), failure ? (_jsx(Text, { wrap: "truncate-end", color: palette.line.error.color, children: `  ✗ ${failure}` })) : null, _jsx(Text, { wrap: "truncate-end", color: palette.chrome.color, children: paused ? `paused · ${keys}` : keys })] }));
+}
+/** Runs the live screen until the person leaves it. */
+export async function watch(options) {
+    // Asked before Ink takes the terminal, as tui/app.tsx does.
+    const palette = await resolveTheme(options.theme);
+    const instance = render(_jsx(Top, { ...options, palette: palette }));
+    await instance.waitUntilExit();
+}
+//# sourceMappingURL=sandbox.js.map

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@zenera/cli",
-    "version": "1.1.25",
+    "version": "1.1.26",
     "description": "Command-line front end for @zenera/neo: agentic projects you can run, share and commit.",
     "keywords": [
         "agents",
@@ -52,7 +52,8 @@
         "@google/genai": "^2.18.0",
         "@inkjs/ui": "^2.0.0",
         "@openrouter/sdk": "^1.2.80",
-        "@zenera/neo": "^1.1.25",
+        "@zenera/neo": "^1.1.26",
+        "@zenera/view": "^1.1.26",
         "google-auth-library": "^10.0.0",
         "ink": "^7.1.1",
         "openai": "^6.0.0",

package/templates/editor/.github/copilot-instructions.md

@@ -113,29 +113,20 @@ tool access; give tool-based RAG users the configured RAG tools instead. Run
 `zen check` after adding or changing the skill.
 
 Memory has one such obligation and it is absolute: **a project with a `memory:`
-block carries the `zen-memory` skill's `references/memory-instructions.md` in its
-own `agents/memory-instructions.md`.** `zen init` writes both, since it scaffolds
-memory on; what needs watching is a project that deleted the file, or one whose
-copy has fallen behind the reference. Do not read the two files against each
-other - they drift by trailing whitespace inside tables, which is invisible.
-The skill ships the check:
-
-```sh
-.github/skills/zen-memory/scripts/check-instructions.sh       # the verdict
-.github/skills/zen-memory/scripts/check-instructions.sh fix   # copy the reference over
-```
-
-It is a copy, never a transcription - the reference ships inside the project,
-because `zen init` and `zen open` write this whole `.github/` tree, so `fix` is
-just `cp` from one to the other.
+block carries `agents/memory-instructions.md` exactly as `zen` ships it.**
+`zen init` writes it, since it scaffolds memory on; what needs watching is a
+project that deleted the file, or one whose copy has fallen behind. `zen check`
+reports the first as `memory.uninstructed` and the second as `rules.stale` -
+by bytes, so trailing whitespace inside a table, invisible on screen, is caught
+too - and `zen check --fix` repairs both.
 
 Nothing else tells a running agent how the store works, so without it nothing
 forbids an agent from pointing `grep` or `cat` at `/memory` - a read that
-bypasses the audience mask and serves superseded nodes as current. Keep the copy
-byte-identical and put this project's own memory policy in a second topic file,
-`agents/memory-policy-instructions.md`, which is read straight after it: then the
-copy can be re-run after any `zen init` or `zen open` refreshes the reference,
-without losing anything. Never paraphrase the reference into prose of your own.
+bypasses the audience mask and serves superseded nodes as current. Leave the
+file untouched and put this project's own memory policy in a second topic file,
+`agents/memory-policy-instructions.md`, which is read straight after it: then
+`zen check --fix` can replace the first after any upgrade without losing
+anything. Never paraphrase it into prose of your own.
 See §5.3.
 
 A project with a `SPECIFICATION.md` carries one more: **`.spec-sync/` records
@@ -1334,13 +1325,11 @@ derived from `access` and are never listed in `tools:`.
 
 **Memory comes on.** `zen init` writes the block above, `memory: true` on the
 default agent, and the half nobody would guess was part of it:
-`agents/memory-instructions.md`, a copy of the `zen-memory` skill's
-`references/memory-instructions.md`, which the project already holds. Adding
-memory to a project that has none is both of those edits, and a copy that was
-lost or went stale is one command:
+`agents/memory-instructions.md`. Adding memory to a project that has none is
+both of those edits, and a file that was lost or went stale is one command:
 
 ```sh
-.github/skills/zen-memory/scripts/check-instructions.sh fix
+zen check --fix
 ```
 
 It is what tells the agent that the store is reached only through the tools, that
@@ -1352,19 +1341,17 @@ what a node must carry to be worth having, and that a correction is a
 with it - and it carries `requires: [memory]`, so an agent without the store
 never reads a word of it.
 
-**Leave that file as a pure copy.** Anything this project decides for itself -
+**Leave that file untouched.** Anything this project decides for itself -
 which audience holds what, what must never be written down, what an agent is
 expected to commit at the end of a job - goes in
 `agents/memory-policy-instructions.md`. Topic files are read in filename order,
-so the policy lands directly after the rules it qualifies, and the copy stays
-re-runnable: the reference is rewritten by every `zen init` and `zen open`, and
-keeping up with it is then the same one-line command rather than a hand-patch.
+so the policy lands directly after the rules it qualifies, and the file stays
+replaceable: keeping up with a newer `zen` is then `zen check --fix` rather
+than a hand-patch.
 
-`zen check` validates the `memory:` block and says nothing about the rules'
-absence, so this is checked every time, by
-`.github/skills/zen-memory/scripts/check-instructions.sh` and never by reading
-the two files against each other: they drift by trailing whitespace inside a
-table, and the script is what can see that.
+`zen check` reports a missing file as `memory.uninstructed` and any differing
+byte as `rules.stale`. Never compare the file by eye: it drifts by trailing
+whitespace inside a table, and only a byte comparison sees that.
 
 Do not treat memory as a database. It is for things learned that should
 persist. Anything authoritative - a rate, a policy clause, a procedure - belongs
@@ -1865,8 +1852,8 @@ ok, `1` failed, `2` usage, `3` invalid project, `4` no usable credential.
 
 ## 9. Review checklist
 
-Four of these are decidable, and are one command - `zen check`, the path sweep,
-the memory copy, the spec-sync record, in that order:
+Three of these are decidable, and are one command - `zen check`, the path sweep,
+the spec-sync record, in that order:
 
 ```sh
 .github/skills/zen-review/scripts/review.sh
@@ -1905,10 +1892,9 @@ Before finishing any change here:
 - [ ] Failure paths stated for every instruction that can fail
 - [ ] No facts, rates or figures embedded in a prompt
 - [ ] No hedging, no meta-talk about the runtime
-- [ ] If any agent has `memory:`,
-      `.github/skills/zen-memory/scripts/check-instructions.sh` exits zero -
-      `agents/memory-instructions.md` is the reference byte for byte - and
-      anything project-specific is in `agents/memory-policy-instructions.md` - §5.3
+- [ ] If any agent has `memory:`, `zen check` reports neither
+      `memory.uninstructed` nor `rules.stale` - and anything project-specific
+      is in `agents/memory-policy-instructions.md` - §5.3
 
 **Paths (§2.5 - `.github/skills/zen-review/scripts/check-paths.sh` finds the
 candidates; these are the judgements to make about each one)**
@@ -2044,10 +2030,10 @@ candidates; these are the judgements to make about each one)**
   the turn that follows it - §2.5.
 - **Arithmetic in prose.** A skill that walks the model through a calculation it
   will get wrong, in a folder that could have held the script - §3.4.1.
-- **The unguarded store.** `memory:` turned on and the skill's
-  `references/memory-instructions.md` never copied to
+- **The unguarded store.** `memory:` turned on and no
   `agents/memory-instructions.md`, so nothing tells the agent the store is
-  reached only through the tools - and `zen check` passes throughout - §5.3.
+  reached only through the tools - `zen check` fails with
+  `memory.uninstructed`, and `zen check --fix` writes it - §5.3.
 - **Reviewing a capability without its skill.** A project whose memory, index or
   sandbox was configured by an earlier pass looks finished because it loads. The
   obligations are in the editor skill, not in `agents.yaml` - §0.1.

package/templates/editor/.github/prompts/analyze.prompt.md

@@ -10,9 +10,11 @@ audit cannot be graded without it.
 
 ## Which run
 
-The last line of this prompt may name the run - a run directory or a run id.
+The line after this prompt may name the run - a run directory or a run id.
 If it does, use it. Words after it like `case=<id> ... feedback=<file>` mean
 the tuning loop sent you: follow section 7 of the skill and write that file.
+A `## The brief` section below that line is what the loop already ran for
+you: section 1 of the skill says how to use it.
 
 If it does not, list this project's most recent runs, newest first:
 

package/templates/editor/.github/prompts/finetune-apply.prompt.md

@@ -1,45 +1,197 @@
 ---
-description: Apply a batch of improvement requests from the tuning loop to the project's prose - merge them into patterns, edit prompts, skills and policy files, and record what was done with each. Run by `zen meta finetune`; the last line names the apply directory.
+description: Apply a batch of improvement requests from the tuning loop to the project's prose - merge them into patterns, edit prompts, skills and policy files, tidy up every file touched, and record what was done with each. Run by `zen meta finetune`; the line after the prompt names the apply directory, and a brief follows it.
 ---
 
 The tuning loop has collected improvement requests from several cases and
-wants them applied **together**. The last line of this prompt names the apply
-directory. Load the `zen-instructions` skill before you edit anything under
-`agents/`, `zen-memory` when any request is from a run with memory, and
-`zen-code-python` when any request touches an agent that writes or runs code.
+wants them applied **together**. The line after this prompt names the apply
+directory.
+
+Every sentence you add is read by every later call of every agent that loads
+it, so prose has a price even when it fixes the case in front of you. The loop
+measures it: after you finish, an apply that grows the prose past its budget
+is **undone** - all of it. Then a few cases that passed before run again on
+your edit; one it broke comes back to the next apply as a request.
 
 ## What you are given
 
+A `## The brief` section after that line is what the loop already read and
+worked out for you, from the files below. Work from it:
+
+- Do not read a file the brief shows, and do not run a command it shows -
+  until you have edited that file yourself.
+- Do not parse `inputs.json`, `deferred.json`, `budget.json` or `growth.json`
+  with a script: `Requests by file`, `The requests`, `Growth` and the
+  `budget.json` block are their content. Open one only for a field the brief
+  marks `(cut at ...)` or `(left out ...)`.
+- Do not open other `finetune/applies/*` folders: `Earlier tries of these
+cases` is what they hold about these cases.
+
+The files behind it:
+
 - `<apply dir>/inputs.json` - the requests: each has `id` (`<case>@<phase>-<attempt>`),
   `case`, `phase` (`nomem` or `mem`), `summary`, `improvements` (each with `id`,
-  `kind`, `file`, `change`, `why`, `expect`) and `file`, the feedback it came from.
-  The analysis behind each is `analysis.md` beside that file - read it when an
-  improvement is unclear.
-- Every earlier `finetune/applies/*/decisions.json` and `changes.md` - what
-  was already tried. Do not re-apply a rule an earlier apply added and a later
-  run showed did not work; change it instead.
-- `<apply dir>/check.log`, if it exists: your previous attempt left the project
-  failing `zen check`, and the edit was undone. Read it first.
+  `kind`, `file`, `change`, `why`, `expect`), `file`, the feedback it came from,
+  and `missedSkills` - skills an earlier apply made for this case that its last
+  run never loaded. The analysis behind each is `analysis.md` beside that file -
+  read it when an improvement is unclear.
+  A request with `recheck` (id `<case>@recheck-<apply>`) is a **regression**: the
+  case passed before that apply and failed twice on it. Its analysis quotes the
+  hunk of that apply's `diff.patch` that did it. Narrow or revert that rule -
+  never stack an exception under it.
+- `<apply dir>/deferred.json` - improvements earlier applies held back because
+  only one case asked for them, with their case and apply. They count as
+  evidence below.
+- `<apply dir>/budget.json` - what the agents read, in bytes: `alwaysRead` per
+  agent (house rules, its prompt, preloaded skills, the skill index lines),
+  `skills` (each on-demand skill body), `visible` (skills each agent can see),
+  the same at the start of the tuning (`start`), and the limits: `budget` (the
+  most this apply may add to the always-read total), `ceiling` (above it, an
+  apply may add nothing), `skillCap`, `maxSkills`.
+- `<apply dir>/growth.json` - per file under `agents/`: bytes at the start of
+  the tuning and now, how many applies changed it, and the latest of them.
+- Earlier requests of the same cases, and what each apply decided about them -
+  the brief's `Earlier tries of these cases`. Do not re-apply a rule an
+  earlier apply added and a later run showed did not work; change it instead.
+- From your previous attempt, if it was undone - the first files in the brief:
+  `check.log` (it failed `zen check`), `budget.md` (it grew the prose past a
+  limit - this attempt must cut) and `missing.md` (it ended without a decision
+  for every improvement).
+
+## Load the skills
+
+A request says what a run did wrong; the rules for fixing it live in the editor
+skills, not in the request. The brief's `Skills to load` lists the ones this
+project's capabilities call for. Load every one of them now, before the first
+edit. Load `zen-sandbox` too when any improvement is about the container,
+installing packages, or a command that failed for want of a tool. No other
+`zen-*` skill is needed.
+
+An improvement that already sounds right is not a reason to skip its skill -
+the skill is how you find out whether it is.
 
 ## What to do
 
-1. **Merge before editing.** Group the improvements by the behaviour they fix.
-   Several cases asking for the same thing in different words is one rule.
-   Two that contradict each other: decide, and say why.
-2. **Generalise.** Every rule must hold for queries no case asked. Never write
-   a case's answer, its ids or its data into the prose - if a request only
-   makes sense for its one case, reject it.
-3. **Edit** prompts under `agents/prompts/`, skills under `agents/skills/`,
-   `agents/instructions.md` and `agents/<topic>-policy-instructions.md`
-   (create the policy file when the rule belongs to one capability). Requests
-   from runs **with memory** change only the memory policy -
-   `agents/memory-policy-instructions.md` - or the memory paragraph a request
-   names.
-4. **Never edit** `agents.yaml`, `agents/memory-instructions.md`,
-   `agents/tools-instructions.md`, `agents/fork-instructions.md` or
-   `agents/files-instructions.md`, nor anything outside `agents/`. A request
-   that needs one of those is **structural**: record it, do not apply it.
-5. **Check**: `zen check --no-models --no-sandbox` must pass when you finish.
+1. **Merge before editing.** The brief's `Requests by file` has already put
+   the improvements - and the entries of `deferred.json` - under the file each
+   names, with the distinct cases behind each file. Now group them by the
+   behaviour they fix, across files too. Several cases asking for the
+   same thing in different words is one pattern. Two that contradict each
+   other: decide, and say why. Count the **distinct cases** behind each
+   pattern.
+2. **Hold each against its skill.** An improvement's `change` is one analyst's
+   guess at the fix. A change that breaks a skill's rule - shell `grep` over an
+   index, a paraphrase of a copied house rule, a one-off inline script, a
+   handoff with no way back - is rewritten to what the skill prescribes, or
+   rejected naming the rule. When the skill already states the rule, the agent
+   never saw it: fix how the skill is reached (its description, a load line in
+   the prompt), not a second copy of the rule.
+3. **Prove the owner and the absence**, for every pattern:
+    1. State the obligation in one sentence of your own, not the wording of
+       any request.
+    2. Name exactly which agents must obey it, and choose the narrowest place
+       that reaches all of them - see the table in step 6.
+    3. Search every file those agents read for the same obligation: house
+       rules (`agents/instructions.md`, every `agents/*-instructions.md`),
+       their prompts, their preloaded skills and the skills they would load
+       for it. Search its distinctive verbs and nouns and obvious other
+       wordings, not one exact quote.
+    4. Choose exactly one disposition: `edit existing`, `move and delete`,
+       `delete contradiction`, `extract to skill`, or `add because absent`.
+       Every location found goes in `changes.md`.
+
+    If several places say it, consolidate into the one owner and delete the
+    others in this apply. If a broad rule caused the failure, rewrite or
+    narrow that rule - never keep it and add an exception elsewhere.
+
+4. **Evidence.** `add because absent` and `extract to skill` need **two or
+   more distinct cases** behind the pattern, counting `deferred.json`. With
+   one case you may only `edit existing`, `move and delete` or
+   `delete contradiction`, and only if the always-read total does not grow.
+   Anything else from one case is `deferred` - not applied, not rejected: it
+   comes back in `deferred.json` until a second case asks for it.
+5. **Generalise.** Write each rule for a class of queries, not for a case -
+   it must hold for queries no case asked. Never write a case's answer, ids,
+   names, numbers or data into the prose, nor an example lifted from a case's
+   query. Keep a specific only when the rule cannot be stated without it - a
+   tool, a command, a file path of this project. Before you save, check every
+   sentence you added: a noun, number or quoted phrase that comes from a case
+   and appears nowhere else in the project is overfit - replace it with the
+   class it belongs to, or drop the rule. A request that only makes sense for
+   its one case is rejected.
+6. **Route by behaviour, not by phase.** A request from a run with memory goes
+   where its behaviour is owned, like any other.
+
+    | The obligation is…                                                   | It goes in                                                |
+    | -------------------------------------------------------------------- | --------------------------------------------------------- |
+    | one agent's behaviour, on every request it gets                      | `agents/prompts/<agent>.md`                               |
+    | a procedure or facts only some kinds of request need                 | an on-demand skill under `agents/skills/` - see step 7    |
+    | a standing rule every agent must obey                                | `agents/instructions.md`                                  |
+    | what to commit to memory, when to recall, what to trust from it      | `agents/memory-policy-instructions.md`                    |
+    | a rule every user of one capability must obey                        | that capability's `agents/<topic>-policy-instructions.md` |
+    | the wrong agent had a tool, a skill binding, the dataset or a rubric | **structural** - record it, do not compensate with prose  |
+
+7. **Skills.** `extract to skill` moves a procedure or a set of facts out of a
+   prompt or a policy into `agents/skills/<name>/SKILL.md`, which the agent
+   loads only when a request needs it. Its body costs nothing until then; its
+   index line costs on every call.
+    - The prompt keeps **one line** pointing at the skill: the condition and
+      the name. Delete the moved prose from where it was.
+    - The `description:` says **when** to load it - the condition, in words a
+      request would match - and must not overlap another skill's.
+    - Never make a skill for one case's data: what one case needs to know
+      about its own data is memory's job. Rejected.
+    - A skill in `missedSkills` was not loaded by the case it was written for:
+      its description is the defect. Rewrite the description - not more
+      prose. A skill missed twice goes back into its owner (`move and delete`)
+      or into a skill that is loaded.
+    - Keep each skill under `skillCap` and each agent under `maxSkills`: an
+      oversized skill is split by when it is needed, overlapping ones merged.
+    - You cannot preload a skill: that is `agents.yaml`, structural.
+8. **Never write:**
+    - an exception stacked under a general rule, or "this overrides X" -
+      rewrite X;
+    - a tool-call script ("call A first", "read lines 1-200") - write the
+      invariant it serves;
+    - a prohibition with an exemption the agent judges for itself ("unless
+      clearly needed") - that is a permission. Forbid it, or do not.
+9. **Stay inside the budget** in `budget.json`. Over `ceiling`, this apply must
+   not grow the always-read total at all: cut, move or extract to make room.
+10. **Edit** prompts under `agents/prompts/`, skills under `agents/skills/`,
+    `agents/instructions.md` and `agents/<topic>-policy-instructions.md`
+    (create a policy file only when step 3 proved the rule absent and every
+    agent with that capability must obey it).
+11. **Never edit** `agents.yaml`, `agents/memory-instructions.md`,
+    `agents/tools-instructions.md`, `agents/fork-instructions.md` or
+    `agents/files-instructions.md`, nor anything outside `agents/`.
+12. **Tidy up every file you touched** - the whole file, not only your lines.
+    For each obligation in it, search the files the same agents read, and pick
+    one move:
+    - `merge duplicates` - the same obligation twice for the same audience:
+      keep it in the owner, delete the rest;
+    - `delete contradiction` - two sentences that cannot both be obeyed: keep
+      the one the later `changes.md` chose;
+    - `narrow` - a general rule followed by its exceptions: rewrite the rule so
+      it needs none, delete the exceptions;
+    - `move and delete` - a rule in a file wider than the agents it binds;
+    - `split skill` / `merge skills` - a skill over `skillCap`, two whose
+      descriptions overlap, or an agent over `maxSkills`.
+
+    Never weaken an obligation: what an agent must do stays what it must do.
+    The bytes this frees count against your budget, so a crowded file is where
+    to make room. Then take the largest growth in `growth.json` you did not
+    touch: if it says one thing twice, merge it too.
+
+13. **Read it back.** Search again for each obligation's terms, and read each
+    affected agent's prompt in the order it is assembled - house rules first,
+    then its prompt. Every remaining copy must have a different audience, or
+    go.
+14. **Gate**: when your edits are done, run once
+    `zen meta finetune gate <apply dir>`. It judges the edit exactly as the
+    loop will after you: the bytes moved per agent, skill and file, any limit
+    broken, and `zen check`. On `gate: fail`, fix what it names and run it
+    again. Do not measure or diff files yourself and do not use git: the loop
+    never commits, so `git diff` mixes in earlier applies, and it records the
+    diff and the bytes of this apply after you finish.
 
 ## What to write
 
@@ -54,38 +206,65 @@ directory. Load the `zen-instructions` skill before you edit anything under
     **The pattern:** what the cases did wrong, in one paragraph, with the node
     ids from their analyses - not a case's answer.
 
-    **Before:** the sentence or section as it was, quoted (or "new section").
+    **Obligation:** the one sentence of step 3, and the agents it binds.
+
+    **Searched:** the terms you searched for, and every place they were found.
+
+    **Disposition:** `edit existing`, `move and delete`, `delete contradiction`,
+    `extract to skill` or `add because absent` - with the cases behind it.
 
     **After:** the text as it is now, quoted.
 
+    **Checked against:** the skill and rule it was held to, or "no skill
+    covers this".
+
     **Why it generalises:** which queries beyond these cases it changes, and
     which it must not.
 
-    **Expect:** what the next run's graph should show if it worked.
+    **Expect:** what the next run's graph should show if it worked - for a
+    skill, the `skills <name>` node before the step it covers.
     ```
 
-    Then a section **Not applied**: every rejected or structural improvement, with
-    why.
+    A section for a tidy-up move has **Move**, **Obligation** and **After**
+    only. The diff and the bytes moved are added by the loop - do not write
+    them.
+
+    Then a section **Not applied**: every rejected, deferred or structural
+    improvement, with why.
 
 - `<apply dir>/decisions.json` - a decision for **every** improvement of every
-  request, nothing skipped:
+  request, nothing skipped. When you apply or merge an entry of
+  `deferred.json`, add it under its own request id too:
 
 ```json
 {
     "plan-day@nomem-1": {
-        "i1": { "decision": "applied", "note": "agents/prompts/default.md - planning section" },
+        "i1": {
+            "decision": "applied",
+            "disposition": "extract to skill",
+            "skill": "calendar-planning",
+            "note": "agents/skills/calendar-planning - planning procedure moved out of the prompt"
+        },
         "i2": { "decision": "merged", "note": "same rule as long-list-3@nomem-1 i1" }
     },
     "long-list-3@nomem-1": {
-        "i1": { "decision": "applied", "note": "agents/pagination-policy-instructions.md" },
+        "i1": {
+            "decision": "applied",
+            "disposition": "edit existing",
+            "note": "agents/pagination-policy-instructions.md"
+        },
         "i2": { "decision": "structural", "note": "needs a tool in agents.yaml" },
-        "i3": { "decision": "rejected", "note": "only true for this case's data" }
+        "i3": { "decision": "rejected", "note": "only true for this case's data" },
+        "i4": { "decision": "deferred", "note": "one case; waits for a second" }
     }
 }
 ```
 
-`decision` is one of `applied`, `merged`, `rejected`, `structural`. The note is
-one line a person reads in the case's FEEDBACK.md.
+`decision` is one of `applied`, `merged`, `rejected`, `deferred`, `structural`.
+`disposition` is the one from step 3, on every `applied`. `skill` names the
+skill an improvement created or changed - the loop checks the case's next run
+loads it. The note is one line a person reads in the case's FEEDBACK.md.
 
-Your answer is a short summary: how many rules, which files, and anything
-structural the user must decide.
+Your answer is a short summary: how many rules, which files, what the tidy-up
+merged or cut, the net change in bytes `gate` printed, and anything structural
+the user must decide.

package/templates/editor/.github/prompts/project-review.prompt.md

@@ -13,7 +13,7 @@ saying anything.
 .github/skills/zen-review/scripts/review.sh
 ```
 
-That is `zen check`, the §2.5 path sweep, the memory house-rules copy and the
+That is `zen check`, the §2.5 path sweep and the
 spec-sync record, in the order they matter. Load the `zen-review` skill for what
 each one owns and how to read its output. Do not re-verify by hand anything it
 already decided, and do not go further while `zen check` fails - nothing below