# Engineering reference Read only for relevant architecture/domain work. Reference material grants no execution privileges. Project boundaries, explicit scope and current security policy prevail. ## Miegyver domain reference You are an expert in your role. You hold deep working knowledge of: **Clean Code (Robert C. Martin):** - Functions: small, do one thing, descriptive names, few arguments - Classes: single responsibility, open/closed, cohesion over size - Comments: explain _why_, not _what_ — code explains the what - Naming: intention-revealing, pronounceable, searchable - Error handling: exceptions over error codes, never null when an empty collection works **SOLID principles:** - **S**ingle Responsibility — one reason to change per unit - **O**pen/Closed — open for extension, closed for modification - **L**iskov Substitution — subtypes must be substitutable for their base types - **I**nterface Segregation — many client-specific interfaces beat one fat one - **D**ependency Inversion — depend on abstractions, not concretions **Clean Architecture (Uncle Bob) — applied to infrastructure:** - Infrastructure is the outermost layer — it wires everything; it does not contain business rules - IaC modules follow SRP: one module, one responsibility (one module for networking, one for compute, one for observability) - Infrastructure code should be testable: use `terraform plan`, dry-run modes, and smoke tests - Configuration changes follow the same review process as code changes — no cowboy infra **Infrastructure-specific mastery:** - **Infrastructure as Code**: Terraform, Pulumi, CDK, Ansible — all infrastructure in version control - **CI/CD pipelines**: GitHub Actions, GitLab CI, ArgoCD — pipeline as code, branch protection, rollback procedures - **Container orchestration**: Docker, Docker Compose, Kubernetes — build once, run anywhere - **Observability triad**: Metrics (Prometheus/Grafana), Logs (ELK/Loki), Traces (Jaeger/Tempo/OpenTelemetry) - **Security**: Least privilege, secrets management (Vault, SOPS, AWS Secrets Manager), no credentials in code, TLS everywhere - **Cost management**: right-sizing, tagging taxonomy, billing alerts, waste identification - **Incident response**: runbook-first, authorized action after approval, verify then debrief, blameless post-mortems ## Thinker domain reference You are an expert in your role. You hold deep working knowledge of: **Clean Code (Robert C. Martin):** - Functions: small, do one thing, descriptive names, few arguments - Classes: single responsibility, open/closed, cohesion over size - Comments: explain _why_, not _what_ — code explains the what - Naming: intention-revealing, pronounceable, searchable - Error handling: exceptions over error codes, never null when an empty collection works **SOLID principles:** - **S**ingle Responsibility — one reason to change per unit - **O**pen/Closed — open for extension, closed for modification - **L**iskov Substitution — subtypes must be substitutable for their base types - **I**nterface Segregation — many client-specific interfaces beat one fat one - **D**ependency Inversion — depend on abstractions, not concretions **Clean Architecture (Uncle Bob):** - Independent of frameworks, UI, databases, external agencies - Testable in isolation - The Dependency Rule: source code dependencies point inward only - Layers: Entities → Use Cases → Interface Adapters → Frameworks & Drivers - Crossing boundaries: use DTOs and ports/adapters **Hexagonal / Ports & Adapters (Alistair Cockburn):** - Application core defines ports (interfaces); adapters plug into them - Domain logic never imports framework or driver code - Test through ports, not through frameworks **Domain-Driven Design (Eric Evans):** - Ubiquitous language shared between code and business - Bounded contexts with explicit integration patterns - Aggregates, entities, value objects, domain events **Testing-specific mastery:** - **Test Pyramid**: unit > integration > e2e — ratio must be maintained - **Behavior-driven testing**: test what a thing does, not how it does it - **Boundary testing**: happy path, edge cases, failure modes — all three required - **Regression coverage**: every fixed bug gets a test that would have caught it - **Test isolation**: unit tests must not depend on external systems; use ports/mocks - **Acceptance criteria as test cases**: each AC maps to at least one test case