Describe and Save a Site

Workflow for analyzing a website and saving it as a brand memo set (Overview + Page memos + Recipes). Run the steps in order. A step that fails stops the work and goes back to the user. The reference memos named in each step hold the details; this memo says what to do, in which order, and when to stop. 1 START - Read Rules, Brand Memo Templates, Extraction Procedure & Screenshots and Components, Motion & Recipes. Add CJK & RTL Typography for Japanese, Chinese, Korean, Arabic or Hebrew text, and Legacy Web (1990-2009) for designs before about 2010. Keep Vocabularies and Media, Assets & Legal at hand. - Scope: brand, domain, design year (or YYYY-MM), target region and language, page types to describe. Home always; other page types as asked, mapped with Vocabularies. - Existing memos: search-memo for "BRAND <Brand>" and the tag brand-<slug>. Same brand and year: update those memos, never duplicate. Another year, or a localized site that looks very different: a new set (Rules 2). - A question from the user ("can you describe X?", "do you know what to do?") is not a go-ahead. Answer with the plan and wait for an explicit go. 2 REGION (hard rule) The set describes the site as a visitor in the target region sees it. Interface language is not region: an English page served to another country is not the US version. - Every fetch and every screenshot uses the same route, from the very first request. If you are not in the target region, use a route that exits there. Example for the US: the Google Translate web proxy https://www-<domain-with-dashes>.translate.goog/<path>?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en (auto -> en leaves English text unchanged; the raw HTML is the original). - Test the route before trusting it: check its egress country (ipinfo-io.translate.goog/json, api-country-is.translate.goog/) and compare the geo data in the page fetched directly and through the route. Some proxy exits sit in another country, and some sites geolocate on the forwarded client IP, so a route can still give the wrong region. - A region chosen in the site's own switcher (Extraction Procedure & Screenshots 2 step 2) counts only if the page state then shows that country. - Prove the region before any analysis: the country in the HTML or page state ("country":"US", ipCountry, geo objects), plus currency, phone numbers and legal links of that country. Write the proof in the working notes; it goes into the captured line later. - No proof, proxy error, redirect to another country, single-page app that does not load, wrong country: stop and tell the user. Never fall back to another region and never explain afterwards that the region does not matter here. - In a browser through the translate proxy: hide the proxy toolbar (#gt-nvframe, .skiptranslate, md-dialog) with an init script, and never type into form fields (the proxy opens a "forms not supported" dialog). 3 FETCH - Download the HTML of one representative URL per page type, every stylesheet, and every script that renders visible components. Use curl with --compressed (CDNs send gzip otherwise), a desktop browser user agent and the target Accept-Language; follow redirects; check status 200, the lang attribute and the region proof on every page. - Client-rendered pages: take the stylesheet and script chunk URLs from the live page (document.styleSheets, script tags, performance resource entries) and fetch them separately. - Webpack single-page apps: the full map of CSS and JS chunks is in manifest-*.js (t.miniCssF for CSS, t.u for JS). Fetch all chunks rather than guessing which ones matter. - Keep working files in a scratch folder, never in memos. 4 ANALYZE THE CODE (draft first) Follow Extraction Procedure & Screenshots 2 steps 4-9 and its code techniques. Write a draft in a working file: tokens, fonts, layout, header and footer, components, pages. Spend the most effort on motion and interaction, which rebuilds miss most often: - every :hover, :focus-visible, :active and :disabled rule and the transition on it (property, ms, delay, easing); - every @keyframes and animation; - durations, easings, springs and formulas set in JS (search the minified code for the class names or custom property names used in CSS); - opening and closing of menus, mega-menus, drawers, modals, accordions, tabs and carousels: both directions, child stagger, switching between triggers, keyboard, mobile; - scroll effects: sticky, shrinking or hide-on-scroll headers, reveals, pinned or scrubbed sections, color changes by scroll. Each one becomes a one-line state note, an interaction record or a Recipe (Components, Motion & Recipes 3 and 8). To find the code of a visible component, search the localization dictionary for its text, take the string id, and search the code for that id. 5 SCREENSHOTS Only when the draft is complete. - Open an isolated browser context (for example chrome-devtools) through the same region route. Check the region again inside the page before the first capture. - Viewports: 1440x900 desktop, 390x844 at 2x mobile; the period viewport for old designs (Vocabularies). - Capture: every described page full length at both widths; first screens; a state sheet (buttons, links, cards, inputs in default, hover, focus-visible, active); every menu, mega-menu, drawer, modal and overlay opened; 2-4 key frames of each animation (closed, mid, open). - Names, captions and the minimum set: Extraction Procedure & Screenshots 5. - Scroll the page once before a full-page capture so lazy content loads; close cookie banners with their own buttons; keep the tab in front. - A mobile full page taller than 16384px cannot be captured at 2x: capture it at 1x with the tab in front. - A capture with the wrong size, region or state is retaken, never attached with an excuse. 6 COMPARE AND FIX - Close the browser. Look at every screenshot next to the draft: section order, elements, colors, sizes, states, animation frames. - Fix the draft where the page differs and add what the code did not show. - Reopen the browser only to check single elements or values that exist nowhere in the code, through the same route and with the same region check. 7 WRITE THE MEMOS Only when the draft and the screenshots agree. - Minimum set: Overview + Page: home + one Recipe per signature motion. Add a Page memo for every other page type in scope. - Fill Brand Memo Templates in section order: English, plain text, TOKENS block as CSS custom property lines. Evidence once in the header, exceptions inline with (est), (ext) or (inf); "not measured, est <value>" instead of an empty MUST field. - captured line: URL, date, region and route (e.g. "US via Google Translate proxy") and the region proof. - Title with brand and year; preview with brand, year, domain and what the memo covers; meta with retrieval cues (Rules 2). - Tag every memo with brand-<slug>; create the tag if missing, with a context line naming the brand and domain. - Links: Page -> Overview; Overview and Page -> the Recipes they use. No other links. - Attach screenshots to the brand memo they illustrate (request-file-upload, upload the bytes, confirm-file-upload) and write one caption entry per file in its SCREENSHOTS section. - Write recognition keys and guardrails last and put them at the top of the Overview. 8 CHECK - Completeness check, then rebuild check (Extraction Procedure & Screenshots 6 and 7). Fix the memos until the rebuild looks like the same design, and write the result in the Overview header. 9 REGISTER THE BRAND IN README - New brand: add one text line at the end of the numbered list in the README section "Brands", with the next number: <Brand> <year> — <domain>, `brand-<slug>`. - New year of a brand already listed: add the year to its existing line. Never renumber or reorder the list. - Do not change the brands image above the list unless the user explicitly asks for it. 10 REPORT Tell the user: memo titles created or updated, the region proof, pages and Recipes covered, the rebuild check result, values left as (est), (ext) or (inf), and anything not done.