{
  "instructions": [
    {
      "instruction": "Dependencies must point inward only — inner layers (entities, use cases) must never import from outer layers (adapters, frameworks)",
      "original_snippets": "Dependency Rule: Dependencies point inward only. Inner layers know nothing about outer layers.",
      "relevant_when": "reviewing or designing module import structure",
      "why_given": "new knowledge"
    },
    {
      "instruction": "Entities must be pure business objects — no ORM decorators, framework types, or infrastructure imports allowed in the entity layer",
      "original_snippets": "Entities remain pure (no framework or infrastructure imports). BAD: Entity imports ORM decorators, framework types. GOOD: Entities are plain objects; adapters handle framework mapping.",
      "relevant_when": "defining domain entity classes",
      "why_given": "new knowledge"
    },
    {
      "instruction": "Use cases must define explicit input/output ports as interfaces and depend on repository abstractions, never on concrete implementations",
      "original_snippets": "Use cases: Have one responsibility, depend on abstractions (ports), not concrete implementations. BAD: Use case instantiates concrete PostgresRepository. GOOD: Use case depends on IRepository interface; DI provides implementation.",
      "relevant_when": "designing use case classes or orchestration logic",
      "why_given": "preference"
    },
    {
      "instruction": "Controllers must be thin — they translate HTTP input to use case input and use case output to HTTP response; no business logic in controllers",
      "original_snippets": "BAD: Controller validates, calculates, and persists data. GOOD: Controller calls use case; use case orchestrates business logic.",
      "relevant_when": "writing HTTP controllers or route handlers",
      "why_given": "preference"
    },
    {
      "instruction": "Circular dependencies between modules are forbidden — extract a shared contract/interface and invert the dependency",
      "original_snippets": "NEVER allow circular dependencies. BAD: Module A imports B and B imports A. GOOD: Extract shared contract/module and invert dependencies.",
      "relevant_when": "resolving circular import errors or reviewing module structure",
      "why_given": "preference"
    },
    {
      "instruction": "Framework and infrastructure code (ORM, Express, DI containers) must live in the outermost layer — the domain must remain framework-free",
      "original_snippets": "Keep frameworks (Express, NestJS, TypeORM, React) in the infrastructure/adapter layer. Domain remains framework-free.",
      "relevant_when": "placing framework configuration or integration code",
      "why_given": "preference"
    },
    {
      "instruction": "NEVER design architectural boundaries for imagined future requirements — only introduce a boundary when the current need justifies the cost",
      "original_snippets": "NEVER design boundaries for imagined future requirements. BAD: Add full hexagonal architecture 'in case' of future DB migration. GOOD: Solve current need; refactor when trigger appears (YAGNI).",
      "relevant_when": "deciding whether to introduce a new architectural boundary",
      "why_given": "preference"
    },
    {
      "instruction": "Document significant boundary decisions in an ADR with rationale, alternatives, chosen option, and risks",
      "original_snippets": "Document Boundary Decisions — ADR with rationale, alternatives, and risks.",
      "relevant_when": "introducing a new service boundary or major architectural change",
      "why_given": "preference"
    }
  ]
}