@bongos/core 1.19.797 → 1.19.798

package/.bongos-core.json

@@ -2,22 +2,22 @@
   "artifact": "bongos-core",
   "manifest_schema": 1,
   "generator": "scripts/gds/package-core.js",
-  "core_version": "1.19.797",
-  "core_contract": "1.19.797",
-  "source_commit": "8f5cae915f47995fbf47d3adaeeb356c02f4a9f7",
+  "core_version": "1.19.798",
+  "core_contract": "1.19.798",
+  "source_commit": "004852105d6e6651ca15c7405fb3aafb859b89d3",
   "source_ref": "HEAD",
-  "built_at": "2026-09-17T01:13:47.184Z",
+  "built_at": "2026-09-17T01:22:01.549Z",
   "redaction": {
     "model": "docs-redacted+functional-verbatim",
-    "docs_redacted": 486,
+    "docs_redacted": 487,
     "agent_docs_stubbed": 25,
-    "functional_verbatim": 2183,
+    "functional_verbatim": 2185,
     "rules": 3,
     "gate_literals": 3,
     "gate": "passed"
   },
-  "file_count": 2694,
-  "tree_sha256": "c15e5cbc3148cc9a221215b7607ed8cdc79df894902b2e7390bc9baa08d49bc6",
+  "file_count": 2697,
+  "tree_sha256": "87cf75447f225dc7cc6c23dbe927a64293ba4c290bc3aaee0b87fabbfabd7b9f",
   "files": [
     {
       "path": ".claude/skills/ask-for-help/SKILL.md",
@@ -1959,10 +1959,15 @@
       "mode": "0000644",
       "sha256": "32d1b4184b6ba494bacb915990f0ba2770535e25c5646c86a2d91d9cc05c93ed"
     },
+    {
+      "path": "docs/adr/0295-the-registry-is-the-witness-the-lane-cannot-be.md",
+      "mode": "0000644",
+      "sha256": "971bd9c2feaa6f3fc910c8a413b1f1a2ebc416cb5c50885dac25f4114cb976c3"
+    },
     {
       "path": "docs/adr/README.md",
       "mode": "0000644",
-      "sha256": "5659dd04d00f3ac4b3087ec41d24d7eea6f9d3ad349cd68b4405b612c8238feb"
+      "sha256": "91240573bd704d34ed8100da3795b082430736acc1e03e8cf6469fcd12e2b220"
     },
     {
       "path": "docs/api-reference.md",
@@ -2517,7 +2522,7 @@
     {
       "path": "docs/file-map.md",
       "mode": "0000644",
-      "sha256": "ec4237ced675e982e57bf25119112729ef1bc16e574a33b925e00c1105f02287"
+      "sha256": "44af03bcfe197664d948053f26ed4af87c7b6fbe1a2a341d3ba3b02439357445"
     },
     {
       "path": "docs/handoff-template.md",
@@ -2527,7 +2532,7 @@
     {
       "path": "docs/module-api-changelog.md",
       "mode": "0000644",
-      "sha256": "e0e6a2d6f7b83b899430db2acfa43e9385fd35237cf0245cf54c415be7fe9424"
+      "sha256": "90e23bd74c05c075cab7d2d7220a4ece60c0cd99d78925b317567c1ada6c0ecd"
     },
     {
       "path": "docs/modules-contract.md",
@@ -7702,12 +7707,12 @@
     {
       "path": "package-lock.json",
       "mode": "0000644",
-      "sha256": "21954c7eccc561a9ad23abf43f4511040f8b67231aeb91fa88e47d324c3ff18d"
+      "sha256": "17535d90fc6adb0a8c78b659584b58869bf2d47da14fabb22defb1f73b303976"
     },
     {
       "path": "package.json",
       "mode": "0000644",
-      "sha256": "4a4cd623c012c80ec9a7d18065e78a47209ed2ded81d282e796e9bca6ce7ce6b"
+      "sha256": "f1a0a4d4fe697be8633c635210d733e0e2b60f263b0e6ecb9925532145e30b4e"
     },
     {
       "path": "public-docs/index.html",
@@ -8624,6 +8629,11 @@
       "mode": "0000644",
       "sha256": "8c6ca4655d1eb54b7e604e659fe8eebdf4f7a0b0231a31dab944883fc5c582e8"
     },
+    {
+      "path": "scripts/gds/publish-watch.js",
+      "mode": "0000644",
+      "sha256": "e64bc7b8d284633d43678721aafc56ffeabb78c071f5ef58da7764dc1325fae3"
+    },
     {
       "path": "scripts/gds/pulse.js",
       "mode": "0000644",
@@ -9587,7 +9597,7 @@
     {
       "path": "src/module-api.js",
       "mode": "0000644",
-      "sha256": "12ad8d673d39e15d3ccf283f17927e66dbcf499f1b5243f15bd6cb46545bb1e2"
+      "sha256": "a4af4ddf0f8f8cc92c41fcebbd1193af19b432de585e836eb6d4626a0dc1e033"
     },
     {
       "path": "src/module-loader/catalog.js",
@@ -12484,6 +12494,11 @@
       "mode": "0000644",
       "sha256": "fb994e6a587b577c5e5fc9f1b8b4e63cc92c51c3ab0dd64ea8caee8c0e70ef7c"
     },
+    {
+      "path": "tests/publish_watch.mjs",
+      "mode": "0000644",
+      "sha256": "91ada5b4bf9b22ff8cefb0508be34f5d006bd223c825c73e5bbc9812411a4253"
+    },
     {
       "path": "tests/push_path_brief.mjs",
       "mode": "0000644",

package/docs/adr/0295-the-registry-is-the-witness-the-lane-cannot-be.md

@@ -0,0 +1,123 @@
+# ADR 0295 — The registry is the witness the publish lane cannot be
+
+**Status:** accepted · **Date:** 2026-09-16 · **Task:** [task 1003916](https://cloudbongos.com/builders#/task/1003916) (goal 1000090)
+
+## Context
+
+On 2026-09-13 eight consecutive publish runs failed between 09:54 and 13:02 UTC on a
+mis-scoped leak gate. For three hours `@bongos/core` received nothing. It was found
+because a person happened to read the npm version list and noticed a hole between
+1.19.715 and 1.19.724 — ten days of exposure closed by luck.
+
+[Task 1003914](https://cloudbongos.com/builders#/task/1003914) fixed the *lossiness*:
+the bump commit is now pushed AFTER a successful publish, so a failure retries the same
+version instead of burning it. It deliberately left the *silence*, which is structural
+rather than an oversight — and every layer involved was working correctly:
+
+- a failed publish is one red row in the Actions tab, and nobody watches the Actions tab;
+- `main` keeps looking healthy, because the next work merge bumps past the failure and
+  publishes normally — the repo self-heals in a way that **erases the evidence**;
+- the lane's own `Publish verdict` step writes ✅/⬜ to the job summary, correctly, and
+  is read by nobody.
+
+This is the same shape as the nightly auto-upgrade sweep that died on 2026-08-25
+reporting `failed=0`. In both cases the machine knew and no human path existed.
+
+## Decision
+
+**A separate reader asks the registry what the lane only ever asserted.** Two sources
+that should agree: *announced* — every version a `release: core X.Y.Z` commit exists
+for — and *published*, what the registry actually holds. A version in the first and not
+the second is a **phantom**.
+
+**"Announced" is deliberately BROADER than the publisher's own `RELEASE_COMMIT_RE`, and
+the gap between the two questions is the reason.** That constant is narrow by design: it
+is the cascade terminator, and it must *not* match a human release commit, because a
+human release is a version that still needs publishing. That is the correct answer to
+the publisher's question ("is this HEAD already done?") and the wrong answer to this
+one ("what did we tell the world we released?"). Human carriers exist on main —
+`release: core 1.19.3 — CLI/init ergonomics carrier`, `release: core 1.18.19 — carrier
+bump for the 32 commits since 1.18.18` — and `publish.yml` fires on any main HEAD with a
+bumped `CORE_VERSION`, hand-edited or not. Matching only the CI shape would have left a
+failed *human* release invisible to the very check meant to catch a failed release. The
+watcher therefore anchors on `^release: core <semver> ` (so a commit merely quoting a
+release line cannot match) and records which lane announced each version, so a finding
+can say which one broke.
+
+**Why this can exist now, when the publisher's own design says it cannot.** The lane
+publishes through OIDC trusted publishing, which carries no read credential and
+authenticates `npm publish` and nothing else; that is precisely why
+`laneReleasedVersions` infers released versions from git rather than asking the
+registry. **That constraint never bound a reader.** Since
+[task 1003872](https://cloudbongos.com/builders#/task/1003872) the package is public, so
+an anonymous read needs no credential at all (verified 2026-09-16). The publisher must
+still infer; the watcher can simply look. Keeping them separate is the point — a lane
+that graded its own homework is what produced the silence.
+
+**Daily, not hourly, and stated as a cost trade rather than a preference.** Actions
+minutes on this repo are billable and already oversubscribed. Hourly is ~720 runs a
+month; a publish outage is measured in hours (09:54→13:02), so a daily sweep bounds the
+silence to about a day where the alternative was ten days and luck. Raise it if a second
+outage is missed. The cadence and the cron are pinned to each other by
+`routine-schedule.js`, so they cannot drift apart silently.
+
+**Deliberately NOT on the session-start path.** `deploy-divergence.js` already runs
+there and would have been the cheapest place to surface this, but it would put a network
+call to a third party on the hot path of every session start, behind a hook timeout. A
+check that makes every session slower is one someone eventually removes.
+
+**A healthy day says nothing.** Findings go to stdout, which `run-routine.js` posts to
+Discord `#ship-news`; the healthy line goes to stderr, so a person running it by hand
+still sees it and the channel does not accrue a daily "all fine". A channel of
+reassurances is a channel nobody reads, which is the failure being fixed.
+
+## Two ways this could cry wolf, and what stops each
+
+**A closed incident is permanent git history.** 1.19.716..723 are announced-and-absent
+today and always will be; an all-history check would fire forever. Only the last 3 days
+are considered — **by time, not by a commit count**, which a burst of releases would
+outrun (the rate varies from ~5 to ~20 a day).
+
+**npm acknowledges a publish before its listing shows it** — the CLI says so outright:
+*"Your package is being processed and may take a few minutes to become available."* This
+was not reasoned about in advance; **the check found it by running.** On its first live
+run it flagged 1.19.794 as a phantom fifteen minutes after a publish whose own log ended
+`published @bongos/core@1.19.794` and whose per-version endpoint answered 200 while the
+aggregate listing still omitted it. Untreated, it would have alarmed on every healthy
+release — a self-defeating monitor. Two guards: a **30-minute grace period**, and a
+**per-version confirmation** before anything is called a phantom. The aggregate listing
+only ever nominates suspects; it never returns a verdict.
+
+## Consequences
+
+- **A failed read is never a clean result.** `publishedVersions` throws rather than
+  returning an empty list. Exit codes are the contract: 0 clean, 1 found **and
+  delivered**, 2 could not run, 3 found and could **not** deliver. 2 and 3 are red.
+  Reporting an unreachable registry as "nothing missing" is exactly the `failed=0` bug
+  that hid the upgrade sweep's death; exit 3 is the same principle applied to the alarm
+  itself, since a finding that reached nobody has reproduced the original defect.
+- **The scheduler calls the script directly rather than through `run-routine.js`, which
+  every other routine uses.** Not a shortcut — a correction, and the second bug this work
+  found by running rather than reading. `run-routine` shells out with `execFileSync`
+  (throws on any non-zero exit) and its catch does an unconditional `process.exit(1)`, so
+  a real exit 2 or 3 arrives at the workflow as 1: the two cases that must be loud would
+  have printed a reassuring notice and gone green. Measured, not inferred — a forced
+  exit-3 run returns 1 through `run-routine` and 3 directly. The same property made the
+  first wiring drop findings entirely: `run-routine` aborts a failed step *before*
+  routing its stdout, so the original `sink: discord` step would have thrown away every
+  finding it produced. The script now delivers for itself. Where a routine's exit code
+  carries meaning, `run-routine` is the wrong harness.
+- **The alarm is armed but mute until one owner action.** The repo has no
+  `DISCORD_SHIP_NEWS_WEBHOOK` secret (checked 2026-09-16), so a real finding takes the
+  exit-3 path — loud in CI, absent from Discord. Adding that secret is the whole fix.
+- **The detector is proven against a real failed publish, not a synthetic one.**
+  `tests/publish_watch.mjs` replays the 2026-09-13 outage out of this repo's history and
+  the live registry: the eight carrier commits exist, the eight versions do not, the
+  check names all eight as of that date and is quiet about them today.
+- **It does not detect a lane that has stopped being TRIGGERED.** It compares what was
+  announced against what was delivered; a publish workflow that never fires announces
+  nothing and looks identical to a quiet day. That is a different check.
+- Rejected: asking the registry from inside the publish lane (it has no read credential,
+  and self-witnessing is the original defect); an all-history sweep (permanent false
+  alarm); hourly (cost, for a failure measured in hours); wiring it into session start
+  (a third-party network call on every session's hot path).

package/docs/adr/README.md

@@ -386,3 +386,4 @@ This keeps the decision history honest and traceable.
 | 0292 | [**Both install paths stay, and vendoring turns out to be the production one** ([task 1003879](https://cloudbongos.com/builders#/task/1003879), goal 1000090 — public-npm **gate 6**, the decision row held back from gate 5's mechanical cleanup because both candidates were large deletions that could as easily be mistakes). Gate 6 framed the **vendored-tarball path** (~124 refs across `upgrade.js`/`init.js`/`provision-repo.js`/`package-core.js`) as insurance for hosts that cannot reach npm, to be weighed against the AGPL self-host promise. Read that way it loses. **That is not what the code does with it:** `provision-repo.js` resolves the core for every wizard-created project as "a tarball built from THIS CHECKOUT, file:-pinned", with `--registry-core` as the opt-out — vendoring is the production provisioning path, not the fallback, and deleting it breaks project creation. `resolveVendorableCoreTarball`'s three-rung ladder (reuse the control plane's own pinned tarball → pack the core it has INSTALLED → rebuild from source) exists to answer one question a registry install cannot express: *what is the control plane actually running?* Rungs 1 and 2 each name the bug they fixed — empty new repos when the runner is itself a consumer (task 1002275), and "the frozen-old-tarball births" (task 1002706). The owner's input — a checkout routinely runs ahead of the registry — holds, though not via `main`: since publish-on-merge, 136 of the last 300 `main` commits are release bumps, releases land every 9–51 min, and `main`'s `CORE_VERSION` equalled the registry `latest` (1.19.785) when this was written. Provisioning does not provision from `main`; it provisions from the control plane's own tree, and an unmerged branch or a deliberately-held pin exists on the registry at NO version, ever. **Supersedes ADR 0134's "vendored is the default until the registry path is proven end-to-end" clause:** the condition is MET twice over — with a token 2026-07-08 (task 2118 / blocker 71) and tokenless since [ADR 0283](0283-the-core-publishes-publicly-because-access-was-never-the-thing-protecting-it.md) (`npm pack @bongos/core` from a clean `HOME` fetches 25.5 MB) — and the default stands anyway, for load-bearing reasons rather than for want of proof. Costs accepted with open eyes: ~124 refs, a second install mode every scaffold/upgrade/provision path must keep straight, a Windows-only test failure ([task 1003839](https://cloudbongos.com/builders#/task/1003839)), `refreshStandaloneCorePin`. **Candidate 2 — `@cloudbongos/cli` — also STAYS, on a NEW justification:** task 1003872 was right that the original reason (reaching the board without a private-registry credential) is gone, so it needs one of its own, and the measurement supplies it — 32 files / 0.5 MB / `undici`, versus the core's 2,611 files / 46.4 MB / `express`+`pg`+`pino`. Collapsing it would make `npx` a 46 MB download dragging in a web server and a Postgres driver to print a task list. **Unpublishing was never on the table** (public at 0.1.3, strangers may have installed it); [ADR 0258](0258-the-public-cli-is-a-generated-client-package-not-the-published-core.md) stands with its *rationale* amended — a deliberately small entry point, no longer a private-core workaround. The one real rot the flip left is rung 2's stale "still-private registry package" clause, a comment. **Gate 6 closes keep/keep, no removal task.** Reopens if provisioning ever stops meaning "match the control plane".](0292-both-install-paths-stay-and-vendoring-is-the-production-one.md) | distribution / provisioning |
 | 0293 | [**The owner's deploy door is an INTENT the control plane drains, not a web tier with a shell** ([task 1003159](https://cloudbongos.com/builders#/task/1003159), goal 1000090). The owner, twice in a month: *"I don't think I can make anything live"*, then *"this is above my paygrade"*. Moving a core pin is gate 3 of the release pipeline and the ONLY act that makes shipped work visible to users — and it was reachable from exactly one place: a shell on the control-plane box holding an ssh key. No route, no hall control. An agent could not close the loop either, because the permission classifier blocks a mutating `sudo -u lars` over ssh BY DESIGN — so the gate had no owner-reachable control AND no agent-reachable one, which is a structural mismatch with a platform whose premise is that agents build and the human holds the gates. Measured cost the day it was written: cloudbongos.com served 1.19.754 while 1.19.757, carrying a shipped fix to the claimable-task feed, sat published and unreachable. **Decision: the door is an INTENT the control-plane runner drains** — the seam [ADR 0111](0111-instance-hosting-provisioning-module.md) already built and that provision/teardown/domain-attach/settings-apply/restart already ride; `enqueueIntent` already carries `requested_by`, so the actor requirement is met by the existing shape rather than bolted on. The web tier gains no sudo, no ssh key, no new capability — it gains the ability to ASK. Rejected: giving the web tier sudo (ADR 0043 makes the control plane a separate privilege domain precisely so compromising the HTTP-reachable process does not hand over the box), and a second bespoke queue (another set of claim/settle/retry semantics to get right, when this one's failure modes are already understood in production). **The control plane is enrolled as a SELF ROW** because `provisioning_intents.instance_id` is NOT NULL and the box has never had one — which is exactly why the door had nothing to point at. That same row puts a teardown button one query away from the platform, so `hosting_shape='control-plane'` is a distinct value every destructive leg can refuse BY NAME, and the rule is an ALLOW-list (`core-upgrade`, `restart`) rather than a deny-list of today's destructive actions: a deny-list would admit tomorrow's by omission, and "permitted by omission" here means the platform deleting itself. A partial unique index makes a second self row impossible. Rejected: a nullable `instance_id` meaning "the control plane" (an implicit encoding that reads as a bug at every later call site and silently widens every query assuming the FK holds). **The target version comes from the published registry, never the request** — not tidiness: the release lane mints a git tag BEFORE the npm publish completes (measured 8–13 minutes on 2026-09-16 against ~100s recorded earlier, learnings 1000263/1000266), so a door trusting "whatever main says" would routinely queue a version that does not exist and die on `npm error notarget`. **Two-step preview-then-confirm**, the owner's own call: auto-rollback already guards the bad-release case, this guards the different one — the wrong button. **Archon-gated server-side, no caching** (ADR 0016), with `core_241` giving the ledger an actor and a source, because a privileged action with an unattributed row is not acceptable and the table carried only a free-text note. **Truth is the BOX's `/version`, not the apex** (the apex sits behind pre-launch basic_auth and its HTML rides a CDN, so an apex read reports a stale answer with total confidence). Self-restart is safe for a stated reason rather than an assumed one: the runner and the web service are DIFFERENT systemd units, and a running process keeps the code it already loaded, so an upgrade rewriting the runner's own files takes effect next tick, never mid-run. Tenant instances ride the same queue and are a filed follow-up. What it does NOT do: make deploys automatic — ADR 0137's three gates stand, and this only gives the third a handle.](0293-the-owners-deploy-door-is-an-intent-the-control-plane-drains.md) | deploy / authority / provisioning |
 | 0294 | [**CLI sessions do not expire; revocation is the whole remedy** ([task 1003956](https://cloudbongos.com/builders#/task/1003956), goal 1000110 — owner request 2026-09-16, after a three-week gap signed him out). A `bongos` sign-in died after 24h idle: `createSession` defaulted a null `expiresAt` to `now()+SESSION_TTL_MS` and `lookupSession` rewrote `expires_at = now()+24h` on every request. **This is the third argument about the number and the first about the mechanism** — V3.R38 ([task #259](https://cloudbongos.com/builders#/task/259), migration 035) set 1h, V3.R90 ([task 1000400](https://cloudbongos.com/builders#/task/1000400)) widened it to 24h because 1h "kicked builders out over lunch", and each round shortened the nuisance while leaving the mechanism alone. The hygiene case for keeping it (criterion C9 — bound a leaked token in the mode-0600 plaintext session file) **does not survive contact with refresh-on-use**: a leaked token is by definition one somebody is using, and every use rolled the expiry forward another day, so the timer could only ever fire on a session gone quiet — the legitimate holder stepping away. The control was aimed at attackers and landed exclusively on users. [ADR 0206](0206-own-scoped-session-revocation-no-absolute-ceiling.md) had already written half of this down ("a CLI bearer in daily use is, in practice, immortal") without drawing the conclusion. Decision: **CLI sessions carry no expiry and last until revoked.** `createSession` records `expires_at = NULL` when the caller names none — every such call site is `source: 'cli'` (device flow, federated sign-in, hall re-issue, dev-box pair) — and `lookupSession` still bumps `last_used_at` but rolls `expires_at` forward only via `CASE WHEN expires_at IS NULL THEN NULL ELSE …`; **without that CASE the first request after sign-in re-mints the very timeout this removes.** Migration `core_243` clears `expires_at` on live unrevoked `source='cli'` rows, so the change reaches existing sessions instead of charging every builder one last forced re-auth on deploy day — migration 035's grace inverted, for the reason 035 gave. **Browser sessions are untouched** (they pass an explicit 30 days, so the new default never reaches them, and the migration's `source='cli'` filter is its whole safety property — `lookupSession` only rolls an expiry it can already see, so a web row cleared by mistake stays cleared forever). `SESSION_TTL_MS` survives as the roll-forward window for rows that have an expiry, no longer as a default. The accepted cost, stated plainly: **a leaked CLI token is valid until revoked** — smaller in practice than it sounds, since under refresh-on-use an actively-used leak was already immortal, so what changes is the *abandoned* copy on a dead laptop. The remedy is ADR 0206's own-scoped revoke, immediate where a TTL is next-day, and that ADR's visibility half (`created_at` beside `last_used_at`) is now the primary control rather than a nice-to-have. Nothing about rank moves: `setBuilderRank` still sweeps on demotion and `requireBuilder` still refuses a deactivated builder on the hot path, neither consulting `expires_at`. Rejected: widening the TTL a fourth time; keeping it and making re-auth cheaper (already built — [task 1000401](https://cloudbongos.com/builders#/task/1000401), [task 1000504](https://cloudbongos.com/builders#/task/1000504) — the friction shrank, the interruption stayed); an absolute `created_at` ceiling (ADR 0206's reasoning holds unchanged); dropping the column (load-bearing for web); a blanket `UPDATE … SET expires_at = NULL`. Revisit for machine principals nobody will notice a leak on, a compliance maximum, or long-dead sessions accumulating faster than people prune them.](0294-cli-sessions-do-not-expire.md) | auth / account security / CLI |
+| 0295 | [**The registry is the witness the publish lane cannot be** ([task 1003916](https://cloudbongos.com/builders#/task/1003916), goal 1000090). On 2026-09-13 eight publish runs failed over three hours and NOTHING reported it; it was found by a person idly reading the npm version list. Task 1003914 fixed the lossiness and left the silence, which is structural: a failed run is one red row nobody watches, `main` self-heals on the next merge and **erases the evidence**, and the lane's own verdict step writes to a job summary no one reads. Same shape as the nightly upgrade sweep that died reporting `failed=0`. **Decision: a separate reader compares what the lane ANNOUNCED (release commits) against what the registry HOLDS**; the difference is a phantom. The publisher infers from git because OIDC trusted publishing carries no read credential — **that never bound a reader**, and since task 1003872 the package is public, so an anonymous read needs none. Keeping witness and publisher separate IS the point. Daily not hourly (billable minutes, against a failure measured in hours), cadence pinned to the cron by `routine-schedule.js`; deliberately NOT on the session-start path (a third-party call behind a hook timeout). Healthy days are SILENT in Discord — findings to stdout, the all-clear to stderr — because a channel of reassurances stops being read. Two false-alarm sources, each guarded: a closed incident is permanent history (a 3-day window, by TIME not commit count, which a release burst would outrun), and **npm acknowledges a publish before its listing shows it** — found by RUNNING the check, which flagged 1.19.794 fifteen minutes after a publish whose log ended `published @bongos/core@1.19.794` and whose per-version endpoint answered 200; hence a 30-minute grace period plus per-version confirmation, with the listing only ever nominating suspects. A failed read throws rather than reading as "nothing missing". Proven by replaying the REAL outage from git + the live registry, not a synthetic failure. Does NOT detect a lane that stopped being triggered.](0295-the-registry-is-the-witness-the-lane-cannot-be.md) | release / observability |

package/docs/file-map.md

@@ -457,6 +457,7 @@ tests/
 ├── overnight-builder/SKILL.md         ← autonomous overnight session-runner — claims the highest-priority safe task, works it end-to-end and ships it; autonomy-gated and OFF by default (restored in task 1003365; unscheduled in core — only redteam-weekly has a firing workflow; config/scheduled-routines.json records the intended cadence)
 ├── overnight-code-review/SKILL.md     ← nightly autonomous code-quality review; each finding lands as its own idea_inbox row so it survives triage; autonomy-gated and OFF by default (restored in task 1003365; unscheduled in core — only redteam-weekly has a firing workflow; config/scheduled-routines.json records the intended cadence)
 ├── peer-vote-tally/SKILL.md           ← deterministic tally (`tally.js`) folding builder-on-builder peer votes at least 7 days old into karma_log rows (criterion C2) (restored in task 1003365; unscheduled in core — only redteam-weekly has a firing workflow; config/scheduled-routines.json records the intended cadence)
+├── publish-watch/SKILL.md             ← daily publish-lane check (task 1003916): compares every version the release lane ANNOUNCED in its own release commits against what the registry actually holds, and posts anything announced-but-never-delivered to Discord #ship-news. Exists because the 2026-09-13 outage (8 failed runs, 3 hours) was found by a person reading the npm version list — a failed run is one red row nobody watches, and the next merge erases the evidence. Silent on a healthy day by design; exit 2 (could not read) is distinct from exit 1 (found one).
 ├── rank-roles-audit/SKILL.md          ← nightly deterministic check that every builder holds one of the four live ranks, so none silently resolves to zero permissions under the governance_002 backfill's INNER JOIN; detect-only, files one idea_inbox row and never repairs, and never fatal at boot (task 1002873; unscheduled in core — only redteam-weekly has a firing workflow; config/scheduled-routines.json records the intended cadence)
 ├── redteam-weekly/SKILL.md            ← weekly deterministic red-team patrol (task 1003128): full-history gitleaks scan + dependency drift review (audit delta, cooldown, young pkgs, stale overrides) + action-pin check → files security reports (advisory, ADR 0162). FIRED BY .github/workflows/redteam-patrol.yml, Mondays 06:17 UTC — `cadence: weekly` here and that cron must agree or fitness Check 25 (scripts/gds/routine-schedule.js) fails the gate (task 1003209, ADR 0188)
 ├── repo-simplify-sweep/SKILL.md       ← weekly repo-cleanliness janitor — runs repo-metrics, files dead-code findings to idea_inbox, and auto-fixes only the narrow safe class (restored in task 1003365; unscheduled in core — only redteam-weekly has a firing workflow; config/scheduled-routines.json records the intended cadence)

package/docs/module-api-changelog.md

@@ -2068,5 +2068,7 @@ is load-bearing: the script throws rather than guess if it is missing, and
         landed since 1.19.795 with no explicit bump. run 35169093667. (task 1002620)
   1.19.797 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
         landed since 1.19.796 with no explicit bump. run 35169694391. (task 1002620)
+  1.19.798 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.797 with no explicit bump. run 35170229509. (task 1002620)
 ---------------------------------------------------------------------------
 ```

package/package-lock.json

@@ -1,12 +1,12 @@
 {
   "name": "@bongos/core",
-  "version": "1.19.797",
+  "version": "1.19.798",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "@bongos/core",
-      "version": "1.19.797",
+      "version": "1.19.798",
       "license": "AGPL-3.0-or-later",
       "dependencies": {
         "express": "^4.21.2",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bongos/core",
-  "version": "1.19.797",
+  "version": "1.19.798",
   "description": "Cloud Bongos — the AI-first build platform core (GDS + platform surfaces + module system), installed as a versioned dependency (ADR 0108).",
   "license": "AGPL-3.0-or-later",
   "main": "src/platform-server.js",

package/scripts/gds/publish-watch.js

@@ -0,0 +1,268 @@
+#!/usr/bin/env node
+// scripts/gds/publish-watch.js — does the registry actually have what the lane
+// SAID it released? (task 1003916)
+//
+// WHY THIS EXISTS. On 2026-09-13 eight consecutive publish runs failed between
+// 09:54 and 13:02 UTC on a mis-scoped leak gate. Nothing reported that the
+// registry had stopped receiving releases for three hours. It was found by
+// someone idly reading the npm version list and noticing a hole. Task 1003914
+// fixed the LOSSINESS (the bump is no longer pushed before the publish, so a
+// failure retries the same version instead of burning it) and deliberately left
+// the SILENCE, which is this task.
+//
+// The silence is structural, not an oversight:
+//   • a failed publish is a red run in the Actions tab, and nobody watches it;
+//   • `main` keeps looking healthy — the next work merge bumps past the failure
+//     and publishes normally, so the repo self-heals in a way that ERASES the
+//     evidence;
+//   • the lane's own `Publish verdict` step writes ✅/⬜ to the job summary,
+//     which is correct and read by nobody.
+//
+// WHAT CHANGED, AND WHY THIS IS NOW A THREE-LINE QUESTION. The lane cannot ASK
+// the registry whether a version is published: publishing via OIDC trusted
+// publishing means there is no read credential, and OIDC authenticates
+// `npm publish` and nothing else. That constraint is what pushed
+// laneReleasedVersions onto a git-log derivation (see bump-version.js).
+// It no longer binds a READER. Post-task 1003872 `@bongos/core` is PUBLIC, so an
+// anonymous `npm view` needs no credential at all — verified 2026-09-16, and the
+// reason this check can exist as a plain comparison rather than an inference.
+//
+// THE COMPARISON. Two independent sources that should agree:
+//   announced — every version the lane wrote a release commit for, read from git
+//               via bump-version.js's RELEASE_COMMIT_RE. Deliberately the SAME
+//               constant the lane itself uses, so an announcement shape can
+//               never mean one thing to the publisher and another here.
+//   published — every version actually on the registry (anonymous read).
+// A version in `announced` and not in `published` is a PHANTOM: the lane said it
+// shipped something it never delivered. 1.19.716..723 are exactly that, and are
+// still observable today — tests/publish_watch.mjs pins the detector against
+// that real history rather than a synthetic failure.
+//
+// WHY A TIME WINDOW, NOT ALL OF HISTORY. The 2026-09-13 phantoms are permanent
+// git history: an all-history check would fire forever on a closed incident and
+// train the owner to scroll past it — the precise failure this task exists to
+// prevent. The window is by TIME rather than by count so it cannot be outrun by
+// a burst of releases (the rate varies from ~5 to ~20 a day).
+'use strict';
+
+const { execFileSync } = require('child_process');
+const path = require('path');
+const { RELEASE_COMMIT_RE } = require(path.join(__dirname, 'bump-version.js'));
+
+const REPO_ROOT = path.resolve(__dirname, '..', '..');
+const PKG = '@bongos/core';
+const DEFAULT_WINDOW_DAYS = 3;
+// npm acknowledges a publish before the aggregate listing shows it: the CLI
+// prints "Your package is being processed and may take a few minutes to become
+// available." A version announced inside this grace period is therefore not yet
+// evidence of anything. Found by RUNNING this check (2026-09-16): it flagged
+// 1.19.794 as a phantom fifteen minutes after a publish whose own log ended
+// `published @bongos/core@1.19.794`, and whose per-version endpoint answered 200.
+const DEFAULT_GRACE_MINUTES = 30;
+const GIT_TIMEOUT_MS = 15000;
+const NPM_TIMEOUT_MS = 60000;
+
+// WHAT COUNTS AS AN ANNOUNCEMENT — deliberately BROADER than the publisher's
+// own RELEASE_COMMIT_RE, and the difference is the point.
+//
+// RELEASE_COMMIT_RE is narrow BY DESIGN: it is the cascade terminator, and it
+// must not match a human release commit, because a human release is a version
+// that still needs publishing (see bump-version.js). That is the right answer to
+// the publisher's question ("is this HEAD already done?").
+//
+// It is the WRONG answer to this file's question ("what did we tell the world we
+// released?"). A human carrier announces a release just as loudly —
+// `release: core 1.19.3 — CLI/init ergonomics carrier (task 1002631)`,
+// `release: core 1.18.19 — carrier bump for the 32 commits since 1.18.18` — and
+// publish.yml fires on any main HEAD with a bumped CORE_VERSION, hand-edited or
+// not. Matching only the CI shape would have left a failed HUMAN release
+// invisible to the exact check meant to catch a failed release.
+//
+// So: anchored at `^` so a commit merely QUOTING a release line cannot match
+// (tested), version-shaped, and each entry records WHICH lane announced it so a
+// finding can say so.
+const ANNOUNCED_RE = /^release: core (\d+\.\d+\.\d+) /;
+
+// Pure. Release commits newest-first, as {version, sha, iso, lane}, parsed from
+// `git log --format=%H|%cI|%s`.
+function parseAnnounced(logText) {
+  const out = [];
+  for (const raw of String(logText == null ? '' : logText).split('\n')) {
+    const line = raw.trim();
+    if (!line) continue;
+    const parts = line.split('|');
+    if (parts.length < 3) continue;
+    const [sha, iso] = parts;
+    const subject = parts.slice(2).join('|');
+    const m = ANNOUNCED_RE.exec(subject);
+    if (!m) continue;
+    out.push({
+      version: m[1],
+      sha,
+      shortSha: sha.slice(0, 8),
+      iso,
+      lane: RELEASE_COMMIT_RE.test(subject) ? 'ci' : 'human',
+    });
+  }
+  return out;
+}
+
+// Pure, and the whole verdict. `published` is any iterable of version strings.
+function phantoms({ announced = [], published = [], now = new Date(), windowDays = DEFAULT_WINDOW_DAYS, graceMinutes = DEFAULT_GRACE_MINUTES } = {}) {
+  const have = new Set(Array.from(published, (v) => String(v)));
+  const nowMs = new Date(now).getTime();
+  const cutoff = nowMs - windowDays * 86400000;
+  const graceEdge = nowMs - graceMinutes * 60000;
+  const considered = [];
+  const missing = [];
+  const settling = [];
+  for (const rel of announced) {
+    const t = Date.parse(rel.iso);
+    if (!Number.isFinite(t) || t < cutoff) continue;
+    considered.push(rel);
+    if (have.has(rel.version)) continue;
+    // Too fresh to judge — the registry may simply not have finished processing.
+    if (t > graceEdge) { settling.push(rel); continue; }
+    missing.push(rel);
+  }
+  return { considered, missing, settling, windowDays, graceMinutes, cutoffIso: new Date(cutoff).toISOString() };
+}
+
+// execFileSync, NOT execSync: the `%H|%cI|%s` format is full of pipes, and a
+// shell splits the command on them into a nonsense pipeline. Caught by running
+// it (exit 2, "could not complete") rather than by reading it.
+function gitLog(ref, { days, cwd = REPO_ROOT } = {}) {
+  const args = ['log', ref];
+  if (days) args.push(`--since=${days + 1} days ago`);
+  args.push('--format=%H|%cI|%s');
+  return execFileSync('git', args, {
+    cwd, encoding: 'utf8', stdio: ['ignore', 'pipe', 'ignore'],
+    maxBuffer: 256 * 1024 * 1024, timeout: GIT_TIMEOUT_MS,
+  });
+}
+
+// Anonymous registry read. Throws on failure — a read that did NOT happen must
+// never be reported as "nothing missing" (the accounting bug that let the
+// nightly upgrade sweep die reporting failed=0 on 2026-08-25).
+function publishedVersions(pkg = PKG) {
+  const raw = execFileSync('npm', ['view', pkg, 'versions', '--json'], {
+    encoding: 'utf8', stdio: ['ignore', 'pipe', 'pipe'],
+    maxBuffer: 64 * 1024 * 1024, timeout: NPM_TIMEOUT_MS,
+  });
+  const parsed = JSON.parse(raw);
+  const list = Array.isArray(parsed) ? parsed : [parsed];
+  if (!list.length) throw new Error(`registry returned no versions for ${pkg}`);
+  return list;
+}
+
+// The aggregate listing is a CANDIDATE source, never a verdict: it lags a
+// publish by minutes. This asks the registry about one exact version, which does
+// not lag — the endpoint answered 200 for 1.19.794 while the listing still
+// omitted it. Returns true only on a clear "it is there"; a thrown request is
+// reported as still-missing by the caller, never silently as present.
+function versionIsPublished(pkg, version) {
+  try {
+    const out = execFileSync('npm', ['view', `${pkg}@${version}`, 'version'], {
+      encoding: 'utf8', stdio: ['ignore', 'pipe', 'pipe'], timeout: NPM_TIMEOUT_MS,
+    });
+    return String(out).trim() === String(version);
+  } catch {
+    return false;
+  }
+}
+
+function check({ ref = 'origin/main', windowDays = DEFAULT_WINDOW_DAYS, now = new Date(), pkg = PKG, graceMinutes = DEFAULT_GRACE_MINUTES, confirm = versionIsPublished } = {}) {
+  const announced = parseAnnounced(gitLog(ref, { days: windowDays }));
+  const published = publishedVersions(pkg);
+  const r = phantoms({ announced, published, now, windowDays, graceMinutes });
+  // Confirm each candidate individually before calling it a phantom. Only runs
+  // on suspects, so a healthy lane costs exactly one registry read.
+  const confirmed = [];
+  const lagging = [];
+  for (const cand of r.missing) (confirm(pkg, cand.version) ? lagging : confirmed).push(cand);
+  return { pkg, ref, ...r, missing: confirmed, lagging, publishedCount: published.length };
+}
+
+// One line when healthy; the roll-call when not. Written for Discord #ship-news,
+// so it stays plain language — the owner reads that channel, not this file.
+function report(r) {
+  if (!r.missing.length) {
+    const extra = [];
+    if (r.settling && r.settling.length) extra.push(`${r.settling.length} still settling`);
+    if (r.lagging && r.lagging.length) extra.push(`${r.lagging.length} present but not yet in the listing`);
+    const tail = extra.length ? ` (${extra.join('; ')})` : '';
+    return `Publish lane healthy — all ${r.considered.length} release(s) announced in the last ${r.windowDays} days are on the registry${tail}.`;
+  }
+  const lines = [
+    `⚠ The publish lane announced ${r.missing.length} release(s) it never delivered to the registry.`,
+    '',
+    `Anyone installing ${r.pkg} cannot get ${r.missing.length === 1 ? 'this version' : 'these versions'}:`,
+  ];
+  for (const m of r.missing) lines.push(`  • ${m.version} — announced ${m.iso.slice(0, 16).replace('T', ' ')}Z by commit ${m.shortSha}${m.lane === 'human' ? ' (hand-cut release)' : ''}`);
+  lines.push('', 'A publish run failed and the next merge will paper over it. Check the publish workflow runs for that window.');
+  return lines.join('\n');
+}
+
+// Deliver the finding ourselves rather than via run-routine.js's `sink: discord`.
+// WHY: run-routine treats a non-zero step as a FAILED step and aborts before it
+// routes stdout anywhere — so exit 1 ("found a phantom") would have thrown the
+// finding away instead of posting it. Caught by running the routine with a
+// forced finding and no webhook (2026-09-16). artifact-audit has the same shape
+// for the same reason: the script performs its own side effect and the routine
+// step stays `sink: none`.
+async function deliver(text) {
+  const { postWebhook } = require(path.join(__dirname, '..', 'discord', 'lib.js'));
+  await postWebhook('ship_news', text);
+}
+
+async function main() {
+  const argv = process.argv.slice(2);
+  const arg = (f, d) => { const i = argv.indexOf(f); return i >= 0 && argv[i + 1] ? argv[i + 1] : d; };
+  const windowDays = Number(arg('--window-days', DEFAULT_WINDOW_DAYS));
+  const graceMinutes = Number(arg('--grace-minutes', DEFAULT_GRACE_MINUTES));
+  const ref = arg('--ref', 'origin/main');
+  const json = argv.includes('--json');
+
+  let r;
+  try {
+    r = check({
+      ref,
+      windowDays: Number.isFinite(windowDays) && windowDays > 0 ? windowDays : DEFAULT_WINDOW_DAYS,
+      graceMinutes: Number.isFinite(graceMinutes) && graceMinutes >= 0 ? graceMinutes : DEFAULT_GRACE_MINUTES,
+    });
+  } catch (err) {
+    // Exit 2 = COULD NOT RUN. Distinct from 1 (ran, found something) so a
+    // scheduler can go red on the former and merely report the latter.
+    console.error(`publish-watch could not complete: ${err && err.message ? err.message : err}`);
+    process.exit(2);
+  }
+
+  const text = report(r);
+  if (json) { console.log(JSON.stringify(r, null, 2)); process.exit(r.missing.length ? 1 : 0); }
+
+  // A healthy day is deliberately quiet: it reports to a person running this by
+  // hand (stderr) and posts nothing. A daily "all fine" in #ship-news is how the
+  // channel becomes wallpaper, which is the failure this check exists to fix.
+  if (!r.missing.length) { console.error(text); process.exit(0); }
+
+  console.log(text);
+  if (argv.includes('--no-post')) process.exit(1);
+
+  try {
+    await deliver(text);
+    console.error('posted the finding to Discord #ship-news.');
+    process.exit(1);
+  } catch (err) {
+    // FOUND SOMETHING AND COULD NOT SAY IT. This is the original defect one
+    // layer down, so it must be the LOUDEST outcome, not the quietest: exit 3
+    // is >= 2, which turns the scheduled run red. A finding that reached nobody
+    // is not a successful run.
+    console.error(`\nFOUND A PHANTOM AND COULD NOT DELIVER IT: ${err && err.message ? err.message : err}`);
+    console.error('The finding is above. Set DISCORD_SHIP_NEWS_WEBHOOK (repo secret) so this reaches #ship-news.');
+    process.exit(3);
+  }
+}
+
+if (require.main === module) main();
+
+module.exports = { ANNOUNCED_RE, parseAnnounced, phantoms, publishedVersions, versionIsPublished, check, report, DEFAULT_WINDOW_DAYS, DEFAULT_GRACE_MINUTES, PKG };

package/src/module-api.js

@@ -71,7 +71,7 @@ const { responsibilityFor, ROLE_RESPONSIBILITIES } = require('./role-responsibil
 // there. scripts/gds/bump-version.js still rewrites the literal below; it appends
 // the entry to that file. Look for a version's history there, not here.
 // ---------------------------------------------------------------------------
-const CORE_VERSION = '1.19.797'; // CI auto-patch carrier (ADR 0161); changelog: docs/module-api-changelog.md
+const CORE_VERSION = '1.19.798'; // CI auto-patch carrier (ADR 0161); changelog: docs/module-api-changelog.md
 
 // A namespaced logger so a module's log lines are attributable + consistent.
 // Usage: const log = api.logger('dev-box'); log.info('mounted');

package/tests/publish_watch.mjs

@@ -0,0 +1,158 @@
+// tests/publish_watch.mjs — the publish-lane silence detector (task 1003916).
+//
+// The LIVE test at the bottom replays the REAL 2026-09-13 incident out of this
+// repo's own history and the real registry, rather than a synthetic failure:
+// eight release commits (1.19.716..723) exist on main and those eight versions
+// are absent from npm to this day. That is a genuinely failed publish preserved
+// in evidence, which is a stronger proof than one manufactured here.
+import test from 'node:test';
+import assert from 'node:assert/strict';
+import path from 'node:path';
+import { execFileSync } from 'node:child_process';
+import { createRequire } from 'node:module';
+
+const require = createRequire(import.meta.url);
+const ROOT = path.resolve(import.meta.dirname, '..');
+const pw = require(path.join(ROOT, 'scripts', 'gds', 'publish-watch.js'));
+
+const REL = (v, iso, sha = 'abcdef1234567890') =>
+  `${sha}|${iso}|release: core ${v} — CI auto-patch carrier (publish-on-merge, ADR 0161)`;
+
+test('parseAnnounced reads BOTH lanes — a hand-cut release announces too', () => {
+  // Deliberately broader than the publisher's RELEASE_COMMIT_RE: that constant is
+  // the cascade terminator and must NOT match a human release, but a human
+  // release is still an announcement, and a failed one is exactly what this
+  // check exists to catch. Real examples on main: 1.19.3, 1.18.19.
+  const log = [
+    REL('1.19.700', '2026-09-13T07:00:00Z'),
+    'deadbeefdeadbeef|2026-09-13T07:05:00Z|fix(auth): something unrelated (task 1)',
+    'cafebabecafebabe|2026-09-13T07:10:00Z|release: core 1.20.0 — carrier for the init-blocker fixes (task 1002624)',
+    REL('1.19.701', '2026-09-13T07:15:00Z'),
+  ].join('\n');
+  const got = pw.parseAnnounced(log);
+  assert.deepEqual(got.map((r) => r.version), ['1.19.700', '1.20.0', '1.19.701']);
+  assert.deepEqual(got.map((r) => r.lane), ['ci', 'human', 'ci']);
+});
+
+test('a failed HUMAN release is reported, and named as hand-cut', () => {
+  const announced = pw.parseAnnounced('cafebabecafebabe|2026-09-10T07:10:00Z|release: core 1.20.0 — carrier for the init-blocker fixes (task 1002624)');
+  const r = pw.phantoms({ announced, published: [], now: new Date('2026-09-10T12:00:00Z') });
+  assert.deepEqual(r.missing.map((m) => m.version), ['1.20.0']);
+  assert.match(pw.report(r), /hand-cut release/);
+});
+
+test('parseAnnounced does not match a subject merely QUOTING a release line', () => {
+  const log = 'aaaabbbbccccdddd|2026-09-13T07:00:00Z|docs: explain "release: core 1.19.9 — CI auto-patch carrier (publish-on-merge"';
+  assert.deepEqual(pw.parseAnnounced(log), []);
+});
+
+test('a delivered lane is silent', () => {
+  const announced = pw.parseAnnounced([REL('1.19.700', '2026-09-16T10:00:00Z'), REL('1.19.701', '2026-09-16T11:00:00Z')].join('\n'));
+  const r = pw.phantoms({ announced, published: ['1.19.700', '1.19.701'], now: new Date('2026-09-16T12:00:00Z') });
+  assert.equal(r.missing.length, 0);
+  assert.equal(r.considered.length, 2);
+  assert.match(pw.report(r), /healthy/);
+});
+
+test('an announced-but-undelivered version is reported, and named', () => {
+  const announced = pw.parseAnnounced([REL('1.19.700', '2026-09-16T10:00:00Z'), REL('1.19.701', '2026-09-16T11:00:00Z')].join('\n'));
+  const r = pw.phantoms({ announced, published: ['1.19.700'], now: new Date('2026-09-16T12:00:00Z') });
+  assert.deepEqual(r.missing.map((m) => m.version), ['1.19.701']);
+  const text = pw.report(r);
+  assert.match(text, /never delivered/);
+  assert.match(text, /1\.19\.701/);
+});
+
+test('the window ages a closed incident out, so it cannot cry wolf forever', () => {
+  const announced = pw.parseAnnounced(REL('1.19.716', '2026-09-13T09:54:30Z'));
+  const fresh = pw.phantoms({ announced, published: [], now: new Date('2026-09-13T18:00:00Z'), windowDays: 3 });
+  assert.equal(fresh.missing.length, 1, 'fires while the incident is recent');
+  const stale = pw.phantoms({ announced, published: [], now: new Date('2026-09-30T00:00:00Z'), windowDays: 3 });
+  assert.equal(stale.missing.length, 0, 'silent once it is old news');
+  assert.equal(stale.considered.length, 0);
+});
+
+test('a read that returned nothing must not read as "nothing missing"', () => {
+  // publishedVersions throws rather than returning [] — an empty registry answer
+  // and a healthy lane are the same shape otherwise, which is how the nightly
+  // upgrade sweep died reporting failed=0 on 2026-08-25.
+  assert.throws(() => pw.publishedVersions('@bongos/definitely-not-a-real-package-1003916'));
+});
+
+test('LIVE: replays the real 2026-09-13 publish outage from git + the registry', (t) => {
+  // The eight carrier commits exist on main...
+  // Bounded: this runs on every ordinary suite run, so it reads a window around
+  // the incident rather than the whole history.
+  const log = execFileSync('git', ['log', 'origin/main', '--since=2026-09-01', '--until=2026-09-20', '--format=%H|%cI|%s'], { encoding: 'utf8', cwd: ROOT, maxBuffer: 64 * 1024 * 1024 });
+  const announced = pw.parseAnnounced(log);
+  const incident = announced.filter((r) => {
+    const n = Number(r.version.split('.')[2]);
+    return r.version.startsWith('1.19.') && n >= 716 && n <= 723;
+  });
+  assert.equal(incident.length, 8, `expected the 8 carrier commits for 1.19.716..723, saw ${incident.length}`);
+
+  // ...and the registry does not have them, to this day. The registry is a third
+  // party on the ordinary suite path, so an unreachable one SKIPS rather than
+  // failing the suite — a flaky red teaches people to ignore a red.
+  let published;
+  try {
+    published = pw.publishedVersions();
+  } catch (err) {
+    t.skip(`registry unreachable (${err && err.message ? err.message : err})`);
+    return;
+  }
+  for (const rel of incident) {
+    assert.equal(published.includes(rel.version), false, `${rel.version} unexpectedly present on the registry`);
+  }
+
+  // Evaluated AS OF the incident, the detector names all eight.
+  const asOf = pw.phantoms({ announced, published, now: new Date('2026-09-13T16:00:00Z'), windowDays: 3 });
+  const named = asOf.missing.map((m) => m.version);
+  for (const rel of incident) assert.ok(named.includes(rel.version), `detector missed ${rel.version}`);
+
+  // And today it is quiet about that same closed incident.
+  const today = pw.phantoms({ announced, published, now: new Date(), windowDays: 3 });
+  for (const rel of incident) {
+    assert.equal(today.missing.some((m) => m.version === rel.version), false, `still crying wolf about ${rel.version}`);
+  }
+});
+
+test('a release announced moments ago is "settling", not a phantom', () => {
+  // npm acknowledges a publish before its aggregate listing shows it. Reporting
+  // inside that window would fire on every healthy release — which is exactly
+  // what this check did on its first live run (1.19.794, 2026-09-16).
+  const announced = pw.parseAnnounced(REL('1.19.794', '2026-09-17T00:45:23Z'));
+  const r = pw.phantoms({ announced, published: [], now: new Date('2026-09-17T00:50:00Z'), graceMinutes: 30 });
+  assert.equal(r.missing.length, 0);
+  assert.deepEqual(r.settling.map((s) => s.version), ['1.19.794']);
+  assert.match(pw.report(r), /healthy/);
+});
+
+test('past the grace period the same release IS a phantom', () => {
+  const announced = pw.parseAnnounced(REL('1.19.794', '2026-09-17T00:45:23Z'));
+  const r = pw.phantoms({ announced, published: [], now: new Date('2026-09-17T04:00:00Z'), graceMinutes: 30 });
+  assert.deepEqual(r.missing.map((m) => m.version), ['1.19.794']);
+});
+
+test('a candidate the registry confirms per-version is lagging, not missing', () => {
+  // The listing is a candidate source; the per-version read is the verdict.
+  const log = [REL('1.19.900', '2026-09-10T00:00:00Z'), REL('1.19.901', '2026-09-10T01:00:00Z')].join('\n');
+  const announced = pw.parseAnnounced(log);
+  const base = pw.phantoms({ announced, published: [], now: new Date('2026-09-10T12:00:00Z'), graceMinutes: 30 });
+  assert.equal(base.missing.length, 2, 'both look missing from the listing alone');
+
+  // Emulate check()'s confirmation pass: 900 really is there, 901 really is not.
+  const confirm = (_pkg, v) => v === '1.19.900';
+  const confirmed = [];
+  const lagging = [];
+  for (const c of base.missing) (confirm(pw.PKG, c.version) ? lagging : confirmed).push(c);
+  assert.deepEqual(lagging.map((l) => l.version), ['1.19.900']);
+  assert.deepEqual(confirmed.map((c) => c.version), ['1.19.901']);
+});
+
+test('versionIsPublished is true for a real version and false for an invented one', (t) => {
+  let live;
+  try { live = pw.versionIsPublished(pw.PKG, '1.19.715'); } catch { live = null; }
+  if (live !== true) { t.skip('registry unreachable'); return; }
+  assert.equal(pw.versionIsPublished(pw.PKG, '1.19.716'), false, '1.19.716 is the real 2026-09-13 hole');
+});