34 lines
1.5 KiB
Markdown
34 lines
1.5 KiB
Markdown
|
---
|
|||
|
|
title: Local Draft State
|
|||
|
|
status: draft
|
|||
|
|
maturity: hypothesis
|
|||
|
|
families: [affordance, mutation]
|
|||
|
|
scales: [L6]
|
|||
|
|
admission: 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. Rejection preserves the proposal; refreshed data prompts
|
|||
|
|
comparison instead of replacing input. 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](VersionCheckedMutation.md).
|
|||
|
|
|
|||
|
|
T01–T05 refer to [TransactionalEvidenceExpansion](../reviews/TransactionalEvidenceExpansion.md).
|
|||
|
|
Connections are research proposals, not admitted graph edges.
|
|||
|
|
Reasoning exercise: [VC-01](../walkthroughs/VC01-TransactionalAdministration.md).
|