tegwick
e34ec3fafe
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a0cffe-206f-7323-89d3-b20ca4cf4bf9
78 lines
7.2 KiB
Markdown
78 lines
7.2 KiB
Markdown
# 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](FeatureDeploymentSources.json) 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](https://single-spa.js.org/docs/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](https://webpack.js.org/concepts/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](../candidates/VerticalFeatureSlice.md) scoped to code
|
|
organization. Develop the existing [Independent Feature Boundary](../candidates/IndependentFeatureBoundary.md)
|
|
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](../candidates/FailureBoundary.md) and
|
|
[Islands of Interactivity](../candidates/IslandsOfInteractivity.md) stay separate decisions.
|
|
|
|
[Provisional VC-06](../walkthroughs/VC06-MicrofrontendEstate.md) 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](FeatureReleaseExperiment.md) 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.
|