`pnpm -r publish` exits before the last package is on the registry — @poveste/plugin-vue is last in 5 of 5 releases, with a 1m36s–4m46s tail

[50rayn]

pnpm -r publish exits zero before every package is on the registry. v0.10.0's run makes the gap unambiguous:

Publish to npm          12:32:47 → 12:33:32   step reported SUCCESS
Verify every package    12:33:32 → 12:37:09   3m37s, the widened window from #404
@poveste/plugin-vue     created  12:37:38     4m06s after publish said success

The verify step was correct to fail. At 12:37:09 that package was not on the registry — npm records its creation 29 seconds later. This is not the read-side propagation lag #401 concluded; the write had not happened.

The same package is last in every release

npm's time metadata for all eleven publishable packages, per release:

release	first → last publish	last package	plugin-vue's position
0.8.0	2m50s	@poveste/plugin-vue	11 of 11
0.8.1	1m36s	@poveste/plugin-vue	11 of 11
0.8.2	1m49s	@poveste/plugin-vue	11 of 11
0.9.0	1m52s	@poveste/plugin-vue	11 of 11
0.10.0	4m46s	@poveste/plugin-vue	11 of 11

Five out of five, always last, with a tail between 1m36s and 4m46s. That variance is why widening the window keeps almost working: #404 moved it to ~3m30s, which covered four of these five and lost to the fifth.

Two claims on the record that this corrects

Both were mine, and both were wrong in different directions.

"Only @poveste/plugin-vue fails — an npm-side Trusted Publishing problem" (#327 era). Right about which package, wrong about the mechanism. Nothing is failing; it finishes late.

"It is simply always last and slow to propagate" (#401). Right that it is timing, wrong that it is propagation. time records when npm created the version, not when a read first saw it. The version did not exist yet.

The honest statement is narrower than either: the publish command returns before this package's publish completes, every time, by a variable amount.

Why a bigger number is the wrong fix

A fixed window is a bet against a tail that has already moved by a factor of three across five samples. The next release picks a number out of the same distribution. Worth considering instead:

• Find out why it is always last. If it is pnpm's topological ordering, @poveste/plugin-vue depends on the most workspace packages and is genuinely published last — in which case the ordering is knowable up front, and the check could wait on that package rather than polling all eleven equally.
• Make the publish step prove its own work. The step exits on pnpm -r publish's status, which is what A green release can still half-publish: nothing verifies the packages reached npm, and v0.7.0 shipped without @poveste/plugin-vue #327 established should not be trusted. Having it confirm each package before returning moves the wait to where the knowledge is, and the verify step goes back to being a second opinion rather than the only one.

What is not wrong

The gate behaved correctly on every count. It failed, it named the package, it left the GitHub release as a draft so nobody was emailed a release whose packages were not all installable, and the documented recovery — re-run the job — published cleanly. The release notes reached subscribers once, correctly, and late rather than wrong.

That is the third time a red run has cost a re-run, though, and the first where the red was accurate. Worth fixing before the reflex becomes "re-run it, it is always fine".