jdi-cli 0.1.1 → 0.1.2

package/runtimes/antigravity/skills/hexagonal/SKILL.md

@@ -0,0 +1,118 @@
+---
+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.
+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/runtimes/antigravity/skills/jdi-architect/SKILL.md

@@ -389,13 +389,29 @@ Write to `.jdi/agents/jdi-reviewer-{slug}.md`.
 
 After writing doer/reviewer, inject `<skills_to_load>` block after `</role>` via Edit.
 
+**Code-design skill (mandatory) — resolve from `PROJECT.md.Code Design` (LOCKED value) using this mapping:**
+
+| Code Design (PROJECT.md) | Skill to load |
+|---|---|
+| The Method | `the-method` |
+| DDD | `ddd` |
+| Clean Architecture | `clean-architecture` |
+| Hexagonal | `hexagonal` |
+| Onion | `onion` |
+| Vertical Slice | `vertical-slice` |
+
+The resolved code-design skill is loaded by **both doer and reviewer**. Exactly one code-design skill is loaded. Never load two code-design skills simultaneously — the project uses exactly one design. If the mapping cannot resolve, abort with an error and ask the user to fix `PROJECT.md.Code Design`.
+
 **Doer — always:**
 ```markdown
 <skills_to_load>
 - solid — before creating classes/modules/interfaces. Detects god class, large switches, deep inheritance, dep on concretes.
+- {CODE_DESIGN_SKILL} — INVIOLABLE structural rules for the project's locked code design. Apply on every file created.
 </skills_to_load>
 ```
 
+Replace `{CODE_DESIGN_SKILL}` with the resolved entry from the mapping above (e.g. `the-method`, `ddd`, `clean-architecture`, `hexagonal`, `onion`, `vertical-slice`).
+
 If `has_frontend=true`, append:
 ```markdown
 - frontend-rules — when task touches .tsx/.vue/.svelte/.razor/.cshtml/.html/.twig/.erb/.blade.php. WCAG 2.2 AA + UX.
@@ -408,9 +424,12 @@ If `has_frontend=true`, append:
 - kiss — gate 5: over-engineering — interface with 1 impl, factory for new(), pass-through, deep inheritance.
 - yagni — gate 5: speculative code — optional params never passed, TODO without ticket, generic with 1 type.
 - clean-code — bad names, long functions, magic numbers, silent catch, boolean params, redundant comments.
+- {CODE_DESIGN_SKILL} — gate 5: enforce INVIOLABLE structural rules for the project's locked code design. BLOCKED on violations defined by the skill.
 </skills_to_load>
 ```
 
+Replace `{CODE_DESIGN_SKILL}` with the same resolved entry — both doer and reviewer load the SAME code-design skill.
+
 If `has_frontend=true`, append:
 ```markdown
 - frontend-rules — gate 5 frontend: <input> without label, button without aria-label, localStorage with token, outline removed.

package/runtimes/antigravity/skills/jdi-researcher/SKILL.md

@@ -61,10 +61,11 @@ Options:
 - Vertical Slice
 - Clean Architecture
 - Hexagonal (Ports & Adapters)
+- Onion Architecture
 - The Method (Juval Löwy)
 - "Don't know, suggest" (-> recommend based on type + stack)
 
-Locked for the life of the project (global rule).
+Locked for the life of the project (global rule). Mutually exclusive — the project uses exactly ONE code design. The choice is enforced by a JDI skill loaded into doer + reviewer (one of: `ddd`, `vertical-slice`, `clean-architecture`, `hexagonal`, `onion`, `the-method`).
 
 **Q4 — MVP scope**
 "Which minimum features for the MVP? (comma-separated)"

package/runtimes/antigravity/skills/onion/SKILL.md

@@ -0,0 +1,124 @@
+---
+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.
+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/runtimes/antigravity/skills/the-method/SKILL.md

@@ -0,0 +1,130 @@
+---
+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.
+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.

package/runtimes/antigravity/skills/vertical-slice/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: vertical-slice
+description: Vertical Slice Architecture (Jimmy Bogard). Organize by feature, not by technical layer. Each feature owns its full request-to-response path with minimal sharing. Language-agnostic rigid rules. Mutually exclusive with The Method, DDD, Clean Architecture, Hexagonal, Onion.
+triggers:
+  - "Vertical Slice"
+  - "Jimmy Bogard"
+  - "feature folder"
+  - "slice architecture"
+---
+
+# Skill: Vertical Slice Architecture
+
+Rigid, inviolable rules from Jimmy Bogard's Vertical Slice Architecture. The system is organized by **feature**, not by technical layer. Each slice owns the full path from external request to external response.
+
+Vertical Slice is the ONLY allowed design when PROJECT.md `Code Design: LOCKED: Vertical Slice`. Do not impose Clean Architecture's 4-layer structure, Onion shells, Hexagonal core/ports/adapters, DDD aggregates as primary structure, or The Method's universal hierarchy on top.
+
+## Mandatory structure
+
+1. **Each feature is one slice.** A feature is a single user-facing capability (e.g., `RegisterCustomer`, `CancelOrder`, `RenewSubscription`).
+2. **A slice owns its full pipeline:** input contract, validator, handler, business logic, persistence access, output contract, and slice-specific tests.
+3. **Slices live in feature folders / packages.** The primary code organization is `features/{feature-name}/` (or equivalent in the language). Technical-layer folders (`controllers/`, `services/`, `repositories/`, `models/`) as the primary structure are forbidden.
+4. **Each feature folder is self-contained.** Inside a folder live only the artifacts that serve that feature.
+5. **No shared "Service" layer, no shared "Repository" layer, no shared "Manager" layer across slices.** Each slice has its own.
+
+## Slice isolation rules (inviolable)
+
+1. **Slices do not call each other directly.** If slice A needs work done by slice B, slice A either duplicates the minimum needed code OR they both publish/subscribe to a shared event bus. Direct invocation of slice B's handler from slice A is forbidden.
+2. **No shared mutable state across slices.** A slice never mutates state owned by another slice except through the shared persistence boundary, and never through another slice's handler.
+3. **DRY applies inside a slice, not across slices.** Two slices that look similar today are still allowed to diverge tomorrow. Forced sharing is the enemy.
+4. **Cross-slice abstractions are introduced only when 3+ slices need the exact same behavior with the exact same shape, and that behavior is stable.** Premature shared abstractions are violations.
+
+## Slice composition (mandatory contents)
+
+Each slice MUST contain:
+
+1. **Request / Command / Query contract** — a structure describing the input.
+2. **Handler** — receives the request, executes the logic, returns the response.
+3. **Validator** (if input requires validation) — slice-local validation rules.
+4. **Response contract** — the output shape returned to the caller.
+5. **Slice-local types** — any DTOs, view models, or projections the slice needs.
+6. **Slice-local tests** — integration tests that exercise the slice end-to-end.
+
+A slice MAY contain:
+
+- A slice-specific persistence access path (raw query, ORM query, projection, command-side persistence).
+- A slice-specific external system call.
+- Slice-local pre/post processing.
+
+A slice MUST NOT contain:
+
+- References to another slice's handler, request, or response types.
+- References to a shared "Service" abstracting multiple slices.
+- A "Manager" coordinating multiple slices.
+
+## Cross-cutting concerns (inviolable)
+
+1. Cross-cutting concerns (logging, authentication, authorization, transactions, validation pipeline, error handling) are applied as **pipeline behaviors / middleware** that wrap the handler, never as shared services injected into the handler.
+2. Authentication and authorization decisions may use shared types (claims, principals) but are enforced at the pipeline level, not inside the handler.
+3. Validation runs as a pipeline step before the handler executes. The handler assumes valid input.
+4. Logging, tracing, metrics: pipeline behaviors. The handler does not invoke logging libraries for cross-cutting purposes.
+
+## Persistence rules
+
+1. **No generic repository spanning slices.** A slice that needs persistence either uses the ORM/database client directly within the slice OR has its own slice-local repository.
+2. **Reads and writes may diverge structurally.** A slice that reads may use a different model than a slice that writes; this is encouraged.
+3. **No "Domain Model" required to be shared across slices.** Each slice models the data it needs in the shape it needs.
+4. **A shared schema (database) is acceptable; a shared in-code model abstraction is not.**
+
+## Forbidden patterns (inviolable)
+
+- **Technical-layer primary folders** (`controllers/`, `services/`, `repositories/`, `models/`) used as the system's primary organization.
+- **A handler calling another handler.**
+- **A "Service" class injected into multiple handlers** to provide their business logic.
+- **A "Manager" class coordinating multiple slices.**
+- **A shared "Repository" abstraction** consumed by 5+ slices.
+- **Cross-slice imports of internal slice types.** Slice A importing `B.HandleQuery` or `B.RequestDto` is forbidden.
+- **Slice A invoking slice B via an internal interface** instead of via the public boundary (HTTP, queue, event).
+- **DRY refactoring that merges 2 slices into 1 because they share 80% of the code.** Slices stay separate until 3+ identical use cases exist with stable shape.
+- **Forcing all slices through a shared base handler class** that contains business logic.
+- **A shared "Domain Model" referenced by all slices** as the primary modeling element.
+
+## Naming conventions
+
+- Feature folders: feature name in domain language (`RegisterCustomer/`, `CancelOrder/`, `ViewCustomerDashboard/`).
+- Request types: domain operation name (`RegisterCustomerCommand`, `CancelOrderCommand`, `ViewCustomerDashboardQuery`).
+- Handler types: paired with request (`RegisterCustomerHandler`).
+- Validator types: paired with request (`RegisterCustomerValidator`).
+- Response types: domain output name (`RegisterCustomerResponse`).
+- Internal slice types: prefixed by feature name when shared inside the slice (`RegisterCustomerEmailTemplate`).
+
+## Reviewer enforcement (gate 5)
+
+Reviewer rejects (BLOCKED) when:
+- The codebase is primarily organized by technical layer instead of by feature.
+- A handler invokes another slice's handler, request, or response type.
+- A new "Service" / "Manager" / "Coordinator" class is introduced that spans multiple slices and carries business logic.
+- A shared generic repository is introduced and consumed by multiple slices.
+- Cross-cutting concerns are injected into handlers as shared services instead of applied as pipeline behaviors.
+- Slice A imports types from slice B's internal folder.
+
+Reviewer warns (APPROVED_WITH_WARNINGS) when:
+- Two slices share an identical small helper that has been duplicated 3+ times (candidate for extraction, not required).
+- A slice contains logic that appears to belong to a different slice.
+- A slice handler is long enough to suggest splitting into pipeline behaviors.
+- A slice references a "Domain Service" or "Aggregate" terminology that may indicate a different design creeping in.
+
+## Anti-patterns
+
+- "Vertical slices" implemented inside an MVC controllers/services/repositories folder structure (the folders betray the layer-primary structure)
+- A "Domain" project that all slices reference, containing entities + services + repositories — that is layered or Onion in disguise
+- Cross-slice "Coordinator" classes that orchestrate two handlers
+- A shared "BaseHandler" that contains transaction management AND business logic
+- A slice handler that delegates 90% of its work to a shared service (the slice is hollow)
+- Premature "DRY" extraction that merges slices into a generic handler with strategy patterns
+
+## Outputs
+
+Does NOT produce own files. Modifies parent agent's structural decisions during code authoring and review.

package/runtimes/claude/agents/jdi-architect.md

@@ -381,13 +381,29 @@ Write to `.jdi/agents/jdi-reviewer-{slug}.md`.
 
 After writing doer/reviewer, inject `<skills_to_load>` block after `</role>` via Edit.
 
+**Code-design skill (mandatory) — resolve from `PROJECT.md.Code Design` (LOCKED value) using this mapping:**
+
+| Code Design (PROJECT.md) | Skill to load |
+|---|---|
+| The Method | `the-method` |
+| DDD | `ddd` |
+| Clean Architecture | `clean-architecture` |
+| Hexagonal | `hexagonal` |
+| Onion | `onion` |
+| Vertical Slice | `vertical-slice` |
+
+The resolved code-design skill is loaded by **both doer and reviewer**. Exactly one code-design skill is loaded. Never load two code-design skills simultaneously — the project uses exactly one design. If the mapping cannot resolve, abort with an error and ask the user to fix `PROJECT.md.Code Design`.
+
 **Doer — always:**
 ```markdown
 <skills_to_load>
 - solid — before creating classes/modules/interfaces. Detects god class, large switches, deep inheritance, dep on concretes.
+- {CODE_DESIGN_SKILL} — INVIOLABLE structural rules for the project's locked code design. Apply on every file created.
 </skills_to_load>
 ```
 
+Replace `{CODE_DESIGN_SKILL}` with the resolved entry from the mapping above (e.g. `the-method`, `ddd`, `clean-architecture`, `hexagonal`, `onion`, `vertical-slice`).
+
 If `has_frontend=true`, append:
 ```markdown
 - frontend-rules — when task touches .tsx/.vue/.svelte/.razor/.cshtml/.html/.twig/.erb/.blade.php. WCAG 2.2 AA + UX.
@@ -400,9 +416,12 @@ If `has_frontend=true`, append:
 - kiss — gate 5: over-engineering — interface with 1 impl, factory for new(), pass-through, deep inheritance.
 - yagni — gate 5: speculative code — optional params never passed, TODO without ticket, generic with 1 type.
 - clean-code — bad names, long functions, magic numbers, silent catch, boolean params, redundant comments.
+- {CODE_DESIGN_SKILL} — gate 5: enforce INVIOLABLE structural rules for the project's locked code design. BLOCKED on violations defined by the skill.
 </skills_to_load>
 ```
 
+Replace `{CODE_DESIGN_SKILL}` with the same resolved entry — both doer and reviewer load the SAME code-design skill.
+
 If `has_frontend=true`, append:
 ```markdown
 - frontend-rules — gate 5 frontend: <input> without label, button without aria-label, localStorage with token, outline removed.

package/runtimes/claude/agents/jdi-researcher.md

@@ -56,10 +56,11 @@ Options:
 - Vertical Slice
 - Clean Architecture
 - Hexagonal (Ports & Adapters)
+- Onion Architecture
 - The Method (Juval Löwy)
 - "Don't know, suggest" (-> recommend based on type + stack)
 
-Locked for the life of the project (global rule).
+Locked for the life of the project (global rule). Mutually exclusive — the project uses exactly ONE code design. The choice is enforced by a JDI skill loaded into doer + reviewer (one of: `ddd`, `vertical-slice`, `clean-architecture`, `hexagonal`, `onion`, `the-method`).
 
 **Q4 — MVP scope**
 "Which minimum features for the MVP? (comma-separated)"