---
name: generated-page-qa
description: QA and fix large batches of generated or semi-internal web pages until they read as real customer-facing, owner-reviewable websites with proof-backed local verification.
triggers:
  - generated page batch
  - owner-reviewable websites
  - customer-facing copy QA
  - forbidden phrase scan
  - local page crawl
  - screenshot proof
  - noindex/noarchive batch QA
---

# Generated Page QA

Use this when turning many generated/prospect/demo pages into customer-facing websites, especially when the user cares about proof, local QA, screenshots, no internal language, and deployment gating.

## Contract

Before saying the batch is done:

- Shared templates/components are fixed before one-off page copy.
- Pages read like real business websites, not audits, strategy notes, AI demos, proof ledgers, campaign pages, or internal sales docs.
- Weak-source details stay in proof artifacts, not visible customer copy.
- Every page has local verification for HTTP status, noindex/noarchive, metadata, schema where practical, CTAs, owner verification note, and forbidden/internal language.
- Representative desktop and mobile screenshots are captured and inspected.
- After the last patch, the full crawl is rerun. Never claim a final `100/100` from a pre-final QA run.
- Deploy/publish remains approval-gated when the user asks for local QA first.

## Workflow

1. **Identify shared causes first.** Inspect the route template, reusable components, layout wrappers, schema/metadata, and data mapping/sanitizer logic before editing individual pages.
2. **Patch global customer-facing foundations.** Fix hero contrast, card text inheritance, CTA readability, mobile layout, owner verification note, metadata, schema, and global copy cleanup.
3. **Move internal material out of the body.** Keep source notes, weak-fit notes, research/proof language, and campaign/outreach logic in proof artifacts or QA reports, not page body copy.
4. **Patch data only after the template pass.** If screenshots or crawls show specific bad visible text, patch source data or sanitizer rules for that language class.
5. **Build locally.** Run the project build before treating the crawl as meaningful.
6. **Run a full local crawl.** Check every route for status, robots/noarchive, metadata, schema, owner note, CTA presence, and forbidden/internal phrases.
7. **Capture screenshots.** Use representative desktop and mobile screenshots, including weak-source pages, recently failed pages, and at least one polished/control page.
8. **Visually inspect screenshots.** Look for readable contrast, no horizontal overflow, usable CTAs, and whether the copy sounds like a business website.
9. **Expand the scan list from visual findings.** Add newly discovered bad-language classes such as doubled sanitizer words, `source note`, `research pass`, `outreach`, `automation`, `proof`, `demo`, `campaign`, `AIBB`, or CTA labels that are internal.
10. **Rerun after final patch.** The final reported pass must come after the last code/data change.

## Forbidden visible language classes

Scan exact user-provided forbidden phrases plus broader classes:

- AI/demo/proof terms: `AI-built`, `demo`, `proof`, `public proof`, `AIBB`, `Hermes`.
- Campaign/outreach terms: `postcard`, `QR campaign`, `campaign`, `outreach`, `recipient`, `mail was sent`, `spend`.
- Internal QA/research terms: `audit`, `internal strategy`, `source notes`, `weak-source`, `research pass`, `proof ledger`.
- Template/process terms: `the page should`, `the site should`, `launch version`, `owner-safe`, `customer path`, `client journey`, `booking journey`.
- Sanitizer artifacts: doubled words like `the the`, awkward substitutions like `private the website team page`, or CTAs like `Verify Before Outreach`.

## Screenshot QA cues

A page can pass text scans and still fail. Reject or patch if screenshots show:

- Hero text over an image without a strong enough overlay or solid panel.
- Light cards inheriting white text or dark cards inheriting dark text.
- CTAs that say internal actions instead of customer actions.
- Copy that talks to Sam/the operator instead of the business’s customers.
- Source confidence caveats presented as marketing copy instead of a small owner-verification note.
- Mobile layout with cramped CTAs, horizontal overflow, or buried phone/directions actions.

## Reporting format

```text
Done:
- ...

Proof:
- Build: <command/result>
- Crawl: <count passed/failed and artifact path>
- Screenshots: <artifact path and count>
- Screenshot QA: <representative verdict>

Blocked:
- ...

Need approval:
- Deploy/publish? <yes/no, explicit ask>
```

## Pitfalls

- Do not approve a batch because one crawl passed before the final patch.
- Do not let sanitizer substitutions create unnatural customer copy.
- Do not leave weak-source/research/proof notes in visible body text.
- Do not deploy/publish without explicit approval when the requested scope is local QA.
- Do not let source-specific proof artifacts become customer-facing content.