Design IaC

Make intended infrastructure state, ownership, dependencies, and operational risk explicit before changing declarative infrastructure. Use CloudFormation or Pulumi, following the repository's established choice; follow its provider, module, state, naming, tagging, and policy conventions.

Lazy Design

Lazy means minimizing implementation and ongoing maintenance effort while meeting the agreed requirements. Read the relevant infrastructure definitions and trace affected resource, state, and traffic dependencies 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 repository; standard tooling; native provider features; installed components; then minimal custom infrastructure logic 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 resources, modules, 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, isolation, least privilege, durability, and required availability and recovery guarantees. Propose scope reductions for agreement.

Dependency Gate

At Components, list every proposed new third-party provider, module, component package, plugin, or managed external service, with its purpose, ownership, lifecycle, and why an existing dependency cannot meet the need. Obtain explicit agreement for each before moving to Interactions. Do not add, configure, or assume approval for a new dependency.

Conversation

Start at Capabilities for topology or environment changes; start at Components for a bounded resource/module change. Never skip Contracts. Present one level at a time and wait for explicit approval. Do not edit IaC, run plans/applies, or show implementation configuration until the design is approved.

1. Capabilities — Confirm target state, environments, availability, security, data residency, cost constraints, blast radius, and exclusions.
2. Components — Identify providers, modules, resources, remote state, networks, identities, observability, and managed dependencies; reuse approved modules first. Consider native resource properties before custom resources or controllers; justify additional regions, clusters, or module layers against current requirements and operating cost. Obtain the dependency agreement.
3. Interactions — Trace resource dependencies, network paths, IAM trust, secret/configuration flow, data flow, lifecycle/replacement effects, and cross-environment promotion.
4. Contracts — Specify module inputs/outputs, provider/version constraints, state boundaries, names/tags, policy controls, ownership, and acceptance checks. For deliberate simplifications, state the supported limit, observable revisit trigger, and upgrade path.
5. Implementation — After approval, propose a staged plan with static validation, plan review, and safe rollout/rollback; implement only when requested. Check replacement and deletion effects even when simplification shrinks the configuration. Record non-obvious accepted limits near the affected definitions using repository conventions.

Surface destructive or replacement risk early. Do not create public exposure, privilege expansion, state moves, or irreversible data effects without a clearly approved decision.