tegwick
a536ec52e0
Phase acceptance delivered (eight connected drafts, VC-01/VC-02, M1-SeedReview). Independent human review, fresh-scenario replication and M1 re-assessment move to residual FEP-WP-0009 (origin_ref FEP-WP-0002). WP-0003/0004/0008 dependencies now point to FEP-WP-0009-T03. M1 gate remains open. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 260325@bnt-lap001 Assistant-Session: 9fd4a535-80cb-4d87-825e-ac95a9162531
109 lines
4.4 KiB
Markdown
109 lines
4.4 KiB
Markdown
# frontend-patterns
|
|
|
|
An evolving research language for frontend architecture and design.
|
|
|
|
Start with the [0.1 research preview](START.md): two decision paths, seventeen
|
|
draft hypotheses and evidence-qualified implementation mappings. Canonical admission,
|
|
independent usefulness and the M1/M2/M3 gates remain open.
|
|
|
|
For ecosystem use, see the [reuse and improvement loop](docs/ReuseAndImprovementLoop.md)
|
|
and its [three-action workplan](workplans/FEP-WP-0008-use-driven-improvement.md).
|
|
|
|
The project treats frontend architecture not as a choice among frameworks or named styles, but as the progressive resolution of recurring forces concerning:
|
|
|
|
- authority,
|
|
- addressability,
|
|
- projection,
|
|
- interaction,
|
|
- mutation,
|
|
- synchronization and reconciliation,
|
|
- composition,
|
|
- execution and delivery,
|
|
- quality boundaries.
|
|
|
|
The repository is intended as an **infospace for both human and agentic reference**.
|
|
|
|
Its goal is to make frontend architecture:
|
|
|
|
1. understandable as a set of recurring design problems,
|
|
2. navigable as a connected language of patterns,
|
|
3. generative rather than merely taxonomic,
|
|
4. explicit about trade-offs and failure modes,
|
|
5. independent of framework fashion,
|
|
6. grounded in known implementations and sources,
|
|
7. machine-readable enough for agents to reason over.
|
|
|
|
## Core proposition
|
|
|
|
> Frontend architecture is the progressive resolution of forces concerning
|
|
> authority, addressability, projection, interaction, synchronization,
|
|
> composition, and execution. A frontend pattern language captures recurring
|
|
> resolutions of those forces and the contexts they create for subsequent
|
|
> design decisions.
|
|
|
|
## Repository map
|
|
|
|
- `canon/` — normative vocabulary and structure of the language.
|
|
- `patterns/` — individual frontend architecture and design patterns.
|
|
- `sequences/` — generative sequences for common frontend situations.
|
|
- `architectures/` — named architectural configurations expressed through patterns.
|
|
- `technologies/` — mappings from technologies/frameworks to the patterns they implement.
|
|
- `research/` — research material, source reconciliation, concepts, catalogues, and cases.
|
|
- `templates/` — authoring templates for new patterns and mappings.
|
|
|
|
## Design principles
|
|
|
|
### Patterns before products
|
|
|
|
React, Solid, HTMX, Astro, LiveView, Vue, Svelte and similar technologies are treated as implementations and examples, not as the ontology.
|
|
|
|
### Forces before preferences
|
|
|
|
A pattern should be selected because of the forces present in a context, not because a framework community considers it idiomatic.
|
|
|
|
### Relations before lists
|
|
|
|
Patterns form a graph. Important relations include:
|
|
|
|
- requires
|
|
- enables
|
|
- refines
|
|
- generalizes
|
|
- complements
|
|
- alternative-to
|
|
- conflicts-with
|
|
- commonly-combined-with
|
|
- creates-context-for
|
|
- implemented-by
|
|
- observed-in
|
|
|
|
### Sequences before checklists
|
|
|
|
A pattern language should help generate architecture through an ordered sequence of decisions.
|
|
|
|
### Failure modes are part of the pattern
|
|
|
|
Software patterns must describe when they become harmful, misleading, expensive or fragile.
|
|
|
|
## Status
|
|
|
|
The corpus currently contains eighteen draft hypotheses, traceable source reviews,
|
|
bounded runtime experiments and four synthetic/provisional walkthroughs. Independent
|
|
human validation, canonical admission and demonstrated generativity remain open.
|
|
The [evolution report](research/evolution/EvolutionReport.md) makes evidence, gaps,
|
|
learning outcomes and unknowns visible; the [method](research/evolution/README.md)
|
|
explains how the language continues learning over time.
|
|
|
|
|
|
## Research entry point
|
|
|
|
Start with the [research program](research/plan/ResearchProgram.md), its
|
|
[protocol](research/plan/ResearchProtocol.md) and [validation cases](research/plan/ValidationCases.md).
|
|
The seed investigation in [FEP-WP-0002](workplans/FEP-WP-0002-seed-language-validation.md)
|
|
is finished with the M1 gate at revise/defer; independent validation of the connected
|
|
seed corpus continues in [FEP-WP-0009](workplans/FEP-WP-0009-m1-independent-validation.md). Later phases broaden coverage and evaluate retrieval against real systems.
|
|
|
|
The [research bench](research/bench/README.md) now provides executable source
|
|
investigations through infospace-bench. Run `make bench-test` to verify the adapter
|
|
and `make bench-plan` to inspect the synthetic pilot. Source reviews and live pilot receipts are retained under `research/`.
|
|
Run `make evolution-check evolution-test` to verify evolution records and reporting.
|