Universal design principles that all generated code and infrastructure must follow. These are not suggestions — they are standards.

Domain: principles

---

Check	Description
STAN-DES-001	Single Responsibility: Every function, method, class, and module must have exactly one responsibility. If a function does more than one thing, split it.
STAN-DES-002	DRY (Don't Repeat Yourself): Extract repeated logic into shared functions, modules, or variables. Duplication is acceptable only when the duplicated code serves genuinely different purposes that may evolve independently.
STAN-DES-003	Open/Closed Principle: Modules and classes should be open for extension but closed for modification. Use variables, parameters, and composition to allow customization without changing the core implementation.
STAN-DES-004	Least Privilege: Grant only the minimum permissions required. Every role assignment, network rule, and access grant should be as narrow as possible.
STAN-DES-005	Explicit Over Implicit: Be explicit about configuration, dependencies, and behavior. Avoid relying on defaults that may change or on implicit ordering.

---

Single Responsibility: Every function, method, class, and module must have exactly one responsibility. If a function does more than one thing, split it.

Rationale: Modular Bicep templates promote reuse and simplify testing of individual components.
Agents: terraform-agent, bicep-agent, app-developer, csharp-developer, python-developer, react-developer, cloud-architect

• Terraform: one resource per module when the resource has complex configuration
• Application: a function that fetches data should not also format it for display
• Bicep: separate networking resources from compute resources into distinct modules

---

DRY (Don't Repeat Yourself): Extract repeated logic into shared functions, modules, or variables. Duplication is acceptable only when the duplicated code serves genuinely different purposes that may evolve independently.

Rationale: Parameterized configurations allow reuse across environments and prevent hardcoded values.
Agents: terraform-agent, bicep-agent, app-developer, csharp-developer, python-developer, react-developer

• Terraform: use locals and variables instead of repeating values
• Application: extract common HTTP client setup into a shared utility
• Bicep: use modules for repeated resource patterns

---

Open/Closed Principle: Modules and classes should be open for extension but closed for modification. Use variables, parameters, and composition to allow customization without changing the core implementation.

Rationale: Parameterized configurations allow reuse across environments and prevent hardcoded values.
Agents: terraform-agent, bicep-agent, app-developer, csharp-developer, python-developer, react-developer

• Terraform: use variable maps for optional features instead of hard-coded conditionals
• Application: use dependency injection instead of hard-coded implementations

---

Least Privilege: Grant only the minimum permissions required. Every role assignment, network rule, and access grant should be as narrow as possible.

Rationale: Following established standards ensures consistency, quality, and maintainability across the codebase.
Agents: terraform-agent, bicep-agent, cloud-architect, security-architect

• Use 'Storage Blob Data Reader' instead of 'Contributor' for read-only access
• Scope role assignments to the specific resource, not the resource group

---

Explicit Over Implicit: Be explicit about configuration, dependencies, and behavior. Avoid relying on defaults that may change or on implicit ordering.

Rationale: Externalized configuration supports environment-specific settings without code changes.
Agents: terraform-agent, bicep-agent, app-developer, csharp-developer, python-developer, react-developer

• Terraform: always set explicit depends_on when resource ordering matters
• Bicep: declare parameter defaults explicitly
• Application: use explicit type annotations and return types

---