| name | audit-lab-functionalities |
| description | Audit a Lab (MVE or Project) to identify missing user-facing functionalities — setup, infrastructure, execution methods, debugging, testing, validation and clean up. Use when asked to find what a Lab is missing, check Lab completeness, or compare a Lab against the functionality matrix. Produces a status matrix, a prioritized gap list and an actionable task list. |
Audit Lab Functionalities
Identify which user-facing functionalities a Lab is missing and report them in a
consumable format (status matrix + gaps + task list).
A "functionality" is an option the user has to: bring up infrastructure, auto-install
tools/deps via setup.sh, execute the Lab (multiple methods), debug it (multiple
scenarios), test every part, validate results (multiple tools), and clean up.
Inputs
- Lab path:
src/[provider]/[mves|projects]/[name].
- Its docs:
docs/src/content/docs/[provider]/[mves|projects]/[name].mdx (EN) and the
es/ counterpart.
- The catalog and landing pages:
docs/src/content/docs/start-here/catalog.mdx and
docs/src/content/docs/index.mdx, plus their es/ counterparts.
- Its global integration test dir:
tests/[provider]/[mves|projects]/[name]/.
References to read first
.claude/rules/example-structure.md — required files/scripts per Lab..claude/rules/docs-style-guide.md — required doc sections and their order..claude/rules/tests-style-guide.md — local and global test conventions.
The Functionality Matrix (primary guide)
This matrix — not a twin Lab — is the source of truth for completeness. A twin Lab
(same service, e.g. s3-minio for s3-garage) is only a convenience for near-1:1 copying
when one exists; most Labs have no twin, so audit against the matrix directly.
The matrix is extensible: when a new common functionality is identified across Labs,
add a row here.
| # | Functionality | Signal in src/ | Signal in docs/ |
|---|
| 1 | Setup — Dev Container | .devcontainer/devcontainer.json with dockerComposeFile + postCreateCommand: scripts/setup.sh, and a dev service in docker-compose.yml | Tab "Dev Container (recommended)" in How to execute |
| 2 | Setup — Manual (mise) | scripts/setup.sh installing mise + mise.toml with a complete setup task | Tab "Manually" |
| 3 | Infrastructure | docker-compose.yml (or SAM/firebase equivalent) with a top-level name: mistlock-[provider]-[lab-name] and no container_name on any service | Step "Start Infrastructure"/"Start Host" |
| 4 | Execution — multiple methods | scripts/run_main.sh; main.py; optional http/*.http, CLI scripts | Step "Run the Example" using <Tabs> (Python / cURL / REST Client / CLI) |
| 5 | Debug | .vscode/launch.json with configs (main.py, function/service, tests) | Section "How to debug" |
| 6 | Test — local | tests/ mirroring src/, tests/conftest.py, .env.test, scripts/run_tests.sh | Section "How to test" |
| 7 | Test — global integration | tests/[provider]/[mves|projects]/[name]/test_[name].py using run_tests/run_main fixtures | — |
| 8 | Validate results — multiple tools | CLI/GUI scripts (*_cli.sh, *-gui.sh), VS Code extensions | Section "Validate results" using <Tabs> (≥2 tools) |
| 9 | Clean Up | docker compose down -v (or service-specific teardown) |
Notes:
- Some functionalities are not applicable to every Lab (e.g. SAM Labs are incompatible
with Dev Containers; a pure CLI Lab may have a single execution method). Mark these
N/A with a one-line reason rather than as a gap.
- Reference "complete" Labs to consult as benchmarks:
aws/mves/lambda-sam,
aws/mves/s3-minio, azure/mves/functions, google-cloud/mves/firebase-cloud-functions,
hybrid/mves/mongo, hybrid/mves/redis.
Procedure
- Inventory the Lab: list files in
src/[lab], read its EN+ES docs pages, and check
for tests/[provider]/[mves|projects]/[name]/.
- Score each matrix row as
✅ (present), ⚠️ (partial), ❌ (missing) or N/A
(with reason) — checking both the src/ signal and the docs/ signal. A row is
only ✅ when both code and docs are present.
- Cite evidence: the exact file path that satisfies (or the absence that fails) each row.
- Twin compare (optional): if a same-service twin exists, diff structure to surface
anything the twin offers that this Lab lacks; otherwise rely on the matrix.
- Check EN/ES parity: same sections in both doc pages.
Output format
Produce Markdown with three parts:
1. Status matrix
Reproduce the matrix table with a Status column and an Evidence column per row.
2. Prioritized gaps
- Critical: an entire functionality dimension absent (e.g. no tests at all, no debug).
- Improvement: partial coverage (e.g. a single execution method where more apply,
missing optional validation tool).
3. Task list
Concrete, ordered, actionable items to close every gap — each naming the file(s) to create
or edit and, when a twin exists, the file to copy from (adjusting service-specific values
such as ports, endpoints, profiles, and dynamic credentials).
