Design Backend

Make backend design decisions visible before implementation. Use the codebase and stated constraints as the source of truth; prefer existing infrastructure and patterns over new abstractions. Treat Go, Rust, and Python as the usual backend languages; follow the existing service language, or agree on one when creating a service.

Lazy Design

Lazy means minimizing implementation and ongoing maintenance effort while meeting the agreed requirements. Read the relevant code and trace affected callers and data flow before recommending a design. For fixes, address the cause at the appropriate shared owner. Favor readable, complete solutions over line-count targets.

Consider, in order: no change if the outcome is already met; reuse in the codebase; standard-library support; native platform features; installed dependencies; then minimal custom code or a justified new dependency. Stop when an option satisfies the contract and constraints. Preserve established conventions when replacing them would add migration work without a concrete benefit.

Require a current need for extra layers, configuration, or extension points. At each applicable level, identify any unnecessary proposed machinery and its replacement; keep this review within the requested scope. Explain why the simpler option suffices or which requirement rules it out. Preserve explicit requirements, trust-boundary validation, security, data integrity, and necessary error handling. Propose scope reductions for agreement.

Dependency Gate

At Components, list every proposed new third-party package, SDK, client, or external service with its purpose and why an existing dependency does not suffice. Obtain explicit agreement for each before moving to Interactions. Do not add, install, configure, or assume approval for a new dependency.

Conversation

Start at Capabilities for cross-service work, data-model changes, integrations, or unclear scope. Start at Components for a bounded endpoint or service. Never skip Contracts. Present exactly one level at a time, concisely; ask for explicit approval before moving on. Do not write code, change files, or include implementation snippets until all needed design levels are approved.

1. Capabilities — Confirm the outcome, in-scope and out-of-scope behavior, actors, non-functional requirements, and constraints.
2. Components — Identify existing and new handlers, services, stores, queues, and adapters. Consider database constraints or existing queries before custom coordination, caches, or services. Justify new boundaries with current ownership, isolation, or scaling needs and obtain the dependency agreement.
3. Interactions — Show request/event flow, ownership, consistency model, failure paths, retries, idempotency, and observability.
4. Contracts — Specify API/event schemas, validation, authorization, error semantics, persistence/migration effects, and test seams. For deliberate simplifications, state the supported limit, observable revisit trigger, and upgrade path.
5. Implementation — After approval, propose a small ordered plan and focused checks of the contract and relevant failure paths; implement only when requested. Record non-obvious accepted limits near the affected code using repository conventions.

At every level, distinguish confirmed facts from assumptions, surface consequential alternatives with a recommendation, and finish with the decision needed for approval. Keep unrequested features out of scope.