0.1.78 was never published to npm, and the Publish run reported success with its publish steps skipped

[khaliqgant]

Summary

@agent-relay/factory@0.1.78 does not exist on npm, despite a
chore(release): @agent-relay/factory@0.1.78 commit on main and a green
Publish workflow run. The npm version list jumps straight from 0.1.77 to
0.1.79.

Nothing is missing from production — 0.1.79 supersedes 0.1.78 and contains
its commits. The defect is the silent green, not a lost artifact. A release
can land, report success, and publish nothing, and no check notices the gap.

Evidence

$ npm view @agent-relay/factory versions --json   (tail)
  ['0.1.71','0.1.72','0.1.73','0.1.74','0.1.75','0.1.76','0.1.77','0.1.79']

$ npm view @agent-relay/factory@0.1.78 version
  npm error 404

Meanwhile on main:

0cb93c3 chore(release): @agent-relay/factory@0.1.79 (#383)
a3c629c chore(release): @agent-relay/factory@0.1.78 (#381)
5129989 chore(release): @agent-relay/factory@0.1.77 (#380)

The mechanism — a green job whose publish steps were skipped

Publish run 32944952439, 2026-08-26T07:53:13Z, head 8f3904c5
(package.json version 0.1.78). Job conclusion: success. Its steps:

#	step	conclusion
1-8	Set up job → Resolve version	success
9	Open version PR	success
10	Verify packed end-to-end lifecycle	skipped
11	Upload release E2E attestation	skipped
12	Dry-run package	skipped
13	Inspect release state	skipped
14	Create release tag	skipped
15	Update npm for OIDC support	skipped
16	Publish	skipped
17	Verify final release state	skipped
33-35	Post-steps → Complete job	success

The run took the open-a-version-PR branch and skipped every step from the
end-to-end verification through the publish and its final verification. Skipped
steps do not fail a job, so the workflow reported green having published
nothing — including step 17, the very step whose job is to catch this.

Why this is worth fixing rather than shrugging at

The observable signal for "this release shipped" is currently a green Publish
run, and that signal is false in exactly the case that matters. A future
release that needed to reach npm — a security fix, or an engine bump a deployed
container resolves by version — would fail the same way and look identical to a
success. The gap was found by hand while auditing something unrelated.

This is the general shape: job success does not mean the steps ran. An
if:-guarded step that is skipped still reports green, so a green job proves
only that nothing errored, never that the intended effect happened.

Related but distinct, and worth noting since it is in the same window: run
32945696981 (08:02:08Z, head 0cb93c38) failed in Test with two
assertion errors at src/orchestrator/factory.test.ts:23579 and :23754
(expected undefined to be 1), and the identical sha then succeeded on
retry at 08:09:19Z (run 32946305602). That is a flaky test gating releases —
a separate problem from this one, but it means the publish path is currently
both flaky and unable to tell you when it no-ops.

Asks

1. Assert the real-world effect, not the job conclusion. After a release
   commit lands on main, verify the version actually resolves on npm and fail
   loudly if it does not.
2. Make the no-op explicit. If the version-PR branch is legitimate, have it
   say so — a job that skips its own publish should not be indistinguishable
   from one that published.
3. Decide whether 0.1.78 should be published retroactively or formally
   skipped. Leaving a hole in the version sequence with no record invites
   someone to assume it was yanked.
4. Track the flaky factory.test.ts:23579 / :23754 assertions separately if
   they are not already covered.