jdi-cli 0.1.1 → 0.1.3

package/runtimes/antigravity/skills/jdi-add-phase/SKILL.md

@@ -0,0 +1,171 @@
+---
+name: jdi-add-phase
+description: Adds a new phase to ROADMAP.md. Append at end (default) or insert at a specific position. Bumps total_phases. Atomic commit.
+argument_hint: "\"<phase name>\" [--goal \"<goal>\"] [--at <position>]"
+runtime_intent:
+  invokes_agent: none
+runtime_overrides:
+  claude:
+    allowed-tools: [Read, Write, Edit, Bash, Grep, Glob, AskUserQuestion]
+  copilot:
+    tools: [read, write, edit, grep, glob, terminal]
+  opencode:
+    subtask: true
+  antigravity:
+    triggers:
+      - "/jdi-add-phase"
+      - "add new phase"
+      - "create phase"
+---
+
+<objective>
+Adds a new phase to the project's roadmap. Edits `.jdi/ROADMAP.md`. Does not start the phase — only registers it. The user advances via `/jdi-discuss <N>` when ready.
+</objective>
+
+<arguments>
+- `name` (required) — short phase name. Quote if it contains spaces.
+- `--goal "<text>"` (optional) — 1-line description of what the phase delivers. If missing, AskUserQuestion will prompt.
+- `--at <position>` (optional) — insert at this position instead of appending. Existing phases at and after `<position>` shift down by 1 (renumbered in ROADMAP only — slugs stay the same in any existing `.jdi/phases/` folders). Default: append.
+
+Examples:
+- `/jdi-add-phase "User authentication" --goal "Login + signup + JWT"`
+- `/jdi-add-phase "Performance pass" --at 3`
+- `/jdi-add-phase "Hotfix N+1 query"`
+</arguments>
+
+<process>
+
+### Step 1: Validation
+```bash
+test -d .jdi/ || { echo "Not a JDI project. /jdi-new first."; exit 1; }
+test -f .jdi/ROADMAP.md || { echo "ROADMAP.md missing."; exit 1; }
+test -f .jdi/STATE.md || { echo "STATE.md missing."; exit 1; }
+```
+
+If `<name>` argument missing: AskUserQuestion "Phase name?" (free text). Required.
+
+If `--goal` flag missing: AskUserQuestion "Phase goal (1 line)?" (free text). Required.
+
+### Step 2: Compute phase number + slug
+
+Read `total_phases` from `.jdi/ROADMAP.md`:
+
+```bash
+TOTAL=$(grep -oE 'total_phases:\s*[0-9]+' .jdi/ROADMAP.md | grep -oE '[0-9]+')
+```
+
+PowerShell:
+```powershell
+$total = (Select-String -Path .jdi/ROADMAP.md -Pattern 'total_phases:\s*([0-9]+)').Matches[0].Groups[1].Value -as [int]
+```
+
+If `--at <pos>` provided, validate `1 <= pos <= total + 1`. Otherwise `pos = total + 1` (append).
+
+If `pos <= current_phase` (read from STATE.md), abort with error: "Cannot insert before current phase {current}. Use --at {current+1} or higher."
+
+Generate `slug` from `name`:
+- Lowercase
+- Replace accents (à → a, é → e, ç → c, ñ → n)
+- Non-alphanumeric → `-`
+- Collapse repeated `-`, strip leading/trailing `-`
+- Truncate to 40 chars
+
+Phase identifier prefix is the 2-digit position (`NN`): `01`, `02`, ..., zero-padded.
+
+### Step 3: Renumber prefix on shift (only if --at)
+
+If `--at <pos>` shifts existing phases:
+
+Edit `.jdi/ROADMAP.md` — for every existing `### Phase K:` where `K >= pos`, change to `### Phase K+1:` and bump its `**Slug:**` prefix from `KK-...` to `(K+1)(K+1)-...`.
+
+**WARNING (printed):**
+> "Renumbering ROADMAP phases. Any existing `.jdi/phases/<NN-slug>/` folders are NOT renamed — they keep their original slugs and become "history". New work in renumbered phases creates new folders. Commits referencing old `phase {K}` remain valid as history."
+
+This is intentional. Do not rename `.jdi/phases/` folders — would break commit history and cross-references in DECISIONS.md.
+
+If `--at` not provided (append), skip Step 3.
+
+### Step 4: Append phase section to ROADMAP.md
+
+If appending (`pos == total + 1`), append at the bottom of `## Phases`:
+
+```markdown
+
+### Phase {pos}: {name}
+- **Slug:** {NN}-{slug}
+- **Status:** pending
+- **Goal:** {goal}
+```
+
+If inserting (`pos <= total`), insert the new section BEFORE the section that previously had number `pos` (now renumbered to `pos+1`).
+
+### Step 5: Bump total_phases
+
+Edit `.jdi/ROADMAP.md`:
+```
+total_phases: {TOTAL + 1}
+```
+
+### Step 6: Audit trail in DECISIONS.md (optional, only if user passes --reason)
+
+Not required. If user wants to record why this phase was added mid-project, they pass `--reason "<text>"`. When present, append to `.jdi/DECISIONS.md`:
+
+```markdown
+D-{N+1} ({date}, phase {pos}): Phase added mid-project. Reason: {reason}
+```
+
+(N = current max D-X.)
+
+### Step 7: Commit
+
+```bash
+git add .jdi/ROADMAP.md .jdi/DECISIONS.md 2>/dev/null
+git commit -m "chore(jdi): add phase {pos} {NN-slug}"
+```
+
+PowerShell:
+```powershell
+git add .jdi/ROADMAP.md .jdi/DECISIONS.md 2>$null
+git commit -m "chore(jdi): add phase $pos $NN-$slug"
+```
+
+### Step 8: Confirm
+
+```
+Phase {pos}: {name} added.
+Slug: {NN}-{slug}
+Goal: {goal}
+Status: pending
+total_phases: {TOTAL + 1}
+
+Next: /jdi-discuss {pos} (when ready to start this phase)
+```
+
+</process>
+
+<gates>
+- pre: `.jdi/ROADMAP.md` + `.jdi/STATE.md` exist
+- pre: `--at <pos>` (if used) is greater than `current_phase` in STATE.md
+- post: ROADMAP.md has new phase section + bumped total_phases + atomic commit
+</gates>
+
+<errors>
+- `.jdi/` missing -> "Run /jdi-new first"
+- `--at <pos>` <= current_phase -> "Cannot insert before current phase. Use --at {current+1} or higher."
+- `--at <pos>` < 1 or > total+1 -> "Position out of range. Valid: 1..{total+1}"
+- Phase name empty -> AskUserQuestion to fill
+- Goal empty -> AskUserQuestion to fill
+</errors>
+
+<runtime_notes>
+
+**Claude Code:**
+- AskUserQuestion handles missing args interactively.
+
+**Copilot:**
+- AskUserQuestion not always available — read missing args from prompt body or fail with clear error.
+
+**OpenCode/Antigravity:**
+- Same interactive flow as Claude when supported. Otherwise fail with clear error message asking the user to re-invoke with all args.
+
+</runtime_notes>

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-remove-phase/SKILL.md

@@ -0,0 +1,228 @@
+---
+name: jdi-remove-phase
+description: Removes a phase from ROADMAP.md. Refuses to remove done phases or the current phase. Archives any existing phase artifacts. Atomic commit.
+argument_hint: "<phase_number> [--force]"
+runtime_intent:
+  invokes_agent: none
+runtime_overrides:
+  claude:
+    allowed-tools: [Read, Write, Edit, Bash, Grep, Glob, AskUserQuestion]
+  copilot:
+    tools: [read, write, edit, grep, glob, terminal]
+  opencode:
+    subtask: true
+  antigravity:
+    triggers:
+      - "/jdi-remove-phase"
+      - "remove phase"
+      - "delete phase"
+---
+
+<objective>
+Removes a phase from `.jdi/ROADMAP.md`. Refuses to remove the current phase or any phase already shipped. If the phase has artifacts under `.jdi/phases/<NN-slug>/`, moves them to `.jdi/archive/removed-<NN-slug>/` instead of deleting (preserves history).
+</objective>
+
+<arguments>
+- `phase_number` (required) — number of the phase to remove (as listed in ROADMAP.md).
+- `--force` (optional) — required when removing a phase that has any artifacts in `.jdi/phases/`. Without `--force`, the command refuses and explains.
+
+Examples:
+- `/jdi-remove-phase 4`
+- `/jdi-remove-phase 5 --force`
+</arguments>
+
+<process>
+
+### Step 1: Validation
+
+```bash
+test -d .jdi/ || { echo "Not a JDI project."; exit 1; }
+test -f .jdi/ROADMAP.md || { echo "ROADMAP.md missing."; exit 1; }
+test -f .jdi/STATE.md || { echo "STATE.md missing."; exit 1; }
+
+# Argument required
+[ -n "$1" ] || { echo "Phase number required. Usage: /jdi-remove-phase <N> [--force]"; exit 1; }
+```
+
+Parse `phase_number` (positional). Parse `--force` flag.
+
+### Step 2: Read state
+
+```bash
+CURRENT=$(grep -oE 'current_phase:\s*[0-9]+' .jdi/STATE.md | grep -oE '[0-9]+')
+TOTAL=$(grep -oE 'total_phases:\s*[0-9]+' .jdi/ROADMAP.md | grep -oE '[0-9]+')
+PHASE_NUMBER=$1
+```
+
+PowerShell:
+```powershell
+$current = (Select-String -Path .jdi/STATE.md -Pattern 'current_phase:\s*([0-9]+)').Matches[0].Groups[1].Value -as [int]
+$total = (Select-String -Path .jdi/ROADMAP.md -Pattern 'total_phases:\s*([0-9]+)').Matches[0].Groups[1].Value -as [int]
+$phaseNumber = [int]$args[0]
+```
+
+### Step 3: Hard refuses (no override)
+
+```bash
+# Must be in range
+if [ "$PHASE_NUMBER" -lt 1 ] || [ "$PHASE_NUMBER" -gt "$TOTAL" ]; then
+  echo "Phase $PHASE_NUMBER does not exist. Valid: 1..$TOTAL"
+  exit 1
+fi
+
+# Cannot remove past phases (preserves history)
+if [ "$PHASE_NUMBER" -lt "$CURRENT" ]; then
+  echo "Cannot remove phase $PHASE_NUMBER — already past. current_phase is $CURRENT. Past phases are immutable history."
+  exit 1
+fi
+
+# Cannot remove the current phase
+if [ "$PHASE_NUMBER" -eq "$CURRENT" ]; then
+  echo "Cannot remove the current phase ($CURRENT). Ship or abandon it first, then advance current_phase."
+  exit 1
+fi
+```
+
+Read the phase's `Status:` from ROADMAP:
+
+```bash
+STATUS=$(awk "/### Phase $PHASE_NUMBER:/,/^### Phase /" .jdi/ROADMAP.md | grep -oE 'Status:\*\* (pending|ready|done|partial|blocked|in-progress)' | head -1 | awk '{print $2}')
+```
+
+If `STATUS == done`: refuse hard.
+```
+Phase $PHASE_NUMBER is `done`. Cannot remove. Shipped phases are immutable history.
+```
+
+### Step 4: Detect artifacts
+
+Find the phase folder under `.jdi/phases/`:
+
+```bash
+NN=$(printf '%02d' "$PHASE_NUMBER")
+PHASE_DIR=$(ls -d .jdi/phases/${NN}-*/ 2>/dev/null | head -1 || true)
+```
+
+PowerShell:
+```powershell
+$nn = '{0:D2}' -f $phaseNumber
+$phaseDir = Get-ChildItem .jdi/phases/ -Directory -Filter "$nn-*" -ErrorAction SilentlyContinue | Select-Object -First 1
+```
+
+If `PHASE_DIR` exists AND `--force` NOT passed: refuse.
+```
+Phase $PHASE_NUMBER has artifacts in $PHASE_DIR (CONTEXT/PLAN/SUMMARY/REVIEW).
+Re-run with --force to archive these artifacts to .jdi/archive/removed-<NN-slug>/ and proceed.
+```
+
+### Step 5: Confirm with user (irreversible-ish action)
+
+AskUserQuestion (always run, even with --force):
+
+> "Remove phase $PHASE_NUMBER: '$PHASE_NAME'?
+>
+> Status: $STATUS
+> Artifacts: ${PHASE_DIR:-none}
+> Action: ROADMAP section removed, total_phases decremented, artifacts (if any) moved to .jdi/archive/removed-<NN-slug>/."
+>
+> Options:
+> - [Yes, remove]
+> - [Cancel]
+
+If "Cancel" -> exit clean.
+
+### Step 6: Archive artifacts (if any)
+
+```bash
+if [ -n "$PHASE_DIR" ]; then
+  mkdir -p .jdi/archive
+  test -f .jdi/archive/index.md || echo "# Archive index" > .jdi/archive/index.md
+
+  BASENAME=$(basename "$PHASE_DIR")
+  TARGET=".jdi/archive/removed-$BASENAME"
+  mv "$PHASE_DIR" "$TARGET"
+  echo "- removed-$BASENAME (removed $(date -u +%F) via /jdi-remove-phase)" >> .jdi/archive/index.md
+fi
+```
+
+PowerShell:
+```powershell
+if ($phaseDir) {
+  if (-not (Test-Path .jdi/archive)) { New-Item -ItemType Directory .jdi/archive | Out-Null }
+  if (-not (Test-Path .jdi/archive/index.md)) { Set-Content .jdi/archive/index.md "# Archive index" }
+  $basename = $phaseDir.Name
+  $target = ".jdi/archive/removed-$basename"
+  Move-Item $phaseDir.FullName $target
+  Add-Content .jdi/archive/index.md "- removed-$basename (removed $(Get-Date -Format 'yyyy-MM-dd') via /jdi-remove-phase)"
+}
+```
+
+### Step 7: Edit ROADMAP.md
+
+Remove the entire `### Phase $PHASE_NUMBER: ...` block (header + bullets) up to (but not including) the next `### Phase ` line or end of file.
+
+Decrement `total_phases`:
+```
+total_phases: {TOTAL - 1}
+```
+
+**Do NOT renumber** subsequent phases. Phases after the removed one keep their original numbers. This preserves all references in commit history, `DECISIONS.md`, and archived phase folders. The roadmap simply has a gap (e.g., 1, 2, 3, 5, 6 — 4 was removed).
+
+### Step 8: Audit trail in DECISIONS.md
+
+Append:
+```markdown
+D-{N+1} ({date}): Phase $PHASE_NUMBER removed via /jdi-remove-phase. Artifacts: ${PHASE_DIR:+archived to .jdi/archive/removed-<NN-slug>/}{none if empty}.
+```
+
+### Step 9: Commit
+
+```bash
+git add .jdi/ROADMAP.md .jdi/DECISIONS.md .jdi/archive/ 2>/dev/null
+git commit -m "chore(jdi): remove phase {PHASE_NUMBER}"
+```
+
+### Step 10: Confirm
+
+```
+Phase {PHASE_NUMBER} removed.
+{if artifacts:} Artifacts archived: .jdi/archive/removed-{NN-slug}/
+total_phases: {TOTAL - 1}
+
+Note: phase numbers are not renumbered — references in commits, DECISIONS, and archive remain valid.
+```
+
+</process>
+
+<gates>
+- pre: `.jdi/ROADMAP.md` + `.jdi/STATE.md` exist
+- pre: `phase_number` is in range `1..total_phases`
+- pre: `phase_number > current_phase`
+- pre: phase status != `done`
+- pre: `--force` provided when phase has artifacts
+- post: ROADMAP.md section removed + total_phases decremented + artifacts archived (if any) + DECISIONS.md appended + atomic commit
+</gates>
+
+<errors>
+- `.jdi/` missing -> "Run /jdi-new first"
+- `phase_number` missing -> usage hint
+- `phase_number` out of range -> "Valid: 1..{total}"
+- `phase_number < current_phase` -> refuse (past = history)
+- `phase_number == current_phase` -> refuse (ship or abandon first)
+- phase status `done` -> refuse (shipped = history)
+- artifacts exist + no `--force` -> refuse + suggest `--force`
+- user cancels at AskUserQuestion -> exit clean
+</errors>
+
+<runtime_notes>
+
+**Claude Code:**
+- Confirms via AskUserQuestion.
+
+**Copilot:**
+- AskUserQuestion not always available — require explicit `--yes` flag as fallback.
+
+**OpenCode/Antigravity:**
+- Same interactive confirm as Claude. Fallback to `--yes` when prompts unsupported.
+
+</runtime_notes>

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.