@blockbite/agent-context 0.1.0

package/skills/site-reviewer/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: site-reviewer
+description: Review BlockBite site builds without mutating files, writing actionable markdown reports for Figma-to-site parity, document-blueprint order, reusable dynamic-template inventory, token drift, dynamic-content contracts, Alpine/ESM errors, responsive layout, and console/network failures.
+---
+
+# Site Reviewer
+
+Use this skill for review-only passes. Do not mutate files, run imports, register templates, sync dynamic content, or alter the database.
+
+Write reports to:
+
+```text
+<workspace>/dev/reviews/<site>/<page>-review.md
+```
+
+## Scope
+
+Review against available Figma nodes, the site plan, island inventory, page blueprint map, template packages, seed files, previews, and browser/runtime checks.
+
+If Figma access is unavailable, state that limitation and review only the local build artifacts and runtime behavior.
+
+## Read First
+
+- `<workspace>/dev/plans/<site>/site-plan.md`
+- `<workspace>/dev/plans/<site>/island-inventory.md`
+- `<workspace>/dev/plans/<site>/page-blueprint-map.md`
+- `<workspace>/dev/plans/<site>/token-map.md`
+- `dev/skills/document-blueprint/SKILL.md`
+- `dev/skills/template-preview/SKILL.md`
+- relevant template package files
+- relevant `document-blueprints/<page>/blueprint.json` and `sections/*.seed.json`
+
+## Checks
+
+Check:
+
+- blueprint section order against the locked page map
+- missing or extra islands
+- duplicate templates that should be reused
+- page-specific duplicate slugs for overlapping designs
+- generic fallback components where Figma expects specific structure, such as mixed-height carousel cards
+- header/footer dynamic-template and theme-pattern registration plan
+- token drift between Figma, `token-map.md`, and `dev/css/design-tokens.css`
+- image/media ratio, crop, focal, and asset mismatches
+- missing SVG asset fields for editable icons/decorative SVGs
+- dynamic-content contracts: source type, field handles, repeater handles, seed shape, and Liquid paths
+- blueprint seed files for reused templates
+- Alpine failures, especially `x-collapse` when Alpine collapse is missing
+- ESM/CDN registration and module loading failures
+- desktop and mobile layout, overflow, text clipping, z-index, and interaction state
+- console errors, network failures, and `window.BlockBiteDebug?.errors` when available
+
+## Browser Review
+
+When reviewing block editor or frontend client-side behavior, inspect browser console, network failures, and relevant runtime logs before writing findings. Use those errors to identify the failing path.
+
+Review at least:
+
+- desktop viewport
+- mobile viewport
+- initial load
+- interaction states for nav, FAQ, sliders, tabs, filters, marquees, and reveals when present
+
+## Report Format
+
+Write markdown with:
+
+```markdown
+# <Page> Review
+
+## Summary
+
+- Reviewed: <preview/page URL or file-backed view>
+- Figma: <file key/node ids or unavailable>
+- Status: pass | needs changes | blocked
+
+## Findings
+
+### P1 - <short title>
+
+- Island: <slug or n/a>
+- Blueprint section: <key or n/a>
+- File: <path or n/a>
+- Evidence: <specific observed mismatch or error>
+- Suggested fix: <actionable fix>
+
+## Open Questions
+
+- <question>
+
+## Checks Run
+
+- <command or browser check>
+```
+
+Severity:
+
+- `P0`: blocks page use, import safety, or runtime boot.
+- `P1`: significant design/content/interaction mismatch.
+- `P2`: polish, maintainability, or minor responsive issue.
+- `P3`: optional improvement.
+
+Findings must be actionable and grounded in a file path, island slug, blueprint section key, URL, screenshot observation, console error, or Figma node. If no issues are found, say so and list any review gaps.
+
+## Finish
+
+Return only the report path, status, highest severity, and short summary of findings. Do not apply fixes in the reviewer pass.

package/skills/sync-plan/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: sync-plan
+description: Create or diff a draft BlockBite sync plan that compares workspace template packages with the database records. Use when the user wants to know what would change before syncing. Never applies changes.
+---
+
+# BlockBite sync plan
+
+## Steps
+
+1. Ensure a project is selected.
+2. To draft a plan, call `blockbite-sync-plan-create` with
+   `{ "slug": "<slug>" }` or `{ "view": "templates/<slug>/template.liquid" }`.
+3. To see explicit current-state comparisons, call `blockbite-sync-plan-diff`
+   with the same target.
+4. Summarize the proposed additions/updates and current state for the user.
+
+## Notes
+
+- Both tools are read-only and never apply changes to posts, Site Editor
+  entities, or workspace files.

package/skills/template-figma/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: template-figma
+description: Build or refine a BlockBite Studio dynamic template from a Figma frame or node link using Figma MCP. Use when the user provides or wants to provide a Figma frame/node URL, wants a Figma design converted into a BlockBite template, or wants a generated Figma template cleaned up into a maintainable dynamic template package.
+---
+
+# Template Figma
+
+Use Figma MCP to turn a frame or node into a maintainable BlockBite Studio dynamic template.
+
+Before mapping Figma layers to DSL tags, read `../references/block-dsl.md` when it exists.
+For BlockBite-specific Tailwind utilities such as `area-[...]`, `grid-area-[...]`, and `children:*`, read `../references/tailwind-utilities.md` when it exists.
+When mapping Figma colors or typography to token-backed Tailwind classes, run `wp bb design-tokens db-to-local` if needed and read `<workspace>/dev/css/design-tokens.css`.
+
+## Agent Contract
+
+The agent is the interface; WP-CLI is only the executor. Do not rely on interactive CLI prompts. Resolve the Figma URL and target slug from the chat, ask only for missing required values, then run commands with full flags.
+
+## Build Mode Contract
+
+Treat BlockBite's reported build mode as authoritative:
+
+- auto-build: after template, style, script, or block-style edits, run `ddev wp bb autobuild`; if Node.js is unavailable, open the signed browser fallback URL.
+- custom-build: do not use the signed browser runner; use the project-specific frontend build pipeline.
+- Default to auto-build for template and site work unless `wp bb learn`, `wp bb init`, or `dev/template-start/latest.json` explicitly reports custom-build.
+- Do not infer custom-build from development manifests in mounted plugins or neighboring projects.
+- Do not start, repair, shim, or mutate external Vite/Webpack setup unless the user explicitly asks for plugin development or custom-build work.
+- If autobuild stalls or fails, report the runner status and stop before changing build setup.
+
+## Inputs
+
+Require:
+
+- Figma frame or node URL
+- target template slug
+- intended source type: `block_instance`, `post_type`, `collection`, `single`, or `hook`
+- desired dynamic fields and repeaters when known
+
+If a handoff JSON exists, read it first and use its answers.
+
+Choose the source type before mapping fields:
+
+- Use `block_instance` for content owned by the inserted template block instance.
+- Use `post_type` for CPT/single-post templates that read the current post's BlockBite source fields directly.
+- Use `block_instance` plus `post_relation` only when the editor should manually select related posts for this template instance.
+
+Do not use a relation field to simulate the current CPT item. Relation-backed patterns read nested data such as `props.fields.work.source.work.client`; `post_type` templates read direct fields such as `props.fields.client` or `section.fields.client`.
+
+## Figma Workflow
+
+Load the Figma context through the available Figma MCP tooling. Inspect layout, typography, spacing, repeated groups, imagery, and interactive states.
+
+Map design structure into:
+
+- section-level `fields`
+- repeated groups as `subcollections`
+- local template assets only when needed
+- shared workspace block styles for reusable button/card/control variants
+- Tailwind classes compatible with BlockBite runtime
+
+Avoid preserving noisy generated wrappers when a simpler structure matches the design.
+
+## Required Package
+
+Write or refine `<workspace>/templates/<slug>/` with:
+
+- `template.liquid`
+- `recipe.json`
+- `seeds.json`
+- `fields.yaml`
+- `manifest.json`
+- `style.css`
+- `module.ts`
+
+Use the standard runtime prelude:
+
+```liquid
+{% assign seed_data = 'seeds.json' | bb_seed %}
+{% assign data = item | bb_source %}
+{% assign props = live | ternary: data, seed_data %}
+```
+
+After choosing fields, compare `fields.yaml`, `recipe.json`, `seeds.json`, and Liquid paths. Repeater handles must stay identical across all files; for example, `subcollections.information` must not become `subcollections.items` in Liquid.
+
+Supported `fields.yaml` field types are: `string`, `text`, `textarea`, `richtext`, `media`, `image`, `file`, `link`, `svg`, `number`, `integer`, `float`, `boolean`, `bool`, `toggle`, `select`, `radio`, `date`, `datetime`, `color`, `email`, `telephone`, `url`, `password`, and `post_relation`.
+
+Map Figma imagery intended for editor selection to `type: media`, not `type: string`. `type: image` and `type: file` are accepted aliases that normalize to `media`. Only use a URL/string field for an intentionally typed external URL. Media fields store object payloads, so render them via `bb_media` or `bb-image`/`core-image` media props instead of treating the value as a bare string.
+
+Map Figma icons or decorative SVG assets to `type: svg`. Use `kind: icon` for icon assets and `kind: shape` for shape assets; `kind` defaults to `icon`. Do not invent `type: icon`.
+
+## Shared Styles Boundary
+
+Do not put Figma island styling or global `html`, `body`, `button`, `input`,
+typography, background, or reset rules in `<workspace>/app/styles-shared/*.css`.
+
+`app/styles-shared/shared.css` is bundled into `app.bundle.css` and loaded in
+block editor previews as well as the frontend. Use it only for intentionally
+shared, scoped component or template-family classes. Put frontend-only global
+page styles in `app/styles-app/app.css` or the theme stylesheet. Put island
+styles in `<workspace>/templates/<slug>/style.css`.
+
+## CLI Flow
+
+Register or update through WP-CLI:
+
+```bash
+ddev wp bb dynamic-template create --slug=<slug>
+ddev wp bb dynamic-content create --slug=<slug> --source-type=<block_instance|post_type|collection|single|hook> --fields=<template-or-source-folder>/fields.yaml
+ddev wp bb source import-seeds --slug=<slug> --file=wp-content/blockbite/templates/<slug>/seeds.json
+```
+
+For CPT-bound templates, use `--source-type=post_type` and the source schema for that CPT, for example `--fields=work/fields.yaml`. Use `block_instance` only for inserted, instance-owned template content.
+
+If rows already exist, use `dynamic-template update` and `dynamic-content sync`.
+
+If the registered slug and filesystem view differ, update the template path separately:
+
+```bash
+ddev wp bb dynamic-template path --slug=<slug> --view=templates/v1/<slug>/template.liquid
+```
+
+## Finish
+
+Verify the template renders with seed data, confirm dynamic fields are editable, and note any Figma details that could not be represented exactly in the runtime.

package/skills/template-new/SKILL.md

@@ -0,0 +1,221 @@
+---
+name: template-new
+description: Create a new BlockBite Studio dynamic template package from a short brief. Use when the user wants a new template/section such as FAQ, hero, cards, services, statistics, team, testimonial, CTA, or a custom section, including creating package files, dynamic fields, seed data, and registering/importing through WP-CLI.
+---
+
+# Template New
+
+Create a full BlockBite Studio dynamic template package in the active workspace.
+
+Before authoring DSL tags, read `../references/block-dsl.md` when it exists.
+For BlockBite-specific Tailwind utilities such as `area-[...]`, `grid-area-[...]`, and `children:*`, read `../references/tailwind-utilities.md` when it exists.
+When token-backed Tailwind classes matter, run `wp bb design-tokens db-to-local` if needed and read `<workspace>/dev/css/design-tokens.css`.
+
+## Agent Contract
+
+The agent is the interface; WP-CLI is only the executor. Do not rely on interactive CLI prompts. Resolve the slug/type from the chat, ask only for missing required values, then run commands with full flags.
+
+## Build Mode Contract
+
+Treat BlockBite's reported build mode as authoritative:
+
+- auto-build: after template, style, script, or block-style edits, run `ddev wp bb autobuild`; if Node.js is unavailable, open the signed browser fallback URL.
+- custom-build: do not use the signed browser runner; use the project-specific frontend build pipeline.
+- Default to auto-build for template and site work unless `wp bb learn`, `wp bb init`, or `dev/template-start/latest.json` explicitly reports custom-build.
+- Do not infer custom-build from development manifests in mounted plugins or neighboring projects.
+- Do not start, repair, shim, or mutate external Vite/Webpack setup unless the user explicitly asks for plugin development or custom-build work.
+- If autobuild stalls or fails, report the runner status and stop before changing build setup.
+
+## Required Package
+
+Write the package under `<workspace>/templates/<slug>/` with:
+
+- `template.liquid`
+- `recipe.json`
+- `seeds.json`
+- `fields.yaml`
+- `manifest.json`
+- `style.css`
+- `module.ts`
+
+Use the current local template style. If a similar template exists, read it first and mirror its runtime conventions.
+
+## Runtime Pattern
+
+Choose the dynamic-content source type before writing files:
+
+- Use `block_instance` when the content belongs to the inserted template block instance.
+- Use `post_type` when the template renders inside a CPT/single post context and should read the current post's BlockBite source fields.
+- Use `block_instance` with a `post_relation` field only when the editor must manually pick a related post or posts for that template instance.
+
+Do not model a CPT-bound island as `block_instance` plus `post_relation` just because it renders on a CPT template. That nests data under the relation field and produces paths such as `props.fields.work.source.work.client`. A CPT-bound island should use `post_type` and read the current post source payload directly, such as `props.fields.client` or, when the local template variable is named `section`, `section.fields.client`.
+
+Start `template.liquid` with:
+
+```liquid
+{% assign seed_data = 'seeds.json' | bb_seed %}
+{% assign data = item | bb_source %}
+{% assign props = live | ternary: data, seed_data %}
+```
+
+Read single fields from `props.fields.<handle>`.
+Read repeaters from `props.subcollections.<handle>`.
+If the template assigns `section = props`, keep the same direct payload model and read `section.fields.<handle>` and `section.subcollections.<handle>`.
+Use `{{ value | bb_str | raw }}` for editable text output.
+
+For `post_relation` fields with `metadata.include_source: true`, selected post source fields are nested under the relation item, for example `props.fields.work.source.work.client`. Use that shape only for relation-backed patterns, not for `post_type` templates.
+
+## Fill Layers
+
+For hero backgrounds, overlays, and visual layers, use the child DSL API:
+
+```liquid
+<bb-group tag="section" class="relative isolate min-h-[720px] overflow-hidden">
+  <bb-fills>
+    <bb-fill type="image" field="{{ props.fields.hero_artwork }}" class="opacity-70" />
+    <bb-fill type="gradient" class="bg-gradient-to-b from-black/20 to-black/70" />
+  </bb-fills>
+
+  ...
+</bb-group>
+```
+
+Do not put fills directly on `<bb-group>` props. Do not use absolutely
+positioned `<core-image>` or `<bb-image>` nodes for images that are only
+background/fill layers. Use `bb-fill type="image"` with a `media` field so the
+editor inline preview and media picker can treat the image as editable fill
+media. Keep foreground content above fills with normal stacking classes such as
+`relative z-10`.
+
+## Field Contract
+
+`fields.yaml` is schema-only:
+
+```yaml
+version: 1
+
+fields:
+  title:
+    type: string
+    label: Title
+    required: false
+
+subcollections:
+  items:
+    label: Items
+    fields:
+      heading:
+        type: string
+        label: Heading
+        required: false
+      text:
+        type: richtext
+        label: Text
+        required: false
+```
+
+Use top-level `fields` for section-level content. Use `subcollections` for repeated cards, FAQ rows, stats, people, logos, and slides.
+
+Supported field types are: `string`, `text`, `textarea`, `richtext`, `media`, `image`, `file`, `link`, `svg`, `number`, `integer`, `float`, `boolean`, `bool`, `toggle`, `select`, `radio`, `date`, `datetime`, `color`, `email`, `telephone`, `url`, `password`, and `post_relation`.
+
+Use `type: media` for WordPress media picker fields. `type: image` and `type: file` are accepted aliases, but they normalize to `media`. Do not model editable images as `image_url: type: string` unless the editor must manually type an external URL. Media field values are objects with `url`, `alt`, `sizes`, and attachment metadata; in Liquid, normalize them with `bb_media` or pass them to `bb-image`/`core-image` media props.
+
+Use `type: svg` for the SVG asset picker. Add `kind: icon` for the icon picker or `kind: shape` for the shape picker; `kind` defaults to `icon`. Do not use `type: icon`.
+
+Before authoring Liquid access paths, compare `fields.yaml`, `recipe.json`, and `seeds.json` handles. Repeater handles must match exactly. If the schema uses `subcollections.information`, do not loop over `subcollections.items`.
+
+## CLI Flow
+
+When the type is known, inspect shipped source-pattern metadata before creating files:
+
+```bash
+ddev wp bb template patterns --type=<type>
+```
+
+If a suitable variant exists, scaffold from it:
+
+```bash
+ddev wp bb template scaffold --slug=<slug> --type=<type> --variant=<variant>
+```
+
+This copies a whitelabel source pattern, compiles DSL to block JSON/AST artifacts, writes the runtime `template.liquid`, and creates the package contract files.
+
+If no pattern fits, start with the generic file scaffold:
+
+```bash
+ddev wp bb template scaffold --slug=<slug> --type=<type>
+```
+
+Then edit the generated files to match the user's request. Pattern variants are starting points, not final design decisions.
+
+Before database registration, run:
+
+```bash
+ddev wp bb doctor
+```
+
+If doctor reports missing BlockBite tables or columns, stop and report the exact missing tables/columns to the user. Do not add, remove, alter, or migrate database tables automatically.
+
+Treat SQL warnings plus a success message as failure until `wp bb doctor` passes and the target rows are verified.
+
+After writing files and passing doctor, use the site CLI from the WordPress project root:
+
+```bash
+ddev wp bb dynamic-template create --slug=<slug>
+ddev wp bb dynamic-content create --slug=<slug> --source-type=<block_instance|post_type|collection|single|hook> --fields=<template-or-source-folder>/fields.yaml
+ddev wp bb source import-seeds --slug=<slug> --file=<workspace>/templates/<slug>/seeds.json
+```
+
+For regular inserted sections, use `--source-type=block_instance --fields=<slug>/fields.yaml`.
+For a CPT-bound template or sidebar island, use `--source-type=post_type` and the CPT source schema, for example `--fields=work/fields.yaml` when the current `work` post is the source of truth.
+
+Use the absolute workspace seed path. Do not assume `wp-content/blockbite/...`; Bedrock projects usually use `web/app/blockbite/...`.
+
+If rows already exist, use `dynamic-template update` and `dynamic-content sync`. If existence is uncertain, prefer the command error over guessing: run create, and if it reports an existing slug, switch to update/sync.
+
+`wp bb dynamic-template package --slug=<slug>` exists, but it only generates `recipe.json`, `fields.yaml`, and `seeds.json` after `template.liquid` already exists. It is not a full package scaffold.
+
+When the template package lives in a nested folder or the registered slug does not match the filesystem view, register or repoint the full view path separately:
+
+```bash
+ddev wp bb dynamic-template path --slug=<slug> --view=templates/v1/<slug>/template.liquid
+```
+
+`dynamic-template path`, `dynamic-template create/update`, and `dynamic-content create/sync` are separate operations.
+
+For complex islands, inspect one real live payload before finalizing Liquid paths. Verify whether data is direct (`fields.client`, `subcollections.information`) or relation-nested (`fields.work.source.work.client`) and remove any stale preassigned `work_*` variables that duplicate direct bindings.
+
+## Alpine And CDN
+
+If the template needs interactivity, use Alpine attributes directly. For collapsible panels use:
+
+```html
+x-show="..." x-collapse x-cloak
+```
+
+Assume Alpine and configured CDN libraries are already loaded unless verification shows otherwise.
+
+For frontend runtime errors, open the current frontend page with
+`#blockbite-debug-panel`, inspect the Client JS chapter, and read
+`window.BlockBiteDebug?.errors` in the browser console before guessing from
+bundled stack traces.
+
+## Shared Styles Boundary
+
+Do not put template-specific styling or global `html`, `body`, `button`,
+`input`, typography, background, or reset rules in
+`<workspace>/app/styles-shared/*.css`.
+
+`app/styles-shared/shared.css` is bundled into `app.bundle.css` and loaded in
+block editor previews as well as the frontend. Use it only for intentionally
+shared, scoped component or template-family classes. Put frontend-only global
+page styles in `app/styles-app/app.css` or the theme stylesheet. Put island
+styles in `<workspace>/templates/<slug>/style.css`.
+
+## Shared Block Styles
+
+If the template needs a reusable visual variant for a block, especially `bb/button`, check `<workspace>/blocks/<namespace>/<block>` before inlining long Tailwind classes. Prefer the `block-style` skill/workflow for shared styles, then use the style from the template.
+
+## Finish
+
+Verify JSON files with `jq`, inspect generated files, run the relevant WP-CLI commands, and report template slug, template id, content id, and source import result.

package/skills/template-preview/SKILL.md

@@ -0,0 +1,115 @@
+---
+name: template-preview
+description: Create a seed-backed aggregate BlockBite dynamic-template preview package that renders multiple workspace templates in one Liquid view without creating a WordPress page or relying on separate blockbite_preview URLs.
+---
+
+# Template Preview
+
+Create or update an aggregate preview package for reviewing several dynamic templates together.
+
+Use this when the user wants a preview page with multiple created templates, a homepage-section stack, or a quick review surface that avoids assembling `bb/dynamic-template` blocks in WordPress content.
+
+If the preview source is a document blueprint, use the `document-blueprint` skill and the `bb_document_blueprint` filter instead of manually listing child templates.
+For BlockBite-specific Tailwind utilities such as `area-[...]`, `grid-area-[...]`, and `children:*`, read `../references/tailwind-utilities.md` when it exists.
+
+## Contract
+
+- Do not create or update a WordPress page for the preview.
+- Do not register the preview package as a dynamic-template row unless the user explicitly asks.
+- Prefer an aggregate preview package over separate `blockbite_preview` links for multi-section review.
+- Render each child template with seed data only.
+- Validate referenced template packages before handing over the preview view.
+
+## Preview Package
+
+Create the preview under:
+
+```text
+<workspace>/templates/preview-<slug>/
+```
+
+Required files:
+
+- `template.liquid`
+- `fields.yaml`
+- `seeds.json`
+- `recipe.json`
+- `manifest.json`
+- `style.css`
+- `module.ts`
+
+The metadata files can be minimal because preview content comes from referenced child templates:
+
+```yaml
+version: 1
+
+fields: {}
+subcollections: {}
+```
+
+```json
+{
+  "fields": {},
+  "subcollections": {}
+}
+```
+
+Use `template.liquid` as the aggregate view. Render child templates with the `bb_template_preview` filter so each child gets its own `seeds.json` context:
+
+```liquid
+<main class="min-h-screen bg-white text-neutral-950" data-bb-preview="home">
+  {{ 'templates/nav/template.liquid' | bb_template_preview | raw }}
+  {{ 'templates/home-hero/template.liquid' | bb_template_preview | raw }}
+  {{ 'templates/services/template.liquid' | bb_template_preview | raw }}
+  {{ 'templates/footer/template.liquid' | bb_template_preview | raw }}
+</main>
+```
+
+Do not use plain `{% render 'child/template.liquid' %}` for standard dynamic-template packages. It inherits the parent preview context, so `seeds.json | bb_seed` can resolve the preview package seed instead of the child template seed.
+
+For document blueprint previews, use the blueprint shortcut instead:
+
+```liquid
+<main class="bb-document-blueprint-preview" data-bb-document-blueprint-preview="design-to-production">
+  {{ "design-to-production" | bb_document_blueprint | raw }}
+</main>
+```
+
+This renders sections from `document-blueprints/<slug>/blueprint.json` with their blueprint seed files and does not write to WordPress content or dynamic content sources.
+
+## Workflow
+
+1. Resolve the template slugs and intended order from the chat or existing homepage/island notes.
+2. Confirm each referenced view exists, usually `templates/<slug>/template.liquid`.
+3. Run or request the normal workspace validation:
+
+   ```bash
+   ddev wp bb validate
+   ```
+
+4. Create or update `templates/preview-<slug>/template.liquid` with one `bb_template_preview` call per child.
+5. Keep preview-specific CSS minimal. Prefer Tailwind classes in `template.liquid`; use `style.css` only for preview-only framing or temporary diagnostics.
+6. If scripts or styles changed in child templates, follow the reported build mode and run the relevant build before visual review.
+
+## Preview View
+
+Use the file-backed view when a URL is needed:
+
+```text
+/?blockbite_preview=1&template=true&view=templates/preview-<slug>/template.liquid
+```
+
+If that route is unreliable in the current environment, still leave the aggregate package in place and report the view path:
+
+```text
+templates/preview-<slug>/template.liquid
+```
+
+## Finish
+
+Report:
+
+- preview package path
+- referenced template views in render order
+- validation/build commands run
+- any referenced templates that were missing or failed to render