similarbuild 0.1.0 → 0.2.1

package/CHANGELOG.md

@@ -31,7 +31,7 @@ Claude Code.
 - `sb-build-shopify` — compositor Shopify Section `.liquid` com `{% schema %}`
   editável, settings agrupadas, presets, sem `image_picker default`,
   `{{ block.shopify_attributes }}` em iterações.
-- `sb-validate-render` — render offline via preset YAML, captura screenshot +
+- `sb-validate-static-render` — render offline via preset YAML, captura screenshot +
   probe de tokens; suporta `--assets-map-path` pra Shopify mock context (resolve
   `image_picker` settings via id-keyword × context-substring).
 - `sb-compare-visual` — pixelmatch + token cross-check, scope-aware com

package/README.md

@@ -26,7 +26,7 @@ determinísticas** atrás de **3 slash commands** que entregam o arquivo pronto:
 Pipeline padrão (cada step é uma sub-skill):
 
 ```
-inspect-live → extract-assets → build-{wp|shopify} → validate-render
+inspect-live → extract-assets → build-{wp|shopify} → validate-static-render
             → compare-visual → review-checks → (auto-correct loop) → entrega
 ```
 
@@ -175,7 +175,7 @@ Cada arquivo é machine-parseable (campos
 | `sb-extract-assets`    | Baixa imagens, strip metadata (EXIF/XMP/IPTC), dedupe content-hash. |
 | `sb-build-wp`          | Compõe HTML/Elementor com defensive specificity + a11y/perf.       |
 | `sb-build-shopify`     | Compõe `.liquid` com `{% schema %}` editável + shims locais.       |
-| `sb-validate-render`   | Renderiza fragment offline (preset YAML), captura screenshot+tokens.|
+| `sb-validate-static-render`   | Renderiza fragment offline (preset YAML), captura screenshot+tokens.|
 | `sb-compare-visual`    | pixelmatch + token cross-check, scope-aware crops simétricos.      |
 | `sb-review-checks`     | Cheerio audit de 14 anti-patterns + 12 design checks (a11y/perf/web).|
 | `sb-tweak`             | Edita arquivo entregue via pedido natural PT/EN, atomic-revert.    |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "similarbuild",
-  "version": "0.1.0",
+  "version": "0.2.1",
   "description": "Visual migration framework for Claude Code — clone a live page, get a paste-ready WordPress/Elementor or Shopify section file, validated and auto-corrected.",
   "type": "module",
   "bin": {

package/templates/commands/build-page.md

@@ -13,9 +13,9 @@ Receive ONE URL and a target (WP or Shopify) and deliver ONE file the user can p
 
 ## The four non-negotiables (inherited from the bootstrap)
 
-1. **Mobile-first sempre.** Default viewport `390×844` on every `sb-inspect-live` and `sb-validate-render` call. Override only if the user explicitly demanded desktop.
+1. **Mobile-first sempre.** Default viewport `390×844` on every `sb-inspect-live` and `sb-validate-static-render` call. Override only if the user explicitly demanded desktop.
 2. **Defensive specificity is mandatory.** This is enforced inside `sb-build-wp` / `sb-build-shopify` — your job is to never strip `fixHints` that target it.
-3. **Validate before showing.** NEVER print the build path, contents, or "ready to ship" message to the user before BOTH `sb-validate-render` AND `sb-compare-visual` confirm `diffPercent < threshold` (or, after auto-correction exhausted, you escalate explicitly).
+3. **Validate before showing.** NEVER print the build path, contents, or "ready to ship" message to the user before BOTH `sb-validate-static-render` AND `sb-compare-visual` confirm `diffPercent < threshold` (or, after auto-correction exhausted, you escalate explicitly).
 4. **No fabrication.** If `sb-extract-assets` returns a `failed[]` entry, surface it; never invent a substitute URL. If `sb-inspect-live` returns `widgetBlocked: true`, stop and escalate to user — don't compose from a blocked page.
 
 ---
@@ -29,11 +29,12 @@ Receive ONE URL and a target (WP or Shopify) and deliver ONE file the user can p
 | `sb-inspect-live` | **Bash** → `node .claude/skills/sb-inspect-live/scripts/inspect-live.mjs ...` | 95%+ deterministic. Stable CLI. LLM adds zero value to the invocation — it just passes args. |
 | `sb-extract-assets` | **Bash** → `node .claude/skills/sb-extract-assets/scripts/extract-assets.mjs ...` | Same. Pure download + sanitize + dedupe. |
 | `sb-build-wp` / `sb-build-shopify` | **Skill** tool → `Skill(skill="sb-build-wp", args="...")` | **The composition is creative**: pick the pattern, name the scope, place defensive specificity. The skill's SKILL.md + `references/wp-build-rules.md` are the LLM's manual. Bash can't compose. |
-| `sb-validate-render` | **Bash** → `node .claude/skills/sb-validate-render/scripts/validate-render.mjs ...` | Headless render + token probe. Fully scripted. |
+| `sb-validate-static-render` | **Bash** → `node .claude/skills/sb-validate-static-render/scripts/validate-static-render.mjs ...` | Headless render + token probe. Fully scripted. |
+| `sb-test-interactivity` | **Bash** → `node .claude/skills/sb-test-interactivity/scripts/test-interactivity.mjs ...` | Headless behavioral probe (aria-controls / details / dialog). Diagnostic gate — `passed:false` becomes a warning, not a block. |
 | `sb-compare-visual` | **Bash** → `node .claude/skills/sb-compare-visual/scripts/compare-visual.mjs ...` | pixelmatch + token diff. Pure determinism. |
 | `sb-review-checks` | **Bash** → `node .claude/skills/sb-review-checks/scripts/review-checks.mjs ...` | cheerio + regex. Pure determinism. Its `candidateFix` strings are the contract — you forward them verbatim, never reformat. |
 
-**Why not all-Skill:** the deterministic five would burden the orchestrator with their SKILL.md instructions on every loop iteration (the auto-correct loop calls `validate-render` + `compare-visual` + `review-checks` up to N+1 times). Bash keeps each call to one CLI invocation and one JSON parse.
+**Why not all-Skill:** the deterministic five would burden the orchestrator with their SKILL.md instructions on every loop iteration (the auto-correct loop calls `validate-static-render` + `compare-visual` + `review-checks` up to N+1 times). Bash keeps each call to one CLI invocation and one JSON parse.
 
 **Why not all-Bash:** `sb-build-wp` has no compose CLI — its `build-wp.mjs` only handles `validate` and `write` subcommands. The actual composition is the LLM reading the skill's references and producing HTML. That work has to happen via Skill.
 
@@ -100,11 +101,11 @@ If the user passes any other flag, ignore it and continue (don't error on unknow
 3. **Project slug.**
    - If `--project-name <slug>` is given: use it verbatim (validate it's URL-safe; warn if not).
    - Else: derive from URL hostname.
-     - Parse hostname (e.g. `https://www.alphainfusemen.com/path?q=x` → `www.alphainfusemen.com`).
+     - Parse hostname (e.g. `https://www.example-store.com/path?q=x` → `www.example-store.com`).
      - Strip `www.`, strip leading subdomain only when it's `www`/`m`/`store`/`shop`.
      - Strip TLD (last `.xxx` or `.xxx.yy` for known compound TLDs like `.com.br`, `.co.uk`).
      - Lowercase, replace any non-`[a-z0-9]` with `-`, collapse repeats, trim leading/trailing `-`.
-     - Examples: `https://alphainfusemen.com` → `alphainfusemen`; `https://www.lojaexemplo.com.br/products/x` → `lojaexemplo`.
+     - Examples: `https://example-store.com` → `example-store`; `https://www.lojaexemplo.com.br/products/x` → `lojaexemplo`.
    - Hold as `{project-slug}` for the rest of the run.
 
 4. **Project structure.** Compute `{project-root}/{output_folder}/{project-slug}/` and ensure these subdirs exist (mkdir -p, idempotent):
@@ -202,7 +203,7 @@ Skill(
 
 If you have a `{designKnowledgeSubset}` or `{patternsSubset}` to pass, include them as additional `args` keys (`design-knowledge-inline=<base64-or-path>`); otherwise omit and let the skill use its bundled defaults.
 
-**The skill returns:** absolute path to the written file, validator's report (errors/warnings), and a one-line note on the chosen pattern. Do not request the file's contents back — you'll let `sb-validate-render` open it.
+**The skill returns:** absolute path to the written file, validator's report (errors/warnings), and a one-line note on the chosen pattern. Do not request the file's contents back — you'll let `sb-validate-static-render` open it.
 
 If the skill's validator returns errors and the skill couldn't fix them, surface to the user; this is a builder-side defect, not an auto-correct case.
 
@@ -211,7 +212,7 @@ If the skill's validator returns errors and the skill couldn't fix them, surface
 ## Step 4 — Validate render (Bash)
 
 ```bash
-node .claude/skills/sb-validate-render/scripts/validate-render.mjs \
+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}" \
@@ -227,7 +228,7 @@ Where `{preset}` is `wp-elementor` or `shopify-section`, `{slug}` is the section
 `image_picker` setting that the builder emitted *without a `default`* (per
 anti-pattern #12) renders as the `{% else %}` placeholder — a neutral grey
 fallback — which inflates `compare-visual` diff% by ~30pp against the live
-photo with no actionable fix. With it, `validate-render` mocks the
+photo with no actionable fix. With it, `validate-static-render` mocks the
 image_picker context from matching assetsMap entries (id-keyword → context-
 substring heuristic) so the rendered fragment shows real imagery.
 
@@ -246,6 +247,31 @@ Capture stdout JSON → `render`. Hold `{render-screenshot}` (`render.screenshot
 
 ---
 
+## Step 4-bis — Test interactivity (Bash, diagnostic gate)
+
+```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}"
+```
+
+Capture `interactivity-report.json` (same dir as `validate-static-render`). Hold the parsed report.
+
+**Diagnostic mode (NOT a blocker):**
+
+- Exit `!= 0` → log stderr verbatim and continue to Step 5 with no warning. Common hint: `playwright`/chromium missing — suggest `npx playwright install chromium`. Don't escalate.
+- Exit `0` AND `passed === true` → silently proceed. No warning, no status change.
+- Exit `0` AND `passed === false`:
+  - **Append** to `interactivityWarnings` array (NOT single-shot overwrite): `interactivityWarnings.push({ iteration: <n>, tests: report.tests.filter(t => !t.passed) })`. Iterations with 0 warnings do NOT append. Cross-iter history preserved — useful for the success/escalation path (Steps 8/10) which renders a section in `report.html` summarizing which iter saw which break.
+  - Status badge on the build's report ganha sufixo `+!interactive` (e.g. `✅+!interactive`). Calculated dynamically: applies if `interactivityWarnings.length > 0` em qualquer iter.
+  - **Final status remains whatever the decision matrix decides** (Step 7). No promotion to ❌. The skill is diagnostic, not a gatekeeper — policy locked in G2 spec change log. A user who wants hard blocking can re-run with the warning visible and choose to discard the build.
+  - Continue to Step 5.
+
+**Why diagnostic and not blocker:** `sb-test-interactivity` is new (G2). False-positives during early adoption are expected (web components outside the canonical whitelist, drawers with atypical transitions). Promoting to hard gate before maturity would block good builds. Explicit warning + `interactivityWarnings` in the report gives visibility without blocking. Promotion to blocker is a separate spec decision (G8+).
+
+---
+
 ## Step 5 — Compare visual (Bash)
 
 ```bash
@@ -283,7 +309,7 @@ drift. Crop both sides to their measured bboxes whenever possible.
   of points with no actual visual drift.
 
 Both DPR flags default to `3` (matches `sb-inspect-live`'s iPhone 14 profile and
-`sb-validate-render`'s aligned `deviceScaleFactor=3`, Pattern #22). Don't override
+`sb-validate-static-render`'s aligned `deviceScaleFactor=3`, Pattern #22). Don't override
 unless one of those skills was invoked at a different DPR.
 
 Capture stdout JSON → `compare`. Note the path to the persisted `report.json` → `{compare-report-path}`.
@@ -322,6 +348,39 @@ Capture stdout JSON → `review`. Note `review.passed` and the `violations[]` ar
 
 ## Step 7 — Decision matrix (Pattern #28)
 
+**Pre-check 0 (coverage gate, runs FIRST):**
+
+Calcule contra schema **real** do `sb-inspect-live`:
+
+```
+buildHeight    = render.geometry.totalHeight        # primary: from 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
+```
+
+`inspection.dom` is **array of root nodes** (schema in `.claude/skills/sb-inspect-live/scripts/inspect-live.mjs:165,1221`). Each node has `bbox: {x, y, w, h}` and optional `sectionType` for classified sections.
+
+If `inspection.dom[]` is empty AND no classified sections collectable → log warn `[build-page] WARN: coverage gate skipped — empty inspection.dom`. Skip coverage gate; proceed to existing matrix. Persist `coverage = null`.
+
+If `buildHeight` is missing (defeito do `sb-validate-static-render`) → HALT with clear error `[build-page] FATAL: render.geometry.totalHeight missing`. Don't try to recover.
+
+If `liveMainHeight < 100` (degenerate) → log warn `[build-page] WARN: liveMainHeight < 100, coverage gate skipped`; skip; persist `coverage.skippedReason = 'degenerate-height'`.
+
+**Tier triage:**
+
+| Range | Status | Action |
+| --- | --- | --- |
+| `< 0.40` | ❌ **incomplete** | Status: `"incomplete — built {ratio*100:.0f}% of source"`. Goes to existing Step 9 (auto-correct loop) if budget remains; existing `review.violations[]` driven fixHints feed back to composer. **NO new EXTENSION marker** — Step 9 already handles auto-correct via review-derived fixHints. Coverage `< 0.40` overrides matrix to ❌ (without it, matrix could route to ⚠️ and miss the issue). |
+| `0.40 — 0.85` | ⚠️ **partial** | Status: `"partial — built {ratio*100:.0f}%"`. Proceeds to matrix below (does NOT bypass). Coverage warning rides on top of whatever the matrix decides. |
+| `>= 0.85` | (proceed) | Coverage OK. Matrix below runs silently. |
+
+Persist `coverage = { buildHeight, liveMainHeight, ratio, source: 'rootBbox'|'sectionsSpan', missingSections?: [...], skippedReason?: <string> }` in the success/escalation report. `missingSections` (when `ratio < 0.85`): walk `inspection.dom` recursively, collect classified-section nodes whose `bbox.y >= buildHeight`.
+
+**Existing matrix (runs only when coverage gate didn't route to ❌):**
+
 You hold both `compare.passed` and `review.passed` now. Apply this matrix:
 
 | `review.passed` | `compare.passed` | Action                                                                                          |
@@ -366,7 +425,7 @@ You only reach here when `review.passed === true` AND `compare.passed === true`.
 
 ## Step 9 — Auto-correct loop body
 
-You only reach here from Step 7's matrix when **both** `review.passed === false` AND `compare.passed === false`. The pre-checks (no-auto-correct, budget exhausted) and the validate-render hard-failure (`tiny-screenshot`) all reroute to Step 10.
+You only reach here from Step 7's matrix when **both** `review.passed === false` AND `compare.passed === false`. The pre-checks (no-auto-correct, budget exhausted) and the validate-static-render hard-failure (`tiny-screenshot`) all reroute to Step 10.
 
 `review.violations[]` is in hand from Step 6 — fixHints to feed back into the builder.
 
@@ -446,10 +505,10 @@ You only reach here when the budget is spent. Be honest:
 
 ## Output structure (recap, for sanity)
 
-After a successful run on `https://alphainfusemen.com`:
+After a successful run on `https://example-store.com`:
 
 ```
-{output_folder}/alphainfusemen/
+{output_folder}/example-store/
 ├── clean/
 │   └── home/hero.html              ← the deliverable
 ├── assets/
@@ -484,7 +543,7 @@ Never write outside `{project-slug}/`. Cross-project assets sharing happens only
 When this command is first wired up, the canonical end-to-end smoke test is:
 
 ```
-/build-page https://alphainfusemen.com
+/build-page https://example-store.com
 ```
 
 Expected: a clean `home/hero.html` (or the home's first detected section), under-threshold diff, report.html opening successfully. That's the MVP milestone.

package/templates/commands/build-site.md

@@ -13,9 +13,9 @@ Receber UMA URL raiz e um target (WP ou Shopify), descobrir todas as páginas re
 
 ## The five non-negotiables
 
-1. **Mobile-first sempre.** Default viewport `390×844` em toda chamada `sb-inspect-live` e `sb-validate-render`. Override só se o usuário pedir desktop explicitamente.
+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-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 ✅.
+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.
 
@@ -31,7 +31,8 @@ Receber UMA URL raiz e um target (WP ou Shopify), descobrir todas as páginas re
 | `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-render` | **Bash** | Headless render + token probe. Pure scripted. |
+| `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. |
 
@@ -66,6 +67,7 @@ O texto após `ARGUMENTS:` contém a entrada do usuário. Extraia:
 | `--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 explícito do Step 4d (globals auto-extract). Sem essa flag, header/footer compartilhados são extraídos pra `clean/global/` quando `crawl.pageCount >= 3` (default ON). Use quando o site não tem chrome compartilhado entre páginas, ou quando estiver fazendo um run de debug que precisa ver o 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.
@@ -289,11 +291,50 @@ node .claude/skills/sb-extract-assets/scripts/extract-assets.mjs \
 
 `assetsMap.failed[]` non-empty → forwarde pro builder, **não** pare a página.
 
-### Step 4d — Detectar global sections (header/footer compartilhados)
+### Step 4d — Extract global sections (header/footer compartilhados)
 
-Heurística: depois de inspecionar e antes de buildar, registre `inspection.sections[]` (ou equivalente) por hash estrutural numa tabela em memória `globalSectionTracker = { headerHash: count, footerHash: count, ... }`. Quando uma seção (header ou footer) tiver `count >= 3` páginas com o MESMO hash, a próxima vez que for emitida será gravada em `clean/global/{header,footer}.{html|liquid}` (uma vez), e os builds posteriores referenciam ao invés de inline.
+**Default ON** quando `crawl.pageCount >= 3` AND a flag `--no-globals` NÃO foi passada. Caso contrário, skip este Step inteiro com uma linha em `decisions.md` (`Step 4d skipped: pageCount<3` OU `Step 4d skipped: --no-globals opt-out`).
 
-> **MVP escape hatch:** se `inspection` da skill atual não emite hashes de seção comparáveis, **skip silenciosamente** este passo — o asset cache já cobre a otimização principal (imagens). Documente em `decisions.md` que global-section dedupe está pendente. Não tente computar hash por conta própria com regex de HTML — fica frágil.
+Estado mantido pelo orchestrator durante o batch:
+
+```
+globalsExtracted = {
+  header: null | <output-path>,   // ex: "clean/global/header.html"
+  footer: null | <output-path>,
+}
+```
+
+**Detector estrutural** (sem hash, sem regex sobre HTML cru):
+
+- **Header** = primeiro elemento da `inspection.dom` (descida em DFS) cujo `tag === 'header'` E que tenha algum descendant cujo `tag === 'nav'`. Se ausente: **skip globals (não extrai nem strippa) + log warning** em `decisions.md`: `[build-site] WARN: Step 4d header detector missed — no <header> semântico com <nav>; globals not extracted, pages keep chrome inline`. Continue pipeline normalmente. **NÃO pergunte ao humano** — non-negotiable #5 (`single human checkpoint = page list confirmation`) proíbe queries mid-batch. Decisão de fix manual fica pra próximo run com `--no-globals` ou refresh do crawl.
+
+- **Footer** = último elemento que é **descendant direto-de-body-ou-main** (i.e., `parent.tag === 'body'` OU `parent.tag === 'main'`) cujo `tag === 'footer'` OU cujo atributo `role === 'contentinfo'`. **NÃO** o último em DFS pós-ordem — isso pegava blog-post `<footer>` ou article `<footer>` em vez do site footer (bug example-shop-class em sites de conteúdo). Se ausente: skip + warn (mesmo padrão do header acima).
+
+**Trigger window:** Step 4d roda apenas quando `globalsExtracted.header === null` (e separadamente para footer). Ou seja, só na primeira inspection que casar o detector. Inspeções subsequentes não re-processam — o asset já está em disco e é referenciado.
+
+**Extração:**
+1. Localize header e/ou footer no `inspection.dom` (em memória).
+2. Serialize cada um pro fragment HTML/Liquid passando pelo composer (`sb-build-wp` ou `sb-build-shopify`) com hint `--target-section=header|footer` (composer trata como input de seção, não página inteira). Output: `clean/global/{header,footer}.{html|liquid}`.
+3. Set `globalsExtracted.header` (e/ou `.footer`) = output path.
+
+**Stripper (mandatório quando globals extracted):** ANTES de invocar o composer pra páginas individuais (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`).
+3. Passe a inspection editada ao composer. Composer não vê header/footer e não pode fabricá-los.
+4. 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 %}`
+5. Grava em `clean/{home,pdp,...}/{slug}.html` o output já strippado-e-comentado.
+
+**Stripper validation:** após gravar o file, faça um grep rápido:
+```
+grep -nE "<header[ >]|<footer[ >]" clean/{home,pdp,...}/{slug}.{html,liquid}
+```
+Padrão sem `^` anchor pra pegar pretty-printed (indented `  <header>`). Glob `{html,liquid}` cobre ambos os targets (WP + Shopify). Se retornar match, é defeito — composer ignorou a inspection editada e re-fabricou, ou stripper passou tag misformada. Log `[build-site] WARN: stripper miss in {slug}.{ext}` em `decisions.md`. Não blocking — orchestrator continua.
+
+**Por que detector estrutural e não hash:** hash exige inspection emitir hashes comparáveis. Detector estrutural usa só tags semânticas que `sb-inspect-live` já captura na DOM tree. Funciona com qualquer inspection que tenha um DOM serializado, sem mudança upstream. Cobre o caso comum (sites WordPress/Shopify usam `<header>`/`<footer>` semântico). Para sites com chrome em `<div class="site-header">` sem semântica, o Ask First gate força decisão consciente em vez de heurística silenciosa.
 
 ### Step 4e — Build (Skill)
 
@@ -313,7 +354,7 @@ Se o validator interno do builder retornar erros que ele não conseguiu corrigir
 ### Step 4f — Validate render (Bash)
 
 ```bash
-node .claude/skills/sb-validate-render/scripts/validate-render.mjs \
+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}" \
@@ -322,10 +363,33 @@ node .claude/skills/sb-validate-render/scripts/validate-render.mjs \
   [--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-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.
+**`--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.
 
 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 4f-bis — Test interactivity (Bash, diagnostic gate)
+
+```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}"
+```
+
+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
@@ -356,6 +420,41 @@ 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 ❌):**
+
 | `review.passed` | `compare.passed` | Ação na página |
 | --- | --- | --- |
 | true | true | ✅ **Página pronta.** Atualiza `pageResults[]` com sucesso, próxima página. |
@@ -363,7 +462,7 @@ Capture `review`.
 | 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. |
 
-Pré-checks (idênticos ao `/build-page`):
+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) → idem, vira ⚠️.
 3. **Mesmo `violations[]` 2 iterações seguidas** → fixHint não pegou. Não rode 3ª. ⚠️ imediato.
@@ -383,7 +482,7 @@ Skill(
 
 ### Step 4k — Append to pageResults
 
-Após cada página, append `{url, type, slug, status, diffPercent, iterations, outputPath, screenshotsLive, screenshotsBuild, diffMap, violations}` ao `pageResults[]`. Imprima a linha de status no console (formato no início do Step 4).
+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.
 
 ---
 
@@ -393,9 +492,11 @@ Depois que TODAS as páginas confirmadas foram processadas (`pageResults[].lengt
 
 1. **Escreva `{output_folder}/{project-slug}/reports/index.html`** com:
    - Header com root URL, target, project-slug, timestamp do run, totals (`X✅ / Y⚠️ / Z❌`).
-   - Tabela com uma linha por página: status badge, type, URL → output path link, diff %, iterations, screenshot side-by-side (live + build, thumbs com link pro full), link pro diff map, violations resumo.
+   - 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.
    - 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.
@@ -406,9 +507,17 @@ Depois que TODAS as páginas confirmadas foram processadas (`pageResults[].lengt
 
 ## Step 6 — Batched auto-learn prompt
 
-Único momento opcional de interação após o checkpoint. Só dispare se houve **pelo menos um fixHint do `sb-review-checks` que destravou um build** durante o batch (i.e. existe ao menos uma página com `iterations > 0` E `status === ✅`).
+Ú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. 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).
+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:
 

package/templates/commands/clip-section.md

@@ -15,9 +15,9 @@ Receber UMA URL + UM seletor CSS + um target (WP ou Shopify) e entregar UM arqui
 
 ## The four non-negotiables (herdados do bootstrap)
 
-1. **Mobile-first sempre.** Default viewport `390×844` em toda chamada `sb-inspect-live` e `sb-validate-render`. Override só se o usuário pedir desktop explicitamente.
+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 path de build, conteúdo, ou mensagem "ready to ship" antes de `sb-validate-render` E `sb-compare-visual` confirmarem `diffPercent < threshold` (ou, após o auto-correct esgotar, escale explicitamente).
+3. **Validate before showing.** NUNCA imprima path de build, conteúdo, ou mensagem "ready to ship" antes de `sb-validate-static-render` E `sb-compare-visual` confirmarem `diffPercent < threshold` (ou, após o auto-correct esgotar, escale explicitamente).
 4. **No fabrication.** `assetsMap.failed[]` não some — surface ao builder; nunca invente URL substituta. `inspection.widgetBlocked: true` → pare e escale; não componha de página bloqueada. **Selector que não casa nada** → pare e escale; não fall-back pra full-page silenciosamente (isso é fabricação de escopo).
 
 ---
@@ -31,7 +31,8 @@ Receber UMA URL + UM seletor CSS + um target (WP ou Shopify) e entregar UM arqui
 | `sb-inspect-live` | **Bash** → `node .claude/skills/sb-inspect-live/scripts/inspect-live.mjs ...` | 95%+ deterministic. Aceita `--selector <css>` nativamente — escopo limitado ao elemento + descendentes. |
 | `sb-extract-assets` | **Bash** → `node .claude/skills/sb-extract-assets/scripts/extract-assets.mjs ...` | Pure download + sanitize + dedupe. **`inspection.imgUrls` já vem filtrado pelo selector** — extract roda nessa lista enxuta. |
 | `sb-build-wp` / `sb-build-shopify` | **Skill** tool → `Skill(skill="sb-build-wp", args="...")` | A composição é criativa. O skill SKILL.md + `references/wp-build-rules.md` é o manual do LLM. Bash não compõe. |
-| `sb-validate-render` | **Bash** → `node .claude/skills/sb-validate-render/scripts/validate-render.mjs ...` | Headless render + token probe. Fully scripted. |
+| `sb-validate-static-render` | **Bash** → `node .claude/skills/sb-validate-static-render/scripts/validate-static-render.mjs ...` | Headless render + token probe. Fully scripted. |
+| `sb-test-interactivity` | **Bash** → `node .claude/skills/sb-test-interactivity/scripts/test-interactivity.mjs ...` | Headless behavioral probe (aria-controls / details / dialog). Diagnostic gate — `passed:false` vira warning, não bloqueia. |
 | `sb-compare-visual` | **Bash** → `node .claude/skills/sb-compare-visual/scripts/compare-visual.mjs ...` | pixelmatch + token diff. Pure determinismo. |
 | `sb-review-checks` | **Bash** → `node .claude/skills/sb-review-checks/scripts/review-checks.mjs ...` | cheerio + regex. Pure determinismo. `candidateFix` strings são contrato — forward verbatim. |
 
@@ -241,7 +242,7 @@ Skill(
 
 Se tiver `{designKnowledgeSubset}`/`{patternsSubset}` curados, inclua como args extras (`design-knowledge-inline=<base64-or-path>`); senão omita e deixe o skill usar bundled defaults.
 
-**O skill retorna:** path absoluto do arquivo escrito, validator report (errors/warnings), e nota de uma linha sobre o pattern escolhido. Não peça o conteúdo do arquivo de volta — o `sb-validate-render` abre.
+**O skill retorna:** path absoluto do arquivo escrito, validator report (errors/warnings), e nota de uma linha sobre o pattern escolhido. Não peça o conteúdo do arquivo de volta — o `sb-validate-static-render` abre.
 
 Se o validator interno do skill retornar erros que ele não conseguiu corrigir → surface ao usuário; isso é defeito do builder, não caso de auto-correct.
 
@@ -250,7 +251,7 @@ Se o validator interno do skill retornar erros que ele não conseguiu corrigir
 ## Step 4 — Validate render (Bash)
 
 ```bash
-node .claude/skills/sb-validate-render/scripts/validate-render.mjs \
+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/{section-slug}-{iteration}" \
@@ -272,6 +273,31 @@ Capture stdout JSON → `render`. Hold `{render-screenshot}` (`render.screenshot
 
 ---
 
+## Step 4-bis — Test interactivity (Bash, diagnostic gate)
+
+```bash
+node .claude/skills/sb-test-interactivity/scripts/test-interactivity.mjs \
+  --file "{output-path}" \
+  --preset "{preset}" \
+  --output-dir "{output_folder}/{project-slug}/reports/validations/{section-slug}-{iteration}"
+```
+
+Capture `interactivity-report.json` (mesmo dir do `validate-static-render`).
+
+**Modo diagnóstico (não-blocker):**
+
+- Exit `!= 0` → log stderr verbatim e continue pra Step 5 sem warning. Hint comum: `playwright`/chromium faltando — sugira `npx playwright install chromium`. Não escala.
+- Exit `0` AND `passed === true` → silently proceed. Sem warning, sem mudança de status.
+- Exit `0` AND `passed === false`:
+  - **Append** ao `interactivityWarnings` array (NÃO single-shot overwrite): `interactivityWarnings.push({ iteration: <n>, tests: report.tests.filter(t => !t.passed) })`. Iterations com 0 warnings NÃO appende. Histórico cross-iter preservado — útil pro success/escalation path (Steps 8/10) que renderiza section em `report.html` resumindo qual iter viu qual break.
+  - Status badge da section build ganha sufixo `+!interactive` (e.g. `✅+!interactive`). Calculado dinamicamente: applies se `interactivityWarnings.length > 0` em qualquer iter.
+  - **Status final permanece o que a decision matrix decidir** (Step 7). Sem promoção pra ❌. Skill é diagnóstica, não gatekeeper — política locked em G2 spec change log.
+  - Continue pra Step 5.
+
+**Por que diagnostic e não blocker:** `sb-test-interactivity` é skill nova (G2). False-positives em early adoption 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` no report dá visibilidade sem bloquear. Mudança pra blocker é decisão de spec própria (G8+).
+
+---
+
 ## Step 5 — Compare visual (Bash)
 
 ```bash
@@ -295,7 +321,7 @@ node .claude/skills/sb-compare-visual/scripts/compare-visual.mjs \
 
   Pattern #27 ainda aplica do lado do build — se a section em mobile fica em 390×507 dentro de viewport 390×844, sem o crop sobra 337px de espaço branco que infla diff% gratuitamente.
 
-DPR flags default `3` (matches `sb-inspect-live` iPhone 14 + `sb-validate-render` `deviceScaleFactor=3`, Pattern #22). Não override.
+DPR flags default `3` (matches `sb-inspect-live` iPhone 14 + `sb-validate-static-render` `deviceScaleFactor=3`, Pattern #22). Não override.
 
 Capture stdout JSON → `compare`. Note path do `report.json` persistido → `{compare-report-path}`.
 
@@ -333,6 +359,39 @@ Capture stdout JSON → `review`. Note `review.passed` e o array `violations[]`
 
 ## Step 7 — Decision matrix (Pattern #28)
 
+**Pre-check 0 (coverage gate, runs FIRST):**
+
+Para `/clip-section`, "live" é o elemento alvo do selector. Calcule contra schema **real** do `sb-inspect-live`:
+
+```
+buildHeight    = render.geometry.totalHeight        # primary: from sb-validate-static-render
+liveMainHeight = inspection.sectionBoundingBox.h    # primary: bbox do selector target (set when --selector é passed)
+                 || inspection.dom[0].bbox.h         # fallback 1: root walked node bbox (warn — clip pode ser menor que a página)
+                 || (walk inspection.dom recursively, collect classified-sections bboxes,
+                     return max(s.bbox.y + s.bbox.h) - min(s.bbox.y))
+                                                    # fallback 2: classified sections span (warn)
+coverageRatio  = buildHeight / liveMainHeight
+```
+
+`inspection.sectionBoundingBox` é o bbox do selector alvo (schema em `inspect-live.mjs:163,1219`). Quando `--selector` é passed, este field é populated. Sem selector, fica `null` e cai pros fallbacks.
+
+If `buildHeight` is missing → HALT com erro `[clip-section] FATAL: render.geometry.totalHeight missing`.
+If `liveMainHeight` fell back → log warning ao user em `report.html` notes.
+If `liveMainHeight < 100` → log warn `[clip-section] WARN: liveMainHeight < 100, coverage gate skipped`; skip; persist `coverage.skippedReason = 'degenerate-height'`.
+If `inspection.dom[]` empty AND no classified sections → log warn `[clip-section] WARN: coverage gate skipped — empty inspection.dom`; skip; `coverage = null`.
+
+**Tier triage:**
+
+| Range | Status | Ação |
+| --- | --- | --- |
+| `< 0.40` | ❌ **incomplete** | Status: `"incomplete — built {ratio*100:.0f}% of source clip"`. Vai pra Step 9 (auto-correct loop) se budget permite; existing review-derived fixHints feed back to composer. **NO new EXTENSION marker** — Step 9 já consome `review.violations[]` canonical. Coverage `< 0.40` apenas força ❌ no matrix override. |
+| `0.40 — 0.85` | ⚠️ **partial** | Status: `"partial — built {ratio*100:.0f}%"`. Prossegue pra matriz abaixo (não bypassa). Coverage warning sobrevive como overlay. |
+| `>= 0.85` | (proceed) | Coverage OK. Matriz roda silenciosamente. |
+
+Persist `coverage = { buildHeight, liveMainHeight, ratio, source: 'sectionBoundingBox'|'rootBbox'|'sectionsSpan', missingSections?: [...], skippedReason?: <string> }` em report. `missingSections` (quando `ratio < 0.85`): walk `inspection.dom` recursivamente, collect classified-section children do selector cujo `bbox.y >= buildHeight`.
+
+**Existing matrix (roda só se coverage gate não routou pra ❌):**
+
 Você tem `compare.passed` E `review.passed` agora. Aplique:
 
 | `review.passed` | `compare.passed` | Ação                                                                                          |
@@ -513,7 +572,7 @@ Nunca escreva fora de `{project-slug}/`. Cross-project asset sharing acontece s
 Quando este command for primeiro wired-up, smoke test canônico:
 
 ```
-/clip-section https://alphainfusemen.com .ai-hero --target shopify
+/clip-section https://example-store.com .ai-hero --target shopify
 ```
 
-Esperado: arquivo `{output_folder}/alphainfusemen/clean/sections/ai-hero.liquid` em até ~30s, diff sob threshold, decision matrix funcionando, report.html abrindo. Sem crawl, sem checkpoint humano. MVP milestone do `/clip-section`.
+Esperado: arquivo `{output_folder}/example-store/clean/sections/ai-hero.liquid` em até ~30s, diff sob threshold, decision matrix funcionando, report.html abrindo. Sem crawl, sem checkpoint humano. MVP milestone do `/clip-section`.