v9.9.0 release candidate — implementation complete, controlled WhatsApp acceptance pending

[the-code-learner]

Draft release-candidate integration of v9.9.0 onto the exact v9.8.1 main baseline.

Baseline and composed surface

• exact base main: d1f965baf4fd2aa1b29266c8d28e3079814bdd6c
• frozen candidate head at this update: 114408d2f0fa6d3f96735e7e64712218eec1ed10
• final composed MCP registry: 130 commands
• intentional v9.9 delta: 12 commands over the v9.8.1 118-command surface, including exactly 8 WhatsApp commands
• historical composition/registry tests are updated to validate the intentional 130-command target
• lazy initialization is preserved: importing/status inspection does not auto-pair or open a WhatsApp socket

WhatsApp clean-room implementation

The planned v9.9 Postmaster WhatsApp surface is implementation-complete:

• local QR pairing flow and encrypted auth persistence
• current WhatsApp Web companion WebSocket + Noise XX transport
• certificate-chain verification and current ClientPayload
• WABinary/current token table
• pair-device / pair-success handling
• Signal v3 X3DH + Double Ratchet direct multi-device sessions
• direct text send/receive with server ACK handling
• encrypted direct media upload/send/download
• canonical Postmaster Stored File handoff for outbound and inbound media
• participating group listing through current w:g2
• Signal SenderKey v3 group text send/receive
• group media send and inbound group media Stored File handoff
• remote receipt observation
• asymmetric receipt policy: local reads never emit a read receipt; explicit reply actions may
• local WebGUI QR rendering as SVG with no external QR service

Runtime status deliberately distinguishes implementation from acceptance:

• implementation_complete = true
• controlled_acceptance_required = true
• protocol_interop_verified = false
• signal_multidevice_verified = false
• controlled_account_interop_verified = false

Current live evidence without pairing an account

The dedicated GitHub Actions workflow is green and exercises the current public WhatsApp endpoint without using a personal/account identity:

• DNS/TCP/TLS/RFC6455 WebSocket reachability
• live Noise ServerHello decrypt
• live certificate-chain verification
• live ClientFinish/current registration payload
• authenticated encrypted post-handshake transport
• current WABinary decoding
• encrypted pair-device reception with QR refs kept private and never persisted/logged

These probes intentionally stop before pairing a real account and therefore do not promote the three acceptance flags.

Controlled-account release gate

A separate manual workflow now covers the complete release acceptance profile:
.github/workflows/whatsapp-v990-controlled-interop.yml

It requires a protected whatsapp-v990-controlled environment and verifies:

• authenticated reconnect
• pre-key maintenance
• direct text + direct media
• group listing
• SenderKey group text + group media
• remote receipt
• inbound direct echo
• inbound group SenderKey echo
• inbound group media decrypt/download + Stored File handoff
• no unintended local read receipt

Evidence contains only booleans/counts: no JIDs, QR refs, auth DB/key bytes, private keys, session secrets or media payloads.

No maintainer personal WhatsApp account is required or expected. The documented release procedure uses dedicated test identities only. See docs/whatsapp-v990-release-gate.md.

Validation at this head

• complete repository regression: 585/585 tests OK
• dedicated WhatsApp regression: 86/86 tests OK
• live WebSocket/Noise/ClientFinish/pair-device jobs: green
• composed MCP command count: 130
• complete MCP runtime import: green
• provider-neutral public-tree validation: green
• compact context-model provisioning: green
• mounted-volume-safe venv rebuild: green
• single-YAML Portainer bootstrap: green
• disabled update-check cached-source path: green

Deployment / dependency boundary

• postmaster-mcp.yml: byte-for-byte unchanged from main (blob f250cc5c33cae66ffe6cd8eea8c30cb49e8203a9)
• canonical Cloudflare/runtime deployment boundary is unchanged
• requirements.txt: one intentional v9.9 addition only: qrcode==8.2 for local SVG pairing QR rendering
• VERSION: remains 9.8.1
• no stable CHANGELOG bump yet
• stable-release.yml now has a v9.9.0 interlock that refuses tag/release creation unless all three WhatsApp acceptance flags are True
• no production activation, Portainer mutation, merge, tag or stable GitHub Release

Stable-release blocker

This PR must remain draft until a full controlled-account run produces reviewed evidence with:

• protocol_interop_observed=true
• signal_multidevice_observed=true
• group_sender_key_interop_observed=true
• media_interop_observed=true
• receipt_policy_observed=true
• controlled_account_interop_observed=true

Only after that evidence exists should the three source acceptance flags be promoted, the complete suite rerun, VERSION/CHANGELOG moved to 9.9.0, and merge/tag/stable release performed.

The current state is therefore: implementation-complete, CI-green release candidate; stable release intentionally blocked only by the unavailable dedicated WhatsApp test identities.