Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@web/src/__tests__/components/settings/SettingSourceBadge.test.ts`:
- Around line 13-53: Replace the repetitive individual it tests in the
SettingSourceBadge suite with a parameterized it.each table that iterates over
rows like [{ source: 'db', label: 'Database', severity: 'info' }, { source:
'env', label: 'Environment', severity: 'warn' }, { source: 'yaml', label:
'YAML', severity: 'secondary' }, { source: 'default', label: 'Default',
severity: 'contrast' }], and for each row mount SettingSourceBadge with
mount(SettingSourceBadge, { props: { source } }) then assert wrapper.text()
contains label and wrapper.find(`[data-severity="${severity}"]`).exists() is
true; keep the test suite name and component reference (SettingSourceBadge)
intact.

In `@web/src/stores/settings.ts`:
- Around line 143-146: The toggleAdvanced function currently writes to
localStorage without a guard; wrap the call to
localStorage.setItem(SETTINGS_ADVANCED_KEY, String(showAdvanced.value)) in a
try/catch so errors in restricted environments are swallowed or logged, keeping
the state flip (showAdvanced.value = !showAdvanced.value) intact; reference the
toggleAdvanced function, showAdvanced ref, and SETTINGS_ADVANCED_KEY when making
this change.
- Line 69: Guard the direct localStorage access used to initialize showAdvanced
(which currently calls localStorage.getItem(SETTINGS_ADVANCED_KEY) === 'true')
by wrapping the getItem call in a try/catch and defaulting to false on error;
update the initialization of showAdvanced to compute the boolean inside the
try/catch and use that value for ref(...). Also ensure any code that later
writes the same SETTINGS_ADVANCED_KEY (e.g., setters or watchers that update
localStorage when showAdvanced changes) uses try/catch to avoid throwing in
restricted contexts.
- Around line 50-58: The current client-side validation builds a RegExp from
validator_pattern and runs .test(value), which can be expensive for long inputs;
add an input-length guard before constructing/using the regex: define a sensible
MAX_VALIDATION_INPUT_LENGTH constant and, inside the block where
validator_pattern and value are validated (the code referencing
validator_pattern and value), if value.length exceeds the limit either skip the
regex test or return a concise validation error (e.g., "Input too long to
validate"), then only construct new RegExp(`^(?:${validator_pattern})$`) and
call .test(value) when value.length is within the limit; keep the existing
try/catch around RegExp construction to handle invalid patterns.

In `@web/src/views/SettingsPage.vue`:
- Line 207: The conditional update handler on TabView currently uses
"auth.mustChangePassword ? undefined : (activeTab = $event)" which returns
undefined but does not stop PrimeVue from visually switching tabs; remove this
ternary and restore a simple setter for the `@update`:value event (i.e., set
activeTab = $event) and rely on each TabPanel's :disabled binding
(auth.mustChangePassword) to prevent navigation; update the TabView's
`@update`:value handler to just assign activeTab and ensure TabPanel :disabled
still references auth.mustChangePassword.
- Around line 196-200: The ToggleSwitch handler currently calls
settingsStore.toggleAdvanced() and ignores the emitted boolean; update the event
binding so the emitted value from `@update`:model-value is passed into the store
(e.g., call settingsStore.toggleAdvanced(value) or create/use a setter like
settingsStore.setAdvanced(value)) so the store receives the explicit new boolean
from ToggleSwitch instead of always flipping state; update the usage of
ToggleSwitch, the settingsStore method signature (toggleAdvanced) or add
setAdvanced to accept the boolean, and ensure the template binding forwards the
emitted value.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@web/src/stores/settings.ts`:
- Around line 52-58: The current JSON validation uses JSON.parse(value) which
accepts primitives (strings, numbers, booleans, null) as valid JSON; if you need
to restrict settings to only objects/arrays, parse the value then verify the
parsed result is a non-null object (Array.isArray(...) or typeof parsed ===
'object' && parsed !== null) and return the error 'Must be valid JSON' when the
parsed value is a primitive; update the validation branch that checks type ===
'json' (using the variables type and value in settings.ts) to perform this extra
check after parsing.

---

Outside diff comments:
In `@web/src/__tests__/views/SettingsPage.test.ts`:
- Around line 23-98: Tests redefine many PrimeVue component mocks (e.g., the
vi.mock calls for 'primevue/tabs', 'primevue/inputtext', 'primevue/button',
'primevue/toggleswitch', etc.) that are already centralized in
web/src/__tests__/__mocks__/primevue.ts; remove these duplicated vi.mock(...)
blocks from SettingsPage.test.ts and instead load the shared registrar by
importing or requiring the centralized mock module (e.g., add a top-level import
of web/src/__tests__/__mocks__/primevue or replace the individual vi.mock calls
with a single vi.mock('primevue', () =>
require('web/src/__tests__/__mocks__/primevue'))), so all tests use the same
mocked behavior.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@web/src/__tests__/stores/settings.test.ts`:
- Around line 158-172: Add an advanced-only namespace fixture to the test by
creating another mock definition (e.g., mockAdvancedOnlyDefinition) whose
definitions all have level: 'advanced', include it in the mocked
settingsApi.getSchema response alongside mockSecurityDefinition, mockDefinition,
and mockAdvancedDefinition, then call useSettingsStore() and await
store.fetchAll(); assert that store.namespaces does not include the
advanced-only namespace while store.showAdvanced is false (optionally also
assert it appears when you set store.showAdvanced = true and refresh if needed).
Ensure you reference the existing test helpers and methods (mock...Definition
symbols, settingsApi.getSchema, useSettingsStore, store.fetchAll,
store.namespaces, store.showAdvanced) so the new fixture integrates with the
current test setup.

In `@web/src/stores/settings.ts`:
- Around line 147-160: After deleting the override in resetSetting (where
settingsApi.resetSetting is called) you currently swallow failures from the
subsequent settingsApi.getAllSettings call which leaves entries showing stale
resolved values; change the flow so that if the refresh fails you do not report
success—either rethrow/propagate the refresh error (so callers see failure) or
proactively update entries to remove/invalidate the specific namespace/key entry
(using entries and generation) before returning; ensure you still clear
savingKey and maintain generation consistency so the UI cannot display an
authoritative stale entry after reset.
- Around line 95-98: The computed namespaces currently ignores the showAdvanced
filter so namespaces with only advanced settings still appear; update the
computed named namespaces to build the present set from schema.value filtered by
the showAdvanced state (e.g., include a definition only if showAdvanced.value is
true or def.level !== 'advanced'), then map to namespaces and apply
NAMESPACE_ORDER.filter as before; reference the computed symbol namespaces, the
reactive schema, and the showAdvanced ref when making this change.
- Around line 128-141: In updateSetting, use the SettingEntry returned by
settingsApi.updateSetting(namespace, key, { value }) to immediately update
entries (and generation if needed) before performing the best-effort refresh;
specifically, after the await of settingsApi.updateSetting(...) apply the
returned entry to the entries reactive list (and clear savingKey) so the store
reflects the saved value even if the subsequent settingsApi.getAllSettings()
refresh fails, and keep the existing generation check/gen increment logic to
avoid races.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@web/src/__tests__/stores/settings.test.ts`:
- Around line 298-303: Replace hardcoded localStorage key strings with the
shared constant SETTINGS_ADVANCED_KEY in the tests: update the assertions that
call localStorage.getItem('settings_show_advanced') to use
localStorage.getItem(SETTINGS_ADVANCED_KEY) so they stay in sync with the
implementation; do this for the assertions surrounding store.toggleAdvanced()
and store.showAdvanced in the failing test blocks (also apply the same change to
the similar assertions at lines noted in the comment).
- Around line 243-247: The test currently only mocks settingsApi.getAllSettings
once, but store.updateSetting(...) triggers a post-update refresh so the second
getAllSettings call is undefined; update the test to mock getAllSettings for
both calls (e.g., use
vi.mocked(settingsApi.getAllSettings).mockResolvedValueOnce(initialData) and
.mockResolvedValueOnce(refreshedData) or mockResolvedValue sequence) and ensure
the mocked settingsApi.updateSetting promise (resolveUpdate) is used to simulate
completion before asserting; apply the same dual-getAllSettings mocking fix to
the other test block that covers lines 251-256.

---

Duplicate comments:
In `@web/src/stores/settings.ts`:
- Around line 19-20: The regex length guard is unreachable because
MAX_VALIDATION_INPUT_LENGTH exceeds MAX_SETTING_VALUE_LENGTH; update the
validation so the shorter limit is enforced first: either set
MAX_VALIDATION_INPUT_LENGTH to a value <= MAX_SETTING_VALUE_LENGTH or remove the
redundant branch that checks MAX_VALIDATION_INPUT_LENGTH in the same validation
flow (look for the constants MAX_SETTING_VALUE_LENGTH and
MAX_VALIDATION_INPUT_LENGTH and the validation logic that returns `Value must be
at most ${MAX_SETTING_VALUE_LENGTH} characters` and the later regex-length
guard) so only one consistent maximum is applied.
- Around line 134-139: The optimistic update currently replaces entries via
entries.value.map(...) after calling settingsApi.updateSetting(namespace, key, {
value }) but does nothing if the entry is missing; change the logic that applies
updatedEntry (and uses the incremented generation) to perform an upsert: search
entries.value for an item matching e.definition.namespace === namespace &&
e.definition.key === key and if found replace it with updatedEntry, otherwise
append/insert updatedEntry into entries.value so the UI reflects the successful
PUT even when the entry wasn't previously present; keep the existing generation
increment and use the same updatedEntry result from settingsApi.updateSetting.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@web/src/__tests__/stores/settings.test.ts`:
- Around line 380-506: The test suite is missing coverage for integer-specific
validation in validateSettingValue; add new tests (using the existing helper
makeDef and pattern in this file) for type: 'int' that assert acceptance of
valid integers (e.g., "42"), rejection of decimals like "3.5", rejection of
empty string, and enforcement of min_value and max_value boundaries (e.g.,
min_value: 0 rejects "-1", max_value: 100 rejects "200"); place these alongside
the other type-specific tests so integer behavior and Number.isInteger()
semantics are verified.

Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In `@web/src/stores/settings.ts`:
- Around line 155-175: The resetSetting function is prematurely mutating
entries.value to a guessed default after calling settingsApi.resetSetting;
instead, stop optimistically replacing the entry with { ...e, value:
e.definition.default, source: 'default' } and only update entries.value from the
authoritative settingsApi.getAllSettings() result; keep savingKey and generation
handling, call settingsApi.getAllSettings() after reset, and if it succeeds (gen
=== generation) assign entries.value = entriesData, otherwise do not modify the
existing entry (or restore the prior entry) and surface the refresh failure;
reference resetSetting, generation, entries.value, settingsApi.resetSetting and
settingsApi.getAllSettings when making the change.