mirror of
https://github.com/langbot-app/LangBot.git
synced 2026-06-20 20:44:21 +00:00
Junyan Chin
e9dd584792
* feat(api): support global API key from config.yaml (api.global_api_key) Accept a config-defined global API key anywhere a web-UI key is accepted (X-API-Key / Bearer), with no login session and no DB record. Useful for automated deployments and AI agents (HTTP API + MCP). Defaults to empty (disabled); does not require the lbk_ prefix. - templates/config.yaml: add api.global_api_key with security notes - service/apikey.py: verify_api_key checks global key first (constant-time) - docs/API_KEY_AUTH.md: document the global key + security guidance - tests: cover global-key match, prefix-free, fallback-to-db, disabled * feat(mcp): expose LangBot management as an MCP server at /mcp Add an MCP (Model Context Protocol) server so external AI agents can manage a LangBot instance. Reuses the same API-key auth as the HTTP API (including the config.yaml global API key). - pkg/api/mcp/server.py: FastMCP server wrapping the service layer; 21 curated tools across system/bots/pipelines/models/knowledge/mcp-servers/skills - pkg/api/mcp/mount.py: ASGI dispatcher fronting Quart; authenticates /mcp requests with an API key, runs the streamable-HTTP session manager lifespan - controller/main.py: serve the wrapped ASGI app via hypercorn (was run_task) - web: new 'MCP' tab in the API integration dialog showing endpoint, auth, and client config; i18n for 8 locales - tests/manual/mcp_smoke.py: e2e check (401 unauth, list tools, call tools) Tool surface is intentionally curated (not all ~25 route groups) to keep the agent surface small, safe, and maintainable. Extend deliberately. * feat(skills): add in-repo skills/ as the single source of truth Migrate the agent skills + QA/e2e test harness from the (now archived) langbot-app/langbot-skills repo into LangBot/skills/, and add four new skills. Migrated: - langbot-plugin-dev, langbot-testing (e2e), langbot-env-setup, langbot-skills-maintenance, langbot-eba-adapter-dev - the bin/lbs CLI (src/, test/, scripts/, schemas/, qa-agent-docs/) New: - langbot-dev core backend + web development - langbot-deploy Docker/K8s deployment + config.yaml + global API key - langbot-mcp-ops operating the LangBot MCP server (/mcp) - langbot-space-ops operating the Space marketplace MCP server - src/cli.ts repoRoot(): recognize the skills assets root (skills.index.json + bin/lbs) so the CLI works when nested inside the LangBot repo - README.md: unified skill catalog; skills.index.json regenerated Parity with source verified: bin/lbs validate + node test suite match the source repo (only the uncommitted .lbpkg build-artifact fixture differs). * docs(agents): document agent-facing surfaces + API/MCP/skills sync rule * docs(readme): add 'Built for AI Agents' section across all locales Highlight MCP server, in-repo skills (single source of truth), AGENTS.md sync rule, and llms.txt. Cross-link LangBot Space MCP marketplace. * style(mcp): fix ruff format + prettier lint in MCP server and API panel * style(web): prettier format MCP i18n locale entries * docs(skills): note MCP instance control in dev/testing skills All development-guidance skills now point to the LangBot instance MCP server (/mcp) and the Space marketplace MCP server, reusing API keys.
58 lines
2.0 KiB
Markdown
58 lines
2.0 KiB
Markdown
# Agent Browser QA Principles
|
|
|
|
This document fixes the direction of LangBot agent testing so the project does not drift into a backend API smoke-test framework.
|
|
|
|
## Primary Goal
|
|
|
|
`langbot-skills` should help an agent behave like a QA engineer using the product, not like a backend curl script.
|
|
|
|
The primary path is:
|
|
|
|
```text
|
|
developer intent -> lbs test plan -> agent controls browser -> UI result + console + logs -> report/assets
|
|
```
|
|
|
|
## Rules
|
|
|
|
1. Browser/UI interaction is the source of truth for product QA cases.
|
|
2. A backend API or curl response is never enough to mark a UI case passed.
|
|
3. API/curl/log checks are allowed as diagnostics after a UI path is attempted or when debugging environment readiness.
|
|
4. A case passes only when the user-visible UI result is correct.
|
|
5. The agent should inspect browser console/network output when available.
|
|
6. If screenshot or vision capability is available, the agent should check for blank pages, overlap, hidden actions, broken layout, and error toasts.
|
|
7. If no visual model is available, use DOM/accessibility snapshots and console output instead.
|
|
8. New stable UI paths should be added as `cases/*.yaml`.
|
|
9. New recurring failure modes should be added as `troubleshooting/*.yaml`.
|
|
10. Secrets, tokens, API keys, and localStorage token values must never be printed.
|
|
|
|
## Command Semantics
|
|
|
|
`lbs` manages assets and produces plans. It does not replace the agent's browser-control ability.
|
|
|
|
```bash
|
|
bin/lbs test plan pipeline-debug-chat
|
|
```
|
|
|
|
This command outputs:
|
|
|
|
- environment variables to use
|
|
- required skills
|
|
- browser steps
|
|
- UI/console/visual/log checks
|
|
- diagnostic options
|
|
- related troubleshooting patterns
|
|
- report template
|
|
|
|
The active agent then executes the plan with Computer Use, Playwright MCP, or another available browser-control tool.
|
|
|
|
## Diagnostics
|
|
|
|
Diagnostics can include:
|
|
|
|
- `bin/lbs env doctor`
|
|
- browser console/network inspection
|
|
- backend logs
|
|
- targeted API/curl checks
|
|
|
|
Diagnostics answer "where did it fail?" They do not replace "did the user-visible UI work?"
|