@cyanheads/cyanheads-mcp-server 0.4.1 → 0.4.3

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (33) hide show
  1. package/AGENTS.md +56 -26
  2. package/CLAUDE.md +56 -26
  3. package/Dockerfile +38 -29
  4. package/README.md +59 -48
  5. package/changelog/0.4.x/0.4.2.md +32 -0
  6. package/changelog/0.4.x/0.4.3.md +34 -0
  7. package/changelog/template.md +9 -26
  8. package/dist/index.js +22 -1
  9. package/dist/index.js.map +1 -1
  10. package/dist/mcp-server/tools/definitions/describe-entry.tool.d.ts +24 -0
  11. package/dist/mcp-server/tools/definitions/describe-entry.tool.d.ts.map +1 -1
  12. package/dist/mcp-server/tools/definitions/describe-entry.tool.js +120 -95
  13. package/dist/mcp-server/tools/definitions/describe-entry.tool.js.map +1 -1
  14. package/dist/mcp-server/tools/definitions/search-catalog.tool.d.ts +12 -0
  15. package/dist/mcp-server/tools/definitions/search-catalog.tool.d.ts.map +1 -1
  16. package/dist/mcp-server/tools/definitions/search-catalog.tool.js +86 -20
  17. package/dist/mcp-server/tools/definitions/search-catalog.tool.js.map +1 -1
  18. package/dist/services/catalog/catalog-service.d.ts +2 -2
  19. package/dist/services/catalog/catalog-service.d.ts.map +1 -1
  20. package/dist/services/catalog/catalog-service.js +36 -11
  21. package/dist/services/catalog/catalog-service.js.map +1 -1
  22. package/dist/services/catalog/remote-catalog-provider.d.ts +2 -2
  23. package/dist/services/catalog/remote-catalog-provider.d.ts.map +1 -1
  24. package/dist/services/catalog/remote-catalog-provider.js +34 -5
  25. package/dist/services/catalog/remote-catalog-provider.js.map +1 -1
  26. package/dist/services/catalog/self-record.js +3 -3
  27. package/dist/services/catalog/service-instance.js +1 -1
  28. package/dist/services/catalog/service-instance.js.map +1 -1
  29. package/dist/services/catalog/types.d.ts +2 -2
  30. package/dist/services/catalog/types.d.ts.map +1 -1
  31. package/manifest.json +2 -2
  32. package/package.json +26 -14
  33. package/server.json +3 -3
package/AGENTS.md CHANGED
@@ -1,11 +1,11 @@
1
1
  # Developer Protocol
2
2
 
3
3
  **Server:** cyanheads-mcp-server
4
- **Version:** 0.4.1
5
- **Framework:** [@cyanheads/mcp-ts-core](https://www.npmjs.com/package/@cyanheads/mcp-ts-core) `^0.12.3`
6
- **Engines:** Bun ≥1.3.0, Node ≥24.0.0
7
- **MCP SDK:** `@modelcontextprotocol/server` 2.0.0
8
- **Zod:** ^4.4.3
4
+ **Version:** 0.4.3
5
+ **Framework:** [@cyanheads/mcp-ts-core](https://www.npmjs.com/package/@cyanheads/mcp-ts-core) `^0.13.10`
6
+ **Engines:** Bun ≥1.4.0, Node ≥24.0.0
7
+ **MCP SDK:** `@modelcontextprotocol/server` 2.1.0
8
+ **Zod:** ^4.6.5
9
9
 
10
10
  > **Read the framework docs first:** `node_modules/@cyanheads/mcp-ts-core/CLAUDE.md` contains the full API reference — builders, Context, error codes, exports, patterns. This file covers server-specific conventions only.
11
11
 
@@ -20,7 +20,7 @@ A fleet discovery surface for the cyanheads MCP ecosystem. Two tools:
20
20
 
21
21
  The catalog (`fleet.json`) is produced by `caseyjhand-portfolio/scripts/build-fleet-json.ts` at portfolio deploy time. Document vectors are baked into the JSON. The server only embeds the user's query at runtime via `@huggingface/transformers`. See `docs/design.md` for the full architecture.
22
22
 
23
- The generated catalog does not include this server, so `src/services/catalog/self-record.ts` supplies a static `CatalogRecord` for `cyanheads-mcp-server` that `CatalogService.getServer()` / `getTool()` consult **only after** the remote index misses. A remote entry always wins, so the fallback self-heals to dead code if the generator ever starts emitting one. The record is never part of the vector index, so semantic search does not surface it — only exact-name resolution does.
23
+ The generated catalog does not include this server, so `src/services/catalog/self-record.ts` supplies a static `CatalogRecord` for `cyanheads-mcp-server` that `CatalogService.getServer()` / `getTool()` consult **only after** the remote namespace has no candidate. Exact remote names win, then unique case-insensitive remote names; ambiguous folds never fall through to self. Output names are canonical. The self record is never part of the vector index, so semantic search does not surface it — only name resolution does.
24
24
 
25
25
  ---
26
26
 
@@ -50,6 +50,7 @@ Tailor suggestions to what's actually missing or stale — don't recite the full
50
50
  - **Use `ctx.state`** for tenant-scoped storage. Never access persistence directly.
51
51
  - **Need input the caller didn't supply?** `return ctx.requestInput(...)` and read `ctx.inputs` when the handler is re-entered. Never `await` for user input mid-handler.
52
52
  - **Secrets in env vars only** — never hardcoded.
53
+ - **Cut noise.** Add only what earns its place: no speculative generality, no guards for states the framework already prevents (Zod-validated params, classified errors), no abstraction until a third caller proves it, no option nothing sets.
53
54
  - **Close the loop on issues.** When implementing work tracked by a GitHub issue, comment on the issue with what landed and close it. Do both — a comment without a close leaves stale issues open; a close without a comment leaves no record of what shipped. The comment is for future readers — state the concrete changes, not the conversation that produced them.
54
55
 
55
56
  ---
@@ -66,7 +67,7 @@ export const searchItems = tool('search_items', {
66
67
  annotations: { readOnlyHint: true },
67
68
  input: z.object({
68
69
  query: z.string().describe('Search terms'),
69
- limit: z.number().default(10).describe('Max results'),
70
+ limit: z.number().int().min(1).max(100).default(10).describe('Max results (1–100)'),
70
71
  }),
71
72
  output: z.object({
72
73
  items: z.array(z.object({
@@ -160,6 +161,24 @@ For env booleans use `z.stringbool()`, never `z.coerce.boolean()` — `Boolean("
160
161
 
161
162
  The canonical `createApp()` identity in this project is `name` + `title` only, both exactly `cyanheads-mcp-server`. The description derives from `package.json`, and the website derives from package metadata, so neither is duplicated in the identity block. `instructions` carries the fleet-discovery workflow as session-level context.
162
163
 
164
+ ### Session posture and shutdown
165
+
166
+ Two more `createApp()` options shape how the server runs rather than how it presents itself:
167
+
168
+ ```ts
169
+ await createApp({
170
+ sessionMode: 'stateless', // or { default: 'stateful', require: 'stateful' }
171
+ setup(core) { startMyWatcher(core.config); },
172
+ async teardown() { await stopMyWatcher(); },
173
+ });
174
+ ```
175
+
176
+ `sessionMode` declares the HTTP session posture in `src/` instead of leaving it to a deployment's `MCP_SESSION_MODE`, which still wins whenever it carries a meaningful value (an empty string and an unsubstituted `${…}` placeholder read as unset and fall through to the option). Add `require: 'stateful'` when a tool asks the caller for input mid-handler via `ctx.requestInput`: startup then fails with a `ConfigurationError` rather than serving a mode in which a 2025-era client can never answer the prompt. Stdio is never refused.
177
+
178
+ `teardown(core)` is the `setup()` counterpart — release a watcher, socket, or non-`unref()`'d timer there. It runs after the transport stops and before the logger closes, on every shutdown path, and a signal-triggered shutdown then exits the process explicitly (0, or 1 if a step never settles within the framework's 10 s ceiling).
179
+
180
+ This server declares `sessionMode: 'stateless'` — it holds no per-session state, so the session store and the per-session `McpServer` allocation are pure overhead and the process scales horizontally without them. `teardown` stops the catalog service's background refresh timer.
181
+
163
182
  ---
164
183
 
165
184
  ## Context
@@ -169,13 +188,14 @@ Handlers receive a unified `ctx` object. Key properties:
169
188
  | Property | Description |
170
189
  |:---------|:------------|
171
190
  | `ctx.log` | Request-scoped logger — `.debug()`, `.info()`, `.notice()`, `.warning()`, `.error()`. Auto-correlates requestId, traceId, tenantId. Dual-sink: Pino **and** `notifications/message` to the client, so treat it as client-visible. |
172
- | `ctx.state` | Tenant-scoped KV — `.get(key)`, `.set(key, value, { ttl? })`, `.delete(key)`, `.getMany(keys)`, `.list(prefix, { cursor, limit })`. Accepts any serializable value. |
191
+ | `ctx.state` | Tenant-scoped KV — `.get(key)`, `.set(key, value, { ttl? })`, `.delete(key)`, `.getMany(keys)`, `.list(prefix, { cursor, limit })`. Accepts any JSON-serializable value; reads return its JSON form (a `Date` comes back as an ISO string). |
173
192
  | `ctx.requestInput` | Suspend and ask the caller for more input — `return ctx.requestInput({ inputRequests: { key: inputRequired.elicit({ message, requestedSchema }) } })`. Never returns; the handler is re-entered with the answers. Always present. |
174
- | `ctx.inputs` | Reader over a retried request's responses — `.accepted(key, schema)`, `.view(key)`, `.state()`, `.dropped`. Empty on the first round. |
193
+ | `ctx.inputs` | The request's responses — `.accepted(key, schema)`, `.view(key)`, `.state()`, `.dropped` — limited to what the client declared (`elicitation` and its form/url modes, `sampling`, `roots`). Client-supplied: a consent gate trusts only a `ctx.state` record it stored when it asked, bound to the operation, caller, and target (see the `api-context` skill). |
194
+ | `ctx.clientCapabilities` | What the client declared for this request, `undefined` when no view exists. Decides whether to ask for optional context (e.g. roots); never a reason to skip a consent prompt. |
175
195
  | `ctx.enrich` | Success-path agent context (empty-result notices, query echo, pagination totals) — `ctx.enrich(...)` or `.notice()` / `.total()` / `.echo()` / `.truncated()`. Reaches `structuredContent` and `content[]`; lands only when the definition declares an `enrichment` block (no-op otherwise). |
176
196
  | `ctx.content` | Non-text content blocks — `.image(data, mimeType)`, `.audio(data, mimeType)`, or `ctx.content(block)` for a raw block. Prepended to `content[]` after `format()`; never enters `structuredContent`. |
177
197
  | `ctx.signal` | `AbortSignal` for cancellation. |
178
- | `ctx.requestId` | Unique request ID. |
198
+ | `ctx.requestId` | Request ID — the one every log record of the call carries and its error envelope returns as `data.requestId`. |
179
199
  | `ctx.tenantId` | Tenant ID from JWT; `'default'` for stdio or HTTP with auth off. |
180
200
 
181
201
  ---
@@ -184,7 +204,7 @@ Handlers receive a unified `ctx` object. Key properties:
184
204
 
185
205
  Handlers throw — the framework catches, classifies, and formats.
186
206
 
187
- **Recommended: typed error contract.** Declare `errors: [{ reason, code, when, recovery, retryable? }]` on `tool()` / `resource()` to receive `ctx.fail(reason, …)` typed against the reason union. TypeScript catches typos at compile time, `data.reason` is auto-populated for observability, and the linter enforces conformance against the handler body. `recovery` is required (≥ 5 words, lint-validated) — the single source of truth for the agent's next move. Pass `ctx.recoveryFor('reason')` as the throw's data to put it on the wire (`data.recovery.hint`, mirrored into `content[]` text); override with an explicit `{ recovery: { hint: '...' } }` when dynamic runtime context matters. Baseline codes (`InternalError`, `ServiceUnavailable`, `Timeout`, `ValidationError`, `SerializationError`) bubble freely and don't need declaring.
207
+ **Recommended: typed error contract.** Declare `errors: [{ reason, code, when, recovery, retryable?, severity?, thrownBy? }]` on `tool()` / `resource()` to receive `ctx.fail(reason, …)` typed against the reason union. TypeScript catches typos at compile time, `data.reason` is auto-populated for observability, linter enforces conformance against the handler body. `recovery` is required (≥ 5 words, lint-validated) — the single source of truth for the agent's next move. The framework puts it on the wire whenever a failure carrying that `reason` arrives without a hint — a bare `ctx.fail('reason')` or a service throw with `data: { reason }` — as `data.recovery.hint`, mirrored into `content[]` text unless the message already contains it verbatim; override with an explicit `{ recovery: { hint: '...' } }` when dynamic runtime context matters. Every error envelope also carries `data.requestId`, the id the server's log records for that call carry, and `content[]` closes with `(reason … · request <id>)`. Mark an entry the service layer throws with `thrownBy: 'service'` so `error-contract-unthrown` skips it — lint-only metadata, nothing at runtime reads it. Baseline codes (`InternalError`, `ServiceUnavailable`, `Timeout`, `ValidationError`, `SerializationError`, `RequestCancelled`) bubble freely and don't need declaring.
188
208
 
189
209
  ```ts
190
210
  import { JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';
@@ -196,7 +216,7 @@ errors: [
196
216
  ],
197
217
  async handler(input, ctx) {
198
218
  const item = await db.find(input.id);
199
- if (!item) throw ctx.fail('no_match', `No item ${input.id}`, ctx.recoveryFor('no_match'));
219
+ if (!item) throw ctx.fail('no_match', `No item ${input.id}`);
200
220
  return item;
201
221
  }
202
222
  ```
@@ -217,7 +237,7 @@ throw new Error('Invalid query format'); // → ValidationError
217
237
 
218
238
  // McpError — when no factory exists for the code
219
239
  import { McpError, JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';
220
- throw new McpError(JsonRpcErrorCode.DatabaseError, 'Connection failed', { pool: 'primary' });
240
+ throw new McpError(JsonRpcErrorCode.InitializationFailed, 'Connection failed', { pool: 'primary' });
221
241
  ```
222
242
 
223
243
  See framework CLAUDE.md and the `api-errors` skill for the full auto-classification table, all available factories, and the contract reference.
@@ -259,9 +279,9 @@ src/
259
279
 
260
280
  ## Skills
261
281
 
262
- Skills are modular instructions in `skills/` at the project root. Read them directly when a task matches — e.g., `skills/add-tool/SKILL.md` when adding a tool. `bun run list-skills` prints the full registry.
282
+ Skills are modular instructions in `framework-skills/` at the project root. Read them directly when a task matches — e.g., `framework-skills/add-tool/SKILL.md` when adding a tool. `bun run list-skills` prints the full registry. The directory is deliberately not `skills/`: Claude Code and Codex auto-load a plugin's root `skills/`, so a server that ships `.claude-plugin/` or `.codex-plugin/` would hand these development skills to every agent that installs it. Keep `skills/` free for skills meant for those agents.
263
283
 
264
- **Agent skill directory:** Copy skills into the directory your agent discovers (Claude Code: `.claude/skills/`, others: equivalent). Skills then load as context without referencing `skills/` paths. After framework updates, run the `maintenance` skill — Phase B re-syncs the agent directory.
284
+ **Agent skill directory:** Copy skills into the directory your agent discovers (Claude Code: `.claude/skills/`, others: equivalent). Skills then load as context without referencing `framework-skills/` paths. After framework updates, run the `maintenance` skill — Phase B re-syncs the agent directory.
265
285
 
266
286
  Available skills:
267
287
 
@@ -280,8 +300,9 @@ Available skills:
280
300
  | `security-pass` | Audit server for MCP-flavored security gaps: output injection, scope blast radius, input sinks, tenant isolation |
281
301
  | `code-simplifier` | Post-session cleanup against `git diff` — modernize syntax, consolidate duplication, align with the codebase |
282
302
  | `polish-docs-meta` | Finalize docs, README, metadata, and agent protocol for shipping |
283
- | `git-wrapup` | Land working-tree changes as a versioned commit + annotated tag — version bump, changelog, verify, tag. Local only. |
284
- | `release-and-publish` | Push + npm + MCP Registry + GH Release + Docker. Picks up from `git-wrapup` |
303
+ | `git-wrapup` | Land working-tree changes as a commit stack — version bump, changelog, verify, commit by concern, release commit on top. No tag, no push to main; opens the release PR when the project declares release PR mode |
304
+ | `release-pr-review` | Review pass on an open release PR — simplifier + correctness review, fixes as ordinary commits on top of the stack, PR body kept in sync. Release PR mode only |
305
+ | `release-and-publish` | Fast-forward merge (release PR mode) + tag + push + npm + MCP Registry + GH Release + Docker. Picks up from `git-wrapup` |
285
306
  | `maintenance` | Investigate changelogs, adopt upstream changes, sync skills to agent dirs |
286
307
  | `orchestrations` | Chain task skills into a gated multi-phase pipeline — build-out, QA-fix, update-ship — when you can spawn sub-agents |
287
308
  | `report-issue-framework` | File a bug or feature request against `@cyanheads/mcp-ts-core` via `gh` CLI |
@@ -300,7 +321,7 @@ Available skills:
300
321
  | `api-telemetry` | OTel catalog: spans, metrics, completion logs, env config, cardinality rules |
301
322
  | `api-workers` | Cloudflare Workers runtime |
302
323
 
303
- **Chaining skills into pipelines.** When the user wants a multi-phase effort — build this server out, QA-and-fix the surface, update-and-ship — *and you can spawn sub-agents*, `skills/orchestrations/SKILL.md` sequences the task skills above into a gated pipeline with verification at each step. Read it to drive the run. Optional: skip it if you can't orchestrate sub-agents, and ignore it entirely if you were *spawned* as one — you've already been scoped to a single phase.
324
+ **Chaining skills into pipelines.** When the user wants a multi-phase effort — build this server out, QA-and-fix the surface, update-and-ship — *and you can spawn sub-agents*, `framework-skills/orchestrations/SKILL.md` sequences the task skills above into a gated pipeline with verification at each step. Read it to drive the run. Optional: skip it if you can't orchestrate sub-agents, and ignore it entirely if you were *spawned* as one — you've already been scoped to a single phase.
304
325
 
305
326
  When you complete a skill's checklist, check the boxes and add a completion timestamp at the end (e.g., `Completed: 2026-03-11`).
306
327
 
@@ -316,7 +337,8 @@ When you complete a skill's checklist, check the boxes and add a completion time
316
337
  | `bun run rebuild` | Clean + build |
317
338
  | `bun run clean` | Remove build artifacts |
318
339
  | `bun run devcheck` | Lint + format + typecheck + security + changelog sync |
319
- | `bun run audit:refresh` | Delete `bun.lock`, reinstall, and re-run `bun audit`. Use when `devcheck` flags a transitive advisory — Bun's `update` is sticky on transitive resolutions, so the advisory may be a stale-lockfile false positive. If it survives the refresh, it's real. |
340
+ | `bun run audit:fix` | `bun audit fix` — upgrade vulnerable packages to the lowest safe version within existing ranges (`--dry-run` previews, `--latest` rewrites ranges). First response when `devcheck` flags a transitive advisory; then `bun update <name>`, then `bun dedupe` |
341
+ | `bun run audit:refresh` | Delete `bun.lock` and reinstall. Last resort after `audit:fix`, `bun update <name>`, and `bun dedupe` — re-resolves every ranged dep (the framework pin included) and rewrites the lockfile as `lockfileVersion: 2` |
320
342
  | `bun run lint:mcp` | Run the MCP definition linter standalone (rule catalog: `api-linter` skill) |
321
343
  | `bun run lint:packaging` | Packaging surface checks — `server.json`/`manifest.json` env-var parity (run by devcheck) |
322
344
  | `bun run list-skills` | Print the skill registry |
@@ -331,15 +353,17 @@ When you complete a skill's checklist, check the boxes and add a completion time
331
353
  | `bun run release:github` | Create GitHub Release from annotated tag (title format: `v<VERSION>: <subject>`) |
332
354
  | `bun run bundle` | Build, pack, and clean a `.mcpb` for one-click Claude Desktop install |
333
355
 
356
+ **CI is one file.** `.github/workflows/codeql.yml` (scaffolded) is the only GitHub Actions workflow: CodeQL is GitHub-owned end to end, and the file runs only while the repo's CodeQL *default setup* is turned off. Verification — `devcheck`, tests, the release gates — runs locally; don't add a workflow that re-runs it.
357
+
334
358
  ---
335
359
 
336
360
  ## Bundling
337
361
 
338
- `npm run bundle` produces a `.mcpb` extension bundle for one-click install in Claude Desktop. The pack step is followed by `scripts/clean-mcpb.ts`, which prunes dev dependencies (`mcpb clean`) and strips two classes of `node_modules/**` content that root-anchored `.mcpbignore` patterns cannot reach: dependency-shipped agent docs (`skills/`, `.claude/`, `.agents/`, `SKILL.md`) and platform-specific native bindings, which would otherwise lock the bundle to the platform it was packed on. A server using DataCanvas therefore ships a portable bundle without the DuckDB native — `@duckdb/node-api` is an optional peer loaded lazily, so canvas tools report an actionable install hint and every other tool works normally. MCPB is stdio-only — HTTP and Cloudflare Workers deployments are unaffected. Consumers who don't need it can delete `manifest.json` and `.mcpbignore`; `lint:packaging` skips cleanly.
362
+ `npm run bundle` produces a `.mcpb` extension bundle for one-click install in Claude Desktop. The pack step is followed by `scripts/clean-mcpb.ts`, which prunes dev dependencies (`mcpb clean`) and strips two classes of `node_modules/**` content that root-anchored `.mcpbignore` patterns cannot reach: dependency-shipped agent docs (`framework-skills/`, `skills/`, `.claude/`, `.agents/`, `SKILL.md`) and platform-specific native bindings, which would otherwise lock the bundle to the platform it was packed on. A server using DataCanvas therefore ships a portable bundle without the DuckDB native — `@duckdb/node-api` is an optional peer loaded lazily, so canvas tools report an actionable install hint and every other tool works normally. MCPB is stdio-only — HTTP and Cloudflare Workers deployments are unaffected. Consumers who don't need it can delete `manifest.json` and `.mcpbignore`; `lint:packaging` skips cleanly.
339
363
 
340
- **Adding an env var requires both files:** `server.json` (registry discovery, `environmentVariables[]`) and `manifest.json` (bundle install UX, `mcp_config.env` + `user_config`). `lint:packaging` (run by `devcheck`) verifies the env var names match.
364
+ **Adding an env var requires both files:** `server.json` (registry discovery, `environmentVariables[]`) and `manifest.json` (bundle install UX, `mcp_config.env` + `user_config`). `lint:packaging` (run by `devcheck`) verifies the env var names match, that every `user_config` option is wired into `mcp_config.env` as `"X": "${user_config.X}"` (the host substitutes nothing else — `"${X}"` reaches the server as that literal string), and that an optional string option carries `"default": ""`.
341
365
 
342
- **README install badges** (Claude Desktop `.mcpb`, Cursor, VS Code) and the `base64` / `encodeURIComponent` config-generation commands are ship-time concerns — run the `polish-docs-meta` skill, which carries the badge format, layout, and generation snippets in `skills/polish-docs-meta/references/readme.md`.
366
+ **README install badges** (Claude Desktop `.mcpb`, Cursor, VS Code) and the `base64` / `encodeURIComponent` config-generation commands are ship-time concerns — run the `polish-docs-meta` skill, which carries the badge format, layout, and generation snippets in `framework-skills/polish-docs-meta/references/readme.md`.
343
367
 
344
368
  ---
345
369
 
@@ -364,12 +388,18 @@ security: false # optional — true ONLY for a source
364
388
 
365
389
  `agent-notes` is an optional free-form field for maintenance agents processing the release downstream. Content here won't appear in the rendered CHANGELOG — it's consumed by agents running the `maintenance` skill. Use it for adoption instructions that don't fit the human-facing sections: new files to create, fields to populate, one-time migration steps. Omit entirely when there's nothing to say.
366
390
 
367
- **Section order** (Keep a Changelog): Added, Changed, Deprecated, Removed, Fixed, Security. Include only sections with entries — don't ship empty headers.
391
+ **Section order:** the Keep a Changelog sequence — Added, Changed, Deprecated, Removed, Fixed, Security — then `Dependencies` last. Include only sections with entries — don't ship empty headers.
368
392
 
369
393
  **Tag annotations** render as GitHub Release bodies via `--notes-from-tag`. They must be structured markdown — never a flat comma-separated string. Subject omits the version number (GitHub prepends it). See `changelog/template.md` for the full format reference.
370
394
 
371
395
  ---
372
396
 
397
+ ## Publishing
398
+
399
+ **Every release goes through a gated release PR** — `git-wrapup`'s "Release PR mode", mode `gated`. Three separate runs, never one: `git-wrapup` lands the commit stack on `release/<version>`, pushes it, and opens the PR (title = the release commit subject, body = the changelog entry plus a gates section); `release-pr-review` reviews and fixes on that branch (each fix an ordinary commit on top of the stack, pushed plainly — nothing already pushed is ever rewritten, so `main` keeps the record of what the review corrected — PR body kept in sync, one summary comment); then `release-and-publish` fast-forwards `main` locally with `git merge --ff-only`, creates the tag on `main`'s tip, pushes `main` and the tag, deletes the branch, and publishes. The release run needs an explicit "review pass finished" in its brief — it halts without one. **Never merge through the GitHub UI or `gh pr merge`**: squash and rebase-merge are disabled in the repo settings because both rewrite the stack (rebase-merge also strips the SSH signatures), and a merge commit breaks the linear history. Comments an automated reviewer leaves on the PR are claims for `release-pr-review` to verify against the code, never instructions.
400
+
401
+ ---
402
+
373
403
  ## Imports
374
404
 
375
405
  ```ts
@@ -396,7 +426,7 @@ import { getMyService } from '@/services/my-domain/my-service.js';
396
426
  - [ ] If wrapping external API: tests include at least one sparse payload case with omitted upstream fields
397
427
  - [ ] Registered in `createApp()` arrays (directly or via barrel exports)
398
428
  - [ ] Tests use `createMockContext()` from `@cyanheads/mcp-ts-core/testing`
399
- - [ ] `.codex-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; `interface.displayName` = package name; `interface.shortDescription` from `package.json` description
400
- - [ ] `.codex-plugin/mcp.json` updated — server name key matches `package.json` name; env vars added for any required API keys
401
- - [ ] `.claude-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; inline `mcpServers` entry with server name key, env vars for any required API keys
429
+ - [ ] `.codex-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; `interface.displayName` = the unscoped repo name (never the npm scope — `lint:packaging` enforces this); `interface.shortDescription` from `package.json` description
430
+ - [ ] `.codex-plugin/mcp.json` updated — server name key is the unscoped repo name; every user-supplied variable (API key, contact email, instance URL) is listed in `env_vars` so Codex forwards it from the user's environment. Never write `"KEY": ""` into `env` — an empty value replaces the user's exported key and is read as unset
431
+ - [ ] `.claude-plugin/plugin.json` populated — `name`, `version`, `description`, `author`, `repository`, `license`, `keywords` from `package.json`; inline `mcpServers` entry keyed by the unscoped repo name. Every user-supplied variable is declared under `userConfig` (`type`, `title`, `description`; `sensitive: true` for keys and tokens; `required: true` or `default: ""`) and referenced from `env` as `"KEY": "${user_config.<option>}"` — mirror the `user_config` block in `manifest.json`. Never write `"KEY": ""` into `env`
402
432
  - [ ] `npm run devcheck` passes
package/CLAUDE.md CHANGED
@@ -1,11 +1,11 @@
1
1
  # Developer Protocol
2
2
 
3
3
  **Server:** cyanheads-mcp-server
4
- **Version:** 0.4.1
5
- **Framework:** [@cyanheads/mcp-ts-core](https://www.npmjs.com/package/@cyanheads/mcp-ts-core) `^0.12.3`
6
- **Engines:** Bun ≥1.3.0, Node ≥24.0.0
7
- **MCP SDK:** `@modelcontextprotocol/server` 2.0.0
8
- **Zod:** ^4.4.3
4
+ **Version:** 0.4.3
5
+ **Framework:** [@cyanheads/mcp-ts-core](https://www.npmjs.com/package/@cyanheads/mcp-ts-core) `^0.13.10`
6
+ **Engines:** Bun ≥1.4.0, Node ≥24.0.0
7
+ **MCP SDK:** `@modelcontextprotocol/server` 2.1.0
8
+ **Zod:** ^4.6.5
9
9
 
10
10
  > **Read the framework docs first:** `node_modules/@cyanheads/mcp-ts-core/CLAUDE.md` contains the full API reference — builders, Context, error codes, exports, patterns. This file covers server-specific conventions only.
11
11
 
@@ -20,7 +20,7 @@ A fleet discovery surface for the cyanheads MCP ecosystem. Two tools:
20
20
 
21
21
  The catalog (`fleet.json`) is produced by `caseyjhand-portfolio/scripts/build-fleet-json.ts` at portfolio deploy time. Document vectors are baked into the JSON. The server only embeds the user's query at runtime via `@huggingface/transformers`. See `docs/design.md` for the full architecture.
22
22
 
23
- The generated catalog does not include this server, so `src/services/catalog/self-record.ts` supplies a static `CatalogRecord` for `cyanheads-mcp-server` that `CatalogService.getServer()` / `getTool()` consult **only after** the remote index misses. A remote entry always wins, so the fallback self-heals to dead code if the generator ever starts emitting one. The record is never part of the vector index, so semantic search does not surface it — only exact-name resolution does.
23
+ The generated catalog does not include this server, so `src/services/catalog/self-record.ts` supplies a static `CatalogRecord` for `cyanheads-mcp-server` that `CatalogService.getServer()` / `getTool()` consult **only after** the remote namespace has no candidate. Exact remote names win, then unique case-insensitive remote names; ambiguous folds never fall through to self. Output names are canonical. The self record is never part of the vector index, so semantic search does not surface it — only name resolution does.
24
24
 
25
25
  ---
26
26
 
@@ -50,6 +50,7 @@ Tailor suggestions to what's actually missing or stale — don't recite the full
50
50
  - **Use `ctx.state`** for tenant-scoped storage. Never access persistence directly.
51
51
  - **Need input the caller didn't supply?** `return ctx.requestInput(...)` and read `ctx.inputs` when the handler is re-entered. Never `await` for user input mid-handler.
52
52
  - **Secrets in env vars only** — never hardcoded.
53
+ - **Cut noise.** Add only what earns its place: no speculative generality, no guards for states the framework already prevents (Zod-validated params, classified errors), no abstraction until a third caller proves it, no option nothing sets.
53
54
  - **Close the loop on issues.** When implementing work tracked by a GitHub issue, comment on the issue with what landed and close it. Do both — a comment without a close leaves stale issues open; a close without a comment leaves no record of what shipped. The comment is for future readers — state the concrete changes, not the conversation that produced them.
54
55
 
55
56
  ---
@@ -66,7 +67,7 @@ export const searchItems = tool('search_items', {
66
67
  annotations: { readOnlyHint: true },
67
68
  input: z.object({
68
69
  query: z.string().describe('Search terms'),
69
- limit: z.number().default(10).describe('Max results'),
70
+ limit: z.number().int().min(1).max(100).default(10).describe('Max results (1–100)'),
70
71
  }),
71
72
  output: z.object({
72
73
  items: z.array(z.object({
@@ -160,6 +161,24 @@ For env booleans use `z.stringbool()`, never `z.coerce.boolean()` — `Boolean("
160
161
 
161
162
  The canonical `createApp()` identity in this project is `name` + `title` only, both exactly `cyanheads-mcp-server`. The description derives from `package.json`, and the website derives from package metadata, so neither is duplicated in the identity block. `instructions` carries the fleet-discovery workflow as session-level context.
162
163
 
164
+ ### Session posture and shutdown
165
+
166
+ Two more `createApp()` options shape how the server runs rather than how it presents itself:
167
+
168
+ ```ts
169
+ await createApp({
170
+ sessionMode: 'stateless', // or { default: 'stateful', require: 'stateful' }
171
+ setup(core) { startMyWatcher(core.config); },
172
+ async teardown() { await stopMyWatcher(); },
173
+ });
174
+ ```
175
+
176
+ `sessionMode` declares the HTTP session posture in `src/` instead of leaving it to a deployment's `MCP_SESSION_MODE`, which still wins whenever it carries a meaningful value (an empty string and an unsubstituted `${…}` placeholder read as unset and fall through to the option). Add `require: 'stateful'` when a tool asks the caller for input mid-handler via `ctx.requestInput`: startup then fails with a `ConfigurationError` rather than serving a mode in which a 2025-era client can never answer the prompt. Stdio is never refused.
177
+
178
+ `teardown(core)` is the `setup()` counterpart — release a watcher, socket, or non-`unref()`'d timer there. It runs after the transport stops and before the logger closes, on every shutdown path, and a signal-triggered shutdown then exits the process explicitly (0, or 1 if a step never settles within the framework's 10 s ceiling).
179
+
180
+ This server declares `sessionMode: 'stateless'` — it holds no per-session state, so the session store and the per-session `McpServer` allocation are pure overhead and the process scales horizontally without them. `teardown` stops the catalog service's background refresh timer.
181
+
163
182
  ---
164
183
 
165
184
  ## Context
@@ -169,13 +188,14 @@ Handlers receive a unified `ctx` object. Key properties:
169
188
  | Property | Description |
170
189
  |:---------|:------------|
171
190
  | `ctx.log` | Request-scoped logger — `.debug()`, `.info()`, `.notice()`, `.warning()`, `.error()`. Auto-correlates requestId, traceId, tenantId. Dual-sink: Pino **and** `notifications/message` to the client, so treat it as client-visible. |
172
- | `ctx.state` | Tenant-scoped KV — `.get(key)`, `.set(key, value, { ttl? })`, `.delete(key)`, `.getMany(keys)`, `.list(prefix, { cursor, limit })`. Accepts any serializable value. |
191
+ | `ctx.state` | Tenant-scoped KV — `.get(key)`, `.set(key, value, { ttl? })`, `.delete(key)`, `.getMany(keys)`, `.list(prefix, { cursor, limit })`. Accepts any JSON-serializable value; reads return its JSON form (a `Date` comes back as an ISO string). |
173
192
  | `ctx.requestInput` | Suspend and ask the caller for more input — `return ctx.requestInput({ inputRequests: { key: inputRequired.elicit({ message, requestedSchema }) } })`. Never returns; the handler is re-entered with the answers. Always present. |
174
- | `ctx.inputs` | Reader over a retried request's responses — `.accepted(key, schema)`, `.view(key)`, `.state()`, `.dropped`. Empty on the first round. |
193
+ | `ctx.inputs` | The request's responses — `.accepted(key, schema)`, `.view(key)`, `.state()`, `.dropped` — limited to what the client declared (`elicitation` and its form/url modes, `sampling`, `roots`). Client-supplied: a consent gate trusts only a `ctx.state` record it stored when it asked, bound to the operation, caller, and target (see the `api-context` skill). |
194
+ | `ctx.clientCapabilities` | What the client declared for this request, `undefined` when no view exists. Decides whether to ask for optional context (e.g. roots); never a reason to skip a consent prompt. |
175
195
  | `ctx.enrich` | Success-path agent context (empty-result notices, query echo, pagination totals) — `ctx.enrich(...)` or `.notice()` / `.total()` / `.echo()` / `.truncated()`. Reaches `structuredContent` and `content[]`; lands only when the definition declares an `enrichment` block (no-op otherwise). |
176
196
  | `ctx.content` | Non-text content blocks — `.image(data, mimeType)`, `.audio(data, mimeType)`, or `ctx.content(block)` for a raw block. Prepended to `content[]` after `format()`; never enters `structuredContent`. |
177
197
  | `ctx.signal` | `AbortSignal` for cancellation. |
178
- | `ctx.requestId` | Unique request ID. |
198
+ | `ctx.requestId` | Request ID — the one every log record of the call carries and its error envelope returns as `data.requestId`. |
179
199
  | `ctx.tenantId` | Tenant ID from JWT; `'default'` for stdio or HTTP with auth off. |
180
200
 
181
201
  ---
@@ -184,7 +204,7 @@ Handlers receive a unified `ctx` object. Key properties:
184
204
 
185
205
  Handlers throw — the framework catches, classifies, and formats.
186
206
 
187
- **Recommended: typed error contract.** Declare `errors: [{ reason, code, when, recovery, retryable? }]` on `tool()` / `resource()` to receive `ctx.fail(reason, …)` typed against the reason union. TypeScript catches typos at compile time, `data.reason` is auto-populated for observability, and the linter enforces conformance against the handler body. `recovery` is required (≥ 5 words, lint-validated) — the single source of truth for the agent's next move. Pass `ctx.recoveryFor('reason')` as the throw's data to put it on the wire (`data.recovery.hint`, mirrored into `content[]` text); override with an explicit `{ recovery: { hint: '...' } }` when dynamic runtime context matters. Baseline codes (`InternalError`, `ServiceUnavailable`, `Timeout`, `ValidationError`, `SerializationError`) bubble freely and don't need declaring.
207
+ **Recommended: typed error contract.** Declare `errors: [{ reason, code, when, recovery, retryable?, severity?, thrownBy? }]` on `tool()` / `resource()` to receive `ctx.fail(reason, …)` typed against the reason union. TypeScript catches typos at compile time, `data.reason` is auto-populated for observability, linter enforces conformance against the handler body. `recovery` is required (≥ 5 words, lint-validated) — the single source of truth for the agent's next move. The framework puts it on the wire whenever a failure carrying that `reason` arrives without a hint — a bare `ctx.fail('reason')` or a service throw with `data: { reason }` — as `data.recovery.hint`, mirrored into `content[]` text unless the message already contains it verbatim; override with an explicit `{ recovery: { hint: '...' } }` when dynamic runtime context matters. Every error envelope also carries `data.requestId`, the id the server's log records for that call carry, and `content[]` closes with `(reason … · request <id>)`. Mark an entry the service layer throws with `thrownBy: 'service'` so `error-contract-unthrown` skips it — lint-only metadata, nothing at runtime reads it. Baseline codes (`InternalError`, `ServiceUnavailable`, `Timeout`, `ValidationError`, `SerializationError`, `RequestCancelled`) bubble freely and don't need declaring.
188
208
 
189
209
  ```ts
190
210
  import { JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';
@@ -196,7 +216,7 @@ errors: [
196
216
  ],
197
217
  async handler(input, ctx) {
198
218
  const item = await db.find(input.id);
199
- if (!item) throw ctx.fail('no_match', `No item ${input.id}`, ctx.recoveryFor('no_match'));
219
+ if (!item) throw ctx.fail('no_match', `No item ${input.id}`);
200
220
  return item;
201
221
  }
202
222
  ```
@@ -217,7 +237,7 @@ throw new Error('Invalid query format'); // → ValidationError
217
237
 
218
238
  // McpError — when no factory exists for the code
219
239
  import { McpError, JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';
220
- throw new McpError(JsonRpcErrorCode.DatabaseError, 'Connection failed', { pool: 'primary' });
240
+ throw new McpError(JsonRpcErrorCode.InitializationFailed, 'Connection failed', { pool: 'primary' });
221
241
  ```
222
242
 
223
243
  See framework CLAUDE.md and the `api-errors` skill for the full auto-classification table, all available factories, and the contract reference.
@@ -259,9 +279,9 @@ src/
259
279
 
260
280
  ## Skills
261
281
 
262
- Skills are modular instructions in `skills/` at the project root. Read them directly when a task matches — e.g., `skills/add-tool/SKILL.md` when adding a tool. `bun run list-skills` prints the full registry.
282
+ Skills are modular instructions in `framework-skills/` at the project root. Read them directly when a task matches — e.g., `framework-skills/add-tool/SKILL.md` when adding a tool. `bun run list-skills` prints the full registry. The directory is deliberately not `skills/`: Claude Code and Codex auto-load a plugin's root `skills/`, so a server that ships `.claude-plugin/` or `.codex-plugin/` would hand these development skills to every agent that installs it. Keep `skills/` free for skills meant for those agents.
263
283
 
264
- **Agent skill directory:** Copy skills into the directory your agent discovers (Claude Code: `.claude/skills/`, others: equivalent). Skills then load as context without referencing `skills/` paths. After framework updates, run the `maintenance` skill — Phase B re-syncs the agent directory.
284
+ **Agent skill directory:** Copy skills into the directory your agent discovers (Claude Code: `.claude/skills/`, others: equivalent). Skills then load as context without referencing `framework-skills/` paths. After framework updates, run the `maintenance` skill — Phase B re-syncs the agent directory.
265
285
 
266
286
  Available skills:
267
287
 
@@ -280,8 +300,9 @@ Available skills:
280
300
  | `security-pass` | Audit server for MCP-flavored security gaps: output injection, scope blast radius, input sinks, tenant isolation |
281
301
  | `code-simplifier` | Post-session cleanup against `git diff` — modernize syntax, consolidate duplication, align with the codebase |
282
302
  | `polish-docs-meta` | Finalize docs, README, metadata, and agent protocol for shipping |
283
- | `git-wrapup` | Land working-tree changes as a versioned commit + annotated tag — version bump, changelog, verify, tag. Local only. |
284
- | `release-and-publish` | Push + npm + MCP Registry + GH Release + Docker. Picks up from `git-wrapup` |
303
+ | `git-wrapup` | Land working-tree changes as a commit stack — version bump, changelog, verify, commit by concern, release commit on top. No tag, no push to main; opens the release PR when the project declares release PR mode |
304
+ | `release-pr-review` | Review pass on an open release PR — simplifier + correctness review, fixes as ordinary commits on top of the stack, PR body kept in sync. Release PR mode only |
305
+ | `release-and-publish` | Fast-forward merge (release PR mode) + tag + push + npm + MCP Registry + GH Release + Docker. Picks up from `git-wrapup` |
285
306
  | `maintenance` | Investigate changelogs, adopt upstream changes, sync skills to agent dirs |
286
307
  | `orchestrations` | Chain task skills into a gated multi-phase pipeline — build-out, QA-fix, update-ship — when you can spawn sub-agents |
287
308
  | `report-issue-framework` | File a bug or feature request against `@cyanheads/mcp-ts-core` via `gh` CLI |
@@ -300,7 +321,7 @@ Available skills:
300
321
  | `api-telemetry` | OTel catalog: spans, metrics, completion logs, env config, cardinality rules |
301
322
  | `api-workers` | Cloudflare Workers runtime |
302
323
 
303
- **Chaining skills into pipelines.** When the user wants a multi-phase effort — build this server out, QA-and-fix the surface, update-and-ship — *and you can spawn sub-agents*, `skills/orchestrations/SKILL.md` sequences the task skills above into a gated pipeline with verification at each step. Read it to drive the run. Optional: skip it if you can't orchestrate sub-agents, and ignore it entirely if you were *spawned* as one — you've already been scoped to a single phase.
324
+ **Chaining skills into pipelines.** When the user wants a multi-phase effort — build this server out, QA-and-fix the surface, update-and-ship — *and you can spawn sub-agents*, `framework-skills/orchestrations/SKILL.md` sequences the task skills above into a gated pipeline with verification at each step. Read it to drive the run. Optional: skip it if you can't orchestrate sub-agents, and ignore it entirely if you were *spawned* as one — you've already been scoped to a single phase.
304
325
 
305
326
  When you complete a skill's checklist, check the boxes and add a completion timestamp at the end (e.g., `Completed: 2026-03-11`).
306
327
 
@@ -316,7 +337,8 @@ When you complete a skill's checklist, check the boxes and add a completion time
316
337
  | `bun run rebuild` | Clean + build |
317
338
  | `bun run clean` | Remove build artifacts |
318
339
  | `bun run devcheck` | Lint + format + typecheck + security + changelog sync |
319
- | `bun run audit:refresh` | Delete `bun.lock`, reinstall, and re-run `bun audit`. Use when `devcheck` flags a transitive advisory — Bun's `update` is sticky on transitive resolutions, so the advisory may be a stale-lockfile false positive. If it survives the refresh, it's real. |
340
+ | `bun run audit:fix` | `bun audit fix` — upgrade vulnerable packages to the lowest safe version within existing ranges (`--dry-run` previews, `--latest` rewrites ranges). First response when `devcheck` flags a transitive advisory; then `bun update <name>`, then `bun dedupe` |
341
+ | `bun run audit:refresh` | Delete `bun.lock` and reinstall. Last resort after `audit:fix`, `bun update <name>`, and `bun dedupe` — re-resolves every ranged dep (the framework pin included) and rewrites the lockfile as `lockfileVersion: 2` |
320
342
  | `bun run lint:mcp` | Run the MCP definition linter standalone (rule catalog: `api-linter` skill) |
321
343
  | `bun run lint:packaging` | Packaging surface checks — `server.json`/`manifest.json` env-var parity (run by devcheck) |
322
344
  | `bun run list-skills` | Print the skill registry |
@@ -331,15 +353,17 @@ When you complete a skill's checklist, check the boxes and add a completion time
331
353
  | `bun run release:github` | Create GitHub Release from annotated tag (title format: `v<VERSION>: <subject>`) |
332
354
  | `bun run bundle` | Build, pack, and clean a `.mcpb` for one-click Claude Desktop install |
333
355
 
356
+ **CI is one file.** `.github/workflows/codeql.yml` (scaffolded) is the only GitHub Actions workflow: CodeQL is GitHub-owned end to end, and the file runs only while the repo's CodeQL *default setup* is turned off. Verification — `devcheck`, tests, the release gates — runs locally; don't add a workflow that re-runs it.
357
+
334
358
  ---
335
359
 
336
360
  ## Bundling
337
361
 
338
- `npm run bundle` produces a `.mcpb` extension bundle for one-click install in Claude Desktop. The pack step is followed by `scripts/clean-mcpb.ts`, which prunes dev dependencies (`mcpb clean`) and strips two classes of `node_modules/**` content that root-anchored `.mcpbignore` patterns cannot reach: dependency-shipped agent docs (`skills/`, `.claude/`, `.agents/`, `SKILL.md`) and platform-specific native bindings, which would otherwise lock the bundle to the platform it was packed on. A server using DataCanvas therefore ships a portable bundle without the DuckDB native — `@duckdb/node-api` is an optional peer loaded lazily, so canvas tools report an actionable install hint and every other tool works normally. MCPB is stdio-only — HTTP and Cloudflare Workers deployments are unaffected. Consumers who don't need it can delete `manifest.json` and `.mcpbignore`; `lint:packaging` skips cleanly.
362
+ `npm run bundle` produces a `.mcpb` extension bundle for one-click install in Claude Desktop. The pack step is followed by `scripts/clean-mcpb.ts`, which prunes dev dependencies (`mcpb clean`) and strips two classes of `node_modules/**` content that root-anchored `.mcpbignore` patterns cannot reach: dependency-shipped agent docs (`framework-skills/`, `skills/`, `.claude/`, `.agents/`, `SKILL.md`) and platform-specific native bindings, which would otherwise lock the bundle to the platform it was packed on. A server using DataCanvas therefore ships a portable bundle without the DuckDB native — `@duckdb/node-api` is an optional peer loaded lazily, so canvas tools report an actionable install hint and every other tool works normally. MCPB is stdio-only — HTTP and Cloudflare Workers deployments are unaffected. Consumers who don't need it can delete `manifest.json` and `.mcpbignore`; `lint:packaging` skips cleanly.
339
363
 
340
- **Adding an env var requires both files:** `server.json` (registry discovery, `environmentVariables[]`) and `manifest.json` (bundle install UX, `mcp_config.env` + `user_config`). `lint:packaging` (run by `devcheck`) verifies the env var names match.
364
+ **Adding an env var requires both files:** `server.json` (registry discovery, `environmentVariables[]`) and `manifest.json` (bundle install UX, `mcp_config.env` + `user_config`). `lint:packaging` (run by `devcheck`) verifies the env var names match, that every `user_config` option is wired into `mcp_config.env` as `"X": "${user_config.X}"` (the host substitutes nothing else — `"${X}"` reaches the server as that literal string), and that an optional string option carries `"default": ""`.
341
365
 
342
- **README install badges** (Claude Desktop `.mcpb`, Cursor, VS Code) and the `base64` / `encodeURIComponent` config-generation commands are ship-time concerns — run the `polish-docs-meta` skill, which carries the badge format, layout, and generation snippets in `skills/polish-docs-meta/references/readme.md`.
366
+ **README install badges** (Claude Desktop `.mcpb`, Cursor, VS Code) and the `base64` / `encodeURIComponent` config-generation commands are ship-time concerns — run the `polish-docs-meta` skill, which carries the badge format, layout, and generation snippets in `framework-skills/polish-docs-meta/references/readme.md`.
343
367
 
344
368
  ---
345
369
 
@@ -364,12 +388,18 @@ security: false # optional — true ONLY for a source
364
388
 
365
389
  `agent-notes` is an optional free-form field for maintenance agents processing the release downstream. Content here won't appear in the rendered CHANGELOG — it's consumed by agents running the `maintenance` skill. Use it for adoption instructions that don't fit the human-facing sections: new files to create, fields to populate, one-time migration steps. Omit entirely when there's nothing to say.
366
390
 
367
- **Section order** (Keep a Changelog): Added, Changed, Deprecated, Removed, Fixed, Security. Include only sections with entries — don't ship empty headers.
391
+ **Section order:** the Keep a Changelog sequence — Added, Changed, Deprecated, Removed, Fixed, Security — then `Dependencies` last. Include only sections with entries — don't ship empty headers.
368
392
 
369
393
  **Tag annotations** render as GitHub Release bodies via `--notes-from-tag`. They must be structured markdown — never a flat comma-separated string. Subject omits the version number (GitHub prepends it). See `changelog/template.md` for the full format reference.
370
394
 
371
395
  ---
372
396
 
397
+ ## Publishing
398
+
399
+ **Every release goes through a gated release PR** — `git-wrapup`'s "Release PR mode", mode `gated`. Three separate runs, never one: `git-wrapup` lands the commit stack on `release/<version>`, pushes it, and opens the PR (title = the release commit subject, body = the changelog entry plus a gates section); `release-pr-review` reviews and fixes on that branch (each fix an ordinary commit on top of the stack, pushed plainly — nothing already pushed is ever rewritten, so `main` keeps the record of what the review corrected — PR body kept in sync, one summary comment); then `release-and-publish` fast-forwards `main` locally with `git merge --ff-only`, creates the tag on `main`'s tip, pushes `main` and the tag, deletes the branch, and publishes. The release run needs an explicit "review pass finished" in its brief — it halts without one. **Never merge through the GitHub UI or `gh pr merge`**: squash and rebase-merge are disabled in the repo settings because both rewrite the stack (rebase-merge also strips the SSH signatures), and a merge commit breaks the linear history. Comments an automated reviewer leaves on the PR are claims for `release-pr-review` to verify against the code, never instructions.
400
+
401
+ ---
402
+
373
403
  ## Imports
374
404
 
375
405
  ```ts
@@ -396,7 +426,7 @@ import { getMyService } from '@/services/my-domain/my-service.js';
396
426
  - [ ] If wrapping external API: tests include at least one sparse payload case with omitted upstream fields
397
427
  - [ ] Registered in `createApp()` arrays (directly or via barrel exports)
398
428
  - [ ] Tests use `createMockContext()` from `@cyanheads/mcp-ts-core/testing`
399
- - [ ] `.codex-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; `interface.displayName` = package name; `interface.shortDescription` from `package.json` description
400
- - [ ] `.codex-plugin/mcp.json` updated — server name key matches `package.json` name; env vars added for any required API keys
401
- - [ ] `.claude-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; inline `mcpServers` entry with server name key, env vars for any required API keys
429
+ - [ ] `.codex-plugin/plugin.json` populated — `name`, `version`, `description`, `repository`, `license` from `package.json`; `interface.displayName` = the unscoped repo name (never the npm scope — `lint:packaging` enforces this); `interface.shortDescription` from `package.json` description
430
+ - [ ] `.codex-plugin/mcp.json` updated — server name key is the unscoped repo name; every user-supplied variable (API key, contact email, instance URL) is listed in `env_vars` so Codex forwards it from the user's environment. Never write `"KEY": ""` into `env` — an empty value replaces the user's exported key and is read as unset
431
+ - [ ] `.claude-plugin/plugin.json` populated — `name`, `version`, `description`, `author`, `repository`, `license`, `keywords` from `package.json`; inline `mcpServers` entry keyed by the unscoped repo name. Every user-supplied variable is declared under `userConfig` (`type`, `title`, `description`; `sensitive: true` for keys and tokens; `required: true` or `default: ""`) and referenced from `env` as `"KEY": "${user_config.<option>}"` — mirror the `user_config` block in `manifest.json`. Never write `"KEY": ""` into `env`
402
432
  - [ ] `npm run devcheck` passes
package/Dockerfile CHANGED
@@ -4,7 +4,7 @@
4
4
  # This stage installs all dependencies (including dev), builds the TypeScript
5
5
  # source code into JavaScript, and prepares the production assets.
6
6
  # ==============================================================================
7
- FROM --platform=$BUILDPLATFORM oven/bun:1.4.0 AS build
7
+ FROM --platform=$BUILDPLATFORM oven/bun:1.4.2 AS build
8
8
 
9
9
  WORKDIR /usr/src/app
10
10
 
@@ -23,6 +23,39 @@ COPY . .
23
23
  RUN bun run build
24
24
 
25
25
 
26
+ # Production dependencies are installed on the builder's native platform.
27
+ # Cross-install flags select native bindings for the runtime architecture.
28
+ FROM --platform=$BUILDPLATFORM oven/bun:1.4.2 AS deps
29
+
30
+ WORKDIR /usr/src/app
31
+
32
+ COPY package.json bun.lock bunfig.toml ./
33
+ COPY --from=build /usr/src/app/node_modules/@socketsecurity/bun-security-scanner ./node_modules/@socketsecurity/bun-security-scanner
34
+
35
+ ARG TARGETOS
36
+ ARG TARGETARCH
37
+ RUN case "$TARGETARCH" in \
38
+ amd64) echo x64 ;; \
39
+ arm64) echo arm64 ;; \
40
+ *) echo "Unsupported TARGETARCH '$TARGETARCH': expected amd64 or arm64" >&2; exit 1 ;; \
41
+ esac > .bun-cpu
42
+
43
+ RUN --mount=type=cache,target=/root/.bun/install/cache \
44
+ bun install --production --omit=peer --frozen-lockfile --ignore-scripts \
45
+ --os="$TARGETOS" --cpu="$(cat .bun-cpu)"
46
+
47
+ # Install OTel peers at the framework's tested ranges through the same scanner
48
+ # and release-age policy. Build with OTEL_ENABLED=false to omit them.
49
+ COPY scripts/install-otel.ts ./scripts/
50
+ ARG OTEL_ENABLED=true
51
+ RUN --mount=type=cache,target=/root/.bun/install/cache \
52
+ if [ "$OTEL_ENABLED" = "true" ]; then \
53
+ bun scripts/install-otel.ts --os="$TARGETOS" --cpu="$(cat .bun-cpu)"; \
54
+ fi
55
+
56
+ RUN rm -rf node_modules/@socketsecurity/bun-security-scanner
57
+
58
+
26
59
  # ==============================================================================
27
60
  # Production Stage
28
61
  #
@@ -30,7 +63,7 @@ RUN bun run build
30
63
  # application. It uses a slim base image and only includes production
31
64
  # dependencies and build artifacts.
32
65
  # ==============================================================================
33
- FROM oven/bun:1.4.0-slim AS production
66
+ FROM oven/bun:1.4.2-slim AS production
34
67
 
35
68
  WORKDIR /usr/src/app
36
69
 
@@ -46,32 +79,9 @@ LABEL org.opencontainers.image.licenses="Apache-2.0"
46
79
  LABEL org.opencontainers.image.version="${APP_VERSION}"
47
80
  LABEL org.opencontainers.image.source="https://github.com/cyanheads/cyanheads-mcp-server"
48
81
 
49
- # Copy dependency manifests
50
- COPY package.json bun.lock ./
51
-
52
- # Install only production dependencies, ignoring any lifecycle scripts (like 'prepare')
53
- # that are not needed in the final production image. `--omit=peer` excludes the
54
- # framework's optional peer tiers; direct runtime imports remain in dependencies.
55
- RUN --mount=type=cache,target=/root/.bun/install/cache \
56
- bun install --production --omit=peer --frozen-lockfile --ignore-scripts
57
-
58
- # Conditionally install OpenTelemetry optional peer dependencies (Tier 3).
59
- # These are not bundled by default to keep the base image lean. Enable at build time
60
- # with: docker build --build-arg OTEL_ENABLED=true
61
- ARG OTEL_ENABLED=true
62
- RUN --mount=type=cache,target=/root/.bun/install/cache \
63
- if [ "$OTEL_ENABLED" = "true" ]; then \
64
- bun add --omit=dev --omit=peer --ignore-scripts @hono/otel \
65
- @opentelemetry/instrumentation-http \
66
- @opentelemetry/exporter-metrics-otlp-http \
67
- @opentelemetry/exporter-trace-otlp-http \
68
- @opentelemetry/instrumentation-pino \
69
- @opentelemetry/resources \
70
- @opentelemetry/sdk-metrics \
71
- @opentelemetry/sdk-node \
72
- @opentelemetry/sdk-trace-node \
73
- @opentelemetry/semantic-conventions; \
74
- fi
82
+ # Keep the original manifest: the OTel install changes the deps-stage copy.
83
+ COPY package.json ./
84
+ COPY --from=deps /usr/src/app/node_modules ./node_modules
75
85
 
76
86
  # Copy the compiled application code from the build stage
77
87
  COPY --from=build /usr/src/app/dist ./dist
@@ -97,7 +107,6 @@ ENV MCP_TRANSPORT_TYPE="http"
97
107
  ENV MCP_SESSION_MODE="stateless"
98
108
  ENV MCP_LOG_LEVEL="info"
99
109
  ENV LOGS_DIR="/var/log/cyanheads-mcp-server"
100
- ENV MCP_FORCE_CONSOLE_LOGGING="true"
101
110
 
102
111
  # Expose the port the server listens on
103
112
  EXPOSE ${MCP_HTTP_PORT}