jdi-cli 0.1.1 → 0.1.3

package/core/skills/ddd/SKILL.md

@@ -0,0 +1,140 @@
+---
+name: ddd
+description: Domain-Driven Design (Eric Evans). Strategic patterns (Bounded Context, Ubiquitous Language, Context Map) plus tactical patterns (Aggregates, Entities, Value Objects, Domain Services, Repositories, Domain Events). Language-agnostic rigid rules. Mutually exclusive with The Method, Clean Architecture, Hexagonal, Onion, Vertical Slice.
+type: skill
+applies_to: |
+  Loaded by doer and reviewer when PROJECT.md `Code Design` is `DDD`.
+  Inviolable design rules. Doer applies during creation. Reviewer enforces at gate 5.
+loaded_by:
+  - jdi-doer-{slug}
+  - jdi-reviewer-{slug}
+runtime_overrides:
+  antigravity:
+    triggers:
+      - "DDD"
+      - "Domain-Driven Design"
+      - "bounded context"
+      - "aggregate root"
+      - "ubiquitous language"
+---
+
+# Skill: Domain-Driven Design (DDD)
+
+Rigid, inviolable rules from Eric Evans's *Domain-Driven Design* and Vaughn Vernon's *Implementing DDD*. The domain is the center of the system. Persistence, UI, frameworks, and external integrations are peripheral details.
+
+DDD is the ONLY allowed design when PROJECT.md `Code Design: LOCKED: DDD`. Do not introduce The Method's Managers/Engines/ResourceAccess, Clean Architecture's concentric layers as a structural primary, Hexagonal port terminology as the primary structure, Onion shells, or Vertical Slice handlers as the primary structure.
+
+## Strategic rules (inviolable)
+
+1. **Bounded Context (BC) is the unit of model isolation.** Every BC owns its own model, its own ubiquitous language, its own database schema, and its own deployment unit (where feasible). A model is meaningful only inside its BC.
+2. **Each BC must be named.** Anonymous BCs do not exist. The name appears in the codebase (folder, namespace, module, package).
+3. **Ubiquitous Language (UL) is contractual within a BC.** The same word means exactly one thing inside the BC. Synonyms are forbidden. Code, tests, docs, conversations, and database column names share the UL terminology.
+4. **No shared model across BCs.** When two BCs reference the same real-world concept, each has its own model class for it. Cross-BC reuse of classes is forbidden.
+5. **Cross-BC interaction follows a Context Map relationship.** Every integration between BCs is explicitly typed as exactly one of: Shared Kernel, Customer/Supplier, Conformist, Anticorruption Layer (ACL), Open Host Service (OHS), Published Language (PL), Partnership, Separate Ways. Undeclared integration is forbidden.
+6. **Anticorruption Layer (ACL) is required when integrating with a legacy or external model.** Foreign models do not leak into a BC.
+7. **Core Domain is identified explicitly.** Other BCs are classified as Supporting Subdomain or Generic Subdomain. The Core Domain receives the highest engineering investment and is never outsourced or replaced by a generic library.
+8. **Domain knowledge does not leak into Generic Subdomains.** Generic Subdomain code (Identity, Logging, Notification) must be reusable across projects without domain assumptions.
+
+## Tactical rules (inviolable)
+
+### Aggregate
+
+1. **An Aggregate has exactly one Root.** All external access goes through the Root. References to inner entities from outside the Aggregate are forbidden.
+2. **The Aggregate Root enforces all invariants of the Aggregate.** No partial state may be observed by other Aggregates or by Application Services.
+3. **One transaction modifies at most one Aggregate instance.** Multi-aggregate consistency is achieved by Domain Events, not by enclosing transactions.
+4. **Aggregates reference other Aggregates only by identifier (ID), never by direct object reference.** Cross-aggregate navigation through references is forbidden.
+5. **Aggregate boundaries are designed around invariants and transactional consistency, never around UI screens or convenience.**
+6. **Aggregates must be small.** If an Aggregate contains a collection that grows unbounded, the design is wrong and must be split.
+
+### Entity vs Value Object
+
+7. **An Entity has identity that persists across state changes.** Equality is by identity, never by attributes.
+8. **A Value Object is immutable and identity-less.** Equality is by attributes. Mutating a Value Object is forbidden — replace, do not modify.
+9. **Prefer Value Objects.** When a concept has no identity, model it as a Value Object. Default to Value Object; promote to Entity only when identity is required.
+10. **Value Objects must be self-validating.** Construction of a Value Object with invalid state must fail at construction time.
+
+### Domain Service
+
+11. **A Domain Service exists only when an operation does not belong to any Entity or Value Object.** If the operation can fit on an Entity/VO, it must live there.
+12. **Domain Services are stateless and named with a Ubiquitous Language verb-noun expressing a domain operation, not a technical action.**
+13. **Domain Services contain domain logic only.** Persistence, transactions, messaging, and orchestration of use cases live in Application Services.
+
+### Repository
+
+14. **One Repository per Aggregate Root.** No repository per Entity that is not a Root. No "generic" repository shared across Aggregates.
+15. **Repository interface lives with the domain model, not with persistence.** Persistence implementation lives outside the domain layer.
+16. **Repositories return whole Aggregates, never partial state.** A method returning a piece of an Aggregate (single inner entity, partial fields) is forbidden.
+17. **Queries that span multiple Aggregates or return projections do not use Repositories.** Use a dedicated Query/ReadModel pattern (CQRS-style). Reads and writes may diverge structurally.
+
+### Domain Event
+
+18. **Domain Events are immutable, past-tense facts.** Names are past tense (e.g., "OrderPlaced", "PaymentRefused"). Mutating a Domain Event is forbidden.
+19. **Domain Events are emitted by Aggregates.** Application Services do not invent domain events.
+20. **Domain Events carry only the data needed to react to the fact.** Do not embed entire Aggregate state.
+21. **Cross-Aggregate consistency uses Domain Events, not synchronous calls between Aggregates.**
+
+### Application Service
+
+22. **Application Services orchestrate use cases.** They load Aggregates via Repositories, invoke domain methods, persist changes, and emit Domain Events. They contain no business rules.
+23. **Application Services are thin.** A method longer than orchestration of 5-8 domain calls is a smell; extract domain logic back to the domain.
+24. **Application Services do not return domain entities directly to UI.** Return DTOs or projections.
+
+### Domain layer purity
+
+25. **The Domain Layer depends on nothing external.** No framework, ORM, HTTP, file system, or messaging library is referenced from domain code.
+26. **Persistence-ignorant domain.** Entities/Aggregates do not inherit from ORM base classes, do not have persistence annotations leaking semantic meaning, and do not know about transactions.
+27. **No anemic models.** Entities and Value Objects own their behavior. A class with only getters/setters and no business methods is forbidden in the domain layer.
+28. **No "Manager", "Helper", "Util", "Processor" classes in the domain layer.** These names betray missing domain concepts.
+
+## Modeling rules (inviolable)
+
+1. The model in code must match the model in conversation with domain experts. If they diverge, the code is wrong.
+2. Names come from the Ubiquitous Language. Technical names ("Data", "Info", "Object", "Item", "Entry") are forbidden in the domain layer.
+3. New domain concepts are added to the Ubiquitous Language before they are added to the code.
+4. Domain experts must recognize the names, intents, and invariants encoded in the domain layer.
+
+## Forbidden patterns (inviolable)
+
+- **Generic Repository** spanning multiple Aggregates (`Repository<T>`) is forbidden.
+- **Lazy-loaded navigation across Aggregates** is forbidden.
+- **Transactions spanning multiple Aggregates** are forbidden.
+- **Returning Entities from a query that crosses Aggregates** is forbidden — use a read model.
+- **CRUD-only Application Services** ("CreateUser", "UpdateUser") with no domain semantics are a smell; reframe as domain operations ("RegisterCustomer", "DeactivateAccount") when meaning exists.
+- **Anti-corruption layer absence** when consuming an external/legacy model is a violation.
+- **Sharing entities across Bounded Contexts** is forbidden.
+- **DTO leaking into the domain layer** is forbidden.
+
+## Reviewer enforcement (gate 5)
+
+Reviewer rejects (BLOCKED) when:
+- Domain code references a framework / ORM / HTTP / messaging library.
+- An Aggregate is mutated from outside its Root.
+- A single transaction modifies more than one Aggregate instance.
+- A Repository serves multiple Aggregate Roots, or returns partial state.
+- Cross-Aggregate references are by object instead of by ID.
+- A Domain Service performs persistence, transactions, or messaging.
+- An Application Service contains business rules.
+- An Entity / VO has only getters/setters (anemic).
+- Two Bounded Contexts share the same model class.
+- An integration with an external system has no Anticorruption Layer.
+
+Reviewer warns (APPROVED_WITH_WARNINGS) when:
+- A class is named "Manager" / "Helper" / "Util" / "Processor" in the domain layer.
+- A Value Object is mutable.
+- An Aggregate exposes its internal collections directly.
+- A Domain Event is named in present/future tense.
+- The Ubiquitous Language used in code disagrees with the language in PROJECT.md or CONTEXT.md.
+
+## Anti-patterns
+
+- Anemic Domain Model
+- Generic Repository pattern
+- God Aggregate (entire schema under one Root)
+- Smart UI bypassing domain
+- Domain services that orchestrate use cases (those are Application Services)
+- "Service layer" without distinguishing Domain Service vs Application Service
+- Database-first design driving Aggregate shape
+
+## Outputs
+
+Does NOT produce own files. Modifies parent agent's structural decisions during code authoring and review.

package/core/skills/hexagonal/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: hexagonal
+description: Hexagonal Architecture / Ports and Adapters (Alistair Cockburn). Application core in the center, surrounded by Ports (interfaces owned by the core) and Adapters (implementations). Driving (primary) vs Driven (secondary) sides. Language-agnostic rigid rules. Mutually exclusive with The Method, DDD, Clean Architecture, Onion, Vertical Slice.
+type: skill
+applies_to: |
+  Loaded by doer and reviewer when PROJECT.md `Code Design` is `Hexagonal`.
+  Inviolable design rules. Doer applies during creation. Reviewer enforces at gate 5.
+loaded_by:
+  - jdi-doer-{slug}
+  - jdi-reviewer-{slug}
+runtime_overrides:
+  antigravity:
+    triggers:
+      - "Hexagonal"
+      - "Ports and Adapters"
+      - "Alistair Cockburn"
+      - "driving adapter"
+      - "driven adapter"
+---
+
+# Skill: Hexagonal Architecture (Ports and Adapters)
+
+Rigid, inviolable rules from Alistair Cockburn's Ports and Adapters. The application is a **core** isolated from the outside world by **ports** (interfaces) and **adapters** (implementations).
+
+Hexagonal is the ONLY allowed design when PROJECT.md `Code Design: LOCKED: Hexagonal`. Do not use The Method, DDD as primary structure, Clean Architecture's 4-layer terminology as primary structure, Onion shells, or Vertical Slice feature folders as primary structure.
+
+## Mandatory structure
+
+The system consists of exactly three structural elements:
+
+1. **Application Core (the hexagon)** — domain model + application logic. Knows nothing about technology, protocols, or external systems. The core is the only place where business rules exist.
+2. **Ports** — interfaces **owned by the core** that declare what the core needs from the outside (driven ports) or what the outside can ask the core to do (driving ports). A port is an abstract contract; it has no implementation in the core.
+3. **Adapters** — implementations of ports living outside the core. Adapters translate between the technology-specific outside world (HTTP, DB, queue, file, UI) and the technology-free core.
+
+Every code unit belongs to exactly one of: Core, Port (still inside the core's package), or Adapter. A unit that does not fit must be redesigned.
+
+## Driving vs Driven (mandatory)
+
+1. **Driving (primary) side** — the side that initiates interaction with the core. UI, HTTP controllers, CLI handlers, scheduled job triggers, integration tests. Driving adapters invoke driving ports.
+2. **Driven (secondary) side** — the side the core delegates to. Persistence, message bus, external APIs, file system, email, cache. The core invokes driven ports, which are implemented by driven adapters.
+3. **Driving port** is an interface that exposes the core's capabilities to the outside. **Driven port** is an interface declared by the core that the outside must satisfy.
+4. **Direction of dependency: adapters depend on ports; ports live in the core; the core depends on nothing infrastructural.**
+
+## Inviolable rules
+
+### Core purity
+
+1. The core has zero imports from any framework, ORM, HTTP library, vendor SDK, file system API, or transport library.
+2. The core defines its own types for inputs and outputs to ports. Adapter types (HTTP request, ORM model, queue message) do not appear in core code.
+3. The core does not know the identity of any adapter. It interacts only with ports.
+4. The core does not perform I/O. All I/O happens through driven ports.
+5. The core is fully testable without any adapter. If a unit test of the core requires spinning up DB / HTTP / queue, the design is wrong.
+
+### Ports
+
+6. A port is an interface. It has no logic.
+7. Ports live in the core's package / module. They are not in an "infrastructure" or "adapters" package.
+8. The core defines a port; the adapter implements it. A port defined outside the core, or implemented in the core, is forbidden.
+9. Driving ports name capabilities of the core in domain language (e.g., `PlaceOrder`, `RenewSubscription`). Driven ports name dependencies in domain language (e.g., `OrderRepository`, `NotificationSender`).
+10. Port methods receive and return only types defined inside the core. They do not receive HTTP requests, ORM entities, or framework-specific types.
+
+### Adapters
+
+11. An adapter implements exactly one port (driving or driven). An adapter that mixes driving and driven roles is forbidden.
+12. A driving adapter translates an external trigger (HTTP request, CLI command, message, schedule) into a core-defined input and invokes a driving port.
+13. A driven adapter translates a core-defined call into a technology-specific action (SQL query, HTTP call, file write, queue publish) and translates the result back into core-defined output.
+14. Adapters contain only translation and I/O. Business rules in an adapter are forbidden — they must move into the core.
+15. Adapters never call other adapters directly. Coordination between adapters happens through the core via a driving adapter → core → driven adapter sequence.
+16. Adapters never call the core's internal classes directly. They go through ports.
+
+### Composition
+
+17. The Composition Root assembles adapters and injects them into the core at startup. The core does not construct its own adapters.
+18. Replacing an adapter (e.g., swapping PostgreSQL for MongoDB, REST for gRPC) must not require changes inside the core. If it does, the port is leaking.
+19. Multiple adapters may implement the same port. The core does not know how many.
+20. Test adapters (fakes, in-memory implementations) are first-class adapters and must use the same ports as production adapters. The core cannot have a "test-only" code path.
+
+## Forbidden patterns (inviolable)
+
+- **Framework types crossing into the core.** No HTTP request type, no ORM entity, no vendor SDK type referenced in core code.
+- **Business rules in adapters.** A driven adapter computing a price, a driving adapter validating a domain rule — both forbidden.
+- **Adapters calling adapters.** Adapter coordination outside the core is forbidden.
+- **Core code instantiating an adapter.** Construction happens in the Composition Root.
+- **Ports defined outside the core.** A port placed in an "infrastructure" module is a violation.
+- **Anemic core.** A core without behavior is a violation — adapters become a leak path for rules.
+- **A driving port returning a framework-specific type** (a port returning `HttpResponse` is wrong).
+- **Driven ports leaking persistence concepts** (a port named `SqlUserRepository` is wrong; it must be domain-named).
+- **Mixed-role adapter** (one adapter both responding to HTTP and writing to DB).
+- **Bypassing ports** by injecting an adapter directly where a port should appear.
+- **Concentric layer terminology** ("Entities layer", "Use Cases layer", "Application Services layer") imposed as the primary structure — Hexagonal organizes by core/ports/adapters, not by concentric layers.
+
+## Naming conventions
+
+- Driving ports: domain capability verbs (`PlaceOrder`, `RegisterCustomer`).
+- Driven ports: dependency names in domain language (`OrderRepository`, `EmailSender`, `PaymentGateway`).
+- Adapters: technology-qualified (`HttpPlaceOrderAdapter`, `PostgresOrderRepositoryAdapter`, `SmtpEmailSenderAdapter`).
+- The core never references a name containing a technology word.
+
+## Reviewer enforcement (gate 5)
+
+Reviewer rejects (BLOCKED) when:
+- Core code imports a framework / ORM / HTTP / vendor SDK / file-system type.
+- A port is defined outside the core or implemented inside the core.
+- A port method's signature mentions a framework-specific type.
+- An adapter contains business logic.
+- An adapter calls another adapter directly.
+- The core instantiates an adapter.
+- A driven port name leaks a persistence technology.
+- A driving adapter returns the result of a port call without translating from a core type to an external type.
+
+Reviewer warns (APPROVED_WITH_WARNINGS) when:
+- An adapter file is doing more translation than necessary (smell: complex mapping suggesting hidden rules).
+- A port is implemented by a single adapter and is unlikely ever to vary (still allowed — keep the port).
+- A core class has no behavior (anemic).
+- Composition wiring is scattered instead of centralized in a Composition Root.
+
+## Anti-patterns
+
+- "Service" layer between core and adapters (no such thing in Hexagonal)
+- Repository implemented inside the core (must be a port)
+- Use Case classes shaped after Clean Architecture's Use Case layer (the structure is core/ports/adapters)
+- Ports tied to a transport (e.g., `RestOrderPort`) — ports are domain-shaped, adapters are transport-shaped
+- "Domain Services" terminology imported wholesale from DDD as the primary structure (acceptable internal to the core when meaningful, but does not replace the hexagonal primary structure)
+
+## Outputs
+
+Does NOT produce own files. Modifies parent agent's structural decisions during code authoring and review.

package/core/skills/onion/SKILL.md

@@ -0,0 +1,133 @@
+---
+name: onion
+description: Onion Architecture (Jeffrey Palermo). Concentric shells with the Domain Model at the absolute center. Dependencies invert across shells - outer depends on inner, inner knows nothing of outer. Language-agnostic rigid rules. Mutually exclusive with The Method, DDD, Clean Architecture, Hexagonal, Vertical Slice.
+type: skill
+applies_to: |
+  Loaded by doer and reviewer when PROJECT.md `Code Design` is `Onion`.
+  Inviolable design rules. Doer applies during creation. Reviewer enforces at gate 5.
+loaded_by:
+  - jdi-doer-{slug}
+  - jdi-reviewer-{slug}
+runtime_overrides:
+  antigravity:
+    triggers:
+      - "Onion Architecture"
+      - "Jeffrey Palermo"
+      - "domain at the center"
+      - "concentric shells"
+---
+
+# Skill: Onion Architecture
+
+Rigid, inviolable rules from Jeffrey Palermo's Onion Architecture. The system is a series of **concentric shells** with the **Domain Model at the absolute center**. Outer shells depend on inner shells; the inverse is forbidden.
+
+Onion is the ONLY allowed design when PROJECT.md `Code Design: LOCKED: Onion`. Do not use The Method, DDD as primary structure, Clean Architecture's 4-named layers, Hexagonal port/adapter terminology as primary structure, or Vertical Slice feature folders as primary structure.
+
+## The shells (mandatory order from center outward)
+
+1. **Domain Model** — entities and value objects expressing the business state. No behavior dependent on infrastructure. The absolute center.
+2. **Domain Services** — domain operations that do not belong to a single entity/value object. Pure domain logic. Stateless.
+3. **Application Services** — orchestrate use cases. Coordinate Domain Services and Domain Model. Define interfaces for infrastructure dependencies (repository contracts, external system contracts).
+4. **Infrastructure** — persistence implementations, external system clients, UI, tests, framework bindings. The outermost shell.
+
+Every code unit belongs to exactly one of these 4 shells. A unit that does not fit must be redesigned.
+
+## The Dependency Direction (inviolable)
+
+**Dependencies point inward.** Every shell may depend on shells closer to the center; no shell may depend on shells farther from the center.
+
+1. Domain Model depends on nothing else in the system.
+2. Domain Services depend on Domain Model only.
+3. Application Services depend on Domain Model and Domain Services.
+4. Infrastructure depends on Application Services, Domain Services, and Domain Model.
+5. Names defined in Infrastructure (ORM types, framework types, vendor SDK types) never appear in any inner shell.
+
+## Inversion across infrastructure (inviolable)
+
+1. **Application Services define the interfaces** (repository contracts, external system contracts) they require. These interfaces live in Application Services or Domain Services — never in Infrastructure.
+2. **Infrastructure implements those interfaces.** The implementation class lives in Infrastructure. The interface lives inward.
+3. **The Composition Root wires interfaces to implementations.** The Composition Root is part of Infrastructure (or a separate startup module that depends on Infrastructure). Inner shells never construct Infrastructure types.
+
+## Domain Model rules
+
+1. The Domain Model contains only entities and value objects in domain language.
+2. The Domain Model has no annotations, no inheritance from framework base classes, no persistence concerns, no serialization concerns.
+3. The Domain Model is not anemic. Behavior that belongs to an entity lives on that entity. Behavior that belongs to no single entity lives in Domain Services.
+4. Value objects are immutable. Replacing is the only mutation pattern.
+5. The Domain Model does not know how it is persisted, displayed, or transmitted.
+
+## Domain Services rules
+
+6. Domain Services are stateless. They contain pure domain logic that does not naturally belong to a single Entity or Value Object.
+7. Domain Services depend on the Domain Model only. They never call repositories, infrastructure, or Application Services.
+8. Domain Services do not perform I/O.
+9. Names of Domain Services are domain operations, not technical operations.
+
+## Application Services rules
+
+10. Application Services orchestrate use cases. One Application Service method = one application-level operation.
+11. Application Services declare the interfaces (repository, gateway, sender, publisher) they require. These interfaces live with Application Services (or in Domain Services when their abstraction is purely domain-driven).
+12. Application Services do not contain business rules — they coordinate. Business rules live in Domain Model and Domain Services.
+13. Application Services do not import any Infrastructure class. They depend on the interfaces they themselves declare.
+14. Application Services receive input DTOs and return output DTOs (or void). They do not return Domain Model entities to outer shells when those would leak persistence concerns.
+
+## Infrastructure rules
+
+15. Infrastructure implements interfaces declared by inner shells. It does not introduce interfaces of its own that inner shells consume.
+16. Infrastructure contains: persistence (ORM mappings, repositories), HTTP/UI controllers, message bus clients, file system access, vendor SDK calls, scheduled job handlers, and the Composition Root.
+17. Infrastructure does not contain business rules.
+18. Infrastructure classes are named with their technology when the technology is the encapsulated concern (e.g., `SqlOrderRepository`, `HttpPaymentGateway`).
+19. Two infrastructure classes do not call each other to fulfill a use case. Coordination happens via Application Services.
+
+## Forbidden patterns (inviolable)
+
+- **Inner shell referencing outer shell.** Domain Model referencing Application Services or Infrastructure is forbidden. Domain Services referencing Application Services or Infrastructure is forbidden. Application Services referencing Infrastructure (concrete classes) is forbidden.
+- **Persistence annotations or framework types in the Domain Model.**
+- **Repository interface placed in Infrastructure.** The interface must live inward (Application Services or Domain Services).
+- **Domain Services performing I/O.**
+- **Application Services containing business rules.**
+- **Infrastructure-defined interfaces consumed by inner shells.**
+- **Skipping a shell** (Infrastructure code calling Domain Model methods directly when an Application Service exists for that use case; or controller calling repository directly bypassing Application Services).
+- **Anemic Domain Model.**
+- **CRUD-only Application Services** with no application semantics.
+- **Cross-shell reach-around** (Infrastructure A calling Infrastructure B to fulfill a use case without going through an Application Service).
+
+## Naming conventions
+
+- Domain Model classes: domain nouns (`Customer`, `Order`, `Subscription`).
+- Domain Services: domain verb-noun (`OrderPricingPolicy`, `SubscriptionRenewalRules`).
+- Application Services: application-level operations (`RegisterCustomerService`, `RenewSubscriptionService`).
+- Interfaces consumed by Application Services: domain-meaningful (`IOrderRepository`, `IPaymentGateway`, `INotificationSender`).
+- Infrastructure classes: technology-qualified (`SqlOrderRepository`, `StripePaymentGateway`, `SmtpNotificationSender`).
+
+## Reviewer enforcement (gate 5)
+
+Reviewer rejects (BLOCKED) when:
+- Domain Model, Domain Services, or Application Services import a framework / ORM / HTTP / vendor SDK type.
+- A repository or external-system interface is declared in Infrastructure and consumed inward.
+- An inner shell file imports an outer shell file.
+- Application Services contain business rules that belong on Domain Model or Domain Services.
+- Domain Services perform I/O or call a repository.
+- Infrastructure classes coordinate use cases instead of being driven by Application Services.
+- Infrastructure introduces an interface that inner shells depend on.
+
+Reviewer warns (APPROVED_WITH_WARNINGS) when:
+- Domain Model is anemic.
+- Application Services are named after CRUD verbs without semantic meaning.
+- Composition Root is fragmented across multiple infrastructure modules.
+- An entity is mutable in places where a value object would be correct.
+
+## Anti-patterns
+
+- "Service" layer mixing Domain Services with Application Services indistinguishably
+- Generic repository (`IRepository<T>`) declared at the Infrastructure level
+- Domain Model classes inheriting from an ORM base
+- Domain Services calling repositories
+- Application Services holding state across calls
+- Direct controller-to-repository wiring
+- Infrastructure types appearing as parameters to inner-shell methods
+- "Onion" framing used to disguise Clean Architecture, Hexagonal, or DDD — the rule is the inward dependency direction and the Domain Model at the absolute center
+
+## Outputs
+
+Does NOT produce own files. Modifies parent agent's structural decisions during code authoring and review.

package/core/skills/the-method/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: the-method
+description: The Method (Juval Löwy, "Righting Software"). Volatility-based decomposition with universal hierarchy (Clients, Managers, Engines, ResourceAccess, Resources, Utilities). Strict communication rules. Language-agnostic. Mutually exclusive with DDD, Clean Architecture, Hexagonal, Onion, Vertical Slice.
+type: skill
+applies_to: |
+  Loaded by doer and reviewer when PROJECT.md `Code Design` is `The Method`.
+  Inviolable design rules. Doer applies during creation. Reviewer enforces at gate 5.
+loaded_by:
+  - jdi-doer-{slug}
+  - jdi-reviewer-{slug}
+runtime_overrides:
+  antigravity:
+    triggers:
+      - "The Method"
+      - "Juval Lowy"
+      - "Righting Software"
+      - "volatility decomposition"
+      - "Universal Hierarchy"
+---
+
+# Skill: The Method (Juval Löwy)
+
+Rigid, inviolable design rules from Juval Löwy's *Righting Software*. Decompose by **volatility**, not functionality. Single architecture in the system — do not mix with any other code design.
+
+The Method is the ONLY allowed design when PROJECT.md `Code Design: LOCKED: The Method`. Do not introduce DDD aggregates, Clean Architecture use cases, Hexagonal ports, Onion shells, or Vertical Slice handlers. Do not invent a hybrid.
+
+## Core principle (inviolable)
+
+**Decompose the system by axes of volatility, never by functionality.**
+
+A component is justified only when it encapsulates an independent reason to change. Two pieces of code that change for the same reason belong together. Two pieces that change for different reasons must be separated even if they currently look identical.
+
+If a component has no clear volatility it encapsulates, it must not exist.
+
+## The Universal Hierarchy (mandatory)
+
+Every system has exactly these 5 architectural categories plus 1 cross-cutting category. No other category may be invented.
+
+1. **Clients** — entry points. UI, CLI, public API endpoints, scheduled triggers, test harnesses. Volatility: presentation, protocol, channel.
+2. **Managers** — own a use case end-to-end. Sequence the work. Hold the workflow. Volatility: business workflow, use case orchestration.
+3. **Engines** — stateless business algorithms. Pure rules, calculations, validation logic. Volatility: business algorithm, formula, policy.
+4. **ResourceAccess** — only path to a Resource. Hides the technology of the data store. Volatility: data access technology.
+5. **Resources** — the actual data store / external system / queue / cache. Volatility: storage technology, vendor, schema.
+
+Cross-cutting (callable from any layer):
+
+6. **Utilities** — Security, Logging, Diagnostics, Hosting, Configuration, Localization, Pub/Sub bus, Identity. Stateless cross-cutting concerns. Volatility: infrastructure technology.
+
+Every code unit produced MUST belong to exactly one of these categories. If you cannot decide its category, the unit is wrong and must be redesigned.
+
+## Communication rules (inviolable)
+
+The hierarchy is strictly directed. Communication that violates these rules is a defect, regardless of how convenient it appears.
+
+1. **Clients call Managers only.** Clients do not call Engines, ResourceAccess, Resources, or other Clients.
+2. **Managers call Engines and ResourceAccess.** Managers may also call Utilities.
+3. **Managers do not call Managers directly.** Manager-to-Manager communication, when required, goes through a **Queue** (publish/subscribe via the Utility bus). Never synchronous Manager-to-Manager.
+4. **Engines do not call Engines.** Composition of engines happens in the Manager.
+5. **Engines do not call ResourceAccess.** The Manager pulls data via ResourceAccess and passes it into the Engine.
+6. **Engines and ResourceAccess do not call Clients.** No upward calls.
+7. **ResourceAccess is the only component allowed to touch a Resource.** Nothing else (no Manager, no Engine, no Client, no Utility) touches a Resource directly.
+8. **Resources do not call anything.** They are passive.
+9. **Utilities are callable by any layer, but do not contain business logic.** Utilities never call Managers, Engines, or ResourceAccess.
+10. **No skip-level calls upward.** Lower layers never call higher layers synchronously.
+11. **Calls fan out, never fan in across the same layer synchronously.** No sideways synchronous calls within Managers or within Engines.
+
+## Volatility rules (inviolable)
+
+1. A component exists only to **encapsulate one axis of volatility**. State it explicitly.
+2. The component's public surface must change only when its encapsulated volatility changes. If a change to an unrelated axis requires editing the component, the decomposition is wrong.
+3. The more volatile the area, the deeper inside the architecture it lives. The more stable, the closer to the edges.
+4. **Functional decomposition is forbidden.** Naming components after features ("OrderManager", "CustomerEngine") is allowed only when the feature itself is a volatility boundary. Naming components after operations ("CreateOrder", "ValidateCustomer") is forbidden.
+5. **Naming after volatility, not noun.** Prefer `PricingEngine` (algorithm volatility) over `OrderService` (feature). Prefer `OrderRepository` only if data-access technology is the encapsulated volatility.
+
+## Composability rules
+
+1. Every Manager must be composable. Adding a new Client (new UI, new API) must not require touching the Manager.
+2. Engines and ResourceAccess components must be reusable across Managers. If they cannot be reused, the volatility encapsulation is wrong.
+3. The system must support adding a new use case by adding 1 Manager (and possibly 1 Client method) without modifying any Engine, ResourceAccess, Resource, or Utility.
+
+## Forbidden patterns (inviolable)
+
+- **No domain-driven aggregates, anti-corruption layers, or bounded contexts** — that is DDD.
+- **No use cases as a separate layer** — Managers ARE the use cases. Do not create a "UseCase" layer on top of Managers.
+- **No ports & adapters / hexagonal terminology** — ResourceAccess plays the role of adapter for Resources. Do not introduce additional port/adapter layers.
+- **No vertical slices** — code is organized by category, never by feature folder.
+- **No Onion shells.** No "domain core" layer above Engines.
+- **No Repository pattern named after entities** ("UserRepository", "OrderRepository"). ResourceAccess is named after the **resource technology and its volatility**, not after a domain entity. Acceptable: `BillingDataAccess`, `CatalogStore`. Forbidden: `OrderRepository` if "Order" is not a volatility boundary.
+- **No anemic Engine** — an Engine without business logic is forbidden. An Engine with only getters/setters is a defect.
+- **No business logic in Clients.** Clients only translate input to a Manager call and present a Manager response.
+- **No business logic in ResourceAccess.** ResourceAccess maps technology to in-memory representations and nothing more.
+- **No business logic in Resources.** Stored procedures, triggers, or business-logic-bearing schemas are violations.
+- **No business logic in Utilities.** Utilities are infrastructure.
+- **No bypassing ResourceAccess** to touch a Resource (no ORM call in a Manager, no raw SQL in an Engine).
+- **No shared mutable state across components.** Engines are stateless. Managers hold transient workflow state only.
+
+## Mandatory acceptance per code unit
+
+Before any Manager / Engine / ResourceAccess / Client / Utility is committed, the author must be able to answer:
+
+1. Which one of the 6 categories does this belong to? (must be exactly one)
+2. What single axis of volatility does it encapsulate? (must be statable in 1 sentence)
+3. Which categories does it call? (must comply with the communication rules above)
+4. What change in the system would cause it to be edited? (must be the volatility it encapsulates, nothing else)
+5. Is it composable: can another Manager / Client be added without modifying this unit? (must be yes for non-Client units)
+
+A unit failing any answer must be redesigned before it ships.
+
+## Reviewer enforcement (gate 5)
+
+Reviewer rejects (BLOCKED) when:
+- A Client calls Engine / ResourceAccess / Resource directly.
+- A Manager calls another Manager synchronously.
+- An Engine calls another Engine.
+- An Engine calls ResourceAccess.
+- Any code outside ResourceAccess touches a Resource.
+- A Utility contains business logic.
+- A Repository / Service / Manager is named after a noun-entity instead of a volatility axis (warn first, block on second occurrence in the same PR).
+- The PR adds a new top-level category not in the universal hierarchy.
+- The PR splits code by feature folders instead of by category.
+
+Reviewer warns (APPROVED_WITH_WARNINGS) when:
+- A component's encapsulated volatility is not declared (missing 1-line statement at top of file or class).
+- An Engine has no behavior (anemic).
+- A new Manager was added without a Client-level entry point.
+
+## Anti-patterns
+
+- "Service layer" with mixed Manager + Engine responsibilities
+- "Helper" / "Util" classes containing business logic
+- Domain entity classes with both data and behavior bound to persistence
+- "Facade" components that hide multiple Managers behind a single class
+- ResourceAccess methods that return business-decided values instead of raw data
+- Cross-Manager transactions implemented via direct calls
+- Synchronous chains crossing 3+ layers
+
+## Outputs
+
+Does NOT produce own files. Modifies parent agent's structural decisions during code authoring and review.