# Phase 1: Draft State Ownership - Discussion Log > **Audit trail only.** Do not use as input to planning, research, or execution agents. > Decisions are captured in CONTEXT.md — this log preserves the alternatives considered. **Date:** 2026-03-28 **Phase:** 01-draft-state-ownership **Areas discussed:** Draft lifecycle, Async field behavior --- ## Draft lifecycle ### When should the editable draft be created? | Option | Description | Selected | |--------|-------------|----------| | On open | Create a working draft from the last saved config when the settings surface opens. | ✓ | | On first edit | Do not create a draft until the user changes something. | | | Persisted always | Keep one always-live draft even while the settings surface is closed. | | **User's choice:** On open **Notes:** Opening Runtime Settings should create the working draft; live polling keeps updating operational status only. ### After a successful save, what should happen to the draft? | Option | Description | Selected | |--------|-------------|----------| | Promote and keep open | Saved values become the new clean baseline and the settings surface stays open. | ✓ | | Save and close | Save, clear the draft, and close the drawer immediately. | | | Save but keep draft dirty | Save to backend while preserving a separate unsaved local copy. | | **User's choice:** Promote and keep open **Notes:** Saved values should become the new baseline immediately. ### What should Cancel do while editing? | Option | Description | Selected | |--------|-------------|----------| | Reset to last saved | Discard unsaved changes and restore the last saved baseline in the form. | ✓ | | Close and keep draft | Close without resetting any unsaved draft values. | | | Ask every time | Require confirmation before resetting changes. | | **User's choice:** Reset to last saved **Notes:** Cancel is the explicit discard action. ### How should Revert differ from Cancel? | Option | Description | Selected | |--------|-------------|----------| | Same as cancel | One full-form revert is enough for Phase 1. | ✓ | | Revert field-by-field | Allow a more granular undo path than Cancel. | | | Revert to effective runtime | Reset to whatever is live, even if it differs from last saved config. | | **User's choice:** Same as cancel **Notes:** No per-field undo is needed yet. ### If the user closes the drawer with unsaved edits, what should happen? | Option | Description | Selected | |--------|-------------|----------| | Keep draft hidden | Close the drawer but restore the same in-session draft on reopen. | ✓ | | Discard draft | Treat close the same as Cancel. | | | Force confirm dialog | Require an explicit choice before allowing close. | | **User's choice:** Keep draft hidden **Notes:** Close/backdrop behavior should differ from Cancel. --- ## Async field behavior ### When a folder picker or file chooser finishes after the draft is already dirty, how should its result be applied? | Option | Description | Selected | |--------|-------------|----------| | Apply only if same field | Update only the field the user just picked, without rehydrating other draft fields. | ✓ | | Apply everything from latest scan | Let the picker or scan refresh the broader form state too. | | | Ask before applying | Show a confirmation before changing the draft. | | **User's choice:** Apply only if same field **Notes:** Async helpers should be field-scoped, not whole-form rehydration triggers. ### If a model rescan finishes while the user is editing, what should happen to model-related state? | Option | Description | Selected | |--------|-------------|----------| | Refresh options, keep selection | Update the available model list but preserve the current draft selection unless it becomes invalid. | ✓ | | Auto-pick best model | Replace the current selection with the first valid or recommended model. | | | Defer until save | Do not update model options until the user saves. | | **User's choice:** Refresh options, keep selection **Notes:** Current draft selection should remain stable unless rescan proves it invalid. ### While the drawer has unsaved edits, how should background polling affect async-derived data like health, GPU hints, or library status? | Option | Description | Selected | |--------|-------------|----------| | Status only, no draft overwrite | Keep live operational status fresh, but never rewrite draft fields or local async selections. | ✓ | | Pause all refreshes | Freeze both status and async derived data until the draft is clean. | | | Full live sync | Continue updating the full form from polling even while dirty. | | **User's choice:** Status only, no draft overwrite **Notes:** Polling remains valuable, but only for live status surfaces. ### If an older async request returns after a newer one for the same field, what should happen? | Option | Description | Selected | |--------|-------------|----------| | Ignore stale results | Only the latest request for that field may update the draft-facing UI. | ✓ | | Last response wins | Whichever request finishes last overwrites the UI. | | | Show conflict warning | Keep both and ask the user which one to accept. | | **User's choice:** Ignore stale results **Notes:** Stale async results must not overwrite newer user intent. ### If a rescan shows the currently drafted model or folder choice is no longer valid, what should the UI do before save? | Option | Description | Selected | |--------|-------------|----------| | Keep draft, mark invalid | Preserve the draft value, show validation, and block save until fixed. | ✓ | | Auto-switch to valid option | Replace it immediately with the first valid option. | | | Clear the field | Remove the invalid choice and force a new selection. | | **User's choice:** Keep draft, mark invalid **Notes:** The UI should preserve user intent visibly instead of silently auto-correcting it. --- ## the agent's Discretion - Exact live-vs-draft visual treatment. - Exact request identity/cancellation mechanism for stale async response handling. - Exact inline validation copy and placement. ## Deferred Ideas - Consolidating the status card and settings surface into one runtime control center belongs to Phase 3. - Broader source/model/path validation improvements beyond draft-safety behavior belong to Phase 4.