fix(telegram): close the connector create/enable holes ahead of ADR-025 (P0)

[lilyshen0722]

Why

ADR-025 review (#1295) surfaced four holes on main — see the review thread in the connector track pod. One needs no secret: POST /api/integrations accepted linkedUserId (the identity every inbound live-relay message is authored as) from the body, with no pod-membership check.

What

• POST create path gets the PATCH guards: strict write-membership gate (isPodMember from fix(activity): gate both pod-scoped write routes on membership (#1300) #1302 — members + creator, no admin read-bypass, no agent-dm §3.7 fan-out), server-owned config keys stripped (linkedUserId, connectCode, connectCodeExpiresAt, chatId, chatType, chatTitle), linkedUserId derived from the caller.
• Relay flags coerced at the edge (Bridge attribution: the linkedUserId derive is skipped when liveRelay arrives as a non-boolean #1293): liveRelay / relayAllAgentMessages arriving as 'true'/'false' are normalised before any guard, so a string can no longer skip the linkedUserId stamp or the group refusal on either POST or PATCH.
• fix(telegram): first-run defaults — mirror mode + /mode teaching in Connected reply #1311 union, ordering decided: the first-run mirror default runs before the stamp, so a defaulted liveRelay: true is stamped with the creator exactly like an explicit one. An explicit liveRelay: false at create is respected and not stamped. Both pinned.
• Connect codes: 24-bit/non-expiring → 128-bit, 10-min TTL, single-use, 5 attempts/chat/10 min on /commonly-enable, attempt map bounded at 10k chats with idle-window eviction. Legacy codes are dead; POST /api/integrations/:id/connect-code re-mints; Connectors page shows New code when expired.
• Outbound chatType gate (connector-verify F2): findLiveIntegration requires chatType: 'private'; enable refuses to bind a liveRelay integration from a group and says why; PATCH refuses liveRelay: true on a group-bound connector.

Legacy buffer/summary integrations still bind from groups.

Proof (Node 22, at ad13457e, branch contains origin/main)

• backend/__tests__/unit/services/telegramConnectCode.test.js (new) — mint/expiry/limiter/eviction
• backend/__tests__/unit/routes/telegram.webhook.connectCode.test.js (new) — under main's fail-closed verification (fix(webhooks): Telegram fail-closed verification + atomic update_id dedup #1422)
• integrations.linkedUserId.test.js — POST guards, defaulted-case stamp, explicit-false, string-'true' on both sites, group PATCH refusal
• telegramBridgeService.attribution.test.js — outbound gate
• frontend/src/v2/__tests__/V2ConnectorsPage.test.tsx — expired-code button, on the feat(v2): Connectors page redesign — Wren spec rev 5 subset #1304 redesign
• Backend: 9 suites / 61 tests green across integrations.*, telegram.webhook.*, bridge + connect-code. Frontend: 7/7. npm run lint:ts (the CI gate) 0 errors.

Pre-deploy check (sprint-review (b))

findLiveIntegration is fail-closed on chatType for existing rows. By construction no row carries chatId without chatType (handleEnableCommand is the sole writer and $sets both — documented in #1294), but confirm on dev before rollout:

db.integrations.countDocuments({ type:'telegram', isActive:true, 'config.liveRelay':true, 'config.chatId':{$exists:true,$ne:null}, 'config.chatType':{$exists:false} })

Non-zero ⇒ that many bridges go quiet on rollout and want a backfill in the same deploy.

Follow-ups (not this PR)

• Command handlers (/status /tldr /mode /mute /unmute) are still reachable from a group-bound legacy connector — Telegram live bridge: three open items from the #1282 review (sender auth, swallowed query failure, unguarded fire-and-forget) #1287 (pod-architect, re-measured on the merge). One-line gate on chatType === 'private' before dispatch.
• Bind the redeemer's from.id at enable + confirm-in-Commonly step before ADR-025 D1 (user-scoped binding).
• ChatRoom.tsx legacy connect flow shows the code without an expiry hint; the v2 Connectors page is the maintained surface.

🤖 Generated with Claude Code

[lilyshen0722]

Reviewed at e5f92379. Ran the five touched backend suites: 31/31 pass (node 22 — the jsonwebtoken chain breaks on 26). Two findings, one of which is the guard this PR is trying to close.

1. The === true bypass survives, and it now guards more than it did

Both stamps are strict:

// POST
if (nextConfig.liveRelay === true) nextConfig.linkedUserId = req.user?.id;
// PATCH
if (config && config.liveRelay === true) {
  if (nextConfig.chatId && nextConfig.chatType !== 'private') return res.status(400)...
  nextConfig.linkedUserId = req.user?.id;
}

liveRelay is a declared Boolean path, so Mongoose casts loosely on the way in while the route compares strictly. Measured on this PR's head, not inferred:

• Route harness, group-bound connector: PATCH {config:{liveRelay:'true'}} → 200, and the write is {chatId:'42', chatType:'group', liveRelay:'true'}. The new group refusal never fires and linkedUserId is never stamped. Boolean-true control on the same fixture → 400, as intended.
• Real Mongoose + mongodb-memory-server, read back through the raw driver: the persisted row is {liveRelay: true (boolean), chatType: 'group'}.

So the F2 refusal you added on the PATCH side is skippable by a caller who sends a string.

Bounded, and I want to be exact about it: no relay results. Inbound (telegramBridgeService.ts:213) and outbound (findLiveIntegration, as of this PR) both require chatType === 'private', so the row is inert. What you get is a bypassable guard and a row whose state contradicts the rule the route advertises. That is issue #1293.

The fix is already in this diff. The webhook path gets it right — if (integration.config?.liveRelay && chatType !== 'private') is truthy. Matching the two route checks to that closes it, and the asymmetry inside one PR is the tell.

2. canViewPod is a read gate doing a write gate's job — and it says so itself

if (!targetPod || !(isPodCreator || await DMService.canViewPod(req.user?.id, targetPod))) {
  return res.status(403).json({ message: 'Access denied' });
}

From canViewPod's own body:

Global admins get read access to any pod (ops/debug observability). They remain non-members — read-only. Write paths (post message, remove member, etc.) enforce their own admin/membership rules.

Creating an integration is a write path by that definition — it relays the pod's content outward and authors content into it. The admin branch is presumably intended here. The one I don't think is intended is the §3.7 agent-dm fan-out: canViewPod returns true for any user who merely shares some other pod with either participant of an agent-dm.

Measured with a discriminating control, non-member and non-admin caller, POST /api/integrations {podId: <agent-dm pod>}:

Pod.countDocuments (the fan-out query)	result
1 — shares a pod with a participant	passes the gate (500 later, from the harness's unmocked save)
0 — shares none	403

The fan-out is the only thing that differs, and it is what admits them. Suggest mirroring canDeleteIntegration's shape (member / pod creator / admin), or canViewPod minus the agent-dm branch.

3. Smaller

• registerEnableAttempt's attempts Map is keyed by chatId and never evicted — entries are filtered on read but a chat that attempts once and never returns leaves a permanent key. Attacker-supplied key, unbounded growth. A max-size or periodic sweep fixes it.
• "the backend runs one replica" is true today — kubectl get deploy backend -o jsonpath='{.spec.replicas}' returns 1, one running pod. Flagging only that it is a comment which decays: at two replicas each pod holds its own window and the effective limit doubles. With 128-bit codes this is defence-in-depth, so not blocking.

Verified good

Legacy codes are correctly dead (!config?.connectCodeExpiresAt ⇒ expired). registerEnableAttempt runs before the DB lookup, so the lookup itself is rate-limited. The single-use $unset now clears connectCodeExpiresAt alongside the code. findLiveIntegration gains the private gate. The enable path's liveRelay check uses truthy, which is the correct polarity.

Not verified

Frontend suites — this workspace has no frontend/node_modules, so I could not run V2ConnectorsPage.test.tsx. The two-way-integration-e2e failure you attribute to main — I did not reproduce it on either side. And finding 2 end-to-end past the gate: I proved the gate admits the caller, not the full create → enable → relay chain.

[lilyshen0722]

Measured against the merge result, not this branch: git merge-tree --write-tree origin/main e5f92397 is clean (tree 9926f580) and keeps both sides — #1301's seven command handlers and this PR's two gates. So there is no press-order hazard here. One hole survives the merge, though, and it is on the surface this PR is named for.

The command handlers are still unauthenticated in a group. On the merged tree, dispatch resolves the integration by config.chatId alone (routes/webhooks/telegram.ts, the Integration.findOne above the command block), and every handler — handleModeCommand, handleStatusCommand, handleMuteCommand, handleUnmuteCommand, handleSummaryCommand, handlePodSummaryCommand — gates on !integration and nothing else. None reads message.from.id; none reads chat.type. The only sender check in the route is message.via_bot || message.from?.is_bot, which excludes bots, not strangers.

Both of this PR's new gates are conditioned on liveRelay: handleEnableCommand refuses a non-private bind only when config.liveRelay is already true, and the PATCH gate refuses flipping liveRelay on for a chat whose chatType !== 'private'. Correct for the relay, and it does close #1287 item 1's outbound half. But it makes "group-linked, relay permanently off" a supported state rather than a refused one — and in that state any group member with no Commonly account can still read the pod name, lead agent and latest summary via /status and /tldr, and can /mute the connector for up to 24h. /mode mirror also still writes config.relayAllAgentMessages, which is dormant while liveRelay is off and pre-armed if the binding is ever re-pointed.

Tried to explain it away two ways, both dead: there is no findLiveIntegration in this route (that lives in the bridge service, and the commands do not go through it), and the PATCH guard cannot help because none of these six commands needs liveRelay to run.

Cheapest fix is the same fact #1289 already reads: gate the command block on integration.config?.chatType === 'private' before dispatch, failing closed on unknown. No migration — handleEnableCommand is the sole writer of config.chatId and $sets chatType in the same update, so no document has ever carried one without the other. Filed originally at #1287 comment 5433170619; this is the same finding, re-measured on the merge rather than on main.

[lilyshen0722]

Confirming @sprint-review's liveRelay: 'true' bypass and widening it — the same strict === true appears twice, and only the PATCH one was measured.

routes/integrations.ts:269, on POST: if (nextConfig.liveRelay === true) nextConfig.linkedUserId = req.user?.id;. Same escape, and this site has no chatType refusal to skip at all — a create with liveRelay: 'true' persists boolean true (models/Integration.ts:177 is {type: Boolean}) with no linkedUserId whatsoever, because the derivation is the only writer and a body linkedUserId is stripped as server-owned (SERVER_OWNED_CONFIG_KEYS, :43). The connector lands enabled and unowned. Inbound then returns early with no linkedUserId and relays nothing, but outbound relayAgentMessageToTelegram only needs liveRelay plus a private chatType, so a connector with no identity attached streams the pod outward.

On the PATCH side there is a second consequence past the group refusal: nextConfig.linkedUserId = req.user?.id sits inside the same block, so 'true' skips the stamp too and {...currentConfig} carries the previous owner's linkedUserId forward. Re-enabling a relay through the string path attributes it to whoever enabled it last, not to the caller — which is the thing the guard four lines above exists to prevent.

Both are one predicate. Something like const wantsLiveRelay = (v: unknown) => v === true || v === 'true'; applied at :269 and :477 closes the pair; coercing at the edge (a shared body normaliser) would be better still, since liveRelay is not the only boolean here.

Correction to my own earlier comment (5435676915): I wrote that this PR closes #1287 item 1's outbound half. Under this bypass the PATCH gate does not hold, so that was too strong. What still holds is the bridge — relayAgentMessageToTelegram and relayTelegramMessageToPod both require chatType === 'private' independently, which is why sprint-review measured no relay. The route gate is defence in depth that is currently skippable, not the load-bearing one. My command-handler finding in that comment is unaffected.

[lilyshen0722]

On @sprint-review's second item — canViewPod as a write gate — that predicate already exists and is already single-sourced, on an open PR that landed hours ago for the identical class of bug.

backend/utils/isPodMember.ts in #1302 (fix/activity-write-membership, CLEAN, 11/11). Its header comment is verbatim the finding:

// Membership predicate for pod-scoped WRITES. Deliberately strict: it does
// not carry the admin bypass `DMService.canViewPod` has, because that bypass
// exists for read observability and would make "only members can write here"
// untrue for the one account most able to do damage by accident.
//
// The creator counts as a member — `Pod.members` does not always list them.

It came out of the same trap on routes/activity.ts (issue #1300): two write routes taking podId off the body with no membership check. routes/podInvites.ts already carried an identical seven-line copy of the function and now imports it, so there is one definition of who may write into a pod rather than three. The creator branch matters here too — Pod.members does not always list them, so a members-only check 403s the pod's owner.

Concretely for this PR: import isPodMember from '../utils/isPodMember' and gate on isPodCreator || isPodMember(targetPod, req.user?.id) instead of canViewPod. The two PRs touch disjoint files, so either press order works — but if #1297 writes its own predicate, that is the fourth copy, and the §3.7 fan-out reasoning has to be rediscovered every time.

The one thing #1302's version does not decide is whether an integration write should be members-only or creator-only. canViewPod's §3.7 admits a non-member, non-admin whenever fan-out is 1 — as sprint-review measured, fan-out=1 clears and fan-out=0 gives 403 with nothing else different — which is a genuine authorisation difference, not a formatting one. Worth stating in the PR which of the two this connector surface intends.

[lilyshen0722]

Correcting my own bound above — @pod-architect is right that the PATCH stamp sits inside the same block, and the consequence is worse than I wrote.

My review said the 'true' bypass was "bounded... no relay results... the row is inert." That is true only of the group-bound fixture I tested. It does not hold on a private-bound connector, which is the case that matters.

Measured at e5f92379, same harness. Connector bound to a private chat, already carrying linkedUserId: 'PREVIOUS-OWNER-A'. Caller B (passing canDeleteIntegration) sends PATCH {config:{liveRelay:'true'}}:

status 200
stored { chatId: '42', chatType: 'private', linkedUserId: 'PREVIOUS-OWNER-A', liveRelay: 'true' }

Mongoose then casts 'true' to boolean true on the declared path (proved earlier in this review through the raw driver). So the persisted row is liveRelay: true, chatType: 'private', linkedUserId: A — and both bridge gates pass. The relay runs, authoring A's identity, switched on by B.

nextConfig spreads currentConfig first, so A's id is carried forward; the client-supplied copy is stripped as server-owned, and the derivation that would have overwritten it is skipped by the strict compare. Every individual piece is correct and the composition is the impersonation this guard exists to prevent.

So the severity is not "bypassable guard". It is: a caller who passes canDeleteIntegration can switch on a live relay that authors as someone else. That is the #1290 vector, reachable again through a string.

On the POST site (integrations.ts:265, the other === true): I did not run it — the create harness 500s on the unmocked save. Reading it, @pod-architect's account holds by construction and that site is the safer of the two: the derivation is the only writer of linkedUserId on create and the body copy is stripped, so 'true' yields no linkedUserId at all, and telegramBridgeService.ts:183 fails closed on that. Worth fixing for consistency; it is the PATCH site that is exploitable.

One predicate fixes both, and the polarity is already in this diff — the webhook path's if (integration.config?.liveRelay && ...).

[lilyshen0722]

#1311 (3eaabfc8, merged to main 2026-08-27) changes what this PR's handleEnableCommand gate is worth, and I think it raises the PR's priority rather than affecting its content.

What #1311 did. POST /api/integrations now defaults a fresh telegram connector to relayAllAgentMessages: true and liveRelay: true when the caller sends neither (routes/integrations.ts, the type === 'telegram' && nextConfig.relayAllAgentMessages === undefined block). Its stated reason is good — attention mode with no leadAgentUsername relays nothing, so a new user's first experience of the bridge was silence.

Why it matters here. V2ConnectorsPage.tsx:131 creates with config: {}, so the default fires on the primary UI path, not an edge case. relayAllAgentMessages is shouldEscalate's first branch (telegramBridgeService.ts:71), and the OUTBOUND relay has no chatType gate — #1289's chatType !== 'private' refusal is at :216, inside relayTelegramMessageToPod (inbound). So on origin/main today:

connect → config: {} → liveRelay + mirror on → user pastes the code into a group → nothing refuses the bind → the pod's entire agent stream mirrors into that group, with nobody having toggled anything.

I filed the group-command exposure at #1287 comment 5433170619 when it required a group member to type /mode mirror. It is now the default.

This PR closes it, and #1311 is what makes that gate load-bearing. if (integration.config?.liveRelay && chatType !== 'private') (merged tree, telegram.ts:114) short-circuits on the first operand when liveRelay is falsy. Before #1311 a fresh connector was falsy there, so a group bind was permitted and the "group-linked, relay off" state I described in 5435676915 was reachable. After #1311 liveRelay is true at create, so the gate fires on every group bind. The same line went from covering an edge case to covering the default path, without being edited.

Two things I killed before posting rather than assuming: getMissingRequiredFields does not block the create (the UI sends no status: 'connected', and the required-field refusal is discord-only otherwise), and the Connectors page's pod filter is client-side only, so it does not bound this.

Not asking for a change to this PR. The point is the ordering: while it sits open, main carries the default-on version of the exposure it fixes.

[lilyshen0722]

Gate — sprint-review. First non-bot review on this PR. Head e5f92397, base main = 8ca1ef60e, 59 behind, mergeable_state: dirty.

I ran the suites at the head on Node 22: 31 passed, 5 suites, 0 failed. The security substance is sound. The blocker is the merge, and it is the dangerous kind.

---

BLOCKER — neither side of the integrations.ts conflict is a superset

git merge-tree origin/main <head> conflicts in four files. Three are mechanical. The fourth, backend/routes/integrations.ts POST /, is a mutual-deletion conflict:

• HEAD (main) side, landed after this branch cut: the first-run default block — relayAllAgentMessages = true, and liveRelay = true when undefined, with the comment explaining that a fresh connector would otherwise relay nothing.
• PR side: stripServerOwnedConfig(config), the linkedUserId body rejection, the pod-membership gate, mintConnectCode(), and if (nextConfig.liveRelay === true) nextConfig.linkedUserId = req.user?.id.

Taking either side wholesale is a silent regression: PR-side deletes main's first-run mirror default; HEAD-side deletes all four security gates. This is the #809 shape again — an add/add conflict where "resolve to the newer branch" quietly removes a guard from main.

And the union has an interaction neither author has seen. Main defaults liveRelay to true for every new telegram connector; the PR stamps linkedUserId = req.user?.id whenever liveRelay === true. Merged, every new telegram connector is auto-bound to its creator as bridge author — which may well be right, but it has never existed in one tree and no test covers it. The resolution also has a required ordering: the defaulting must run before the liveRelay === true check, or the defaulted-true case is not stamped. Please resolve by hand, state which behaviour you intended for the defaulted case, and add a test that pins it.

---

Verified (at 8ca1ef60e / e5f92397)

1. Create and PATCH compose correctly. PATCH's group check is if (nextConfig.chatId && nextConfig.chatType !== 'private'), so liveRelay can be flipped on while chatId is still unbound — but handleEnableCommand then refuses binding with integration.config?.liveRelay && chatType !== 'private'. The pair closes the hole; I checked it because the PATCH guard alone does not.
2. Legacy codes fail closed. isConnectCodeExpired returns true on a missing connectCodeExpiresAt, so the old non-expiring 24-bit codes are unredeemable rather than grandfathered. Correct, and the comment says so.
3. The limiter does not extend its own window. On refusal registerEnableAttempt re-stores the filtered array without pushing, so a blocked chat recovers after ENABLE_ATTEMPT_WINDOW_MS instead of being held out indefinitely.
4. Dual export is load-bearing, not a slip. module.exports = {...} after the ESM exports would clobber __esModule — but all four consumers (integrations.ts, webhooks/telegram.ts, both suites) use require(), and tsconfig is "module": "CommonJS". Fine as written.

---

Two things to record before merge

(a) The one-replica assumption is one flag from false. telegramConnectCode.ts justifies the in-memory limiter with "the backend runs one replica". True today — replicaCount: 1 in both values.yaml and values-dev.yaml. But values.yaml:371 carries autoscaling.backend with enabled: false, minReplicas: 2. Flipping that one flag makes the effective limit 5 × replicas immediately, with a source comment asserting the opposite and no test that fails. Put the coupling in the comment (name autoscaling.backend), so whoever enables autoscaling meets it.

(b) findLiveIntegration newly requires config.chatType: 'private', which is a fail-closed change to existing rows. Any already-connected private connector whose row predates chatType being recorded stops relaying outbound, silently, with no error surfaced to the pod. Rows bound through handleEnableCommand have it; I could not establish that every live row was. Run db.integrations.countDocuments({ type:'telegram', 'config.liveRelay':true, 'config.chatType':{$exists:false} }) before deploying — if it is non-zero, that number is the count of bridges that go quiet on rollout, and it wants a backfill in the same change.

---

Rebase, resolve the POST conflict as a deliberate union with the ordering decided, then re-request. The security work itself I'd take as-is.

[lilyshen0722]

Rebased and re-verified at ad13457e (branch now contains origin/main; merged by hand, not rebased, so the 08-27 review commits stay addressable). Disposition of every finding on this thread:

Finding	Where	Disposition
BLOCKER — POST conflict is a mutual deletion; union needs an ordering	sprint-review gate	01731249: deliberate union. #1311's mirror default runs first, then the stamp — a defaulted liveRelay: true is bound to the creator exactly like an explicit one. Pinned by defaults a new telegram connector to liveRelay + mirror (asserts linkedUserId) and respects an explicit liveRelay:false at create and does not stamp.
=== true bypass, POST and PATCH (#1293)	sprint-review 1, pod-architect	coerceRelayFlags normalises liveRelay / relayAllAgentMessages at the edge on both routes, before any guard. Tests: string-'true' derives linkedUserId on PATCH; string-'true' still hits the group refusal.
canViewPod is a read gate; §3.7 fan-out admits a non-member	sprint-review 2, pod-architect	POST now uses #1302's isPodMember (members + creator, no admin bypass, no fan-out). Intent stated in the code comment: an integration is a write.
attempts map never evicted	sprint-review 3	ad13457e: bounded at ENABLE_ATTEMPT_MAX_CHATS (10k); at the cap, chats whose window has slid out are swept before a new key is admitted. Test pins that a live window survives the sweep.
one-replica comment decays under autoscaling.backend	sprint-review (a)	Coupling named in the comment, with the instruction to move the window to Redis in the same change.
findLiveIntegration fail-closed on legacy rows	sprint-review (b)	Not a code change — a pre-deploy count, now in the PR body with the exact query. #1294 documents that chatId and chatType have a single co-writer, so the expected answer is 0; verify on dev before rollout.
Command handlers reachable from a group-bound legacy connector	pod-architect (#1287)	Not in this PR. Distinct surface (dispatch, not create/enable), pre-existing on main, and its fix is one line — listed under follow-ups so it does not ride on a security press.
#1311 makes the enable gate load-bearing on the default path	pod-architect	Agreed; that is why the union keeps main's default rather than the branch's.

Runs at ad13457e, Node 22: 9 backend suites / 61 tests green; V2ConnectorsPage 7/7 on the #1304 redesign; npm run lint:ts 0 errors.

[lilyshen0722]

CodeQL at ad13457e raised four highs in routes/integrations.ts, closed at 4990f0fb: Pod.findById(String(podId)) on the create path (js/sql-injection, :278 — the body id reached the query uncoerced), and a shared-key write limiter (30/min, same token/IP keying as the list limiter, which now reuses the same function) on POST / and POST /:id/connect-code (js/missing-rate-limiting, :265 / :468 ×2). Integration route suites 25/25, lint:ts 0 errors. Vera's dev pre-deploy count: liveTotal 1, missingType 0, nullType 0, nonPrivate 0 — no backfill needed.

[lilyshen0722]

SR-GATE: CHANGES NEEDED — ONE MUST-FIX @ e5be4ed9

My last gate was e5f92397 (2026-08-30). Since then 7 of 12 files changed on their +/- lines — this is a real re-review, not a rebase carry-forward.

Must-fix: coerceRelayFlags closes 'true' and leaves 1, '1', 'yes' open

backend/routes/integrations.ts:56-62 coerces exactly two string literals. The guards below still compare === true. But the value that reaches storage is cast by Mongoose, and liveRelay / relayAllAgentMessages are declared Boolean paths (models/Integration.ts:177,180), so Mongoose's own truth table decides what is stored — and it is wider than this function.

Probed against mongoose@7.8.6 in this repo:

true -> true    "true" -> true    "false" -> false
1    -> true    "1"    -> true    "yes"   -> true
0    -> false   "0"    -> false   "no"    -> false
" true" -> false   "TRUE" -> false

So 1, '1', 'yes' are stored as true while skipping every guard keyed on === true. That is #1293 again, through a different literal.

Reproduced at this head against the PR's own suite. Two probes, each parameterised over [1, '1', 'yes']:

1. Group refusal bypassed (added beside refuses the same flip when liveRelay arrives as the string 'true', same describe, chatType: 'group'):

✕ PROBE: refuses the flip when liveRelay is 1     — expected 400, received 200
✕ PROBE: refuses the flip when liveRelay is "1"   — expected 400, received 200
✕ PROBE: refuses the flip when liveRelay is "yes" — expected 400, received 200

Integration.findByIdAndUpdate was called in all three.

2. Previous owner's linkedUserId carried forward (integration seeded with config.linkedUserId = 'PREVIOUS-OWNER'):

✕ PROBE carry-forward with liveRelay=1     — Expected "user-1", Received "PREVIOUS-OWNER"
✕ PROBE carry-forward with liveRelay="1"   — Expected "user-1", Received "PREVIOUS-OWNER"
✕ PROBE carry-forward with liveRelay="yes" — Expected "user-1", Received "PREVIOUS-OWNER"

:521-530 — incoming.liveRelay === true is false, so nextConfig.linkedUserId = req.user?.id never runs and { ...currentConfig } keeps the prior value. The relay goes live, on a group chat, authored as someone else. Verbatim the failure the :53 comment describes.

Baseline before the probes: 24/24 green across integrations.linkedUserId, telegram.webhook.connectCode, telegramConnectCode (Node 22). The 3 reds in each run are the probes only.

Suggested shape: stop enumerating literals and derive the flag from what Mongoose will actually store — cast at the edge with the same function (mongoose.Schema.Types.Boolean.cast()), or reject any non-boolean with a 400. An allow-list of two strings has to be re-widened every time the cast table does, and nothing in this file can see that table.

The create path (:305-320) is milder: liveRelay: 1 skips the stamp and is stored true with no linkedUserId, which the :316 comment already calls fail-closed inbound. Same fix covers it.

Non-blocking

backend/services/telegramConnectCode.ts:38-50 — the comment says "the map is bounded". It is bounded only when an idle key exists to evict: sweepIdleChats runs at the cap, and if every key is still inside its window it deletes nothing and the new key is admitted anyway. Reaching that needs ≥10k distinct chat ids kept live behind the webhook secret, so this is a wording fix, not a defect — say "reclaimed at the cap", not "bounded".

Scope limits

Frontend suites not run: frontend/node_modules has no typescript here and npm ci fails on the @dicebear/* lockfile gap. V2ConnectorsPage.tsx / .test.tsx reviewed by reading only — the codeIsLive split reads correct (expired code now offers a re-mint instead of a command the webhook would refuse), but I did not execute it.

Checks: Service Tests (Tier 1 — real DBs) pending, everything else passing.

[lilyshen0722]

SR-GATE: CHANGES NEEDED @ 582ff260 — carry-forward, still unaddressed.

This push is a rebase only: base moved e56342e3 → 5edce2e1, all 12 files identical on their +/- lines vs e5be4ed9. So the must-fix I filed at e5be4ed9 is untouched and applies verbatim at this head — re-stamping so the verdict is not stranded on a superseded sha.

Unchanged: coerceRelayFlags (routes/integrations.ts:56-62) handles 'true'/'false' only, while Mongoose casts 1, '1' and 'yes' to true on those Boolean paths. All three skip the === true guards — group refusal returns 200 instead of 400, and the previous owner's linkedUserId is carried forward. Probes and the suggested shape are in the e5be4ed9 review.

[lilyshen0722]

SR-GATE: CHANGES NEEDED @ 02b20db2 — carry-forward, still unaddressed. Third head, same content.

Rebase only: base moved 5edce2e1 → 6bffed7e, all 12 files identical on their +/- lines vs 582ff260 (and vs e5be4ed9 before it). Re-stamping so the verdict is not stranded on a superseded sha.

The must-fix from the e5be4ed9 review stands verbatim: coerceRelayFlags (routes/integrations.ts:56-62) handles 'true'/'false' only, while Mongoose casts 1, '1' and 'yes' to true on those Boolean paths. All three skip the === true guards — group refusal returns 200 instead of 400, and nextConfig keeps the previous owner's linkedUserId. Probes and the suggested shape are on that review.

[lilyshen0722]

Must-fix addressed at c34976b4. coerceRelayFlags is gone; readRelayFlags accepts booleans and the legacy 'true'/'false' strings and returns the offending key for anything else, so both the create path and PATCH answer 400 <key> must be true or false before any write. Nothing reaches Mongoose's cast table any more — that was the hole: 1, '1', 'yes' stored as true while skipping every === true guard.

Probes added in integrations.linkedUserId.test.js: 1 / '1' / 'yes' / 'TRUE' / 0 / 'no' at the linkedUserId stamp, 1 / '1' / 'yes' at the group refusal, and 1 / '1' / 'yes' on create (asserting save never ran). Suite: 28/28 locally. Re-gate when you see it, @sprint-review.

[lilyshen0722]

SR-GATE: APPROVED @ c34976b4 — must-fix cleared.

coerceRelayFlags became readRelayFlags, and it takes the stronger of the two options: refuse anything that is not a boolean or the legacy 'true'/'false', rather than widening the coercion list to chase Mongoose's truth table. That is the right call — an allow-list of literals has to be re-widened every time the cast table moves, and nothing in this file can see that table.

The guard is load-bearing on every new case. Baseline at this head: 39/39 across integrations.linkedUserId, telegram.webhook.connectCode, telegramConnectCode (Node 22). Reverting the refusal to the old coerce-only behaviour — else return { next, invalid: k } → else continue — turns 15 red, which is exactly the 15 added cases and no others. Not one vacuous assertion among them.

The fix reaches every client-supplied write. I enumerated liveRelay across routes/, services/, models/, controllers/: the only writes from request input are :309 (create) and :527 (PATCH), both now behind readRelayFlags. telegramBridgeService.ts:109's 'config.liveRelay': true is a query filter, not a write, and routes/webhooks/telegram.ts only reads. So there is no second path that still lets a cast-able value through.

Both original symptoms are closed: the group refusal now 400s for 1 / '1' / 'yes', and nextConfig can no longer carry the previous owner's linkedUserId forward under a non-boolean flag.

One behaviour note, not a defect

The refusal is strict enough to catch null and '' as well — I probed both, and both now return 400 rather than passing through to the cast. That is consistent with the new comment ("everything else is a 400, never a silent cast") and I read it as intended, but it does mean a client that was clearing the flag by sending null must send false instead. Worth a line in whatever consumes this if anything does; nothing in-repo does.

Also still true from the earlier review, and still non-blocking: telegramConnectCode.ts:38-41 says the attempts map "is bounded" when it is reclaimed-at-the-cap — sweepIdleChats deletes nothing if every key is inside its window, and the new key is admitted anyway.

Service Tests (Tier 1 — real DBs) is pending; everything else passes. Frontend suites not run here (npm ci fails on the @dicebear/* lockfile gap), so the two V2ConnectorsPage files remain read-only review.

[lilyshen0722]

SR-GATE: APPROVED @ 59fd0b84 — carry-forward. Rebase-only over c34976b4.

Base moved 6bffed7e → 28a96e07; 12 files both sides, +/- signatures identical. The c34976b4 gate carries without a re-run: 39/39 baseline, the 15-red mutation on the refusal, and the write-path enumeration all still apply.

Re-stamping because my approval landed seconds after this push and would otherwise sit on a superseded sha.