frontend-patterns/research/plan/ResearchProgram.md

# Frontend Patterns Research Program

Status: ongoing · Program established: 2026-09-24

Start with [Research Protocol](ResearchProtocol.md), the
[executable research bench](../bench/README.md), then the
[validation cases](ValidationCases.md). Source families and pattern names below
are a research agenda, not completed evidence.

## 1. Objective

Develop a coherent Alexander-style pattern language for frontend architecture and design that is useful to both human practitioners and software agents.

The work should move from source collection toward:

1. common vocabulary,
2. recurring forces,
3. candidate patterns,
4. pattern relations,
5. generative sequences,
6. architecture decompositions,
7. technology mappings,
8. machine-readable retrieval and reasoning.

## 2. Research thesis

Frontend architecture is not fundamentally organized around frameworks.

It is organized around recurring decisions concerning:

- authority,
- addressability,
- projection,
- interaction,
- mutation,
- synchronization,
- reconciliation,
- composition,
- execution,
- quality boundaries.

Named architectures and frameworks are configurations or implementations of these decisions.

## 3. First research case

Use Ryan Carniato's "The Grand Unifying Architecture of Frontend" as the first extraction exercise.

Research tasks:

1. reconstruct its Navigation → Content → Affordance model,
2. identify implicit assumptions,
3. extract candidate patterns,
4. identify the forces each pattern resolves,
5. identify where server-authority assumptions cease to hold,
6. compare against local-first architectures,
7. compare against hypermedia architectures,
8. compare against SPA and server-component architectures,
9. map findings into the responsibility model,
10. retain useful concepts without treating the article as the canonical ontology.

## 4. Research streams

### Stream A — Historical GUI architecture

Study:

- MVC,
- MVP,
- Presentation Model,
- Presentation / Domain Separation,
- Flux / Redux,
- Elm architecture,
- event-driven UI.

Goal:

Identify durable state, dependency and interaction patterns that predate current web frameworks.

### Stream B — Web navigation and hypermedia

Study:

- document web,
- REST/hypermedia,
- progressive enhancement,
- HTML forms,
- HTMX-style server interaction,
- browser navigation semantics.

Goal:

Understand addressability, navigation, mutation and server projection.

### Stream C — Rendering and execution

Study:

- CSR,
- SSR,
- SSG,
- hydration,
- partial hydration,
- islands,
- server components,
- resumability,
- streaming,
- edge execution.

Goal:

Separate projection patterns from execution placement and delivery mechanisms.

### Stream D — State authority and synchronization

Study:

- client/server state,
- remote caches,
- optimistic UI,
- local-first,
- CRDTs,
- event sourcing,
- offline-first,
- subscriptions,
- push/pull synchronization.

Goal:

Establish a coherent authority/synchronization/reconciliation language.

### Stream E — Composition and organizational architecture

Study:

- component composition,
- feature slicing,
- microfrontends,
- design systems,
- frontend platform architecture,
- backend-for-frontend patterns,
- monorepos and deployment independence.

Goal:

Separate software composition from ownership and deployment boundaries.

### Stream F — Quality patterns

Study:

- accessibility,
- progressive enhancement,
- performance,
- fault containment,
- security,
- privacy,
- observability,
- recovery.

Goal:

Represent cross-cutting frontend qualities as architectural patterns and forces rather than afterthoughts.

## 5. Research method

For each source or architecture:

### Step 1 — Extract claims

Record what the source says without prematurely normalizing terminology.

### Step 2 — Identify forces

Ask what competing constraints make the proposed solution useful.

### Step 3 — Extract candidate patterns

Look for recurring configurations rather than named technologies.

### Step 4 — Normalize vocabulary

Map source-specific language into the current canon where possible.

### Step 5 — Find counterexamples

Test whether the pattern still holds under:

- offline operation,
- local authority,
- real-time collaboration,
- very low interaction density,
- high interaction density,
- independent deployment,
- unreliable networks,
- strong accessibility requirements.

### Step 6 — Establish relations

Record:

- requires,
- enables,
- refines,
- alternatives,
- conflicts,
- resulting contexts.

### Step 7 — Test generativity

Ask whether the pattern helps produce a next architectural decision.

### Step 8 — Promote cautiously

Move a concept into `patterns/` only when it is sufficiently stable and reusable.

## 6. Initial source families

Create a source catalog spanning:

- Christopher Alexander and pattern-language literature,
- Martin Fowler GUI architecture,
- REST and hypermedia literature,
- Redux / Elm / Flux,
- Feature-Sliced Design,
- microfrontends,
- local-first,
- web.dev rendering literature,
- Patterns.dev,
- framework architectural documentation,
- accessibility and progressive-enhancement literature,
- distributed-systems synchronization concepts.

## 7. Initial pattern extraction targets

Priority candidate patterns:

### Authority

- Server Authority
- Local Authority
- Replicated Authority
- Derived State
- Single Writer

### Address & navigation

- URL as Application State
- Resource Address
- Hierarchical Route
- Progressive Navigation

### Projection

- Static Projection
- Server Projection
- Client Projection
- Streaming Projection
- Islands of Interactivity

### Interaction

- Local Interaction State
- Immediate Feedback
- Pending State
- Optimistic Overlay

### Synchronization

- Invalidate and Reproject
- Pull Synchronization
- Push Synchronization
- Persistent Subscription
- Conflict-Free Merge
- Explicit Conflict

### Composition

- Presentation / Domain Separation
- Vertical Feature Slice
- Independent Feature Boundary
- Backend for Frontend

### Quality

- Progressive Enhancement
- Failure Boundary
- Accessible by Construction
- Performance Budget
- Observable Interaction

## 8. Validation architectures

The emerging language should be tested against at least these application types:

1. mostly-static publication,
2. e-commerce storefront,
3. administrative CRUD application,
4. high-interaction SaaS workspace,
5. real-time dashboard,
6. collaborative editor,
7. offline field application,
8. local-first personal tool,
9. large microfrontend estate,
10. mobile-web/PWA application.

A useful language should explain all ten without forcing them into one preferred architecture.

## 9. Agentic use cases

The infospace should eventually support prompts such as:

> Given this application description, identify the dominant forces and propose applicable patterns.

> Explain why the current architecture exhibits this failure mode.

> Which patterns are incompatible with our offline requirement?

> Decompose this framework architecture into technology-independent patterns.

> What pattern should be considered next after choosing server authority and streaming projection?

> Compare two architectures in terms of forces, not framework features.

This requires graph-friendly metadata and stable identifiers.

## 10. Execution and review gates

The phases are ordered by evidence dependencies, not calendar deadlines. A failed
review gate returns to the relevant research question; it does not force promotion.
Workplan files own execution status. This table defines intended outcomes.

| Phase | Work record | Deliverable and exit criterion |
| --- | --- | --- |
| M0 — Scaffold | FEP-WP-0001, finished | Intent, repository structure and State Hub integration exist. |
| M1 — Seed investigation | [FEP-WP-0002](../../workplans/FEP-WP-0002-seed-language-validation.md), blocked (independent evidence) | Reconciled schema; first source case and local-first contrast; 6–10 connected draft patterns; two completed case walkthroughs with evidence and counterexamples. |
| M2 — Broaden and challenge | [FEP-WP-0003](../../workplans/FEP-WP-0003-contrasting-schools.md), blocked (M1 open; bounded exploration permitted) | Evidence from all six streams; coverage matrix for all ten application types; revise, merge or reject candidates; complete at least four further contrasting cases. |
| M3 — Retrieval and empirical use | [FEP-WP-0004](../../workplans/FEP-WP-0004-reference-surface.md), blocked (M1/M2 prerequisites) | Validated metadata and graph export; held-out retrieval cases; at least two real repository studies tied to revisions; publish limitations. |

M1 does not require a large catalog. Six to ten patterns is a working scope cap,
not a maturity score. Expand toward the original 20–30 candidate ambition only
when additional patterns explain decisions the seed corpus cannot express.

### First research cycle

1. T01 of FEP-WP-0002 resolves the metadata contradictions in `REVIEW.md` with
   worked examples. Source extraction can begin while that contract is explored.
2. T02 completes the Carniato case and an independently sourced local-first case.
   Use the source-review template and record claims before normalizing vocabulary.
3. T03 selects a connected subset around authority, addressability, projection,
   local interaction, mutation and reconciliation. Walk through VC-01 and VC-02.
4. Review the evidence and question ledger. Record rejected patterns, missing
   responsibilities and ordering failures as carefully as supporting examples.
5. Write an M1 review under `research/reviews/` with pass/revise/defer for each
   criterion and links to artifacts. Hand unresolved work into the next workplan.

### Working rhythm and ownership

The executing repository agent owns artifact updates and State Hub synchronization;
`owner: codex` does not imply a scheduled or autonomous background run. Each research
session takes one bounded question or case, records evidence, updates the question
ledger and task status, and commits and syncs the result. Review at every phase gate
and whenever contradictory evidence changes the ontology. Review roles are explicit
in the resulting review document; a self-review must be identified as such.

### User-directed operational reuse — 2026-09-27

[WP-0008](../../workplans/FEP-WP-0008-use-driven-improvement.md) establishes the
minimal discovery → use receipt → bounded improvement loop with monthly human
oversight. Qualified draft use and feedback-led research can proceed before M1/M2/M3;
those gates still control their original evidence/admission claims. Independent-human
validation remains unclaimed and is not a routine operation dependency. Prioritize
real consumer outcomes and instrumentation over unprompted source expansion. Explicit
scheduler/executor proof is required before claiming unattended operation.

## 11. Open research questions

1. Is the current responsibility model minimal?
2. Should mutation be separate from intent?
3. Is reconciliation a responsibility or a synchronization subfamily?
4. Is addressability a frontend responsibility or a system-level concern?
5. Should rendering and projection remain distinct terms?
6. How should temporal behavior be represented?
7. How should pattern strength or evidence be measured?
8. Can pattern selection be meaningfully represented as constraint solving?
9. How should anti-patterns be modeled?
10. Can architecture health be described as unresolved or contradictory forces?

## 12. Definition of useful progress

The project is not advanced by adding pattern names alone.

Useful progress means improving one or more of:

- conceptual precision,
- pattern reuse,
- relation quality,
- generative power,
- evidence quality,
- applicability across architectures,
- retrieval quality for humans and agents.

## 13. Continuous learning and transparent evolution

Milestones are finite review boundaries within an ongoing research program. Passing
a gate does not finish the language. Evidence can narrow, supersede or demote a
pattern; preserve those changes as part of the knowledge base.

[FEP-WP-0006](../../workplans/FEP-WP-0006-language-evolution.md) establishes the
[evidence baseline and evolution method](../evolution/README.md). Its generated
[report](../evolution/EvolutionReport.md) separates current maturity, support tiers,
coverage, usefulness and learning outcomes. Early rapid learning and later diminishing
returns are testable expectations, not a prescribed curve or catalog-size target.
Measure prospective comparable cycles, retain unknown historical effort, and record
corroboration separately from consequential revisions. Broaden contexts when they
expose new decisions; improve structure when ambiguity prevents use; seek independent
validation when mechanisms stabilize. Keep fresh evaluation tasks separate from
consumed development anchors, including the immutable language pilot.