frontend-patterns/SCOPE.md

# SCOPE

Reviewed: 2026-09-27 · Scope: ongoing research and a versioned knowledge base.

## Purpose and deliverable

Develop a framework-independent frontend architecture pattern language for human
and agent reference, following [INTENT.md](INTENT.md). Its intended practical
outcome is an explainable path from a frontend problem and its forces to compatible
patterns and implementation options.

The deliverable is a versioned Markdown knowledge base with structured metadata,
traceable evidence and transparent revision history. The language evolves through
bounded investigations and review gates; it has no final completion date. Completing
an experiment or milestone does not establish a mature language.

## In scope

- `canon/`: responsibilities, forces, scales, relations and the metadata contract,
  including testing whether the proposed vocabulary explains contrasting cases.
- `research/`: identifiable sources, claim-level interpretations, candidate patterns,
  counterexamples, pinned implementation studies and bounded executable experiments.
- `patterns/`: evidence-qualified canonical records when admission is justified;
  research candidates remain separately identified until then.
- `sequences/` and `architectures/`: decision ordering, compatible configurations,
  alternatives and resulting contexts, exercised through contrasting walkthroughs.
- `technologies/`: descriptive mappings from patterns to implementation approaches,
  including their constraints and limits.
- `templates/`, `scripts/` and the infospace-bench adapter: authoring, metadata checks
  and reproducible research evaluation. Live model execution uses llm-connect.
- `research/evolution/` and `history/`: evidence profiles, immutable snapshots,
  prospective questions and effort, supersession, learning outcomes and dated
  assessments. Track applicability, trustworthiness, usefulness, coherence,
  maintainability and learning efficiency separately.

These areas include intended capabilities; directory presence is not evidence that
the corresponding capability is implemented or validated.

## Current capabilities and limits

As of 2026-09-27, seventeen developed research candidates remain draft hypotheses;
none is canonically admitted. Sources and claim-level reviews, metadata contract
checks, an infospace-bench adapter and bounded runtime research fixtures exist.
Four walkthroughs are synthetic drafts or provisional studies, not validated
architecture recipes. Six further validation cases remain planned.

The frozen development pilot scored 18/24 in each presentation condition after
submitted model-review adjudication. It establishes neither a naming benefit nor
equivalence; independent human validation and decision-time measurement remain open.

Evolution profiles, a baseline, learning ledger, snapshots and a generated report
are implemented. Four effort-accounted prospective cycles belong to four different
comparison groups: there is no comparable window for a diminishing-returns claim.
Evidence types, implementation families and review provenance remain distinct.
Static source mechanisms and authored runtime fixtures do not establish complete
pattern recurrence, production fitness or independent human confirmation.

Canonical admission, M1/M2 acceptance, demonstrated generativity, full graph export,
held-out retrieval evaluation and developed technology mappings remain open.
There is research runtime code, but no maintained frontend application or framework
is offered as the product. See the [evolution report](research/evolution/EvolutionReport.md)
for current counts and evidence limits; [REVIEW.md](REVIEW.md) preserves the initial
2026-09-23 review and is not a current capability inventory.

## Research boundaries and exclusions

- Do not build or operate a general frontend application, framework, router or
  release platform as the deliverable. Fixtures exist to investigate claims.
- Do not rank frameworks, prescribe a universal architecture or turn the language
  into a component cookbook or collection of tool-specific idioms.
- Do not treat candidate counts, source counts, passing assertions or model agreement
  as maturity, independent recurrence or proof of usefulness.
- Do not infer accessibility conformance, production guarantees or upstream defects
  from bounded DOM experiments or partial source inspection.
- Do not combine viability dimensions into a maturity percentage, infer historical
  effort from commits, or pool incomparable studies to claim learning saturation.

## Work ownership and review boundaries

[WP-0002](workplans/FEP-WP-0002-seed-language-validation.md) owns seed evidence,
connected-corpus validation and M1. [WP-0003](workplans/FEP-WP-0003-contrasting-schools.md)
owns contrasting streams, broader walkthroughs, ontology decisions and M2.
[WP-0004](workplans/FEP-WP-0004-reference-surface.md) is proposed follow-up for graph,
held-out retrieval and real-repository applicability, subject to its recorded gates.
[WP-0006](workplans/FEP-WP-0006-language-evolution.md) owns ongoing learning visibility,
review dates and comparable-cycle measurement. Actionable work stays in workplans;
this file describes boundaries, not a second backlog.

The [2026-09-27 scope–intent assessment](history/2026-09-27T010237+0200-scope-vs-intent.md)
records the current gaps and recommended priorities. Future assessments should
preserve that historical judgment and cite changed evidence.

## Registration

- Repository: `frontend-patterns`
- Category: `research`
- Domain / topic: `infotech / canon`
- Workplan prefix: `FEP-WP`

The topic groups this research with semantic coordination work; it does not imply
that the proposed language is an adopted fleet standard.