Skip to content

WeChat tracer: checked source file processing and original-DM file reply #903

Closed

Description

@DoodleBears

Parent

#902 — Personal WeChat capability alignment. IM coordination reference: #48.

What to build

The paired owner sends a file in WeChat; the bound PersonaBot can fetch and process that exact source attachment through existing tools, then return a file to the same authorized WeChat DM.

Scope: personal WeChat/iLink, explicitly authorized paired-owner DM. Enterprise WeChat/WeCom is excluded.

Acceptance criteria

  • Admit a file-only message and a message containing text plus a file as canonical Source Events with bounded attachment metadata. Show the original filename, supported media type, size when provided, and source identity in Inbox/source details.
  • Expose checked, source-scoped attachment reads through the existing Messaging attachment seam. Enforce byte limits during download as well as after decryption; reject oversized, malformed, unavailable or stale media without consuming unbounded resources.
  • Resolve media references and AES/CDN transport material only inside the qualified Provider. The model and Client receive safe attachment references, never private download authority.
  • Send a generated file using the acting Bot's current identity/Grant and original DM route. Preserve honest per-send receipts, cancellation and unknown outcomes; do not blindly repeat an uncertain external send.
  • Real E2E: send a small test archive/document with a unique payload, have the Bot read the payload and produce a result file, receive it in WeChat, and independently verify its downloaded contents. Cover revoked authorization and an over-limit or invalid media case.

Blocked by

None — can start immediately. Completed prerequisite: #878 / PR #894.

Delivery and evidence

  • Deliver one production-shaped tracer through the qualified Provider, canonical Messaging authority, applicable PersonaBot/Channel/Inbox behavior, and an operable Client path. Reuse the existing exclusive Consumer; do not create standalone dsh-im Sessions or a parallel message store.
  • Keep the original external author, timestamp, lossless native message ID, Source Event ID, and trusted reply route. Every external send uses the acting Bot's own bound identity and current Grant; platform credentials, context tokens and media keys remain Provider-private.
  • Qualify the changed Provider capability on the maintained fork and pin the verified artifact. Submit reusable Provider changes upstream where appropriate, without making upstream merge a release prerequisite.
  • Complete fresh real WeChat E2E with the Human controlling WeChat. Include observable success and the relevant refusal/recovery behavior, focused regression coverage, and packaged-product verification. A model's claim, HTTP success, or client acknowledgement alone is not delivery/read proof.
  • Preserve real screenshots or recording during acceptance; embed GitHub-renderable evidence in the PR, including before/after and applicable light/dark states for visible UI changes. Do not publish credentials or unrelated chat contents.
  • Update the illustrated English and Chinese WeChat connection guide and reusable IM integration guidance with verified behavior and platform limitations; edit canonical source docs, not generated site content.
  • Create one issue-linked PR, then pause for Human QA. Merge and deployment require their own Human authorization. Issue closure requires the accepted behavior, not only documentation or a capability flag.

Activity

  1. added this to the v1.1 milestone on Oct 5, 2026
  2. added
    ready-for-agentFully specified, ready for an AFK agent
    area:fullstackEnd-to-end Host and Client implementation
    feature:messagingMessaging module and external providers
    scope:tracerHuman-testable implementation slice
    on Oct 5, 2026
  3. DoodleBears commented on Oct 5, 2026

    @DoodleBears
    ContributorAuthor

    Agent work claim

    • Agent: Codex
    • Task: codex/local/01a0f14c-5338-7020-853b-0fe54b87aa95 (not a DSH Session)
    • Issue scope: paired-owner checked file intake, bounded source-file processing, own-identity original-DM file reply, operable source details and real E2E evidence; no sibling media or WeCom expansion
    • Branch: codex/903-wechat-files
    • Started: 2026-10-05 18:28 UTC
    • State: active
  4. added
    agent:activeOne or more coding-agent tasks currently claim this issue; see claim comments for task IDs
    on Oct 5, 2026
  5. DoodleBears commented on Oct 5, 2026

    @DoodleBears
    ContributorAuthor

    Implementation checkpoint for #903 (one issue / one PR).

    • Local candidate uses the pinned Provider fork, private source-scoped file tickets, a 25 MiB actual download limit, and current-authority validation after upload before final send.
    • Provider regression: 3,574 PASS / 0 FAIL. BotHarness implementation regression: 2,574 PASS / 9 SKIP; subsequent wording/documentation changes passed lint, formatting, typecheck and build. Product packaging and the 354-page docs build passed. No CI result is claimed yet.
    • A fresh Human-sent WeChat ZIP entered the canonical Bot Inbox. The real model saved and extracted it, then generated an independent result ZIP after Human approved the bounded native file operations once. Independent checks confirm the 207-byte original is unchanged and the 224-byte result contains exactly the expected processed result.txt.
    • The canonical result artifact has one original-source file reply intent in provider-accepted state; the Bot Inbox source is handled. Provider acceptance is not native receipt or read proof. The Human downloaded BH903-result.zip from the paired WeChat conversation. Independent verification passed: downloaded bytes exactly match the 224-byte model-generated ZIP, it contains only result.txt with the blind expected content, and the 207-byte input is unchanged.
    • Real Inbox/source screenshots and a seven-second intake UI recording are retained; the recording demonstrates file inspection only. The native file/model/result roundtrip is now verified. Latest main was merged without conflicts; complete integrated regression is running and final UI evidence will be recaptured before creating the single WeChat tracer: checked source file processing and original-DM file reply #903 PR. No merge, deployment or sibling implementation is claimed.
  6. DoodleBears commented on Oct 5, 2026

    @DoodleBears
    ContributorAuthor

    Agent work outcome

    • Agent: Codex
    • Task: codex/local/01a0f14c-5338-7020-853b-0fe54b87aa95 (not a DSH Session)
    • State: paused — Human QA
    • PR: feat(wechat): process source files and return results in the original DM #932 — feat(wechat): process source files and return results in the original DM #932
    • Exact head: 28ae77022d92244263519d2ffffb904e2e63ea8f
    • Delivered candidate: paired-owner WeChat source-file intake, bounded working-copy processing, own-identity result-file reply in the original DM, source UI and bilingual illustrated guides.
    • Real E2E: Human-downloaded result matches the model-generated 224-byte ZIP exactly and contains the blind expected result.txt; the original 207-byte input is unchanged. SHA-256: 3364e577a3e99579372e5060d6180f13a50c7fb55c6623d91c2c1fa28255edb9.
    • Final main-integrated local verification: lint / format / typecheck / test / build passed; 2,585 PASS / 9 SKIP. Provider: 3,574 PASS / 0 FAIL. Docs: 358 pages. CI is queued/running, not yet passed.
    • Evidence: GitHub-rendered before/after dark/light screenshots, actual 3.64-second source inspection recording, plus separate PR Lens architecture/animated flow comment. All eight media URLs were checked successfully. External file E2E preceded latest-main integration; the unchanged file path was rebuilt/reinstalled and existing canonical state/UI reverified afterward.
    • Remaining: Human QA and separate merge authorization; broader WeChat media/lifecycle capabilities remain in sibling WeChat tracer: checked image intake and native image reply #904–WeChat tracer: global behavior defaults and Profile inheritance #912. No merge, deployment or sibling implementation started.
  7. added and removed
    ready-for-agentFully specified, ready for an AFK agent
    agent:activeOne or more coding-agent tasks currently claim this issue; see claim comments for task IDs
    on Oct 5, 2026
  8. DoodleBears commented on Oct 5, 2026

    @DoodleBears
    ContributorAuthor

    Agent work outcome

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:fullstackEnd-to-end Host and Client implementationfeature:messagingMessaging module and external providersready-for-humanRequires human implementationscope:tracerHuman-testable implementation slice

    Type

    No type

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions