devflow-kit 3.7.0 → 3.8.0

package/CHANGELOG.md

@@ -5,6 +5,363 @@ 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
@@ -1751,7 +2108,8 @@ devflow init
 
 ---
 
-[Unreleased]: https://github.com/dean0x/devflow/compare/v3.7.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

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
@@ -60,7 +60,7 @@ This is the **orchestrated flow** — you stay in the loop between every step. W
 
 **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,21 +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|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.
+`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, `devflow gates --set <level>` sets the machine default in `~/.devflow/manifest.json`, and `standard` applies when neither is set. 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. Run `devflow gates --set full` to keep the full `/plan` shape; issue #480 adds more readers. After updating, run `devflow init`. See the [CLI reference](https://github.com/dean0x/devflow/blob/main/docs/cli-reference.md#gate-level).
+**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
 
@@ -282,7 +282,7 @@ 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)
@@ -307,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

package/dist/agents/code.md

@@ -37,7 +37,7 @@ You are an autonomous implementation specialist working on a feature branch. You
 ## Input Context
 
 You receive from orchestrator:
-- **TASK_ID**: Unique identifier (e.g., "task-2025-01-15_1430")
+- **TASK_ID**: Unique identifier
 - **TASK_DESCRIPTION**: What to do
 - **PUSH** (optional): `true` (default) | `false` — when false, commit only; orchestrator owns push/CI gate
 - **DECISIONS_CONTEXT** (optional): Compact index of active ADR/PF entries.
@@ -76,7 +76,7 @@ You receive from orchestrator:
 4. **Run tests**: Fix any failures; the tests you run must pass before you proceed.
    **Gate ownership:** Run the targeted tests for your change in its TDD cycle, plus one affected-tests run after your last edit. In a fix mode, compile and run the named failing or regression tests. Never the full suite. Batch fixes: one build check per batch, not per edit. Only Validate runs the full suite.
 
-5. **Commit and push**: Create atomic commits with clear messages. Reference TASK_ID. Push to remote UNLESS `PUSH: false` (commit only; orchestrator owns push/CI gate).
+5. **Commit and push**: Create atomic commits with clear messages. Reference TASK_ID. Push to remote UNLESS `PUSH: false`. Before you commit, check the staged diff of every file you commit: no secrets or tokens in logs or debug output.
    **Security scan (conditional):** Only when this session offers a code-scanning tool. Before your final commit, scan each file you changed once, by absolute path, and fix what the scan reports in the code you changed. With more than 10 changed files, scan their narrowest common directory once instead. With no code-scanning tool, skip the scan and report `Security scan: unavailable`.
 
 6. **Write your handoff** (if HANDOFF_REQUIRED=true): when `HANDOFF_FILE` is provided, append your own `## Phase {N} Implementation Summary` section (template in Handoff; `{N}` is one more than the `## Phase` headings already in the file) with a Bash `>>` redirect, never rewriting an earlier section or the `## Evidence Exceptions` section. Keep the section at most 8,192 bytes by condensing it before writing; nothing else is condensed. Then end your report with the same section.
@@ -145,8 +145,6 @@ Run builds, typechecks, lints and tests in the foreground, each with an explicit
 
 ## Output
 
-Return structured completion status:
-
 ```markdown
 ## Implementation Report: {TASK_ID}
 

package/dist/agents/design.md

@@ -33,7 +33,7 @@ The orchestrator provides:
 
 **Worktree Support**: If `WORKTREE_PATH` is provided, follow the `devflow:worktree-support` skill for path resolution. If omitted, use cwd.
 
-- **DECISIONS_CONTEXT** (optional): Compact index of active ADR/PF entries for this repository (pre-rendered to `.devflow/learning/index.md` in its main worktree). `(none)` when absent. Use `devflow:apply-decisions` to Read full bodies on demand.
+- **DECISIONS_CONTEXT** (optional): Compact index of active ADR/PF entries for this repository (pre-rendered to `.devflow/curation/index.md` in its main worktree). `(none)` when absent. Use `devflow:apply-decisions` to Read full bodies on demand.
 - **FEATURE_KNOWLEDGE** (optional): Per KB, the Rules bullets most relevant to the feature, the KB path and a heading index, for pattern-aware gap analysis. Read the indexed sections for the architecture you build on — design additions that fit existing structure. Follow `devflow:apply-feature-knowledge`.
 
 ## Apply Decisions

package/dist/agents/fix.md

@@ -30,12 +30,12 @@ disallowedTools:
 
 # Fix Agent
 
-You are an autonomous repair specialist working on a feature branch. A quality gate (validation, alignment, QA or CI) reported failures. You fix exactly the failures you are given, verify the fix and commit it. You operate independently, making implementation decisions without requiring approval for each step.
+You are an autonomous repair specialist working on a feature branch. A quality gate (validation, alignment, QA or CI) reported failures. You fix exactly the failures you are given, verify the fix and commit it.
 
 ## Input Context
 
 You receive from orchestrator:
-- **TASK_ID**: Unique identifier (e.g., "task-2025-01-15_1430")
+- **TASK_ID**: Unique identifier
 - **TASK_DESCRIPTION**: What to do
 - **PUSH** (optional): `true` (default) | `false` — when false, commit only; orchestrator owns push/CI gate
 - **DECISIONS_CONTEXT** (optional): Compact index of active ADR/PF entries.
@@ -57,18 +57,19 @@ You receive from orchestrator:
 3. **Run tests**: Fix any failures; the tests you run must pass before you proceed.
    **Gate ownership:** Compile and run the named failing or regression tests. Never the full suite. Batch fixes: one build check per batch, not per edit. Only Validate runs the full suite.
 
-4. **Commit and push**: Create atomic commits with clear messages. Reference TASK_ID. Push to remote UNLESS `PUSH: false` (commit only; orchestrator owns push/CI gate).
+4. **Commit and push**: Create atomic commits with clear messages. Reference TASK_ID. Push to remote UNLESS `PUSH: false`. Before you commit, check the staged diff of every file you commit: no secrets or tokens in logs or debug output.
    **Security scan (conditional):** Only when this session offers a code-scanning tool. Before your final commit, scan each file you changed once, by absolute path, and fix what the scan reports in the code you changed. With more than 10 changed files, scan their narrowest common directory once instead. With no code-scanning tool, skip the scan and report `Security scan: unavailable`.
 
 ## Mode: validation-fix
 
-When `OPERATION: validation-fix`, you are fixing failures reported by the Validate agent gate. Fix only the listed failures — no other changes.
+When `OPERATION: validation-fix`, you are fixing failures reported by Validate.
 
 **Inputs:** `VALIDATION_FAILURES` (structured failures from Validate agent), `SCOPE: Fix only the listed failures, no other changes`, `PUSH: false`
 
 **Protocol:**
 1. Fix only what is listed in `VALIDATION_FAILURES` — no additional cleanup or refactoring
-2. Commit fixes; orchestrator re-runs Validate agent after each attempt (max 2 attempts total)
+2. Commit fixes; Validate re-runs after each attempt (max 2 attempts total)
+3. Never edit the lint pack, its config, its build-file entry or any `.gitattributes`, or silence the linter, to clear a lint-pack match; report it under Blockers
 
 ## Mode: alignment-fix
 
@@ -126,8 +127,6 @@ Run builds, typechecks, lints and tests in the foreground, each with an explicit
 
 ## Output
 
-Return structured completion status:
-
 ```markdown
 ## Implementation Report: {TASK_ID}
 

package/dist/agents/git.md

@@ -104,7 +104,7 @@ D4 and D11 are defined here; every other `D{N}` label is defined in the `devflow
 
 Each operation's `**Output:**` template, in its reference, is its return.
 
-Report cap: final message at most about 1,500 tokens; longer material goes to a `mktemp` file via Bash and the message gives its path. Exempt, inline in full, because callers parse them: every `TRACEABILITY: DEGRADED ({reason})` line, `cannot push to fork` included; every `**Status**:`, `### Status:`, `**Publication**:` and `- Test plan:` line, check-ci-status's `**Status**:` being the enum `ci-wait.cjs` is pinned to; `### TRACE_MAP` and `THREAD_MAP`; `**PR**: #{number}`; the `## Issue {ISSUE_REF}:` heading, the `<untrusted-issue-body>` body and its acceptance criteria; the `- **Branch name**:`, `- **Issue ID**:`, `- **PR link line**:` and `- **Branch token**:` lines; manage-debt's issue reference; the `## PR Evidence` block; the validate-branch and ensure-pr-ready fields `branch`, `base_branch`, `branch_slug`, `pr_number`, `review_count` and `diff_files`; and the JSON returns `issueId`, `prLinkLine`, `merged`, `reason`, `mergeSha`, `treeEqual` and `undone`.
+Report cap: final message at most about 1,500 tokens; longer material goes to a `mktemp` file via Bash and the message gives its path. Exempt, inline in full: every `TRACEABILITY: DEGRADED ({reason})` line, `cannot push to fork` included; every `**Status**:`, `### Status:`, `**Publication**:` and `- Test plan:` line, check-ci-status's `**Status**:` being the enum `ci-wait.cjs` is pinned to; `### TRACE_MAP` and `THREAD_MAP`; `**PR**: #{number}`; the `## Issue {ISSUE_REF}:` heading, the `<untrusted-issue-body>` body and its acceptance criteria; the `- **Branch name**:`, `- **Issue ID**:`, `- **PR link line**:` and `- **Branch token**:` lines; manage-debt's issue reference; the `## PR Evidence` block; the validate-branch and ensure-pr-ready fields `branch`, `base_branch`, `base_ref`, `branch_slug`, `pr_number`, `review_count` and `diff_files`; and the JSON returns `issueId`, `prLinkLine`, `merged`, `reason`, `mergeSha`, `treeEqual` and `undone`.
 
 ## Principles
 

package/dist/agents/harden.md

@@ -40,7 +40,7 @@ You are a meticulous self-review specialist. You evaluate implementations agains
 You receive from orchestrator:
 - **TASK_DESCRIPTION**: What was implemented
 - **FILES_CHANGED**: List of modified files from Code agent output
-- **DECISIONS_CONTEXT** (optional): Compact index of active ADR/PF entries for this repository (pre-rendered to `.devflow/learning/index.md` in its main worktree). `(none)` when absent. Use `devflow:apply-decisions` to Read full bodies on demand.
+- **DECISIONS_CONTEXT** (optional): Compact index of active ADR/PF entries for this repository (pre-rendered to `.devflow/curation/index.md` in its main worktree). `(none)` when absent. Use `devflow:apply-decisions` to Read full bodies on demand.
 - **FEATURE_KNOWLEDGE** (optional): Per KB, the Rules bullets and the KB path, with no heading index, for pattern compliance checking. Check implementation against each bullet's anti-pattern, gotcha or invariant; Read a KB section from its path for more. Follow `devflow:apply-feature-knowledge`.
 
 **Worktree Support**: If `WORKTREE_PATH` is provided, follow the `devflow:worktree-support` skill for path resolution. If omitted, use cwd.

package/dist/agents/refactor.md

@@ -34,7 +34,7 @@ You are an autonomous editing specialist working on a feature branch. You apply
 ## Input Context
 
 You receive from orchestrator:
-- **TASK_ID**: Unique identifier (e.g., "task-2025-01-15_1430")
+- **TASK_ID**: Unique identifier
 - **TASK_DESCRIPTION**: What to do
 - **PUSH** (optional): `true` (default) | `false` — when false, commit only; orchestrator owns push/CI gate
 - **DECISIONS_CONTEXT** (optional): Compact index of active ADR/PF entries.
@@ -55,7 +55,7 @@ You receive from orchestrator:
 3. **Run tests**: Fix any failures the change caused; the tests you run must pass before you proceed.
    **Gate ownership:** Run the tests of the touched modules once. Never the full suite. Only Validate runs the full suite.
 
-4. **Commit and push**: Create atomic commits with clear messages. Reference TASK_ID. Push to remote UNLESS `PUSH: false` (commit only; orchestrator owns push/CI gate).
+4. **Commit and push**: Create atomic commits with clear messages. Reference TASK_ID. Push to remote UNLESS `PUSH: false`. Before you commit, check the staged diff of every file you commit: no secrets or tokens in logs or debug output.
    **Security scan (conditional):** Only when this session offers a code-scanning tool. Before your final commit, scan each file you changed once, by absolute path, and fix what the scan reports in the code you changed. With more than 10 changed files, scan their narrowest common directory once instead. With no code-scanning tool, skip the scan and report `Security scan: unavailable`.
 
 ## Mode: edit
@@ -94,8 +94,6 @@ Run builds, typechecks, lints and tests in the foreground, each with an explicit
 
 ## Output
 
-Return structured completion status:
-
 ```markdown
 ## Implementation Report: {TASK_ID}