frontend-patterns/research/plan/ResearchProtocol.md

Research protocol

Status: working method · 2026-09-24

Research unit

A unit is a question, an evidence set and a recorded conclusion. Before reading, state the question, current hypothesis, assumptions and what would contradict it. Use SourceReview for extraction and ArchitectureWalkthrough for application.

Evidence handling

1. Prefer original publications, standards, research papers, official documentation and identifiable implementations. Secondary surveys help discovery; trace their substantive claims to primary evidence where possible.
2. Record author/publisher, title, exact URL or bibliographic locator, publication date/version and access date. Mark unavailable information as unknown.
3. In each source review, assign local claim labels (C01, C02, …). Cite claims by file path plus label. Separate source statements, our interpretations and tests.
4. Cite sections, pages or repository revisions. Paraphrase accurately; keep any quotations short and attributed. A source being listed is not evidence of review.
5. Record conflicts and negative cases. Multiple sources repeating the same origin are not independent confirmation. An unavailable source stays pending.
6. Update research/catalog/SourceCatalog.md with the review path and state: queued, extracted or reviewed. These are research workflow labels, not pattern evidence maturity. Do not invent publication details to fill a template.

Pattern synthesis

Extract problem, context, competing forces, recurring configuration, dynamics, resulting context, consequences and failure modes before assigning a pattern name. Compare candidates against existing ones: retain, merge, split, reject or defer, with reasons in research/catalog/PatternCandidateCatalog.md.

A draft promoted into patterns/ must satisfy the schema agreed in FEP-WP-0002, include at least two competing forces, evidence locators, a justified relation to another pattern, a failure case and an explicit maturity. Cite two contrasting applications where available; otherwise retain hypothesis status and state the gap. A framework feature alone does not establish recurrence. A directory named canon does not confer evidence maturity on its contents.

Generativity test

Hold the application brief fixed. Record each architectural decision, forces, applicable alternatives, chosen patterns and resulting context. Then vary one constraint (for example offline operation or independent deployment) and explain which decisions change. Compare with a plain architecture narrative written without the pattern catalog. If the language adds only renamed labels, revise it.

Record quality constraints at the start and throughout the walkthrough: accessibility, security, privacy, recovery and performance must influence earlier decisions too. The existing sequence's late quality step is a hypothesis to challenge.

Review and stopping rules

For every gate, record reviewer, date, artifacts, checks, counterevidence and outcome (pass, revise or defer) in research/reviews/. A review passes only if references are traceable, examples resolve their metadata references, and another reader can follow the reasoning. Distinguish synthetic scenarios from observed systems.

Stop broad source collection when the bounded question has sufficient evidence to support or reject the current hypothesis; record remaining uncertainty. Do not stretch source claims to meet a pattern-count target. Preserve superseded conclusions through Git history and link the replacement. Reopen a conclusion when new evidence invalidates a stated assumption.