Publish workflow cannot resume a partial two-package release after the library succeeds

A failure publishing the demo leaves the library published and the GitHub release public; a whole-workflow retry then reaches the already-published library first.

Observed incident

Publish run 33854645746 for v0.1.10 successfully completed Publish library, then failed in the demo's prepublishOnly TypeScript build. PR #32 confirms that split publication and explains why recovery used 0.1.11 instead of retrying 0.1.10.

As checked September 13, npm has library 0.1.10, while the demo registry history omits 0.1.10 and includes 0.1.11. The v0.1.10 GitHub release remains public.

The TypeScript cause was fixed in #32, including building the demo during preflight. At 070f654f6248, however, publish.yml still starts on release: published and sequentially runs unconditional npm publish for the library and demo, without per-package recovery checks. A later registry/network/authentication failure after the first publish can produce the same split state.

Suggested recovery behavior

This release path does not follow the publish-then-record saga pattern: it announces the GitHub release before registry work completes and does not checkpoint the two irreversible publishes.

1. Build and pack both packages before either upload; retain the exact artifacts for recovery.
2. For each package, distinguish a verified matching published artifact from an absent version. Skip only verified matches, publish missing artifacts, and fail on conflicts or indeterminate registry responses.
3. Verify both packages are available before finalizing the public release. A dispatch using an immutable commit/version or a draft-release flow could keep the completion record pending until then.

A useful regression scenario is: library upload succeeds, demo upload fails once, then recovery publishes only the demo and finalizes the same release without a version bump. This is a workflow resilience report based on the existing run, not a new local publication attempt.

Prepared with AI assistance (Codex); evidence comes from the linked public workflow, run history, and release metadata. No production release was triggered for this report.

Start with .github/workflows/publish.yml at commit 070f654f6248b74cc633cdbea9777ce9b2767ac2, then review run 33854645746 and PR #32 for the existing publication sequence and failure context. Define the recovery behavior around the two package uploads and public release state. Done should cover the reported case: after the library succeeds and the demo fails once, recovery publishes only the demo and completes the same release without a version bump.