feat: 기능 추가 과정중

docs/architecture/layers.md

@@ -10,6 +10,7 @@ adapters implement application-owned ports and are assembled only in
 | `application` | use cases, ports, orchestration, view-models | domain and application siblings |
 | `presentation` | routes, components, user interaction and view state | application public API and shared UI |
 | `adapters` | browser and third-party implementations of application ports | application ports and limited domain values |
+| `features/<id>` | removable vertical domain/application/contracts/adapters/presentation slice | the same inward rule plus platform public boundaries |
 | `bootstrap` | runtime configuration, adapter construction and React mount | all selected runtime modules |
 
 The following edges are forbidden:
@@ -18,25 +19,41 @@ The following edges are forbidden:
 - application to presentation, concrete adapters, bootstrap, React, or browser globals
 - presentation to concrete adapters, raw DTO schemas, or storage implementations
 - an adapter to presentation, bootstrap internals, or another concrete adapter
+- feature domain/application to its presentation or outbound adapter, and
+  feature presentation to its outbound adapter
 
 `bootstrap` contains composition only. Business rules and page-specific
 orchestration belong to domain/application.
 
-This table is the current coarse-grained rule. The
-[ports, adapters, and feature-boundary target](./frontend-ports-adapters-and-boundaries.md)
-defines the missing application input boundary, explains that `presentation`
-acts as the inbound adapter, and separates current outbound adapters from
-project-selected capabilities. The
-[platform capability review](./frontend-platform-capability-review.md) records
-where the current composition still bypasses this intended rule.
+The [ports, adapters, and feature-boundary contract](./frontend-ports-adapters-and-boundaries.md)
+explains how `presentation` acts as the inbound adapter and how feature
+application APIs augment the generic typed input registry. Concrete output
+ports are composed in bootstrap and stay hidden behind the application facade.
+Project-selected capabilities still implement the same output boundaries.
 
-Architecture reports use this shape:
+`check:architecture` keeps dependency-cruiser's report and adds the
+authoritative TypeScript-aware graph below it:
 
 ```json
 {
-  "schemaVersion": 1,
-  "generatedAt": "ISO-8601",
-  "rules": [{ "name": "rule-id", "severity": "error", "violations": 0 }],
-  "summary": { "errors": 0, "warnings": 0 }
+  "staticImportGraph": {
+    "analyzer": "babel-parser-node-resolver",
+    "modules": [],
+    "dependencies": [],
+    "unresolved": [],
+    "parseFailures": [],
+    "cycles": [],
+    "violations": [],
+    "summary": { "errors": 0 },
+    "fixtureChecks": { "passed": true, "checks": [], "failures": [] }
+  }
 }
 ```
+
+The graph scans TypeScript and TSX, including static, dynamic, type, CommonJS
+and JSDoc import references. It applies the path rules from
+`.dependency-cruiser.json`, requires explicit TypeScript extensions for local
+source imports, and fails closed on JavaScript-family source/specifiers,
+unsupported rule shapes, unresolved imports, parse failures, error-severity
+layer violations, or cycles. Regression fixtures prove the allowed resolver
+path and each rejection class.