Legacy settings import renames the document before importing, then swallows per-section failures — partial configuration loss on upgrade

[Ragnoryok1]

Summary. SettingsForms.importLegacyDocument() renames the removed settings.yaml to settings.yaml.imported before it writes any section into the active profile, then catches each section's failure and only logs it. A section whose plugin entry is not mounted at that moment — or whose entry rejects the write for a different reason — is silently dropped, and because the rename already happened the import is never retried.

Where

• packages/settings/settings/src/index.ts:241-257 — rename(path, imported) at :246, the loop at :248-255, both logger.warn calls at :253-254.
• :235 — the whole import is a fire-and-forget void ctx.root.loader.await().then(() => this.importLegacyDocument()), so even a total failure is only logged.
• The doc comment at :238-240 states the behaviour is intentional ("a section the running composition rejects is logged and remains only in the renamed file"). My report is not about the log line — it is that the user gets no actionable signal, there is no retry, and the rename makes the loss one-shot and unrepeatable.

Evidence from my machine (Windows, 0.1.7-alpha.2). After the upgrade settings.yaml no longer existed; the only copy is settings.yaml.imported (19.3 KB), alongside a series of timestamped settings.yaml.bak-* files. Of the eight sections in .imported, seven have a counterpart in the active profile patch (ui-theme, agent-default-model, locale, llm-pi-ai, ui-chat, llm-deepseek, and ui-onboarding via its mapping in LEGACY_SECTION_ENTRIES:203), but agent-presets has none — no entry of that name in the active patch and no mapping in that table. That is the shape this defect produces: one section missing, no error, the original preserved only in a renamed file.

Suggested directions

1. Import first; rename only after every section either landed or was reported as unmappable.
2. Keep it retryable — leave the source in place (or re-attempt on loader settle / config reload) instead of making the first attempt final.
3. Surface an actionable signal: a startup notice or settings-UI row listing sections that did not import, with the path to the preserved document.
4. Distinguish "entry not mounted yet" from "entry has no volatile fields" (the second is reported by write() but is not transient), since the same catch currently covers both.

Question. Is rename-before-import deliberate as a one-shot-migration guarantee? If so, was a user-visible notice intended, and would import-then-rename break an invariant I cannot see?