[lilyshen0722]

Encrypts discord_integrations.webhookUrl at rest and fixes the three blockers that made the encryption safe to switch on. Wren's ruling: option A, keyed with kind (74127). Gate: @vera.

The shape

connector_secrets is the envelope that already held Slack's bot token. A secret's identity becomes the pair (integrationId, kind); writers store only a ref (Integration.config.webhookUrlRef), readers resolve through one new module.

• services/connectorSecretKinds.ts — the single definition: kind, provider, the row paths that hold that kind's ref, and the sentence written for the person reading the Connectors page. Four sites encode the pair (the index, the upsert filter, the 11000 retry's filter, the orphan sweep's keep-condition) and all four read this instead of literals.
• utils/discordWebhookUrl.ts — the one precedence definition: encrypted ref wins, the two legacy plaintext stores (platformIntegration.webhookUrl, Integration.config.webhookUrl) are fallbacks. A ref that cannot be resolved throws rather than falling through to a plaintext copy: a wrong webhook URL does not fail authentication, it authenticates as a different connector (vera 74141 — a missing secret is loud, a substituted one is not).
• Writers — the connect path (routes/integrations.ts) and the lazy backfill (discordService.connect) both put the URL and $set the ref; only webhookId, which is not a secret, stays on the platform document.
• Strip list — webhookUrl and webhookUrlRef join SERVER_OWNED_CONFIG_KEYS (the URL is derived server-side on both writers; a planted ref would aim a row at another row's secret, and a planted URL would be picked up as the resolver's legacy fallback). webhookUrlRef also joins INTEGRATION_SECRET_CONFIG_KEYS so the pointer never rides out in a response.

The three blockers

#	Defect	Fix	Witness
1	sweepOrphanedConnectorSecrets kept a secret only on a Slack botTokenRef pair → revoked a Discord secret 10 min after put	keep-condition drawn from the registry, unrecognized kinds KEPT and logged (fail-closed)	"keeps a Discord webhook secret past the grace window while its row still points at it"
2	sweepUnavailableSlackSecretKeys marked any row "Slack connector secret key is unavailable" — user-facing since #1878/#1881	kind-aware reason; Slack's sentence unchanged	"names the Discord webhook, not a Slack key, when a Discord secret is unreadable"
3	upsertEncrypted filtered { integrationId } on both the upsert and the retry → second kind silently overwrote the first, first ref decrypting the second secret	kind in the filter; one index on the pair	"keys a secret by the PAIR…" + "declares exactly one index, on the pair"

Migration — separate gated step

backend/scripts/encrypt-discord-webhook-url (same shape as #1891): dry-run by default, --apply writes, digests instead of URLs, reads both plaintext stores (discord_integrations.webhookUrl and the legacy Integration.config.webhookUrl), and clears a row only after its own ref is stored — per row, put first, then both $unsets, so a failure of any kind leaves that row whole in both stores and a re-run reports it as still waiting. Corrected after vera's hold: the first draft also called listWithUnavailableKey() as a pre-flight and claimed it failed fast. That call does parse the key ring before it queries, so it would throw on an unusable ring — but so does every put, ahead of either $unset, so the pre-flight was redundant rather than protective and was removed rather than witnessed; the two suite witnesses below hold the ordering instead. (vera's correction at 74198: the first version of this note said the call “cannot fail”, which was false — listWithUnavailableKey's first statement is parseKeyRing().)

kubectl exec -n commonly-dev deploy/backend -- node -e "require('ts-node/register'); require('./scripts/encrypt-discord-webhook-url')"   # dry run first

Run it after this deploys: the current image reads the plaintext field directly.

Two things found while building, both disclosed

1. config on Integration is a strict subdocument, so an undeclared path in $set is dropped in silence. The ref write was a no-op until webhookUrlRef: String was declared beside webhookUrl. The witness that caught it is the created-row assertion in integrations.discordTokenCopy.test.js (it read undefined while every mocked-model suite stayed green).
2. The Discord connect path now depends on the connector-secret ring, exactly as the Slack bind already does. Without it a connect 500s instead of storing plaintext — fail-closed, and the ring is part of the deployment. Three route suites needed the ring in their setup; that is a real deployment dependency, not a test detail.

Verification

• full backend tier: 446 suites / 4167 tests passed, 0 failed (24 skipped by their own guards);
• tsc -p tsconfig.build.json --noEmit exit 0; eslint . --ext .ts 0 errors at the 1210-warning baseline;
• mutation ledger, no survivors — 8 arms on the code: M1 filter loses kind (2 red), M2 a second unique index (2 red), M3 Slack-only keep-condition (1 red), M4 Slack-only reason (1 red), M5 fall back instead of throw (2 red), M6 connect writes plaintext again (1 red), M7 the strip entries removed (1 red), M8 the schema declaration removed (1 red). On the migration script: vera's mutation — both $unsets above the put — reddens 3 named tests (both ordering witnesses + the empty-ring one), removing the dry-run guard reddens 1, and re-adding the deleted pre-flight is a survivor by design, and the reason it survives is that it is redundant — both it and put reach the same parseKeyRing() before any write, so no test can distinguish them;
• full backend tier re-run: 446 suites, the only two failures were the known oauthController total-count flake (TASK-134) and admin.analytics.human-filter, both green on re-run (24 passed).

Not changed, deliberately: installable/projectors/webhookProjector.ts still revokes only Slack refs on uninstall — the orphan sweep now covers a leftover Discord ref within the grace window, so a second revoke path would be duplicate machinery rather than a fix.