tegwick
642163a1ed
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a0cffe-206f-7323-89d3-b20ca4cf4bf9
44 lines
2.1 KiB
Markdown
44 lines
2.1 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. 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](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).
|
||
|
||
## Implementation evidence update — 2026-09-25
|
||
|
||
[Frontend recovery review](../reviews/FrontendRecoveryImplementations.md) 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.
|