# Rules

These rules are mandatory and apply to all work: editing files, generating patches, running commands, using tools/MCP servers, and responding in chat. If a user request would violate any rule, stop and ask for explicit confirmation before proceeding. If the user confirms, proceed only to the minimum extent required.

- **No silent fallbacks / no hidden defaults (code + MCP servers + chat):** Do not guess, invent, or assume missing required inputs/config/constants. Only use defaults that are product-specified, explicit, documented, and tested. Otherwise, surface the failure.
- **Single source of truth:** Every piece of data (environment variables, database state, configuration, derived metrics) must have one canonical source. Do not maintain separate mutable state when it can be derived from the canonical source.
- **Response protocol:** Answer direct questions explicitly before proposing or generating changes.
- **Environment files:** Never modify the repository's `.env` file (application secrets). Only modify the `.env.example` file. If a change is needed in `.env`, ask the user to make it and provide exact, copyable instructions. Note: `.agent-layer/.env` is managed by `al wizard` and is a separate file from the repository's application `.env`.
- **Repository boundary:** Never delete files outside of the repository. If a file outside of the repository needs to be deleted, ask the user to delete it.
- **Unexpected repository changes:** Do not pause, warn, or ask about unrelated working tree changes; only stop if the changes overlap files you are editing or could cause a conflict, otherwise ignore them and continue.
- **Secrets and credentials:** Never add secrets, private keys, access tokens, or credentials to repository files, logs, or outputs. Use placeholders and documented variable names in `.env.example`, and instruct the user to supply real values locally.
- **Destructive actions:** Never run or recommend destructive operations that can remove or overwrite large amounts of data without explicit confirmation from the user, and always name the exact paths that would be affected.
- **No content substitution:** When asked to summarize or read specific content (documentation, code, website), if you cannot access or fully read it, surface the failure and let the user decide.
- **Verification claims:** Never claim that you ran commands, tests, or verification unless you actually did and observed the output. If you did not run verification, state what should be run and why.
- **Test integrity:** Never skip tests. If a test fails, fix the underlying issue or fix the test. If a test cannot run due to missing dependencies, ensure the dependencies are available rather than skipping the test.
- **No tautological or self-confirming tests:** Every test must be able to fail because of a real implementation defect. Delete tests whose assertions are satisfied by their own setup or merely restate implementation facts: mocked values echoed back unchanged, static JSX/rendered text with no behavior or contract under test, trivial argument passthrough, or constants/config compared to themselves. Do not write runtime tests for constraints already enforced by a language, compiler, type checker, schema, or static analyzer; test behavior, logic, integration, and runtime failure modes instead. Prefer a visible coverage gap to false coverage.
