Repository navigation
Create the app inside Bind app: Lark credentials and WeChat QR (Provider setup capability) #1111
Description
Parent: #1107 · ADR-0142 · after slice 3
What to build
- Provider (
@botharness/im-providerfork): a versioned, optional setup capability on the public same-Host Service:- Start setup, submit credentials, start and poll a WeChat QR session, cancel.
- It returns only the new opaque account reference and the authenticated
describeBotresult. - Secrets and QR tokens go from the Client to the Provider's own settings transport and never through the BotHarness Host.
- New accounts start in
external-consumermode, so no standalone Provider Session answers before binding. - This requires a new Provider version, digest and qualification record (ADR-0104/0127).
- Host: negotiate the capability. Bind the returned account in the same flow (fingerprint check, then Binding, then registration). For WeChat, the paired-owner DM becomes default traffic through the slice 1 path.
- Client:
- Bind app → Create app step for Lark/Feishu (domain, App ID, App Secret, plus permission and event checklist links from the existing Lark guide) and WeChat (QR).
- Resumable when the dialog closes mid-way.
- Without the capability, fall back to opening the Provider settings and return to the bind step.
Acceptance criteria
- Lark: from a Bot DM, create and bind a new app in one dialog. DM and mention work with no visit to Settings.
- WeChat: scan the QR in the dialog, then the owner DM reaches the Bot and the reply arrives in WeChat.
- No secret or QR token appears in BotHarness Host logs, the Operational Database, the snapshot DTO or Memory (test asserts this).
- A newly created account is never answered by a standalone Provider Session between creation and binding.
- The fallback path works with a Provider lacking the capability.
- Real-platform evidence with the packaged product Provider, plus the Provider qualification record.
Blocked by
Slice 3 (#1110). Provider fork release.
Activity
DoodleBears commentedon Oct 8, 2026
Agent work claim
codex/local/01a117bf-865d-72d1-a9c6-88658c59f844(not a DSH Session)codex/1111-inline-app-setupdocs: record inline setup review and Windows baseline evidence
DoodleBears commentedon Oct 8, 2026
#1111 remains active in draft product PR #1231 and Provider PR #18.
.2/9889ada5actual Client creation/binding, native DM1591and group @1927passed with matching Source/Inbox/native receipts and Human confirmation. The original unknown request remains preserved without replay.bddd7d93: 3768/3768 passed, zero skips. Composed Host tests now use real management transport, assert all routes including setup, and retain original isolation/disposal/error checks. Runtime digest remains unchanged.78aba544integrated; latest product43c03b2dis mergeable, focused 113/113, types/lint/format/bilingual ledgers passed, both review axes clear. Verify and package preparation both passed: 3478 tests, 9 skipped, 426 passed files and 5 skipped. Preparation uploadednpm-prerelease-0.1.0-alpha.1-preview.1231.37839285349(dry-run only, no registry publication). Prior58a97aafverify passed 3471 tests / 9 skipped; its preparation hit one original 60-second docs-build timeout. A subsequent QA formatting failure was corrected; no test or timeout was relaxed. Earlier Windows failures are retained separately..6, sourceb80b8890/ Provider.17/bddd7d93: actual authenticated public Host QR generation, pending poll and cancellation passed. Identity count one before/after, WeChat account count zero, Lark connected, no QR in BotHarness snapshots. This package predates Generation 73 main integration and is not Client visual or native pairing qualification.6b2491e, based on upstreambbafc99(scope/claim #338). Its separate Lark/Feishu-only adaptation passes clean Linux 3987/3987, zero skips, focused 155/155, build/package verification and exact rebuilt-artifact comparison. Upstream CI is green: Linux full 3987/3987, Windows workspace 147 passed /1 skipped. Both PR Lens PNG themes render in the upstream PR. It exposes no WeChat setup: upstream first needs a checked external-consumer WeChat account contract. This does not change the product pin, fork candidate or installed profiles. Independent upstream review and native qualification remain pending; earlier downstream Lark evidence does not qualify this new revision..6Client generated a WeChat QR, closed/reopened its pending operation and cancelled it; the QR was removed. Two public screenshots (1559 ×865, Chinese/dark) show Create app and the cancelled form; the pending QR image stays private. Post-cancel read-only proof confirms one identity, zero WeChat accounts, Lark connected and no QR in Host snapshot. This is.6evidence, not latest-main Client qualification. No continuous recording capability is exposed; a fresh baseline viewport capture timed out and the override was reset.0.1.0-alpha.1-preview.1231.37839285349/43c03b2dinstalled into a fresh isolated Profile: authenticated public QR generation, pending poll and cancellation passed; Bot count stayed zero and WeChat account count zero. Its CI Provider artifact has 413 runtime files and its own verified hash; no previous IM config or pairing was copied. Normal native login subsequently succeeded. Actual final-head Client model DM17×19 → 323, QR generation, close/reopen Bind app → Create app → resume, cancel → QR removed, Tab → Close and Escape → closed all passed. No console errors; native diagnostics shell-ready, no earlier failure. Read-only audit: one auto-created Bot, zero WeChat accounts, no QR in public snapshot. Three final-head screenshots are attached; live QR is private. Existing instances were retained.The issue and goal remain active; no issue completion, merge, registry/product release or deployment is claimed. Agent-Task:
codex/local/01a117bf-865d-72d1-a9c6-88658c59f844.docs: record Linux inline setup regression comparison
merge: integrate main into inline app setup
docs: qualify inline Lark setup and clarify reply read permission
Merge latest main while retaining inline app setup
feat(client): pair WeChat inside the app binding dialog
33 remaining items
DoodleBears commentedon Oct 13, 2026
Agent continuation claim — GitHub-owned Provider publication
codex/local/01a1342d-5ce4-7872-9f9e-492a9caee393(not a DSH Session).20Provider publication using the repository's existingNPM_TOKENand protectednpm-releaseenvironment. Prepare a Provider-only GitHub job that consumes the exact natively qualified archive; preserve product publishing, secrets and environment/tag protections.codex/1111-github-provider-publication.merge: preserve main access scope before proactive quota migration
docs: record exact Provider registry publication and final integration
fix: preserve uncertain picker requests and reuse exact published Pro…
fix: reconcile original post receipts through the owning Outbox
test: include read-only post recovery in the exported bridge contract
fix: isolate Provider staging from ambient TypeScript configuration
merge: preserve main schema and isolate proactive quota revisions
DoodleBears commentedon Oct 13, 2026
Agent work outcome — completed
codex/local/01a1342d-5ce4-7872-9f9e-492a9caee393(not a DSH Session).2bf2bfc292fc9ea0bcbe191350f05a81a9aa9317at 2ff29cce, and closed Proactive posts to any conversation the platform lets the app speak in #1115 and Create the app inside Bind app: Lark credentials and WeChat QR (Provider setup capability) #1111. All acceptance checkboxes are complete.@botharness/im-provider@4.32.0-botharness.20is on npmnext; actual registry archive bytes match the natively qualified SHA-512. Publication used the existing protected GitHub NPM_TOKEN; local npm login was not needed. Registrylatestremains.16; stable Product install identity is unchanged.