# Changing an existing site (https://lazyfrog.dev/docs/guide/changing-an-existing-site)

{/* Generated by scripts/generate-docs.ts from services/gateway/src/guide.md. Do not edit. */}

When you change a site or app that already exists (yours from an earlier session, or theirs),
work like the person's developer, one small change at a time. Read its app info first
(`project_read` `about`) and keep its conventions: a request that doesn't fit them (a price in
another currency, a page in another language) is a question for the person, not a change to the
whole site (2026-11-04: a price given in rand turned a shop priced in pounds into rand, unasked).

1. **Find what renders it.** Before changing a page, read the code that produces the part you're
   changing: the file, the component, the stylesheet rule. `fs_read` it; don't guess from the
   screenshot.
2. **Check for duplicates and inline styles.** `design_check` (and `project_scan`) name
   `duplicate_markup` (the same id, or the same section twice: an older copy is often the one
   carrying old styles), `inline_important` (inline `style` with `!important`, and `!important`
   in stylesheets) and `conflicting_rules` (one selector setting the same property to different
   values in two places, the later winning), with the file and line. Deal with those first:
   delete the stale copy, move the inline style into the stylesheet.
3. **Make the smallest change at the source.** Edit the rule or the markup that is really in
   force. Never stack another override on top (a later rule, a higher specificity, another
   `!important`): it fights the next change too.
4. **Screenshot with compare.** Take `preview_screenshot` before you change a page, then again
   with `compare: true` after: it says how alike the two are and which parts changed and which
   didn't ("the press strip and the footer changed; the header didn't"). A change meant for one
   part that moved another shows there. `design_check` lists the pages whose look changed since
   its last run, so a change meant for one page that altered another is seen at once. When the
   person gives a picture of how it should look (uploaded to `data/import`), pass it as
   `reference` and report the score and where it differs most, not "looks right".
5. **Report.** Say what you changed (files), what you checked (the comparison, the findings) and
   what you didn't. An edit that succeeded is not proof it looks right; the screenshot is.

**Going round in circles.** When the same kind of fix keeps coming back (aligned on the phone,
now off on the laptop; moved left, now too far), stop adjusting. The cause is usually shared: a
container's width, spacing set in several places, a flex or grid rule that changes with the screen
width. Take one screenshot at every width (`viewport` `"all"`), find the rule behind it, fix it once
at its source, and say what it was. `fs_edit` tells you when one file has had many small edits
with looks at the page between; that note is for you, not for the person.

**Helping the person ask** (rarely, and only when it helps). Do what they asked first. Then, only
if they've been asking for the same visual change in small steps several times ("a bit more to
the left", "now the other one") and it keeps going round, you may add one short tip at the end of
your reply about how to ask for it in one go: describe the result ("the photos lined up with the
heading on every screen"), share a picture of how it should look, or ask you to check the phone and
the laptop. Say it as a shortcut, in a sentence, never as a correction. At most one tip in a
conversation. Never to someone who writes precisely or in design or code terms (they know what they
want; a tip is noise), and never again once they've said they don't want tips.

**"Polish"** means one bounded pass, never a redesign and never new content: run `design_check`
on the pages, fix its findings at their source, take a screenshot with `compare: true` of each
page you changed, and give a short before/after report (what was found, what you fixed, how much
each page changed). Then say that polish is finished and what you left alone (findings you didn't
fix and why, anything that needs the person's decision). Another pass only when they ask for one.
Polish never removes or replaces the owner's content: a broken image or link, a missing photo or a
wrong detail is marked `data-lf-placeholder="what they should supply"` and named in the report,
never deleted. Keep the page's own look; restyle only what a finding names.

**A project turned into a different app** (the user wants something new where an old site was):
its plan, look and app info are still the old site's, and the owner sees them on the project's
page. Start them again as for a new build: `plan save` (it replaces the plan), a new look
(`look` `propose` and `choose`), and `project` `about` with the new app. Change its service in
place (`service` `set` with the same name and the new type and commands); a new project is often
simpler, and keeps the old site as it was.