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>
Adds a danger-zone escape hatch below SiteDesignPanel's existing "Reset to
Defaults": blanks every page down to one empty Home, blanks the header and
footer, and resets all design tokens. Guarded by typing the exact site
domain to arm the confirm button.
The brief's setHeader('')/setFooter('') calls were wrong -- both take a
SerializedTreeNode (same tree shape as replaceAllPages), not a craft-state
string; passing '' would have hit treeToCraftState's sanitizeAiTree and
silently fallen back to a generic div-shaped empty canvas instead of a
proper header/footer. Built BLANK_HEADER_TREE/BLANK_FOOTER_TREE (tagged
header/footer) alongside the brief's page tree, and dropped the brief's
literal's extraneous flat-state fields (isCanvas/displayName/custom/hidden/
linkedNodes) that made it need an `as any` cast -- sanitizeAiTree/
flattenTreeForCraft only ever read type/props/nodes.
In standalone mode (no WHP_CONFIG) siteDomain is '', so the entire danger
zone -- not just the button -- is hidden behind `siteDomain &&`, closing off
the empty-string-trivially-matches guard bypass.
Dialog copy states the reset is undoable... is NOT undoable, and that
auto-save (confirmed exactly 30s via TopBar.tsx's setInterval) turns the
blank canvas into the saved draft shortly after, so no false safety-net
claim is made.
Verified load-bearing: reverted the implementation via git stash and
confirmed 3 of 4 new tests fail (the 4th, an absence-only standalone-mode
check, passed vacuously on first draft -- rewritten into a same-test
contrast against the non-standalone case, which does fail on revert).
Split into a second mock-free integration test file
(SiteDesignPanel.reset.integration.test.tsx) after vi.mock's file-scoped
hoisting made a same-file vi.doUnmock silently keep using the mocks --
it exercises the real PageProvider/SiteDesignProvider/treeToCraftState
pipeline end to end via the real editorHarness.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
shadowdaoandClaude Opus 5