fix web clone prompt seed across type switches - #7140
fix web clone prompt seed across type switches#7140open-design-crew[bot] wants to merge 2 commits into
Conversation
|
QA browser verification (Simplified Chinese)
Automated validation: 631 test files passed; 6679 tests passed, 1 expected fail, 11 skipped. Typecheck and guard passed. |
|
🧪 This PR has changes that need a manual QA pass before merge — please hold off self-merging for now; we'll loop QA in once it's merge-ready (and design/product have signed off, where applicable). |
PerishCode
left a comment
There was a problem hiding this comment.
The persisted prompt-ownership marker can become stale across an existing live handoff, which makes the new remount logic delete a real user prompt. Please make marker revocation part of every non-scaffold prompt replacement and cover that remount path.
🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.| && !( | ||
| pendingChipRestore?.chipId === 'web-clone' | ||
| && ( | ||
| pendingChipRestore.promptSeedKind === 'web-clone' |
There was a problem hiding this comment.
Revoke a stale scaffold marker before treating every restored prompt as system-owned. The existing HOME_COMPOSER_SEED_EVENT path at onSeed replaces the prompt and marks it edited, but it does not clear active.promptSeedKind; the persistence effect therefore saves { chipId: 'web-clone', promptSeedKind: 'web-clone' } beside the handed-off prompt. After a real unmount/remount, this branch marks that arbitrary non-empty prompt unedited solely because the marker exists, and switching away from Website clone then clears it. This loses the prompt passed by seedHomeComposerPrompt, a documented cross-surface flow. Clear promptSeedKind whenever a non-scaffold prompt replaces the seed (including the live seed event), or centralize prompt replacement so the marker can only remain while the prompt is exactly the scaffold. Add a regression that selects Website clone, dispatches a different live seed, unmounts/remounts, switches to Prototype, and verifies the handed-off prompt remains.
|
Follow-up QA for manual Website-clone scaffold dismissal:
Automated validation: focused Home regressions 45/45; full web 6680 passed, 1 expected fail, 11 skipped; web typecheck and root guard passed. |
PerishCode
left a comment
There was a problem hiding this comment.
The persisted Website-clone seed ownership can still survive a live prompt handoff and cause a real user prompt to be deleted after remount. Please revoke seed ownership for every non-scaffold prompt replacement and add the live-handoff remount regression before merge.
🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.| if (active?.promptSeedKind) { | ||
| setActive({ ...active, promptSeedKind: null }); |
There was a problem hiding this comment.
Clear seed ownership for programmatic prompt replacements too. These changed lines revoke promptSeedKind only when handlePromptChange processes an editor edit, but the existing HOME_COMPOSER_SEED_EVENT handler replaces the prompt with setPrompt(prompt) and marks it user-edited without clearing active.promptSeedKind. The persistence effect then stores the handed-off prompt beside promptSeedKind: 'web-clone'; after unmount/remount, the new restore logic treats that arbitrary prompt as system-owned, and switching to Prototype deletes it. Update the live seed handler (and preferably centralize all non-scaffold prompt replacement) to clear promptSeedKind, then add a regression that selects Website clone, calls seedHomeComposerPrompt with different text while mounted, unmounts/remounts, switches to Prototype, and verifies that text remains.


















































Why
I hit this while verifying the Chinese Home creation-type tabs. Website clone inserts a localized URL scaffold into an empty composer, but switching to Prototype or another type preserved that scaffold as if it were user-authored text. A reload made the problem sticky because the restored non-empty draft was marked as user-edited.
Follow-up UI verification found a second part of the same user flow: manually deleting the Website-clone scaffold worked only for the current page session. Reloading or restarting restored the scaffold, despite the user's explicit deletion.
What users will see
An untouched Website-clone URL scaffold is cleared when the user switches to another creation type. If the user adds a URL or edits the scaffold, the draft remains intact.
If the user manually deletes the scaffold, it stays dismissed across type switches, Home remounts, page reloads, and a full local daemon/web restart. The dismissal is scoped to the current Home composer draft and is cleared after a successful creation, together with the rest of that draft.
Drafts leaked by the previous behavior are cleaned up on the first fixed load, and the system-owned/user-owned distinction survives a real unmount and remount.
Surface area
apps/weborapps/desktop(including Electron menu bar)odsubcommand or flag, newtools-dev/tools-packflag, or newOD_*env var/api/*endpoint, new SSE event, or changed shape inpackages/contractsskills/,design-systems/,design-templates/, orcraft/, or change to the skills protocolTRANSLATIONS.mdfor the locale workflow)package.json(dependenciesordevDependencies); workspace-packagepackage.jsonfiles are out of scope.Screenshots
Before/after browser verification screenshots are attached in the QA comments. The latest comment shows the empty Website-clone composer after manual deletion and confirms it remains empty after reload and a full local service restart.
Bug fix verification
apps/web/tests/components/HomeView.web-clone-tracking.test.tsx想要复刻的网站链接:.想要复刻的网站链接:.Validation
pnpm --filter @open-design/web test— 631 files passed; 6680 tests passed, 1 expected fail, 11 skippedpnpm --filter @open-design/web typecheckpnpm guardhttps://example.comURL remains across type switches and reload