Go-Live Readiness System

What this is

A conductor layer on top of existing QA, test, drift, and monitoring infrastructure. Lets the founder (or any agent) invoke:

/ensure-solid <property>

…and get back a single go-live scorecard — a 9-dimension audit of whether a property is ready for marketing push.

This system does not implement new tests. It invokes existing skills (qa-orchestrator, journey-runner, test-chatbot, test-voice), existing scripts (check-api-drift.sh, pnpm derive --check), existing SQL checks (validate_product_knowledge()), and existing CI gates (critical-path-gate.yml), collects the results, and produces a scorecard.

The 9 Readiness Dimensions

#	Dimension	What "solid" means
1	User journeys	Every acceptance-spec journey passes end-to-end for each persona
2	Viewports	All feature tests green on desktop (1280×720), tablet (iPad Mini), mobile (iPhone 12)
3	Knowledge accuracy	pricing.ts, product_knowledge, marketing copy match canonical YAML source of truth
4	Onboarding / billing / UI	Signup → Stripe → magic link → dashboard → tier gating all verified
5	User docs (help)	Customer-facing help surface exists, is accurate, and is up to date
6	Drift & issues tracked	Unresolved P0/P1 founder_action_items count = 0; moderation_violations reviewed within SLA
7	Analytics in founder dashboard	Per-property KPIs render in /founder/[token] (MRR, active customers, conversion)
8	Marketing funnels	Landing → pricing → checkout tested end-to-end; MailerLite campaigns wired
9	Claude agent monitoring	Active worktrees visible, no resource conflicts in ACTIVE_WORK.md

Files

readiness/
├── README.md               ← this file
├── cwa.yaml                ← ChurchWiseAI core (voice + chatbot)
├── pewsearch.yaml          ← PewSearch directory + Premium Page
├── itw.yaml                ← IllustrateTheWord
├── sermonwise.yaml         ← SermonWise AI (hostname rewrite on CWA)
├── sharewise.yaml          ← ShareWiseAI (status: coming_soon)
├── pro-website.yaml        ← Pro Website ($19.95/mo standalone)
└── reports/                ← Scorecard outputs (both .md and .json)
    └── <property>-<YYYYMMDD-HHMM>.{md,json}

How to read a per-property YAML

Each property YAML describes which existing tooling the orchestrator should invoke for that property. The skill does not guess — it reads the YAML and executes what's declared.

• registry_filter — which knowledge/tests/registry.yaml entries apply to this property
• commands — exact shell invocations for each dimension (fully qualified paths, deterministic)
• dimensions_enabled — per-dimension switch. Set false for dimensions that don't apply (e.g., viewports: false for a pure API product)
• status: coming_soon — orchestrator returns "N/A — coming soon" for all dimensions instead of trying to test what doesn't exist yet

How the orchestrator works

/ensure-solid <property>
   │
   ├─1. Read readiness/<property>.yaml
   ├─2. For each enabled dimension, run the declared command (parallel where independent)
   ├─3. Collect structured results
   ├─4. Self-heal bounded fixes (rerun `pnpm derive` if drift detected, update registry `last_run` stamps)
   ├─5. Write scorecard → readiness/reports/<property>-<ts>.md (+ .json twin)
   ├─6. Append P0/P1 findings → FOUNDER_ACTIONS.md with `[auto:ensure-solid]` tag
   └─7. Print one-screen summary with overall % and top 5 punch-list items

How the dashboard reads scorecards

/founder/[token] has a Readiness tab that reads the latest .json scorecard per property (via /api/founder/readiness/[property]) and renders status chips + punch-list items + active-worktree list from ACTIVE_WORK.md.

Rules for the orchestrator

MAY automatically:

• Rerun pnpm derive if derive --check fails
• Stamp last_run / last_break in registry.yaml
• Refresh stale materialized views
• Regenerate docs/api-catalog.md on pure-doc drift
• Regenerate PDFs via pnpm generate-pdfs

MUST NOT automatically:

• Modify Stripe products, prices, coupons
• Alter database schema
• Push to main/master or any deploy branch
• Touch voice agent (voice-agent-livekit/, lk.exe agent deploy)
• Modify files listed under a critical_path: true registry entry unless the designated Playwright spec has been re-run green in this same invocation

Extending to a new property

1. Create readiness/<property>.yaml — copy pro-website.yaml as template
2. Ensure knowledge/tests/registry.yaml entries have the matching property: field
3. Ensure at least one acceptance/ spec exists for the property
4. Run /ensure-solid <property> — first run will reveal gaps to fill

Related

• Skill: C:/dev/churchwiseai-web/.claude/skills/ensure-solid/SKILL.md
• Registry: knowledge/tests/registry.yaml
• Acceptance specs: knowledge/acceptance/
• SOT check wrapper: knowledge/scripts/readiness-sot-check.ts
• Active work manifest: C:/dev/ACTIVE_WORK.md
• Founder action items: C:/dev/FOUNDER_ACTIONS.md