Keep a draft without promising a remote backup

# Apply the “Keep a draft without promising a remote backup” guide in your agent

## Objective
Separate current edits, the last local copy and the last server-confirmed version. Say where the draft lives and when saving really succeeded. Recover after refresh without silently replacing newer work, and offer a deliberate fallback when storage fails. Local persistence is not a backup guarantee.

## Prerequisites
- Inspect the repository, documentation, and existing conventions.
- Confirm the need matches the guide scope: Choose explicit save or autosave and recover from storage failures, offline use and conflicting revisions.
- Preserve the correct decisions already in place.

## Guide steps
- 1. Define the storage boundary — List the draft fields and retention policy for a note editor. A browser copy belongs to that browser profile and may be cleared. It is neither cross-device storage nor an encrypted secret vault. Exclude passwords, tokens and sensitive fields unless an appropriate storage design explicitly covers them. Explain shared-device risks before entry and offer a clear discard action.
- 2. Distinguish saved states — Use edited, saving, saved locally, synced and failed only with evidence. A delayed autosave remains unsaved until writing succeeds. An offline queue is not confirmation of remote persistence. Explicit save suits consequential commits; autosave suits recoverable drafts when failures and revisions are handled. Choose based on the harm of losing an edit or publishing it too early.
- 3. Example: resume a note — After a successful local write, show Draft on this device. On reopening, offer that dated draft and Discard. Restore visible content before trying to restore a fine-grained cursor position. If the remote version changed, preserve both copies while choosing or merging. Do not silently replace newer work with an old browser draft. Disclose unsupported conflict resolution.
- 4. Recover when writing fails — Catch denied storage and quota failures. Keep editing possible, show persistence failed and offer explicit copy or export appropriate to the data. A completed timer is not a successful write. A beforeunload warning is a last guard, not persistence: browsers may omit it during exit. Save during the journey and remove unnecessary leave warnings once the data is safe.
- 5. Verify the recovered bytes — Edit, save and reopen; compare exact content. Repeat with storage blocked and an outdated draft against a newer remote copy. Check that discard removes only the intended draft. This guide defines a contract for your app, not a cloud capability of SkillCodex. Encryption, backup and durability need independent implementation evidence.

## Acceptance criteria — Verify in your product
- Saved labels name the storage location.
- Write failure stays visible.
- Refresh recovers exact content.
- Newer work is protected.
- Discard has a precise scope.
- Sensitive fields have a policy.

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

• Requires · The real project context: repository, documentation, and existing constraints

# Anchor the guide in the project

## Objective
Turn the applied steps into durable repository conventions.

## Checks
- Link each decision made to the guide step that justifies it.
- Add the checklist to the relevant reviews.
- Record out-of-scope cases for the neighboring guides.

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

sha256:98bc5e3844c141323f7af10224589345dc57fc5ca2f46f53f03d18aa2b6a16cc

# Diagnose a failed application of the “Keep a draft without promising a remote backup” guide

## Observed symptom
[DESCRIBE THE SYMPTOM HERE]

## Observable checks
- Replay the steps in order and note the first one that diverges:
- 1. Define the storage boundary — List the draft fields and retention policy for a note editor. A browser copy belongs to that browser profile and may be cleared. It is neither cross-device storage nor an encrypted secret vault. Exclude passwords, tokens and sensitive fields unless an appropriate storage design explicitly covers them. Explain shared-device risks before entry and offer a clear discard action.
- 2. Distinguish saved states — Use edited, saving, saved locally, synced and failed only with evidence. A delayed autosave remains unsaved until writing succeeds. An offline queue is not confirmation of remote persistence. Explicit save suits consequential commits; autosave suits recoverable drafts when failures and revisions are handled. Choose based on the harm of losing an edit or publishing it too early.
- 3. Example: resume a note — After a successful local write, show Draft on this device. On reopening, offer that dated draft and Discard. Restore visible content before trying to restore a fine-grained cursor position. If the remote version changed, preserve both copies while choosing or merging. Do not silently replace newer work with an old browser draft. Disclose unsupported conflict resolution.
- 4. Recover when writing fails — Catch denied storage and quota failures. Keep editing possible, show persistence failed and offer explicit copy or export appropriate to the data. A completed timer is not a successful write. A beforeunload warning is a last guard, not persistence: browsers may omit it during exit. Save during the journey and remove unnecessary leave warnings once the data is safe.
- 5. Verify the recovered bytes — Edit, save and reopen; compare exact content. Repeat with storage blocked and an outdated draft against a newer remote copy. Check that discard removes only the intended draft. This guide defines a contract for your app, not a cloud capability of SkillCodex. Encryption, backup and durability need independent implementation evidence.

## Possible causes
- A step was skipped or executed out of order.
- The actual need falls outside the guide scope.
- A checklist criterion was never verified.

## Bounded fixes
- Redo only the diverging step and what depends on it.
- Document the gap if the guide scope does not cover the need.

## Final verification — Verify in your product
- Saved labels name the storage location.
- Write failure stays visible.
- Refresh recovers exact content.
- Newer work is protected.
- Discard has a precise scope.
- Sensitive fields have a policy.

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

• Requires · The real project context: repository, documentation, and existing constraints

# Prevent the next drift

## Objective
Turn the first diverging step into an explicit project check.

## Checks
- Add a focused check on the step that diverged.
- Verify the checklist on a second real case.
- Document the scope limit you hit.

## Guardrails
- Show the proposed changes before any external action.
- Do not publish, send, delete, pay for, or change remote state without explicit authorization.
- Preserve unrelated changes and stop if the scope becomes ambiguous.

## Output format
- Outcome or verdict.
- Files or actions involved.
- Checks run and observable evidence.
- Remaining blockers or limitations.

sha256:df802a9be01d63f1cb443673428c3c93e6f3a44c2fe5cc5a8f231715aa2efea3