From c97da0292ae1e6a6bab094301baebfb994a2b120 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andr=C3=A9=20Padez?= Date: Sun, 30 Aug 2026 11:32:05 +0100 Subject: [PATCH] release 2026.08.30.03 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit One commit — 537cc29c, fixing what the 2026.08.30.01 rollout found on fofos: a plugin declaring `@tiptap/pm` was reported as a failed install. Nothing was broken on disk. That package has no root entry point by design — it is tiptap's single pinned copy of ProseMirror and you import `@tiptap/pm/state`, never the bare name — so the checker asked a question it could not answer. Worth its own release rather than waiting: `bun run plugins:update` exits 1 on fofos every time until this lands, so the plugin step of every future deploy fails there and reads as a new problem each time. No schema change and no dependency change, with the two commands that prove it in the plan. docs:check green. Only fofos has fofos-admin installed, so everywhere else this is a no-op in behaviour. ── Why .03 ── 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 and the tag was not, so a tag pointing off-branch existed for about ten seconds. The watcher claimed the version inside that window, and a claim is permanent by design — so .02 is spent and carries a claim with no .done, which is what "attempted and did not succeed" should look like. No host moved. Every one stayed on 816f8695 throughout. The lesson is in the ordering, and it is now the practice: pull, then push the branch, then tag only once the branch has landed. Pushing both in one command means a rejected branch still publishes a tag. Co-Authored-By: Claude Opus 5 (1M context) --- deploy/2026.08.30.03.md | 99 +++++++++++++++++++++++++++++++++++++++++ package.json | 2 +- 2 files changed, 100 insertions(+), 1 deletion(-) create mode 100644 deploy/2026.08.30.03.md 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": [