@@ -1,24 +1,34 @@
 ---
-'@objectstack/cli': patch
+'@objectstack/cli': minor
 ---
 
-feat(cli): `os migrate organization-ownership --apply` executes only the plan the operator reviewed (ADR-0131 D10)
+feat(cli)!: `os migrate organization-ownership --apply` executes only the plan the operator reviewed (ADR-0131 D10)
 
-Clause-②: no
+Clause-②: yes (widening)
 
-`--apply` now requires `--plan-file FILE`, the plan file a plan run wrote. Before it writes anything it compares that file with the plan it computes, and refuses when either differs:
+<!-- adr-0087: not-required (no-migration-prescription) No metadata moves: no spec key, authorable spelling, object definition or stored shape is added, removed, renamed or re-shaped, and no exported declaration is removed or narrowed, so there is nothing for `objectstack migrate meta` to rewrite. What narrows is the accept set of one CLI command's writing mode: `--apply` without the reviewed plan file is refused, and the remedy is in the invocation an operator types (add `--plan-file`), never a rewrite of a package source or a stored row. The other categories are closed on facts: the package publishes (not unpublished); no ADR-0087 id is named or touched (not registered or already-registered); and nothing exported is removed or narrowed (not runtime-interface-only, type-surface-only or runtime-export-retired). -->
 
-- **Another inventory digest** (`plan-digest-mismatch`): the fates it would run are not the ones the reviewed plan showed. That happens with a different `--fate-supplement`, or with another release's inventory. Without this check, planning with supplement A and applying with supplement B ran B's fates unreviewed, including a mirror deletion A never listed.
-- **Another tenancy posture** (`plan-posture-mismatch`): the plan file records the posture it was computed under (`OS_TENANCY_POSTURE` / `OS_MULTI_ORG_ENABLED`), and the posture decides which rows attribution gives an owner and which it reports. A plan reviewed under a wall, which lists rows as reported, would otherwise give them owners when applied under `single`.
-- **Another database** (`plan-database-mismatch`).
+**BREAKING** (a narrowing of `--apply`'s accept set, released in 18.0.0-next.1), shipped as `minor` under the launch-window convention for breaking changes. It also widens the command: a new flag, `--plan-file`, new refusal reasons, and two new keys on the apply report.
+
+`--apply` now requires `--plan-file FILE`, the plan file a plan run wrote. Before it writes anything, it compares that file with the plan it computes, and refuses when any of these differs:
+
+- **The inventory digest** (`plan-digest-mismatch`). The fates it would run are not the ones the reviewed plan showed: a different `--fate-supplement`, or another release's inventory. Without this check, planning with supplement A and applying with supplement B ran B's fates unreviewed, including a mirror deletion A never listed.
+- **The tenancy posture** (`plan-posture-mismatch`). The plan file records the posture it was computed under (`OS_TENANCY_POSTURE` / `OS_MULTI_ORG_ENABLED`), and the posture decides which rows attribution gives an owner and which it reports. A plan reviewed under a wall, which lists rows as reported, would otherwise give them owners when applied under `single`.
+- **The database** (`plan-database-mismatch`).
 
 The refusal names both values and the remedy: run the plan again with the same flags (or run the apply under the plan's posture), review it, and pass the new file. No flag skips the comparison.
 
-A file that is not an organization-ownership plan (missing its digest, posture or database), or cannot be read, is refused as `plan-file-unusable`. `--apply` without the flag is refused as `plan-file-required`. Both refusals come before the backup question and before the database is opened.
+A file that is not an organization-ownership plan, or that lacks its digest, posture or database, or cannot be read, is refused as `plan-file-unusable`. `--apply` without the flag is refused as `plan-file-required`. Both refusals come before the backup question and before the database is opened.
 
 A checkpoint recorded under another digest is no longer discarded silently. The reviewed plan supersedes it: every step runs again (each is idempotent), and the apply report names the discarded checkpoint in `restartedFrom`, beside `reviewedPlan`.
 
-`--apply` has not shipped in a release yet (its changeset is still pending), so no released invocation changes. The one-line form is:
+## FROM → TO
+
+| invocation | FROM (18.0.0-next.1) | TO |
+|:--|:--|:--|
+| `os migrate organization-ownership --apply --backup-taken` | performed the plan it computed at apply time | refused, `plan-file-required`: run `os migrate organization-ownership --out plan.json`, review it, then `--apply --backup-taken --plan-file plan.json` |
+| `os migrate organization-ownership --fate-supplement host-fates.json --apply --backup-taken` | performed the plan it computed with that supplement | refused, `plan-file-required`: plan with the same `--fate-supplement`, then add `--plan-file plan.json` |
+| `--apply … --plan-file plan.json`, where the file was planned with another supplement, release, posture or database | (no such flag) | refused with `plan-digest-mismatch`, `plan-posture-mismatch` or `plan-database-mismatch`, naming both values |
 
 ```bash
 os migrate organization-ownership --out plan.json                                  # plan, then review plan.json
 
@@ -42,6 +42,7 @@ import {
   type OrganizationOwnershipApplyReport,
   type StepReport,
 } from './organization-ownership-apply.js';
+import { inventoryDigest } from './organization-ownership-plan.js';
 
 // [#10126] Pay the first load of what the boot reaches through dynamic
 // `import()`s at MODULE LOAD, outside the clocked hook.
@@ -126,6 +127,8 @@ async function ceremony(posture: string, db: Database.Database): Promise<Organiz
     },
     posture,
     database: 'v17',
+    // The plan the operator reviewed: the one this run computes.
+    reviewedPlan: { file: 'plan.json', generatedAt: '2026-10-14T00:00:00Z', database: 'v17', inventoryDigest: inventoryDigest(), posture },
     catalog,
     door: { save: async (type, name) => { throw new Error(`the door was asked to save ${type} ${name}`); } },
     templates: { find: async () => undefined },
 
@@ -91,7 +91,10 @@ function projectFor(name: string, config: Record<string, unknown>): string {
   return projectDir;
 }
 
-/** The real command, `--apply`, from `projectDir`, over a fresh copy of the fixture. */
+/**
+ * The real command from `projectDir`, over a fresh copy of the fixture: the plan
+ * run first (its file is the reviewed plan `--apply` executes), then `--apply`.
+ */
 async function applyIn(projectDir: string): Promise<{ dbFile: string; report: any; exitCode: number }> {
   const dbFile = join(projectDir, 'v17.db');
   copyFileSync(templateDb, dbFile);
@@ -109,9 +112,15 @@ async function applyIn(projectDir: string): Promise<{ dbFile: string; report: an
   process.chdir(projectDir);
   let exitCode: number | undefined;
   try {
+    const planFile = join(projectDir, 'plan.json');
+    await MigrateOrganizationOwnership.run(['--out', planFile, '--database-url', `file:${dbFile}`, '--json'], { root: CLI_ROOT });
+    stdout.mockClear();
     try {
       await MigrateOrganizationOwnership.run(
-        ['--apply', '--backup-taken', '--out', join(projectDir, 'apply.json'), '--database-url', `file:${dbFile}`, '--json'],
+        [
+          '--apply', '--backup-taken', '--plan-file', planFile,
+          '--out', join(projectDir, 'apply.json'), '--database-url', `file:${dbFile}`, '--json',
+        ],
         { root: CLI_ROOT },
       );
     } catch (error) {