diff --git a/deploy/2026.08.30.03.md b/deploy/2026.08.30.03.md
new file mode 100644
index 00000000..9a6d1ec9
--- /dev/null
+++ b/deploy/2026.08.30.03.md
@@ -0,0 +1,99 @@
+# 2026.08.30.03 — a package with no root entry point is not a broken install
+
+**One commit.** `537cc29c`, fixing what the 2026.08.30.01 rollout found on `fofos`.
+
+**Why .03 and not .02.** `2026.08.30.02` was tagged against a commit that was not on `master` — the
+rollout's own report had just been pushed and the release was cut without pulling first. The branch push
+was rejected, the tag was not, and a tag pointing off-branch was published for about ten seconds before
+being withdrawn. The watcher claimed the version inside that window.
+
+A claim is permanent by design and that is correct: `.02` was attempted, so `.02` is spent and cannot be
+deployed. It has a claim and no `.done`, which is exactly what "attempted and did not succeed" should
+look like in the record. Nothing reached any host — every one stayed on `816f8695` throughout.
+
+**No schema change and no dependency change.** Verified rather than assumed:
+
+```bash
+git diff --name-only deploy/2026.08.30.01..deploy/2026.08.30.03 | grep -iE 'schema|/db/|databases'   # nothing
+git diff --name-only deploy/2026.08.30.01..deploy/2026.08.30.03 -- package.json bun.lock             # nothing
+```
+
+So **no `bun db:push` and no `bun install` step exists in this plan, and neither should be improvised.**
+
+## What it fixes, and what it does not
+
+`unresolvableDependencies` asked `Bun.resolveSync(name, pluginDir)` of every package a plugin declares.
+That is the right question for almost all of them and unanswerable for a few.
+
+`@tiptap/pm` declares no `main`, no `module`, and an `exports` map with no `"."` — it exists only as
+subpaths, because it is tiptap's single pinned copy of the ProseMirror packages and you import
+`@tiptap/pm/state`, never `@tiptap/pm`. Asked to resolve the bare name, Bun correctly says it cannot,
+and the checker read that as a failed install.
+
+**Nothing was ever broken on disk.** The install on `fofos` is complete — the directory, its `dist` and
+thirteen prosemirror packages. The editor works. What failed was the verification, which then failed
+`plugins:update`, which exits non-zero if any plugin failed.
+
+The consequence worth shipping for: **`bun run plugins:update` exits 1 on `fofos` every time** until
+this lands, so the plugin step of every future deploy fails there and looks like a new problem.
+
+The strong check stays first, so a package that installed but cannot be loaded on this machine still
+fails — `sharp` resolving to a platform-specific binary is the shape it was written for. Only a package
+that fails it is asked the weaker question: is it there.
+
+## Every host — the commands
+
+The standard steps in `prompts/deploy-commander.md` are the whole rollout (dirty check,
+`git fetch origin --tags`, `git merge --ff-only deploy/2026.08.30.03`, `bun run plugins:update`), plus:
+
+```bash
+pm2 restart officer
+```
+
+`officer` only — `plugins:update` has already restarted the plugin sidecars.
+
+**`fofos` is the host this release is for.** Its `plugins:update` failed 4/5 on the last rollout and
+should now be 5/5, exit 0. That is the check that matters:
+
+```
+→ fofos-admin
+    packages: installed and resolvable
+```
+
+If `fofos` still reports 4/5 with `@tiptap/pm cannot be resolved`, this release did not work and that
+is the finding — report it rather than working around it.
+
+Everywhere else this is a no-op in behaviour: no other host has `fofos-admin` installed, so no other
+host was failing and none should start.
+
+### Verify it came back
+
+`pm2 jlist`: `officer` online and `restart_time` moved, then `/api/health` on the host's own port
+(9010 on `macbookpro` and `production-pertento-bridge`, 9000 elsewhere). `200` or `401` are healthy.
+
+No file-browser check this time — this release touches one function in the plugin installer and
+nothing a browser reaches.
+
+## Per host
+
+Every host went to `816f8695` an hour ago and all seven came back online, so they start from there.
+
+| Host | Note |
+| --- | --- |
+| `officer-dev` | **SKIP ENTIRELY.** The rollout runs here. It already holds this commit and its `officer` was restarted by hand at 11:23. |
+| `alpha` | Ordinary target. No `fofos-admin`, so nothing changes in behaviour. |
+| `fofos` | **The reason for this release.** Expect `plugins:update` to go 4/5 → 5/5. |
+| `macbookpro` | macOS, port **9010**, a laptop. Unreachable is a SKIP with a note, not a failure. |
+| `macbruno` | macOS, login **`brunoalcadapadezmonteirodaconceicao`**. |
+| `production-pertento-bridge` | Port **9010**. |
+| `edge-pertento-bridge` | Ordinary target. |
+| `deadpool-rezio-bridge` | Login **`br`**, checkout `/home/br/officerdev/platform`. |
+
+Note for whoever reads the report: `scripts/chk.ts` is untracked on `fofos` and was noted last time. It
+is still a note, not a skip.
+
+## What "done" looks like
+
+Per host: HEAD before and after, `plugins:update` result, `officer` back online with a moved
+`restart_time`. And for `fofos` specifically, the `fofos-admin` line reading
+`packages: installed and resolvable`.
diff --git a/package.json b/package.json
index 9f3f7ff5..70988f50 100644
--- a/package.json
+++ b/package.json
@@ -1,6 +1,6 @@
 {
   "name": "officer",
-  "version": "2026.08.30.01",
+  "version": "2026.08.30.03",
   "private": true,
   "type": "module",
   "workspaces": [