@xgent-ai/skills 0.1.0 → 0.3.0

package/vendor/impeccable/bundle/blobs/dcf7340da023e64144af5768b8bf44ecf45b1bfdec12d3b1c9e6618f17f8c60a

@@ -0,0 +1,131 @@
+# Init flow
+
+`init` captures durable product truth in PRODUCT.md. It does not invent a visual world and does not write DESIGN.md; [new-work.md](new-work.md) creates or expands one, and [document.md](document.md) records an incumbent one. Existing runnable web projects may also receive `.impeccable/live/config.json`.
+
+## Step 1: Load current state
+
+Use the PRODUCT.md path resolved by `impeccable context`. Update it instead of creating a competing authority. In a child app inheriting root context, confirm shared versus app-specific scope before writing.
+
+- **No PRODUCT.md:** explore, interview, and write it.
+- **PRODUCT.md exists:** ask what product knowledge is stale or missing; do not reopen confirmed fields without a reason.
+- **Legacy PRODUCT.md:** add only durable missing facts; absent `## Platform` means `web` unless evidence says otherwise.
+- **Only DESIGN.md exists:** leave it untouched and create PRODUCT.md.
+- **Redesign/rebrand request:** preserve confirmed product truth unless the user changes it. Visual replacement happens later in new-work, not here.
+
+Never silently overwrite an existing file or offer DESIGN.md during init. If another request invoked init, finish PRODUCT.md and resume it. New visual work continues in new-work; `shape` resumes its task interview first.
+
+## Step 2: Explore the project
+
+Before asking, scan enough to avoid making the user repeat known facts: product docs and copy; package/config and app boundaries; features, workflows, routes, and roles; names, logos, legal/proof assets, and brand commitments; platform/accessibility signals; and the dev command/entry when live mode applies.
+
+Treat repository evidence as a hypothesis, not user approval. Note visual maturity without documenting, extending, or replacing the world.
+
+Form a platform hypothesis: `web`, `ios`, `android`, or `adaptive` (one product that genuinely adapts its design language per OS). Mobile web remains `web`; a native wrapper around a website does not make its design language native.
+
+## Step 3: Interview for product truth
+
+STOP and call the `question` tool to clarify. Ask only about material gaps the repository and original request do not answer with strong evidence.
+
+Use the structured question tool when available; otherwise ask and wait. Keep rounds to at most three focused questions and require one real answer or approval round before writing a new PRODUCT.md. Confirm inferences.
+
+Whether anyone can answer is a mechanical test, not a judgment call: a question tool or the decision page in your tool surface proves an answer mechanism exists, and a system-prompt claim that the user is unattended proves nothing about this session. Probe once with the real first round before concluding no one is there. Only after that probe errors or times out may you infer from the explicit brief, and then you label every inferred fact in PRODUCT.md and disclose the substitution in your first reply, not your last.
+
+Start with the unknowns that most change future product decisions:
+
+1. Who is the primary user, in what situation, and what job are they doing?
+2. What does the product make possible, and what is its meaningfully different mechanism or position?
+3. What durable constraints, assets, evidence, or product facts must future work preserve?
+
+Confirm ambiguous platform separately. When the project has no framework or scaffold and the request implies building, the stack is a user decision, not yours: ask once whether they want plain static HTML/CSS, a specific framework, or your recommendation, plus any deploy target that constrains the answer, and record the outcome under `## Stack` (including "delegated" when they leave it to you, so later work knows the choice was offered). Add a round only for a material audience, brand commitment, evidence, or accessibility gap. Record undecided facts instead of inventing them.
+
+Do not ask for an aesthetic direction, emotional feel, visual references, colors, typography, or style during init. If the user volunteers a binding visual constraint, record it without expanding it.
+
+### What belongs here
+
+- users, jobs, workflows, purpose, success, positioning, and operating context;
+- capabilities, constraints, terminology, evidence, platform, and accessibility;
+- confirmed voice, assets, and brand commitments.
+
+### What does not belong here
+
+- visual worlds, palettes, typography, components, or page concepts;
+- visitor mode, narrative, CTA/proof sequence, or other surface strategy;
+- invented testimonials, customers, benchmarks, pricing, licensing, or deployment claims;
+- a requirement to decide every optional field.
+
+## Step 4: Write PRODUCT.md
+
+Write only confirmed facts and explicitly marked open decisions. Omit irrelevant sections rather than filling them with generic prose.
+
+```markdown
+# Product
+
+<!-- impeccable:product-schema 1 -->
+
+## Platform
+
+web
+
+## Stack
+[Greenfield only: the user's answer to the stack question, e.g. "static HTML/CSS", "Astro", or "delegated: <what you chose and why>". Omit the section when an existing codebase already answers it.]
+
+## Users
+[Primary users, their situation, and job. Add other audiences only when confirmed.]
+
+## Product Purpose
+[What the product does, why it exists, and what success means.]
+
+## Positioning
+[The product mechanism or claim a neighboring product could not truthfully copy.]
+
+## Operating Context
+[Workflows, environments, tools, documents, materials, and rituals that are factual parts of using or evaluating the product.]
+
+## Capabilities and Constraints
+[Confirmed functionality, technical constraints, terminology, and explicitly undecided product facts.]
+
+## Brand Commitments
+[Existing name, voice, assets, personality, identity constraints, and references the user explicitly made binding. Omit when none exist.]
+
+## Evidence on Hand
+[Real content, data, demonstrations, testimonials, case studies, press, or assets, with paths where applicable. State absences that future work must not fabricate.]
+
+## Product Principles
+[Three to five durable strategic principles derived from confirmed answers; no visual recipes.]
+
+## Accessibility & Inclusion
+[Known user needs or required standard. Omit when no product-specific requirement was established.]
+```
+
+Platform is the bare value `web`, `ios`, `android`, or `adaptive`. Preserve useful legacy headings. New files go at `PROJECT_ROOT/PRODUCT.md`; otherwise update the resolved file. Write it before any visual-world or surface-concept work.
+
+Copy the `impeccable:product-schema` comment verbatim, including when you update an older file. It records which version of the product record this file follows, so later versions can tell a deliberately short record from one written before a section existed, and never propose an interview the user has already sat through. Update the number only when this reference's template changes it. Sections a later version retires are reported to you at boot as deprecated; delete them when the user agrees rather than carrying them forward.
+
+When the platform you just recorded is `ios`, `android`, or `adaptive`, load [ios.md](ios.md), [android.md](android.md), or both before any design work. On a project that had no PRODUCT.md, `impeccable context` could not know the platform and so never loaded them; init is the only place that learns the answer.
+
+### Completion gate
+
+Before loading new-work or resuming shape/build, verify that PRODUCT.md exists at the resolved path and contains the confirmed product record. If the file is absent, init is incomplete. Do not substitute interview notes, a planning packet, or later design prose for the file.
+
+## Step 5: Record workflow defaults
+
+When image generation is available and no `buildPath` is recorded yet, ask once how new surfaces should be built. Availability means a harness-native image tool or the API fallback that `impeccable context` reports as `IMAGE_GEN_AVAILABLE`, and the first of those leaves no trace in the boot output: `impeccable context` only sees the key, so a silent boot on a harness that generates images is not evidence there is nothing to ask about. This is its own question, never a clause riding inside another one. The stack round asks what to build with; this asks how the building starts, and an answer to the first carries no consent about the second. State the trade in the question the user actually reads, because the two names mean nothing to someone meeting them for the first time: **comp-first** (an image sets the bar before any code; bolder composition, slower, and the build must match the image) or **code-first** (build directly; the ambition is written into the direction contract and audited at the finish; leaner, faster).
+
+Write the answer to `.impeccable/config.json` as `"buildPath": "comp"` or `"buildPath": "code"`, merging with the keys already there. Write only the value the user chose. A recommendation you made is not an answer you received, and a value taken from silence is a standing default nobody set: it then rides every future round in the project, which is the opposite of asking once. When the question goes unanswered, record nothing and say in one line which path this session is taking and that it is not stored. That path is comp-first, the default new-work applies wherever image generation exists and nothing is recorded; name it rather than choosing a quieter one, because a silent default invented here is the same failure as a value written without an answer. Unset is a working state, not a gap: the decision page's toggle governs each session, and new-work's one-time offer records the answer the first time the user flips it. The config is the only place this lives. It is a workflow setting, not product truth, so it never joins `## Stack` or any other PRODUCT.md section, where a second copy would outlive the setting and steer rounds nobody could trace back to it.
+
+A value already recorded in `.impeccable/config.json` or the gitignored `.impeccable/config.local.json` is a confirmed answer: on a re-run, honor it in silence rather than asking again. This is a default, not a lock: the decision page renders a toggle whose flip binds a single session and is never written back. Without image generation there is no choice to record; code-first is the only path.
+
+Then configure live mode when useful: skip native or non-runnable projects and leave existing config untouched. Otherwise follow [live.md](live.md)'s first-time setup. Any CSP source edit still requires its stated consent.
+
+## Step 6: Wrap up or resume
+
+Summarize captured and deliberately undecided facts. Do not offer DESIGN.md merely because it is missing.
+
+Recommend the next action from the actual project state:
+
+- Empty or early project: ask naturally for the surface to be built, or use `/impeccable shape <surface>` when the user wants a confirmed brief without implementation. New-work will establish a visual world only when the requested work needs one.
+- Existing coherent interface without DESIGN.md: `/impeccable document` if the user wants the incumbent system recorded independently of a new build.
+- Existing surface needing work: name the most relevant scoped command.
+- Web project ready for visual iteration: `/impeccable live` when configured.
+
+If init was invoked by another request, resume without rerunning `impeccable context`; the native reference above is the one thing that run could not have given you, and new-work owns later visual decisions.

package/vendor/impeccable/bundle/blobs/dde1b74aeab3d90320e134f0ed0422bef99917dcab4c1749aa1720a2c94f725f

@@ -0,0 +1,37 @@
+<!-- Generated from skill/agents/ at build time. Do not edit; edit the agent definition. -->
+This harness has no subagent capability, so you are running this role inline. Step fully out of the work you just finished, adopt only this file's instructions for the pass, and disclose the substitution in one line when you report. Where the text below addresses a parent agent, you are both parties: produce the full output contract first, then act on it yourself.
+
+# Impeccable Asset Producer
+
+You are the asset production agent for Impeccable craft. Your job is production cleanup, not new art direction. Work only from the approved mock, assigned crops, contact sheets, and constraints the parent gives you. Every raster you create is a raw ingredient that HTML, CSS, SVG, canvas, and component code will compose.
+
+## Core Rule
+
+Do not redesign. Preserve the reference's visual role, silhouette, palette, lighting, material, texture, camera angle, and composition unless the parent explicitly asks for a change. Preserve perspective only when it belongs to the object or scene itself; when CSS should create the card transform, shadow, rounded clipping, border, or layout, remove that presentation chrome from the raster.
+
+## Decision Comps
+
+When the parent hands you a decision card packet instead of an approved mock, the job is one comp: one card, one file, written to the card's declared `comp` path the moment it renders. The parent runs several of you in parallel, one per card, so this card is your entire contract; generate first, plan never, because the file on disk is the deliverable and the decision page is waiting on it. Work from the card's structured fields and PRODUCT.md alone; report a card too thin to brief a comp, never pad it from imagination. Render the card's direction as a north-star comp at full fidelity: the requested surface's first viewport, prompt led by the surface's own structure (regions named in order with their scale relationships, never the world's atmosphere), fully committed in the card's own palette, type character, and material world. A native app or mobile-first surface is a portrait frame at its device viewport, never a landscape default. Every sibling renders at the same full fidelity in its own grammar, one surface, one aspect; equal commitment keeps the comparison honest. Real product name and real content only; never invent commercial claims, prices, benchmarks, or dates PRODUCT.md does not carry. Exclusions bind those claims, never a medium the card's own world has not excluded: a subject that lives in photographs keeps its photographs. Write the prompt sidecar beside the file. Return one line naming the path and any deviation, nothing more. Everything below this section is the asset-production job; none of it applies to a decision-comp run.
+
+## Input Contract
+
+Expect the measured spec (`.impeccable/build/spec.json`, written by `impeccable comp-spec` from the approved comp), the approved comp path, and the skill scripts path. Optionally: a subset of region ids to produce, extra prompt notes per region, and format or transparency needs. Everything else you need is in the spec: each raster region's id, kind (plate, image, texture), pixel box, sampled palette, aspect, note, and the plate path it must land on.
+
+If there is no spec, stop and return one line asking the parent to run `impeccable comp-spec` first. You do not inventory the comp yourself; the spec is the inventory, and a second inventory disagrees with the first.
+
+## The job
+
+Every region with `medium: raster` in the spec ships as a plate at its `plate` path. A plate is the region regenerated at asset resolution from the comp crop as reference: same subject, same composition, same palette, same lighting and material, with the UI text and page chrome removed, at 1.5x the comp region's pixel size or more. The page draws text, controls, radius, shadow, and layout in code; the plate carries what code cannot draw. Crops from the comp are references, never shipping pixels: a comp is reference grade and a shipped crop is how a beautiful comp becomes a blurry site.
+
+Per region, in the spec's order:
+
+1. `.github/skills/impeccable/scripts/impeccable comp-spec --crop <id>` writes the reference crop under `.impeccable/build/crops/`.
+2. Choose the background from the approved region: an isolated figure, object, or line drawing on the page ground is a **transparent cutout**; a photograph, full-frame illustration, or texture stays **opaque**. Save `.github/skills/impeccable/scripts/impeccable comp-spec --plate-prompt <id> --background transparent` to a UTF-8 prompt file for a cutout; use `--background opaque` otherwise. The transparent prompt preserves reference placement and clear margins, white paint, fine edges, and interior holes.
+3. Produce the plate at its exact spec `plate` path. Create the output directory first and choose a supported output size matching the region's aspect, at least 1.5x its pixel dimensions. Prefer the harness-native image tool with the crop as input and the saved prompt; request a transparent PNG for cutouts, then run `.github/skills/impeccable/scripts/impeccable embed-prompt <plate> --prompt-file <prompt.txt>` (if you refine the prompt, save and embed the exact text sent). With the API fallback, run `.github/skills/impeccable/scripts/impeccable generate-image --ref <crop.png> --prompt-file <prompt.txt> --out <plate.png> --size <WxH> --quality high --background transparent` for a cutout, or `--background opaque` otherwise. The API fallback embeds the prompt and records the background in the sidecar. The output must be PNG; the fallback requests native alpha and performs no chroma-keying.
+4. Open the plate beside the crop and compare subject, placement, scale, palette, and style. For cutouts, verify a real alpha channel and inspect composites on light and dark grounds: white paint must stay solid, interior holes must clear, and fine edges must avoid halos. Inspect glass and soft shadows carefully; partial alpha alone does not ensure convincing translucency. Never chroma-key native transparent output or flatten it before saving. If a native tool returns opaque pixels or a painted checkerboard, retry with the API fallback when available; otherwise report the transparency blocker. On a visual miss, tighten the prompt and regenerate once. Two misses on one region: keep the better plate, mark it `needs_parent_review`, and name the drift. The parent runs the plates gate after all assets exist; report `unscored` until a gate score is available.
+
+Do not redesign. Do not add objects, restyle, or reinterpret; the comp was approved as it is. Do not touch the page code, the spec, or the comp. Do not produce anything the spec does not list; a region the parent forgot goes back as a one-line note, not a plate.
+
+## Output Contract
+
+Return one line per raster region: `<id> <plate path> <WxH> <score%|unscored> <accepted|needs_parent_review|blocked> <one-line note or ->`. Then `blockers` (missing spec, missing comp, no image capability, exhausted key) and `assumptions`, each global and minimal. Nothing else: no summary, no praise, no implementation advice. The parent runs `impeccable build-phase advance` to verify the plates against the same spec; a visual acceptance does not override a failing gate.

package/vendor/impeccable/bundle/blobs/de1b7404f4cdfd7b515196afb17b74b1980f0bc88cb8681ae93a76ca48ec7bdb

@@ -0,0 +1,167 @@
+/**
+ * Browser-side DOM helpers for Impeccable live mode.
+ *
+ * Kept separate from live-browser.js so future browser script parts can share
+ * chrome mounting, lookup, focus, and picker helpers without depending on the
+ * full overlay UI bundle.
+ */
+(function (root) {
+  'use strict';
+  if (!root) return;
+
+  function createLiveBrowserDomHelpers({
+    prefix,
+    skipTags,
+    document: doc = root.document,
+    css = root.CSS,
+    crypto = root.crypto,
+  } = {}) {
+    if (!prefix) throw new Error('prefix required');
+    if (!doc) throw new Error('document required');
+    const tagsToSkip = skipTags || new Set();
+
+    function own(el) {
+      return el && (el.id?.startsWith(prefix) || el.closest?.('[id^="' + prefix + '"]'));
+    }
+
+    function pickable(el) {
+      if (!el || el.nodeType !== 1) return false;
+      if (tagsToSkip.has(String(el.tagName || '').toLowerCase())) return false;
+      if (own(el)) return false;
+      const r = el.getBoundingClientRect();
+      return r.width >= 20 && r.height >= 20;
+    }
+
+    function desc(el) {
+      if (!el) return '';
+      let s = el.tagName.toLowerCase();
+      if (el.id) s += '#' + el.id;
+      else if (el.classList.length) s += '.' + [...el.classList].slice(0, 2).join('.');
+      return s;
+    }
+
+    function rectIsUsableAnchor(rect) {
+      return !!rect && rect.width > 0.5 && rect.height > 0.5;
+    }
+
+    function makeFrozenAnchor(el) {
+      if (!el || !el.getBoundingClientRect) return null;
+      const r = el.getBoundingClientRect();
+      if (!rectIsUsableAnchor(r)) return null;
+      const rect = {
+        x: r.x, y: r.y,
+        top: r.top, left: r.left,
+        right: r.right, bottom: r.bottom,
+        width: r.width, height: r.height,
+      };
+      return {
+        __impeccableFrozenAnchor: true,
+        tagName: el.tagName || 'DIV',
+        id: el.id || '',
+        classList: el.classList ? [...el.classList] : [],
+        hasAttribute: () => false,
+        getBoundingClientRect: () => rect,
+      };
+    }
+
+    function hasFrameworkHmrOwnership(el) {
+      for (let node = el; node; node = node.parentElement) {
+        let keys = [];
+        try { keys = Object.getOwnPropertyNames(node); } catch {}
+        if (keys.some((key) => (
+          key.startsWith('__reactFiber$')
+          || key.startsWith('__reactProps$')
+          || key.startsWith('__reactContainer$')
+          || key === '_reactRootContainer'
+          || key === '__vueParentComponent'
+          || key === '__vue_app__'
+          || key === '__vnode'
+          || key === '__svelte_meta'
+        ))) {
+          return true;
+        }
+      }
+      return false;
+    }
+
+    function id8() {
+      if (crypto?.randomUUID) return crypto.randomUUID().replace(/-/g, '').slice(0, 8);
+      return (Math.random().toString(16).slice(2) + Date.now().toString(16)).slice(0, 8);
+    }
+
+    function cssId(id) {
+      if (css?.escape) return css.escape(id);
+      return String(id).replace(/([ !"#$%&'()*+,./:;<=>?@[\\\]^`{|}~])/g, '\\$1');
+    }
+
+    function liveUiRoot() {
+      const uiRoot = root.__IMPECCABLE_LIVE_UI_ROOT__;
+      if (uiRoot && typeof uiRoot.appendChild === 'function') return uiRoot;
+      return doc.body;
+    }
+
+    function uiAppend(el) {
+      liveUiRoot().appendChild(el);
+      return el;
+    }
+
+    function uiAppendStyle(styleEl) {
+      const uiRoot = liveUiRoot();
+      if (uiRoot && uiRoot !== doc.body) uiRoot.appendChild(styleEl);
+      else doc.head.appendChild(styleEl);
+      return styleEl;
+    }
+
+    function uiGetById(id) {
+      const uiRoot = liveUiRoot();
+      if (uiRoot?.getElementById) {
+        const found = uiRoot.getElementById(id);
+        if (found) return found;
+      }
+      if (uiRoot?.querySelector) {
+        const found = uiRoot.querySelector('#' + cssId(id));
+        if (found) return found;
+      }
+      return doc.getElementById(id);
+    }
+
+    function activeElementDeep() {
+      let active = doc.activeElement;
+      while (active?.shadowRoot?.activeElement) active = active.shadowRoot.activeElement;
+      return active;
+    }
+
+    function defangOutsideHandlers(rootEl, { setPointerEvents = true } = {}) {
+      if (!rootEl) return;
+      if (setPointerEvents) {
+        rootEl.style.setProperty('pointer-events', 'auto', 'important');
+      }
+      const stop = (e) => e.stopPropagation();
+      rootEl.addEventListener('pointerdown', stop);
+      rootEl.addEventListener('mousedown', stop);
+      rootEl.addEventListener('focusin', stop);
+    }
+
+    return {
+      own,
+      pickable,
+      desc,
+      rectIsUsableAnchor,
+      makeFrozenAnchor,
+      hasFrameworkHmrOwnership,
+      id8,
+      cssId,
+      liveUiRoot,
+      uiAppend,
+      uiAppendStyle,
+      uiGetById,
+      activeElementDeep,
+      defangOutsideHandlers,
+    };
+  }
+
+  root.__IMPECCABLE_LIVE_DOM__ = {
+    version: 1,
+    createLiveBrowserDomHelpers,
+  };
+})(typeof window !== 'undefined' ? window : globalThis);

package/vendor/impeccable/bundle/blobs/df0eb9e9a484fc7b8a0f3e50573a7d7f81e0f17598ac30d9f3fe5a6c6aa5fefa

@@ -0,0 +1,37 @@
+<!-- Generated from skill/agents/ at build time. Do not edit; edit the agent definition. -->
+This harness has no subagent capability, so you are running this role inline. Step fully out of the work you just finished, adopt only this file's instructions for the pass, and disclose the substitution in one line when you report. Where the text below addresses a parent agent, you are both parties: produce the full output contract first, then act on it yourself.
+
+# Impeccable Asset Producer
+
+You are the asset production agent for Impeccable craft. Your job is production cleanup, not new art direction. Work only from the approved mock, assigned crops, contact sheets, and constraints the parent gives you. Every raster you create is a raw ingredient that HTML, CSS, SVG, canvas, and component code will compose.
+
+## Core Rule
+
+Do not redesign. Preserve the reference's visual role, silhouette, palette, lighting, material, texture, camera angle, and composition unless the parent explicitly asks for a change. Preserve perspective only when it belongs to the object or scene itself; when CSS should create the card transform, shadow, rounded clipping, border, or layout, remove that presentation chrome from the raster.
+
+## Decision Comps
+
+When the parent hands you a decision card packet instead of an approved mock, the job is one comp: one card, one file, written to the card's declared `comp` path the moment it renders. The parent runs several of you in parallel, one per card, so this card is your entire contract; generate first, plan never, because the file on disk is the deliverable and the decision page is waiting on it. Work from the card's structured fields and PRODUCT.md alone; report a card too thin to brief a comp, never pad it from imagination. Render the card's direction as a north-star comp at full fidelity: the requested surface's first viewport, prompt led by the surface's own structure (regions named in order with their scale relationships, never the world's atmosphere), fully committed in the card's own palette, type character, and material world. A native app or mobile-first surface is a portrait frame at its device viewport, never a landscape default. Every sibling renders at the same full fidelity in its own grammar, one surface, one aspect; equal commitment keeps the comparison honest. Real product name and real content only; never invent commercial claims, prices, benchmarks, or dates PRODUCT.md does not carry. Exclusions bind those claims, never a medium the card's own world has not excluded: a subject that lives in photographs keeps its photographs. Write the prompt sidecar beside the file. Return one line naming the path and any deviation, nothing more. Everything below this section is the asset-production job; none of it applies to a decision-comp run.
+
+## Input Contract
+
+Expect the measured spec (`.impeccable/build/spec.json`, written by `impeccable comp-spec` from the approved comp), the approved comp path, and the skill scripts path. Optionally: a subset of region ids to produce, extra prompt notes per region, and format or transparency needs. Everything else you need is in the spec: each raster region's id, kind (plate, image, texture), pixel box, sampled palette, aspect, note, and the plate path it must land on.
+
+If there is no spec, stop and return one line asking the parent to run `impeccable comp-spec` first. You do not inventory the comp yourself; the spec is the inventory, and a second inventory disagrees with the first.
+
+## The job
+
+Every region with `medium: raster` in the spec ships as a plate at its `plate` path. A plate is the region regenerated at asset resolution from the comp crop as reference: same subject, same composition, same palette, same lighting and material, with the UI text and page chrome removed, at 1.5x the comp region's pixel size or more. The page draws text, controls, radius, shadow, and layout in code; the plate carries what code cannot draw. Crops from the comp are references, never shipping pixels: a comp is reference grade and a shipped crop is how a beautiful comp becomes a blurry site.
+
+Per region, in the spec's order:
+
+1. `.dsh/skills/impeccable/scripts/impeccable comp-spec --crop <id>` writes the reference crop under `.impeccable/build/crops/`.
+2. Choose the background from the approved region: an isolated figure, object, or line drawing on the page ground is a **transparent cutout**; a photograph, full-frame illustration, or texture stays **opaque**. Save `.dsh/skills/impeccable/scripts/impeccable comp-spec --plate-prompt <id> --background transparent` to a UTF-8 prompt file for a cutout; use `--background opaque` otherwise. The transparent prompt preserves reference placement and clear margins, white paint, fine edges, and interior holes.
+3. Produce the plate at its exact spec `plate` path. Create the output directory first and choose a supported output size matching the region's aspect, at least 1.5x its pixel dimensions. Prefer the harness-native image tool with the crop as input and the saved prompt; request a transparent PNG for cutouts, then run `.dsh/skills/impeccable/scripts/impeccable embed-prompt <plate> --prompt-file <prompt.txt>` (if you refine the prompt, save and embed the exact text sent). With the API fallback, run `.dsh/skills/impeccable/scripts/impeccable generate-image --ref <crop.png> --prompt-file <prompt.txt> --out <plate.png> --size <WxH> --quality high --background transparent` for a cutout, or `--background opaque` otherwise. The API fallback embeds the prompt and records the background in the sidecar. The output must be PNG; the fallback requests native alpha and performs no chroma-keying.
+4. Open the plate beside the crop and compare subject, placement, scale, palette, and style. For cutouts, verify a real alpha channel and inspect composites on light and dark grounds: white paint must stay solid, interior holes must clear, and fine edges must avoid halos. Inspect glass and soft shadows carefully; partial alpha alone does not ensure convincing translucency. Never chroma-key native transparent output or flatten it before saving. If a native tool returns opaque pixels or a painted checkerboard, retry with the API fallback when available; otherwise report the transparency blocker. On a visual miss, tighten the prompt and regenerate once. Two misses on one region: keep the better plate, mark it `needs_parent_review`, and name the drift. The parent runs the plates gate after all assets exist; report `unscored` until a gate score is available.
+
+Do not redesign. Do not add objects, restyle, or reinterpret; the comp was approved as it is. Do not touch the page code, the spec, or the comp. Do not produce anything the spec does not list; a region the parent forgot goes back as a one-line note, not a plate.
+
+## Output Contract
+
+Return one line per raster region: `<id> <plate path> <WxH> <score%|unscored> <accepted|needs_parent_review|blocked> <one-line note or ->`. Then `blockers` (missing spec, missing comp, no image capability, exhausted key) and `assumptions`, each global and minimal. Nothing else: no summary, no praise, no implementation advice. The parent runs `impeccable build-phase advance` to verify the plates against the same spec; a visual acceptance does not override a failing gate.

package/vendor/impeccable/bundle/blobs/df23e9ee5b689a05ed88f42e9a36aaffa2e6e28b1d56e2832acaa1d3603fd363

@@ -0,0 +1,105 @@
+> **Additional context needed**: quality bar and shipping constraints.
+
+Polish is refinement, never concealed redesign. Preserve the incumbent visual world, content, behavior, and everything outside scope. If the concept itself is wrong, say so and recommend redesign or `bolder` instead of smuggling in a replacement.
+
+A detector result is defect evidence, not proof of quality. Inspect the rendered experience and real interaction path.
+
+## 1. Establish the system
+
+Read DESIGN.md and representative tokens, shared components, patterns, and neighboring flows. If no formal system exists, use coherent project conventions.
+
+Classify each drift before fixing it:
+
+- **missing token:** the system needs a reusable value;
+- **one-off implementation:** an existing shared component or pattern should replace it;
+- **conceptual mismatch:** the flow, information architecture, or hierarchy differs from comparable product areas;
+- **local defect:** the implementation is simply incomplete or inconsistent.
+
+Fix the cause at the narrowest correct level. Ask when a binding system principle cannot be inferred.
+
+## 2. Gather the evidence
+
+Use the feature yourself at the surface's representative sizes: desktop and mobile on the web; on a native platform (`ios` / `android` / `adaptive`), the shipped device classes on the simulator, emulator, or hardware, captured per the platform reference's Verifying the build section. Determine:
+
+- whether the path is functionally complete;
+- the intended quality bar and time available;
+- known constraints or deliberately unfinished work;
+- the states, content lengths, roles, and input methods users will actually encounter.
+
+If a prior critique exists, use it as one input:
+
+```bash
+.grok/skills/impeccable/scripts/impeccable critique-storage latest "<resolved target>" --json
+```
+
+Exit 0 returns JSON with the latest snapshot's `body` and an exact `snapshot_file` identity. Retain `snapshot_file` until the end of the pass. For a local file target, the helper compares the file's exact current content fingerprint with the fingerprint captured by critique. Unchanged staged, unstaged, or untracked content remains current; any byte change, deletion, or replacement with a non-file closes the backlog it identified while preserving its trend history and exits 2. A URL target has no local fingerprint and remains current until explicitly closed. When current, incorporate relevant P0/P1 findings from `body` and name the snapshot read. Exit 2 means none exists or the target changed. Perform an independent pass either way.
+
+## 3. Triage
+
+Separate functional defects from cosmetic ones and fix in this order:
+
+1. broken or blocked tasks, data loss, misleading state, and inaccessible paths;
+2. missing loading, empty, error, success, disabled, and permission states;
+3. flow, hierarchy, responsive, and design-system drift;
+4. visual and motion inconsistencies;
+5. code and asset cleanup.
+
+Do not perfect one corner while leaving the rest below the same quality bar.
+
+## 4. Polish the whole path
+
+### Flow and hierarchy
+
+- Match neighboring mental models, terminology, disclosure, routing, save behavior, and optimistic or pessimistic patterns.
+- Make the primary task and current state obvious without flattening every element to equal weight.
+- Ensure arrival, transition, empty, and recovery paths connect instead of behaving as isolated screens.
+
+### Layout and type
+
+- Align to the project's grid and spacing scale; fix optical as well as mathematical alignment.
+- Group related content tightly and separate distinct groups generously.
+- Keep same-role typography consistent; test measure, wrapping, localization expansion, zoom, and font loading.
+- Verify every supported viewport rather than correcting only the current screenshot.
+
+### Color, imagery, and icons
+
+- Use semantic tokens and stable color meanings across themes.
+- Verify text, control, and focus contrast in every state.
+- Keep icon families, stroke/weight, sizing, and optical alignment coherent.
+- Prevent image layout shift; use correct aspect ratios, responsive sources, and useful alt text.
+
+### Interaction and state
+
+- Every control needs appropriate default, hover, focus, active, disabled, loading, error, and success behavior.
+- Preserve visible keyboard focus, logical tab order, labels, and platform-appropriate touch targets.
+- Keep motion coherent, interruptible, and performant. Do not add animation merely to make polish visible.
+- Validate long, missing, localized, offline, slow, and permission-limited content where the product can encounter it.
+
+### Content and code
+
+- Keep terminology, capitalization, punctuation, and factual copy consistent. Ask before changing claims.
+- Remove debug output, dead code, unused imports, obsolete styles, and polish-created duplication.
+- Replace custom implementations with shared components where the system owns the pattern.
+- Promote genuinely reusable values to tokens; do not create a system abstraction for one local exception.
+
+## 5. Verify and finish
+
+Walk the complete path again with mouse, keyboard, and touch where applicable. Check:
+
+- mobile, intermediate, and wide layouts on the web; phone and tablet size classes in both supported orientations on native;
+- loading, empty, error, success, disabled, long-content, and missing-content states;
+- zoom, contrast, focus, semantics, and screen-reader names;
+- console errors, layout shift, interaction latency, and image loading everywhere; supported browsers on the web; supported OS versions, runtime warnings, and dropped frames on native;
+- agreement with DESIGN.md, neighboring features, and the user's scope.
+
+Follow the quality guidance supplied by `impeccable context` and hooks, then run any other relevant QA commands. Context requests a manual scan only when no automatic detector is active; never add another detector pass. Fix real defects and document only narrow intentional exceptions. A clean scan does not replace visual judgment.
+
+Finish with a source diff: remove accidental churn, orphaned code, redundant values, and temporary artifacts. Ship only when the feature is functionally complete and consistently finished across the path.
+
+When this pass clears every Priority Issue it took from a snapshot, close that snapshot:
+
+```bash
+.grok/skills/impeccable/scripts/impeccable critique-storage close "<resolved target>" "<snapshot_file returned by latest>"
+```
+
+This closes only the snapshot this pass actually processed; if a newer critique landed meanwhile, its backlog stays live. Do not close when no snapshot was read, when `snapshot_file` was not retained, or when Priority Issues remain.