This repo can publish 0.2.0 over the real 0.1.8 with a single tag — shipping a third of the tool surface to `latest`

[yakimoto]

This repo can publish over the real @wave-av/mcp-server, and unlike the equivalent hazard in wave-av/adk (wave-av/adk#64), it needs nothing but a tag — no version bump, no edit. The result would be a package one third the size of the one it replaces, on latest.

Why it's armed right now

on:
  push:
    tags: ['v*']
...
      - run: npm publish --access public --no-provenance
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

NPM_TOKEN is set on this repo. There is no version gate, no dist-tag, and no environment.

	value
package.json here	0.2.0
npm latest	0.1.8

0.2.0 is unpublished and higher, so npm accepts it. npm publish with no --tag writes to latest regardless of semver. So one v* tag pushed here becomes the version every npm install @wave-av/mcp-server resolves to.

That is the difference from wave-av/adk#64: there, the local version (1.0.2) is behind the published one and already taken, so a tag fails on duplicate-version and the hazard only opens if someone bumps. Here the gap is already open.

What would ship

This repo does not publish @wave-av/mcp-server today. Measured from git refs, not working trees:

copy	version	src files	LOC	files in src/tools
this repo	0.2.0	13	882	7
the copy that matches what npm serves	0.1.8	27	2,864	21

So the version number is ahead while the package is roughly a third of the size, with a third of the tool definitions. Consumers importing any of the other 14 tools would break on a release that looks, from the version alone, like a routine minor bump.

I want to be explicit that I got this backwards at first: I read 0.2.0 > 0.1.8 and concluded this repo was the readier one. It isn't. A higher version number is not evidence of a fuller package, and that's precisely why a version-only guard doesn't catch this class.

Suggested fix

Same shape as wave-av/adk#64 — stop this repo from being able to publish:

• Remove the push: tags: ['v*'] trigger from .github/workflows/publish.yml, or delete the workflow.
• Revoke NPM_TOKEN on this repo. That alone disarms it immediately, needs no merge and no CI, and is trivially reversible if this repo later becomes the real publisher.

If this repo is meant to become the publisher, that's a reasonable outcome — but it should happen deliberately, after the 21-tool copy is reconciled into it, not as a side effect of a tag.

Context

Part of the publishing audit in wave-av/sdks#42. Filing rather than fixing: revoking a publish credential is outside my lane, and org Actions are billing-locked right now so nothing here can be verified in CI anyway.

[coderabbitai]

🔗 Related PRs

#37 - fix(open-core): genericize gateway repo ref in capabilities.json [closed]

---

📝 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]

Mitigated — NPM_TOKEN revoked on this repo

Authorized and done. The ungated publish path now fails closed rather than publishing.

adk          revoke -> HTTP/2.0 204 No Content
mcp-server   revoke -> HTTP/2.0 204 No Content
sdk          revoke -> HTTP/2.0 204 No Content

Verified after the fact rather than trusting the status code — GET /actions/secrets on all nine repos in the publishing scope now returns no NPM_TOKEN anywhere.

Checked before acting, so this breaks nothing:

• NPM_TOKEN was referenced in exactly one place per repo — publish.yml:27. No CI, install, or build step read it. (In wave-av/sdk the only other mentions are comments in release.yml stating it is deliberately not used.)
• The repos that legitimately publish hold no token at all and are unaffected: wave-av/sdks and the @wave-av/dispatch publisher both authenticate via OIDC trusted publishing.
• wave-av/sdk's good path — release.yml, OIDC + --provenance + version gate + dist-tag routing — keeps working, because it never used the token.
• The value is in the vault, so this is reversible if a decision later calls for it.

This is a mitigation, not the fix. The ungated workflow still exists, and re-adding a token would re-arm it. The change proposed above still stands as the actual repair — one publisher, one gate, OIDC rather than a long-lived credential.

Cross-refs: wave-av/adk#64 · #65 · wave-av/sdk#51 · audit at wave-av/sdks#42