frontend-patterns/research/reviews/FeatureDeploymentBoundaries.md

Feature organization and deployment boundaries — 2026-09-26

Status: bounded static source review by Codex, WP-0003 T01. Seventeen inspected files from three pinned example repositories, plus two primary documentation pages. No application build, CI run, deployed service, traffic or rollback drill was executed. Manifest records file URLs, commit IDs and SHA-256. These are demonstration implementations, not evidence of team autonomy in production.

Primary claims

Claim	Source / locator	Located observation	Limit / editorial implication
D01	SRC-0031 feature-sliced/examples, todo-app/src/features/toggle-task/index.ts, ui.tsx and model/toggle-task.ts	Feature entry exports UI/model; UI delegates toggling to a model using the task entity	Located partial feature grouping and interface; not proof of enforced import rules
D02	SRC-0031 todo-app/src/pages/tasks-list/index.tsx; package.json scripts	Page imports two feature entry points; package has one react-scripts application build	Source capability boundaries do not themselves create separate release artifacts
D03	SRC-0031 entities/task/model/tasks.ts; shared/api/typicode/tasks.ts	Entity effects call a shared HTTP adapter; toggle model directly updates the entity store	Capability code need not own its storage adapter; this demo does not establish durable write behavior
D04	SRC-0032 root-config/src/react-mf-root-config.js and src/index.ejs	Runtime imports resolve named applications via an external import map; layout declares routes and navbar loader/error UI	Composition and binding are separate from feature internals; fallback presence alone does not prove failure recovery
D05	SRC-0032 and SRC-0033 .github/workflows/build_and_deploy.yml	Each repo builds its artifact, uploads under a run-specific path, then updates its named import-map entry; root additionally uploads index.html	Located separate release definitions, not observed successful or atomic production releases
D06	SRC-0033 src/react-mf-navbar.js and root.component.js	Navbar exports bootstrap/mount/unmount and adapts a React tree with a rendering fallback	A concrete host/feature lifecycle interface; authentication, compatibility and teardown correctness remain untested
D07	SRC-0032 src/react-mf-root-config.js	Layout activation and start occur inside successful styleguide-import continuation	Shared runtime prerequisite can affect startup despite separate artifact pipelines; no outage was induced
D08	SRC-0034 single-spa recommended setup, In-browser versus build-time modules / Deployment and CI / State management	Documents runtime module binding, artifact upload followed by import-map update, concurrent map-update hazards and shared-state compatibility costs	Repository layout is not our proposed independence criterion; compatibility and activation need explicit contracts
D09	SRC-0035 webpack Module Federation, Separate builds per page / Sharing modules	Describes separate page/container builds, shell changes for routes and shared dependency negotiation	Another composition mechanism, not another verified application or automatic version compatibility

SRC-0031 commit 3050d1080506823df79c77457b96b47a835f87c8 (2025-08-08); SRC-0032 b5414dcf7b4ecda95f11ada3821e30d2acfd9e4e (2025-08-18); SRC-0033 55ff88e74714d12d3e3447250e34a2b7742e91f6 (2025-06-19). Dates are commit timestamps, not release evidence. Documentation accessed 2026-09-26, living revisions unknown; single-spa page identifies its 6.x documentation line. Dependency ranges in source package files are not asserted as installed versions.

Boundary comparison

Boundary	Feature-sliced todo example	Microfrontend example family	What remains to verify
Source imports	Page consumes feature public entry points; model consumes entity API	Navbar internals behind lifecycle exports; root imports named application	Enforced dependency direction and unintended private imports
Build	Application-level build script	Separate root/navbar build scripts and CI artifacts	Actual build output and dependency resolution
Activation	No per-feature activation mechanism located in inspected files	Named map entries updated after artifact upload	Atomic map updates, cached maps, old sessions and rollback
Runtime dependency	Shared entity state and API adapter	Shared styleguide gates root startup; shared runtime packages may couple versions	Outage, version skew and mixed-version behavior
Organizational ownership	Unknown	Unknown; separate repositories/workflows are not team evidence	Who owns interfaces, release decisions and incident response

The root-config and navbar repositories belong to one example family. FSD supplies a contrasting source-layout example, not a second independent implementation of a complete independent-release contract. None establishes recurrence of the full new hypothesis.

Counterexamples and generative consequence

A feature can have a good public code interface and still ship in one artifact. A separate artifact can still require coordinated releases when shared state or a host interface breaks compatibility. A successful upload can be invisible until its binding changes. Changing a binding does not necessarily change a module already loaded in a long-running tab. Rolling back assets cannot be assumed to reverse domain effects or restore compatibility after an incompatible backend migration. These are proposed review obligations, not observed bugs in these example projects.

Keep Vertical Feature Slice scoped to code organization. Develop the existing Independent Feature Boundary seed around independently releasable capabilities and explicit composition contracts. Do not make it require a microfrontend framework, separate Git repository or a network request per component. Failure Boundary and Islands of Interactivity stay separate decisions.

Provisional VC-06 applies the distinction to independent teams/releases, shared navigation and partial outages. It includes a single-release constraint branch, without declaring the M2 walkthrough gate complete.

Next evidence

Under WP-0003 T01, exercise two compatible feature versions against one unchanged host, a deliberately incompatible version, a failed asset load and rollback of the activation binding with both fresh and already-running sessions. Check startup-critical shared resources separately from feature-local failure. Do not use existing deployment workflows or credentials to perform the experiment; a local controlled harness suffices. Q06 is sharpened, not closed. No additional inference was needed for this review.

Executed synthetic follow-up

Feature release experiment now exercises the proposed version/load/rollback cases in an authored native-module host. This does not change the static-only status of the upstream repositories inspected above.