ZeroClaw separates QQ reply support from proactive delivery and real bot readiness

ZeroClaw's September 12 QQ work exposes a product-support distinction that channel lists often hide. The runtime could answer through a live channel instance, yet one-off sends and scheduled announcements using a configured alias failed before network I/O. An open proposal adds that dispatcher path. Separately, a merged health-check change tests the bot's identity endpoint after obtaining a token, rather than declaring the channel healthy merely because credentials can mint one. These are different availability states and different proofs. Neither source reports a live QQ delivery test with actual bot credentials.

The facts

- The proactive-delivery proposal says dotted qq aliases previously reached an unsupported-channel error outside the live reply registry. - It builds the proposed one-off and announcement route from the canonical per-alias configuration, peer resolver and channel proxy. - The existing live reply path remains preferred and keeps the triggering message ID; bare qq still resolves only a default alias. - The separate health change merged September 12 and calls users/@me with the same QQBot authorization scheme used by message paths. - A cached live token can be reused, and readiness errors distinguish token minting from the subsequent identity probe. - The delivery proposal discloses that a disabled but configured alias can still be targeted, while the health probe cannot validate a recipient before a send.

Why it matters

For an operator deciding whether to move a daily report onto QQ, supported-channel status is too coarse. Inbound conversation, proactive delivery, accepted bot identity and a valid recipient are separate capabilities. This source cluster turns those seams into visible product constraints rather than implying that one green diagnostic certifies them all. The current channel documentation helps ground the sender and target vocabulary, while the open delivery proposal explains which capability is still being added.

Current

Inspected on 2026-09-13. The ZeroClaw release baseline is v0.8.5 published 2026-09-05T07:31:19Z. The main source was open (not merged) when captured. Proposals, merged mainline changes and packaged releases are different availability states; the linked release baseline does not imply that open proposals have shipped.

Evidence

Primary evidence: zeroclaw-labs/zeroclaw PR #10799 (https://github.com/zeroclaw-labs/zeroclaw/pull/10799). Supporting context: zeroclaw-labs/zeroclaw PR #10798 (https://github.com/zeroclaw-labs/zeroclaw/pull/10798); ZeroClaw — current chat-platform documentation (https://raw.githubusercontent.com/zeroclaw-labs/zeroclaw/master/docs/book/src/channels/chat-others.md). Sources were read directly through public pages or GitHub API bodies. Contributor test results are attributed claims, not independently reproduced results.

Operator take

Before enabling unattended QQ work on a future build, verify an authorized one-off send and a scheduled occurrence against the actual intended recipient. Check whether disabling a configured alias is expected to suppress outbound jobs; the proposal identifies that as an existing gap, not a new guarantee. The authors added feature-specific test lanes because default builds do not execute QQ tests. Stub-server and dispatcher tests are useful, but neither substitutes for a controlled live-platform acceptance run.

Caveat

Health-probe mainline merge is confirmed; proactive delivery remains proposed. No live QQ bot send was verified by the authors or this publication. The source body's older unsupported-set wording sits beside its new dispatcher description, so the article does not claim every support marker is settled; recipient validity and disabled-alias behavior remain distinct limitations.