Scenario guide test results
On 2026-09-07, we checked these guides in a separate test project with Lizard CLI 0.3.92. Application checks are separate from build status. The tests used the guide commands, with a distinct project name and the documentation test branch for the GitHub example.
| Guide | Result | Checks |
|---|---|---|
| Remote MCP | Passed locally and in the cloud | Health 200; missing and invalid token 401; authenticated GET 405; rejected Origin 403; initialize, tools/list and tools/call; result 5 over public HTTPS |
| Coding agent: upload | Passed | lizard up, health 200, database-backed response 200, unknown route 404; an updated Postgres row remained after service restart |
| Coding agent: GitHub | Passed | Repository attached with --no-deploy; branch, root directory and environment configured before redeploy; the public app read the same existing Postgres row |
| Redis worker | Passed | Port 0; enqueue and result; result retained after restart; new job after restart; an unfinished processing entry recovered on startup |
| Telegram bot | Local tests only | Seven mocked tests cover updates, failed sends, token checks and webhook refusal. A real token, chat and cloud echo test are still required |
Versions
The MCP container ran Node.js 22.23.2 with MCP TypeScript SDK 1.30.0. The coding-agent example uses pg 8.16.3 and connected to Managed Postgres running PostgreSQL 18.4. The worker container ran Python 3.13.15 with redis-py 6.4.0. Dependency lockfiles or exact requirements live with the examples.
Scope
The MCP check covers the example’s stateless HTTP transport and fixed bearer token. It does not establish OAuth compatibility, browser support, long-duration streaming or load capacity. The token expires after one hour.
The GitHub check used the documentation branch and _examples/agent-app directory. It tested an explicit redeploy; it did not test every private-repository permission setup or webhook event.
The Redis recovery check seeded an unfinished processing entry before restarting a single consumer. It did not test Redis failure, multiple workers or exactly-once external effects. The database check establishes persistence across an application restart, not backup or disaster recovery.
Runtime log tails were initially empty for the test services. A live worker log stream later delivered a newly processed job. Use the HTTP, MCP client and job-result checks as the completion criteria; an empty log tail alone does not establish either success or failure.
The Telegram example is not marked cloud-verified. Its preflight reads getMe and getWebhookInfo without changing the bot’s webhook. Use a separate test bot before enabling its polling loop.
See framework test results for the separate 16-recipe framework batch, and known issues for CLI archive and failed-build exit-code limits.
Updated