refactor: 프론트엔드 리펙토링

docs/architecture/capability-consumer-experience.md

@@ -48,18 +48,39 @@ its business requirement.
 
 ## Scenario B — IndexedDB local draft
 
-An executable consumer probe lives at:
+The original executable consumer probe remains at:
 
 `tests/contract/consumer-experience/indexeddb-local-draft.test.ts`
 
-with the feature-owned fixture:
+with its isolated fixture:
 
 `tests/contract/consumer-experience/fixtures/local-draft-feature.ts`
 
-The fixture models a small local-draft feature with save/find/remove and
-optimistic revision checking.
+The architecture is now also exercised by a real vertical slice under:
 
-Measured result:
+`src/features/local-draft-feature`
+
+It owns the Local Draft domain/application API and binds an
+`IndexedDbRepositoryPort<LocalDraft, never>` in its feature adapter. The
+cross-capability composition contract lives at:
+
+`tests/contract/reusable-capability/feature-adapter-composition.test.ts`
+
+That test composes one HTTP-only contribution and the IndexedDB-only Local Draft
+contribution through the same generic catalog path.
+
+The browser-level composition proof lives at:
+
+`tests/browser-capabilities/local-draft-composition.spec.ts`
+
+It runs against native browser IndexedDB. The test creates the platform
+`createIndexedDbRuntime`, exposes that runtime through the typed
+`createIndexedDbRepositoryProvider`, composes
+`LOCAL_DRAFT_FEATURE_ADAPTER_CONTRIBUTION`, then executes Local Draft
+save/find/remove through the feature API. The Local Draft feature still does
+not import the IndexedDB runtime or native browser API.
+
+Measured probe result:
 
 | Metric | Result |
 | --- | ---: |
@@ -81,8 +102,11 @@ The contract test rejects feature source that reaches for
 
 ## What this does and does not prove
 
-The probe confirms that **feature business code does not need native IndexedDB
-knowledge** once an `IndexedDbRepositoryPort` has been composed.
+The contract probe confirms that **feature business code does not need native
+IndexedDB knowledge** once an `IndexedDbRepositoryPort` has been composed.
+The browser-capability proof additionally confirms that the same feature
+contribution works when that port is backed by the repository's real
+`createIndexedDbRuntime` and native IndexedDB implementation.
 
 It does not prove that composition of `createIndexedDbRuntime` is cheap.
 That constructor still owns substantial infrastructure policy:
@@ -96,10 +120,15 @@ That constructor still owns substantial infrastructure policy:
 - durability, scheduling and observation.
 
 That complexity belongs at the composition/platform boundary, not in the
-feature. A new `create...Repository<T>` convenience factory should be added
-only when a second real product consumer demonstrates which subset is stable
-enough to become a reusable profile. Creating one now would guess at policy and
-risk producing a universal storage abstraction.
+feature. The Local Draft vertical slice is now the second concrete consumer, and
+it confirms that the stable seam is the typed repository provider plus a
+feature-owned repository identity. It does **not** show that dataset scope,
+retention, migration, codec or lifecycle-authority configuration can be safely
+collapsed into one universal `create...Repository<T>` factory.
+
+A convenience profile should therefore be introduced only after another
+IndexedDB-backed product feature repeats the same infrastructure policy, not
+merely because two features consume the same repository port.
 
 ## Consumer-quality review checklist