Six @wave-av packages are published from repos other than the one they declare, and 45 of the 49 packages here have never published at all

[yakimoto]

@wave-av/adk exists as three separate source copies, all declaring "name": "@wave-av/adk", at two different versions. Only one of them is what npm actually serves.

Location	Version	Build	ERROR-CODES.md	Publishes
wave-av/sdks → sdk-typescript/packages/adk	1.0.14	6 entry points + --emitDeclarationOnly	yes	yes — publish-npm.yml
wave-av/wave-surfer-connect → packages/adk	1.0.14	6 entry points	yes	pre-carve origin
wave-av/adk (standalone repo)	1.0.2	single entry (tsup src/index.ts)	no	has a publish.yml

Evidence that sdks is the publisher

The published @wave-av/adk@1.0.14 tarball contains ERROR-CODES.md and code-split dist/chunk-*.js. The standalone adk repo has neither — it has no ERROR-CODES.md at all, and its build is tsup src/index.ts --format esm,cjs, single-entry, which cannot emit chunks. The monorepo copies build six entry points, which matches.

Why this matters

1. The standalone repo is 12 versions behind and nobody can tell. wave-av/adk presents as the home of the package — it is the URL in repository.url, it has the issue templates, the CODEOWNERS, the README. Work landed there does not reach users. I found this the hard way: I opened #59 there to fix a real shipped bug and it would have fixed nothing. The actual fix is #41.

2. Its SSOT describes a package that does not exist. wave-av/adk's .wave/repo.json declares:

subpath-exports … "the subpaths are not actually built or resolvable" — status: planned

That is true of the 1.0.2 fork and false of the shipped package, which builds and ships all six subpath entries. The Content Engine generates that repo's README from these facts, so we are publishing a documented "planned" for a feature that has been GA since 1.0.3.

3. The standalone repo has a live publish.yml running npm publish --access public. If it ever fires with a bumped version, it publishes a single-entry build with no subpath exports over a package whose consumers import @wave-av/adk/tools. That is a breaking release shipped by accident. This is the part worth acting on soonest, regardless of how the rest is resolved.

4. Two copies at 1.0.14 will drift. sdks and wave-surfer-connect are byte-identical on the file I looked at today, but nothing enforces that. The langgraph bug is present in all three.

What needs deciding

This is a "pick one" question, and it's an owner call, not something to resolve by fiat:

• Option A — sdks is the home. Archive wave-av/adk (or reduce it to a pointer README), delete its publish.yml, and move its issues/.wave/repo.json into sdks. Drop the wave-surfer-connect copy in favour of the workspace dependency.
• Option B — wave-av/adk is the home. Sync it forward from 1.0.14, move publish-npm.yml's adk job there, and make the monorepos consume the published package instead of vendoring source.

Either way, three things should happen regardless of which is chosen:

• Disable publish.yml in wave-av/adk now — it is the accident waiting to happen, and it's a one-line change.
• Add a CI check that fails if more than one workspace declares the same name in package.json. This class of problem is mechanically detectable and would have caught it years earlier.
• Correct or retire wave-av/adk's .wave/repo.json so the Content Engine stops generating a README for a package that isn't shipped. Right now the drift gate reports that repo as clean, because the facts faithfully describe the fork.

Related

• fix(adk): langgraph graph nodes look up tools by the wrong names and always fail #41 — the langgraph fix, against the copy that actually ships
• fix(langgraph): graph nodes look up tools by the wrong names and always fail adk#59 — the same fix against the fork; keep or close depending on the decision above
• feat(tools): fleet, dispatch and payment toolkits (#72) adk#58 — new fleet/dispatch/payment toolkits, built against the fork. This needs re-basing onto sdks if Option A wins, which is the immediate practical cost of leaving this unresolved.
• Test files import vitest but vitest is not installed and no test script exists — the suite has never run adk#60, CI pins go-version 1.22 — two EOL generations below the published floor #61, chore(deps): bump nanoid from 3.3.16 to 3.3.18 in /sdk-typescript #62, chore(observability): drop retired Dash0 from console source enum and AgentLogger comment #63 — all filed against the fork; each likely applies to sdks too and should be re-pointed.

Surfaced while building wave-av/wave-context#72.

[coderabbitai]

🔗 Related PRs

#5 - W-S2: carve adk/mcp-server/workflow-sdk folds + 3 missed real product modules + #59 origin fix [closed]
#9 - fix(publish): available registry names (rust→wave-sdk, pypi→wave-av-sdk) [closed]
#33 - feat(kernel): shared @wave-av/kernel client (Phase A slice 1) [merged]
#35 - feat(adk): consume shared @wave-av/kernel client (Phase A consumer 1) [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[yakimoto]

Progress: two of the three "regardless of which option wins" items are now done or filed.

• Disable publish.yml in wave-av/adk → chore(ci): stop this fork from publishing over the real @wave-av/adk adk#64. Trigger is now workflow_dispatch only, plus a guard that refuses any version not strictly ahead of the registry (verified: 1.0.2 vs 1.0.14 REFUSE, 1.0.14 REFUSE, 0.9.0 REFUSE, 1.0.15 and 1.1.0 allow). Also SHA-pinned the two actions, since mutable tags on the one workflow that mints an npm token is a poor combination.
• CI check for duplicate name across workspaces — still open.
• Correct or retire wave-av/adk's .wave/repo.json — still open, and see below.

I re-verified the fork-filed issues against this copy rather than assuming

In the original issue I wrote that the adk-filed findings "likely apply to sdks too and should be re-pointed." That was an assumption, and checking it changed the answer for half of them:

Filed against the fork	Applies to the published package?
adk#63 — three dead tool paths	yes, live in 1.0.14 → refiled as #43
adk#61 — adapters wrap only AgentToolkit	yes
adk#62 — call() ignores response.ok	no — this copy has if (!response.ok), and so does the shipped artifact
adk#60 — test suite never runs	no — vitest run works here (27 passed / 2 skipped)

Two of four were fork-only, both already fixed upstream and never backported. I've corrected the record on adk#62 rather than leave the over-broad claim standing.

That split is itself an argument for Option A: the fork isn't just behind, it's accumulating phantom bugs that read as real ones. Anyone auditing wave-av/adk in good faith will keep finding defects that don't exist in the product.

[yakimoto]

Correction — I named the wrong publisher. It is wave-surfer-connect, not this repo.

I based the original claim on circumstantial evidence (this repo has publish-npm.yml; the tarball's ERROR-CODES.md and code-split dist/ match this copy's build). That evidence was consistent with sdks but not decisive, and it was wrong.

npm records the publishing commit. Both packages carry a gitHead:

@wave-av/adk@1.0.14        gitHead e8ae9597e859ffe015590b184fedf9a0948fa5e3
@wave-av/mcp-server@0.1.8  gitHead e8ae9597e859ffe015590b184fedf9a0948fa5e3   (same commit)
published 2026-04-03 by wave-online <jake@wave.online>

Testing which repo contains it:

$ git cat-file -e e8ae9597^{commit}
wave-av/adk                : does not contain it
wave-av/sdks               : does not contain it
wave-av/wave-surfer-connect: CONTAINS it
  e8ae9597 2026-04-02 feat: commit remaining work — SSE transport, dashboard, vector helpers, lockfile

Corroborated by repository.directory, which is baked into the published package.json:

Copy	directory	files
published artifact	.	dist, README, LICENSE, CHANGELOG, ERROR-CODES
wave-surfer-connect/packages/adk	.	exact match
sdks/sdk-typescript/packages/adk	sdk-typescript/packages/adk	match
wave-av/adk	packages/adk	no CHANGELOG/ERROR-CODES

Only wave-surfer-connect matches on both fields.

The corrected picture

wave-surfer-connect is the sole publisher of both packages. wave-av/adk, wave-av/mcp-server, and wave-av/sdks have all never published them. Both were released from one monorepo-wide publish on 2026-04-03 — nearly four months ago.

And the direction differs per package, so nothing here generalises:

Package	Standalone repo	sdks copy	wave-surfer-connect	npm
@wave-av/adk	1.0.2	1.0.14	1.0.14 — publisher	1.0.14
@wave-av/mcp-server	0.2.0 (ahead)	0.1.8, src/tools empty	0.1.8 — publisher	0.1.8

mcp-server's standalone repo is ahead of npm at 0.2.0 with 18 real tool definitions, while the sdks copy is a shell with zero tool definitions in src/tools. So "the monorepo is authoritative" is false in general — it happens to be true for adk and false for mcp-server.

What this changes

• fix(adk): langgraph graph nodes look up tools by the wrong names and always fail #41 is in the wrong repo. The LangGraph fix is correct, and its regression tests are sound, but merging it into sdks would not reach npm either. Re-pointing at wave-surfer-connect/packages/adk.
• Three AgentToolkit tools call paths that cannot succeed — live in published @wave-av/adk@1.0.14 (two gateway-denied 403, one 404s at the captions spoke) #43 (three dead tool paths) still stands — those paths are in the published artifact regardless of which source copy produced it — but the fix belongs in wave-surfer-connect too.
• The real question is bigger than "which of these three is the home." It is: four repos exist for two packages, the one that actually publishes is a private application monorepo, and nothing has shipped since April. Any of the four could be tagged today by someone acting in good faith.
• wave-av/adk#64 (disabling that fork's publish trigger) is still correct and still worth merging — it just guards one of several doors.

Suggested check, revised

The duplicate-name scan I proposed only works within a workspace. It cannot see across four repos. What actually catches this:

npm view <pkg> gitHead   →   git cat-file -e <sha>^{commit} in each candidate repo

Mechanical, needs no credential, and gives a definitive answer instead of a plausible one. Worth running for every @wave-av/* package to find out how many others are in this state — I have only checked two.

Apologies for the churn; I would rather correct it loudly than leave two issues asserting the wrong repo.

[yakimoto]

Reframe: this is an unfinished split, not an accident

Jake notes wave-surfer-connect is almost completely split — the packages have been carved out into standalone repos and this monorepo is being decomposed. That changes what the four copies mean, and what the right fix is.

The carve-out moved the code. It did not move the publishing. So:

	Where the code was carved to	Where npm still publishes from
@wave-av/adk	wave-av/adk, wave-av/sdks	wave-surfer-connect
@wave-av/mcp-server	wave-av/mcp-server, wave-av/sdks	wave-surfer-connect

Both were last published 2026-04-03 from the same commit. Nothing has shipped from any carved-out repo — which is exactly what you'd expect from a split whose release step hasn't crossed over yet.

So "which repo is the home" was the wrong question. The destination repos already exist and are already the home. The real gap is that the release path is still anchored in the repo being decommissioned, and every improvement made in a carved-out repo — including everything filed here tonight — cannot reach users until that moves.

What this makes right

• Don't invest further in the wave-surfer-connect copies. Fixing bugs there is patching a repo scheduled for removal, and it doubles the maintenance surface. The exception is a live user-facing bug with no other route to npm, which is precisely the LangGraph case (fix(adk): langgraph graph nodes look up tools by the wrong names and always fail #41) — and even that is a stopgap.
• The real unblock is moving the publish step, not choosing between four repos. Whichever carved-out repo owns each package needs the npm token and a working release workflow; then wave-surfer-connect's packages/ can be deleted rather than reconciled.
• mcp-server is further along than adk. Its standalone repo is at 0.2.0 with 18 real tool definitions, ahead of the published 0.1.8, while the sdks copy is a shell with zero tools in src/tools. That repo looks ready to take over publishing. adk is the messier one: the standalone is at 1.0.2 and genuinely stale, while sdks is at 1.0.14 and current.
• chore(ci): stop this fork from publishing over the real @wave-av/adk adk#64 (disabling the stale fork's publish trigger) stays correct either way — it stops the wrong repo publishing while the right one is wired up.

Revised checklist

• Disable the stale fork's publish trigger → chore(ci): stop this fork from publishing over the real @wave-av/adk adk#64
• Decide which carved-out repo owns each package's release (sdks vs the standalone repos) and move the npm token + release workflow there
• Sync the winning adk copy forward to 1.0.14 before its first publish, or the release re-buries twelve versions
• Delete wave-surfer-connect/packages/{adk,mcp-server} once publishing has moved — do not reconcile them
• Re-point the findings filed tonight (Three AgentToolkit tools call paths that cannot succeed — live in published @wave-av/adk@1.0.14 (two gateway-denied 403, one 404s at the captions spoke) #43, Framework adapters wrap only AgentToolkit — the fleet, dispatch, and payment tools are unreachable from Mastra/LangGraph/LiveKit/Kernel adk#61) at whichever copy survives

Audit command for the rest of the surface, since I have only checked two of ~50 packages under sdk-typescript/packages/:

npm view @wave-av/<pkg> gitHead   →   git cat-file -e <sha>^{commit}  in each candidate repo

[yakimoto]

Audited all 49 packages. It is six packages, not two — and one of my earlier claims was wrong.

I said "nothing has shipped since 2026-04-03." That is false. @wave-av/dispatch published 0.7.0 on 2026-05-30, from a proper release PR, and it has 14 versions. Correcting it in the title too.

Every @wave-av package that exists on npm

All of this is readable from the public registry — curl -s https://registry.npmjs.org/@wave-av%2F<name>:

Package	npm	Versions	Declared repository	Last publish
@wave-av/adk	1.0.14	15	wave-av/adk	2026-04-03
@wave-av/sdk	2.0.14	16	wave-av/sdk	2026-04-03
@wave-av/cli	1.0.8	8	wave-av/cli	2026-04-03
@wave-av/mcp-server	0.1.8	9	wave-av/mcp-server	2026-04-03
@wave-av/workflow-sdk	1.0.6	7	wave-av/workflow-sdk	2026-04-03
@wave-av/dispatch	0.7.0	14	wave-av/dispatch-edge	2026-05-30

Six for six, the declared repository is not where the package was published from. The test is the same one that settled the adk question — npm stores the publishing commit as gitHead, so git cat-file -e <gitHead>^{commit} inside the declared repo is a yes/no answer, not an inference. Every one of the six declared repos answers no.

Five of the six were published from a single commit-range on 2026-04-02/03. @wave-av/dispatch is the exception on every axis: its own repo, its own release PR, 14 versions, and a publish two months later. It is the one package here with a working release process, and it's worth copying rather than redesigning.

The part that is specific to this repo

Of the 49 packages under sdk-typescript/packages/, 45 have never been published at all. Not stale — absent from the registry entirely:

audience, autopilot, billing, camera-control, captions, chapters, clips,
cloud-switcher, collab, connect, console, core, creator, desktop, discovery,
distribution, drm, edge, editor, fleet, ghost, kernel, marketplace, mesh,
notifications, phone, pipeline, podcast, prism, prompter, pulse, qr, replay,
scene, search, sentiment, signage, slides, studio, studio-ai, transcribe,
usb, vault, voice, zoom

The four that do exist on npm — adk, sdk, mcp-server, workflow-sdk — were all published from elsewhere. So this repo has published nothing, ever.

One of those four is a live regression risk rather than a stale copy: sdk is 3.0.0 here and 2.0.14 on npm. A major version of work sits in this repo that consumers cannot install, and a naive npm publish from here would ship a 3.0.0 that has never been released through whatever process produced 2.0.14.

What I think this changes

The original framing — "pick which of four repos owns adk" — is too small. The real question is that six packages have a declared home that has never published them, and forty-five more are source with no path to a user at all. Deciding adk's home one package at a time will take six decisions and still leave the 45.

Two things I'd suggest before any of the open PRs matter:

1. Fix the repository fields first. Six wrong pointers is the reason this was hard to see, and it's a metadata change with no release risk. Any future audit — mine or a human's — starts from a true map.
2. Copy dispatch's release setup rather than designing a new one. It demonstrably works, in this org, with these credentials.

Reproducing this

No credentials needed, and it does not depend on trusting me:

curl -s https://registry.npmjs.org/@wave-av%2F<pkg> | jq -r '.versions[."dist-tags".latest].gitHead'
git -C <candidate-repo> cat-file -e <sha>^{commit} && echo "published from here"

Note npm view does not work on a workstation whose .npmrc points at GitHub Packages — it will report the wrong registry's answer. Query registry.npmjs.org directly.

I've filed the repo-by-repo mapping (which repo actually holds each publishing commit) internally rather than here, since it's a map of private infrastructure. Everything above is registry-observable.

[yakimoto]

Refining my own number above — "45 packages with no path to a user" overstates it

I measured the source instead of assuming. The 45 are not one population:

	count	shape
Scaffolds	32	3 files, ~100–400 LOC, the same index/types/client skeleton
Real implementations	14	4+ files, 500–1300 LOC
Already published	3	adk, mcp-server, workflow-sdk

The 14 with real code and no release: captions, collab, core, editor, kernel, phone, pipeline, scene, search, sentiment, studio, studio-ai, transcribe, voice.

So the accurate statement is 14 packages of real work have never reached a user, not 45. The other 32 being unpublished is correct behaviour, not a failure — you don't ship an empty client.

And I had the sdk risk backwards

I said sdk was "3.0.0 here, 2.0.14 on npm — a major version of work consumers cannot install." Wrong direction.

sdk_typescript/packages/sdk is 2 files, 75 lines. The published @wave-av/sdk@2.0.14 has 16 versions behind it. This copy isn't ahead — it's a shell that happens to carry a higher version number.

That makes the hazard worse than I described, not better: a npm publish from this directory would ship 75 lines as 3.0.0 over a real 2.0.14, and semver would present it to every consumer as the newest release. Same failure mode wave-av/adk#64 guards against, in a second location. Whatever version guard we settle on needs to cover this directory too.

Measurement, if you want to re-run it:

for d in sdk-typescript/packages/*/; do
  printf '%-16s %s\n' "$(basename $d)" \
    "$(find $d/src -name '*.ts' -o -name '*.tsx' 2>/dev/null | xargs cat 2>/dev/null | wc -l)"
done

[yakimoto]

Correcting a claim I made earlier in this thread.

I wrote that the sdks copy of mcp-server "is a shell with zero tool definitions in src/tools," and used that to argue its standalone repo looked readier to take over publishing. That is false. Measured from the refs:

copy	version	src files	LOC	files in src/tools
sdks/sdk-typescript/packages/mcp-server	0.1.8	27	2,864	21
standalone wave-av/mcp-server	0.2.0	13	882	7

The standalone is numerically ahead and substantively one third the size — the same shape as sdk@3.0.0 being 75 lines against a published 2.0.14. I made the identical mistake twice in one audit: read a version number, inferred which copy was newer, did not look at the tree.

Two consequences worth stating plainly:

• sdks holds the fullest copy of both adk and mcp-server. Consolidating here is the simple path, not the risky one I described.
• A version number is not evidence of completeness anywhere in this scope. Both times it pointed the wrong way. The size comparison in fix(ci): validate the whole release before publishing any of it #45 exists because of exactly this.

Full per-package measurements are in the internal tracking issue.

[yakimoto]

Correction: the headline is 5 of 6, not 6 of 6

I wrote that all six published @wave-av packages "declare a repository that has never published them," and listed @wave-av/dispatch → wave-av/dispatch-edge alongside the other five as metadata rot.

That grouping is wrong. dispatch-edge is a deliberate open-core mirror, and the publish setup names it as the intended publishing target once provenance is wired up. Its sdk/js history is a series of sync: mirror open-core subset from private repo commits — it is where that package is meant to ship from, not a stale pointer someone forgot. "Fixing" that URL would have made it worse, not better.

The other five are genuine rot and the finding stands for them.

What is true for all six: zero provenance

Read straight from the public registry:

adk          1.0.14   attestations: NONE | signatures: 1
mcp-server    0.1.8   attestations: NONE | signatures: 1
sdk          2.0.14   attestations: NONE | signatures: 1
cli           1.0.8   attestations: NONE | signatures: 1
workflow-sdk  1.0.6   attestations: NONE | signatures: 1
dispatch      0.7.0   attestations: NONE | signatures: 1

Every artifact currently on npm under this scope is unattested. That is the thing worth fixing, and it is exactly what publishing from this public repo is for — npm provenance (sigstore) requires a public source repo, so it cannot be produced from a private one at all.

#45 remains the prerequisite: until it lands, the publish workflow cannot complete a run, and the naive repair would ship a 75-line sdk@3.0.0 over the real published 2.0.14.

Tracking the cross-repo consolidation internally; this issue stays scoped to what belongs in this repo.

[yakimoto]

Correction: packages/sdk is the meta-package. It was never a shell.

I've described sdk-typescript/packages/sdk repeatedly as "2 files, 75 lines, a shell, a leftover name pointing at nothing," and built an argument on top of that. It's wrong, and it's the most consequential thing I've gotten wrong in this audit.

src/index.ts re-exports all 44 product namespaces:

export * from "@wave-av/core";
export * as clips from "@wave-av/clips";
export * as voice from "@wave-av/voice";
...44 total

and package.json declares every one of them as a workspace:* dependency. That is a meta-package — the exact thing I proposed building as "option (a)" for this package's future. It already exists.

A re-export barrel is supposed to be short. I used line count as a proxy for completeness, and for a barrel that proxy is inverted: 75 lines is what correct looks like. Same mistake I made on mcp-server (read the version, not the tree), one layer up — this time I read the file size, not the file.

The 3.0.0 major is also defensible on that reading, not suspicious: 2.0.14 was one monolithic 994KB aggregate; 3.0.0 is a thin barrel over 44 separately-installable packages. That's a real breaking change, deliberately made.

The actual hazard is worse than the one I described

Every one of those 44 dependencies is checked against the public registry:

meta-package dependencies: 44
published on npm:          0
NOT published:             44

core clips voice captions chapters editor phone collab podcast studio-ai transcribe sentiment search studio fleet mesh edge scene pipeline cloud-switcher creator audience marketplace distribution connect slides desktop signage qr usb camera-control prompter replay pulse prism zoom vault drm billing notifications ghost autopilot console discovery

So publishing @wave-av/sdk@3.0.0 today doesn't ship an empty package — it ships one whose every dependency is unresolvable. npm install @wave-av/sdk would fail outright for every consumer, replacing a 2.0.14 that installs and works. A shell at least installs. This bricks the install.

What this means for #45

#45's tarball-size guard does block this release — 4,749B against a published 994,775B — but for the wrong reason, and that matters:

• It reports "package is less than half the size of the one it replaces," which mis-diagnoses a correctly-small barrel as a truncated package.
• It would keep blocking the meta-package after the 44 are published and the release becomes correct. The guard would have to be disabled at exactly the moment it's supposed to be trusted, which is how guards get routed around.

The right check for this class is dependency resolvability: refuse to publish if any dependency won't resolve on the registry at the version being published. That catches this precisely, stays silent once the 44 are shipped, and generalizes to every package in the workspace rather than special-casing one.

I'll add that to #45. The size guard still earns its place for the genuinely-truncated case, but it should not be the thing standing between us and a correct release.

The ordering constraint this exposes

The umbrella cannot publish before its contents. The 44 product packages must reach npm first, then @wave-av/sdk. That's a hard sequencing requirement for the release plan, and it wasn't in my earlier recommendation because I thought the umbrella was empty rather than waiting.

On the reliability of this audit

That's four corrections now: mcp-server's tool count, the sdk@3.0.0 risk direction, the wave-av/sdk repo's role, and this. The measured tables — file counts, LOC, gitHead containment, registry state — have held up every time. What has repeatedly failed is my characterization of what a thing is for, inferred from a cheap signal (a version number, a line count) instead of reading it. Weight the numbers here; treat any sentence of mine describing intent as provisional until you've read the file.

[yakimoto]

Correcting my own correction: I overstated the meta-package hazard

Earlier today I wrote that publishing @wave-av/sdk@3.0.0 "ships one whose every dependency is unresolvable — npm install @wave-av/sdk would fail outright for every consumer." I built that on the measurement that 0 of its 44 dependencies are on npm.

The measurement is right. The conclusion doesn't follow. This workflow publishes the whole workspace in one run, and all 44 dependencies are in that workspace. In a normal coordinated release they publish alongside the umbrella, pnpm rewrites workspace:* to the real versions, and the result installs correctly. I checked the count and never checked whether it mattered.

I found this while writing the guard the claim implied. Building it forced me to test it against the actual workspace, and it would have rejected 45 of 49 packages — because nearly all of them depend on @wave-av/core, which is equally unpublished. A guard derived from a true fact and a false inference, and the fact that it fired on almost everything is what exposed the inference.

What is actually wrong — narrower, and real

The publish loop iterates packages/*/ — alphabetical order, not dependency order — and runs under set -euo pipefail. So a failure partway through leaves everything before it already published.

sdk sorts before eleven of its own dependencies:

… scene, sdk, search, sentiment, signage, slides, studio-ai, studio,
  transcribe, usb, vault, voice, zoom

If the run dies anywhere after sdk and before zoom, @wave-av/sdk@3.0.0 is live on npm with up to eleven dependencies that were never published — and npm does not validate dependency existence at publish time, so nothing stops it. That leaves a broken package as latest, permanently, because npm versions can't be replaced.

This is not specific to sdk; it's any package that sorts before something it depends on. @wave-av/adk depends on @wave-av/kernel, and adk sorts first.

Filed separately as #46. The fix is to publish in topological order rather than alphabetical — pnpm -r already topo-sorts for build and pack, so the ordering is available; the publish loop just doesn't use it.

What shipped to #45

The dependency check, rewritten to the rule that survives testing: reject a dependency that exists neither on the registry nor in this workspace. That's a genuinely broken reference — a rename, a typo, a package deleted from under a dependent — and it can't be fixed by publishing harder. Verified both directions locally, since CI can't run:

• all 45 packages with @wave-av dependencies pass — no false positives
• a synthetic dependency on a package that exists nowhere is rejected by name, while its workspace sibling in the same manifest is not

I also corrected the false claim I'd written into the size-guard comment, and tightened registry_meta's slug validation — the case pattern only anchored the first character, so a name like a/../x would have reached the URL.

The pattern, since it keeps happening

Five corrections now. Every one has the same shape: a real measurement, then a conclusion about what it means that I didn't test. The numbers in this audit have held up under checking; my interpretations of them have a poor record. The thing that caught this one was trying to build the guard the claim implied — which is a decent general rule. If a finding is real, the check for it should be writable, and it should stay quiet on everything that isn't the finding. This one screamed at 45 of 49.