devflow-kit 3.6.0 → 3.8.0

package/CHANGELOG.md

@@ -5,6 +5,441 @@ All notable changes to Devflow will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [3.8.0] - 2026-10-21
+
+### Upgrade notes — Curation rename
+
+The learning feature is now called curation ([#529](https://github.com/dean0x/devflow/issues/529)).
+This is a breaking change. It releases as a minor version (3.8.0).
+Devflow keeps no alias for the old command and the old init flags. The old switch keys stay readable, as the table shows. Read the steps that you must do by hand.
+
+**Superseding statement for 3.6.0:** The 3.6.0 notes say that `devflow learning`, `features.learning`,
+`.devflow/learning/` and the learning ops do not change. That statement is no longer true.
+This release changes all of them. The 3.6.0 text stays as released.
+
+**What you must do:**
+- Run `devflow init` after you update.
+- Replace `devflow learning` and the old init flags in your scripts.
+- Delete each backup folder after `devflow curation --status` shows 0 pending rows for it.
+  A backup made on re-upgrade can hold the only copy of entries that 3.7 wrote. Check them before you delete it.
+- Delete the leftover `.devflow/learning/` folder in each linked worktree whose main checkout has a `.devflow/` folder
+  and is not your home folder.
+  A worktree whose main checkout has no `.devflow/` folder, or is your home folder, keeps a live ledger.
+  That ledger moves like any project.
+- Run `devflow curation --enable` if the machine switch is off and you want it on.
+
+**Renamed names:**
+
+| Old name | New name |
+|----------|----------|
+| `devflow learning` | `devflow curation` |
+| `devflow init --learning` and `--no-learning` | `devflow init --curation` and `--no-curation` |
+| `features.learning` in `~/.devflow/manifest.json` | `features.curation` (the old key stays as a mirror) |
+| `features.learning` in a repository `project.json` or `config.json` | `features.curation` (the old key is still read) |
+| `.devflow/learning/` | `.devflow/curation/` |
+| `learning.json` (in the project folder and in `~/.devflow/`) | `curation.json` |
+| Settings line field `LEARNING=` | `CURATION=` |
+| Prompt markers `<!-- learning:on -->` and the build output `dist/learning-off/` | `<!-- curation:on -->` and `dist/curation-off/` |
+| HUD label `Learning:` | `Curation:` |
+| Session start headers `--- LEARNING MAINTENANCE ---` and `--- LEARNING PAUSED ---` | `--- CURATION MAINTENANCE ---` and `--- CURATION PAUSED ---` |
+| Hook files `learning-lock` and `lib/learning-store.cjs` | `curation-lock` and `lib/curation-store.cjs` (init removes the old files) |
+
+These names do not change: the `self-learning:` source stamp in rendered rows, the design-decision IDs,
+the `decisions-*.jsonl` files, the `apply-decisions` skill, the learn-conventions family and the
+`agents.learning.model` key (it stays an older name for the Curate agent model).
+
+**Breaking change:**
+- `devflow learning`, `devflow init --learning` and `devflow init --no-learning` now fail.
+  They give the unknown command or option error, and the exit code is 1.
+- Change every script, alias and note that uses an old name.
+
+**What the migration does:**
+- `devflow init` moves the learning data of each project that it finds, and of the project where you run it.
+  The move takes the ledger files, the queue and the project tuning file. Entry IDs do not change.
+  Devflow renders the index again at the new path.
+- Init also renames `~/.devflow/learning.json` to `curation.json`.
+  If both names exist, the new one wins, the old one stays, and init logs one line.
+- The session start hook makes the same move for the project of each session.
+  It also runs when the curation switch is off.
+- If a project already has both folders, one rule decides which folder stays.
+  If `.devflow/curation/` has a non-empty log, it wins and the old folder becomes the backup.
+  If not, the old ledger set moves in and the rest of the old folder becomes the backup.
+  Devflow never merges one ledger into the other.
+- After an upgrade, the first `devflow` command that loads the whole manifest
+  (for example `devflow init` or `devflow flags --status`) heals `~/.devflow/manifest.json`.
+  The file then carries both `features.curation` and `features.learning` with the same value.
+  Every later write keeps the two keys equal.
+  The `--status` commands of curation, memory, knowledge and gates write nothing.
+
+**Upgrade, downgrade and re-upgrade:**
+- Upgrade: run `devflow init` (a full init, not `--hud-only`). Until you do, the installed prompts and agents are still the old version.
+  `devflow init --hud-only` and a plugin-only update install the new hooks and settings script, but not the new prompts.
+  The old prompts do not accept the `CURATION=` field, so they use their fail-closed settings until you run a full `devflow init`.
+- Downgrade to 3.7: 3.7 does not read `.devflow/curation/`. It starts a new empty ledger in `.devflow/learning/`.
+  Your moved data stays in `.devflow/curation/`. The mirror key `features.learning` keeps a 3.8 opt-out in force.
+- Re-upgrade to 3.8: the next init or session start finds both folders and applies the rule above.
+  When the folder `.devflow/curation/` has a non-empty log, it wins.
+  The queue rows of the 3.7 folder merge into the winner. The entries that 3.7 wrote stay in the backup only.
+- The Curate model in the global tuning file: init renames `~/.devflow/learning.json` to `~/.devflow/curation.json`,
+  and 3.7 reads only the old name. After a downgrade, set the Curate model again with `devflow learning --configure`.
+  Choose the global scope. On re-upgrade, an existing `curation.json` wins and init logs one line.
+  To keep a value that you set on 3.7, delete `curation.json` first.
+
+**The machine switch:**
+- If `features.curation` and `features.learning` in the manifest disagree, the switch is off.
+  A reader never treats a disagreement as on.
+- To turn it on again, run `devflow curation --enable`. This writes both keys.
+- A 3.7 toggle writes only the old key. An opt-out made on 3.7 stays in force after you upgrade again.
+  If you ran no 3.7 `devflow init`, an enable made on 3.7 after a 3.8 disable stays off until you run `devflow curation --enable`.
+- A 3.7 `devflow init` removes the key `features.curation`. After that, only the old key carries the opt-out.
+  A 3.7 enable made after that init then takes effect when you upgrade again.
+- Between the package update and `devflow init`, `devflow curation --enable` and `--disable` write both keys
+  and move nothing. Only `--disable` drains the queue among these toggles. The commands `--restore`, `--clear`, `--reset`
+  and `--configure` (project scope) refuse until you run `devflow init`.
+
+**The backup:**
+- Where: `.devflow/learning.backup-<stamp>-<8 hex>` in the project, one folder for each move.
+  A move makes a backup only where a project had both folders.
+- No devflow command deletes a backup, except `devflow uninstall`.
+  Uninstall removes the backups of the project at the git root of your current directory, with that project's data, after you confirm.
+  `devflow curation --reset` and `devflow curation --clear` leave the backup in place.
+- A disable drains the queue files in the backups. `devflow curation --disable`, and `devflow init` with curation switched off,
+  remove the queue, claim, private and overflow files in each backup folder (at most 500 folders, and 200 files in each).
+  The ledger files, the swept files and the claim owner file stay in the backup.
+  Without this drain, a later `--enable` and init would merge those rows into the live queue.
+  The drain deletes nothing when a backup folder, or one of its queue files, is a symbolic link, and it says so.
+  The drain also deletes nothing when git tracks any entry under a data folder or a backup folder, or when a `.git` entry stands and git does not answer.
+  It then prints the notice that the git check shows (see Outcomes that need action).
+  If the backups cannot be listed for another reason, the drain still removes the queue files of the live and the old folder, and prints a warning that the backups were not drained.
+- `devflow curation --status` prints one `Backup:` line for each backup folder.
+  The line shows how many pending rows the backup still holds.
+  For the first 50 folders it prints one line each. One more line counts the folders from the 51st to the 500th and their pending rows.
+  If there are more than 500 backup folders, a last line counts the folders after the 500th. Status does not read them, and no init or drain reaches them.
+- Delete a backup folder only when `devflow curation --status` shows 0 pending rows for it.
+  Until then, a later init can still merge the rows.
+  A backup made on re-upgrade can hold the only copy of entries that 3.7 wrote. Check them before you delete it.
+- An init merges rows from at most 50 backup folders in one run. It passes over a folder that holds no pending rows,
+  so a later folder is reached when the earlier ones are done.
+
+**The queue cap:**
+- A merge fills a pending queue up to 100 lines and no further.
+  A capture trim keeps the newest 100 lines and starts only above 200 lines, so a merge never causes a trim.
+- Rows that do not fit wait in overflow files in the backup. A later init merges them as room appears.
+  Status counts them as pending rows, so the delete step waits for zero pending rows.
+- The move drops no row, and it never causes a trim.
+  A queue that holds more than 200 lines is still trimmed to its newest 100 lines when a capture arrives.
+  This is the rule from before 3.8.0, and the move does not change it.
+- `devflow init` drains the queue of a project where curation is off, as it did before 3.8.0.
+
+**Outcomes that need action:**
+- Busy: another run holds the move lock. Init prints `Ledger move skipped for <root>: a lock is held.`
+  A curation command prints `Another run is moving this project's curation data.`
+  Nothing is written. Wait a moment, then run the command again. A session start retries by itself.
+  When a queue claim holds the move, init prints `Ledger move skipped for <root>: a queue claim holds the move.`
+  A curation command prints `A Curate run holds this project's curation queue, and the move waits for it.`
+  The move runs after Curate finishes, which can take up to 15 minutes. Run the command again after that.
+- Refused: a symbolic link sits on the path, or a private, swept or overflow queue file sits directly in the old folder.
+  Nothing moves. Init prints `Ledger move refused for <root>`.
+  The HUD and `devflow curation --status` print `Curation: move refused, see the hook log`.
+  Remove the cause, then run `devflow init` or start a new session.
+- Skipped by the git check: git tracks any entry under `.devflow/learning/`, `.devflow/curation/` or a backup folder
+  (`.devflow/learning.backup-*`), or tracks an entry named `.devflow` ([#598](https://github.com/dean0x/devflow/issues/598)). The same outcome applies when a `.git` entry stands and git does not answer.
+  Nothing in the project changes. Init prints `Ledger move skipped for <root>` and a fixed notice that holds nothing from the repository.
+  The HUD prints `Curation: move skipped, git tracks files in the .devflow data folders`
+  or `Curation: move skipped, git did not answer`.
+  `devflow curation --status`, `--list` and `--show` print the whole notice. The HUD and these commands print the skip also when `.devflow/curation/` exists.
+  While the old folder is there, `--restore`, `--clear`, `--reset` and `--configure` (project scope) print the notice, change nothing and exit 1.
+  `--enable` and `--disable` print the notice as a warning, and their exit code does not change.
+  `--disable`, `--clear` and an init with curation off delete no queue file in these cases, and each prints the notice once.
+  When init has printed the notice in its `Ledger move skipped for <root>` line, its drain adds only `The curation queue was not drained.`
+  When git tracks files, the notice tells you to run `git ls-files .devflow`, and then `git rm --cached <file>`, in the checkout that holds the folders.
+  When git does not answer, the notice tells you to check that git runs in the project. The move runs again at the next session start or the next init.
+  A session start runs the check again in both cases.
+- Not yet moved: `devflow curation --status`, `--list`, `--show` and the HUD print
+  `Curation: run devflow init, or open Claude Code in this project after it`.
+  They do not read the old folder.
+- Failed: init prints `Ledger move failed for <root>` and copies nothing. The next init tries again.
+  A move that fails at session start shows the same `Curation: move refused, see the hook log` line as a refusal.
+  The hook log names the cause. The next session start tries again.
+- Skipped, no repository: git did not name the project's repository within one second, for example on a hung mount.
+  Init prints `Ledger move skipped for <root>: git did not answer in time.` and does not count the project as moved.
+  The other projects move. The next init tries again, and a session start in the project moves it too.
+
+**What stays behind:**
+- Reach: a project that neither `devflow init` nor a Claude Code session reaches keeps its old
+  `.devflow/learning/` folder untouched. It moves at its next session start.
+- Linked worktrees: if the main checkout has a `.devflow/` folder and is not your home folder,
+  the ledger of a linked worktree is the ledger of the main checkout.
+  Devflow does not move a `.devflow/learning/` folder that sits inside that worktree.
+  Delete that leftover folder by hand when you do not need it.
+  If the main checkout does not meet this condition, the `.devflow/learning/` folder of the worktree is a live ledger.
+  It moves like any project.
+- First session: the first session start in a project with an old folder runs the move.
+  This adds a short delay to that one start. Later starts add nothing.
+
+**Mixed-version teams:**
+- A 3.7 install reads only `features.learning` in a committed `.devflow/project.json`.
+  A 3.8 install reads both keys and narrows when either key is `false`.
+- Keep the old key in committed files, or set both keys, until every team member runs 3.8.
+
+### Upgrade notes — Lint pack
+
+**Stale-install window:**
+- Until you run `devflow init`, the installed `/implement` and Validate do not run the lint pack.
+
+### Upgrade notes — Base resolver
+
+The base resolver ([#495](https://github.com/dean0x/devflow/issues/495)) adds stops and a script call.
+Do the step below after you update.
+
+**What you must do:**
+- Run `devflow init` after you update. A full init installs `resolve-base.cjs` and the updated commands.
+
+**Stops:**
+- `/implement` stops when no usable base exists, for example in a shallow clone without the base history. `/code-review` and `/bug-analysis` stop in that case on a full-range run. The message names the cause and the fix: `git fetch --unshallow`, `git fetch origin <base>`, or a re-run (and `devflow init` if the re-run repeats the stop).
+- The same three commands stop on a base branch name outside the allowed set, or one that git refuses. The message states the set.
+- In `/code-review` multi-worktree mode, a rejected base blocks only that worktree.
+- `/code-review` and `/bug-analysis` stop when the branch name does not fit the allowed characters and length. The message states the allowed characters. In `/code-review` multi-worktree mode, this blocks only that worktree.
+- The Git agent's `validate-branch` returns BLOCKED in the same cases. `/resolve` takes its branch diff from it.
+- The Git agent's `ensure-pr-ready` stops only on a base name outside the allowed set, or one that git refuses. For any other base stop it prints `TRACEABILITY: DEGRADED (base {REASON}; fix: {fix})` and goes on.
+- `/dynamic-build`: a ticket whose setup reports no base commit stops with the `base-missing` escalation. Check the setup output, then re-run.
+
+**New resolver call:**
+- `ensure-pr-ready` calls `resolve-base.cjs` in `pr` mode with the base branch of the PR, or with the default branch when no PR applies. The call makes at most one fetch of the base branch.
+- `/implement` passes the base ref that it resolved in Phase 1, so a normal `/implement` run makes one fetch.
+- The `/dynamic-build` wave PR step runs `ensure-pr-ready` with no base ref, so that step makes this call.
+- The base resolver reads the base name from standard input (`--name-stdin`), so the name is not part of shell command text ([#561](https://github.com/dean0x/devflow/issues/561)).
+- The Git agent's `ensure-pr-ready` and `validate-branch` write the base name to a file. The step checks the status of both `gh` calls. It treats `gh` as failed when either status is not 0.
+- In `ensure-pr-ready` and `validate-branch`, a name file whose only content is an empty line counts as empty. The default-branch path then takes `main`, or else `master`.
+- `validate-branch` takes the default branch as the base when no PR applies: the branch has none, `gh` is missing or logged out, or the repository has no GitHub remote.
+
+**Stale-install window:**
+- Until you run `devflow init`, the installed commands and Git agent do not call the resolver.
+
+**Known limits:**
+- A fetch that stops at its 45-second bound can leave a `refs/remotes/origin/<name>.lock` file in the git directory. Later runs then report `fetch-failed` until you delete the file.
+- The fetch needs git 2.29 or newer. With an older git, every run reports `fetch-failed` and prints the base warning.
+- The fetch runs no askpass program. Where an askpass program is the only credential source, a remote that needs credentials gives `fetch-failed` on every run, with the base warning.
+
+### Upgrade notes — Review markers
+
+**What changes:**
+- Incremental review and analysis markers are stored under the git directory of each worktree; the first run after the update covers the full branch.
+
+### Upgrade notes — Review ranges
+
+**What changes:**
+- `/dynamic-build`: in single-ticket mode, the review covers the diff from the commit the ticket branch was forked from to HEAD. On a non-default start branch, that is the ticket's own commits.
+- `/dynamic-build`: the wave evidence step lists the changed files with a diff from the base ref of the wave PR. The base ref must be a commit ID of 40 or 64 lowercase hex digits, and the diff must exit 0. If not, the step is skipped, and the run summary holds `TRACEABILITY: DEGRADED (wave base unusable)`.
+- A Review agent with no patch file and no usable diff range returns `reviewed: false`. After one retry, the engine records a coverage gap, and the run verdict is never PASS.
+
+### Upgrade notes — Level readers
+
+**Stale-install window:**
+- If an installed `/implement` or `/resolve` is newer than its installed level reference, the reference stays unreadable until you run `devflow init`.
+
+### Upgrade notes — Polish by level
+
+**What you must do:**
+- The default level, `standard`, now skips Polish in `/implement` and `/resolve`. Run `devflow gates --set full` to keep Polish.
+- A quality rule that you keep at `~/.devflow/rules/quality.md` replaces the shipped one. At `standard` and `lean`, you then lose Polish and do not get the new bullet. Add the bullet to your copy. Or run `devflow rules unshadow quality`, which deletes your copy, and then run `devflow init`.
+
+**Stale-install window:**
+- Until you run `devflow init`, your install has no level row that skips Polish, so Polish still runs at every level. An install from 3.7.0 has no level reference at all. The installed quality rule also lacks its new bullet.
+
+### Upgrade notes — Harden by level
+
+**What you must do:**
+- At `lean`, `/implement` now skips Harden on a docs-only diff. Run `devflow gates --set standard` or `--set full` to keep Harden on every diff.
+
+**Stale-install window:**
+- Until you run `devflow init`, your installed level reference has no Harden row, so Harden runs at every level.
+
+### Added
+
+- **`devflow init` asks for the gate level** ([#543](https://github.com/dean0x/devflow/issues/543), [#507](https://github.com/dean0x/devflow/issues/507)).
+  - `devflow gates --set <level>` and `devflow init` set the machine gate level, so a user who runs `init` learns that the level exists.
+    An interactive `init` asks for it: `full`, `standard` or `lean`, each with a one-line effect.
+    On a first install the prompt starts on `standard`.
+    On a re-init it shows the current value and starts on it, so Enter keeps a valid level.
+    A malformed or `null` stored value starts the prompt on `full`, and if you accept it, init writes `full` in its place. The machine level that applies does not change.
+  - `devflow init --gate-level <full|standard|lean>` sets the machine level with no prompt, in an interactive or a non-interactive run.
+    A bad value, or no value, exits 1 before `init` writes anything and names the valid levels. The flag cannot be combined with `--hud-only`.
+    `devflow init --recommended` and a non-interactive `init` show no prompt and keep the stored value.
+  - The Recommended settings note has a `Gate level:` row.
+    The summary at the end of `init` shows the level that is set, and adds `(was X)` when the run changes the machine level that applies.
+    `init` writes the same machine default as `devflow gates --set`, and a personal `gateLevel` in a repository's `.devflow/config.json` still wins there.
+  - If `~/.devflow/manifest.json` is valid JSON with a `features` object that devflow rejects (a field is missing or mistyped, or a byte-order mark leads), a promptless `init` and `init --hud-only` keep the gate level stored in it, as it is stored, and warn that they kept the level while they replaced the file.
+    When the prompt runs, your answer is the level. If you accept a malformed or `null` value, init writes `full`.
+  - If the manifest is corrupt, is not JSON, has no `features` object, or is over 1 MiB and also one that devflow rejects, `init` cannot read the level.
+    The prompt shows `Current setting: unknown` and starts on `standard`.
+    A promptless `init` or `init --hud-only` records no level and warns that `standard` applies and that `devflow gates --set <level>` sets it again.
+    `devflow gates --status` words its manifest warning for each case.
+  - `devflow init --reset` removes the stored level, and over a rejected manifest the summary names the level it removed, as in `(was full)`.
+    A bare `devflow gates --set` names the levels in its error, as `devflow init --gate-level` does.
+- **A lint pack template, and a lean lint pack in Validate** ([#475](https://github.com/dean0x/devflow/issues/475)).
+  - The package ships a template in `templates/lint-pack/`: a script, an example config and a README.
+    You copy it into your repository and own the copy.
+    devflow does not install, update or run the template itself.
+  - At `lean`, Phase 6 of `/implement` has Validate run your root `lint-pack` script last, after the build, typecheck, lint and test commands pass.
+    Validate finds it as a `package.json` script, else as a `Makefile` target.
+    The script reads the lines the branch changed.
+    It finds a removed flag that a doc still names, a plan ID or a tombstone phrase in new text, and an oversized function (through your own linter).
+    A match fails validation and reaches Fix as a file and line reference.
+  - Fix does not edit the lint pack, its config, its build-file entry or any `.gitattributes` to clear a match.
+    Fix does not silence the linter to clear a match, with a disable comment or a linter-config change.
+    It reports the match under Blockers.
+    To clear a match that you judge false, add an allow glob to `.lint-pack.conf`, commit it, and ask `/implement` to re-validate.
+  - A pack error does not change the validation result.
+    A git older than 2.30, a config that the script cannot read, a linter that did not run and a run that a timeout stops are pack errors, never a clean run.
+    A pack error reads `UNVERIFIED` in the `/implement` final report and in the Testing part of the PR body.
+    The pack also prints a `pack-changed` line for a changed build-file line in the compared range that names `lint-pack` or `BASE`, a `pack-dirty` line for an uncommitted change to a pack file, and the base it compared.
+    Known limit: the pack prints the base it compared (`base <sha>`), but Validate does not check that base yet, and issue [#537](https://github.com/dean0x/devflow/issues/537) adds that check.
+    If the project has no `lint-pack` script or target, Validate prints one "not configured" line.
+  - The re-validation that you ask `/implement` for runs the pack.
+    The re-validation after QA fixes, `/resolve`, `/self-review`, `/release` and `/dynamic-build` do not run it, and no level below `lean` runs it.
+
+### Changed
+
+- **`/implement` skips Harden at `lean` on a docs-only diff** ([#482](https://github.com/dean0x/devflow/issues/482)). At `lean`, `/implement` skips Phase 4 Harden when the diff is docs-only. The decision reads path names only. It reads no diff content and runs no detection script. Harden is skipped only when all of these hold: the compliance lens is exactly `off`; the branch diff list is not empty; no Code report names a deleted, renamed or moved path; and every changed path is the root `README.md`, the root `CHANGELOG.md` or a `.md` file under the root `docs/`. A path on that list has no segment that starts with a dot, no double quote in its name and no file name that agents load as instructions, in any letter case. No loaded instruction, rules or imported file names the path. A tests-only diff runs Harden. When the decision is unclear, Harden runs. The run report says `Harden: ran` or `Harden: SKIPPED (docs-only diff)` at `lean` only. `full` and `standard` do not change. When Harden runs, it reads the whole branch diff. `/code-review` security runs at every level. The README, the CLI reference and the command reference state the rule. Known limits at `lean` on a docs-only diff: stub and wiring detection does not run; the pitfall check of public text in README and CHANGELOG does not run; a path that only a not-yet-loaded instruction file, such as a nested one, names is not seen; and Harden does not review a delete or a rename that no Code report names ([#571](https://github.com/dean0x/devflow/issues/571)). The docs-only check reads path names. It does not look at symlinks, file-type changes, or docs files that a site generator compiles. Run `devflow gates --set standard` or `--set full` to keep Harden on every diff.
+- **`/implement` and `/resolve` skip Polish at `standard` and `lean`** ([#481](https://github.com/dean0x/devflow/issues/481)).
+  - At `standard` and `lean`, `/implement` skips Phase 3 Polish, and `/resolve` skips Phase 6 Polish in each worktree at that level.
+    At `full`, both spawn Polish.
+    `/self-review`, `/debug` and `/dynamic-build` keep Polish at every level and read no level.
+    Harden still reads the whole branch diff, and Validate does not depend on Polish.
+  - The quality rule has one bullet that holds a subset of Polish's cleanup list: leftover debug statements, unused imports, unnecessary variables used once right after assignment, nested ternaries, checks the types enforce and catches around code that cannot throw.
+    The bullet cuts debug statements everywhere, but it keeps checks and catches at a trust boundary or a fail-closed path.
+    The Code agent applies it while it writes.
+    At `full` and `standard`, `/code-review` can report these items.
+    `devflow gates`, the `devflow init` level hints, the README, `docs/cli-reference.md` and `docs/commands.md` state the effect.
+  - Accepted risk: at `standard` and `lean`, no `/implement` agent grades naming and consistency, and Harden reports both as `SKIP (Polish agent)`.
+    No rule holds two other Polish items: language-behavior tests and verbose names.
+    Harden's test pillar partly covers language-behavior tests.
+  - At `standard` and `lean`, `/resolve` skips Polish and never spawns Harden, so debug statements in its fixes that hold no secret or token get no later pass beyond the quality rule and the review.
+    At `lean`, `/code-review` does not report the cleanup items.
+    Ticket [#568](https://github.com/dean0x/devflow/issues/568) tracks the Harden wording.
+    Run `devflow gates --set full` to keep Polish.
+- **`/implement` and `/resolve` read the gate level** ([#480](https://github.com/dean0x/devflow/issues/480)).
+  - At `standard` and `lean`, each command reads its level reference one time for each run. At `full`, it reads no reference.
+    `/implement` reads it at the start of Phase 3.
+    `/resolve` reads it in Step 0d when any worktree is at `standard` or `lean`.
+    The references hold the phase rows, and the [#481](https://github.com/dean0x/devflow/issues/481) entry lists the rows that this release adds.
+  - The `/implement` report and the `/resolve` display name the level at every level.
+    `/resolve` also names it in `resolution-summary.md`.
+    `devflow gates` says that `/implement` and `/resolve` read the level.
+  - If a reference cannot be read, the command says `level reference unreadable: no level rows applied`.
+    It applies no row and keeps the level, so at `lean` the lint pack still runs.
+  - No level removes Validate, the CI gate, the evidence claims, the Verification Gate or the compliance directive.
+    No level changes the Triage security gate or the ESCALATED route.
+- **Code, Fix and Refactor check the staged diff for secrets or tokens in logs or debug output before each commit** ([#584](https://github.com/dean0x/devflow/issues/584)).
+  - Each of these agents checks the staged diff of every file it commits.
+    The check runs at every level, wherever `/resolve`, `/implement`, `/debug`, `/dynamic-build` (and dynamic workflows that spawn them) or ambient mode spawn these agents.
+    Run `devflow init` to install the updated agents.
+- **`/implement`, `/code-review`, `/bug-analysis` and `/resolve` check branch names against an allowed set** ([#495](https://github.com/dean0x/devflow/issues/495)).
+  - A base branch name outside the allowed set, or one that git refuses, stops the run. The message states the set.
+    In `/code-review` multi-worktree mode, a rejected base blocks only that worktree.
+  - An incremental `/code-review` or `/bug-analysis` run takes the full range when it cannot use the stored review head.
+    A failed patch write in `/code-review` stops the run.
+
+### Fixed
+
+- **`/implement`, `/code-review`, `/bug-analysis` and `/resolve` use a fresh base for branch diffs** ([#495](https://github.com/dean0x/devflow/issues/495)).
+  - A new script, `resolve-base.cjs`, makes at most one fetch of the base branch, picks the base by one stated rule and prints one status line.
+    The fetch updates only the remote-tracking ref of the base branch, and credential prompts are off for it.
+    The branch diff starts at the fork point of that base and `HEAD`.
+  - The fetch stops after 45 seconds, each local git call stops after 30 seconds, and one run has a budget of 100 seconds.
+    A local git call that gives no answer reports `resolver-unavailable`.
+    A normal `/implement` run fetches the base branch once, and a re-validation that you ask for can add one more fetch.
+  - When the fetch fails or times out, `/implement`, `/code-review` and `/bug-analysis` use the best base they have and print a warning.
+    Known limit: `/resolve` uses that base without a warning.
+  - When no usable base exists, for example in a shallow clone without the base history, `/implement` stops, and `/code-review` and `/bug-analysis` stop on a full-range run.
+    Each names the cause and a fix.
+    `/resolve` takes its branch diff from the Git agent's `validate-branch`, which returns BLOCKED in that case.
+  - Run `devflow init` after you update, to install the script and the updated commands.
+- **SessionStart loads the current working memory once** ([#591](https://github.com/dean0x/devflow/issues/591)).
+  - It does not load pre-compaction memory snapshots, also when a snapshot is newer or the current memory is missing.
+  - SessionStart does not delete or move the existing `backup.json` file. The next PreCompact writes it again with Git state only.
+
+---
+
+## [3.7.0] - 2026-10-16
+
+### Upgrade notes — Gate level
+
+The settings line has a new last field for the gate level ([#472](https://github.com/dean0x/devflow/issues/472)).
+Do the step below after you update.
+
+**What you must do:**
+- Run `devflow init` after you update. A full init installs the commands that accept the new settings line.
+- After `devflow init`, a user with no level gets `standard` in `/code-review`: no TypeScript focus, and no Dependencies focus on a code diff that changes no dependency manifest. Run `devflow gates --set full` to keep today's set.
+- A user with no level also gets the lean `/plan`: fewer agents, while the security gap analysis and the design review still run. Run `devflow gates --set full` to keep the full `/plan`.
+
+**Stale-install window:**
+- The settings line now ends with `GATE_LEVEL=<full|standard|lean>`. An installed command from an
+  older version accepts only the old fields, so it does not accept the longer line.
+- `devflow init --hud-only` and a plugin-only update refresh the resolver script. They do not
+  refresh the installed prompts.
+- Until you run a full `devflow init`, every installed command uses its fail-closed settings value.
+- Until you run `devflow init`, the installed `/code-review` and `/plan` ignore the level.
+
+**Known limits:**
+- A corrupt manifest, or one over 1 MiB, reads as the `standard` level. `devflow gates --status`
+  warns that `devflow init` will replace the file.
+- `devflow init` still overwrites a corrupt or rejected manifest. The stored level is lost with it.
+- Two commands that write the manifest at the same moment can lose one update.
+- There is no team floor. A repository that declares compliance can run a lower personal level.
+  `/code-review` and `/plan` read the level, so a personal `lean` level narrows the review and the
+  planning run even where compliance is declared. The Compliance focus still runs on its trigger,
+  and in `/plan` the security gap focus and the design review run at every level.
+  Issue [#488](https://github.com/dean0x/devflow/issues/488) (the compliance lens as a floor on
+  the level) is open.
+
+### Upgrade notes — Working memory
+
+The memory worker's write is limited to its staged file. Read the items below after you update.
+
+**What you must do:**
+- Update Claude Code to 2.1.269 or newer. On an older version, working memory does not update and Claude Code shows no message. The worker log has one line that says why.
+- If a worker `env` value lives only in your project or local Claude Code settings, move it to your user settings file. The worker loads only the user settings.
+
+**Your own settings:**
+- Allow rules in your own Claude Code settings also apply to the worker's run. A user-level Edit allow rule that covers other paths covers the worker too.
+
+**Known limits:**
+- A project path that contains any of `* ? [ ] \ " { }` or a control character gets no working-memory updates. The permission rule carries the path without quoting. The worker skips the project, logs the reason and shows one message at session start. Parentheses and spaces in the path are carried as they are.
+
+### Added
+
+- **A gate level on the settings line, and the `devflow gates` command** ([#472](https://github.com/dean0x/devflow/issues/472)). The settings line ends with `GATE_LEVEL=<full|standard|lean>`. The level comes from a personal `gateLevel` key in `.devflow/config.json`, then from the machine default `features.gateLevel` in `~/.devflow/manifest.json`, then from `standard`. The personal key may raise or lower the level. It is not a narrow-only switch, and a later change can make it narrow-only. A `gateLevel` in `project.json` is ignored, and no command writes the personal key. A malformed value reads as `full`. `devflow gates --set <level>` writes the machine default and nothing else. `devflow gates --status` shows the level in effect, the layer that decided it and the machine default. `/code-review` reads the level ([#474](https://github.com/dean0x/devflow/issues/474)) and so does `/plan` ([#473](https://github.com/dean0x/devflow/issues/473)); [#480](https://github.com/dean0x/devflow/issues/480) adds more readers.
+- **`devflow init --hud-only` prints a line when the installed prompts come from another devflow version** ([#472](https://github.com/dean0x/devflow/issues/472)). It tells you to run `devflow init`.
+- **A message at session start when working memory stops for a cause you can fix.** If the worker cannot write its staged file at the project path (for example, a path with a character the permission rule cannot carry), or Claude Code refuses the worker's write in two runs with no successful update between them, the next session start shows one message that points to the log. Each cause is shown once.
+
+### Changed
+
+- **`/code-review` picks its focus set by gate level** ([#474](https://github.com/dean0x/devflow/issues/474)). `full` runs every focus, as before. `standard`, the default, drops TypeScript, and drops Dependencies on a code diff that changes no dependency manifest (a lockfile alone does not count). `lean` runs Security, Testing and Reliability on a code diff. The Compliance focus keeps its own trigger at every level. A docs-only, tests-only or lockfile-only diff keeps its reduced set, and at `lean` a tests-only diff drops Consistency. A mixed non-code diff runs the union of its classes' sets. Security runs at every level and in every class. `/code-review` reads a new level reference only at `standard` or `lean`. If it cannot read the reference, it says so and runs the full sets. The review summary now shows the gate level and the focuses, and a review with no security report gives CHANGES REQUESTED.
+- **`/plan` runs a lean shape at `standard` and `lean`** ([#473](https://github.com/dean0x/devflow/issues/473)). `full` runs the phases as before. `standard`, the default, and `lean` run one Explore round of two agents (three for several issues), or none when a `/research` report from the same conversation covers the scope; no Synthesize step; two gap-analysis agents, one for security and one for completeness, architecture and performance (plus consistency and dependencies for several issues); one Plan agent; and the design review. The security gap agent and the design review run at every level, the Compliance agent keeps its own trigger, and Gates 0, 1 and 2 run at every level. Every agent spawn in `/plan` names its agent type; the planning spawns use Claude Code's built-in `Plan` agent. If `/plan` cannot read its level reference, it says so and runs the full shape. The run report names the gate level. Run `devflow gates --set full` to keep the full shape.
+- **`/implement` splits long plans into sequential Code phases; a run with no plan stays single** ([#452](https://github.com/dean0x/devflow/issues/452)).
+- **Code agents read large files once, by range, and cap printed output** ([#452](https://github.com/dean0x/devflow/issues/452)).
+- **Polish, Harden, Evaluate and Test get the full branch diff as `FILES_CHANGED`** ([#452](https://github.com/dean0x/devflow/issues/452)).
+- **`/implement` stops when the base branch name has a character outside ASCII letters, digits and `._/+@,#-`, or is longer than 200** ([#452](https://github.com/dean0x/devflow/issues/452)). The check also covers the re-validation path. Git accepts some refused names, such as `café`. For them, `/implement` stops and tells the user which characters are allowed.
+- **The token audit counts files written through Bash** ([#442](https://github.com/dean0x/devflow/issues/442)).
+- **The memory worker's write is limited to its staged file.** The `claude -p` run loads only your own Claude Code settings plus two permission rules, an allow rule for `.devflow/memory/WORKING-MEMORY.md.new` and a deny rule for every path under it, and a permission mode that refuses every call that no allow rule covers. Allow rules in your own Claude Code settings also apply to the run, so a user-level Edit allow rule that covers other paths covers the worker too. A folder or a link at the staged path is removed by one guarded delete of exactly that path; when it cannot be removed, the run fails and removes nothing. The worker ignores a project's or a local Claude Code settings file.
+- **Working memory needs Claude Code 2.1.269 or newer.** `devflow init` states the version at its working-memory step. On an older Claude Code the worker does not run, keeps the queue and writes one log line that says why, so working memory does not update until you update Claude Code.
+- **The memory log gets one `Run:` line for each worker run.** `.background-memory-update.log` under `~/.devflow/logs/`, in the folder for the session that ran the worker (`<session-directory-slug>`), ends every run with `Run: cli=<version|unknown> argv=<lean|legacy|none> result=<updated|conflict|failed|skip|below-floor> denials=<count|unknown|n/a> removed=<none|dir|link>`. `cli=unknown` means the worker read no version, `denials=unknown` means the result reported no count, and `denials=n/a` means no run started. A below-floor line adds `floor=<version>`. The line holds keywords and digits only, never turn or prompt text.
+- **A project inside a `.git` folder gets no working-memory update.** The worker skips it, logs the reason and shows the path message once at session start. A checkout under `.claude/worktrees` is updated like any other checkout.
+- **PR links and `/dynamic-build` ticket branches follow stricter rules** ([#486](https://github.com/dean0x/devflow/issues/486)). `/implement` prints `TRACEABILITY: DEGRADED (ambiguous issue reference)` when it has an issue number and no link line. `/code-review` and `/bug-analysis` PRs no longer get a closing line from the branch name. A PR body has no `## Related Issues` heading when neither an issue number nor a link line is given. In a `/dynamic-build` wave, the ticket branch must be a local branch name that passes the allowlist. A name with a leading `#` or `-`, a revision name such as `HEAD`, a tag and a SHA are all refused, and the ticket is quarantined. The wave aborts the merge only when the merge began. On Jira and Linear, the PR link line always uses the default reference form (`Refs {KEY}-{n}`). A custom `## Reference Rendering` section no longer shapes that line. It still shapes the release Shipped Issues section. Follow-up [#511](https://github.com/dean0x/devflow/issues/511) tracks applying it to the PR link line.
+
+### Fixed
+
+- **Prompts resolve the Claude config directory with the same rule as the installer** ([#517](https://github.com/dean0x/devflow/pull/517)). `CLAUDE_CONFIG_DIR` applies when it is an absolute path, else `~/.claude`.
+- **A tracked `.devflow/config.json` no longer applies as personal config** ([#489](https://github.com/dean0x/devflow/pull/489)). devflow ignores it and shows a warning.
+- **`/dynamic-build` wave merges are safer, and a supplied PR link line is used as given** ([#486](https://github.com/dean0x/devflow/issues/486)). A wave merge uses `git merge --no-ff` and records the pre-merge SHA. The ticket branch name is checked before the merge, and a refused name quarantines that ticket. The wave halts when the merge or base SHA is not valid. A ticket whose branch adds no commit stops the wave before the post-merge build, and no wave PR opens. A merge whose post-merge build fails is undone by a reset to the recorded SHA. The run summary names why the wave halted. A PR gets no closing reference from a bare number or the branch name.
+- **Model discovery waits up to 6 s for the routing runtime** ([#519](https://github.com/dean0x/devflow/pull/519)). The wait was 2 s. On a loaded machine, the first start of node with the routing runtime can take more than 2 s. The agents TUI then reported an installed runtime as unknown. `devflow proxy --enable` then did not refresh the model cache. A runtime that does not answer within 6 s still falls back to the stale cache.
+- **The memory worker keeps the queue when it finds neither jq nor node** ([#523](https://github.com/dean0x/devflow/issues/523)). The hooks that start the worker already stop without a parser. A worker that ran with a different PATH deleted the queued turns. Now the worker stops before it reads the queue, and the queue stays for the next run. A parser that exits with an error also leaves the queue and the batch in place, and a queue that cannot be added to a leftover batch stays in its file.
+- **A malformed queue line no longer stops the worker from reading the other lines** ([#528](https://github.com/dean0x/devflow/issues/528)). With jq, the worker read the queue as one stream, so one malformed line stopped the parse. The valid turns after it were lost, or the whole batch was deleted. Now the worker reads each line alone, skips only the malformed line, and logs how many lines in the read window it skipped. A row cut off before its line break runs into the next row, so those two rows are one malformed line. Both parsers read a line as a turn only when its role is user, assistant or qa, so jq and node log the same skip count. A batch with no readable line is still removed.
+
+---
+
 ## [3.6.0] - 2026-10-14
 
 ### Upgrade notes — Agent rename (6 agents)
@@ -1673,7 +2108,9 @@ devflow init
 
 ---
 
-[Unreleased]: https://github.com/dean0x/devflow/compare/v2.0.0...HEAD
+[Unreleased]: https://github.com/dean0x/devflow/compare/v3.8.0...HEAD
+[3.8.0]: https://github.com/dean0x/devflow/compare/v3.7.0...v3.8.0
+[3.7.0]: https://github.com/dean0x/devflow/compare/v3.6.0...v3.7.0
 [3.6.0]: https://github.com/dean0x/devflow/compare/v3.5.0...v3.6.0
 [3.5.0]: https://github.com/dean0x/devflow/compare/v3.4.0...v3.5.0
 [3.4.0]: https://github.com/dean0x/devflow/compare/v3.3.0...v3.4.0

package/README.md

@@ -30,7 +30,7 @@ you: /implement (hand it the plan)
 
   Git                    branch feat/42-rate-limit-upload
   Code                   implements the plan — your learned decisions, pitfalls, and feature knowledge preloaded
-  Polish · Harden        cleanup pass, then 9-pillar quality gate
+  Polish · Harden        cleanup pass at full, then 9-pillar quality gate (lean: not on docs-only diffs)
   Evaluate               implementation matches the original request ✓
   Validate               build ✓ typecheck ✓ lint ✓ tests ✓
   Test                   5/5 QA scenarios pass
@@ -56,11 +56,11 @@ This is the **orchestrated flow** — you stay in the loop between every step. W
 
 **A staffed agent roster.** 20 specialized agents with explicit model assignments — Opus for analysis, Sonnet for execution, Haiku for I/O. Reassign any agent's model with `devflow agents`, including GPT models through external model routing (`devflow proxy`).
 
-**Up to 20 parallel Review agents.** Security, architecture, performance, complexity, consistency, regression, testing, and more. Each produces findings with severity, confidence scoring, and concrete fixes. Conditional Review agents activate when relevant (TypeScript for `.ts` files, database for schema changes, compliance when regulated surface detected in the diff). Every finding gets validated and resolved automatically.
+**Up to 20 parallel Review agents.** Security, architecture, performance, complexity, consistency, regression, testing, and more. Each produces findings with severity, confidence scoring, and concrete fixes. Conditional Review agents activate when relevant (language focuses such as TypeScript for `.ts` files, database for schema changes, compliance when regulated surface detected in the diff). The gate level narrows these sets: the default `standard` level drops the TypeScript focus, and `lean` runs fewer focuses still. Every finding gets validated and resolved automatically.
 
 **Memory that persists.** Session context survives restarts, `/clear`, and context compaction. Your agent picks up exactly where it left off.
 
-**Self learning.** A background agent detects architectural decisions and known pitfalls from your session dialogs and writes them to `.devflow/learning/decisions.md` and `.devflow/learning/pitfalls.md` — informing every future review and implementation session without any manual bookkeeping.
+**Decisions and pitfalls.** A background agent detects architectural decisions and known pitfalls from your session dialogs and writes them to `.devflow/curation/decisions.md` and `.devflow/curation/pitfalls.md` — informing every future review and implementation session without any manual bookkeeping.
 
 **Feature knowledge bases.** Curated `KNOWLEDGE.md` files per feature area — patterns, conventions, and gotchas — git-tracked and shared with your team. Planning, implementation, and review workflows load them automatically and refresh them after changes.
 
@@ -128,14 +128,14 @@ Graph runs trade tokens for autonomy: you make your calls at each wave's decisio
 npx devflow-kit init
 ```
 
-That's it. The interactive wizard offers Recommended defaults or an Advanced flow — plugin selection, feature configuration, compliance frameworks, and security settings. Ambient mode, working memory, and learning are on by default. Non-interactive: `npx devflow-kit init --recommended`.
+That's it. The interactive wizard offers Recommended defaults or an Advanced flow — plugin selection, feature configuration, compliance frameworks, the gate level, and security settings. Ambient mode, working memory, and curation are on by default. Non-interactive: `npx devflow-kit init --recommended`.
 
 ## Privacy & Sharing
 
 Everything Devflow generates lives under `.devflow/` — working memory, decisions and pitfalls, feature knowledge bases, naming conventions, docs and transient locks. On first use Devflow appends one block to your project's root `.gitignore`. It keeps per-developer runtime state on your machine and shares three things through git: the feature knowledge bases, the learned naming conventions and the team's settings in `.devflow/project.json`, which carry its [evidence policy](#evidence-policy):
 
 ```gitignore
-# Devflow runtime data — local by default (memory, learning, docs, locks).
+# Devflow runtime data — local by default (memory, curation, docs, locks).
 # Shared via git: feature knowledge bases under .devflow/features/ (index.md and
 # every {slug}/KNOWLEDGE.md), .devflow/conventions.md (naming authority),
 # .devflow/policy.json (retired; presence only) and .devflow/project.json (team settings).
@@ -188,19 +188,21 @@ A repository can commit `.devflow/project.json` to settle team-wide choices. Eve
 ```json
 {"version":1,"evidence":"required","compliance":["hipaa"],
  "tracker":{"provider":"jira","site":"https://acme.atlassian.net","key":"ACME"},
- "reviewPublication":"auto","features":{"learning":false}}
+ "reviewPublication":"auto","features":{"curation":false}}
 ```
 
 - `evidence` is the [evidence policy](#evidence-policy); `compliance` names the regulatory frameworks the repository answers to, and its presence raises the evidence floor to `required`.
 - `tracker` selects the repository's issue tracker. Your personal `.devflow/config.json` may only narrow it, to `github` or to the same provider.
 - `reviewPublication` is a ceiling only: it can lower your personal value, never raise it. With no personal value you get at most `auto` — a team `off` still lowers it — so a branch that commits `full` cannot switch off the visibility gate for whoever reviews it.
-- `features` can switch memory, learning or knowledge off for this repository, never back on. Your personal `config.json` can do the same for you.
+- `features` can switch memory, curation or knowledge off for this repository, never back on. Your personal `config.json` can do the same for you. The key is `features.curation`. Devflow 3.8 reads the old key `features.learning` too, and the repository turns the feature off when either key is `false`. A 3.7 install reads only `features.learning`. In a team with mixed versions, keep the old key in the committed file, or set both keys, until every member runs 3.8.
 
 **Adopting it.** Commit `project.json` on the default branch. `evidence` is always read from the default branch, so a feature branch cannot lower the bar it is judged by. Every other key — `tracker` with its `site` and `key`, `features` and the `reviewPublication` ceiling — is read from the branch you have checked out, so a branch that edits them sees the change at once. `compliance` is read from both and joined with your machine's frameworks: a branch can add a framework, never remove one, so a pull request that deletes `"compliance":["hipaa"]` is still reviewed under HIPAA. The default branch's copy is read from your clone's tracking branch, as fresh as your last fetch, never over the network, so a framework added on the default branch reaches the lens once your checkout has fetched it.
 
-Each key is checked on its own, so one bad value never disables the rest: a bad `evidence` resolves to `required`, a bad `reviewPublication` to `off`, a bad `compliance` list to the generic lens. A `project.json` or `config.json` that exists but is not a JSON object is never read as absent: the settings fail closed (publication off, knowledge write-back off, the tracker reported as invalid). The compliance lens is the exception, because it only adds scrutiny: it keeps every framework a readable layer declares, and an unreadable `project.json` counts as the generic lens. Memory and learning capture fail open instead: the hooks read an unreadable file as narrowing nothing, so capture runs as your machine's switch says.
+Each key is checked on its own, so one bad value never disables the rest: a bad `evidence` resolves to `required`, a bad `reviewPublication` to `off`, a bad `compliance` list to the generic lens. A `project.json` or `config.json` that exists but is not a JSON object is never read as absent: the settings fail closed (publication off, knowledge write-back off, the tracker reported as invalid). The compliance lens is the exception, because it only adds scrutiny: it keeps every framework a readable layer declares, and an unreadable `project.json` counts as the generic lens. Memory and curation capture fail open instead: the hooks read an unreadable file as narrowing nothing, so capture runs as your machine's switch says.
 
-`config.json` is personal, so it must not be committed. A `config.json` that git tracks is ignored as if it were absent — otherwise a branch could commit `"reviewPublication":"full"` for whoever reviews it — and `devflow tracker|memory|learning|knowledge --status` say so, with the fix: `git rm --cached .devflow/config.json`. Commands never read the file themselves — one local resolver folds it with your `config.json` and the machine settings, without touching the network.
+`config.json` is personal, so it must not be committed. A `config.json` that git tracks is ignored as if it were absent — otherwise a branch could commit `"reviewPublication":"full"` for whoever reviews it — and `devflow tracker|memory|curation|knowledge|gates --status` say so, with the fix: untrack the tracked entry with `git rm --cached`, then check or delete the file, because untracking leaves the committed bytes on disk as your personal file. Commands never read the file themselves — one local resolver folds it with your `config.json` and the machine settings, without touching the network.
+
+**Gate level.** The gate level (`full`, `standard` or `lean`) is not a narrow-only switch: your personal `.devflow/config.json` may carry a top-level `"gateLevel"` key that raises or lowers the machine default, which sits in `~/.devflow/manifest.json`, and `standard` applies when neither is set. `devflow init` asks for the machine default (an interactive run only; `devflow init --gate-level <full|standard|lean>` sets it with no prompt, and `--recommended` or a non-interactive init keeps the stored value), and `devflow gates --set <level>` changes it later. A `gateLevel` in `project.json` is ignored, and no command writes the personal key. A malformed value reads as `full`. `/code-review` and `/plan` read the level: `standard` and `lean` run fewer review focuses and fewer planning agents. The security checks and, in `/plan`, the design review run at every level. The compliance gap agent runs on its own trigger at every level. At `lean` and at no other level, `/implement` has Validate run your project's `lint-pack` script last (template in `templates/lint-pack/`). The script finds the faults a linter does not, such as a removed flag that a doc still names. To clear a match that you accept, add an allow glob to `.lint-pack.conf`. Run `devflow gates --set full` to keep the full `/plan` shape and Polish. `/implement` and `/resolve` also read the level and name it in their report. At `standard` and `lean` they skip Polish, and `full` keeps it. At `lean`, `/implement` also skips Harden on a docs-only diff (the root `README.md`, the root `CHANGELOG.md` or `.md` files under the root `docs/` that no agent loads as instructions, with the compliance lens `off`), and its report says `Harden: ran` or `Harden: SKIPPED (docs-only diff)`. Run `devflow gates --set standard` or `--set full` to keep Harden on every diff. A level reference that cannot be read applies no row and keeps the level. After updating, run `devflow init`. See the [CLI reference](https://github.com/dean0x/devflow/blob/main/docs/cli-reference.md#gate-level).
 
 ## Evidence policy
 
@@ -280,12 +282,14 @@ For deep dives: [Working Memory](https://github.com/dean0x/devflow/blob/main/doc
 npx devflow-kit init                    # Install (interactive wizard)
 npx devflow-kit init --plugin=implement # Install specific plugin
 npx devflow-kit ambient --enable        # Toggle ambient mode (orchestrator)
-npx devflow-kit learning --enable       # Toggle decision/pitfall tracking (all projects)
+npx devflow-kit curation --enable       # Toggle decision/pitfall tracking (all projects)
 npx devflow-kit compliance --enable     # Enable compliance (pick frameworks); prints the keys to add to .devflow/project.json
 npx devflow-kit compliance --status     # Show compliance state and this repo's evidence policy
 npx devflow-kit tracker --set jira       # Pick the machine's default tracker (github | jira | linear)
 npx devflow-kit tracker --status         # Show provider, this repo's effective one, learned conventions, mechanics
 npx devflow-kit tracker --servers default # Tracker servers the agents may call (comma-separated names, or default)
+npx devflow-kit gates --set lean         # Set the machine's default gate level (full | standard | lean)
+npx devflow-kit gates --status          # Show the gate level in effect here and which layer decided it
 npx devflow-kit rules --status          # Show installed rules
 npx devflow-kit security --status       # Show / manage the security deny list
 npx devflow-kit safe-delete --enable    # Install rm -> trash safe-delete
@@ -303,7 +307,7 @@ See [docs/cli-reference.md](https://github.com/dean0x/devflow/blob/main/docs/cli
 | Tool | Role | What It Does |
 |------|------|-------------|
 | **[Skim](https://github.com/dean0x/skim)** | Context Optimization | Code-aware AST parsing, command rewriting, output compression |
-| **Devflow** | Meta-Harness | Orchestrated + graph workflows, parallel review, memory, self-learning |
+| **Devflow** | Meta-Harness | Orchestrated + graph workflows, parallel review, memory, curated decisions |
 | **[MDS](https://github.com/dean0x/mdscript)** | Prompt Engineering | Composable template language for prompts — variables, loops, conditionals, imports, compiled to clean Markdown |
 
 ## Building from Source