docs: plugins describe aep 0.63, ess 0.37 and worktree 0.8.2; release 0.16.0

CHANGELOG.md

@@ -1,5 +1,40 @@
 # Changelog
 
+## [0.16.0] — 2026-09-28
+
+The `ess`, `aep` and `worktree` plugins describe the newest CLI releases: ess 0.37.0, aep 0.63.1
+and worktree 0.8.2. `verified.json` pins all three.
+
+- `aep` describes the Git-native store, `aep.project/5`. The artifact files are the store, a move
+  appends to `transitions`, and each evidence record is one file under `.engineering/evidence/`.
+  `aep:planning` and `aep:implementing` read `.engineering/project.yaml` before the first write, and
+  tell the user once, with the exact upgrade, when the store is not `/5`: `/1` migrates with
+  `aep plan store migrate git --verify`, `/2`–`/4` through the pinned build named in
+  `aep:upgrade`. `aep:init`, adoption and the reverse engineer start new stores at `/5`. Reasons
+  that rested on the old append-only journal now rest on one writer and the `revision:` conflict.
+- `ess:hardening` uses `ess verify conform mutate`, with `--emit` and `--collect` for a project's
+  own runner, and the Go and TypeScript explorers. It no longer says the audit is unshipped. A
+  surviving mutant is answered by making the rule observable or filing a synthesis gap, never by
+  an authored scenario.
+- `ess:specifying` gains `references/later-formats.md`: fixtures, value expressions, the outcome
+  shapes (`unknown_instance:`, `deletes:`, `into:`, `accepts: nothing`, `preconditions:`),
+  `presence:`, `Json`, `prefix:`, `skip_absent`, case-insensitive guards, `when_subject_state:`
+  with its limits, and a per-holder limit ("at most five per member"). Each example validates and
+  synthesizes under ess 0.37.0. `syntax.md` gives the unknown-instance order, `instance:` on a
+  create and on a move, `params:` on a view, and the one-default rule for outcome `when`s.
+- `ess:retrofitting` maps a command that ignores in one state and refuses in another. `ess:init`
+  and `ess:upgrade` cover `ess specify toolchain` and an exact `requires: ess` pin.
+  `ess:testing-conformance` covers fixture providers and the suite versions the Go and TypeScript
+  runtimes accept.
+- The specification interview skips its questions when the request asks for a finished
+  specification. Without an AEP store it lists the decisions it took in the report.
+- `worktree:managing-worktrees` covers what `archive` includes and refuses, and how `gc` finishes an
+  interrupted removal. `worktree:init` covers `activate --install-agent-guidance`.
+- The `ess-pipeline` trial fixture sets the fields its invariant reads, which ess 0.37.0 requires
+  (`ESS-COMMAND-018`). The four ESS trials' baselines are re-recorded. `ess-new` now takes 38 tool
+  calls, not 12, because it models the per-member limit it used to leave unmapped; unmapped
+  markers fell from 7 to 4.
+
 ## [0.15.0] — 2026-09-28
 
 Eight methods from two public MIT skill collections, rewritten into the `aep`, `ess` and `b10x`

Cargo.toml

@@ -3,7 +3,7 @@ resolver = "2"
 members = ["crates/agentplugins-check", "crates/b10x"]
 
 [workspace.package]
-version = "0.15.0"
+version = "0.16.0"
 edition = "2021"
 rust-version = "1.85"
 license = "Apache-2.0"

plugins/aep/.claude-plugin/plugin.json

@@ -2,7 +2,7 @@
   "name": "aep",
   "displayName": "AEP",
   "description": "Plan governed work in the AEP artifact store and deliver it in reviewed waves: decomposition, plan critique, reverse engineering, story scoping, implementation and adversarial review.",
-  "version": "0.15.0",
+  "version": "0.16.0",
   "author": {
     "name": "Beyond10x"
   },

plugins/aep/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "aep",
-  "version": "0.15.0",
+  "version": "0.16.0",
   "description": "Plan governed work in the AEP artifact store and deliver it in reviewed waves.",
   "author": {
     "name": "Beyond10x"

plugins/aep/skills/diagnosing/SKILL.md

@@ -3,7 +3,7 @@ name: diagnosing
 description: Diagnose a hard bug or a performance regression by building a red-capable feedback loop before any hypothesis, then ranked falsifiable hypotheses, one-variable probes, a regression test at the right seam, and evidence recorded in the AEP store. Use when the user says diagnose, debug, "why is this failing", "this is slow", or reports something broken, throwing, flaky or slower than before. Not for a failing CI job whose cause is already named in its log, and not for raising conformance coverage, which is `ess:testing-conformance`.
 ---
 
-**Skill version 0.15.0** — the version in `.claude-plugin/plugin.json`.
+**Skill version 0.16.0** — the version in `.claude-plugin/plugin.json`.
 
 # Diagnosing a failure
 

plugins/aep/skills/implementing/SKILL.md

@@ -3,7 +3,7 @@ name: implementing
 description: Implement accepted AEP work, in one of two modes. A wave picks the stories that can be implemented at once, proposes the wave for approval, dispatches one implementor per story into its own worktree, sends each result to the adversary and merges what goes green. A drive hands one story to a governed `metaharness aep drive` run and reports the run id. Use when the operator asks to implement, build or deliver planned stories, to pick or start the next wave, to implement several stories in parallel or fan out across sub-agents, to drive a story or start a governed run, or asks why a wave's rules are instructions and a drive's are enforced. A wave proposes first and stops; a drive starts one run and reports; neither moves an artifact itself.
 ---
 
-**Skill version 0.15.0** — the version in `.claude-plugin/plugin.json`; a wave's stage-1 proposal quotes it.
+**Skill version 0.16.0** — the version in `.claude-plugin/plugin.json`; a wave's stage-1 proposal quotes it.
 
 # Implementing accepted work
 
@@ -22,6 +22,19 @@ question that names both. Then read that mode's reference in full; this page onl
 The operator can also name the mode directly: `/aep:wave [story-id…]` (`aep:wave`) or
 `/aep:drive <story-id>` (`aep:drive`), two commands that load this skill in that mode.
 
+## The store's version, first
+
+Before reading or writing the store, read `version` in `.engineering/project.yaml`. On anything but
+`aep.project/5`, tell the user once, before any store write, which version it is and its upgrade;
+do not wait for `aep` to print a notice:
+
+| the store | upgrade |
+|---|---|
+| `aep.project/1`, or `.engineering/planning/` with no `project.yaml` | `aep plan store migrate git --verify` on a clean `.engineering` (no `project.yaml`: add `--protocols` and `--profile`, `aep:planning` § 5), then commit. Every verb still works (with no `project.yaml`, only given `--store <dir>`); carry on |
+| `aep.project/2`, `/3` or `/4` | `cargo install --git https://github.com/beyond10x/aep --rev 9c0f1da44429ff935fa0b2d743457945d51e1c51 aep-cli`, then `aep plan store migrate git --verify` on a clean `.engineering`, commit, then install the current release (`aep:upgrade`). Every planning verb refuses the store: stop and report |
+
+`aep:upgrade` carries the steps; the user decides when the migration runs.
+
 ## Rules for both modes
 
 - Implement only stories the store shows as accepted; neither mode moves an artifact itself.

plugins/aep/skills/implementing/references/adversary.md

@@ -173,16 +173,16 @@ Only the residue — what could not be made into a failing case. **You return th
 report. You do not write them to the planning store, and you run no `aep plan artifact` command at
 all.**
 
-The reason is mechanical, not stylistic. You work in a worktree, and the store's journal is
-append-only and committed. A record you write there is a second tail on a branch nobody merges, and
-when the coordinator's tree and yours both append, the textual merge produces a document whose
-revision no event supports — which the store's own validator reports as forgery. One agent, one
-surface; the store is the coordinator's surface and never yours.
+The reason is mechanical, not stylistic. You work in a worktree, on a branch. Every store write
+bumps the artifact's `revision:` line, so a record you write there and the coordinator's write to
+the same artifact conflict at merge, and a resolution that drops either side's move is refused by
+`aep plan artifact validate`. One agent, one surface; the store is the coordinator's surface and
+never yours.
 
 This was measured, not feared: on the wave of 2026-08-30 two adversaries were given the same
-charter, one declined and said why, the other complied and wrote into its worktree's store. Its
-journal was 564 lines against the main tree's 568 — forked, and a merge away from the failure the
-rule exists to prevent.
+charter, one declined and said why, the other complied and wrote into its worktree's store. That
+store's journal (the layout of the time) was 564 lines against the main tree's 568 — forked, and a
+merge away from the failure the rule exists to prevent.
 
 So the findings arrive as a table in your report, one row per finding, each carrying a `file:line`,
 one verdict and one origin:

plugins/aep/skills/implementing/references/security-reviewer.md

@@ -167,11 +167,11 @@ Only the residue — what could not be made into a failing case. **You return th
 report. You do not write them to the planning store, and you run no `aep plan artifact` command at
 all.**
 
-The reason is mechanical, not stylistic. You work in a worktree, and the store's journal is
-append-only and committed. A record you write there is a second tail on a branch nobody merges, and
-when the coordinator's tree and yours both append, the textual merge produces a document whose
-revision no event supports — which the store's own validator reports as forgery. One agent, one
-surface; the store is the coordinator's surface and never yours.
+The reason is mechanical, not stylistic. You work in a worktree, on a branch. Every store write
+bumps the artifact's `revision:` line, so a record you write there and the coordinator's write to
+the same artifact conflict at merge, and a resolution that drops either side's move is refused by
+`aep plan artifact validate`. One agent, one surface; the store is the coordinator's surface and
+never yours.
 
 So the findings arrive as a table in your report, one row per finding, each carrying a `file:line`,
 one verdict and one origin:

plugins/aep/skills/implementing/references/story-scoper.md

@@ -20,9 +20,8 @@ exactly where it is weakest.
 
 ## You change nothing
 
-Read-only, and for a reason beyond caution: many of you run at once. The planning store's journal is
-append-only and one file, so N agents writing it concurrently is a race. You return the section; the
-one session that called you writes it, in order.
+Read-only, and for a reason beyond caution: many of you run at once, and the planning store takes
+one writer at a time. You return the section; the one session that called you writes it, in order.
 
 * **Bash is for reading** — `aep plan artifact show`, `list`, `graph`, `git log`, `git grep`, `rg`,
   and nothing that writes.

plugins/aep/skills/implementing/references/wave.md

@@ -79,11 +79,11 @@ matters* is the load-bearing half. Almost none of a healthy wave matters.
 A sub-agent's report is **input to you, never output to the operator.** Its register is not yours to
 pass on: take the findings, drop the voice.
 
-**Why you own every store write.** The planning store's journal is append-only and committed, and
-nothing merges it. Two branches that each move their own story both append to the tail, and the
-textual merge produces a document whose revision no event supports — which the store's own
-validator reports as forgery. Implementors touching only source files makes that impossible. It is
-also the division that works: one agent, one surface; the shared files are yours.
+**Why you own every store write.** Every store write bumps the artifact's `revision:` line, and a
+move appends to its `transitions`. A unit branch that writes an artifact the coordinator also
+writes conflicts on those lines at merge, and a resolution that drops either side's move is
+refused by `aep plan artifact validate`. Implementors touching only source files makes that
+impossible. It is also the division that works: one agent, one surface; the shared files are yours.
 
 ---
 
@@ -113,8 +113,8 @@ a real backlog most bodies cite no path at all, so the disjointness a wave rests
 unless somebody establishes it.
 
 Fan out `story-scoper`, one agent per candidate, and run them at once. They are read-only by
-charter — which is what makes running many safe: the planning journal is append-only and one file,
-so N agents writing it would race. **They return `## Scope` sections; you write them**, one at a
+charter — which is what makes running many safe: the store takes one writer at a time, and that is
+you. **They return `## Scope` sections; you write them**, one at a
 time, through `aep plan artifact body` with the complete body.
 
 Each section says where the work lands and marks every line `cited` or `inferred`. Read the

plugins/aep/skills/init/SKILL.md

@@ -35,8 +35,10 @@ aep plan artifact list
 ```
 
 A store answers with its artifacts. No store: `aep:planning` § 5 (*Starting from a repository that
-has no store*) says how a first one is created; an existing backlog in markdown moves in with
-`aep:migrating`.
+has no store*) says how a first one is created — `aep plan reverse init`, which writes an
+`aep.project/5` project with `store: {git: {}}`; an existing backlog in markdown moves in with
+`aep:migrating`. A store whose `.engineering/project.yaml` names another `version` is upgraded
+first: `aep:upgrade` (*An older planning store*).
 
 ## 3. Pick the work
 

plugins/aep/skills/migrating/SKILL.md

@@ -3,7 +3,7 @@ name: migrating
 description: Migrate a repository's legacy work tracking — story trees, TODO.md, plan and issue documents — into the governed AEP planning store, without deleting or rewriting the sources. Use when the user asks to migrate, import, port or convert an existing backlog into AEP, when a repository is adopting AEP and already has work written down somewhere, or when a store has been adopted beside a legacy backlog nobody retired. Read it before creating the first artifact in a repository that already tracks work in markdown.
 ---
 
-**Skill version 0.15.0** — the version in `.claude-plugin/plugin.json`.
+**Skill version 0.16.0** — the version in `.claude-plugin/plugin.json`.
 
 # Migrating legacy tracking into the store