instar 1.3.243 → 1.3.244

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "instar",
-  "version": "1.3.243",
+  "version": "1.3.244",
   "description": "Coherence infrastructure for self-evolving AI agents — on the Claude Code or Codex subscription you already have.",
   "type": "module",
   "main": "dist/index.js",

package/src/data/builtin-manifest.json

@@ -1,8 +1,8 @@
 {
   "$schema": "./builtin-manifest.schema.json",
   "schemaVersion": 1,
-  "generatedAt": "2026-06-04T07:16:51.612Z",
-  "instarVersion": "1.3.243",
+  "generatedAt": "2026-06-04T16:26:00.075Z",
+  "instarVersion": "1.3.244",
   "entryCount": 198,
   "entries": {
     "hook:session-start": {

package/upgrades/1.3.244.md

@@ -0,0 +1,23 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+- The Telegram authorized-user check is now type-tolerant. The legacy auth path compared the incoming numeric Telegram id against the configured `authorizedUserIds` with a strict membership check, so an id written as a string in config silently failed to match and the authorized user was treated as unknown (hitting the registration gate).
+- The mini-onboarding auto-add now also compares ids loosely, so it no longer appends a duplicate when the configured list already holds the id as a string.
+
+## What to Tell Your User
+
+- **Telegram access fix**: "If your Telegram user id was ever written as text in my config, I would have wrongly treated you as a stranger and asked you to register. That comparison now ignores whether the id is stored as a number or text, so the right person is recognized either way."
+
+## Summary of New Capabilities
+
+| Capability | How to Use |
+|-----------|-----------|
+| Type-tolerant Telegram authorization | No action needed. Existing `authorizedUserIds` entries are honored whether they are stored as numbers or strings. |
+
+## Evidence
+
+Added a focused unit test (`telegram-auth-id-type-tolerant.test.ts`, 5 cases) covering number-configured ids, string-configured ids (the regression), mixed lists, unauthorized rejection, and the empty/open passthrough. `tsc --noEmit` is clean. CI is the authority across the full shard matrix.

package/upgrades/side-effects/telegram-auth-id-type-tolerant.md

@@ -0,0 +1,56 @@
+# Side-Effects Review — Telegram authorizedUserIds type-tolerant comparison
+
+**Version / slug:** `telegram-auth-id-type-tolerant`
+**Date:** `2026-06-04`
+**Author:** `echo`
+**Second-pass reviewer:** `not required`
+
+## Summary of the change
+
+The legacy (non-shared-AuthGate) Telegram auth path used
+`authorizedUserIds.includes(userId)` where `userId` is a `number` but the config
+field, though typed `number[]`, is untyped JSON at runtime and may hold the id as
+a string. `Array.prototype.includes` uses SameValueZero (no coercion), so a
+string-configured id silently failed to match and the authorized user was treated
+as unknown. The fix compares as strings (`authorized.some(id => String(id) ===
+String(userId))`), mirroring the shared-AuthGate path which is already string-based.
+The mini-onboarding auto-add (`server.ts`) is given the same loose membership check
+so it does not append a duplicate when the list already holds the id as a string.
+
+## Decision-point inventory
+
+One decision point: `isAuthorized(userId)` returns true/false (authorized vs gated).
+The change only affects WHICH equal-by-value ids match; it does not change the
+empty-list semantics (still "accept all" on the legacy path) or any other branch.
+
+## 1. Over-block
+
+**What legitimate inputs does this change reject?** None. The change only makes the
+comparison match MORE inputs that were always intended to match (an id equal by
+value, regardless of number-vs-string representation). No id that previously
+authorized stops authorizing: `String(n) === String(n)` holds for every number that
+`includes` would have matched. The empty/absent-list "accept all" path is untouched.
+
+## 2. Under-block
+
+**What does this still miss?** It does not change the fail-open vs fail-closed
+posture of the legacy path (empty list still accepts all — unchanged, out of scope).
+It does not touch the shared-AuthGate path (already string-based) or the Slack/
+WhatsApp/iMessage adapters (separate code, their own typing). It compares by exact
+string equality after coercion, so it intentionally does NOT treat e.g. leading-zero
+or whitespace-padded ids as equal — Telegram ids are canonical integers, so this is
+correct.
+
+## 3. Blast radius
+
+Two callsites: `TelegramAdapter.isAuthorized` (the auth gate) and the `server.ts`
+mini-onboarding auto-add. Both are Telegram-only. No schema, config-shape, or API
+change — existing configs (number ids, string ids, or mixed) all keep working, and
+configs that already worked are unaffected. Behavior strictly widens recognition to
+match the documented intent.
+
+## 4. Reversibility
+
+Fully reversible: revert the two edits. No state migration, no persisted format
+change. Config files are not rewritten by this change (the mini-onboarding still
+pushes a numeric id as before; it just no longer duplicates an existing string id).