chore(ci): stop this fork from publishing over the real @wave-av/adk

[yakimoto]

Closes the one item on wave-av/sdks#42 that needs no decision: this repo can currently publish over the real package, and shouldn't be able to.

The hazard

publish.yml triggered on push: tags: ['v*'] and ran npm publish --access public.

This repo does not publish @wave-av/adk. npm serves 1.0.14, built from wave-av/sdks → sdk-typescript/packages/adk. This repo is at 1.0.2, builds single-entry (tsup src/index.ts), and ships none of the six subpath exports (@wave-av/adk/tools, /agents, /adapters, /templates, /types) that the real package builds and that consumers import.

Publishing 1.0.2 would simply fail — npm rejects a duplicate version. The real hazard is a bump: anyone who sets version to something ahead of 1.0.14 here and tags it ships a single-entry build over a package whose consumers rely on those subpaths. A breaking release, from a repo nobody realised was live, with no review step in between.

The change

Two things, both reversible:

1. Trigger is now workflow_dispatch only — it cannot fire on its own.
2. A guard refuses any version not strictly ahead of the registry, so even a deliberate manual dispatch from this fork can't clobber the real package.

Verified against the real values:

local=1.0.2   published=1.0.14 -> REFUSE   <-- this repo, today
local=1.0.14  published=1.0.14 -> REFUSE
local=0.9.0   published=1.0.14 -> REFUSE
local=1.0.15  published=1.0.14 -> allow
local=1.1.0   published=1.0.14 -> allow

I also SHA-pinned actions/checkout and actions/setup-node to the revisions lint.yml already uses. The mutable @v4 tags tripped the supply-chain scanner, which matters more than usual on the one workflow that mints an npm token.

What this does not decide

Nothing about which repo should be the home — that's wave-av/sdks#42. If this repo wins, restore the tag trigger, but sync forward from 1.0.14 first or the first publish re-buries twelve versions of work. The comment block in the file says so, so whoever restores it reads it.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

---

Note

Low Risk
CI-only changes to publish triggers, a version guard, and action pinning; no application or package runtime code is modified.

Overview
Hardens the npm publish workflow so this stale fork cannot accidentally ship @wave-av/adk over the real package built from wave-av/sdks (npm 1.0.14 vs local 1.0.2).

The tag push trigger (v*) is removed; publish runs only via workflow_dispatch, with a long comment explaining the fork hazard and pointing to wave-av/sdks#42.

A new step Refuse to publish behind the registry compares package.json to npm view @wave-av/adk version and fails if the local version is not strictly ahead—so manual dispatch cannot clobber the registry either.

checkout and setup-node are SHA-pinned to the same revisions as lint.yml (replacing mutable @v4 tags).

^{Reviewed by Cursor Bugbot for commit 975f7ea. Configure here.}

---

Summary by cubic

Disable automated npm publish from this fork and add guardrails to prevent publishing over the real @wave-av/adk. Removes tag-based publishing, requires manual dispatch, and blocks versions that are not ahead of the registry.

• Bug Fixes

  • Switch publish trigger to workflow_dispatch only; remove tag trigger.
  • Add version guard: refuse publish if local version ≤ npm’s @wave-av/adk.

• Dependencies

  • Pin actions/checkout and actions/setup-node to SHAs to avoid mutable tags.

^{Written for commit 975f7ea. Summary will update on new commits.}

[changeset-bot]

⚠️ No Changeset found

Latest commit: 975f7ea

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_48daccd0-df72-4fc8-a5fb-0a3fddf53e62)

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 38 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 852c45f1-9c35-40ad-8a02-c13da8e58028

📥 Commits

Reviewing files that changed from the base of the PR and between eb79119 and 975f7ea.

📒 Files selected for processing (1)

• .github/workflows/publish.yml

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch chore/disable-fork-publish

✨ Simplify code

• Create PR with simplified code
• Commit simplified code in branch chore/disable-fork-publish

---

_{Comment @coderabbitai help to get the list of available commands.}

[yakimoto]

Correction to this PR's body, which I wrote: it says npm serves 1.0.14 "built from wave-av/sdks → sdk-typescript/packages/adk."

That attribution is wrong. The definitive test is the gitHead npm records for the published version, checked for containment in each candidate repo:

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

That commit resolves to the private monorepo, not to wave-av/sdks. sdks holds the fullest copy of the source (24 src files / 2,391 LOC, matching what ships) and is the intended future publisher — but it has never actually published this package. I conflated "has the code and a publish workflow" with "is the publisher," which is the same circumstantial reasoning this PR exists to guard against.

Nothing about the change here is affected. The hazard is that this repo can publish over a package it doesn't own, and that remains true regardless of which repo does own it. The fix is still correct as written.

One addition worth making while this is open: revoking NPM_TOKEN on this repo would disarm the path immediately, without needing this PR to merge or CI to be green — both of which are currently blocked. Same recommendation now filed for the sibling repos at wave-av/mcp-server#65 and wave-av/sdk#51, where the equivalent workflow is armed in the same way.

Full audit context: wave-av/sdks#42.

[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: #64 · wave-av/mcp-server#65 · wave-av/sdk#51 · audit at wave-av/sdks#42