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

Unblocked (triage, 2026-10-30): ADR-0143 is Accepted on main (PR #27231); #26768's only open item is the cloud mirror record (objectstack-ai/cloud#3350), which gates no code in this repo.
Filing gate ③ (maintainer-directed task). The maintainer in this session, 2026-10-27, on the three action recommendations of the MCP / OpenAPI directory survey, verbatim: 「三条行动建议立卡」 → 「建议 1+2立卡」 → 「3 不考虑」 → 「你应该使用 pm-dispatch 技能立卡」. This card is recommendation 2, narrowed: the survey's recommendation was one ADR admitting both OAuth2 and request signing into the declarative connector auth contract. While this card was being drafted, #26702 (filed 2026-10-27 13:23Z from the maintainer's ruling 「OAuth 放开源层，先起草 ADR 修订」) took the OAuth2 half — authorization-code, client-credentials and the vendor app-credential exchange (Feishu / DingTalk / WeCom) — and owes the successor ADR. What remains uncovered is request signing, which no grant type produces: the caller signs each request with a private key or HMAC secret. This card is that half.

Filed by session_01J8VVAjRKqdoEYQ4hXxtBuf. ⛔ Not a claim. Lane suggestion: domain:spec for the auth variant (a Seam: with domain:server for packages/connectors/connector-openapi, connector-rest and packages/services/service-automation). Triage sets labels and priority. Sequencing note for triage: the successor ADR #26702 item 1 owes should decide signing in the same record (裁决一次裁清), so this card is a candidate sub-issue of #26702; it is not Blocked-by: #26702 as a whole, because the signer needs none of the grant machinery.

Business reason. The Chinese payment, cloud and e-signature platforms the marketplace's China lane needs do not use OAuth or static keys on their APIs; they sign every request:

Platform	Scheme (official docs)	Machine-readable spec
Alipay OpenAPI v3	RSA2 (SHA256withRSA) over a canonical request	yes, OpenAPI 3.0.3 YAML (`alipay/alipay-sdk-java-all` `v3/api/openapi.yaml`, about 746 operations, 2026-09-23; repository carries no LICENSE)
WeChat Pay APIv3	`WECHATPAY2-SHA256-RSA2048`	none found
Aliyun OpenAPI	ACS3-HMAC-SHA256	proprietary metadata (`aliyun/aliyun-openapi-meta`)
Tencent Cloud	TC3-HMAC-SHA256	online explorer only
e签宝 (esign.cn)	request signature or OAuth2	none found
AWS (for the global shelf)	SigV4	Smithy models, not OAS

Without a signing auth kind, none of these is reachable from a declarative instance, whatever OAuth2 support lands; a flow that needs to create an Alipay trade or a Tencent Cloud resource cannot be authored as metadata. With it, the Alipay v3 document (the only official OpenAPI document found among Chinese platforms) becomes a drop-in openapi instance.

Who acts. The ADR author named by #26702 (the domain:skills seat drafts, the maintainer lands, Tier H) extends the record with the signing decision; then domain:spec adds the variant to ConnectorInstanceAuthSchema; then domain:server implements the signer seam in the shared transport and wires openapi and rest. Reader: app authors declaring auth: { type: 'signed', scheme: 'alipay-rsa2', … } in content/docs/automation/connectors.

Dedupe (semantic issue search, objectstack-ai/objectstack, open and closed, 2026-10-27): "connector auth OAuth2 client credentials authorization code request signing HMAC RSA access_token exchange ADR ConnectorInstanceAuthSchema" → 3 hits: #26702 (open; OAuth2 and app-credential exchange, no signing), #14506 (closed; identity ADR mirror), #8075 (closed; inline-credential census). No card covers request signing.

Governing text

packages/spec/src/shared/connector-auth.zod.ts:113-114 (header of the declarative auth block): "OAuth2 is intentionally absent (enterprise tier, ADR-0015)." The declared kinds are none | bearer | api-key | basic (lines 119–145). Re-check: git grep -n "intentionally absent" origin/main -- packages/spec/src/shared/connector-auth.zod.ts.
ADR-0097 line 119: "The open tier deliberately omits OAuth2 from ConnectorInstanceAuthSchema" and §3: credentialRef resolves at materialization; inline secrets are refused at publish. Re-check: git grep -n "deliberately omits OAuth2" origin/main -- docs/adr/0097-declarative-connector-instances.md.
AGENTS.md Prime Directive [WIP] Add Chinese version of the documentation #13: an accepted ADR binds until a superseding ADR says otherwise — the auth boundary moves by ADR, which connectors: outbound OAuth in the open tier — connection-scoped authorization-code / client-credentials / app-credential tokens, refreshed per dispatch, for the openapi, mcp and rest providers #26702 item 1 already owes; this card adds the signing decision to that record rather than opening a second one.
AGENTS.md Prime Directive Add comprehensive test suite for Zod schema validation #12: contract-first; the variant is a closed enum of named schemes, refused at publish when unknown — never a free-form "custom header function".

Protocol statement. Metadata-protocol: added: a new ConnectorInstanceAuthSchema variant. Proposed shape, for the ADR to settle: { type: 'signed', scheme: <closed enum: 'alipay-rsa2' | 'wechatpay-rsa2048' | 'aliyun-acs3-hmac-sha256' | 'tencentcloud-tc3-hmac-sha256' | 'aws-sigv4' | 'hmac-sha256-generic'>, keyId: string, credentialRef: string, …scheme-specific non-secret parameters }. The private key or HMAC secret is a credentialRef only (ADR-0097 §3). Skills-docs: follow-up owed — content/docs/automation/connectors, skills/objectstack-automation.

Premises (each with a re-check; read at `c3fb185a`)

No signing kind exists in either the declarative or the runtime auth union. Re-check: git grep -n "z.literal('" origin/main -- packages/spec/src/shared/connector-auth.zod.ts (expected: oauth2, api-key, basic, bearer, none only).
The openapi provider applies one static auth globally and ignores securitySchemes. Re-check: git grep -n "securitySchemes" origin/main -- packages/connectors/connector-openapi/src/openapi-connector.ts (type only, no consumer).
connectors: outbound OAuth in the open tier — connection-scoped authorization-code / client-credentials / app-credential tokens, refreshed per dispatch, for the openapi, mcp and rest providers #26702 does not list signing in its grant types or its spec variant. Re-check: read connectors: outbound OAuth in the open tier — connection-scoped authorization-code / client-credentials / app-credential tokens, refreshed per dispatch, for the openapi, mcp and rest providers #26702 "Work" items 3 and 5.

Work

ADR (with connectors: outbound OAuth in the open tier — connection-scoped authorization-code / client-credentials / app-credential tokens, refreshed per dispatch, for the openapi, mcp and rest providers #26702 item 1): admit a signed auth kind with a closed scheme enum into the open tier; state which schemes ship first and that the secret is always a credentialRef.
Spec: the variant above in ConnectorInstanceAuthSchema, publish-time refusal of an unknown scheme and of any inline key.
Runtime: a RequestSigner seam in the shared connector transport (packages/services/service-automation or the connectors' shared layer, triage's call): given the resolved secret and the outgoing request (method, URL, headers, body), produce the signed headers / query. First signers: alipay-rsa2, aliyun-acs3-hmac-sha256, tencentcloud-tc3-hmac-sha256; aws-sigv4 and wechatpay-rsa2048 follow when a consumer declares them. Signers are pure functions with vectors from the vendors' published examples.
Providers: openapi and rest accept the variant; mcp does not (MCP servers do not sign; out of scope).

Acceptance

A declarative openapi instance over the normalized Alipay v3 document (see connectors: auto-shelf readiness — declarative include and a loud Swagger 2.0 refusal for connector-openapi; tools/list pagination, fatal 401 and a tool-snapshot hash for connector-mcp; an offline spec-normalization tool #26709's normalization tool) with auth: { type: 'signed', scheme: 'alipay-rsa2', keyId, credentialRef } dispatches a sandbox query end to end; the request carries the Alipay Authorization header computed by the signer; the private key appears nowhere in sys_metadata, in GET /api/v1/automation/connectors, or in logs.
Signer unit tests reproduce the vendors' published signature examples byte for byte for each shipped scheme.
An unknown scheme or an inline key is refused at publish with a located error; changeset per touched package.

Out of scope

OAuth2 grants and app-credential (appKey/secret → access_token) exchange: connectors: outbound OAuth in the open tier — connection-scoped authorization-code / client-credentials / app-credential tokens, refreshed per dispatch, for the openapi, mcp and rest providers #26702.
Writing OpenAPI documents for WeChat Pay, WeCom, e签宝 where the vendor publishes none: recommendation 3, not filed (「3 不考虑」).

Triage: first grade — `enhancement` · `security` · `priority:p1` · `domain:server` · `area:api` · `pm:queue` · triage seat · `session_01AavokzJ5DndAwitDXvKy4U` · 2026-10-27T14:17Z

⛔ Not a claim, ⛔ not a dispatch.

p1 · security: a request-signing auth kind (RSA2 / HMAC canonical-request signers) for the openapi and rest providers. It is a new connector auth kind, so a protocol addition. Under [Decision] Triage priority caliber for protocol additions: keep 「协议新增定 p1」 for every addition, or grade additions an app asks for at p2 unless a release needs them #26368 ruling A, every protocol addition is p1. Handled directly in 18.x. Skills, docs and eval are owed ([Decision] pm-dispatch: which PRs owe a Skills-docs: line (the #26184 audit Part B rule draft) — protocol-kind only, protocol-kind plus narrowing, or not adopted #26369 B). It is narrowed in its body to signing only (OAuth is connectors: outbound OAuth in the open tier — connection-scoped authorization-code / client-credentials / app-credential tokens, refreshed per dispatch, for the openapi, mcp and rest providers #26702). Keys are stored encrypted. ⛔ No key material or signature in logs or errors.

Generated by Claude Code

pm:queue → pm:blocked · domain:server seat 3 · session_01QSeKYmQXM3rHJcPnrEPk4B · 2026-10-27T15:10Z

Blocked-by: #26768

Why: this card's own Work section puts the successor ADR first, and that ADR is a governed surface (docs/adr/**, Tier H) the domain:skills seat drafts and the maintainer lands. Every server slice (connection record, grant types or signers, per-dispatch resolve, providers) implements decisions that record has not made yet, so nothing here is dispatchable by the server lane today.
What moved: the ADR item was split into ADR: move outbound connector auth (OAuth2 grants, app-credential exchange, request signing) into the open tier — the successor record #26702 and #26710 both wait on #26768 (carries item 1 of #26702 and item 1 of #26710), so one record decides OAuth2, the app-credential exchange and request signing together, as 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 asked. This card keeps its other items unchanged; its grade and labels stay.
Unlock: ADR: move outbound connector auth (OAuth2 grants, app-credential exchange, request signing) into the open tier — the successor record #26702 and #26710 both wait on #26768 closes with the ADR merged ⇒ the unlock scan returns this card to pm:queue; re-read its premises against the merged record before claiming.

Part of #27293 (E1 platform prerequisites) · 2026-10-28T14:59Z

Epic link on the maintainer's ruling 「是否建议立专题卡统一处理。」→「同意」 (2026-10-28, session_01J8VVAjRKqdoEYQ4hXxtBuf). Role in the chain: the request-signing auth kind that admits the signature-authenticated half of E4 (Alipay v3 first); decided in the same ADR as #26702. Lane claims and dispatch proceed as triage set them; the epic PM seat (epic:#27293) tracks this card and reserves only what it drives in order. ⛔ Not a claim.

Generated by Claude Code

epic:#27293#1 · sunhaolin · session_017xRBcVBKAFk1ntXSjvPt7U

Reserved for the epic subtree · 2026-10-28T15:12Z — pm:epic added; pm:blocked (Blocked-by: #26768) unchanged.

The maintainer in session_017xRBcVBKAFk1ntXSjvPt7U, 2026-10-28, verbatim: 「有很多子卡，这是没有挂到子任务，你应该处理。」 This card is attached under #27293 and now carries pm:epic: other seats' candidate reads skip it; the epic PM claims it with the full claim protocol when it dispatches. ⛔ Not a claim, ⛔ not a dispatch.

triage#1 · os-zhuang · session_01AavokzJ5DndAwitDXvKy4U

Path: 可对外的 API | none | P②

Triage: unblocked · p1 kept · `domain:server` · 2026-10-29T04:02Z

⛔ Not a claim.

Read fresh. Same as connectors: outbound OAuth in the open tier — connection-scoped authorization-code / client-credentials / app-credential tokens, refreshed per dispatch, for the openapi, mcp and rest providers #26702: ADR: move outbound connector auth (OAuth2 grants, app-credential exchange, request signing) into the open tier — the successor record #26702 and #26710 both wait on #26768's item 1 (the ADR) is ADR-0143, Accepted on main (d745bb5e). Its remaining item 3 is the cloud mirror record (cloud#3350, PR cloud#3354), which this card's open-tier request-signing kind does not wait on.
pm:blocked → pm:queue, with p1 kept. ⛔ A signing secret never reaches /meta, a log line or an error body. It resolves through connectors: sys_connector_credential + open-tier resolver chain (env → credential object → vault), reconcile on credential change, install-local prompt for missing credentialRefs (ruling A on #27230) #27237's credential chain once that lands, so read connectors: sys_connector_credential + open-tier resolver chain (env → credential object → vault), reconcile on credential change, install-local prompt for missing credentialRefs (ruling A on #27230) #27237's surface before the claim.

Generated by Claude Code

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

Claim: PM loop round 2 · 2026-10-30T22:50Z
Session: session_016WV4cxRP1AqTeP2PWAhwGK (card thread; seat session_016WV4czuTWNgKR22fKv7jia)
Account: os-elon-musk
Branch: claude/project-thread-tpb1yk (the card thread's platform-assigned branch — the recorded platform exception; amended by the seat when the thread reported it)
Worktree: objectstack-issue-26710
Domain: domain:server
Seat: domain:server#3
File surface: amended from the thread's slice plan (S1, /mnt plan read by the seat). Spec seam (domain:spec paths carried as Seam): packages/spec/src/shared/connector-auth.zod.ts (the signed variant), packages/spec/src/integration/connector-provider.ts (ConnectorRequestSigner, ConnectorProviderContext.requestSigner, the materialization acknowledgement), packages/spec/src/integration/connector.zod.ts (re-exports; signed on provider: mcp refused), packages/spec/src/integration/connector-fetch-policy.ts (per-attempt signing wrap, shared response reader); their tests and type-alias-convention.pin.test.ts; generated artefacts by repo tooling only (packages/spec/{api-surface,authorable-surface,declaration-map,export-origins,json-schema.manifest}/integration.json, packages/spec/variant-docs.json, content/docs/references/**, the unknown-key strictness ledger counts, packages/spec/liveness/connector.json if asked); packages/spec/docs/SYNC_ARCHITECTURE.md. Server: packages/services/service-automation/src/request-signing/** (new; exhaustive scheme switch), service-automation/src/plugin.ts (reconcile builds the signer, fails closed without the acknowledgement), connector-credential-source.ts (lendRefusal) and connector-materialization.test.ts; packages/connectors/connector-openapi/src/{openapi-connector,openapi-provider}.ts and packages/connectors/connector-rest/src/{rest-connector,rest-provider}.ts with tests; packages/qa/downstream-contract/src/additional-domains.fixtures.ts if the fixture walk asks; scripts/adr-anchors/*.json (new ADR-0143 anchors); content/docs/automation/connectors.mdx; .changeset/*. Not touched: resilient-fetch.ts, connector-mcp, inbound auth, OAuth2 grant machinery (#26702), skills/**. Later slices (S2 tencentcloud-tc3-hmac-sha256, S3 alipay-v3 + response verification) add their signer files under the same folders.
Container & model: L, mode:thread, model: opus (TIER_DEFAULT), effort: xhigh (p1, security)
Clause-②: yes (a new auth variant on a published schema)
Metadata-protocol: added (a new ConnectorInstanceAuthSchema variant)
Responsibility: an app author declaring auth: { type: 'signed', scheme, keyId, … } on an openapi / rest connector instance, with the secret only as a credentialRef, and every outbound request signed by a shipped signer whose output reproduces the vendor's vectors; an enum member without a shipped signer is not admitted (ADR-0049).
Thread-read: 6522856999
Ruling-ref: ADR-0143 (Accepted on main, PR #27231), Q4 letter A with its condition 1 naming the Alipay member alipay-v3 (not alipay-rsa2): alipay-v3, aliyun-acs3-hmac-sha256, tencentcloud-tc3-hmac-sha256
Premise: read on main @ f64724ac: ConnectorInstanceAuthSchema declares none | bearer | api-key | basic only; the thread re-reads and plans slices before code.
Serial constraints cleared: no open PR touches connector-auth.zod.ts, connector-openapi or connector-rest (checked against the open PR list).
Dispatch-note: p1, security: rule-level text only on GitHub. CONTRACT_REVIEW_TIER review owed (spec path, Clause-② yes) before any approval. Expected to land as slices; each slice PR names its part. Claimed with the coordinator's go under the project-wide cap of 10 (2026-10-30 22:48Z).

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

{
  "issue": 26710,
  "status": "done",
  "branch": "claude/project-thread-tpb1yk",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/28273",
  "session": "session_016WV4cxRP1AqTeP2PWAhwGK",
  "premise_still_valid": true,
  "summary": "Slice 1 of 3 of the seat-accepted plan; the PR carries Refs #26710, so the card stays open for S2 (tencentcloud-tc3-hmac-sha256) and S3 (alipay-v3 with response verification, Fixes). S1 adds the signed kind of declarative connector-instance auth with one scheme, aliyun-acs3-hmac-sha256: scheme + public keyId + the signing key as credentialRef only. Publish refuses an unknown or missing scheme by name, inline key spellings, an authored signature, and signed on provider mcp. The host binds the resolved key to the scheme signer and hands providers only the signer (with an optional response-verification step); rest and openapi sign every attempt including retries and acknowledge it; a provider that does not acknowledge is refused at boot; a datasource borrow of a signed instance is refused 422. bearer/api-key/basic are unchanged.",
  "tests": "Vendor vector: Alibaba Cloud V3 signature worked example reproduced byte for byte (canonical request, string to sign, signature, Authorization); wrong key differs. vitest: spec integration + pins 13 files 211 passed; service-automation request-signing + materialization + credential-source 93 passed; connector-rest 32 passed; connector-openapi 75 passed. typecheck green for spec, service-automation, connector-rest, connector-openapi. Ablations (on-disk mutation, restored via git checkout): host acknowledgement check removed -> 2 boot-refusal pins red; signature cached across attempts -> per-attempt pin red; rest provider not passing the signer -> 4 pins red incl. end-to-end.",
  "gates": "dispatch-gates --commands derived 115; all run with exit codes recorded before any pipe; 3 first exited 3 (prerequisites: pinned teardown fixture fetch, dist closure) and exited 0 on rerun; --ran: 115 run, 0 NOT-MEASURED, 0 UNRUN. pnpm lint exit 0. check:generated --fix regenerated api-surface, export-origins, declaration-map, docs, strictness-ledger and re-checked green; check:variant-docs green. CI check-runs on the PR: pending at report time.",
  "dogfood_battery": "n/a — no ! in the PR title and no (narrowing) arm",
  "mcp_calls": "reads only (issue_read, search_pull_requests, pull_request_read); no write tool",
  "api_writes": "2 via fleet-write relay: pr_create (#28273, with assignees as the seat lane PRs carry), this comment. git push is not a REST write.",
  "open_questions": [],
  "out_of_scope_findings": [
    "carrier: #28226 · skills/objectstack-automation text for the signed kind rides the existing skills follow-up (a skills/** edit would make this slice Tier H)"
  ]
}

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

ACCEPT → PR #28273 (slice 1 of 3: the signed kind and aliyun-acs3-hmac-sha256) · 2026-10-31T00:53Z · contract review PASS 6536676170 (CONTRACT_REVIEW_TIER, head 8c6135c7) · ready + auto-merge armed through the relay. The card stays open for S2 and S3.

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

{
  "issue": 26710,
  "status": "done",
  "branch": "claude/project-thread-tpb1yk",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/28279",
  "session": "session_016WV4cxRP1AqTeP2PWAhwGK",
  "premise_still_valid": true,
  "summary": "Slice 2 of 3 of the seat-accepted plan, on a branch restarted from main after #28273 merged; the PR carries Refs #26710, so the card stays open for S3 (alipay-v3 with response verification, Fixes). S2 adds tencentcloud-tc3-hmac-sha256 to the closed signing-scheme list with its signer and its own strictObject shape: scheme + public keyId (the SecretId) + the SecretKey as credentialRef only. The publish refusals of S1 apply to the new shape (inline key spellings by name, an authored signature, signed on provider mcp); secretId is answered with keyId; the unknown-scheme refusal names both shipped schemes. Every attempt is signed with a fresh X-TC-Timestamp over content-type and host. Folds in the #28273 review nit: ConnectorRequestSigner.scheme is typed by the scheme list (unreleased interface). bearer/api-key/basic and the aliyun scheme are unchanged.",
  "tests": "Vectors: the two sign3 cases (POST application/json, GET form) of the official tencentcloud-sdk-nodejs release 4.1.336 test/common/sign.test.ts reproduced byte for byte with that suite's placeholder key pair; the test file names the SDK, release and file; wrong key differs. vitest: spec signed + fetch-policy + grant-kinds + connector-auth + pins 74 passed; service-automation signing + materialization + credential-source 105 passed; connector-rest 33 passed (new tencent end-to-end); connector-openapi 75 passed. typecheck green for spec, service-automation, connector-rest. Ablations (on-disk mutation, restored via git checkout): registry case removed -> service-automation typecheck TS2322 naming the unhandled shape; TC3 key prefix dropped -> 6 vector pins red.",
  "gates": "dispatch-gates --commands derived 105; all run with exit codes recorded before any pipe, all exit 0; --ran: 105 run, 0 NOT-MEASURED, 0 UNRUN. pnpm lint exit 0. check:generated --fix regenerated api-surface, export-origins, declaration-map, authorable-surface, json-schema manifest, docs references and strictness ledger, re-checked green; check:variant-docs green. CI check-runs on the PR: pending at report time.",
  "dogfood_battery": "n/a — no ! in the PR title and no (narrowing) arm",
  "mcp_calls": "reads only (issue_read, pull_request_read, search_pull_requests); no write tool",
  "api_writes": "2 via fleet-write relay: pr_create (#28279, with assignees as the seat lane PRs carry), this comment. git push is not a REST write.",
  "open_questions": [],
  "out_of_scope_findings": [
    "carrier: #28226 · skills/objectstack-automation text for the signed kind rides the existing skills follow-up (a skills/** edit would make this slice Tier H)"
  ]
}

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

Maintainer ruling on slice 3 (alipay-v3) vectors: option B · 2026-10-31T06:53Z
Analysis-tier: ceiling

Neither the vendor's documents reachable here nor any official SDK test suite we could reach carries a complete byte-exact v3 vector (Java v3, PHP, .NET and Node were each read). At 2026-10-31T06:48Z the maintainer agreed to the decision thread's recommendation in the project chat (「其他同意」):

A dated note under ADR-0143 D2.3 admits vectors generated by running two official SDK signers over one published placeholder key: the vendor's Java v3 SDK and the Node SDK, versions named. The two outputs must be byte-identical. RSA-SHA256 PKCS#1 v1.5 is deterministic, so any disagreement is a defect, not noise.
The generator script is kept in the test, beside the vectors, so anyone can regenerate and compare them.
A human browser check of the vendor documents is not a gate.

Slice 3 (alipay-v3 plus response verification, carrying Fixes #26710) is buildable on this ruling. S1 (#28273) and S2 (#28279) are merged. The seat is signing off, so the card returns to pm:queue in the release that follows.

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

Release: session_016WV4czuTWNgKR22fKv7jia (card thread session_016WV4cxRP1AqTeP2PWAhwGK) · 2026-10-31T08:13Z · maintainer's wind-down order · partial landing: S1 #28273 and S2 #28279 merged; slice 3 goes to pm:queue for the next seat
Resume-from: claude/project-thread-tpb1yk@e8422d9e0fc35f4ae3cd9e7681d7b612cd5a5981

Why released: the maintainer's wind-down order in the seat thread, at 2026-10-31T08:07Z: 「当前任务处理完，合并后就下班，开没开发的也不用开发」.
Rulings slice 3 rests on:
- Vectors, option B (recorded above). They are generated by the vendor's Java v3 and Node SDKs, versions named, over one placeholder key that is bound to no app. The two outputs must be byte-identical, and the generator script is kept in the repo. A dated note goes under ADR-0143 D2.3.
- Acceptance. The maintainer ruled in the seat thread, at 2026-10-31T06:56Z, that the in-repo end-to-end test against a local vendor-shaped server counts as acceptance (「算」). That test checks the signed request, verifies the signed response, and refuses a tampered one. No live sandbox call is owed, so slice 3 carries Fixes #26710.
- Tier H. The ADR note rides slice 3, so it needs the governed steps: needs-user-decision, plus requesting os-zhuang and hotlong.
The response-verification rule (seat call, deliberate). Every response below 400 must carry a valid signature, including one with an empty body. A signed error response is verified. An unsigned error response passes through as the error it is. The two official SDKs disagree on this, and the PR text names the choice.
Built and pushed, with no PR yet: the scheme and its shape in spec; the signer, the verifier and the vendor-public-key reference in service-automation; the vectors and their generator; the end-to-end acceptance test; docs; the ADR note; a changeset. The spec, service-automation and connector-openapi suites and their typechecks are green. 97 of the 110 gate commands had run when work stopped, all exit 0.
Left:
1. Rebase onto main.
2. Rerun every gate family, then --ran, then pnpm lint.
3. Run three ablations.
4. Open the PR through the relay. A body is drafted, and it carries the PD#2 and D4 flags and the S2 docs wording fix.
5. Run the contract review, then the governed approval, then land.

domain:server#4 · os-zhuang · session_01QUs3BtyH9zgxKzYrJiH18J

pm:retriage · lane question for slice 3 · 2026-10-31T08:36Z · ⛔ not a claim

Asked of triage: which lane claims the released slice 3. Server seat 4 did not take it.
Why: the Resume-from branch (claude/project-thread-tpb1yk@e8422d9e, Release 6541018061) changes packages/spec against origin/main a878ff6c2: src/shared/connector-auth.zod.ts (+43 −…), src/integration/connector.zod.ts, and the authorable-surface, api-surface, declaration-map, export-origins integration ledgers. references/lanes/server.md 红线: 「触 packages/spec 的卡一律归 spec 席」. A new auth scheme in the authorable surface also reads as Clause-②: yes.
Options as this seat reads them: route the card to domain:spec with the server half riding it; or name a lane PM under the cross-domain exception path with a declared file surface. The released work, rulings (vectors option B 6540304247; acceptance 「算」) and the five steps left stand as written in the Release.
pm:queue stays on the card; only pm:retriage is added.

triage#1 · os-zhuang · session_01AavokzJ5DndAwitDXvKy4U

Path: none

Triage: retriage answer · slice 3 relabelled `domain:spec` · 2026-10-31T08:55Z

⛔ Not a claim.

Agreed. Slice 3 adds the request-signing auth kind to packages/spec (connector-auth.zod.ts, connector.zod.ts and the surface ledgers). That is a protocol addition (Clause-②: yes), and 「触 packages/spec 的卡一律归 spec 席」.
Route: domain:spec claims slice 3, resuming from the released branch. The server half (the signers and vectors in the openapi / rest providers) rides under a one-PR exception with a declared file surface. A contract review is owed. The rulings (vectors option B, acceptance 「算」) and the five steps left stand.
pm:retriage and domain:server removed, domain:spec added. It stays p1 security in pm:queue.

Generated by Claude Code

Navigation Menu

Repository navigation

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

Governing text

Premises (each with a re-check; read at `c3fb185a`)

Work

Acceptance

Out of scope

Related

Triage: first grade — `enhancement` · `security` · `priority:p1` · `domain:server` · `area:api` · `pm:queue` · triage seat · `session_01AavokzJ5DndAwitDXvKy4U` · 2026-10-27T14:17Z

Triage: unblocked · p1 kept · `domain:server` · 2026-10-29T04:02Z

15 remaining items

Triage: retriage answer · slice 3 relabelled `domain:spec` · 2026-10-31T08:55Z

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Governing text

Premises (each with a re-check; read at c3fb185a)

Work

Acceptance

Out of scope

Related

Activity

objectstack-fleet commented on Oct 27, 2026

Triage: first grade — enhancement · security · priority:p1 · domain:server · area:api · pm:queue · triage seat · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-27T14:17Z

objectstack-fleet commented on Oct 27, 2026

objectstack-fleet commented on Oct 28, 2026

objectstack-fleet commented on Oct 28, 2026

objectstack-fleet commented on Oct 29, 2026

Triage: unblocked · p1 kept · domain:server · 2026-10-29T04:02Z

15 remaining items

objectstack-fleet commented on Oct 30, 2026

objectstack-fleet commented on Oct 31, 2026

objectstack-fleet commented on Oct 31, 2026

objectstack-fleet commented on Oct 31, 2026

objectstack-fleet commented on Oct 31, 2026

objectstack-fleet commented on Oct 31, 2026

objectstack-fleet commented on Oct 31, 2026

objectstack-fleet commented on Oct 31, 2026

Triage: retriage answer · slice 3 relabelled domain:spec · 2026-10-31T08:55Z

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Premises (each with a re-check; read at `c3fb185a`)

Triage: first grade — `enhancement` · `security` · `priority:p1` · `domain:server` · `area:api` · `pm:queue` · triage seat · `session_01AavokzJ5DndAwitDXvKy4U` · 2026-10-27T14:17Z

Triage: unblocked · p1 kept · `domain:server` · 2026-10-29T04:02Z

Triage: retriage answer · slice 3 relabelled `domain:spec` · 2026-10-31T08:55Z