feat(kilo-mcp): mark beta and add per-release changelog and bundle SBOM

[iscekic]

What

Kilo MCP (services/kilo-mcp) is now marked beta, and each production release of it gets a changelog section and an SBOM.

1. Beta label

• initialize: serverInfo.title is Kilo MCP (beta). The instructions start with a beta notice.
• The consent page ("Connect to Kilo MCP") shows a beta line.
• The kilo-mcp skill template has the beta notice. .kilo/skills/kilo-mcp/SKILL.md was regenerated.
• No public kilo.ai docs page for Kilo MCP exists, so the in-repo surfaces carry the label.

2. Changelog (services/kilo-mcp/CHANGELOG.md)

• New job kilo-mcp-release in deploy-production.yml runs after deploy-workers succeeds. It calls .github/workflows/kilo-mcp-release.yml.
• The job builds the bundle from the deployed commit (wrangler deploy --dry-run). It releases only when the bundle SHA-256 differs from the previous release.
• Each release has the tag kilo-mcp-release/<date>-<sha7>. The annotated tag records bundle-sha256.
• scripts/kilo-mcp-release-notes.mjs body lists the merged PRs that touched services/kilo-mcp/ since the previous tag. It uses the same PR-link format as the kilo-app changelog.
• land rebuilds the kilo-mcp-changelog branch as one commit on the newest main. A merged PR never loses a section, and the open PR never conflicts with main.
• One reusable bot PR, assigned to iscekic, carries the new sections to main. This works the same way as the kilo-app version-bump PR.

3. SBOM

• scripts/kilo-mcp-sbom.mjs reads the esbuild metafile of the bundle. A package is a component only if the bundle carries bytes of it.
• Each component's hash is its pnpm-lock.yaml integrity. The document records the commit, the tag, and the bundle SHA-256.
• The SBOM is attached to the GitHub Release (with --latest=false) and kept as the kilo-mcp-sbom-<sha> workflow artifact.
• docs/sbom.md describes the new family.

The script reuses the kilo-app and mobile SBOM helpers. Those helpers are now exported; their behavior did not change.

Verification

• node --test scripts/kilo-mcp-release.test.mjs: 6 pass. The tests cover land, a squash-merge followed by a branch delete, a rerun, and tree-shaken and virtual inputs.
• kilo-app-release, mobile-sbom-pnpm, mobile-sbom-cyclonedx, deployment-workflows, and kilo-mcp-catalog script tests pass.
• services/kilo-mcp vitest index and consent tests pass: 140. Typecheck, lint, and actionlint are clean.
• On this host, two dry-run builds produced the same bundle hash. The SBOM listed 6 bundled packages with lockfile hashes.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Executive Summary

Reviewed the Kilo MCP beta labeling and the new per-release changelog/SBOM tooling across 14 changed files; the changed code is internally consistent, and no correctness, security, or data-integrity issues were found on the PR's changed lines.

Files Reviewed (14 files)

• .github/workflows/deploy-production.yml
• .github/workflows/kilo-mcp-release.yml
• .kilo/skills/kilo-mcp/SKILL.md
• apps/web/src/scripts/mcp-catalog/skill-template.md
• docs/sbom.md
• package.json
• scripts/kilo-app-release-notes.mjs
• scripts/kilo-mcp-release-notes.mjs
• scripts/kilo-mcp-release.test.mjs
• scripts/kilo-mcp-sbom.mjs
• scripts/mobile-sbom-pnpm.mjs
• services/kilo-mcp/CHANGELOG.md
• services/kilo-mcp/src/index.ts
• services/kilo-mcp/src/oauth/pages.ts

Notes (no findings)

• The release gate, bundle-hash comparison, idempotent tag reuse, and retry/--force-with-lease changelog rebuild all behave consistently with the existing kilo-app release flow; the changelog section ordering and blank-line handling are correct.
• SBOM component extraction (packageRootOf, lockfile integrity hashes, tree-shaken/virtual-input exclusion) matches the bundled artifact semantics and the existing mobile SBOM helpers it now exports.
• No new unbounded resources, listeners, or caches that could leak were introduced.

---

_{Reviewed by deepseek-v4.1-flash · Input: 110.2K · Output: 41.2K · Cached: 2M}

_{Review guidance: REVIEW.md from base branch main}

[iscekic]

E2E verification (GCloud VM, deleted afterwards)

Result: done. All scenarios passed at cbb5c86.

Release job (kilo-mcp-release.yml)

The harness ran every run: step of the job against a local bare origin. gh was a stub.

Scenario	Result
A: first release	Tag kilo-mcp-release/2026-10-05-<sha7> with bundle-sha256=…, a CycloneDX 1.6 SBOM with 6 bundled packages, the release notes, the kilo-mcp-changelog branch, and a PR create with --assignee iscekic.
B: rerun of the same commit	The job reused the tag and printed changelog: … (already present). It pushed nothing and kept 1 section.
C: changelog PR squash-merged and branch deleted, then fix(kilo-mcp): … (#9999)	The notes list only #9999, not the changelog PR. The branch was rebuilt on the new main with the new section on top.
D: commit that changes only CHANGELOG.md	No kilo-mcp input changed: the job skipped every later step.
E: kilo-mcp change outside the bundle (vitest.config.ts)	The kilo-mcp bundle is unchanged … no release.

A bug was found and fixed in cbb5c86: the first section had no blank line after the header.

Beta label (wrangler dev --env dev, apps/web stubbed)

The test ran the full OAuth flow: register, authorize, status, org picker, token, and initialize.

• Consent page: <p><strong>Beta:</strong> Kilo MCP is in beta. Its tools and behavior can change.</p>
• initialize: serverInfo.title = "Kilo MCP (beta)". The instructions start with Kilo MCP is in beta: its tools and behavior can change.

A stub replaced apps/web. A real GitHub tag push, Release, and PR run only on the first production deploy after the merge.