clean-architecture-frontend-template/docs/architecture/capability-consumer-experience.md

# Capability consumer experience baseline

Correctness inside a reusable capability is not sufficient. The platform is
also evaluated by how much of that correctness a normal feature developer must
understand.

These measurements are baselines, not score targets. A lower line count is not
automatically better if it hides business semantics or creates a universal
repository abstraction.

## Scenario A — reference REST feature

The existing reference feature is the executable REST consumer.

It covers list/detail/create behavior, mapping, typed operation inputs,
application ports and an optimistic mutation path.

Current source size:

| Feature-owned area | LOC |
| --- | ---: |
| `application/reference-feature-api.ts` | 91 |
| `contracts/reference-mapper.ts` | 109 |
| `adapters/reference-http-gateway.ts` | 65 |
| `adapters/create-reference-feature-input.ts` | 41 |
| Total measured boundary/application source | 306 |

The important boundary metric is not the raw total. It is what those files need
to know about the platform.

Current result:

- HTTP platform imports in the feature adapter layer: 2 files,
- canonical import path used by both:
  `src/adapters/http/index.ts`,
- direct imports of `http-execution-v3.ts`, retry scheduler, response reader,
  auth admission or effect-certainty internals: 0,
- feature gateway owns transport failure projection: 0,
- feature gateway chooses operation ID, route ID, exact input/value type and
  mapper: yes,
- central installed files own feature-specific adapter/runtime wiring: no;
  feature-owned contributions are aggregated centrally.

The reusable HTTP capability now owns execution-outcome normalization through
`createFeatureHttpBinding`. A feature may still implement a custom outbound
adapter behind its application port when the reusable contract does not match
its business requirement.

## Scenario B — IndexedDB local draft

The original executable consumer probe remains at:

`tests/contract/consumer-experience/indexeddb-local-draft.test.ts`

with its isolated fixture:

`tests/contract/consumer-experience/fixtures/local-draft-feature.ts`

The architecture is now also exercised by a real vertical slice under:

`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 |
| --- | ---: |
| feature-owned fixture LOC | 97 |
| platform import statements | 1 |
| native IndexedDB API references | 0 |
| `src/adapters/storage/indexeddb/**` imports | 0 |
| runtime-internal IndexedDB types imported by feature | 0 |

The feature depends only on the public application boundary:

`src/application/ports/browser-file-storage/index.ts`

and specifically `IndexedDbRepositoryPort<LocalDraft, never>`.

The contract test rejects feature source that reaches for
`globalThis.indexedDB`, `IDBFactory`, `IDBDatabase`, `IDBTransaction`,
`IDBObjectStore` or the concrete IndexedDB adapter directory.

## What this does and does not prove

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:

- dataset scope and storage policy,
- physical store governance,
- retention/idempotency stores,
- schema migrations,
- codec and query policy,
- lifecycle authority,
- durability, scheduling and observation.

That complexity belongs at the composition/platform boundary, not in the
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

For each new product feature, record:

- feature-owned adapter LOC,
- platform glue LOC,
- files changed,
- central catalog edits,
- direct imports from capability-internal modules,
- native browser/network API references,
- duplicated failure/retry/lifecycle policy.

A healthy feature path should look like:

1. domain type and invariant,
2. use case,
3. business port,
4. feature-owned mapper/codec and policy,
5. capability-specific binding,
6. presentation controller/page.

The feature should not need the retry scheduler, abort ownership,
effect-certainty machinery, IndexedDB transaction lifecycle, OPFS journal,
reconnect coordinator or provider process model.