6.2 KiB
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.