frontend-patterns/START.md

# Start with a frontend decision

**0.1 research preview.** Seventeen candidate patterns, all hypotheses. Use them to
make assumptions and trade-offs explicit; confirm the required contracts in your
implementation. This language has not yet demonstrated improved decision quality.

## Choose your starting problem

| Your problem | Start here | What the sequence helps decide |
| --- | --- | --- |
| Users edit shared records; writes can conflict or lose their responses | [Transactional editing](sequences/TransactionalApplication.md) | Preserve intent, reject stale proposals, resolve uncertain outcomes, refresh views |
| Users edit notes offline and must resume after restarting | [Offline local work](sequences/LocalFirstApplication.md) | Acknowledge local save, retain pending propagation, handle divergence, plan recovery |
| You need navigation, rendering, feature or interaction guidance | [Extension candidates](reference/0.1/Catalog.md#extensions) | Explore individual hypotheses with their current evidence limits |
| You need an overview of coverage | [Classification inventory](research/catalog/ClassificationCoverage.md) | Compare families, scales, responsibilities and selected forces |

Before choosing, state who can accept the relevant change, which state must survive
restart, and what the user is allowed to retain. A locally displayed result is not
necessarily accepted. Where a view is computed is a separate decision from authority.

If you cannot answer those questions, clarify them first. If you require globally
exclusive approval while fully disconnected, neither sequence supplies that guarantee.
A collaborative editor, hard real-time system or complete security architecture needs
additional domain work; an unfilled catalog cell is not permission to improvise a
validated solution.

## Read the language as decisions

A candidate explains a problem and forces, a proposed solution, its resulting context,
alternatives and failure modes. Follow conditional links only when their assumptions
hold. The eight [core candidates](reference/0.1/Catalog.md#core) connect into the two
sequences; the other nine are extensions, not mandatory additions.

[Transactional mappings](technologies/TransactionalRecovery.md) and
[offline mappings](technologies/OfflineRecovery.md) locate implementation mechanisms.
No listed product is certified to implement the whole proposed configuration.

A short example: if an edit succeeds remotely but its response disappears, preserve
its operation identity and treat the outcome as unknown. Find the result or use a
verified bounded replay contract before creating another attempt. After acceptance,
refresh observations separately; a refresh failure does not undo acceptance. Follow
the [transactional sequence](sequences/TransactionalApplication.md) for assumptions
and alternatives.

## Evidence and future versions

The [0.1 release record](reference/0.1/README.md) pins the corpus and lists supported
contexts. [Evidence profiles](research/evolution/EvolutionReport.md) separate documents,
code inspection and runtime observations. No candidate is canonically admitted; a
source locator or passing fixture does not prove its full contract.

For a counterexample, record the candidate ID, the context, expected versus observed
behavior, implementation revision and any reproducible evidence. Explain whether a
precondition was absent or the proposed solution failed despite it. Use the source or
learning-cycle templates under `templates/`; proposed corrections require a named
review with retained prior claims. Never paste private data or credentials into evidence.

Later versions may revise, merge, split or retire candidates. Preserve identities and
supersession records; do not silently reinterpret an older release. The language is
intended to keep learning.

## Agent reference

For an explicit candidate, force or responsibility, use the local pinned-reference
helper:

```bash
python3 scripts/reference_consume.py --version 0.1 lookup --candidate CAND-0007
python3 scripts/reference_consume.py --version 0.1 lookup --force recoverability --responsibility mutation
```

Filters intersect; multiple candidate IDs form an allowlist. Results carry force
costs, evidence gaps, conditional relations and commit-specific contract/evidence
locators. A metadata match is a research lead, not an applicability or compatible
configuration proof. With no filters the helper requests context; valid filters with
no results produce `no-match`. Unknown vocabulary or unpublished IDs fail explicitly.
Read the complete pinned contracts before making the consumer's decision.
The [consumer receipt instructions](feedback/ConsumerIntegration.md#local-lookup-and-closeout-helper)
explain how to retain that decision and its unknown or later observed outcome.

Read [index.json](reference/0.1/index.json) for stable research identities, proposed
relations, classification, evidence and gaps. It is a candidate reference export, not
an admitted canonical graph. Read the linked contracts before making a recommendation;
do not infer inverse edges, unconditional dependencies or transitive guarantees.