chore: sync seven upstream main commits

[DDePuy2015]

Summary\n- Integrate upstream main commits WYRE-AI#83, WYRE-AI#84, WYRE-AI#87, WYRE-AI#81, WYRE-AI#89, WYRE-AI#91, and WYRE-AI#93.\n- Preserve Summit-specific explicit reusable-workflow secret mappings and the newer checkout pin while taking upstream workflow/action pins.\n- Adopt the upstream MCPB release workflow and TypeScript-major Dependabot hold.\n\n## Validation\n- npm ci --ignore-scripts\n- typecheck, lint, 281 tests, application build, and UI build\n- production dependency audit: 0 vulnerabilities\n- full development-tree audit retains existing toolchain findings\n\nNo Azure image was built or deployed by this PR. The two open Dependabot PRs will be reevaluated after this merge.

[devin-ai-integration]

Post-merge code review (PR #24)

1. secrets: inherit on the release job — least-privilege regression (highest-value item here)

uses: wyre-technology/.github/.github/workflows/mcp-server-release.yml@8bfc9b3…
with: …
secrets: inherit          # ← added by this PR

I read the reusable workflow at the pinned SHA. Its on.workflow_call block declares no secrets: inputs at all, and the only secret referenced anywhere in its 600+ lines is secrets.GITHUB_TOKEN (10 occurrences), which is auto-provisioned to reusable workflows without inherit. So secrets: inherit grants nothing the pipeline uses, while handing every repo/org secret — including AZURE_CLIENT_ID / AZURE_TENANT_ID / AZURE_SUBSCRIPTION_ID, which the deploy job right below deliberately maps one-by-one, and CLAUDE_CODE_OAUTH_TOKEN — to an external-repo workflow whose contents can change under a future pin bump.

This also contradicts the PR description ("Preserve Summit-specific explicit reusable-workflow secret mappings"): after this change the release job is the one job in the file that does not map explicitly.

Worth noting the blast radius: release.yml also triggers on pull_request, so any collaborator branch PR produces a run with all inherited secrets in scope. (Fork PRs are safe — GitHub withholds secrets and forces a read-only token for pull_request from forks — so this is bounded by who can push branches, not by the repo being public.)

Suggested fix: delete the line. If a later pin does need something, add secrets: with just that key.

2. Dropping the local mcpb stopgap — verified safe

I checked the claim rather than taking it on faith. The upstream job at pin 8bfc9b3 reproduces every property the local stopgap had, and one it didn't:

• auto-detects support via jq -e '.scripts["pack:mcpb"]' package.json (this repo has the script, so it runs);
• gated on the release having been cut, in its own job needing only release, so a pack failure can't fail the release;
• stamps the released version — npm version "$VERSION" --no-git-tag-version --allow-same-version — which was the whole reason for the local job (v1.12.0 shipping a bundle labelled 1.5.3). Upstream adds --allow-same-version, which the local copy lacked and which would have failed the job whenever package.json already carried the released version;
• installs the CLI globally (npm install -g @anthropic-ai/mcpb), matching the local behaviour, and hard-errors if pack:mcpb produces no .mcpb at the repo root — a check the local version didn't have.

No action needed; recording the verification so the next sync doesn't have to redo it.

3. dependabot.yml — valid, but the comment now reads as attached to the wrong block

The new ignore: is correctly nested under the npm ecosystem entry (4-space indent, sibling of groups), so it applies to all npm updates, which is what's wanted. Two cosmetic notes:

• It lands directly beneath # Production MAJORS are intentionally NOT grouped → individual PRs, held for human review, so that comment now reads as if it introduces the ignore block. Moving ignore: above that trailing comment (or below the groups: map) keeps each comment adjacent to what it describes.
• typescript is a devDependency here, so the practical effect is on the dev-dependencies group (which explicitly opts into "major"), not on the production-major path the neighbouring comment discusses. A half-line — "narrows the dev-dependencies group above" — would save the next reader the round trip I just made.

4. Action pin bumps

add-to-project.yml, claude.yml, and both release.yml reusable pins are plain SHA bumps with the version comment updated. No issues.

One thing not caused by this PR but touched by it: claude.yml triggers on issues/issue_comment with contents: write, pull-requests: write, issues: write and no author_association gate, on a public repo. Any GitHub user can open an issue containing @claude and get a write-scoped run using CLAUDE_CODE_OAUTH_TOKEN. Since this repo keeps bumping that pin, consider adding to the if::

&& contains(fromJSON('["OWNER","MEMBER","COLLABORATOR"]'), github.event.comment.author_association)

(with the matching github.event.issue.author_association for the issues legs).

---

Cross-cutting, found while reviewing #16, #19, #20, #21 and #24 together

CI never runs the tests or the linter

.github/workflows/ci.yml's build job is npm ci → npm run typecheck → npm run build, and that's it. npm test and npm run lint appear in no workflow. Every one of these five PRs listed "typecheck, lint, N tests" as validation — all of it run locally by hand, none of it enforced. Concretely: #21 added assertions pinning the tool count at 46 in two places, exactly the kind of thing that drifts on the next tool addition, and nothing in CI would have failed. Adding two steps to the existing job closes it:

- run: npm run lint
- run: npm test

Three different Node majors across build, release and runtime

• ci.yml → node-version: '20'
• reusable release workflow → node-version input defaults to '22' (not overridden by release.yml)
• Dockerfile → node:26-alpine, both stages

So code is typechecked on 20, released on 22 and executed on 26. @types/node is ^26.1.2, i.e. the types match the runtime and not either CI Node. Aligning ci.yml (and passing node-version: '26' to the release workflow, which accepts it as an input) removes a class of "passes CI, fails in the container" gap — worth doing before the next runtime bump rather than after it.