Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a0cffe-206f-7323-89d3-b20ca4cf4bf9
117 lines
8.2 KiB
Markdown
117 lines
8.2 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.
|
||
|
||
## 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.
|