Pipeline Steps Reference

Detailed technical and operational reference for every pipeline step.

Step Status Values

Every step is stored as one of four string values in the pipeline data file:

Value	Meaning	Display
not_started	Default state. Step has never been triggered.	Grey dot, step name as label
in_progress	Step is actively running. If the app crashes while a step is in_progress, it is reset to not_started on next startup.	Amber dot, pulsing label
complete	Step completed successfully. Timestamp recorded in step_times.	Green dot
failed	Step terminated with an error. Can be retried by clicking the step cell again.	Red dot

Step 1 — Demo

What it does: Uses AI (Claude Code CLI or Gemini CLI) to rebuild the downloaded original website into a modern static site (semantic HTML5 + vanilla CSS + GSAP animations; no SPA framework) stored in edited_sites/<slug>/.

Prerequisite: Site must have been downloaded successfully (WebCopy complete).

Process:

1. The app builds a prompt containing: original site file tree, content summary, any example sites in the same niche, and build instructions.
2. Prompt is written to data/temp/tmpXXXXXX.txt.
3. A new PowerShell terminal opens in edited_sites/<slug>/.
4. The CLI runs: claude --dangerously-skip-permissions --model <model> --effort <effort> $task
5. When the terminal closes (CLI exits), the step is automatically marked complete or failed based on exit code.

Output: A static site in edited_sites/<slug>/ (hand-written index.html and sub-pages, CSS, JS, and the copied media) plus a DESIGN_NOTES.md describing AI design decisions.

Model: Configurable per use-case in Settings → AI Model & Effort. Default: Sonnet 4.6, max effort. (Opus 4.7 is the default for Build from Scratch, not pipeline Demo.)

Step 2 — Copy Check 1

What it does: Scans images in the demo site using Google Lens to identify potential stock photos.

Prerequisite: Demo step complete. Built site must have image files.

Process:

1. Playwright launches a non-headless Chromium browser window.
2. For each image file in the site, it uploads the image to Google Lens and searches for visual matches.
3. The resulting page is scanned against a list of 30+ stock photo domain names (Shutterstock, Getty, iStock, etc.).
4. Images are classified into risk tiers: CRITICAL, HIGH, PASSIVE, or FREE_TRAP.

Output: A popup listing every flagged image with its risk tier and the matching stock site found.

Note: The Chromium window is visible on screen during the scan. Do not close it manually — the worker closes it when done.

Step 3 — Host Demo

What it does: Deploys the built site to Cloudflare Pages and attaches a custom subdomain.

Prerequisite: Demo step complete. Cloudflare API credentials configured in Settings.

Process:

1. Reads Cloudflare credentials from the Windows Registry.
2. Runs deploy-demo.ps1 -SiteName <slug> in a hidden PowerShell window.
3. The script creates a Cloudflare Pages project if one doesn't exist, runs wrangler pages deploy, and creates a CNAME DNS record for <slug>.demos.<domain>.
4. On success, the demo URL is saved to the pipeline entry and displayed as a clickable link.
5. Also scans for any .md files in the site folder. If found, each is AES-256-GCM encrypted and staged in data/encrypted-docs/, then deploy-docs.ps1 pushes them to the shared client-docs Cloudflare Pages project. The shareable link is a fragment URL: https://client-docs.demos.<domain>/#<uuid>:<key>.

Output: Live URL at https://<slug>.demos.<yourdomain>.

Timeout: 3 minutes. Fails if Wrangler does not complete within this window.

Step 4 — Cold Call

What it does: Uses AI to scrape the original business website and extract contact information.

Prerequisite: Any stage after site download. Does not require the demo to be built.

Process:

1. Runs claude -p "<prompt>" --model claude-sonnet-4-6 --effort low silently (no visible terminal).
2. Prompt instructs Claude to read the downloaded HTML files and return a JSON array of contact objects.
3. Each object has type (Phone / Email / Facebook / Instagram / etc.) and value fields.
4. If the JSON parse fails, a regex fallback extracts phone numbers and emails directly from the HTML.

Output: Contact popup with one-click copy buttons for each contact item.

Timeout: 3 minutes.

Step 5 — Form / Implement

What it does: Takes client feedback from a text file and feeds it back to the AI for revision.

Prerequisite: Demo step complete. Client has reviewed the demo and provided feedback.

Process:

1. A file picker opens. Select a .txt file containing the client's form response.
2. The file contents are prepended with an instruction: "Make changes to our website based on this form reply by the owner."
3. A new terminal opens in edited_sites/<slug>/ running the AI with the revision prompt.
4. When the terminal closes, a backup of the current site state is automatically created at Site Backups/<slug>/Edition N/.
5. The ITERATE cell unlocks and shows v1 — ready for a follow-up Reiterate if needed.
6. Copy Check 2 is reset to not_started so you re-scan after the revision.

Model: Configurable in Settings. Default: Sonnet 4.6, max effort.

Iterate (Reiterate)

What it does: Sends another round of revision instructions to the AI after Form completes. Not a formal pipeline step — it re-runs the same AI flow and increments the version counter on the ITERATE cell (v1, v2, …).

Process: Identical to Form — a file picker opens for a .txt file. The instruction prefix is "Make further changes based on this updated form reply." A backup is created on completion and Copy Check 2 resets.

Step 6 — Copy Check 2

Identical to Copy Check 1. Run after the Form step to verify no stock photos were introduced during revisions.

Step 7 — Final Hosting (Go Live)

What it does: Publishes the approved site to the client's real domain on Cloudflare — apex and www — as the permanent production host.

Prerequisite: The client's domain must already exist as a zone on your Cloudflare account, and Cloudflare credentials must be configured.

Process (FinalHostWorker → tools/host-final.ps1):

1. You enter the target apex domain (e.g. example.com) in the prompt.
2. The worker confirms that domain is a zone on your Cloudflare account. If it is not, it stops with a clear message — add the domain to Cloudflare first.
3. wrangler pages deploy uploads edited_sites/<slug>/ to a dedicated <slug>-live Pages project, kept separate from the demo project.
4. The apex and www hostnames are attached as custom domains and proxied CNAME records are created.
5. If the apex/www already has live records, the deploy refuses to overwrite them. Re-run the action (a second Publish click) to replace them with -Force — so you never silently take down a site that is still serving.
6. On success the final_url is saved and shown as a clickable link in the pipeline row.

Step 8 — Email (Contact Mailbox + DNS)

What it does: Provisions a contact@<domain> mailbox on Purelymail and writes the matching email DNS into the domain's Cloudflare zone, giving the client working email on their own domain.

Prerequisite: The domain must be a zone on your Cloudflare account, and PURELYMAIL_API_TOKEN must be set in Settings.

Process (EmailProvisionWorker):

1. You enter the apex domain in the prompt.
2. The domain is added to Purelymail if it isn't already, and the account ownership code is fetched.
3. The required records are written into the Cloudflare zone (idempotently): an MX to Purelymail, the SPF TXT, the ownership-proof TXT, three DKIM CNAMEs, and a managed DMARC CNAME.
4. The contact@<domain> mailbox is created with a generated password, shown once in a dialog and stored in the registry.

Related — client contact forms: the demo/final sites' contact forms post to a small Cloudflare Pages worker that relays submissions over Purelymail SMTP to this mailbox. See Deployment Infrastructure.

Step 9 — SEO (Goal Loop to 100%)

What it does: Audits the built site across four categories — Technical, Local SEO, AI/GEO readiness, and Performance — and can repeatedly run AI enhancement until every category scores 100%.

Process:

1. The SEO window audits edited_sites/<slug>/ with the app's own deterministic auditors (the same scoring used in the client report) and shows a colour-coded score chip per category.
2. Run AI Enhancement performs a single AI pass against the audit findings; Re-Audit then recomputes the scores.
3. Enhance to 100% (loop) automates that cycle: audit → AI-enhance the failing categories → re-audit → repeat until all four hit 100%, the iteration cap (SEO_MAX_ITERATIONS, default 5) is reached, or a pass makes no measurable progress.
4. The deterministic audit is the success check, so "complete" means the report genuinely reads 100 / 100 / 100 / 100 — not the AI's own estimate.

Note: the SEO window also generates and publishes the client-facing SEO report through the encrypted client-docs pipeline (see Deployment Infrastructure).