frontend-patterns/research/walkthroughs/VC06-MicrofrontendEstate.md

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	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	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, 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, 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. 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 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.

Executed model follow-up — 2026-09-26

Seven-scenario native-module experiment now supports steps 2–6's publication/activation, version mismatch, failed loading and session-scoped rollback distinctions in a synthetic host. Both browsers meet all seven expected observations, including deliberate failures. Old lazy sessions need retained artifacts even when loaded old sessions still work. Post-import compatibility gates cannot prevent evaluation side effects. Shared startup outage is a separate fault scope.

This supersedes the lack of any load/rollback execution in the initial self-review, but the quality criterion remains revise: browser focus/accessibility, unsaved work, real API/data compatibility and independent review are still unverified. VC-06 stays provisional; no production release or M2 acceptance is inferred.