jdi-cli 0.1.1 → 0.1.2

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

@@ -0,0 +1,119 @@
+---
+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.
+---
+
+# 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/opencode/skills/the-method/SKILL.md

@@ -0,0 +1,124 @@
+---
+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.
+---
+
+# 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/opencode/skills/vertical-slice/SKILL.md

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