RESULT-CODEX-V2R1-PERSONAL-WEIXIN-UPSTREAM-PROTOCOL-EVIDENCE-20260716T105003UTC8

status: EVIDENCE_RECORDED
scope: official_upstream_protocol_evidence_only
baseline_commit: 62a4067cf7a462ebe7cf29524238bc5d0a70b813
verified_at: 2026-07-16T10:50:03+08:00
upstream:
  repository: Tencent/openclaw-weixin
  release: v2.4.6
  release_commit: cef0bfc390393f716903e16d50408118047f87e0
  npm_package: "@tencent-weixin/openclaw-weixin"
  npm_version: 2.4.6
B3: PARTIAL
B3_raw_fixture: NOT_AVAILABLE_IN_REVIEWED_OFFICIAL_SOURCES
B4: NO_OFFICIAL_EXACT_BINDING_CONTRACT
implementation_changed: false
main_changed: false
production_changed: false

Official primary sources

Release commit: https://github.com/Tencent/openclaw-weixin/commit/cef0bfc
Release patch with full commit identity: https://github.com/Tencent/openclaw-weixin/commit/cef0bfc.patch
Release tag: https://github.com/Tencent/openclaw-weixin/releases/tag/v2.4.6
Point-in-time tag/main comparison: https://github.com/Tencent/openclaw-weixin/compare/v2.4.6...main
Protocol types at the immutable release commit: https://raw.githubusercontent.com/Tencent/openclaw-weixin/cef0bfc/src/api/types.ts
API implementation at the immutable release commit: https://raw.githubusercontent.com/Tencent/openclaw-weixin/cef0bfc/src/api/api.ts
Outbound send implementation at the immutable release commit: https://raw.githubusercontent.com/Tencent/openclaw-weixin/cef0bfc/src/messaging/send.ts
Protocol README at the release tag: https://raw.githubusercontent.com/Tencent/openclaw-weixin/v2.4.6/README.md
Official npm package metadata page: https://www.npmjs.com/package/@tencent-weixin/openclaw-weixin?activeTab=versions

Version and provenance boundary

The GitHub release page binds v2.4.6 to commit cef0bfc; the official patch endpoint expands that identity to cef0bfc390393f716903e16d50408118047f87e0. At verification time, the official comparison page reported v2.4.6 and main as identical. main is mutable and the npm web page is dynamically published metadata, so protocol conclusions below are bound to the immutable release commit, not to future main or future dist-tag state.

The official npm page reported @tencent-weixin/openclaw-weixin version 2.4.6 as latest at verification time. This corroborates release provenance but does not add wire-level response fields beyond the immutable source.

B3 — PARTIAL

Official documentation and types establish the structural inbound contract:

getUpdates returns a msgs collection and a reusable get_updates_buf cursor.
WeixinMessage declares message_id, client_id, from_user_id, to_user_id, session_id, context_token, message type/state, and item content fields.
The implementation posts the cursor to ilink/bot/getupdates, parses the JSON response as GetUpdatesResp, and returns the parsed envelope.

This is sufficient to identify candidate wire fields and to design a strict parser. It is not sufficient for B3 acceptance because none of the reviewed official URLs provides an authenticated, redacted raw getUpdates response captured from the provider. No authoritative raw fixture was available in the reviewed source/document set, so real field presence, numeric/string encoding, authority ownership, credential wiring, and rotation/reload behavior remain unproven.

B3:
  status: PARTIAL
  official_schema: VERIFIED
  official_endpoint_semantics: VERIFIED
  provider_raw_capture: MISSING
  deployable_authority_map: NOT_PROVEN
  credential_contract: NOT_PROVEN

B4 — NO_OFFICIAL_EXACT_BINDING_CONTRACT

The immutable source has two distinct identifier surfaces but does not bind them:

WeixinMessage can carry both provider-side message_id and client-supplied client_id on inbound/update messages.
SendMessageReq carries the client-generated client_id.
SendMessageResp contains only ret and errmsg; it has no provider message_id and no echoed client_id field.
The API layer treats a zero/absent ret as success and returns no provider identifier.
The outbound helper generates a local client_id, sends it, then returns that same local value as messageId. This is a local alias after accepted send, not evidence of a provider-assigned message ID.

No reviewed official response schema, event example, source path, release note, or README semantics demonstrates an exact relation of the form request.client_id -> authoritative provider.message_id for the same send. Therefore an exact outbound quote binding cannot be asserted from official upstream evidence, and using the helper's returned messageId as a provider ID would be semantically incorrect.

B4:
  status: NO_OFFICIAL_EXACT_BINDING_CONTRACT
  request_client_id: PRESENT
  send_response_provider_message_id: ABSENT
  send_response_client_id_echo: ABSENT
  local_messageId_value: generated_client_id
  authoritative_provider_binding: NOT_PROVEN
  safe_policy: keep_outbound_quote_authority_disabled

Verification summary

official_source_fetch: PASS
release_commit_identity: PASS
release_tag_identity: PASS
tag_main_point_in_time_comparison: IDENTICAL
npm_version_metadata: PASS
implementation_tests: NOT_APPLICABLE_RESULT_ONLY
secrets_recorded: false
long_verbatim_quotes_recorded: false

Release impact

This result narrows the evidence boundary; it does not authorize B3/B4 implementation, release preflight, canary, tag creation, or production deployment. B3 still requires owner/vendor raw evidence and deployment contracts. B4 requires an owner/vendor exact binding contract or an owner-approved contract amendment that keeps outbound quote authority disabled.

5.6 KiB Raw Blame History