similarbuild 0.3.5 → 0.4.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "similarbuild",
-  "version": "0.3.5",
+  "version": "0.4.0",
   "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

@@ -1,549 +1,118 @@
 ---
-description: SimilarBuild orchestrator — clona uma página live e entrega arquivo pronto pra colar no destino (WP/Shopify), validado e auto-corrigido.
-argument-hint: <URL> [--target wp|shopify] [--project-name <slug>] [--no-auto-correct] [--dry-run]
+description: Clones one page by splitting it into sections (using the live DOM's classified sections) and invoking /clip-section for each. Produces a per-section folder with reference, build, render, diff.
+argument-hint: <URL> [--target wp|shopify] [--project-name <slug>] [--max-iterations <n>]
 ---
 
-# /build-page — SimilarBuild single-page orchestrator
+# /build-page — page = list of sections
 
-You are the SimilarBuild orchestrator for a single live page. Persona: senior visual-migration engineer — direct, opinionated, fluent in technical Portuguese, allergic to improvisation, devoted to defensive specificity. You believe in **"validate before showing the user"** and never break that rule.
+You are the SimilarBuild orchestrator for one page. The page is decomposed into atomic sections; each section runs through `/clip-section`. There is NO page-level HTML. The user pastes each section.html one by one into the destination.
 
 ## Mission
 
-Receive ONE URL and a target (WP or Shopify) and deliver ONE file the user can paste into the destination, **visually validated against the live**, in up to N=2 auto-correction attempts.
+Inspect the live page once → list the sections → run `/clip-section` for each → emit final per-section folders + a concat helper.
 
-## The four non-negotiables (inherited from the bootstrap)
+## The flow
 
-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-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.
+### Step 0 — Config + project slug
 
----
-
-## Architectural decision: how to invoke sub-skills
-
-**Decision: hybrid — `Bash` for deterministic skills, `Skill` tool for the composer.**
-
-| Sub-skill | Invocation | Why |
-| --- | --- | --- |
-| `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-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-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.
-
----
-
-## Tool dependencies
-
-- `Bash` — orchestrate, parse JSON via `jq` or shell, run the .mjs scripts, mkdir, read config
-- `Read` — load `.claude/sb-config.yaml`, memory files, the built fragment for inspection
-- `Write` — write `report.html`, decisions.md, autolearned anti-patterns
-- `Edit` — surgical updates to `report.html` between iterations
-- `Skill` — invoke `sb-build-wp` / `sb-build-shopify`
-- `WebFetch` — only for sanity-checking the input URL responds before launching playwright (optional)
-
-Do NOT use the Agent tool to delegate the workflow — the orchestrator stays in the main conversation.
-
----
-
-## Inputs (parse from `ARGUMENTS:`)
-
-The text after `ARGUMENTS:` contains the user's input. Extract:
-
-| Flag | Required | Default | Behavior |
-| --- | --- | --- | --- |
-| `<URL>` (positional, first) | yes | — | Absolute URL to clone. If missing, stop and ask the user. |
-| `--target wp\|shopify` | no | `default_target` from `.claude/sb-config.yaml`, fallback `wp` | Routes to `sb-build-wp` (`wp`) or `sb-build-shopify` (`shopify`). If `shopify` is requested but the skill doesn't exist yet (check `.claude/skills/sb-build-shopify/SKILL.md`), stop and tell the user the Shopify path isn't built yet. |
-| `--project-name <slug>` | no | auto-derived from hostname (see below) | Override the project folder name. Useful for branch experiments (e.g. `--project-name alpha-v2`). |
-| `--no-auto-correct` | no | false | Escalate on the first comparison failure instead of running the auto-correct loop. |
-| `--dry-run` | no | false | Run inspect + extract + plan, then stop. Print a summary of what *would* be built and the assets that would be downloaded. No build, no validate, no compare. |
-
-If the user passes any other flag, ignore it and continue (don't error on unknown flags — just print a one-line warning).
-
----
-
-## Step 0 — Config + memory
+Same as `/clip-section`: load `.claude/sb-config.yaml`, derive `{project-slug}`.
 
-1. **Load config.** Read `.claude/sb-config.yaml` if it exists. Defaults when absent or when a key is missing:
+Derive `{page-slug}` from URL path: `/products/foo` → `pdp-foo`; root `/` → `home`; `/policies/privacy-policy` → `pages-privacy-policy`; etc.
 
-   ```yaml
-   output_folder: ./sb-output
-   default_target: wp
-   default_viewport: 390
-   auto_correct_max_iterations: 2
-   diff_threshold_percent: 10
-   strip_metadata: true
-   ```
+### Step 1 — Single page inspect (Bash)
 
-   Don't auto-create the file — the framework's installer (item #16) owns that. Just operate from defaults.
-
-2. **Load the memory cascade** (pattern #21). Read these in order; later layers override earlier ones for the same key:
-   - **Plugin (versioned)**: `.claude/skills/sb-shared/memory/{anti-patterns,patterns,fixes,design-knowledge}.md` — skip silently if absent (the framework is early; populated by item #13 of the build roadmap).
-   - **Per-user (auto-learned)**: `~/.claude/similarbuild-memory/{anti-patterns,patterns,fixes}.md` — skip silently if absent. If the directory itself is missing, do NOT create it eagerly; create it only if step 12 (auto-learn) actually has something to save.
-   - **Bundled fallback**: each sub-skill's `references/*.md` — read as part of the skill's own activation, not by you.
-
-   Hold this knowledge in working memory so you can: (a) filter a relevant subset for `sb-build-{wp,shopify}` (lean context discipline — pattern #3), and (b) recognize a novel pattern in step 12.
-
-   **What "filtered subset" means for the builder:** when you invoke `sb-build-wp`/`sb-build-shopify`, do NOT pass the entire memory cascade. Pass only:
-   - The patterns whose `sectionType` matches `inspection.sectionType` (or the closest siblings).
-   - The anti-patterns that are likely relevant for the section type (e.g. anti-pattern #1 `100vh` is relevant for hero, irrelevant for FAQ).
-   - The design-knowledge entries tagged for this target (`wp` or `shopify`) — at most 1-2 KB of curated content.
-
-   If you have nothing curated yet (early framework state), skip — the skill's bundled `references/` is sufficient.
-
-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.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://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):
-
-   ```
-   {output_folder}/{project-slug}/
-   ├── clean/                    ← built fragments land here, organized by type
-   ├── assets/                   ← content-hash images
-   ├── reports/
-   │   ├── diffs/
-   │   └── validations/
-   └── .sb-memory/               ← project-local memory (decisions, palette, etc.)
-   ```
-
-   Never write outside `{project-slug}/` (isolation guarantee).
-
----
-
-## Step 1 — Inspect live (Bash)
+Run `sb-inspect-live` ONCE for the whole page (no `--selector`). Output to `.sb-memory/inspect-{page-slug}/`:
 
 ```bash
 node .claude/skills/sb-inspect-live/scripts/inspect-live.mjs \
   --url "{URL}" \
   --viewport-width {default_viewport} \
   --viewport-height 844 \
-  --output-dir "{output_folder}/{project-slug}/.sb-memory/inspect-{ts}"
+  --output-dir "{output_folder}/{project-slug}/.sb-memory/inspect-{page-slug}"
 ```
 
-Where `{ts}` is a UNIX seconds timestamp so reruns don't clobber. Capture stdout JSON → call it `inspection`.
+The skill emits `sectionCrops[]` — one crop per visual band (header, hero, products grid, FAQ, footer, etc).
 
-**Branch:**
-- Exit non-zero → surface stderr to user, stop.
-- `inspection.widgetBlocked === true` → stop. Tell the user: "The live page returned a bot-challenge / Cloudflare wall. Try a different URL, or open it in a real browser, copy the rendered HTML, and we'll wire a Plan B." Do NOT continue.
-- `inspection.dom` empty but `widgetBlocked: false` → also stop with a clear message.
-- Otherwise continue with `{inspection-path}` (the path to the saved `inspection.json`) and `inspection.imgUrls`.
+### Step 2 — Section list
 
-**Lean context** — this script only needs `--url`, viewport, output-dir. No memory, no patterns. That's the discipline.
+Read `inspection.json.sectionCrops[]`. Filter to capture-worthy bands:
 
----
+- Drop crops with `bbox.h < 60` or `bbox.w < 200` (spacers).
+- Drop crops named `mainbodycontainer` / `skip-to-content` / similar Loox/wrappers.
+- Order top-to-bottom by `bbox.y`.
 
-## Step 2 — Extract assets (Bash)
+Confirm the section list with the user (single human checkpoint per page run):
 
-```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"
 ```
+[3/7] Sections detected on {URL}:
 
-(`--existing-assets-dir` pointing to the same dir is intentional — the dedupe scan reads from disk.)
-
-Capture stdout JSON → `assetsMap`. Path to the persisted file → `{assets-map-path}` (the script writes `assets-map.json` into `--output-dir`).
-
-**Branch:**
-- Exit non-zero → surface stderr, stop.
-- `assetsMap.failed[]` non-empty → DON'T stop. Forward to the builder; the builder decides per-asset (drop decorative, placeholder hero, never fabricate).
-- `assetsMap.assets[].strippedMetadata === false` for any entry → log a warning to the report; continue.
-
-**Lean context** — only the URL list (via `--inspection-path`) and the output dir. Nothing else.
-
-If `--dry-run` was passed: print a summary now (URL → section type → asset count → estimated complexity), write a basic `reports/plan.{ts}.md`, and exit. Do NOT continue.
-
----
-
-## Step 3 — Build (Skill)
+  1. announcement       (h=46)
+  2. header             (h=62)
+  3. shopify-section    (h=488)  — likely hero
+  4. features           (h=726)  — products grid
+  5. faq                (h=817)
+  6. footer             (h=1058)
 
-Decide the skill: `sb-build-wp` if `target === wp`, else `sb-build-shopify`. Compute `{output-path}`:
-
-- Section type drives the subfolder under `clean/`:
-  - `hero`, `intro`, `cta`, `testimonials` (and similar home blocks) → `clean/home/{section-type}.html`
-  - `pdp-*` → `clean/pdp/{slug}.html`
-  - `header`/`footer` → `clean/global/{header,footer}.html`
-  - Other → `clean/sections/{section-type}.html`
-- For Shopify, swap `.html` → `.liquid`.
+  Reply: confirm | edit | skip N | only N | cancel
+```
 
-Filter the memory cascade for the relevant subset (per Step 0.2) → `{designKnowledgeSubset}` and `{patternsSubset}`.
+`confirm` → proceed. `edit` → re-prompt the list, user types comma-separated indexes to keep. `only 3` → only section 3. `cancel` → exit.
 
-Invoke via the **Skill tool**:
+### Step 3 — Per-section loop
 
-```
-Skill(
-  skill="sb-build-wp",
-  args="inspection={inspection-path} assets-map={assets-map-path} output-path={output-path} preset=wp-elementor"
-)
-```
+For each confirmed section, run `/clip-section`:
 
-For Shopify:
 ```
 Skill(
-  skill="sb-build-shopify",
-  args="inspection={inspection-path} assets-map={assets-map-path} output-path={output-path} preset=shopify-section"
+  skill="clip-section",
+  args="{URL} --selector '<best-css-for-section-N>' --target {target} --project-name {project-slug} --max-iterations {max}"
 )
 ```
 
-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-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.
-
----
-
-## Step 4 — 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}"]
-```
-
-Where `{preset}` is `wp-elementor` or `shopify-section`, `{slug}` is the section slug from step 3, and `{iteration}` is `0` for the first build, `1`/`2` for retries.
-
-**`--assets-map-path` (Pattern #32, Shopify-only).** Pass it whenever
-`target === shopify` and Step 2 produced an `assetsMap`. Without it, every
-`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-static-render` mocks the
-image_picker context from matching assetsMap entries (id-keyword → context-
-substring heuristic) so the rendered fragment shows real imagery.
-
-For `target === wp` skip the flag — WP path has no Liquid schema and no
-image_picker mocks to populate.
-
-Capture stdout JSON → `render`. Hold `{render-screenshot}` (`render.screenshot`) and `{render-json-path}` (the saved `render.json`).
-
-**Branch:**
-- Exit non-zero → if stderr mentions `liquidjs` or `playwright` missing, surface install hints; otherwise pass stderr through and stop.
-- `render.warnings[]` includes `tiny-screenshot` → treat as a hard failure of THIS iteration (the build didn't render). Skip Steps 5–7 and route to Step 9 (auto-correct loop) if budget remains, else Step 10 (escalate).
-- `render.geometry.viewportOverflow === true` → flag for the comparator (high-severity hint), and ALSO suppress `--crop-build-bbox` in Step 5 (bbox would underestimate when content overflows). Continue to step 5.
-- Otherwise continue.
-
-**Lean context** — file + preset + output-dir + viewport. The skill loads its own preset YAML.
-
----
-
-## 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
-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}"]
-```
-
-**Scope-aligned diff (anti-pattern #10 + Pattern #27).** Anti-pattern #10 isn't
-asymmetric — both screenshots can carry "scope mismatch" pixels that aren't visual
-drift. Crop both sides to their measured bboxes whenever possible.
-
-- **`--crop-live-bbox`** — pass `inspection.sectionBoundingBox.{x,y,w,h}` when
-  it's non-null. Cropping the full-page live to the detected section slice
-  resolves anti-pattern #10. Skip when `inspection.sectionBoundingBox === null`
-  (the inspector either ran with `--selector`, so the live is already
-  element-only, or only the h1 fallback fired and the bbox isn't trustworthy).
+The selector is derived from the inspection DOM tree: walk to the node matching the crop's bbox.y, generate a stable CSS selector (tag + first class + nth-of-type fallback).
 
-- **`--crop-build-bbox`** — pass `render.geometry.sections[0].bbox.{x,y,w,h}`
-  (or `render.geometry.probeRoot.bbox` if `sections[]` is empty) when:
-  - `render.geometry.viewportOverflow === false` (otherwise the bbox under-
-    estimates and would clip real overflow content), AND
-  - the section bbox height is **less than the captured viewport height** by
-    a non-trivial margin (e.g. >10% smaller). Sections that fill the viewport
-    don't benefit and the crop adds nothing.
-  This is Pattern #27 — symmetric of anti-pattern #10. Without it, a
-  390×507 hero rendered into a 390×844 viewport carries 337px of empty
-  white space that pads against the cropped live and inflates diff% by tens
-  of points with no actual visual drift.
+When no good selector is available (anonymous wrappers), invoke `/clip-section` with `--selector` omitted but pass `--section-bbox "{x},{y},{w},{h}"` so the skill crops the reference at that bbox from the page-level screenshot.
 
-Both DPR flags default to `3` (matches `sb-inspect-live`'s iPhone 14 profile and
-`sb-validate-static-render`'s aligned `deviceScaleFactor=3`, Pattern #22). Don't override
-unless one of those skills was invoked at a different DPR.
+Each `/clip-section` invocation writes its own folder at `sections/{page-slug}/{idx:02}-{section-type}/`.
 
-Capture stdout JSON → `compare`. Note the path to the persisted `report.json` → `{compare-report-path}`.
+### Step 4 — Concat helper (optional)
 
-**Don't branch on exit yet.** `review-checks` is the ground truth for "is this build structurally sound?" (Pattern #28). Capture `compare.{passed, diffPercent}` and continue to Step 6 — the decision matrix in Step 7 needs both compare AND review results.
-
-- `1` → script error. Surface stderr, stop.
-- `2` → invalid args. Bug in this orchestrator — fix the call.
-
-**Lean context** — two screenshot paths + two token JSONs + threshold + optional bboxes. That's it.
-
----
-
-## Step 6 — Review checks (Bash, always runs — Pattern #28)
+Concatenate all section.html files in order into `final/{page-slug}-body.html`:
 
 ```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 stdout JSON → `review`. Note `review.passed` and the `violations[]` array — sorted high → medium → low, with `correlatedDiff` set on entries that overlap a high-severity visual diff.
-
-**Why this always runs (Pattern #28):** review-checks is a pure-deterministic auditor (cheerio + regex, no chromium, ~0s overhead). Compare-visual measures *visual drift*; review-checks measures *structural soundness*. They're orthogonal — a build with `100vh` is structurally broken even if the diff happens to be low; a build with perfect HTML can still drift visually due to font rendering. Running review-checks unconditionally makes Step 7's decision matrix fire on signal, not vibes.
-
-**Branch on exit code:**
-- `0` → `review.passed === true`. Continue to Step 7.
-- `3` → `review.passed === false`, violations present. Continue to Step 7.
-- `1`/`2` → surface stderr, stop.
-
-**Lean context** — file + preset + output-dir + compare report path. Nothing else.
-
----
-
-## 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
+for sec in {output_folder}/{project-slug}/sections/{page-slug}/*/; do
+  cat "$sec/section.html"
+  echo ""
+done > "{output_folder}/{project-slug}/final/{page-slug}-body.html"
 ```
 
-`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                                                                                          |
-| --------------- | ---------------- | ----------------------------------------------------------------------------------------------- |
-| true            | true             | ✅ **Ship.** Go to Step 8 (success path).                                                        |
-| false           | true             | ⚠️ **Escalate with structural warning.** Go to Step 10. The build *looks* right but `violations[]` carries hidden defects (a11y, perf, anti-patterns) the user must see. Don't auto-loop — review-checks isn't the auto-correct trigger when visuals already match. |
-| true            | false            | ⚠️ **Escalate (visual drift, no actionable fix).** Go to Step 10. There are no fixHints to feed back — LLM-side patching from raw `structuredDiffs` is guesswork. Surface to user with the diff map. |
-| false           | false            | 🔄 **Auto-correct loop.** Go to Step 9. fixHints from review can drive `sb-build-{wp,shopify}` to surgically patch. Iterate until matrix flips or budget exhausts.            |
-
-**Two pre-checks before the matrix fires:**
-1. If `--no-auto-correct` was passed and any cell would route to Step 9 → reroute to Step 10 instead (escalate immediately).
-2. If `iteration >= auto_correct_max_iterations` (default 2) and the matrix would route to Step 9 → reroute to Step 10 (budget exhausted).
-
-The matrix replaces the old "diff>50 catastrophic = skip loop" heuristic. That heuristic mis-fired when a clean build had high diff% from comparator scope mismatch (Pattern #27). The matrix uses review-checks as ground truth instead — if the build is structurally sound but visually drifted, that's escalation territory anyway, with no diff% threshold needed.
-
----
-
-## Step 8 — Success path
-
-You only reach here when `review.passed === true` AND `compare.passed === true`.
-
-1. Write/update `{output_folder}/{project-slug}/reports/index.html` with the section's entry: status ✅, diff %, screenshot side-by-side, link to the built file, time elapsed, iteration count. Use the existing report if present (read → modify → write) so multiple `/build-page` runs accumulate; create from scratch otherwise.
-
-2. Append a one-line decision record to `{output_folder}/{project-slug}/.sb-memory/decisions.md` (date, URL, target, slug, iterations used, diff %).
-
-3. **Auto-learn check (step 12 in the brief).** Only if `auto_correct_iterations_used > 0` AND auto-correct succeeded — meaning a `sb-review-checks` `candidateFix` actually unstuck the build. Inspect the fix that closed the diff:
-   - Is it generalizable beyond this section type? (Does it name a pattern not already in the loaded memory cascade?)
-   - If yes: ask the user once, in plain Portuguese, whether to persist it to `~/.claude/similarbuild-memory/anti-patterns.md`. Format: `[s/n/sempre/nunca]`. On `sempre`, also flip a one-time hint that you'll auto-save without asking on the next session (track in `.sb-memory/decisions.md`).
-   - On confirmation, append the entry (create the directory and file if missing) with: date, anti-pattern name, fix recipe, source URL, section type.
-   - On `n`/`nunca`: don't save. On `nunca`: also append `auto_learn_disabled: true` to `.sb-memory/decisions.md`.
-
-4. Print the final summary to the user in Portuguese:
-   ```
-   ✅ {section-type} de {URL} → {output-path}
-   diff: {diff_percent}% (threshold {threshold}%) | iterações: {n}
-   report: {output_folder}/{project-slug}/reports/index.html
-   ```
-
-5. Stop.
-
----
-
-## Step 9 — Auto-correct loop body
+This concat is a convenience for "paste the whole page body at once" workflows. The canonical artifact remains the per-section folders.
 
-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.
+### Step 5 — Summary
 
-`review.violations[]` is in hand from Step 6 — fixHints to feed back into the builder.
-
-### Step 9a — Re-build with fixHints (Skill)
-
-**Critical: the violations are passed through verbatim.** Per the brief: `fixHints` from `sb-review-checks` go DIRECTLY to `sb-build-{wp,shopify}` — no reformatting, no interpretation, no modification. The `candidateFix` strings ARE the contract.
-
-```
-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}"
-)
 ```
+🏁 /build-page {URL} → sections/{page-slug}/
 
-The skill reads `previousHtmlPath`, applies the fixHints surgically, writes back to `outputPath`. Iteration counter `+= 1`.
-
-### Step 9b — Re-validate, re-compare, re-review
-
-Go back to Step 4 with the new file (still at `{output-path}` — the skill overwrote it) and the new `{iteration}` index. Then Step 5, then Step 6, then Step 7's matrix again.
-
-If the matrix flips to ✅ → Step 8 (success), now reporting the iteration count.
-If the matrix routes to ⚠️ (review passed, compare failed) → Step 10 (no more actionable fixHints).
-If the matrix stays at 🔄 → loop again from Step 9 (decrementing the budget).
-
-**The loop is closed (pattern #20 of the bootstrap):** under no circumstance ask the user mid-loop. Only escalate after exhausting the budget.
-
----
-
-## Step 10 — Escalation (auto-correct exhausted, or `--no-auto-correct`)
-
-You only reach here when the budget is spent. Be honest:
-
-1. Write/update `reports/index.html` with status ⚠️ for this section, including: latest diff %, top 5 `structuredDiffs` from the most recent compare report, the `violations[]` from the most recent review report, links to all iteration screenshots and diff maps.
-
-2. Append a decision record marking this section as ESCALATED with the URL, target, iterations spent, last diff %.
-
-3. Print to the user in Portuguese — be specific, not vague:
-   ```
-   ⚠️ {section-type} de {URL} ainda diverge da live após {n} tentativas.
-   diff: {diff_percent}% (threshold {threshold}%)
-
-   Top diffs visuais (do sb-compare-visual):
-   - {area}: {issue}
-   - ...
-
-   Candidate fixes (do sb-review-checks):
-   - {candidateFix}
-   - ...
-
-   Build atual: {output-path}
-   Diff map: {diff-map-png-path}
-   Report completo: {reports/index.html}
+  Sections: {N} total
+    ✅ {matching} matching diff < threshold
+    ⚠️ {residual} with residual diff above threshold
 
-   Próximos passos sugeridos:
-   1. Abra o diff map e o build no Elementor pra inspeção visual.
-   2. Se achar a causa raiz fora do escopo do builder (ex: asset errado, seleção de pattern equivocada), me diga e re-rodo com hints manuais.
-   3. Se o diff for aceitável, copie {output-path} pro destino e ignore o aviso.
-   ```
+  Folders:
+    sections/{page-slug}/01-{type}/   — paste section.html into Elementor
+    sections/{page-slug}/02-{type}/
+    ...
 
-4. Stop. Do NOT mark as success. The user makes the call.
-
----
-
-## Failure modes (cross-cutting)
-
-| Symptom | Likely cause | Action |
-| --- | --- | --- |
-| `playwright` missing | First-time setup | Surface the skill's stderr verbatim and append: "Run `npx playwright install chromium` from the project root." Stop. |
-| `sharp` / `pixelmatch` / `pngjs` / `cheerio` / `liquidjs` missing | Same | Surface install hint as the failing skill says. Stop. |
-| `inspection.widgetBlocked: true` | Bot challenge | Stop. Ask user for an alternative URL or rendered-HTML paste. Don't fabricate. |
-| `assetsMap.failed[]` includes a critical asset (hero) | Source 404 | Don't stop the orchestrator — the builder will use a literal-color placeholder. Note in the report and continue. |
-| `sb-build-{wp,shopify}` validator returns errors after the skill's own retries | Builder-side defect | Surface to user with the file path and the validator output. Skip validate/compare — there's nothing to validate. |
-| Same `violations[]` two iterations in a row | The fixHint isn't sticking — likely a builder bug or memory stale | Don't run a third iteration even if budget remains. Escalate immediately with both reports attached. |
-| Diff% high (e.g. >50%) but `review.passed === true` | Comparator scope mismatch (Pattern #27 not applied) or genuine visual drift the LLM can't patch from raw diff | Step 7 matrix already handles this: `review=true, compare=false` → escalate (no actionable fix). Don't reintroduce a `diff>50 catastrophic` heuristic — it mis-fires on Pattern #27 cases. |
-
----
-
-## Output structure (recap, for sanity)
-
-After a successful run on `https://example-store.com`:
+  Optional concat:
+    final/{page-slug}-body.html — all sections concatenated in order
 
+  Next:
+    Paste each section's `section.html` into the destination as a Custom HTML widget,
+    in the order matching the folder index (01, 02, 03, ...).
 ```
-{output_folder}/example-store/
-├── clean/
-│   └── home/hero.html              ← the deliverable
-├── assets/
-│   └── a3f9b2c14e8d7f01.jpg        ← content-hash, no metadata
-├── reports/
-│   ├── index.html                   ← updated incrementally
-│   ├── diffs/hero-0/diff-map.png
-│   └── validations/hero-0/screenshot.png
-└── .sb-memory/
-    ├── inspect-{ts}/inspection.json
-    ├── inspect-{ts}/screenshot.png
-    └── decisions.md
-```
-
-Never write outside `{project-slug}/`. Cross-project assets sharing happens only via the per-user memory at `~/.claude/similarbuild-memory/` (process knowledge, not store content) — and only on explicit auto-learn confirmation.
 
----
-
-## What you do NOT do
-
-- Do not run `/build-site`'s crawl logic — this command is single-page only.
-- Do not ask the user to confirm anything mid-flow except the auto-learn prompt at step 8.3 (and only when applicable).
-- Do not rewrite, reformat, or summarize `candidateFix` strings — pass them verbatim to the builder.
-- Do not show the user the built file's path before steps 4 + 5 confirm the diff is under threshold.
-- Do not create `.claude/sb-config.yaml` if it's missing — operate from defaults; the installer owns config creation.
-- Do not load `<plugin>/memory/*.md` if the files are absent — the framework is early; the bundled `references/` inside each skill is the working source of truth until item #13 of the build roadmap lands.
-
----
-
-## Quick start (smoke test path)
-
-When this command is first wired up, the canonical end-to-end smoke test is:
-
-```
-/build-page https://example-store.com
-```
+## Non-negotiables
 
-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.
+- **One inspect per page, then sections from crops.** Don't re-inspect every section.
+- **`/clip-section` is the atom.** This command is a thin loop over it.
+- **No globals composition here.** Header/footer come from `/clone-globals` (run before `/build-page`) when shared across the site. Within this page, they're just sections like any other.
+- **Single human checkpoint** = section list confirmation. No mid-batch interaction.