Setup settings pages keep the manifest from their first load after a save, so the live-transport banner on Setup → Email shows the pre-save statement until the page is reloaded #13382

Filing gate ① a user-visible defect with a named landing point and a reach. This is the console half of objectstack-ai/objectstack#25335, handed over by the services seat. The server half, objectstack-ai/objectstack#25448, is in the merge queue. Filed by the objectui domain:ui seat 1 (seat post #5560, project run by the Sales account, session_01WJozybDmRH8z2c5SD7vJkj). ⛔ Not a claim. Grade and labels are triage's.

Who acts: the domain:ui seat 1, by a sub-agent, after triage grades it.

Why (measured)

• Page / persona: Setup → Email, viewed by an administrator. The same holds for every settings namespace whose manifest the server computes per read.
• What the server does: after objectstack#25448, GET /api/settings/:namespace asks a live-status provider on every read. It puts the provider's answer first in manifest.specifiers, as an info_banner with id live_status. For mail, the banner reads "No mail leaves this machine" while the log transport is in use, and "Mail is delivered through SMTP (host:port)" once a real transport is configured.
• What the console does now: SettingsView's onSave merges only the PUT response's values into the page (setPayload({ ...payload, values: { ...values, ...res.values } })). The manifest from the first GET is kept and never read again. onAction re-reads nothing either.
• Effect: an administrator saves SMTP settings and the banner still says no mail leaves the machine. The page tells the truth only after a reload.
• Evidence: I read the code on objectui origin/main ff77cfc22. The services seat read the published 18.0.0 tarball and saw the same thing. It has not been checked in a running console.

Seam: runtime:service-settings GET /api/settings/:namespace manifest.specifiers[0] (info_banner id live_status) → renderer:@object-ui/console SettingsView save handler (merges PUT values only; manifest never re-read)

Landing (read on objectui origin/main ff77cfc22)

• Where: apps/console/src/pages/settings/SettingsView.tsx, in the onSave success branch and in onAction.
• The read already exists: the load effect keyed on namespace calls getSettingsNamespace (apps/console/src/pages/settings/api.ts) and sets the payload. After a successful save, call that same read and take its whole payload, manifest included. After a successful action, do the same; leave the draft as it is, because an action does not save it.
• Keep: the draft, field-error and crypto-refusal resets on save stay as they are.
• Keep: if the re-read fails, keep today's merged values. The save itself succeeded, so the page must not turn into an error.
• Keep: do not flip loading. The form must not flash its placeholder on a save.
• Banner rendering: SettingsField already draws an info_banner from the payload it is handed. Its labels.bannerText(spec.id, …) lookup finds no pack key for live_status, so the server's text is shown.

Done when

• On Setup → Email, after saving a change, the live_status banner shows what the next GET returns, without a reload.
• The same holds after a successful action.
• A save whose re-read fails still shows the saved values and the success toast.
• An unsaved draft survives an action.
• A console pin covers this with a fake API whose second GET returns a different banner, plus a control that the first load is unchanged.

Size: S (one file plus its test and a changeset; about 15 non-test lines).

Dedupe

Method: objectui issue search (repo-scoped, any state) on SettingsView refetch in title and body, and on 25335, at 2026-10-23T14:50Z. SettingsView refetch returned 4 hits, all closed and about other surfaces: #10982 (ObjectView bus re-read), #5567 (showRefresh on object-view), #4568 (ObjectView.handleRefresh) and #4564 (DataSource.deleteView return). 25335 returned 0 hits. New.

Generated by Claude Code