[objectstack-fleet]

Requested by Elon · project thread

domain:server#3 · os-elon-musk · session_016WV4cxRP1AqTeP2PWAhwGK

Refs #26710

Clause-②: yes (widening: one member added to the closed signing-scheme list and one shape to the signed union; one schema export and its type added. ConnectorRequestSigner.scheme is now typed by the scheme list, but that interface is in no release yet: it ships with #28273's pending changeset, so no published surface narrows)
Metadata-protocol: added

维护者速读

• 改了什么:signed 认证新增第二个签名方案，腾讯云 API 3.0 签名 v3(tencentcloud-tc3-hmac-sha256)。元数据仍只写方案名、公开的 SecretId(keyId)和密钥引用 credentialRef;rest / openapi 每次请求(含重试)用新的时间戳重新签名。
• 为什么改:connectors: request-signing auth kind for the openapi and rest providers (RSA2 / HMAC canonical-request signers: Alipay, WeChat Pay, Aliyun, Tencent Cloud, e签宝) — the vendor-auth half that #26702 does not cover #26710 第二片(ADR-0143 Q4 A 的第二个成员)。腾讯官方文档示例把 SecretKey 打了码，无法复现，所以按 D2.3 改用腾讯官方 Node SDK 的测试向量，测试里写明了 SDK 和版本。
• 拒绝什么：与第一片相同。内联密钥按名拒绝、手写 signature 拒绝、mcp 上拒绝;secretId 提示改写为 keyId;未知 scheme 的提示现在列出两个方案。
• 没变的:阿里云方案、bearer / api-key / basic 不变;签名接缝只把 scheme 的类型从任意字符串收紧到方案列表(该接口尚未发布)。
• 先看:packages/services/service-automation/src/request-signing/tencentcloud-tc3-hmac-sha256.ts 和它的测试。
• 两分钟验证:pnpm --filter @objectstack/service-automation exec vitest run src/request-signing,看到腾讯 SDK 的 POST 与 GET 两个签名逐字节复现，错误密钥得到不同签名。
• 需要你做的：无。契约复审(CONTRACT_REVIEW_TIER)待做;Tier S,席位验收后落地。

What changes

@objectstack/spec

• ConnectorSigningSchemeSchema gains tencentcloud-tc3-hmac-sha256. The signed union gains ConnectorInstanceSignedTencentCloudTc3AuthSchema: { type: 'signed', scheme: 'tencentcloud-tc3-hmac-sha256', keyId, credentialRef }, a strictObject. keyId is the SecretId. The SecretKey is only ever a credentialRef.
• The publish door refuses on the new shape what it refuses on the first one: secret, privateKey, secretKey and accessKeySecret by name with the credentialRef prescription, an authored signature, and signed on provider: 'mcp'. secretId is answered with keyId. The unknown-scheme refusal names both shipped schemes.
• The review nit from feat(spec): signed connector instance auth, with aliyun-acs3-hmac-sha256 signing every request (ADR-0143 D2.3, slice 1 of #26710) #28273 is fixed: ConnectorRequestSigner.scheme is typed ConnectorSigningScheme rather than string.

@objectstack/service-automation

• request-signing/tencentcloud-tc3-hmac-sha256.ts:
  • The canonical request is the method, the path, the query exactly as sent, content-type: and host:, content-type;host, and the hex SHA-256 of the body.
  • The string to sign is TC3-HMAC-SHA256, the timestamp, the scope <date>/<service>/tc3_request and the hashed canonical request.
  • The key is derived HMAC("TC3"+SecretKey, date) → service → tc3_request.
  • Every attempt gets a fresh X-TC-Timestamp.
  • The service is the first label of the endpoint host (regional endpoints included).
  • X-TC-Action / -Version / -Region stay unsigned, as in the vendor's SDK.
  • A request that names no content type is signed and sent with application/x-www-form-urlencoded (what the SDK sends on a GET), so the signed header is the sent header.
• The registry gains the case. Its exhaustive check now tests auth itself against never, which still names an unhandled scheme at compile time (ablation below).

Docs: connectors.mdx "Request signing" gains the Tencent example and the scheme's header rules. The variant-docs.json scheme key lists both members. The references are regenerated with check:generated --fix.

The surface is inside the amended claim 6535175098.

Why

ADR-0143 D2.3 / Q4 A: the closed list grows one scheme at a time, each with its signer and vectors. D2.3's vector rule takes the vendor's worked example when it is complete, and otherwise the vendor's official SDK test suite named with its version. Tencent's own example masks the SecretKey, so this slice takes the second branch.

Verification

• Vectors: tencentcloud-tc3-hmac-sha256.test.ts reproduces, byte for byte, the two sign3 cases of the official tencentcloud-sdk-nodejs release 4.1.336, test/common/sign.test.ts: POST application/json and GET application/x-www-form-urlencoded. It uses that suite's own placeholder key pair, timestamp and service, and the file header names the SDK, release and file. The suite's multipart case is not carried, because a signed body is text here. A wrong key gives a different signature. The bound signer at the vector's instant gives the vector.
• Beyond the vectors:
  • The unsigned API headers do not move the signature.
  • A request with no content type gets the form type, and its signature equals the GET vector. CONTROL: a typed request is not given another type.
  • A regional host scopes to cvm.
  • The query is signed as sent.
  • The timestamp is fresh per request.
  • The registry binds the scheme, and the key is absent from the output.
  • 23 signing tests pass.
• Publish door: connector-auth-signed.test.ts adds:
  • a CONTROL accept on rest and openapi
  • the inline-key refusals over both schemes
  • the secretId alias
  • both names in the unknown-scheme message
  • union membership
• End to end: connector-rest-plugin.test.ts runs a real host with the rest provider and a tencentcloud-tc3-hmac-sha256 instance. The call carries a TC3 Authorization scoped to cvm and an X-TC-Timestamp, and the key is absent from calls and descriptors.
• Suites:
  • spec signed, fetch-policy, grant-kinds, connector-auth and pins: 74 passed.
  • service-automation signing, materialization and credential source: 105 passed.
  • connector-rest: 33 passed.
  • connector-openapi: 75 passed.
• pnpm --filter <pkg> typecheck is green for spec, service-automation and connector-rest.
• Ablations:
  • With the tencentcloud-tc3-hmac-sha256 registry case removed, service-automation typecheck fails, naming the unhandled shape (TS2322 at the never check).
  • With the "TC3" prefix dropped from the key derivation, 6 vector pins go red.
  • With the code as pushed, everything is green.
• Every family dispatch-gates --commands derives (105) ran and exited 0, reconciled with --ran: 105 run, 0 NOT-MEASURED. pnpm lint exits 0.

Skills-docs: grep -rlnE "credentialRef|app-credential|api-key" skills hits skills/objectstack-automation/{SKILL.md,references/integration-recipes.md,evals/integrations-declared.json}. The signed text rides #28226, as for #28273, because a skills/** edit would make this slice Tier H. content/docs/automation/connectors.mdx carries it here.

Human Minimum

• 1. Schemas start as Zod; packages/spec holds no runtime logic. (The signer is in service-automation.)
• 2. Every name I added uses the casing for its kind.
• 3. No formatter ran; pnpm lint passes.
• 4. One issue, one branch off an up-to-date main, one pull request (slice 2 of 3 of connectors: request-signing auth kind for the openapi and rest providers (RSA2 / HMAC canonical-request signers: Alipay, WeChat Pay, Aliyun, Tencent Cloud, e签宝) — the vendor-auth half that #26702 does not cover #26710).
• 5. A change that publishes carries a changeset, and both declaration lines are filled in here and in the changeset.
• 6. packages/spec touched: its generated artifacts are regenerated and committed.
• 7. No hand edits to content/docs/references/, packages/*/CHANGELOG.md or content/docs/releases/.
• 8. Title, body and comments are in English (the 维护者速读 block is the lane's maintainer summary).

🤖 Generated with Claude Code

https://claude.ai/code/session_016WV4cxRP1AqTeP2PWAhwGK

[github-actions]

📓 Docs Drift Check

This PR changes 2 package(s): @objectstack/service-automation, @objectstack/spec, touching 16 documentable anchor(s). ⚠️ 7 changed file(s) yielded no anchor (packages/spec/api-surface/integration.json, packages/spec/authorable-surface/integration.json, packages/spec/declaration-map/integration.json, …), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/automation/connectors.mdx (via keyId (literal, a string literal in ConnectorInstanceSignedTencentCloudTc3AuthSchema))
• content/docs/plugins/index.mdx (via keyId (literal, a string literal in ConnectorInstanceSignedTencentCloudTc3AuthSchema))
• content/docs/protocol/objectql/security.mdx (via keyId (literal, a string literal in ConnectorInstanceSignedTencentCloudTc3AuthSchema))

What this run could not see

• 7 changed file(s) yielded no anchor (packages/spec/api-surface/integration.json, packages/spec/authorable-surface/integration.json, packages/spec/declaration-map/integration.json, …) — pages documenting those are invisible to this run
• 4 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 59 of 211 client-bound route-ledger rows — the other 152 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 152: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 97 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 168 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 6285203da7ec7e0587b6aab25ebfb28277ab454d → packageMentionDocs.

Which tree this was computed on

This run read content/docs from a997b267d297f4cef00f5d1ce38b1065f859bf11 — the merge of head baa3375ab08c377e5d9f590c0ae655080165066e into base 6285203da7ec7e0587b6aab25ebfb28277ab454d, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin a997b267d297f4cef00f5d1ce38b1065f859bf11 && git checkout a997b267d297f4cef00f5d1ce38b1065f859bf11
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 6285203da7ec7e0587b6aab25ebfb28277ab454d baa3375ab08c377e5d9f590c0ae655080165066e && git checkout -B drift-repro 6285203da7ec7e0587b6aab25ebfb28277ab454d && git merge --no-ff baa3375ab08c377e5d9f590c0ae655080165066e

node scripts/docs-audit/affected-docs.mjs --json 6285203da7ec7e0587b6aab25ebfb28277ab454d

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 6285203da7ec7e0587b6aab25ebfb28277ab454d → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

domain:server#3 · os-elon-musk · session_016WV4czuTWNgKR22fKv7jia

Contract-review-claim: session_016WV4czuTWNgKR22fKv7jia · head baa3375ab08c377e5d9f590c0ae655080165066e · 2026-10-31T02:43Z

The lane seat runs the CONTRACT_REVIEW_TIER review this PR owes (Clause-②: yes, Metadata-protocol: added, packages/spec/src/** paths).

[objectstack-fleet]

domain:server#3 · os-elon-musk · session_016WV4czuTWNgKR22fKv7jia

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: baa3375ab08c377e5d9f590c0ae655080165066e
Local-runs: probe — the repo checkout has no node_modules, so no package test or typecheck ran; one probe ran instead: the PR's own tencentcloud-tc3-hmac-sha256.ts (extracted from the head, executed under Node 22 type stripping, no other PR code) was fed the two sign3 inputs and compared against the expectation strings parsed out of TencentCloud/tencentcloud-sdk-nodejs release 4.1.336 test/common/sign.test.ts, fetched independently. POST (application/json) and GET (application/x-www-form-urlencoded): both MATCH byte for byte; a wrong key gives a different signature. The author's typecheck ablation (TS2322 at the never check) is not re-run here; see ① for why the structure guarantees it.
Scope: packages/spec/src/shared/connector-auth.zod.ts, packages/spec/src/integration/connector-provider.ts, packages/spec/src/integration/connector.zod.ts, packages/services/service-automation/src/request-signing/{index,tencentcloud-tc3-hmac-sha256}.ts (+ tests), packages/spec/src/integration/connector-auth-signed.test.ts, connector-fetch-policy.test.ts, type-alias-convention.pin.test.ts, packages/connectors/connector-rest/src/connector-rest-plugin.test.ts, packages/spec/{api-surface,authorable-surface,declaration-map,export-origins,json-schema.manifest}/integration.json, packages/spec/variant-docs.json, content/docs/automation/connectors.mdx, content/docs/references/**, docs/audits/2026-07-unknown-key-strictness-ledger.counts/shared.md, .changeset/26710-signed-connector-auth-tencentcloud.md. Read, not reviewed: the merged S1 seam on main (connector-fetch-policy.ts, plugin.ts reconcile, connector-credential-source.ts, connector.zod.ts mcp refusal, scripts/adr-anchors/…request-signing__index.ts.json).

① Derived judgments

• Enum admits only what ships. ConnectorSigningSchemeSchema gains one member; the signed discriminated union gains one strictObject shape; the registry gains one case. Exhaustiveness is a two-part guarantee: the switch narrows auth (the union) to never, so a union shape without a signer is a TS2322 at compile time; and connector-auth-signed.test.ts:131 pins union members equal to the enum options, so an enum member without a shape fails the spec suite. Together no third member can land without its signer. Correct. The auth.scheme → auth change at the never check is equivalent in effect, not a weakening.
• Vectors. The two signatures, the placeholder key pair, timestamp, service, trace header and body are copied from the vendor suite named by SDK, release and file; none is regenerated from the signer (confirmed against the independently fetched vendor file). The multipart case is correctly left out: the S1 wrap refuses a non-text body. D2.3 permits the SDK suite here: the ADR text on main reads "Where it does not (a masked secret, an unreachable page), the vectors are taken from the vendor's official SDK test suite, and the test names that SDK and its version", and Q4 condition 3 records that Tencent masks its SecretKey. The PR body's claim is verified against the ADR, not taken from the PR.
• Signing algorithm vs vendor source. Canonical request (method, path, query as sent, content-type/host by hostname, content-type;host, hex SHA-256 of body), string to sign (TC3-HMAC-SHA256, timestamp, <date>/<service>/tc3_request, hashed canonical request), key derivation ("TC3"+SecretKey → date → service → tc3_request) and the UTC date of the timestamp all match the SDK's src/common/sign.ts at the cited release. Service = first host label is consistent with the vendor's <service>[.<region>].tencentcloudapi.com endpoint convention; the doc tells authors to point baseUrl at the product endpoint. Correct.
• ConnectorRequestSigner.scheme: string → ConnectorSigningScheme. Not a narrowing of any released surface: the interface entered main at b358e7995e (feat(spec): signed connector instance auth, with aliyun-acs3-hmac-sha256 signing every request (ADR-0143 D2.3, slice 1 of #26710) #28273), which is not an ancestor of tag @objectstack/spec@18.2.0 (27f38ada49, 2026-10-27), and the published @objectstack/spec@18.2.0 tarball contains no ConnectorRequestSigner. Both ship together in the next release under the two pending changesets. Correct; the test-double updates in connector-fetch-policy.test.ts are the only consequence.
• Publish door. SIGNED_GUIDANCE is shared, so the new shape refuses secret, privateKey, secretKey, accessKeySecret by name with the credentialRef prescription and refuses an authored signature; secretId is a strictObject alias, which is refused with a prescription pointing at keyId (not accepted and rewritten, so no lenient alias under PD Add comprehensive test suite for Zod schema validation #12). The unknown-scheme message is derived from ConnectorSigningSchemeSchema.options, not hard-coded. All pinned in connector-auth-signed.test.ts.
• Fail-closed paths are scheme-agnostic (entry.auth?.type === 'signed'): mcp refusal at auth.type (connector.zod.ts:1261), datasource borrow refusal (connector-credential-source.ts:130), and the requestSignerApplied acknowledgement (plugin.ts). Unchanged by S2 and cover the new member without edits; the new rest e2e test exercises the acknowledged path.
• Per attempt. The S1 wrap calls sign inside the per-attempt fetchImpl; the signer reads the clock on each sign, so X-TC-Timestamp is fresh per retry (TC3 has no nonce). The body hashed is init.body, the string the same call sends. The signer's content-type default is added to the sent headers by the wrap, so the signed header equals the sent header; a request that names its type is not retyped (CONTROL pinned).
• Spec logic-free and browser-safe. Spec changes are a z.enum member, a strictObject, a union member, re-exports and a type import; node:crypto stays in service-automation. Widening only on every published surface.
• Generated artefacts. The same regenerated families S1 touched (five integration.json surfaces, references docs, strictness ledger 24→25, pin count 804→805, variant-docs.json). The variant-docs key uses the repo's a|b multi-member convention. The S1 ADR anchor on request-signing/index.ts is invariant-prose, unchanged, and its invariant still holds.
• Author: PR user.login is objectstack-fleet[bot]; no login note owed.

② Semver level

• minor on @objectstack/spec and @objectstack/service-automation: a new enum member, a new union shape, a new schema export and type, a new signer. Matches Clause-②: yes (widening) in the PR body and the changeset. connector-rest changes only a test: no changeset owed. Metadata-protocol: added is right for a new authorable variant. The ADR-0087 marker not-required (no-migration-prescription) is a recognised disposition (check-adr-0087-registration.mjs), the body carries no migration prescription, and nothing an author wrote before is refused or re-shaped. Consistent.

③ Boundary flags

• Dev open_questions: none. out_of_scope_findings: skills text for the signed kind rides Teach oauth2 and app-credential connector auth once S1 serves them: skills recipe bullet, its eval, and lint steer strings still say the union has no oauth2 #28226 (a skills/** edit would make this slice Tier H). Accepted; this slice carries the author-facing text in content/docs/automation/connectors.mdx.
• Rule level: the scheme signs content-type and host and the body as sent; it refuses an inline key spelling, an authored signature, an unknown scheme, and signed on provider: 'mcp'; the key is a credentialRef resolved on the server and bound to the signer, and only the signer reaches a provider.
• Governance: the file list touches no GOVERNED_SURFACES row (docs/audits/** is not docs/adr/**). Not governed.
• CI at review time: 23 success, 9 skipped, 15 in progress on the head. This record judges the contract; the landing gate's all-green condition is checked separately by the owning seat.
• Note, not a must-fix: connectors.mdx says "A request without a body is sent with Content-Type: application/x-www-form-urlencoded"; the signer's rule is "a request without a content type". The two coincide on the authored path because rest and openapi set application/json on any body without a type. The signer docblock and the changeset state the precise rule.

④ Design judgment

• The slice is exactly the ADR's growth model: one member, its signer, its vectors, one closed shape, no seam change. The scheme-specific non-secret parameter set is keyId only, which is right for TC3 (service and date are derived from the endpoint and the clock, so nothing about canonicalisation is authored).
• Typing scheme by the enum closes the feat(spec): signed connector instance auth, with aliyun-acs3-hmac-sha256 signing every request (ADR-0143 D2.3, slice 1 of #26710) #28273 nit at the one moment it is free, before the interface is released. Good timing.
• Vendor fidelity: the signer leaves X-TC-Action / -Version / -Region unsigned and defaults the content type as the vendor SDK does, so an instance behaves as the vendor's own client would. The e2e test proves the whole host→provider→wrap→signer chain for the new member without touching S1 code.
• No findings outside the claimed surface.

Implemented-by: claude/project-thread-tpb1yk
Reviewed-by: session_016WV4czuTWNgKR22fKv7jia (seat subagent)

VERDICT: PASS

[objectstack-fleet]

domain:server#3 · os-elon-musk · session_016WV4czuTWNgKR22fKv7jia

Seat ACCEPT · PR #28279 · head baa3375ab08c377e5d9f590c0ae655080165066e · 2026-10-31T03:07Z

维护者速读

• 改了什么： signed 鉴权新增第二个方案 tencentcloud-tc3-hmac-sha256（腾讯云 TC3），带签名器和官方测试向量；ConnectorRequestSigner.scheme 改为按方案列表定型（connectors: request-signing auth kind for the openapi and rest providers (RSA2 / HMAC canonical-request signers: Alipay, WeChat Pay, Aliyun, Tencent Cloud, e签宝) — the vendor-auth half that #26702 does not cover #26710 第 2 片，ADR-0143 D2.3 / Q4 A）。
• 为什么改： 腾讯云 API 用 TC3 逐请求签名；没有这个方案，腾讯云接口无法用元数据接入。
• 风险与回滚： 纯新增（Clause-②: yes (widening)，Metadata-protocol: added）；阿里云方案和静态鉴权不变。密钥仍只能是 credentialRef，失败一律关闭。scheme 定型不是收窄：该接口尚未发布。回滚即还原本 PR。
• 先看： service-automation/src/request-signing/tencentcloud-tc3-hmac-sha256.ts。
• 两分钟验证： 跑它的测试（腾讯官方 SDK 4.1.336 两个 sign3 向量逐字节复现）。
• 需要你做的： 无（Tier S，未命中受管面；契约复核 PASS 6538077823，按本期落地授权由席位落地）。

席位核对

• Shape: draft → main, Refs #26710 (slice 2 of 3; S3 alipay-v3 with response verification carries Fixes and waits on a vector ruling). 21 files (+537/−35). check-governed-merges --pr 28279: NOT governed (0 of 21 paths hit the register).
• Premise: S1 (feat(spec): signed connector instance auth, with aliyun-acs3-hmac-sha256 signing every request (ADR-0143 D2.3, slice 1 of #26710) #28273) merged; the branch was restarted from main b358e7995, not stacked on the merged history.
• File surface: within the claim as amended (6535175098). One registry change outside the order's letter, reported by the dev: the exhaustive default now checks auth against never (the old auth.scheme check stops compiling with two members); the review found it equivalent, not a weakening.
• Declarations: Clause-②: yes (widening), Metadata-protocol: added, ADR-0087 not-required marker; changeset minor. Generated artefacts regenerated by the repo's tooling.
• Contract review: CONTRACT_REVIEW_TIER, PASS at this head, 6538077823. D2.3's SDK-test-suite branch verified against the ADR text on main (the vendor's own example masks the secret). The scheme typing is no released narrowing: the seam is in no published spec version. One non-blocking docs wording note rides S3's doc touch.
• Security wording: security card; the PR body, changeset and records stay at rule level; the vectors are cited by vendor source and version.
• Local (card thread): dispatch-gates 105/105, 0 NOT-MEASURED; pnpm lint 0; ablations red. Report 6537941569.
• Gate check-runs on this head: 50 total, 41 success, 9 skipped by the path filter, 0 failed. mergeable_state: clean.
• Landing: Tier S, under the maintainer's landing grant for this term (2026-10-29T22:05Z, seat thread). Ready + auto-merge through the relay. The card stays open for S3.

ACCEPT