##### Context
Rempla.Web is the user-facing web application for benefactors and beneficiaries. It needs a rich, interactive frontend while maintaining simplicity — no build tools, no framework lock-in, and clean separation between server-rendered content and client-side composition.

Verita's TD.Pwa project established a proven pattern for this exact problem: a panel-based SPA shell using vanilla JS ES modules, import maps for dependency management, and server-side partial views fetched on demand. This pattern has been running in production on the TXI platform.

##### Decision
Use the **TD.Pwa panel-based SPA architecture** for Rempla.Web, adapted for .NET 10 without PWA features.

Key elements:
- **Single HTML shell** served by `LayoutController.Index` — no Razor layout chain
- **Import maps** for ES module resolution (no webpack, no bundler, no npm)
- **Panel-based layout** — named `data-panel` divs (top, left, center, right, bottom, modal) that modules render into
- **Route-driven module loading** — JS router maps URL paths to module imports; modules fetch server partials and inject HTML
- **JS module contract** — every module exports `init()`, `load()`, `data`, `events`, `layout` for consistent lifecycle
- **`ImportMapFactory`** — server-side utility reads `import-map.json` and appends version strings for cache busting
- **Bootstrap 5.3** served locally (not CDN) for the base CSS/JS layer

Explicitly excluded from TD.Pwa:
- No service worker or PWA manifest (not needed for this product)
- No Universal Router library (simplified inline route table)

##### Rationale
- **Zero build tooling**: Import maps are natively supported in modern browsers. No `node_modules`, no transpilation, no CI build step for frontend assets. This eliminates an entire class of maintenance burden.
- **Proven pattern**: TD.Pwa has validated this architecture in a production .NET application with complex domain screens. The panel/module/router abstractions scale to real features.
- **Server-side partials**: Controllers return focused HTML fragments. This keeps the rendering close to the data (Razor has full model access) while the client handles composition and lifecycle.
- **Progressive enhancement path**: Starting with server-rendered partials means features work immediately. Client-side interactivity layers on top via the module's `events` and `data` hooks.
- **Independent from Rempla.Admin**: The admin portal uses Razor Pages (ADR-003). Keeping the architectures separate means each app uses the right tool for its audience.

##### Consequences
- Frontend debugging happens in the browser (no source maps from a build step — but `sourceURL` comments in modules provide clean stack traces)
- New team members need to understand the module contract and panel system (documented in CLAUDE.md)
- Import map entries must be manually maintained in `import-map.json` when adding new modules
- Bootstrap is vendored locally and must be updated manually

---
**Decision Date**: March 4, 2026
**Author**: Lead Architect