@su-record/vibe 2.8.52 → 2.9.1

package/skills/arch-guard/agents/violation-checker.md

@@ -1,51 +1,51 @@
----
-name: arch-violation-checker
-role: Scans all import statements across the codebase and flags boundary violations against the rule set
-tools: [Glob, Grep, Read]
----
-
-# Arch Violation Checker
-
-## Role
-Performs the mechanical import-graph scan against the generated rule set. For every file in a `from` layer, it extracts all import paths and checks whether any resolve into a `cannotImport` layer. Reports each violation with full context.
-
-## Responsibilities
-- Enumerate all files matching each rule's `from` glob pattern
-- Extract import and require statements from each file
-- Resolve relative imports to their canonical layer classification
-- Check resolved imports against the `cannotImport` glob patterns
-- Collect violations with file path, line number, importing path, and violated rule
-
-## Input
-Normalized rule set JSON from `arch-rule-generator` and project root path.
-
-## Output
-Violation list JSON:
-```json
-{
-  "violations": [
-    {
-      "rule": "domain-no-infra",
-      "file": "src/domain/user.ts",
-      "line": 3,
-      "import": "../infra/db/userRepository",
-      "resolved": "src/infra/db/userRepository.ts",
-      "severity": "error"
-    }
-  ],
-  "scannedFiles": 142,
-  "cleanFiles": 139
-}
-```
-
-## Communication
-- Reports violation list to: `arch-reporter`
-- Receives instructions from: arch-guard orchestrator (SKILL.md)
-
-## Domain Knowledge
-Import resolution rules:
-- Relative imports (`./`, `../`) must be resolved relative to the importing file's location
-- Path aliases (`@/`, `~/`) must be resolved using the project's `tsconfig.json` `paths` config
-- External package imports (no leading `.` or `/`) are always allowed — skip them
-- Re-export barrel files (`index.ts`) count as the directory they represent
-- Type-only imports (`import type`) still count as dependencies for boundary purposes
+---
+name: arch-violation-checker
+role: Scans all import statements across the codebase and flags boundary violations against the rule set
+tools: [Glob, Grep, Read]
+---
+
+# Arch Violation Checker
+
+## Role
+Performs the mechanical import-graph scan against the generated rule set. For every file in a `from` layer, it extracts all import paths and checks whether any resolve into a `cannotImport` layer. Reports each violation with full context.
+
+## Responsibilities
+- Enumerate all files matching each rule's `from` glob pattern
+- Extract import and require statements from each file
+- Resolve relative imports to their canonical layer classification
+- Check resolved imports against the `cannotImport` glob patterns
+- Collect violations with file path, line number, importing path, and violated rule
+
+## Input
+Normalized rule set JSON from `arch-rule-generator` and project root path.
+
+## Output
+Violation list JSON:
+```json
+{
+  "violations": [
+    {
+      "rule": "domain-no-infra",
+      "file": "src/domain/user.ts",
+      "line": 3,
+      "import": "../infra/db/userRepository",
+      "resolved": "src/infra/db/userRepository.ts",
+      "severity": "error"
+    }
+  ],
+  "scannedFiles": 142,
+  "cleanFiles": 139
+}
+```
+
+## Communication
+- Reports violation list to: `arch-reporter`
+- Receives instructions from: arch-guard orchestrator (SKILL.md)
+
+## Domain Knowledge
+Import resolution rules:
+- Relative imports (`./`, `../`) must be resolved relative to the importing file's location
+- Path aliases (`@/`, `~/`) must be resolved using the project's `tsconfig.json` `paths` config
+- External package imports (no leading `.` or `/`) are always allowed — skip them
+- Re-export barrel files (`index.ts`) count as the directory they represent
+- Type-only imports (`import type`) still count as dependencies for boundary purposes

package/skills/arch-guard/frameworks/clean-architecture.md

@@ -1,108 +1,108 @@
----
-name: clean-architecture
-type: framework
-applies-to: [arch-guard]
----
-
-# Clean Architecture — Reference Card
-
-## Layer Model
-
-```
-┌─────────────────────────────────┐
-│  Frameworks & Drivers           │  ← UI, DB, HTTP, CLI, external APIs
-├─────────────────────────────────┤
-│  Interface Adapters             │  ← Controllers, Presenters, Gateways
-├─────────────────────────────────┤
-│  Application Use Cases          │  ← Business rules orchestration
-├─────────────────────────────────┤
-│  Entities (Domain)              │  ← Core business objects & rules
-└─────────────────────────────────┘
-```
-
-**Dependency Rule**: Dependencies point inward only. Inner layers know nothing about outer layers.
-
-## Layer Responsibilities
-
-| Layer | Contains | Must NOT contain |
-|-------|----------|-----------------|
-| Entities | Domain models, value objects, domain rules | Framework imports, DB calls |
-| Use Cases | Application workflows, business logic | HTTP, DB drivers, UI logic |
-| Adapters | Controllers, mappers, repository impls | Business rules, domain logic |
-| Frameworks | Express routes, Prisma, React, CLI | Business or application logic |
-
-## Dependency Rule in Code
-
-```ts
-// Good — Use Case depends on abstraction (repository interface)
-// src/use-cases/CreateUser.ts
-interface UserRepository { save(user: User): Promise<void> }
-
-export class CreateUserUseCase {
-  constructor(private users: UserRepository) {}
-  execute(data: CreateUserInput): Promise<User> { /* business logic only */ }
-}
-
-// Good — Adapter implements the interface
-// src/adapters/PrismaUserRepository.ts
-import { PrismaClient } from '@prisma/client'; // framework import OK here
-class PrismaUserRepository implements UserRepository {
-  save(user: User): Promise<void> { /* prisma call */ }
-}
-
-// Bad — Use Case imports Prisma directly (crosses boundary)
-// src/use-cases/CreateUser.ts
-import { PrismaClient } from '@prisma/client'; // VIOLATION
-```
-
-## Boundary Crossing Patterns
-
-### Data Transfer Objects (DTOs)
-Cross boundaries using plain data structures, not domain entities.
-
-```ts
-// Input DTO — from outer layer into use case
-type CreateUserInput = { email: string; name: string }
-
-// Output DTO — from use case out to adapter
-type CreateUserOutput = { id: string; email: string; createdAt: Date }
-```
-
-### Repository Pattern
-Isolates data access behind an interface defined in the domain layer.
-
-```ts
-// Defined in domain layer
-interface UserRepository {
-  findById(id: string): Promise<User | null>
-  save(user: User): Promise<void>
-  delete(id: string): Promise<void>
-}
-```
-
-## Common Violations
-
-| Violation | Example | Fix |
-|-----------|---------|-----|
-| Framework import in entity | `import express from 'express'` in `User.ts` | Move to adapter layer |
-| DB call in use case | `prisma.user.findMany()` in use case | Use repository interface |
-| Business logic in controller | `if (price > 100) applyDiscount()` in route handler | Move to use case |
-| Entity exposed via HTTP | Return `User` domain object as JSON directly | Map to response DTO |
-| Use case depends on use case | `CreateOrder` imports `CreateUser` | Extract shared logic to domain service |
-
-## Directory Structure Convention
-
-```
-src/
-  domain/          ← Entities, value objects, domain interfaces
-  use-cases/       ← Application business rules
-  adapters/        ← Controllers, repository implementations, mappers
-  infrastructure/  ← DB, HTTP, external services (framework layer)
-```
-
-## Arch-Guard Checks
-
-- No `import` crossing inward (outer → inner only)
-- No framework imports (`express`, `prisma`, `mongoose`) in `domain/` or `use-cases/`
-- No `fetch`/`axios` in entities or use cases
-- All use case dependencies are interfaces, not concrete classes
+---
+name: clean-architecture
+type: framework
+applies-to: [arch-guard]
+---
+
+# Clean Architecture — Reference Card
+
+## Layer Model
+
+```
+┌─────────────────────────────────┐
+│  Frameworks & Drivers           │  ← UI, DB, HTTP, CLI, external APIs
+├─────────────────────────────────┤
+│  Interface Adapters             │  ← Controllers, Presenters, Gateways
+├─────────────────────────────────┤
+│  Application Use Cases          │  ← Business rules orchestration
+├─────────────────────────────────┤
+│  Entities (Domain)              │  ← Core business objects & rules
+└─────────────────────────────────┘
+```
+
+**Dependency Rule**: Dependencies point inward only. Inner layers know nothing about outer layers.
+
+## Layer Responsibilities
+
+| Layer | Contains | Must NOT contain |
+|-------|----------|-----------------|
+| Entities | Domain models, value objects, domain rules | Framework imports, DB calls |
+| Use Cases | Application workflows, business logic | HTTP, DB drivers, UI logic |
+| Adapters | Controllers, mappers, repository impls | Business rules, domain logic |
+| Frameworks | Express routes, Prisma, React, CLI | Business or application logic |
+
+## Dependency Rule in Code
+
+```ts
+// Good — Use Case depends on abstraction (repository interface)
+// src/use-cases/CreateUser.ts
+interface UserRepository { save(user: User): Promise<void> }
+
+export class CreateUserUseCase {
+  constructor(private users: UserRepository) {}
+  execute(data: CreateUserInput): Promise<User> { /* business logic only */ }
+}
+
+// Good — Adapter implements the interface
+// src/adapters/PrismaUserRepository.ts
+import { PrismaClient } from '@prisma/client'; // framework import OK here
+class PrismaUserRepository implements UserRepository {
+  save(user: User): Promise<void> { /* prisma call */ }
+}
+
+// Bad — Use Case imports Prisma directly (crosses boundary)
+// src/use-cases/CreateUser.ts
+import { PrismaClient } from '@prisma/client'; // VIOLATION
+```
+
+## Boundary Crossing Patterns
+
+### Data Transfer Objects (DTOs)
+Cross boundaries using plain data structures, not domain entities.
+
+```ts
+// Input DTO — from outer layer into use case
+type CreateUserInput = { email: string; name: string }
+
+// Output DTO — from use case out to adapter
+type CreateUserOutput = { id: string; email: string; createdAt: Date }
+```
+
+### Repository Pattern
+Isolates data access behind an interface defined in the domain layer.
+
+```ts
+// Defined in domain layer
+interface UserRepository {
+  findById(id: string): Promise<User | null>
+  save(user: User): Promise<void>
+  delete(id: string): Promise<void>
+}
+```
+
+## Common Violations
+
+| Violation | Example | Fix |
+|-----------|---------|-----|
+| Framework import in entity | `import express from 'express'` in `User.ts` | Move to adapter layer |
+| DB call in use case | `prisma.user.findMany()` in use case | Use repository interface |
+| Business logic in controller | `if (price > 100) applyDiscount()` in route handler | Move to use case |
+| Entity exposed via HTTP | Return `User` domain object as JSON directly | Map to response DTO |
+| Use case depends on use case | `CreateOrder` imports `CreateUser` | Extract shared logic to domain service |
+
+## Directory Structure Convention
+
+```
+src/
+  domain/          ← Entities, value objects, domain interfaces
+  use-cases/       ← Application business rules
+  adapters/        ← Controllers, repository implementations, mappers
+  infrastructure/  ← DB, HTTP, external services (framework layer)
+```
+
+## Arch-Guard Checks
+
+- No `import` crossing inward (outer → inner only)
+- No framework imports (`express`, `prisma`, `mongoose`) in `domain/` or `use-cases/`
+- No `fetch`/`axios` in entities or use cases
+- All use case dependencies are interfaces, not concrete classes

package/skills/arch-guard/frameworks/solid.md

@@ -1,102 +1,102 @@
----
-name: solid-principles
-type: framework
-applies-to: [arch-guard]
----
-
-# SOLID Principles — Reference Card
-
-## S — Single Responsibility Principle
-> A class/module should have only one reason to change.
-
-**Violation signal**: A function does fetching + parsing + formatting + writing.
-
-```ts
-// Bad — UserService handles auth AND email AND db writes
-class UserService {
-  login(email: string, password: string): void { /* auth logic */ }
-  sendWelcomeEmail(user: User): void { /* email logic */ }
-  saveToDb(user: User): void { /* db logic */ }
-}
-
-// Good — each class owns one concern
-class AuthService { login(email: string, password: string): void {} }
-class EmailService { sendWelcome(user: User): void {} }
-class UserRepository { save(user: User): void {} }
-```
-
-## O — Open/Closed Principle
-> Open for extension, closed for modification.
-
-**Violation signal**: Adding a new type requires editing existing switch/if chains.
-
-```ts
-// Bad — adding payment type requires editing processPayment
-function processPayment(type: string, amount: number): void {
-  if (type === 'card') { /* ... */ }
-  if (type === 'paypal') { /* ... */ }
-}
-
-// Good — extend via new class, no existing code changes
-interface PaymentProcessor { process(amount: number): void }
-class CardProcessor implements PaymentProcessor { process(amount: number): void {} }
-class PayPalProcessor implements PaymentProcessor { process(amount: number): void {} }
-```
-
-## L — Liskov Substitution Principle
-> Subtypes must be substitutable for their base types.
-
-**Violation signal**: Overriding a method to throw `NotImplementedError` or changing preconditions.
-
-```ts
-// Bad — Square breaks Rectangle's invariant (width/height independence)
-class Rectangle { setWidth(w: number): void {} setHeight(h: number): void {} }
-class Square extends Rectangle {
-  setWidth(w: number): void { this.width = w; this.height = w; } // breaks contract
-}
-
-// Good — separate types, shared interface
-interface Shape { area(): number }
-class Rectangle implements Shape { area(): number { return this.w * this.h; } }
-class Square implements Shape { area(): number { return this.side ** 2; } }
-```
-
-## I — Interface Segregation Principle
-> Clients should not depend on interfaces they do not use.
-
-**Violation signal**: Implementing an interface and leaving methods as `() => { throw new Error() }`.
-
-```ts
-// Bad — Printer forced to implement fax() it doesn't support
-interface Machine { print(): void; scan(): void; fax(): void; }
-
-// Good — split into focused interfaces
-interface Printer { print(): void }
-interface Scanner { scan(): void }
-interface FaxMachine { fax(): void }
-```
-
-## D — Dependency Inversion Principle
-> Depend on abstractions, not concretions.
-
-**Violation signal**: High-level module imports a specific low-level class directly.
-
-```ts
-// Bad — OrderService tightly coupled to MySQLDatabase
-import { MySQLDatabase } from './MySQLDatabase';
-class OrderService { db = new MySQLDatabase(); }
-
-// Good — depend on interface, inject implementation
-interface Database { query(sql: string): unknown[] }
-class OrderService { constructor(private db: Database) {} }
-```
-
-## Quick Checklist
-
-| Principle | Red Flag |
-|-----------|----------|
-| SRP | Function/class name contains "And" or "Manager" |
-| OCP | Adding feature requires editing existing if/switch |
-| LSP | Subclass throws `NotImplemented` or removes behavior |
-| ISP | Interface has methods unused by most implementors |
-| DIP | `new ConcreteClass()` inside a high-level module |
+---
+name: solid-principles
+type: framework
+applies-to: [arch-guard]
+---
+
+# SOLID Principles — Reference Card
+
+## S — Single Responsibility Principle
+> A class/module should have only one reason to change.
+
+**Violation signal**: A function does fetching + parsing + formatting + writing.
+
+```ts
+// Bad — UserService handles auth AND email AND db writes
+class UserService {
+  login(email: string, password: string): void { /* auth logic */ }
+  sendWelcomeEmail(user: User): void { /* email logic */ }
+  saveToDb(user: User): void { /* db logic */ }
+}
+
+// Good — each class owns one concern
+class AuthService { login(email: string, password: string): void {} }
+class EmailService { sendWelcome(user: User): void {} }
+class UserRepository { save(user: User): void {} }
+```
+
+## O — Open/Closed Principle
+> Open for extension, closed for modification.
+
+**Violation signal**: Adding a new type requires editing existing switch/if chains.
+
+```ts
+// Bad — adding payment type requires editing processPayment
+function processPayment(type: string, amount: number): void {
+  if (type === 'card') { /* ... */ }
+  if (type === 'paypal') { /* ... */ }
+}
+
+// Good — extend via new class, no existing code changes
+interface PaymentProcessor { process(amount: number): void }
+class CardProcessor implements PaymentProcessor { process(amount: number): void {} }
+class PayPalProcessor implements PaymentProcessor { process(amount: number): void {} }
+```
+
+## L — Liskov Substitution Principle
+> Subtypes must be substitutable for their base types.
+
+**Violation signal**: Overriding a method to throw `NotImplementedError` or changing preconditions.
+
+```ts
+// Bad — Square breaks Rectangle's invariant (width/height independence)
+class Rectangle { setWidth(w: number): void {} setHeight(h: number): void {} }
+class Square extends Rectangle {
+  setWidth(w: number): void { this.width = w; this.height = w; } // breaks contract
+}
+
+// Good — separate types, shared interface
+interface Shape { area(): number }
+class Rectangle implements Shape { area(): number { return this.w * this.h; } }
+class Square implements Shape { area(): number { return this.side ** 2; } }
+```
+
+## I — Interface Segregation Principle
+> Clients should not depend on interfaces they do not use.
+
+**Violation signal**: Implementing an interface and leaving methods as `() => { throw new Error() }`.
+
+```ts
+// Bad — Printer forced to implement fax() it doesn't support
+interface Machine { print(): void; scan(): void; fax(): void; }
+
+// Good — split into focused interfaces
+interface Printer { print(): void }
+interface Scanner { scan(): void }
+interface FaxMachine { fax(): void }
+```
+
+## D — Dependency Inversion Principle
+> Depend on abstractions, not concretions.
+
+**Violation signal**: High-level module imports a specific low-level class directly.
+
+```ts
+// Bad — OrderService tightly coupled to MySQLDatabase
+import { MySQLDatabase } from './MySQLDatabase';
+class OrderService { db = new MySQLDatabase(); }
+
+// Good — depend on interface, inject implementation
+interface Database { query(sql: string): unknown[] }
+class OrderService { constructor(private db: Database) {} }
+```
+
+## Quick Checklist
+
+| Principle | Red Flag |
+|-----------|----------|
+| SRP | Function/class name contains "And" or "Manager" |
+| OCP | Adding feature requires editing existing if/switch |
+| LSP | Subclass throws `NotImplemented` or removes behavior |
+| ISP | Interface has methods unused by most implementors |
+| DIP | `new ConcreteClass()` inside a high-level module |