archrip 0.1.7 → 0.1.9

package/dist/schema/architecture.schema.json

@@ -68,7 +68,7 @@
         "implements": { "type": "string" },
         "externalService": { "type": "string" },
         "sqlExamples": { "type": "array", "items": { "type": "string" } },
-        "depth": { "type": "integer", "minimum": 0, "maximum": 2, "description": "Abstraction depth: 0=overview (boundary), 1=structure (internal), 2=detail (implementation). Auto-inferred from category if omitted." }
+        "depth": { "type": "integer", "minimum": 0, "maximum": 2, "description": "Abstraction depth: 0=overview, 1=structure, 2=detail. Auto-inferred from layer if omitted." }
       },
       "additionalProperties": false
     },

package/dist/templates/slash-commands/claude/archrip-scan.md

@@ -25,16 +25,31 @@ Read existing documentation to understand architecture context:
 3. Use this knowledge to inform the analysis — documentation often reveals architectural intent that code alone does not show (use cases, business context, external dependencies)
 
 ## Phase 3: Layer Identification
-Based on the framework, identify architectural layers:
+Assign each component a `layer` integer. The rule: **higher layer = closer to domain core (more stable, fewer external dependencies). Lower layer = closer to external world (more volatile, I/O-bound).**
 
-**Common patterns:**
-- Laravel: Controllers → Services → Ports → Adapters → Models
-- Express/NestJS: Routes/Controllers → Services → Repositories → Models
-- Next.js: Pages → Components → Hooks → API Routes → Services
-- Django: Views → Serializers → Services → Models
-- Spring Boot: Controllers → Services → Repositories → Entities
-- Go: Handlers → Services → Repositories → Models
-- Generic: Group by directory responsibility
+Both layouts use this value — dagre places higher layers lower on screen, concentric places them at the center.
+
+**Reference mappings** (layer numbers in parentheses — adapt to actual project structure):
+
+MVC / Layered:
+- Laravel: External(0) → Controllers(1) → Services(2) → Models(3)
+- Rails: External(0) → Controllers(1) → Services(2) → Models(3)
+- Django: External(0) → Views(1) → Serializers(2) → Services(3) → Models(4)
+- Spring Boot: External(0) → Controllers(1) → Services(2) → Repositories(3) → Entities(4)
+- NestJS: External(0) → Controllers(1) → Services(2) → Repositories(3) → Entities(4)
+- Next.js App Router: External(0) → Route Handlers/Pages(1) → Components(2) → Hooks/Services(3) → Data Access(4)
+- FastAPI: External(0) → Routers(1) → Services(2) → Repositories(3) → Models(4)
+
+DDD / Clean Architecture / Hexagonal (use `"layout": "concentric"`):
+- Generic: External(0) → Adapters(1) → Controllers(2) → Application Services(3) → Ports(4) → Domain Entities(5)
+- Go (Hex): External(0) → Handlers(1) → Adapters(2) → Use Cases(3) → Ports(4) → Domain(5)
+- Flutter (Clean): External(0) → Data Sources(1) → Repositories(2) → Use Cases(3) → Entities(4)
+
+Serverless / Microservices:
+- SST/Lambda: External(0) → API Gateway(1) → Lambda Handlers(2) → Services(3) → Domain(4)
+- Microservices: External(0) → Gateway/BFF(1) → Service Boundaries(2) → Internal Services(3) → Shared Domain(4)
+
+For unlisted frameworks: group by directory responsibility and apply the abstract rule above.
 
 ## Phase 4: Read Key Files
 For each layer, read representative files to extract:
@@ -115,11 +130,11 @@ After writing the file:
 
 ### Node Rules
 - `id`: kebab-case, prefixed by category abbreviation (ctrl-, svc-, port-, adpt-, model-, ext-, job-, dto-)
-- `layer`: 0=external, 1=entry points, 2=application logic, 3=abstractions, 4=implementations, 5=data
+- `layer`: non-negative integer. **Higher = closer to domain core / more stable. Lower = closer to external world / more volatile.** Dagre (TB) places higher layers lower on screen; concentric places them at center. Use as many layers as the architecture requires (typically 3-6). Example for DDD: 0=external, 1=adapters, 2=controllers, 3=app services, 4=ports, 5=domain entities. Example for MVC: 0=external, 1=controllers, 2=services, 3=models.
 - `category`: one of controller, service, port, adapter, model, external, job, dto (or custom)
 - `label`: display name for the node
 - `filePath`: relative from project root
-- `depth` (optional): 0=overview (boundary), 1=structure (internal), 2=detail (implementation). Auto-inferred from category if omitted
+- `depth` (optional): 0=overview, 1=structure, 2=detail. Auto-inferred from `layer` if omitted: with 3+ unique layers, lowest → 0, middle → 1, highest → 2. With 1-2 layers, all nodes get depth 0 (always visible).
 - `useCases`: array of use case IDs this node participates in
 
 ### Edge Rules

package/dist/templates/slash-commands/codex/archrip-scan.md

@@ -25,16 +25,31 @@ Read existing documentation to understand architecture context:
 3. Use this knowledge to inform the analysis — documentation often reveals architectural intent that code alone does not show (use cases, business context, external dependencies)
 
 ## Phase 3: Layer Identification
-Based on the framework, identify architectural layers:
+Assign each component a `layer` integer. The rule: **higher layer = closer to domain core (more stable, fewer external dependencies). Lower layer = closer to external world (more volatile, I/O-bound).**
 
-**Common patterns:**
-- Laravel: Controllers → Services → Ports → Adapters → Models
-- Express/NestJS: Routes/Controllers → Services → Repositories → Models
-- Next.js: Pages → Components → Hooks → API Routes → Services
-- Django: Views → Serializers → Services → Models
-- Spring Boot: Controllers → Services → Repositories → Entities
-- Go: Handlers → Services → Repositories → Models
-- Generic: Group by directory responsibility
+Both layouts use this value — dagre places higher layers lower on screen, concentric places them at the center.
+
+**Reference mappings** (layer numbers in parentheses — adapt to actual project structure):
+
+MVC / Layered:
+- Laravel: External(0) → Controllers(1) → Services(2) → Models(3)
+- Rails: External(0) → Controllers(1) → Services(2) → Models(3)
+- Django: External(0) → Views(1) → Serializers(2) → Services(3) → Models(4)
+- Spring Boot: External(0) → Controllers(1) → Services(2) → Repositories(3) → Entities(4)
+- NestJS: External(0) → Controllers(1) → Services(2) → Repositories(3) → Entities(4)
+- Next.js App Router: External(0) → Route Handlers/Pages(1) → Components(2) → Hooks/Services(3) → Data Access(4)
+- FastAPI: External(0) → Routers(1) → Services(2) → Repositories(3) → Models(4)
+
+DDD / Clean Architecture / Hexagonal (use `"layout": "concentric"`):
+- Generic: External(0) → Adapters(1) → Controllers(2) → Application Services(3) → Ports(4) → Domain Entities(5)
+- Go (Hex): External(0) → Handlers(1) → Adapters(2) → Use Cases(3) → Ports(4) → Domain(5)
+- Flutter (Clean): External(0) → Data Sources(1) → Repositories(2) → Use Cases(3) → Entities(4)
+
+Serverless / Microservices:
+- SST/Lambda: External(0) → API Gateway(1) → Lambda Handlers(2) → Services(3) → Domain(4)
+- Microservices: External(0) → Gateway/BFF(1) → Service Boundaries(2) → Internal Services(3) → Shared Domain(4)
+
+For unlisted frameworks: group by directory responsibility and apply the abstract rule above.
 
 ## Phase 4: Read Key Files
 For each layer, read representative files to extract:
@@ -115,11 +130,11 @@ After writing the file:
 
 ### Node Rules
 - `id`: kebab-case, prefixed by category abbreviation (ctrl-, svc-, port-, adpt-, model-, ext-, job-, dto-)
-- `layer`: 0=external, 1=entry points, 2=application logic, 3=abstractions, 4=implementations, 5=data
+- `layer`: non-negative integer. **Higher = closer to domain core / more stable. Lower = closer to external world / more volatile.** Dagre (TB) places higher layers lower on screen; concentric places them at center. Use as many layers as the architecture requires (typically 3-6). Example for DDD: 0=external, 1=adapters, 2=controllers, 3=app services, 4=ports, 5=domain entities. Example for MVC: 0=external, 1=controllers, 2=services, 3=models.
 - `category`: one of controller, service, port, adapter, model, external, job, dto (or custom)
 - `label`: display name for the node
 - `filePath`: relative from project root
-- `depth` (optional): 0=overview (boundary), 1=structure (internal), 2=detail (implementation). Auto-inferred from category if omitted
+- `depth` (optional): 0=overview, 1=structure, 2=detail. Auto-inferred from `layer` if omitted: with 3+ unique layers, lowest → 0, middle → 1, highest → 2. With 1-2 layers, all nodes get depth 0 (always visible).
 - `useCases`: array of use case IDs this node participates in
 
 ### Edge Rules

package/dist/templates/slash-commands/gemini/archrip-scan.md

@@ -25,16 +25,31 @@ Read existing documentation to understand architecture context:
 3. Use this knowledge to inform the analysis — documentation often reveals architectural intent that code alone does not show (use cases, business context, external dependencies)
 
 ## Phase 3: Layer Identification
-Based on the framework, identify architectural layers:
+Assign each component a `layer` integer. The rule: **higher layer = closer to domain core (more stable, fewer external dependencies). Lower layer = closer to external world (more volatile, I/O-bound).**
 
-**Common patterns:**
-- Laravel: Controllers → Services → Ports → Adapters → Models
-- Express/NestJS: Routes/Controllers → Services → Repositories → Models
-- Next.js: Pages → Components → Hooks → API Routes → Services
-- Django: Views → Serializers → Services → Models
-- Spring Boot: Controllers → Services → Repositories → Entities
-- Go: Handlers → Services → Repositories → Models
-- Generic: Group by directory responsibility
+Both layouts use this value — dagre places higher layers lower on screen, concentric places them at the center.
+
+**Reference mappings** (layer numbers in parentheses — adapt to actual project structure):
+
+MVC / Layered:
+- Laravel: External(0) → Controllers(1) → Services(2) → Models(3)
+- Rails: External(0) → Controllers(1) → Services(2) → Models(3)
+- Django: External(0) → Views(1) → Serializers(2) → Services(3) → Models(4)
+- Spring Boot: External(0) → Controllers(1) → Services(2) → Repositories(3) → Entities(4)
+- NestJS: External(0) → Controllers(1) → Services(2) → Repositories(3) → Entities(4)
+- Next.js App Router: External(0) → Route Handlers/Pages(1) → Components(2) → Hooks/Services(3) → Data Access(4)
+- FastAPI: External(0) → Routers(1) → Services(2) → Repositories(3) → Models(4)
+
+DDD / Clean Architecture / Hexagonal (use `"layout": "concentric"`):
+- Generic: External(0) → Adapters(1) → Controllers(2) → Application Services(3) → Ports(4) → Domain Entities(5)
+- Go (Hex): External(0) → Handlers(1) → Adapters(2) → Use Cases(3) → Ports(4) → Domain(5)
+- Flutter (Clean): External(0) → Data Sources(1) → Repositories(2) → Use Cases(3) → Entities(4)
+
+Serverless / Microservices:
+- SST/Lambda: External(0) → API Gateway(1) → Lambda Handlers(2) → Services(3) → Domain(4)
+- Microservices: External(0) → Gateway/BFF(1) → Service Boundaries(2) → Internal Services(3) → Shared Domain(4)
+
+For unlisted frameworks: group by directory responsibility and apply the abstract rule above.
 
 ## Phase 4: Read Key Files
 For each layer, read representative files to extract:
@@ -115,11 +130,11 @@ After writing the file:
 
 ### Node Rules
 - `id`: kebab-case, prefixed by category abbreviation (ctrl-, svc-, port-, adpt-, model-, ext-, job-, dto-)
-- `layer`: 0=external, 1=entry points, 2=application logic, 3=abstractions, 4=implementations, 5=data
+- `layer`: non-negative integer. **Higher = closer to domain core / more stable. Lower = closer to external world / more volatile.** Dagre (TB) places higher layers lower on screen; concentric places them at center. Use as many layers as the architecture requires (typically 3-6). Example for DDD: 0=external, 1=adapters, 2=controllers, 3=app services, 4=ports, 5=domain entities. Example for MVC: 0=external, 1=controllers, 2=services, 3=models.
 - `category`: one of controller, service, port, adapter, model, external, job, dto (or custom)
 - `label`: display name for the node
 - `filePath`: relative from project root
-- `depth` (optional): 0=overview (boundary), 1=structure (internal), 2=detail (implementation). Auto-inferred from category if omitted
+- `depth` (optional): 0=overview, 1=structure, 2=detail. Auto-inferred from `layer` if omitted: with 3+ unique layers, lowest → 0, middle → 1, highest → 2. With 1-2 layers, all nodes get depth 0 (always visible).
 - `useCases`: array of use case IDs this node participates in
 
 ### Edge Rules

package/dist/viewer-template/package.json

@@ -9,6 +9,7 @@
     "preview": "vite preview"
   },
   "dependencies": {
+    "@dagrejs/dagre": "^1.1.4",
     "@xyflow/react": "^12.10.0",
     "nuqs": "^2.8.8",
     "react": "^19.2.0",

package/dist/viewer-template/src/App.tsx

@@ -14,6 +14,7 @@ import '@xyflow/react/dist/style.css';
 import type { ArchFlowNode, ArchNodeData } from './types.ts';
 import { getCategoryColors } from './types.ts';
 import { ArchNode } from './components/nodes/ArchNode.tsx';
+import { GroupNode } from './components/nodes/GroupNode.tsx';
 import { DetailPanel } from './components/DetailPanel.tsx';
 import { UseCaseFilter } from './components/UseCaseFilter.tsx';
 import { DepthFilter } from './components/DepthFilter.tsx';
@@ -24,11 +25,11 @@ import { useDepthFilter } from './hooks/useDepthFilter.ts';
 import { useUseCaseFilter } from './hooks/useUseCaseFilter.ts';
 import { useTheme } from './hooks/useTheme.ts';
 
-const nodeTypes = { archNode: ArchNode };
+const nodeTypes = { archNode: ArchNode, groupNode: GroupNode };
 
 function AppInner() {
-  const { nodes, edges, useCases, projectName, loading, error, onNodesChange, onEdgesChange } = useArchitecture();
-  const { depthLevel, setDepthLevel, visibleNodes, visibleEdges } = useDepthFilter(nodes, edges);
+  const { nodes, edges, useCases, projectName, layoutType, loading, error, onNodesChange, onEdgesChange } = useArchitecture();
+  const { depthLevel, setDepthLevel, visibleNodes, visibleEdges } = useDepthFilter(nodes, edges, layoutType);
   const { selectedUseCase, setSelectedUseCase, categories, filteredNodes, filteredEdges } = useUseCaseFilter(visibleNodes, visibleEdges, useCases);
   const [selectedNodeId, setSelectedNodeId] = useQueryState('node', parseAsString.withOptions({ history: 'replace' }));
   const { theme, toggleTheme } = useTheme();
@@ -36,9 +37,9 @@ function AppInner() {
 
   const selectedNodeData: ArchNodeData | null = useMemo(() => {
     if (!selectedNodeId) return null;
-    const found = nodes.find((n) => n.id === selectedNodeId);
+    const found = visibleNodes.find((n) => n.id === selectedNodeId);
     return found?.data ?? null;
-  }, [selectedNodeId, nodes]);
+  }, [selectedNodeId, visibleNodes]);
 
   const onNodeClick: NodeMouseHandler<ArchFlowNode> = useCallback((_event, node) => {
     void setSelectedNodeId(node.id);