mirror of
https://github.com/langbot-app/LangBot.git
synced 2026-08-09 20:50:58 +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.
68 lines
3.9 KiB
Markdown
68 lines
3.9 KiB
Markdown
# Agent Workflow
|
|
|
|
This repository stores reusable LangBot agent-testing assets. Keep changes structured so the next agent does not need to rediscover paths.
|
|
|
|
## First Steps
|
|
|
|
1. Read `skills/.env` before using local URLs, paths, browser profiles, or proxy defaults. If present, `skills/.env.local` overrides it for this machine and must not be committed. On a new machine, copy `skills/.env.example` to `skills/.env.local` first.
|
|
2. Pick the smallest relevant skill:
|
|
- `langbot-env-setup` for environment, browser, OAuth, proxy, and startup.
|
|
- `langbot-testing` for WebUI, provider, pipeline, cases, and troubleshooting.
|
|
- `langbot-skills-maintenance` for adding, deduplicating, or auditing this skills repository.
|
|
3. Prefer existing cases and troubleshooting entries before exploring from scratch.
|
|
|
|
## Editing Rules
|
|
|
|
- UI/browser testing is the primary QA path. API/curl checks are diagnostic only and cannot make a UI case pass by themselves.
|
|
- Put skills under `skills/<name>/`.
|
|
- Keep `SKILL.md` concise; move detailed workflows to `references/`.
|
|
- Put reusable test paths in `cases/*.yaml`.
|
|
- New or edited cases must include `priority`, `risk`, `ci_eligible`, and `evidence_required` so agents can select the right test set without rereading every file.
|
|
- Use `env_any` / `automation_env_any` for one-of machine inputs, such as `LANGBOT_PIPELINE_URL|LANGBOT_PIPELINE_NAME`; do not list those alternatives as separate all-required env keys.
|
|
- Put reusable groups of cases in `suites/*.yaml` rather than hardcoding test sets in docs or CLI code.
|
|
- Put growing failure knowledge in `troubleshooting/*.yaml`.
|
|
- Do not hardcode local ports in testing docs; use `skills/.env` variables and machine-local `skills/.env.local` overrides.
|
|
- Do not store secrets, API keys, OAuth tokens, or localStorage token values.
|
|
|
|
## Required Checks
|
|
|
|
After structural changes, run:
|
|
|
|
```bash
|
|
bin/lbs validate
|
|
```
|
|
|
|
After changing skills, cases, or troubleshooting assets, run:
|
|
|
|
```bash
|
|
bin/lbs index
|
|
```
|
|
|
|
Use `bin/lbs env show` to inspect defaults and `bin/lbs env doctor` when diagnosing local environment readiness. Env output is redacted by default; do not work around that by printing raw secrets.
|
|
Use `bin/lbs fixture check` before fixture-heavy cases such as MCP, RAG, multimodal, or plugin smoke tests.
|
|
Use `bin/lbs case list --ready` for cases that have no missing machine inputs and no manual preconditions. Use `bin/lbs case list --machine-ready` when you want to keep `manual-check` candidates and confirm their preconditions yourself.
|
|
|
|
Before executing a saved QA path, generate the agent-facing plan:
|
|
|
|
```bash
|
|
bin/lbs test plan <case-id>
|
|
```
|
|
|
|
Read the plan readiness sections before running the browser path. Missing env,
|
|
automation env, or fixture readiness means the case is not ready to execute and
|
|
should be marked `blocked` or fixed first.
|
|
`manual_check` means machine inputs are present but the agent must verify the
|
|
declared `preconditions` or `setup` items before executing the UI path. Do not
|
|
turn a `manual_check` case into `pass` until those items were checked in the
|
|
same run.
|
|
|
|
Before executing a group of saved QA paths, generate the suite plan:
|
|
|
|
```bash
|
|
bin/lbs suite plan <suite-id>
|
|
```
|
|
|
|
Use `bin/lbs suite start <suite-id>` to create a shared suite run id, suite evidence root, per-case evidence directories, and `suite-start.json`/`suite-start.md` handoff files. Then run `bin/lbs suite report <suite-id> --evidence-dir <dir>` to aggregate case results.
|
|
Automation scripts write `automation-result.json`; write the final per-case `result.json` with `bin/lbs test result <case-id> --result <status> --reason <text> --evidence-dir <dir> --evidence <comma-list>` after collecting the required evidence. A `pass` result must include all required evidence.
|
|
For runner-specific Debug Chat cases, prefer case-specific pipeline env keys such as `LANGBOT_LOCAL_AGENT_PIPELINE_URL` over the generic `LANGBOT_PIPELINE_URL`; otherwise an agent can accidentally test the wrong runner.
|