frontend-patterns/research/walkthroughs/VC06-MicrofrontendEstate.md
tegwick f273a190f0 Test activation conflicts and draft-preserving application reload
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0cffe-206f-7323-89d3-b20ca4cf4bf9
2026-09-26 23:30:15 +02:00

117 lines
8.2 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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.
## Executed model follow-up — 2026-09-26
[Seven-scenario native-module experiment](../reviews/FeatureReleaseExperiment.md)
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.
## Activation/update-reload follow-up — 2026-09-26
[21 expected observations](../reviews/ActivationConflictsAndReload.md) now cover
stale binding writers and the application-controlled reload path with unfinished work.
Conditional replacement rejects stale maps; disjoint intent is explicitly reapplied,
while conflicting rollback awaits a decision. Preserve the latest authorized draft
before reload and revalidate its schema on the next document; a preflight check can
be invalidated by a later activation. Storage failure and unknown write outcome block
the fixture's reload. This does not establish distributed-map atomicity, native-unload
protection, backend acceptance, authorized retention or complete VC-06 validation.