93 lines
6.6 KiB
Markdown
93 lines
6.6 KiB
Markdown
|
# VC-06 — Microfrontend estate
|
|||
|
|
|
|||
|
|
Status: provisional draft, editorial self-review only. Codex, 2026-09-26.
|
|||
|
|
Synthetic fixed brief; exploratory preparation under WP-0003 T01/T02, not M2 acceptance.
|
|||
|
|
Corpus: seventeen research hypotheses; no canonical admission.
|
|||
|
|
|
|||
|
|
## Fixed brief and assumptions
|
|||
|
|
|
|||
|
|
Independent teams/releases, shared navigation and partial outages are the fixed
|
|||
|
|
constraints. For this exercise, assume a host shell with two capabilities, Reports
|
|||
|
|
and Account, served in one browser context. Each team should release a compatible
|
|||
|
|
change without rebuilding the host or the other capability. Host owns top-level route
|
|||
|
|
selection and persistent navigation; teams own declared subroutes and lifecycle cleanup.
|
|||
|
|
The service remains authoritative for protected data and writes. Offline edits,
|
|||
|
|
collaborative editing and numerical latency budgets are unspecified and not promised.
|
|||
|
|
|
|||
|
|
Keyboard/focus continuity, meaningful load/error feedback and usable navigation during
|
|||
|
|
a feature load failure are required. Separate bundles confer no authorization or
|
|||
|
|
security isolation. Authentication/session policy, dependency versions, event schemas
|
|||
|
|
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.
|
|||
|
|
|
|||
|
|
## Review
|
|||
|
|
|
|||
|
|
| Criterion | Assessment | Reason |
|
|||
|
|
| --- | --- | --- |
|
|||
|
|
| Traceability | pass (editorial) | Pinned source mechanisms separated from proposed release contracts |
|
|||
|
|
| Configuration coherence | pass (editorial) | Host routes, lifecycle and compatibility responsibilities explicit |
|
|||
|
|
| Usefulness beyond baseline | unknown | Same-author synthesis; baseline already contains the obligations |
|
|||
|
|
| Quality constraints | revise | No outage, keyboard/focus, old-session or rollback execution |
|
|||
|
|
| Changed constraint | pass (editorial) | Single cadence permits combining artifacts while retaining code boundaries |
|
|||
|
|
|
|||
|
|
## Gaps and ownership
|
|||
|
|
|
|||
|
|
[WP-0003 T01/T02](../../workplans/FEP-WP-0003-contrasting-schools.md) owns a local
|
|||
|
|
version-skew/load-failure/binding-rollback harness and independent walkthrough review.
|
|||
|
|
No cloud deployment, production artifact activation or operational team independence
|
|||
|
|
was verified. VC-04/05 remain planned; this draft does not complete VC-06's M2 gate.
|