mirror of
https://github.com/langbot-app/LangBot.git
synced 2026-10-28 11:25:35 +08:00
0582d1b3d4
Move the 27 internal design docs (87 tracked files) from docs/ to dev-docs/ to make room for the public documentation site, adjust Docker/fnOS ignores, refresh the README/AGENTS/ARCHITECTURE references, and land the docs workflows ahead of the subtree import so they cannot diverge from mirror. Co-Authored-By: Mika (Multica) <[email protected]> Co-authored-by: multica-agent <[email protected]>
83 lines
4.9 KiB
Markdown
83 lines
4.9 KiB
Markdown
# Message routing acceptance
|
|
|
|
Use an isolated worktree, data directory, ports and Plugin Runtime. Preserve the
|
|
member's database and bot configuration. Back up SQLite with its backup API before
|
|
repairing data; do not copy a live WAL database with a plain file copy.
|
|
|
|
## Reproduction and repair
|
|
|
|
The product processor form sends `POST /api/v1/agents` with `kind=pipeline`.
|
|
Previously `AgentService` forwarded `config={}`, bypassing the Pipeline service's
|
|
default-config branch. The row was inserted, then stage initialization raised
|
|
`KeyError: safety`. Repeated failed creates could leave empty-config rows.
|
|
|
|
Pipeline creation now omits this empty override and the Pipeline service also
|
|
handles explicit `{}` as a request for defaults. Existing non-empty configs are
|
|
not replaced. For affected historical rows, back up first, inspect their config,
|
|
and repair only rows whose entire config is exactly `{}` with the version's
|
|
default Pipeline template. Preserve UUID, name and all other columns. Do not
|
|
silently reset partial or non-empty configurations.
|
|
|
|
New bots previously had no routes if there was no Pipeline. First-bot setup now
|
|
creates one default Pipeline and reuses it, serialized within the instance.
|
|
Existing bots are never rewritten. The old message preset added one unfiltered
|
|
route; it now adds separate private and group-mention routes, with an explicit
|
|
boolean mention condition in the editor. Reapplying preserves manual targets and
|
|
disabled routes.
|
|
|
|
## Acceptance sequence
|
|
|
|
1. Use the real WebUI to create a Pipeline, verify success, refresh its page, and
|
|
inspect persisted `trigger`, `safety`, `ai`, `output` sections. Correlate the
|
|
creation request with the HTTP access log.
|
|
2. Create a separate test bot. Confirm that the two message routes already
|
|
exist. Expand conditions and verify the private/group split and boolean
|
|
`is_at_bot=true`.
|
|
3. On the test bot only, remove the generated routes, use the message template,
|
|
save, wait for success, then refresh. Click the template again and check that
|
|
it neither duplicates conditions nor replaces manual targets.
|
|
4. Connect a local OneBot Universal protocol simulator using its own token and
|
|
fake bot/group/user IDs. Never attach the simulator to a real QQ account.
|
|
5. Send a bounded sequence: unmentioned group, mention of another user, private,
|
|
mention of the bot. Capture per-case task counters, Core logs, and the WebUI
|
|
bot log/matching records. The first two must create no Pipeline tasks; the
|
|
latter two must route to the selected Pipeline.
|
|
6. Verify actual replies separately with an authorized model. A matched route
|
|
followed by a missing-model error proves routing, not successful AI replies.
|
|
Label local protocol simulation separately from real-platform acceptance.
|
|
7. Confirm original member rows/configs are unchanged, capture service ownership
|
|
and health, and keep the isolated dev services available for manual review.
|
|
|
|
Use existing `skills/.env` conventions for machine-specific URLs. Apply resource
|
|
stop thresholds before bounded tests; do not treat a short idle sample as a soak
|
|
test or a health endpoint as feature acceptance.
|
|
|
|
## Wizard regression coverage
|
|
|
|
The Wizard creates a dedicated Pipeline before creating its disabled Bot, and
|
|
passes the same explicit private/group-mention template used by manual setup.
|
|
Returning to the same platform reuses the Bot and retains unsaved form values.
|
|
A successful Pipeline remains in the in-page draft if Bot creation fails, so a
|
|
retry reuses it. Create/save operations have a synchronous reentry guard.
|
|
Saving adapter settings reads the current Bot and only initializes routes when
|
|
none exist; it never replaces nonempty custom rules or re-enables disabled ones.
|
|
|
|
For real UI acceptance, use a separate empty data directory and ports; never
|
|
reset the member's database or Wizard progress. Complete registration, platform
|
|
selection, save/enable, receipt of an isolated protocol message, AI choice and
|
|
finish. Refresh the completion page and compare persisted Bot/Pipeline UUIDs.
|
|
Return to the platform step and submit again; assert one Bot, one Pipeline and
|
|
unchanged route IDs. Remove/reapply the message template through the Bot UI and
|
|
repeat the private/unmentioned-group/other-mention/bot-mention protocol probes.
|
|
Disable a rule through the UI, restore a QA-only step-1 Wizard draft pointing to
|
|
the existing Bot/Pipeline, save through the UI, and compare every binding field.
|
|
Verify the disabled rule also stays inactive at runtime.
|
|
|
|
The 2026-10-20 Mac run completed this flow against real Core/RT using native
|
|
Codex Computer Use. Both default and manual templates created tasks only for
|
|
private messages and mentions of this bot. After custom group-route disablement
|
|
and Wizard resave, even a mention created no task. Model execution failed with
|
|
missing credentials; successful AI replies and real long-running busy model
|
|
sessions are not certified by this run. Busy-session controller/response-rule
|
|
unit tests are a separate regression result, not a substitute for that evidence.
|