switchroom 0.20.11 → 0.20.13

package/skills/switchroom-release/SKILL.md

@@ -22,12 +22,13 @@ Cut a release of `switchroom/switchroom` and get it live on the fleet. This is a
 1. `git fetch origin`, confirm `main` is at the commit you want released.
 2. `gh pr list --state open` — confirm no PR meant for this release is still open. Ask the operator if unsure.
 3. Confirm CI on `main` is green (`gh run list --branch main --limit 3`).
-4. Read `CHANGELOG.md` — the `## Unreleased` section is the staging area for this release's notes. If it's empty, there's nothing to release.
+4. Read `CHANGELOG.md` — the `## Unreleased` section is the **continuously-maintained** staging area for this release's notes. Every PR since the last release stages its own entry there as it merges, enforced by `scripts/check-changelog-entry.mjs` (part of `npm run lint`), so by release time this section should already read as a near-complete draft — you tidy and summarise, you do NOT author it from scratch. **An empty (or missing) `## Unreleased` at release time is now an ANOMALY, not the normal state:** it means either there genuinely is nothing to release, OR the enforcement was bypassed (`no-changelog` labels / `[skip changelog]` tokens on their own line on PRs that should have staged entries). Before assuming the former, cross-check against `git log <last-tag>..origin/main` — if real shippable work landed but Unreleased is bare, investigate and reconstruct rather than shipping a hollow release (this is exactly the v0.20.12 failure mode the enforcement exists to prevent).
 5. Pick the next version: read the latest tag (`git tag --list 'v*' --sort=-v:refname | head -1`) and bump the patch (or minor if the operator asks). Confirm with the operator which.
 
 ## Step 1 — Consolidate the changelog (the release commit is CHANGELOG-only)
 
-- Move the `## Unreleased` entries under a new `## vX.Y.Z — <one-line summary>` heading.
+- The section is maintained continuously (see pre-flight 4), so this step is now a **rename + tidy**, not authorship: change the `## Unreleased` header to `## vX.Y.Z — <one-line summary>`, then read through the staged entries and lightly edit for grouping/summary. If Unreleased was empty or thin, STOP and resolve the anomaly (pre-flight 4) before proceeding — do not invent a release note.
+- **Re-seed a fresh empty `## Unreleased` block at the top** (header + the convention HTML comment) immediately below `# Changelog`, so the staging area exists for the next cycle and `scripts/check-changelog-entry.mjs` keeps enforcing it. (Copy the comment block from the section you just renamed.)
 - The release commit touches **CHANGELOG.md only**. Do NOT bump `package.json` (placeholder discipline).
 - Branch protection blocks direct push to `main`, so: create a `release/vX.Y.Z` branch, push it, open a `chore: release vX.Y.Z` PR (base `main`), arm auto-merge (squash, delete-branch) on green CI.
 

package/telegram-plugin/README.md

@@ -38,8 +38,8 @@ adds the ergonomics and reliability that an always-on agent fleet needs:
 - **Switchroom slash-commands** — `/agents`, `/restart`, `/logs`, `/memory`,
   `/grant`, `/dangerous`, `/permissions`, `/reconcile` etc., handled by the
   plugin without consuming Claude Code tokens.
-- **11 MCP tools** — `reply`, `react`, `edit_message`,
-  `delete_message`, `forward_message`, `pin_message`, `send_typing`,
+- **10 MCP tools** — `reply`, `react`, `edit_message`,
+  `delete_message`, `forward_message`, `send_typing`,
   `download_attachment`, `get_recent_messages`, `send_checklist`,
   `update_checklist` (the latter two ship native Telegram checklists,
   see #272).
@@ -228,15 +228,6 @@ Sends a typing indicator ("Bot is typing...") to a chat. Auto-expires after ~5 s
 |-----------|----------|-------------|
 | `chat_id` | yes | Target chat ID |
 
-### `pin_message` tool
-
-Pins a message in a chat. Requires admin rights in groups.
-
-| Parameter | Required | Description |
-|-----------|----------|-------------|
-| `chat_id` | yes | Chat ID |
-| `message_id` | yes | Message to pin |
-
 ### `forward_message` tool
 
 Forwards an existing message to a chat, preserving original sender attribution. In forum topics, the forwarded message lands in the correct thread (auto-detected or explicit).

package/telegram-plugin/bridge/bridge.ts

@@ -213,18 +213,6 @@ const TOOL_SCHEMAS = [
       required: ['chat_id'],
     },
   },
-  {
-    name: 'pin_message',
-    description: 'Pin a message in a Telegram chat. Useful for important outputs the user wants to find later. Requires admin rights in groups.',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        chat_id: { type: 'string' },
-        message_id: { type: 'string' },
-      },
-      required: ['chat_id', 'message_id'],
-    },
-  },
   {
     name: 'delete_message',
     description: 'Delete a message the bot previously sent. Prefer edit_message if you just want to update text — delete_message is for true removal.',

package/telegram-plugin/bunfig.toml

@@ -2,9 +2,13 @@
 # `bun-test-run` job (scripts/bun-test-ci.sh) and `bun run --cwd telegram-plugin`.
 #
 # bun reads the bunfig.toml in its CWD only, so this file exists purely to load
-# the same state-dir hermeticity preload as the repo-root bunfig.toml. Keep the
-# two in sync; `npm run lint:agent-state-dir-hermeticity` fails if either stops
-# loading the guard. Rationale for the guard itself lives in
-# tests/vitest-setup/agent-state-dir-guard.mjs.
+# the same shared-state hermeticity preloads as the repo-root bunfig.toml. Keep
+# the two in sync; `npm run lint:agent-state-dir-hermeticity` and
+# `npm run lint:hindsight-bank-hermeticity` fail if either bunfig stops loading
+# either guard. Rationale lives in tests/vitest-setup/agent-state-dir-guard.mjs
+# and tests/vitest-setup/hindsight-bank-guard.mjs.
 [test]
-preload = ["../tests/vitest-setup/agent-state-dir-guard.mjs"]
+preload = [
+  "../tests/vitest-setup/agent-state-dir-guard.mjs",
+  "../tests/vitest-setup/hindsight-bank-guard.mjs",
+]

package/telegram-plugin/chat-lock.ts

@@ -2,7 +2,7 @@
  * Per-(chat, thread) FIFO serialization for outbound Telegram API calls.
  *
  * Without this, concurrent MCP tool handlers (reply, stream_reply, react,
- * edit_message, delete_message, pin_message, forward_message) all call
+ * edit_message, delete_message, forward_message) all call
  * `bot.api.*` independently. When two calls race, HTTP latency can flip
  * their delivery order — a later `reply` can land before an earlier
  * `stream_reply` edit, or a `react` can resolve before the `reply` it

package/telegram-plugin/dist/bridge/bridge.js

@@ -25196,18 +25196,6 @@ var TOOL_SCHEMAS = [
       required: ["chat_id"]
     }
   },
-  {
-    name: "pin_message",
-    description: "Pin a message in a Telegram chat. Useful for important outputs the user wants to find later. Requires admin rights in groups.",
-    inputSchema: {
-      type: "object",
-      properties: {
-        chat_id: { type: "string" },
-        message_id: { type: "string" }
-      },
-      required: ["chat_id", "message_id"]
-    }
-  },
   {
     name: "delete_message",
     description: "Delete a message the bot previously sent. Prefer edit_message if you just want to update text \u2014 delete_message is for true removal.",