Files

T

pastilhasandClaude Opus 5 c97da0292a release 2026.08.30.03

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) <noreply@anthropic.com>

2026-08-30 11:38:06 +01:00

4.9 KiB

Raw Blame History

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:

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:

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.

4.9 KiB Raw Blame History