Ten rulebooks · Three owners

Rules reference

A fast path into the canonical instructions used by Claude Code and Codex. Each topic has one primary owner, explicit handoffs, and conditions that prevent “always” or “never” advice from becoming accidental architecture.

01ArchitectureCapabilities, boundaries, ownership, dependency direction, and couplingArchitecture→02Dependency InjectionProvider forms, runtime tokens, scopes, ports, composition, and cycle repairArchitecture→03Error HandlingTaxonomy, stable contracts, multi-transport filters, deadlines, retries, privacy, and fatal failuresRuntime→04SecurityValidation, authentication, authorization, tokens, secrets, and abuse controlsRuntime→05PerformanceMeasurement, event-loop safety, database latency, memory, caching, and capacityRuntime→06TestingUnit, TestingModule, integration, contract, E2E, reliability, and load testsRuntime→07Database & ORMData ownership, mappings, migrations, transactions, queries, pools, and integrityArchitecture→08API DesignDTOs, response contracts, pagination, idempotency, versioning, and transportsRuntime→09MicroservicesExtraction gates, service contracts, data ownership, delivery, and operationsArchitecture→10DevOps & DeploymentCI/CD, containers, Kubernetes, supply chain, SRE, recovery, drain, and rolloutRuntime→

One rule model, not ten competing checklists

The labels are navigation; the three skills remain the ownership model. Architecture decides system and data boundaries. OOP and Design Patterns shapes collaborators inside those boundaries. Features, Scaling, and Performance implements runtime behavior and verifies it under load and failure.

Context beats slogans

Repository evidence, explicit contracts, security, data integrity, and measured runtime behavior outrank a generic rule. The rulebooks state their conditions and handoffs wherever a topic crosses skill boundaries.