frontend-patterns/research/candidates/LocalDraftState.md
tegwick f273a190f0 Test activation conflicts and draft-preserving application reload
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0cffe-206f-7323-89d3-b20ca4cf4bf9
2026-09-26 23:30:15 +02:00

2.7 KiB
Raw Permalink Blame History

title status maturity families scales admission
Local Draft State draft hypothesis
affordance
mutation
L6
research-candidate-only

Local Draft State

Context: editing a shared server-validated record. Problem: a refresh or rejected write can destroy unfinished intent. Responsiveness and recoverability compete with state complexity and privacy.

Proposed solution: keep base observation, editable proposal and current server observation distinct. Where access and retention policy permits, rejection preserves the proposal; refreshed data prompts comparison instead of replacing input. Access revocation may instead require clearing content. Export is a separate permission, not an automatic recovery fallback. Explicit discard clears the draft. Define whether navigation or restart persistence is required rather than implying it.

Consequences: review is possible after rejection, but stale drafts and sensitive data need lifetime rules. Binding inputs directly to a refreshed cache is simpler when there is no unfinished work; durable local authority is a different requirement.

Evidence: T01/T02 motivate rejection recovery; T05 illustrates local submission data. None verifies this complete draft lifecycle in a deployed frontend. Exact known uses and recurrence: unknown. Hypothesis only.

Proposed connection: supports recovery from Version-Checked Mutation.

T01–T05 refer to TransactionalEvidenceExpansion. Connections are research proposals, not admitted graph edges. Reasoning exercise: VC-01.

Implementation evidence update — 2026-09-25

Frontend recovery review R01/R03 locates Zulip and Element draft storage/restoration at exact commits. These are two partial known uses of unsent-intent separation, not confirmation of the entire base/draft/current merge contract. Full-pattern recurrence remains unknown. A composer may hand submitted content to a separate pending record. Preserve the recoverable intent across that handoff; do not require the input box to stay filled.

Executed application-update path — 2026-09-26

Reload follow-up recovers text and a base marker across a same-tab reload, supports declining an update, and refuses progress on injected storage failure or schema mismatch. It reads edits made during asynchronous preflight and rechecks schema after navigation. Explicit discard clears stale stored content too. These are synthetic policy mechanisms, not permission to persist restricted data or guarantees for native unload, device failure, multiple tabs or remote outcomes.