tracking(bots): harden onboarding after V1
- Dominant language
- TypeScript
- Stars
- 5.4k
- Forks
- 502
- Avg merge
- 1d 2h
- Merged PRs (30d)
- 715
Description
## Problem
V1 IM onboarding is implemented, but its remaining security, authorization,
observability, packaging, and provider-lifecycle work exists only in the
architecture document. Without a focused tracker, the shipped onboarding path
can stay partially hardened indefinitely.
## Completed baseline
- #1197 added main-process-owned QR onboarding, secret-free renderer snapshots, fenced credential commit/rollback, runtime reconciliation, and manual fallback.
- #1526 extended onboarding/runtime coverage to QQ, Slack, and WhatsApp.
- Existing sessions keep credentials in the owner-only settings boundary and never expose raw provider responses to the renderer.
## Remaining work
- [ ] Move bot secrets into a Keychain-backed credential authority while preserving masked renderer projection
- [ ] Add pairing approval and a remote permission-profile policy
- [ ] Add bounded retry telemetry and redacted, diagnosable health events
- [ ] Add a packaged Electron smoke for native architecture, ASAR resolution, and SDK resources
- [ ] Define provider-specific revoke/delete behavior while keeping local-only cancellation explicit where necessary
## Non-goals
- Replacing the Bot runtime or moving onboarding into MCP
- Removing provider-specific manual setup
- Exposing secrets, device codes, poll tokens, or raw provider errors
- Bot reply streaming, which is tracked separately by #2504
## Design
- [IM onboarding runtime architecture](https://github.com/apache/maka/blob/main/docs/architecture/bot-onboarding-runtime.zh-CN.md)
- V1 implementation: #1197
- Additional providers: #1526
Contributor guide
Research direction
Start with docs/architecture/bot-onboarding-runtime.zh-CN.md and review the baseline work in #1197 and #1526. Use the five remaining-work items to identify the affected entry points and dependencies; the tracker is done only when each security, policy, telemetry, packaging, and provider-lifecycle requirement has an agreed implementation and verification path.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- electron, typescript
- Domain
- authorization, desktop, observability-sre, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100