shadowdaoandClaude Opus 5
aba0d187d7
Two Important review findings on the previous commit (1a01834):
1. handleResetSite ran unconditionally -- the confirm button's `disabled`
attribute was the only thing standing between a mismatched/empty typed
value and a full site wipe. Extracted the match check into a single
exported pure predicate, siteResetConfirmMatches(typed, domain), used
for the button's disabled/cursor/opacity (previously three duplicated
inline comparisons) AND as the first line of handleResetSite itself,
which now returns early if it doesn't hold. An empty domain is rejected
outright (`!!domain &&` short-circuits) so the guard holds even if the
handler were ever reached with no configured domain, independent of the
entry point being hidden.
2. The dialog said "design tokens" but resetToDefaults() also wipes
headCode (analytics/search-console/third-party scripts) and favicon --
neither is one of the 17 documented design properties, so a user had no
reason to read them as included. Copy now names both explicitly.
Re-verified every remaining claim in the paragraph against what the
handler actually does (page/header/footer replacement, no undo, no
publish call, images untouched, 30000ms auto-save) -- all still hold.
Verified load-bearing by temporarily reverting each guard in place (no git
stash -- shared across worktrees/sessions per review feedback) and
confirming the corresponding test fails: dropping the !!domain check broke
the empty-domain unit test; removing the handleResetSite check broke a new
test that invokes the confirm button's React onClick directly (bypassing
both the disabled attribute and react-dom's own disabled-click suppression,
which independent investigation confirmed blocks a plain DOM `.disabled =
false; .click()`/dispatchEvent bypass -- pulling onClick off the element's
stashed __reactProps$ key was the only way to actually exercise the
handler's own guard).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
