The pack addresses the registration-mode select by its DOM name
attribute, which react-hook-form derives from the field name — now
`registrationMode` (dot-free, see admin-settings-form.ts). Caught by CI
run 713; the pack needs VS_NFD_MODE stages and was not part of the local
verification set.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017aviRTgWCcAHUh1SBoxf6P
The general and quota cards registered their react-hook-form fields under
the dotted settings keys. RHF treats dots as nested-path separators, so
the form DISPLAYED fine (its getter falls back to the literal flat key)
but typing nested the value ({ instance: { name } }) and the api's strict
PATCH schema rejected the body — none of these fields ever saved through
the UI, on any instance. Found by Stefan on a fresh self-hosted install.
- admin-settings-form.ts: dot-free form model with one explicit mapping
to the dotted settings keys and converters in both directions; the
submit now also carries ONLY the settings these cards edit, so the
internal branding metadata keys never ride along.
- Saving invalidates the branding query too — the TopBar reads the
instance name from it and kept the old name until its staleTime ran out.
- admin-settings.spec.ts (new e2e pack, registered in ci.yml): drives the
rename THROUGH THE FORM — success message, TopBar update without
reload, value survives reload, api returns it. Verified locally to fail
against the unfixed page and pass against the fix. Every existing
admin-settings test patched the api directly, which is why this bug was
invisible to CI.
- admin-settings-form.test.ts pins that no form field name contains a dot
and the mapping round-trips.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017aviRTgWCcAHUh1SBoxf6P
