Web
AuraScore 81/100

Micro-Frontend Shell Isolation Specification

Define contract interfaces, routing isolation, and shared state boundary specs for modular web frontends.

Use this template when designing an enterprise micro-frontend architecture where independent feature teams must coexist safely within a shared container shell.

Template

Role: Principal Frontend Architect specializing in modular enterprise web architectures.

Context

  • Host Shell Application: {{host_application}}
  • Child Micro-Apps: {{child_apps}}
  • Global State Mechanism: {{shared_state_library}}
  • Inter-App Event Bus: {{communication_bus}}
  • Performance Budget: {{bundle_budget_kb}} KB per sub-application
  • Target Browser Baseline: {{target_browsers}}

Task

Draft an exhaustive engineering specification that establishes runtime isolation, dependency sharing, lifecycle management, and communication protocols across all child applications mounting inside {{host_application}}.

Method

  1. Establish the mounting and unmounting lifecycle contract for {{child_apps}}, detailing mount, bootstrap, unmount, and error-boundary hooks.
  2. Define the routing arbitration model between the parent shell and child micro-apps to eliminate route collision risks.
  3. Specify the CSS scoping and DOM encapsulation strategy (such as Shadow DOM or scoped namespaces) compatible with {{target_browsers}}.
  4. Document the shared dependency matrix to prevent duplicate runtime loading while enforcing {{bundle_budget_kb}} limits.
  5. Design the event payloads and typed contracts for {{communication_bus}} to enforce decoupled inter-app communication.
  6. Formulate state synchronization boundaries when interacting with {{shared_state_library}} to prevent cross-app state contamination.
  7. Define the fault-tolerance fallback mechanism when a child micro-app fails to fetch or throws an uncaught runtime exception.

Constraints

  • MUST define explicit TypeScript interface signatures for all lifecycle hooks and cross-app events.
  • MUST NOT allow child micro-apps to directly mutate parent window global variables or bypass {{communication_bus}}.
  • MUST include a sub-application fallback render state for network timeout conditions.
  • Limit architectural trade-off discussions to practical implementation decisions under 200 words per section.

Output format

  • Section 1: Architectural Overview & Lifecycle State Diagram (Text-based ASCII)
  • Section 2: Host-to-Child Interface Contracts (TypeScript definitions)
  • Section 3: Isolation & Shared Dependency Policy
  • Section 4: Inter-App Communication Protocol
  • Section 5: Resilience, Error Handling, and Fallbacks

Self-review

  • Are all 6 context variables explicitly incorporated into the specification rules?
  • Are TypeScript interfaces complete with explicit parameter types rather than 'any'?
  • Does the routing and unmounting section prevent memory leaks during rapid navigation?
AuraScore breakdown
81/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering10/12 · Adequate

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness5/5 · Strong

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

developers
developers-web
technology-software
micro-frontends
frontend-architecture
typescript