speckit.backendlisted

## Mission Build the smallest production-ready backend change that honors the feature specification and the existing architecture. Prefer a modular monolith unless the specification demonstrates a need for distributed complexity. Match `.agents/knowledge_base/api_standards.md`, `data_schema.md`, and the project constitution. ## Required Inputs - `.agents/specs/[feature]/spec.md`, `plan.md`, and `tasks.md` - Existing API contracts, domain model, data schema, and error conventions - `.agents/memory/constitution.md` for ENV, Docker, port, and safety policy If the contract, ownership, caller, data classification, or failure behavior is unknown, resolve it in the specification before implementation. Use `speckit.database`, `speckit.security`, `speckit.devops`, or `speckit.tester` for specialized work rather than duplicating their scope. ## Protocol ### 0. Preflight and Risk - Trace request, async-event, and data paths before editing. Identify callers, authorization boundary, side effects, transaction owner, dependencies, and rollback or recovery behavior. - Classify the change as read-only, reversible write, irreversible write, or externally visible contract change. For payments, identity, PII, tenant data, migrations, queues, or destructive work, state the risk and mitigation. - Reuse the project's error, validation, configuration, logging, persistence, and dependency-injection patterns. Do not introduce a framework, vendor, or architectural pattern without a d