and route collisions are integration contracts. This brief does not require a specific
framework, separate repositories, or separate origins.
## Baseline narrative without the pattern catalog
Produce a versioned artifact for each capability and load it through a host-selected
binding. Define mount/unmount, inputs/events and supported host/API versions. Keep
routing and shared state small enough that compatible feature changes do not force
all teams to release together. Publish before activating; retain prior compatible
artifacts and declare how old tabs continue operating. Show a local load failure while
keeping navigation available. Test dependency failures that can still affect the host.
The same obligations can be expressed without pattern names; no decision benefit is proven.
## Decisions
| Order | Context / forces | Pattern reference | Alternative / reason | Resulting context | Evidence |
| --- | --- | --- | --- | --- | --- |
| 1 | Independent release cadence versus integration cost | [Independent Feature Boundary](../candidates/IndependentFeatureBoundary.md) | One application release violates the assumed cadence; source folders alone cannot satisfy it | Separate artifacts plus explicit composition/activation contract | D04–D06/D08 |
| 2 | Local change cohesion versus shared dependencies | [Vertical Feature Slice](../candidates/VerticalFeatureSlice.md) | Global technical folders can scatter capability changes; do not force every shared primitive into a feature | Internal code organization can vary independently of release packaging | D01–D03 |
| 3 | Shared navigation and deep links | [URL-addressable State](../candidates/URLAddressableState.md), host-owned route context | Uncoordinated routers can disagree; a shared route schema still needs compatibility | Host selects capability; feature owns a declared subroute space | D04, editorial proposal |
| 4 | Partial outage versus coherent experience | [Failure Boundary](../candidates/FailureBoundary.md), scoped to load/render/lifecycle separately | A render boundary alone cannot handle a failed download | Host retains navigation and exposes a local error/retry path | D04/D06, runtime unverified |
| 5 | Independent activation versus version skew | Independent Feature Boundary | Upload-only is not activation; simultaneous incompatible upgrades defeat the stated independence | Supported version combinations and binding rollback defined | D05/D08/D09 |
D01–D09 resolve in the [source review](../reviews/FeatureDeploymentBoundaries.md).
Independent source, build, activation and failure boundaries are distinct decisions.
## Failure and recovery trace
1. Host H1 activates Reports R1 and Account A1 from a declared binding. Route and
public data/event contracts have tested compatibility ranges. This is an assumption
to be verified, not an observed guarantee of the example repositories.
2. Publish Reports R2 to a distinct retained URL, validate H1/R2/A1 and relevant API
combinations, then update only the Reports binding. Concurrent binding changes
need an atomic or conflict-detecting update contract.
3. A fresh session obtains R2; an open session may retain R1. Do not assume import-map
replacement hot-swaps existing modules. Define whether a session remains pinned,
reloads at a safe boundary or uses an explicit supported replacement protocol.
4. If R2 fails to load, keep shell navigation available and show an accessible feature
error. Retry identity here is a load concern; do not resubmit a domain mutation
merely because the feature remounts. Guard teardown callbacks from changing focus
or state owned by a newer instance.
5. If R2 requires an incompatible host/shared-state contract, do not claim independent
release. Reject activation or coordinate a migration with support for old sessions.
6. Roll back the Reports binding to retained R1 for applicable sessions. Verify API/data
compatibility before promising recovery; bytes alone cannot undo server effects.
A shared startup dependency outage is a separate scenario: local feature fallbacks
cannot protect a shell that never starts.
## Change one constraint
Replace independent releases with **one coordinated release cadence**; keep separate
teams, shared navigation and partial-outage requirements. Internal feature interfaces
and ownership can remain, but a single tested application artifact may now satisfy
the brief with less activation/version-skew machinery. Retain scoped failure handling;
do not infer it disappears when deployment units merge. This branch demonstrates why
Vertical Feature Slice need not imply Independent Feature Boundary.