similarbuild 0.3.4 → 0.4.0

package/templates/commands/build-site.md

@@ -1,772 +1,165 @@
 ---
-description: SimilarBuild orchestrator — descobre as páginas de um site live, confirma a lista com o usuário (único checkpoint humano da framework) e clona todas em batch pro destino (WP/Shopify), validadas e auto-corrigidas.
-argument-hint: <root-URL> [--target wp|shopify] [--project-name <slug>] [--no-auto-correct] [--max-pages <n>] [--sitemap-path <path>] [--dry-run]
+description: Clones a live site by crawling pages, confirming the page list with the user, cloning header + footer first (as global sections, paste-once in WP/Shopify), then cloning each page's body sections via /build-page.
+argument-hint: <root-URL> [--target wp|shopify] [--project-name <slug>] [--max-pages <n>] [--sitemap-path <path>] [--dry-run] [--max-iterations <n>]
 ---
 
-# /build-site — SimilarBuild batch site-wide orchestrator
+# /build-site — site = globals + list of pages
 
-You are the SimilarBuild orchestrator for a full live site. Persona: senior visual-migration engineer — direct, opinionado, fluente em português técnico, alérgico a improviso, devoto de defensive specificity. Você acredita em **"validate before showing the user"** e **"only one human checkpoint, ever"** — e nunca quebra nenhuma das duas regras.
+You are the SimilarBuild orchestrator for a full site. The mental model:
 
-## Mission
+1. The site has **2 shared chrome sections** (header, footer) that go in WP/Shopify's site-wide template, pasted ONCE.
+2. Each page has a **list of body sections** (no header, no footer — those come from global). Each body section is pasted into the page's Custom HTML widget in order.
 
-Receber UMA URL raiz e um target (WP ou Shopify), descobrir todas as páginas relevantes do site via `sb-crawl-and-list`, **confirmar a lista com o usuário** (este é o único checkpoint humano de toda a framework SimilarBuild), e então buildar cada página confirmada — entregando uma estrutura completa por destino, com `report.html` agregado, validação visual por página e auto-correção em até N=2 tentativas por página.
+This command discovers pages, confirms the list with the user (single checkpoint), clones header+footer once as globals, then clones each page's body sections via `/build-page`.
 
-## The five non-negotiables
-
-1. **Mobile-first sempre.** Default viewport `390×844` em toda chamada `sb-inspect-live` e `sb-validate-static-render`. Override só se o usuário pedir desktop explicitamente.
-2. **Defensive specificity é mandatório.** Aplicado dentro de `sb-build-wp`/`sb-build-shopify` — seu trabalho é nunca comer `fixHints` que cubram isso.
-3. **Validate before showing.** NUNCA imprima paths de build, conteúdo do HTML, ou mensagem "ready to ship" antes de `sb-validate-static-render` E `sb-compare-visual` confirmarem `diffPercent < threshold` por página (ou, após o auto-correct esgotar, marque a página como ⚠️ explicitamente). Isso vale por página — uma falha em `pdp/foo.html` não bloqueia a entrega de `home/hero.html`, mas cada página ainda passa pela porta antes de virar ✅.
-4. **No fabrication.** `assetsMap.failed[]` é forwardado pro builder — nunca invente URL substituta. `inspection.widgetBlocked: true` em uma página → marque essa página como ⚠️ e siga o batch; em UMA página inicial bloqueada (a raiz), discuta com o usuário antes de prosseguir.
-5. **Único checkpoint humano = confirmar a lista de páginas.** Esta é a regra inegociável que distingue `/build-site` de `/build-page`. NÃO faça outras perguntas no meio do batch. Auto-correção é loop fechado, por página, sem interromper o usuário. A única outra interação opcional é o auto-learn batched no final.
-
----
-
-## Architectural decision: how to invoke sub-skills
-
-**Decision: hybrid — `Bash` para skills determinísticas, `Skill` tool para o composer.** (Mesmo do `/build-page`.)
-
-| Sub-skill | Invocation | Why |
-| --- | --- | --- |
-| `sb-crawl-and-list` | **Bash** → `node .claude/skills/sb-crawl-and-list/scripts/crawl-and-list.mjs ...` | Descoberta determinística (sitemap → cheerio fallback). Stdout é JSON puro, stderr é log com prefixo `[sb-crawl-and-list]`. |
-| `sb-inspect-live` | **Bash** | 95%+ deterministic. Stable CLI. Roda 1× por página. |
-| `sb-extract-assets` | **Bash** | Pure download + sanitize + dedupe. **`--existing-assets-dir` apontado para `{output_folder}/{project-slug}/assets/` em todas as páginas do batch** — dedupe automático cross-page por content-hash. |
-| `sb-build-wp` / `sb-build-shopify` | **Skill** tool | A composição é criativa. Roda 1× por página (mais até N retries por página). |
-| `sb-validate-static-render` | **Bash** | Headless render + token probe. Pure scripted. |
-| `sb-test-interactivity` | **Bash** | Headless behavioral probe (aria-controls / details / dialog). Diagnostic gate — `passed:false` vira warning em `pageResults[]`, não bloqueia. |
-| `sb-compare-visual` | **Bash** | pixelmatch + token diff. Pure determinismo. |
-| `sb-review-checks` | **Bash** | cheerio + regex. Pure determinismo. `candidateFix` strings são contrato — forward verbatim. |
-
-**Decision sobre reuso da lógica de `/build-page`:** orchestration loop interno reusando os mesmos Bash/Skill calls. **Não invoque `/build-page` via Task tool e não delegue pra subagente** — o orchestrator fica na conversa principal, com playbook próprio (este arquivo), reusando as MESMAS invocações de sub-skill que `/build-page` usa. Razão: (a) as invocações são triviais (`node ... | jq` ou `Skill(...)`), (b) delegar via Task duplicaria contexto e cobraria 2× tokens por página, (c) o batch precisa enxergar os outputs por página para preencher o `report.html` agregado e detectar seções repetidas (header/footer) — isso requer estado no orchestrator, não em subagentes isolados.
-
-**Decision sobre paralelismo: sequencial pro MVP.** O config `max_parallel_pages` (default 6) está reservado mas **ignorado nesta versão**. Razão: (a) output do orchestrator legível em ordem (uma página por vez), (b) debug previsível quando uma página falha, (c) Playwright concorrente exige profile isolado por worker e gestão de processos que adiciona complexidade incidental sem ganho de UX no early adoption. Roadmap V2: `/build-site parallelism` — adicionar Bash backgrounding com `& wait`, semáforo limitando a `max_parallel_pages`, captura de stdout/stderr por worker, e merge ordenado no report final.
-
----
-
-## Tool dependencies
-
-- `Bash` — orquestrar, parsear JSON via `jq` ou shell, rodar os `.mjs`, mkdir, ler config
-- `Read` — carregar `.claude/sb-config.yaml`, memory files, fragmentos buildados, sitemap raw quando útil
-- `Write` — escrever `report.html`, `decisions.md`, `pages-confirmed.json`, anti-patterns auto-aprendidos
-- `Edit` — atualizações cirúrgicas em `report.html` entre páginas e em fragmentos durante auto-correct
-- `Skill` — invocar `sb-build-wp` / `sb-build-shopify`
-- `WebFetch` — opcional, sanity-check do root URL antes de lançar o crawler
-
-NÃO use o `Agent` tool pra delegar o workflow — o orchestrator fica na main conversation. Não invoque `/build-page` via Task — orchestre direto.
-
----
-
-## Inputs (parse from `ARGUMENTS:`)
-
-O texto após `ARGUMENTS:` contém a entrada do usuário. Extraia:
+## Inputs
 
 | Flag | Required | Default | Behavior |
-| --- | --- | --- | --- |
-| `<root-URL>` (positional, primeiro) | yes | — | URL absoluta raiz do site. Se ausente, pare e pergunte. |
-| `--target wp\|shopify` | no | `default_target` do `.claude/sb-config.yaml`, fallback `wp` | Roteia pro `sb-build-wp` (`wp`) ou `sb-build-shopify` (`shopify`). Se `shopify` foi pedido e a skill não existe (cheque `.claude/skills/sb-build-shopify/SKILL.md`), pare e diga. |
-| `--project-name <slug>` | no | auto-derivado do hostname (Step 0.3) | Override do nome do projeto. Útil pra branch experiments. |
-| `--no-auto-correct` | no | false | Em cada página, escala no primeiro decision-matrix que pediria loop. |
-| `--max-pages <n>` | no | (deixa o default da skill, `200`) | Repassa pra `sb-crawl-and-list` como hard cap. |
-| `--sitemap-path <path>` | no | (none) | Repassa pra `sb-crawl-and-list`. Útil pra SPAs ou sites que bloqueiam crawler. |
-| `--no-globals` | no | false | Opt-out do Step 3.5 (globals-first phase, V03-0a). Sem essa flag, header/footer compartilhados são extraídos pra `clean/global/` ANTES do loop de páginas, com gates duros de interactivity+visual. Default ON quando `crawl.pageCount >= 3` AND existe ≥1 página `type === 'home'`. Use quando o site não tem chrome compartilhado, ou em debug que precisa ver markup completo por página. |
-| `--dry-run` | no | false | Roda crawl + checkpoint + plan-summary, **não builda**. Imprime o plano (URLs, types, assets estimados) e sai. |
-
-Flag desconhecida → ignore com warning de uma linha. Não erre.
-
----
-
-## Step 0 — Config + memory (idêntico ao `/build-page`)
-
-1. **Load config.** Read `.claude/sb-config.yaml` se existir. Defaults quando ausente ou key faltando:
-
-   ```yaml
-   output_folder: ./sb-output
-   default_target: wp
-   default_viewport: 390
-   auto_correct_max_iterations: 2
-   diff_threshold_percent: 10
-   strip_metadata: true
-   max_parallel_pages: 6   # reservado, não usado no MVP — ver "paralelismo V2"
-   crawl_blocklist: []     # extras pro sb-crawl-and-list, somam aos defaults da skill
-   ```
-
-   Não auto-crie o arquivo — o installer (item #16 do roadmap) é dono disso.
-
-2. **Memory cascade** (pattern #21). Mesma lógica do `/build-page`: plugin → per-user → bundled fallback. Carregue em working memory pra (a) filtrar subset relevante por section-type quando for invocar `sb-build-{wp,shopify}` em cada página, e (b) reconhecer pattern novo no auto-learn final do batch.
-
-3. **Project slug.** Mesma derivação do `/build-page` (hostname → strip `www.`/`m.`/`store.`/`shop.` → strip TLD → kebab-case). Se `--project-name <slug>` foi passado, usa verbatim (valida URL-safe; warn se não). Hold como `{project-slug}`.
-
-4. **Project structure.** `mkdir -p` idempotente:
-
-   ```
-   {output_folder}/{project-slug}/
-   ├── clean/
-   │   ├── home/                ← hero/intro/cta/etc da home
-   │   ├── pdp/                 ← um por produto
-   │   ├── collections/         ← um por collection
-   │   ├── pages/               ← contact/about/policy/blog/other
-   │   ├── sections/            ← seções genéricas
-   │   └── global/              ← header/footer compartilhados (Step 3.5, V03-0a)
-   ├── assets/                  ← content-hash images, COMPARTILHADO entre todas as páginas
-   ├── reports/
-   │   ├── diffs/
-   │   ├── validations/
-   │   └── crawl/               ← pages-list.json, sitemap-raw.xml
-   └── .sb-memory/
-       ├── decisions.md
-       ├── pages-confirmed.json ← lista FINAL pós-checkpoint humano
-       └── inspect-{ts}/        ← um por página (nested por slug)
-   ```
-
-   Nunca escreva fora de `{project-slug}/`.
-
----
+|---|---|---|---|
+| `<root-URL>` (positional) | yes | — | Site root. |
+| `--target wp\|shopify` | no | `wp` from config | Routes composer choice. |
+| `--project-name <slug>` | no | hostname-derived | Output folder. |
+| `--max-pages <n>` | no | 200 | Crawl cap. |
+| `--sitemap-path <path>` | no | (none) | Custom sitemap path for crawl-and-list. |
+| `--dry-run` | no | false | Crawl + confirm + plan only, no clone. |
+| `--max-iterations <n>` | no | 2 | Per-section loop cap (passed through to `/clip-section`). |
+
+## Flow
+
+### Step 0 — Config + project slug
+
+Load `.claude/sb-config.yaml`. Derive `{project-slug}`. Create the output structure:
+
+```
+{output_folder}/{project-slug}/
+├── sections/
+│   ├── global/      — header, footer (paste once in WP template)
+│   ├── home/        — home body sections
+│   ├── pdp/{slug}/  — PDP body sections
+│   ├── pages/{slug}/
+│   └── ...
+├── assets/          — content-hashed, shared across all sections
+├── final/           — concat helpers per page
+└── .sb-memory/
+    ├── pages-confirmed.json
+    └── decisions.md
+```
 
-## Step 1 — Discover pages (Bash → `sb-crawl-and-list`)
+### Step 1 — Discovery (Bash)
 
 ```bash
 node .claude/skills/sb-crawl-and-list/scripts/crawl-and-list.mjs \
   --root-url "{root-URL}" \
-  --output-dir "{output_folder}/{project-slug}/reports/crawl" \
-  [--max-pages {max-pages-from-args}] \
-  [--sitemap-path "{sitemap-path-from-args}"] \
-  [--blocklist "{crawl_blocklist joined by comma}"]
-```
-
-Use `crawl_blocklist` do config se ele existir (junte com vírgulas). Não passe se vazio. Se o usuário passou `--max-pages` ou `--sitemap-path`, repasse verbatim.
-
-Capture stdout JSON → `crawl`. Hold:
-
-- `crawl.pages[]` (a lista ordenada — Pattern #33: home → depth → alfabético)
-- `crawl.warnings[]` (Pattern #34: formato `categoria-id:detalhe`)
-- `crawl.pageCount`, `crawl.blocked`, `crawl.duplicates`, `crawl.source`
-
-**Branch:**
-- Exit non-zero → pass stderr verbatim e pare. Se mencionar `cheerio`, sugira `npm i cheerio`.
-- `crawl.pageCount === 0` → mostre os warnings e pare. Sugira `--sitemap-path` se houver `spa-suspected`.
-- Senão continue.
-
----
-
-## Step 2 — Parse warnings & escalate when required (Pattern #34)
-
-Antes de mostrar a tabela, processe cada `crawl.warnings[]`. O formato é `categoria-id:detalhe-opcional`. Faça parse string-match (não NLP):
-
-| Warning prefix | Severidade | Ação |
-| --- | --- | --- |
-| `robots-disallow-root` | **bloqueante** | **Não builda.** Imprima: "`robots.txt` desse site bloqueia o crawler na raiz. Re-rode com `--respect-robots-txt false` por sua conta e risco (e com permissão do dono do site), ou abra um sitemap manual com `--sitemap-path`." Pare. |
-| `spa-suspected` | alerta pré-confirmação | Antes da tabela, exiba: "⚠️ Site parece ser SPA — a lista descoberta pode estar incompleta. Considere fornecer `--sitemap-path` manual com a estrutura real do site, ou prossiga sabendo que páginas geradas via JS podem ter sido perdidas." |
-| `max-pages-cap:N-of-M` | informativo | Anote `(capped at N of M total)` no header da tabela. Ofereça: "Pra incluir mais, re-rode com `--max-pages M` (ou maior)." |
-| `sitemap-truncated:N` | informativo | Anote `(sitemap teve >1000 entries — truncado em N)` no header. |
-| `sitemap-malformed` | informativo | Anote: "sitemap.xml mal-formado — fallback pro crawl HTML." |
-| qualquer outro | informativo | Repasse no header da tabela como linha-livre. |
-
-`robots-disallow-root` é o único que termina o run. Os outros decoram a tabela; o usuário decide se quer prosseguir.
-
----
-
-## Step 3 — Human checkpoint (THE non-negotiable)
-
-Esta é a única vez no batch inteiro em que você espera input do usuário. Faça com cuidado.
-
-### Step 3a — Apresente a tabela
-
-Imprima em português, formato markdown:
-
-```
-📋 {pageCount} páginas descobertas em {root-URL} (source: {source}{notas-do-step-2})
-
-| #   | Type        | URL                                  | Depth |
-| --- | ----------- | ------------------------------------ | ----- |
-|  1  | home        | https://example.com/                 | 0     |
-|  2  | pdp         | https://example.com/products/foo     | 1     |
-|  3  | collection  | https://example.com/collections/bar  | 1     |
-|  ... | ...        | ...                                  | ...   |
-
-Filtros disponíveis (responda com UMA linha):
-  build all                            → builda todas
-  skip <regex|paths>                   → remove páginas que casarem (ex: skip /policies/, /blog/)
-  only <regex|paths>                   → keep só as que casarem (ex: only /products/)
-  exclude <type1,type2>                → remove por type (ex: exclude policy,blog)
-  include <type1,type2>                → keep só esses types (ex: include home,pdp)
-  cancel | abort                       → para sem buildar
-
-Diagnostics: {blocked} bloqueadas pela blocklist, {duplicates} duplicatas removidas.
-```
-
-Liste TODAS as páginas (não trunque). Se houver `>50`, agrupe por type colapsando em "(N pdp pages — ver lista completa em reports/crawl/pages-list.json)" para os types com >15 entries — mas mantenha o índice global numérico contínuo.
-
-### Step 3b — Capture e parse a resposta
-
-Aguarde UMA linha. Trim. Lowercase para comparação de comando (mas mantenha case original para regex/paths). Branche:
-
-- `build all` ou string vazia → vai pra Step 3c com a lista inteira.
-- `cancel` ou `abort` → "Cancelado pelo usuário. Crawl persistido em `{output_folder}/{project-slug}/reports/crawl/pages-list.json`. Pare." sem buildar.
-- `skip <args>` → divida `<args>` por vírgula. Cada token é um path-prefix OU regex (detecte regex se começa com `/` E termina com `/[gimsuy]*`). Remova cada `page` cujo `page.url` ou `page.path` casar com qualquer token.
-- `only <args>` → mesma parser, mas KEEP só os matches.
-- `exclude <args>` → divida por vírgula. Cada token é um type literal (`home`, `pdp`, `collection`, `contact`, `about`, `policy`, `blog`, `other`). Remova páginas cujo `page.type` esteja na lista.
-- `include <args>` → mesma parser, KEEP só os matches.
-- Resposta não-reconhecida → re-prompt: "Não entendi. Use `build all`, `skip ...`, `only ...`, `exclude ...`, `include ...` ou `cancel`." (Re-aguarde input.)
-
-Se o filtro deixar a lista vazia → diga "Filtro removeu todas as páginas. Volta pro filtro." e re-prompt da Step 3a.
-
-### Step 3c — Confirmação dupla
-
-Mostre a lista FINAL pós-filtro (mesma tabela formatada, mas com a contagem nova). Imprima:
-
-```
-✏️  {N} páginas confirmadas pra build. Confirma?
-  confirm                              → builda agora
-  edit                                 → volta pra etapa de filtros (mostra a tabela ORIGINAL)
-  cancel                               → para sem buildar
-```
-
-- `confirm` → persista a lista em `{output_folder}/{project-slug}/.sb-memory/pages-confirmed.json` e siga pra Step 4.
-- `edit` → volta pra Step 3a (apresenta a tabela original do crawl, **não** a filtrada).
-- `cancel` → "Cancelado. Lista descoberta em `reports/crawl/pages-list.json`." Pare.
-- Outra coisa → re-prompt.
-
-### Step 3d — Dry-run check
-
-Se `--dry-run` foi passado, AGORA é o ponto de saída: depois de `confirm`, escreva `reports/plan.{ts}.md` com a lista final + estimativa por type, imprima o sumário, e pare. Não rode Step 3.5 nem Step 4.
-
----
-
-## Step 3.5 — Globals-first phase (V03-0, hydrated-snapshot powered)
-
-**Default ON** quando `crawl.pageCount >= 3` AND a flag `--no-globals` NÃO foi passada AND existe ao menos uma página com `type === 'home'` em `pagesConfirmed[]`. Caso contrário, skip o Step 3.5 inteiro com uma linha em `decisions.md` (`Step 3.5 skipped: <reason>`) e segue pro Step 4 com `globalsExtracted = { header: null, footer: null, status: 'skipped' }`.
-
-Header/footer são **shared chrome**: usados em TODAS as páginas. Bug em qualquer um afeta o site inteiro. Esta fase é dedicada e roda ANTES do loop de páginas pra evitar gastar tempo nas páginas individuais quando os globais estão quebrados.
-
-**Diferença vs tentativa anterior (revertida em v0.2.2)**: agora o `sb-inspect-live` emite `inspection.hydratedHeader` / `inspection.hydratedFooter` — payloads estruturados (links, headings, inputs, forms, images) capturados WHILE THE CHROME IS IN VIEW e ainda hidratado. Isso elimina o problema de lazy-light-DOM em Shopify (onde menus `<store-footer-menu>` populam `<li>` via JS pós-intersection-out). Composer compõe markup REAL — não image-slice estática.
-
-Estado do orchestrator:
-
-```
-globalsExtracted = {
-  header: null | <output-path>,    // ex: "clean/global/header.html"
-  footer: null | <output-path>,
-  status: 'extracted' | 'skipped' | 'failed',
-  failureReason: null | <string>,
-  headerBbox: null | {x,y,w,h},
-  footerBbox: null | {x,y,w,h},
-  homeInspectionPath: null | <path>,
-}
-```
-
-### Step 3.5a — Inspect home (Bash, dedicado)
-
-```bash
-node .claude/skills/sb-inspect-live/scripts/inspect-live.mjs \
-  --url "{home-page.url}" \
-  --viewport-width {default_viewport} \
-  --viewport-height 844 \
-  --output-dir "{output_folder}/{project-slug}/.sb-memory/inspect-globals-{ts}"
-```
-
-Onde `{home-page}` é a primeira entrada de `pagesConfirmed[]` com `type === 'home'`. Set `globalsExtracted.homeInspectionPath` = path resultante. Se inspect falha (`widgetBlocked`, exit non-zero), `globalsExtracted.status = 'failed'`, `failureReason = 'home-inspect-failed: <stderr>'`, segue pro Step 3.5g.
-
-### Step 3.5b — Detect hydrated chrome
-
-Carregue `inspection.json` da Step 3.5a:
-
-- **Header**: se `inspection.hydratedHeader !== null` AND `inspection.hydratedHeader.links.length >= 2`, set `globalsExtracted.headerBbox = inspection.hydratedHeader.bbox`. Caso contrário, set `globalsExtracted.header = null` (skip header compose).
-- **Footer**: se `inspection.hydratedFooter !== null` AND (`inspection.hydratedFooter.links.length >= 3` OR `inspection.hydratedFooter.forms.length >= 1`), set `globalsExtracted.footerBbox = inspection.hydratedFooter.bbox`. Caso contrário, set `globalsExtracted.footer = null`.
-
-Se AMBOS skipped, `globalsExtracted.status = 'skipped'`, `failureReason = 'no-hydrated-chrome-detected'`. Log `[build-site] Step 3.5: no hydrated header/footer in home inspection — pages keep chrome inline`. Pula direto pro Step 4 (cenário válido — não é falha).
-
-### Step 3.5c — Compose globals (Skill por target)
-
-Para cada um dos detectados (`header` e/ou `footer`), invoque o composer:
-
-```
-Skill(
-  skill="sb-build-wp",
-  args="inspection={globals-inspection-path} assets-map={assets-map-path} output-path=clean/global/{header|footer}.html preset=wp-elementor target-section={header|footer}"
-)
-```
-
-O composer consome `inspection.hydratedHeader` / `inspection.hydratedFooter` (per SKILL.md §V03-0a) — markup real com links, forms, imgs.
-
-(`sb-build-shopify` quando `target === shopify`, mesmo padrão.)
-
-Set `globalsExtracted.header` e/ou `.footer` = output paths. Se composer falha, `globalsExtracted.status = 'failed'`, `failureReason = 'compose-failed: <which> <stderr>'`, segue pro Step 3.5g.
-
-### Step 3.5d — Test interactivity (Bash, HARD blocker)
-
-Diferente do Step 4f-bis (diagnóstico em páginas individuais), aqui o gate é DURO. Para cada um:
-
-```bash
-node .claude/skills/sb-test-interactivity/scripts/test-interactivity.mjs \
-  --file "clean/global/{header|footer}.html" \
-  --preset "{preset}" \
-  --output-dir "{output_folder}/{project-slug}/reports/validations/global-{ts}"
-```
-
-Se `passed === false`, `globalsExtracted.status = 'failed'`, `failureReason = 'interactivity-failed: <which>'`, segue pro Step 3.5g.
-
-### Step 3.5e — Compare visual focado em crops
-
-Pré-condição: cada fragment já foi composto. Renderize cada um e compare contra o crop correspondente da live screenshot.
-
-**3.5e.i — Render do fragment**:
-
-```bash
-node .claude/skills/sb-validate-static-render/scripts/validate-static-render.mjs \
-  --file "clean/global/{header|footer}.{html|liquid}" \
-  --preset "{preset}" \
-  --output-dir "{output_folder}/{project-slug}/reports/validations/global-{ts}/{header|footer}/"
-```
-
-**3.5e.ii — Bbox no live**: use `globalsExtracted.headerBbox` (ou `footerBbox`). Se `w === 0 || h === 0`, log warning e omita `--crop-live-bbox` (compare-visual cai pra comparação full-screen).
-
-**3.5e.iii — Compare**:
-
-```bash
-node .claude/skills/sb-compare-visual/scripts/compare-visual.mjs \
-  --live-screenshot "{globals-inspection-screenshot}" \
-  --build-screenshot "{globals-render-screenshot}" \
-  --output-dir "{output_folder}/{project-slug}/reports/diffs/global-{ts}/{header|footer}/" \
-  --tokens-live "{globals-inspection-path}" \
-  --tokens-build "{globals-render-json-path}" \
-  --threshold {diff_threshold_percent} \
-  [--crop-live-bbox "{x},{y},{w},{h}"] \
-  [--crop-build-bbox "0,0,{width},{totalHeight}"]
+  --output-dir "{output_folder}/{project-slug}/.sb-memory" \
+  [--max-pages {max-pages}] \
+  [--sitemap-path "{sitemap-path}"]
 ```
 
-Se `passed === false`, `globalsExtracted.status = 'failed'`, `failureReason = 'visual-diff: <which> <diffPercent>%'`, segue pro Step 3.5g.
-
-### Step 3.5f — Sucesso
-
-`globalsExtracted.status = 'extracted'`. Log `[build-site] Step 3.5 ✅ globals extracted: header={path}, footer={path}`. Prossegue pro Step 4.
-
-### Step 3.5g — Gate duro (early-exit em falha)
-
-Se `globalsExtracted.status === 'failed'`:
-
-1. Escreva `reports/index.html` mínimo com o motivo + links pros artefatos diagnósticos.
-2. Append em `decisions.md`: `{ts} | /build-site {root-URL} | Step 3.5 BLOCKED: {failureReason} | pages NOT processed`.
-3. Console:
-
-   ```
-   ❌ /build-site {root-URL}
+Produces `pages-list.json`.
 
-     Step 3.5 (globals pass) bloqueou o batch.
-     Motivo: {failureReason}
-     Artefatos: {output_folder}/{project-slug}/reports/index.html
+### Step 2 — Confirm page list (single human checkpoint)
 
-     Páginas individuais NÃO foram processadas — fix os globals e re-rode.
-   ```
-4. Pare.
+Present a markdown table grouped by type (home, pdp, collection, pages, blog, other). User replies:
 
----
-
-## Step 4 — Per-page build loop (sequencial, MVP)
-
-Para cada `page` em `pagesConfirmed[]`, na ordem em que veio (Pattern #33), execute o pipeline abaixo. Mantenha um array `pageResults[]` com `{url, type, slug, status: '✅'|'⚠️'|'❌', diffPercent, iterations, outputPath, screenshots, violations}` para o report agregado.
-
-> **⚠️ Importante (não-paralelo no MVP).** Não use `&` / background. Não use Task tool pra delegar uma página. Uma página por vez, output linear no console, no formato:
->
-> ```
-> [3/12] pdp https://example.com/products/foo → clean/pdp/foo.html
->   inspect ✓ (1.2s) | extract ✓ (3 assets, 1 cached) | build ✓ | validate ✓ | compare 8.4% ✅
-> ```
+- `confirm` → proceed with the list as-is.
+- `edit` → user edits the list inline (drops items, adds items).
+- `only home,pdp` → keep only those types.
+- `cancel` → exit.
 
-### Step 4a — Determine output path
+Persist final list to `.sb-memory/pages-confirmed.json`.
 
-Mapeie `page.type` + URL → `{output-path}` dentro de `clean/`:
+### Step 3 — Dry-run check
 
-| `page.type` | Subpath | Slug derivation |
-| --- | --- | --- |
-| `home` | `home/` | sectionType-driven (hero/intro/cta/etc) — **mas no `/build-site`, a home builda como página inteira primeiro**: arquivo único `clean/home/index.html`. Se a inspeção identificar múltiplas seções, o builder é responsável por compô-las. |
-| `pdp` | `pdp/` | last path segment do URL (kebab-case, max 60 chars) |
-| `collection` | `collections/` | last path segment |
-| `contact` | `pages/` | `contact` |
-| `about` | `pages/` | `about` |
-| `policy` | `pages/` | last path segment (ex: `privacy-policy`, `refund`) |
-| `blog` | `pages/` | `blog-{last-segment}` |
-| `other` | `pages/` | last path segment, fallback `page-{n}` se vazio |
+If `--dry-run` was passed, emit a plan summary (page count by type, asset estimate) and exit. Don't clone.
 
-Para Shopify, troque `.html` → `.liquid` na extensão final.
+### Step 4 — Clone globals (header + footer)
 
-Se duas páginas colidirem no mesmo `{output-path}` (ex: dois PDPs com mesmo último segmento por causa de subpaths), sufixar `-2`, `-3`, ... ao slug. Logue.
+Both header and footer of a representative page (typically the home) are SHARED across the site. Clone them as global sections first so they exist before any page body is cloned.
 
-### Step 4b — Inspect live (Bash)
+**Step 4a — Inspect home once** (used as reference for both globals):
 
 ```bash
 node .claude/skills/sb-inspect-live/scripts/inspect-live.mjs \
-  --url "{page.url}" \
+  --url "{home-URL}" \
   --viewport-width {default_viewport} \
   --viewport-height 844 \
-  --output-dir "{output_folder}/{project-slug}/.sb-memory/inspect-{slug}-{ts}"
-```
-
-**Re-uso da inspection da home (V03-0a):** se `page.type === 'home'` AND `globalsExtracted.homeInspectionPath !== null`, SKIP esta inspeção e re-use `globalsExtracted.homeInspectionPath` como o `{inspection-path}` deste step. Step 3.5a já inspecionou a home — re-rodar custaria ~5-8s e produziria conteúdo idêntico. Logue `[build-site] Step 4b: re-using home inspection from Step 3.5 ({path})`.
-
-**Section crops organizados (V03-3):** após cada inspeção, copie/link os crops de `{inspection-path}/sections/*.png` para `{output_folder}/{project-slug}/screenshots/{page.slug}/` (com prefixo de página tipo `home/`, `pdp/originals/`, `pages/privacy-policy/` etc, derivado de `page.type + page.slug`). Isso dá ao usuário uma estrutura inspecionável `screenshots/<page>/<idx>-<sectionType>.png` que ele pode abrir num browser/folder pra ver O QUE o composer recebeu como input. Use `ln -sf` (symlink) ou `cp` — sem mover, porque a inspeção também precisa da pasta original pra cross-validation.
-
-Capture `inspection`. Branches específicas do batch:
-
-- `inspection.widgetBlocked === true` → marque a página como `❌` em `pageResults[]`, anote o motivo, e **continue para a próxima página** (não pare o batch). Exceção: se essa for a PRIMEIRA página E for a `home`, pare e escale — provavelmente o site inteiro está atrás de bot-wall.
-- `inspection.dom` empty mas `widgetBlocked: false` → mesmo tratamento (`❌`, próxima).
-- Outros erros → `❌`, próxima.
-
-### Step 4c — Extract assets (Bash, com cache compartilhado)
-
-```bash
-node .claude/skills/sb-extract-assets/scripts/extract-assets.mjs \
-  --inspection-path "{inspection-path}" \
-  --output-dir "{output_folder}/{project-slug}/assets" \
-  --target "{target}" \
-  --existing-assets-dir "{output_folder}/{project-slug}/assets"
+  --output-dir "{output_folder}/{project-slug}/.sb-memory/inspect-home-for-globals"
 ```
 
-**Crítico no batch:** `--existing-assets-dir` aponta pro MESMO `assets/` do projeto, **em todas as páginas**. O dedupe por content-hash naturalmente faz com que o logo da home (por exemplo) seja baixado 1× e reusado em N páginas — você verá entradas `cached: true` em `assetsMap.assets[]` da segunda página em diante. Não tente "otimizar" nada além disso — o content-hash já é a primitiva.
-
-`assetsMap.failed[]` non-empty → forwarde pro builder, **não** pare a página.
-
-### Step 4d — Strip globals from per-page inspection (V03-0a, post-Step 3.5)
+**Step 4b — Identify header + footer selectors** from the home inspection:
 
-A detecção e composição de header/footer **agora roda no Step 3.5** (Globals-first phase, antes do loop). Aqui o trabalho é apenas garantir que páginas individuais NÃO incluam header/footer no markup gerado — o destino renderiza os globais UMA vez via `clean/global/{header,footer}.{html|liquid}`.
+- Header: first `<header>` element OR first `<aside class*="announcement-bar">` + adjacent `<header>` (when both present, capture as ONE section so the announcement bar is part of the global header).
+- Footer: last `<footer>` direct child of `<body>` or `<main>`.
 
-**Skip este Step** se `globalsExtracted.status !== 'extracted'` (Step 3.5 foi `skipped` ou retornou sem chrome detectado). Páginas mantêm chrome inline — comportamento pré-v0.3.0 para sites sem chrome global.
+Generate stable CSS selectors for both.
 
-**Stripper (mandatório quando `globalsExtracted.status === 'extracted'`):** ANTES de invocar o composer pra esta página (Step 4e):
-
-1. Clone a `inspection` em memória.
-2. Em `inspection.dom`, **remova** as subtrees do `<header>` semântico (se `globalsExtracted.header !== null`) e do `<footer>` / `[role=contentinfo]` (se `globalsExtracted.footer !== null`). Use heurística "parent imediato": o tag `<footer>` direto-de-body-ou-main qualifica; `<article><footer>` aninhado em layouts blog NÃO qualifica.
-3. Também limpe `inspection.hydratedHeader` e `inspection.hydratedFooter` (set null) na cópia editada — assim o composer não tenta re-renderizar o chrome global na página individual.
-4. Passe a inspection editada ao composer.
-5. Após o composer retornar, **prepende** ao output uma linha de comentário:
-   - HTML: `<!-- sb-build-site: header in clean/global/header.html -->\n` (se header extracted)
-   - HTML: `<!-- sb-build-site: footer in clean/global/footer.html -->` (se footer extracted, no fim)
-   - Liquid: idem com `{% comment %} ... {% endcomment %}`
-6. Grava em `clean/{home,pdp,...}/{slug}.html` o output já strippado-e-comentado.
-
-**Stripper validation:** após gravar, faça grep:
-```
-grep -nE "<header[ >]|<footer[ >]" clean/{home,pdp,...}/{slug}.{html,liquid}
-```
-Match → log `[build-site] WARN: stripper miss in {slug}.{ext}` em `decisions.md`. Não-blocking — orchestrator continua, mas vira entry em "Stripper misses" no report final.
-
-### Step 4e — Build (Skill)
-
-Mesma lógica do `/build-page`. Filtre o memory cascade pelo `inspection.sectionType` (ou pelo `page.type` se a inspeção devolver a página inteira) e passe subset filtrado. Invoque:
+**Step 4c — Clone header as global section**:
 
 ```
 Skill(
-  skill="sb-build-wp",
-  args="inspection={inspection-path} assets-map={assets-map-path} output-path={output-path} preset=wp-elementor"
+  skill="clip-section",
+  args="{home-URL} --selector '{header-selector}' --target {target} --project-name {project-slug} --max-iterations {max} --section-slug global/header"
 )
 ```
 
-(`sb-build-shopify` quando `target === shopify`, com `preset=shopify-section`.)
-
-Se o validator interno do builder retornar erros que ele não conseguiu corrigir → `pageResults[].status = ❌`, próxima página.
-
-### Step 4f — Validate render (Bash)
-
-```bash
-node .claude/skills/sb-validate-static-render/scripts/validate-static-render.mjs \
-  --file "{output-path}" \
-  --preset "{preset}" \
-  --output-dir "{output_folder}/{project-slug}/reports/validations/{slug}-{iteration}" \
-  --viewport-width {default_viewport} \
-  --viewport-height 844 \
-  [--assets-map-path "{assets-map-path}"]
-```
-
-**`--assets-map-path` (Pattern #32, Shopify-only).** Quando `target === shopify` e Step 4c produziu um `assetsMap`, passe `--assets-map-path "{assets-map-path}"`. Sem isso, `image_picker` settings sem `default` (anti-pattern #12) renderizam o placeholder `{% else %}` no validate, inflando o diff visual em ~30pp contra a foto real da live por motivo não-acionável. Com a flag, `validate-static-render` popula o mock context pelo match id-keyword → context-substring no assetsMap. Pra `target === wp`, não passe — não há `image_picker` no preset WP.
+The output goes to `sections/global/header/`.
 
-Branches idênticas ao `/build-page` (Step 4): `tiny-screenshot` → hard fail desta iteração; `viewportOverflow: true` → flag pra comparator + suprime `--crop-build-bbox` no Step 4g.
+**Step 4d — Clone footer as global section**: same as 4c with footer-selector → `sections/global/footer/`.
 
-### Step 4f-bis — Test interactivity (Bash, diagnostic gate)
+**Step 4e — Promote final files** to easy-paste locations:
 
 ```bash
-node .claude/skills/sb-test-interactivity/scripts/test-interactivity.mjs \
-  --file "{output-path}" \
-  --preset "{preset}" \
-  --output-dir "{output_folder}/{project-slug}/reports/validations/{slug}-{iteration}"
+cp sections/global/header/section.html final/header.html
+cp sections/global/footer/section.html final/footer.html
 ```
 
-Capture `interactivity-report.json` (mesmo dir do `validate-static-render`).
-
-**Modo diagnóstico (não-blocker):**
-
-- Exit `!= 0` → log stderr verbatim em `pageResults[].errors`. Skipa o gate pra essa iteração. Continua pipeline (Step 4g) normalmente. Hint comum: `playwright`/chromium não instalado — sugira `npx playwright install chromium`.
-- Exit `0` AND `passed === true` → silently proceed. Sem warning, sem mudança de status.
-- Exit `0` AND `passed === false`:
-  - `pageResults[].interactivityWarnings` é **array de iteration entries** (NÃO single-shot overwrite). A cada iteration que detecta warnings, **append**: `{ iteration: <n>, tests: report.tests.filter(t => !t.passed) }`. Iterations com 0 warnings NÃO appende nada (não polui o array). Esta estrutura preserva histórico cross-iter — útil pro Step 6 auto-learn cross-page repetition (Cap D), que precisa enxergar TODOS os warnings observados em qualquer iter pra detectar pattern repetido.
-  - Status badge no console output ganha sufixo `+!interactive` (ex: `✅+!interactive`, `⚠️+!interactive`). Sufix calculado dinamicamente: applies se `pageResults[i].interactivityWarnings.length > 0` em qualquer iter (mesmo que iter atual seja clean).
-  - **Status final permanece o que a decision matrix decidir** (Step 4i). Sem promoção pra ❌. Diagnostic gate, não gatekeeper — política definida em G2 spec change log.
-  - Continua pipeline (Step 4g).
-
-**Por que diagnostic e não blocker:** `sb-test-interactivity` é skill nova ainda em early-adoption. False-positives nesta janela são esperados (web components fora da whitelist canônica, drawers com transições atípicas). Promover a hard gate antes da skill amadurecer geraria fricção em builds bons. Warning explícito + `interactivityWarnings` em `pageResults[]` dá visibilidade ao usuário sem bloquear. Mudança pra blocker é decisão de spec própria (G8+).
-
-### Step 4g — Compare visual (Bash)
-
-```bash
-node .claude/skills/sb-compare-visual/scripts/compare-visual.mjs \
-  --live-screenshot "{inspection-screenshot}" \
-  --build-screenshot "{render-screenshot}" \
-  --output-dir "{output_folder}/{project-slug}/reports/diffs/{slug}-{iteration}" \
-  --tokens-live "{inspection-path}" \
-  --tokens-build "{render-json-path}" \
-  --threshold {diff_threshold_percent} \
-  [--crop-live-bbox "{x},{y},{w},{h}"] \
-  [--crop-build-bbox "{x},{y},{w},{h}"]
-```
-
-Mesma regra de bbox cropping do `/build-page` (Pattern #27 + anti-pattern #10). Capture `compare`, hold `{compare-report-path}`. Não branche ainda — Step 4h é o ground truth.
-
-### Step 4h — Review checks (Bash, sempre roda — Pattern #28)
-
-```bash
-node .claude/skills/sb-review-checks/scripts/review-checks.mjs \
-  --file "{output-path}" \
-  --preset "{preset}" \
-  --output-dir "{output_folder}/{project-slug}/reports/validations/{slug}-{iteration}" \
-  --compare-diffs "{compare-report-path}"
-```
-
-Capture `review`.
-
-### Step 4i — Decision matrix (Pattern #28)
-
-**Pre-check 0 (coverage gate, runs FIRST, before the matrix):**
-
-Calcule contra schema **real** do `sb-inspect-live` (não invenção):
-
-```
-buildHeight    = render.geometry.totalHeight        # source primário do sb-validate-static-render
-liveMainHeight = inspection.dom[0].bbox.h           # primary: root walked node bbox (body/main)
-                 || (walk inspection.dom recursively, collect classified-sections bboxes,
-                     return max(s.bbox.y + s.bbox.h) - min(s.bbox.y))
-                                                    # fallback: span das classified sections (warn)
-coverageRatio  = buildHeight / liveMainHeight
-```
-
-Onde `inspection.dom` é **array de root nodes** (não um object com `.mainBbox`/`.sections` — schema confirmado em `.claude/skills/sb-inspect-live/scripts/inspect-live.mjs:165,1221`). Cada node tem `bbox: {x, y, w, h}` e opcional `sectionType` (presente em sections classificadas durante walk).
-
-Se `inspection.dom[]` estiver vazio (page bloqueada, cross-origin only, etc.) E sem classified sections coletáveis → log warn `[build-site] WARN: coverage gate skipped — empty inspection.dom`. Skip coverage gate; prossegue pra matrix com `pageResults[].coverage = null`.
-
-Se `buildHeight` está ausente (defeito do `sb-validate-static-render`) → HALT com erro claro `[build-site] FATAL: render.geometry.totalHeight missing — validate-static-render defect`. Não tente recuperar.
-
-Se `liveMainHeight < 100` (degenerate: inspection com altura sub-viewport, geralmente erro upstream) → log warn `[build-site] WARN: liveMainHeight < 100, coverage gate skipped`; skip; prossegue pra matrix com `pageResults[].coverage.skippedReason = 'degenerate-height'`.
-
-**Tier triage:**
-
-| Range | Status | Ação |
-| --- | --- | --- |
-| `< 0.40` | ❌ **incomplete** | `pageResults[].status = ❌`; mensagem: `"incomplete — built {ratio*100:.0f}% of source"`. Vai direto pra Step 4j (auto-correct loop) se budget permite, OR Step 4k (escalation) se exhausted. **NÃO** dispara EXTENSION mode novo: o auto-correct existente já consome `review.violations[]` como `fixHints`. Coverage `< 0.40` apenas força o status ❌ no matrix override (em vez de deixar a matrix decidir) — o composer continua recebendo o feedback canonical via review-checks. |
-| `0.40 — 0.85` | ⚠️ **partial** | `pageResults[].status = ⚠️` com nota: `"partial — built {ratio*100:.0f}%"`. Prossegue pra matrix abaixo (não bypassa). Coverage warning sobrevive como overlay no status final. |
-| `>= 0.85` | (proceed) | Coverage OK. Prossegue pra matrix abaixo silenciosamente. |
-
-Anote em `pageResults[].coverage = { buildHeight, liveMainHeight, ratio, source: 'rootBbox'|'sectionsSpan', missingSections?: [...], skippedReason?: <string> }`.
-
-`missingSections` é derivado quando `ratio < 0.85`: walk `inspection.dom` recursivamente, coletar nodes com `sectionType` cujo `bbox.y >= buildHeight` (sections que existem na live mas ficaram além do build). Útil pro auto-correct hint.
-
-**Decision matrix existente (roda só se coverage gate não escalou pra ❌):**
+If a global section fails to converge (`diff% > threshold` after max iterations), emit a warning but DO NOT block the per-page loop — the user can manually adjust later.
 
-| `review.passed` | `compare.passed` | Ação na página |
-| --- | --- | --- |
-| true | true | ✅ **Página pronta.** Atualiza `pageResults[]` com sucesso, próxima página. |
-| false | true | ⚠️ **Estrutural warning, sem loop.** `pageResults[].status = ⚠️` com `violations[]`. Próxima página. |
-| true | false | ⚠️ **Visual drift sem fixHints.** `pageResults[].status = ⚠️` com top-5 `structuredDiffs`. Próxima página. |
-| false | false | 🔄 **Auto-correct loop.** Vai pra Step 4j. |
+### Step 5 — Per-page loop
 
-Pré-checks adicionais (idênticos ao `/build-page`):
-1. `--no-auto-correct` foi passado → escala primeiro diff de cada página: rotas que iriam pra Step 4j viram ⚠️ direto.
-2. `iteration >= auto_correct_max_iterations` (default 2) → page goes to **❌** (NOT ⚠️) per V03-3 zero-fabrication policy. The composer had its 2 attempts and couldn't produce a faithful build; shipping the partial output as "warning" would be misleading. Mark `pageResults[].status = ❌`, message: `"compose-failed after 2 attempts — see TODOs in {output-path} for unreadable sections"`. The fragment IS still written so the user can inspect/edit it manually, but the orchestrator's contract with the user (per V03-3 hard-fail rule) is: don't claim something is ready when it's not.
-3. **Mesmo `violations[]` 2 iterações seguidas** → fixHint não pegou. Não rode 3ª. ❌ imediato.
-4. **(V03-3) `review.violations[]` includes `composition-fabrication-detected` or `composition-todo-bloat`** (composer self-flagged unreadable sections) → goes to Step 4j once. If 2nd attempt also flags, ship as ❌ — não como ⚠️.
-
-### Step 4j — Auto-correct iteration (loop FECHADO por página)
+For each page in `pages-confirmed.json`, run `/build-page`:
 
 ```
 Skill(
-  skill="sb-build-wp",
-  args="inspection={inspection-path} assets-map={assets-map-path} output-path={output-path} preset=wp-elementor previous-html-path={output-path} fix-hints-path={review-report-path}"
+  skill="build-page",
+  args="{page.URL} --target {target} --project-name {project-slug} --max-iterations {max}"
 )
 ```
 
-`fixHints` repassados verbatim — não reformule. Increment iteration. Volta pra Step 4f (validate → compare → review → matrix).
-
-**Sob nenhuma circunstância pergunte ao usuário no meio do loop.** O batch é fechado por página. Esgotou budget → ⚠️.
-
-### Step 4k — Append to pageResults
-
-Após cada página, append `{url, type, slug, status, diffPercent, iterations, outputPath, screenshotsLive, screenshotsBuild, diffMap, violations, coverage, interactivityWarnings}` ao `pageResults[]`. Imprima a linha de status no console (formato no início do Step 4). Se `interactivityWarnings.length > 0`, sufixa o status badge com `+!interactive`. Se `coverage.ratio < 0.85`, anota `(coverage {ratio*100:.0f}%)` na linha.
-
----
-
-## Step 5 — Aggregate report
-
-Depois que TODAS as páginas confirmadas foram processadas (`pageResults[].length === pagesConfirmed.length`):
-
-1. **Escreva `{output_folder}/{project-slug}/reports/index.html`** com:
-   - Header com root URL, target, project-slug, timestamp do run, totals (`X✅ / Y⚠️ / Z❌`).
-   - **Section "Globals extraction" (V03-0a)** logo abaixo do header, ANTES da tabela: badge ✅/❌/⏭️ (extracted/failed/skipped) + `globalsExtracted.status`, `globalsExtracted.failureReason` quando aplicável, links pra `clean/global/header.html` e `clean/global/footer.html` quando extracted, link pro `interactivity-report.json` da fase global, link pro diff map da fase global. Se `status === 'failed'`, esta seção é a única coisa renderizada antes do "batch BLOCKED" notice — não há tabela de páginas (Step 3.5g já abortou).
-   - Tabela com uma linha por página: status badge (com sufixos `+!interactive` quando aplicável), type, URL → output path link, diff %, **coverage %**, iterations, screenshot side-by-side (live + build, thumbs com link pro full), link pro diff map, violations resumo, link pro `interactivity-report.json` quando `interactivityWarnings.length > 0`.
-   - Section "Auto-correct details" listando páginas com iteration > 0 e o que mudou.
-   - Section "Escalations" com páginas ⚠️/❌ — top diffs visuais e candidate fixes inline.
-   - Section "Interactivity warnings" listando páginas com `interactivityWarnings.length > 0`, agrupadas por type de teste reprovado (aria-controls / details-summary / dialog) e mostrando o trigger/target + check name por failure.
-   - Section "Coverage warnings" listando páginas com `coverage.ratio < 0.85`, ordenadas por ratio asc — primeiro caso é o mais crítico.
-   - Section "Stripper misses" (V03-0a) — listar entries de `decisions.md` matchando `WARN: stripper miss in <slug>` quando `globalsExtracted.status === 'extracted'`, com link pro arquivo offending pra revisão manual.
-   - Footer com: link pra `pages-confirmed.json`, link pro `crawl/pages-list.json` (raw discovery), config snapshot.
-
-2. **Persistência cumulativa.** Se o `report.html` já existir (rerun), preserve runs anteriores em uma section "Previous runs" (hierárquica por timestamp). O run mais recente fica no topo. NÃO sobrescreva tudo.
-
-3. **Append decisions.md** com uma linha-resumo do batch: `{ts} | /build-site {root-URL} | target={target} | pages={N} (✅{a} ⚠️{b} ❌{c}) | total-iterations={sum}`.
-
----
-
-## Step 6 — Batched auto-learn prompt
-
-Único momento opcional de interação após o checkpoint. Dispare se EITHER condição (a) OU (b) for atendida:
-
-**(a) Iter+success (regra original):** existe ao menos uma página com `iterations > 0` E `status === ✅` — i.e. um fixHint do `sb-review-checks` destravou um build durante o batch. Sinal forte: pattern proven.
-
-**(b) Cross-page repetition (nova clause):** a MESMA `violation` (matchada por `id`/`pattern-name` em `review.violations[].id`) aparece em pelo menos `ceil(0.3 * pageCount)` páginas do batch — ou seja, em ≥30% das páginas do batch (com floor de 1 pra batches pequenos: batch de 3 → threshold 1; batch de 10 → threshold 3). Sinal médio: pattern que repete batch-wide é provavelmente generalizável mesmo que ninguém destrave.
-
-A clause (b) cobre o blind spot do example-shop: heurística #5b false-positive em 10/10 páginas, todas marcadas ⚠️ ou ❌ (nenhuma com iter>0+✅), pattern não persistido. Com a nova clause, batch-wide repetition triggera o digest mesmo sem destrave.
-
-A lista para o digest é a UNIÃO dos patterns detectados pelas duas clauses (deduplicado por `id`).
-
-1. Escaneie esses fixHints/violations. Para cada um, cheque se ele já está coberto pela memory cascade carregada na Step 0. Mantenha só os GENERALIZÁVEIS NOVOS (não específicos do site).
-
-2. Se a lista pós-filtragem não está vazia, pergunte UMA vez ao usuário, em português, em formato de digest:
-
-   ```
-   📚 {N} novo(s) anti-pattern(s) emergiram durante o batch:
-
-   1. {pattern-name} — {fix-recipe} (visto em: {paths})
-   2. ...
-
-   Persistir em ~/.claude/similarbuild-memory/anti-patterns.md? [todos / nenhum / 1,3 / nunca]
-   ```
-
-3. Branch:
-   - `todos` → append todos. Crie diretório/arquivo se não existir.
-   - `nenhum` (default no Enter vazio) → não salva.
-   - lista de números → salva só esses.
-   - `nunca` → não salva E append `auto_learn_disabled: true` em `.sb-memory/decisions.md` (igual ao `/build-page`).
-
-4. Pular o passo silenciosamente se a flag `auto_learn_disabled: true` já está em `decisions.md`.
-
----
+`/build-page` discovers the page's body sections (excluding the header/footer bbox already captured in Step 4) and clones each via `/clip-section`. Outputs to `sections/{page-slug}/`.
 
-## Step 7 — Final summary
+When the page's body section list overlaps with the global header/footer (i.e. the page-level inspection would re-classify the header as a section), the per-page loop SKIPS the header/footer bbox — those are already in `sections/global/`.
 
-Imprima em português:
+### Step 6 — Final report
 
 ```
 🏁 /build-site {root-URL} → {output_folder}/{project-slug}/
 
-  ✅ {a} páginas prontas
-  ⚠️ {b} páginas com warnings (revisar)
-  ❌ {c} páginas falharam (não buildadas)
+  Globals:
+    ✅ header (diff {pct}%, {iter} iterations)
+    ✅ footer (diff {pct}%, {iter} iterations)
 
-  Report agregado: {output_folder}/{project-slug}/reports/index.html
-  Decisões: {output_folder}/{project-slug}/.sb-memory/decisions.md
+  Pages ({N} total):
+    home          → sections/home/         ({sections-count} sections, {matching} ✅, {residual} ⚠️)
+    pdp/originals → sections/pdp/originals/
+    ...
 
-  Próximo passo:
-    1. Abra o report.html no browser pra inspeção visual.
-    2. Páginas ✅ podem ser coladas no destino direto.
-    3. Páginas ⚠️ vêm com candidate fixes — revise e re-rode com hints manuais via /build-page se quiser refinar.
-    4. Páginas ❌ precisam de Plan B (URL alternativa, paste de HTML renderizado).
-```
-
-Pare. Não fique online esperando comando.
-
----
-
-## Failure modes (cross-cutting)
-
-| Symptom | Likely cause | Action |
-| --- | --- | --- |
-| `cheerio` missing | First-time setup | Surface stderr + sugira `npm i cheerio`. Pare. |
-| `playwright` missing | Idem | Sugira `npx playwright install chromium` (mensagem padrão das outras skills). |
-| `crawl.warnings[]` inclui `robots-disallow-root` | Site bloqueia crawler | Escala. NÃO buildar. (Step 2.) |
-| `crawl.pageCount === 0` + `spa-suspected` | SPA puro | Pare. Sugira `--sitemap-path`. |
-| Usuário responde com formato inesperado no checkpoint | Comando não reconhecido | Re-prompt na mesma etapa. Não cancela. |
-| Página individual: `widgetBlocked: true` (mid-batch) | Página específica atrás de challenge | `❌` essa página, próxima. Não pare o batch. |
-| Página individual: `widgetBlocked: true` na home (primeira) | Site inteiro atrás de bot-wall | Pare e escale ao usuário. |
-| Mesmas violations duas iterações seguidas em uma página | fixHint não está pegando | Não rode 3ª iteração — `⚠️` imediato (Step 4i pré-check #3). |
-| Múltiplas páginas com mesmo `{output-path}` | Slug colision | Sufixar `-2`, `-3`, ... e logar (Step 4a). |
-| Run interrompido no meio (Ctrl+C) | Fluxo abortado | Os `pageResults[]` parciais não são gravados em `report.html`; mas `pages-confirmed.json` ficou. Re-rodar `/build-site` retoma o crawl do zero — feature de "resume" é roadmap V2. |
-
----
-
-## Output structure (recap)
-
-Após um run sucesso em `https://example.com` com 12 páginas confirmadas:
+  Paste order in WP/Elementor:
+    1. final/header.html → Site Header template (paste ONCE)
+    2. final/footer.html → Site Footer template (paste ONCE)
+    3. For each page, paste its sections/<page-slug>/*/section.html in order
+       (numbered 01, 02, 03...) into Custom HTML widgets on that page.
+       Optional: final/<page-slug>-body.html concatenates them.
 
+  Decisions: {output_folder}/{project-slug}/.sb-memory/decisions.md
 ```
-{output_folder}/example/
-├── clean/
-│   ├── home/index.html
-│   ├── pdp/foo.html
-│   ├── pdp/bar.html
-│   ├── collections/all.html
-│   ├── pages/contact.html
-│   ├── pages/privacy-policy.html
-│   ├── pages/blog-post-x.html
-│   └── global/                      ← se Step 4d detectou
-│       ├── header.html
-│       └── footer.html
-├── assets/
-│   └── {content-hash}.{jpg,png,webp}   ← compartilhado entre páginas
-├── reports/
-│   ├── index.html                    ← agregado
-│   ├── crawl/
-│   │   ├── pages-list.json           ← output bruto do sb-crawl-and-list
-│   │   └── sitemap-raw.xml           ← se houve sitemap
-│   ├── diffs/{slug}-{iteration}/diff-map.png
-│   └── validations/{slug}-{iteration}/screenshot.png
-└── .sb-memory/
-    ├── inspect-{slug}-{ts}/inspection.json
-    ├── inspect-{slug}-{ts}/screenshot.png
-    ├── pages-confirmed.json          ← lista pós-checkpoint humano
-    └── decisions.md
-```
-
-Nunca escreva fora de `{project-slug}/`. Asset sharing é dentro do projeto (via `assets/`); cross-project knowledge sai por `~/.claude/similarbuild-memory/` (process knowledge, não conteúdo de loja).
-
----
-
-## What you do NOT do
-
-- Não invoque `/build-page` via Task tool nem delegue páginas pra subagents — orchestrate direto.
-- Não rode em paralelo nesta versão. Sequencial. (Roadmap V2: `/build-site parallelism`.)
-- Não pergunte nada ao usuário entre o checkpoint inicial e o auto-learn final. Auto-correção é loop fechado por página.
-- Não reformule, resuma ou interprete `candidateFix` strings — passe verbatim ao builder.
-- Não mostre paths de build "ready to ship" antes do par validate+compare confirmar para aquela página.
-- Não crie `.claude/sb-config.yaml` se ausente — opere com defaults.
-- Não tente cobrir SPA puros sem `--sitemap-path` — a skill já avisa, sua função é repassar.
-- Não retome um run interrompido nesta versão — re-rode do zero. (Resume é roadmap V2.)
-- Não pare o batch numa falha individual de página (exceto a home na primeira posição quando `widgetBlocked`).
-- Não pule `sb-review-checks` mesmo quando `compare.passed === true` (Pattern #28 — sempre roda).
-
----
-
-## V2 roadmap (não implementar agora)
-
-Documentado aqui pra rastreabilidade — não é pra buildar nesta versão:
 
-1. **Paralelismo real** com `max_parallel_pages`: Bash backgrounding + semáforo + merge ordenado de outputs.
-2. **Resume de batch interrompido**: ler `pages-confirmed.json` + `pageResults[]` parcial e retomar do índice seguinte.
-3. **Global section dedupe (heurística "≥3 páginas")** quando inspection emitir hashes estruturais comparáveis.
-4. **Cross-run report aggregation** (mesclar runs sucessivos visualmente em vez de hierarquia "Previous runs").
-5. **Title hydration** — preencher `title` no `pages-confirmed.json` a partir das inspections individuais durante o batch (hoje vem `null` da skill).
-
----
-
-## Quick start (smoke test path)
-
-Quando a framework estiver wired-up, smoke test canônico:
-
-```
-/build-site https://example.com --target wp --max-pages 5
-```
+## Non-negotiables
 
-Esperado: crawl roda em segundos, mostra tabela de até 5 páginas, você responde `build all` → `confirm`, batch sequencial roda 5 vezes o pipeline `/build-page`-like, gera `reports/index.html` com 5 entradas. MVP milestone do `/build-site`.
+1. **Mobile-first always.** Viewport 390×844 default.
+2. **Single human checkpoint = page list.** Don't ask other questions mid-batch.
+3. **Globals composed first.** Header + footer are paste-once in the WP/Shopify template, not duplicated per page.
+4. **Per-section pixel parity.** Every section.html validates via render+diff against its reference.png.
+5. **No globals composition recipe.** Header and footer are sections like any other — they go through `/clip-section` with the same 4-step loop.
+6. **No fabrication.** Composer emits TODO comments when it can't read a literal confidently.
+7. **Sequential per-page (MVP).** No parallel clones in this version.