Proposal: Demo-Prospect Readiness Wiring into /ensure-solid

Date: 2026-05-20 Author: Demo Integrity Auditor (agent) Status: PROPOSAL — requires founder approval before editing cwa.yaml or registry.yaml

Context

/ensure-solid cwa currently has zero coverage of the scrape-and-demo cold-outreach flow. The four cold-outreach registry entries (cold-outreach-church, cold-outreach-director-transfer, cwa-preview-funeral, cwa-preview-vet) all have last_run: null and are absent from cwa.yaml's registry_filter.covers_tokens. The acceptance spec demo-prospect.md did not exist until 2026-05-20 (now at knowledge/acceptance/demo-prospect.md).

This is a critical gap: cold-outreach emails with /p/[token] links ARE being sent (10 sent, 1 clicked as of 2026-05-20), but /ensure-solid will not catch a broken demo flow.

Part A — Specific Wiring Changes Proposed for `knowledge/readiness/cwa.yaml`

A1. Add `demo-prospect.md` to `acceptance_specs`

acceptance_specs:
  # ... existing specs ...
  - demo-prospect.md     # ADD — cold-outreach prospect demo journey

A2. Add a `demo-prospect` critical journey

critical_journeys:
  # ... existing journeys ...
  - name: demo-prospect-church
    description: >
      Cold email received → /p/[token] click → /s/[slug] demo loads → chatbot answers
      with church-specific data → booking CTA reachable. Requires demo-prep score ≥ 80
      AND demo-verify PASS on structural + chat checks.
    registry_entry: cold-outreach-church
    spec: knowledge/acceptance/demo-prospect.md

  - name: demo-prospect-funeral
    description: >
      Funeral cold email → /p/[token] → /preview/[slug] with FuneralPreview template,
      booking CTA to /funeralwiseai/book. No chatbot on preview page (by design).
    registry_entry: cwa-preview-funeral
    spec: knowledge/acceptance/demo-prospect.md

  - name: demo-prospect-vet
    description: >
      Vet cold email → /p/[token] → /preview/[slug] with VetPreview template,
      booking CTA to /vetwiseai/book.
    registry_entry: cwa-preview-vet
    spec: knowledge/acceptance/demo-prospect.md

A3. Add cold-outreach entries to `registry_filter.covers_tokens`

registry_filter:
  covers_tokens:
    # ... existing tokens ...
    - acceptance/demo-prospect.md          # ADD
    - processes/cold-outreach-provision.md # ADD (if process doc exists)

A4. Add a `demo-prospect` property token to `registry_filter.property_tokens`

registry_filter:
  property_tokens: [cwa, churchwiseai, chatbot, voice, voice-agent, cold-outreach, demo-prospect]
  #                                                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ADD

A5. Add `demo-verify` command to `commands` block

commands:
  # ... existing commands ...
  demo_verify_go_tier: >
    cd C:/dev/churchwiseai-web &&
    node scripts/demo-verify/index.mjs urls --all-prospects --no-chat
  demo_prep_audit: >
    cd C:/dev/churchwiseai-web &&
    node scripts/demo-prep/index.mjs audit --all-prospects

Rationale for --no-chat on the batch command: Full chat scenarios take ~50 seconds per demo. 100 demos × 50s = 83 minutes batch time. The /ensure-solid scorecard should use --no-chat for structural checks in the batch, then run full chat scenarios only on the GO-tier cohort (the 11 with demo_prep_score ≥ 80) or on a random 5-demo sample.

Part B — Registry Changes Proposed for `knowledge/tests/registry.yaml`

Note: Do NOT edit registry.yaml directly without founder approval. These are proposals only.

B1. Flip `cwa-preview-funeral` and `cwa-preview-vet` to `critical_path: true`

Both are currently critical_path: false. Given that funeral/vet cold emails ARE going out (or will be), these should be elevated to critical_path once their Playwright specs are authored.

B2. Set `last_run` on `cold-outreach-church` after first green Playwright run

The spec file e2e/cold-outreach-church-e2e.spec.ts exists in the registry but has never been run (last_run: null). A demo-verify pass is not a substitute — the Playwright E2E spec must be executed against the deployed URL before this entry can be considered verified.

B3. Add `cold-outreach-church` to `registry_filter.covers_tokens` in `cwa.yaml`

Currently the entry exists in the registry with property: cwa but is NOT referenced in cwa.yaml's registry_filter. This means /ensure-solid does not check it.

Part C — Additional `/ensure-solid` Staleness Found

C1. CRITICAL — dim-6 monitoring SQL is schema-invalid (confirmed 2026-05-20 via Supabase MCP)

cwa.yaml monitoring section queries:

error_sources:
  - moderation_violations WHERE reviewed = false        # ← column `reviewed` does NOT exist
  - founder_action_items WHERE priority <= 1 ...        # ← priority is TEXT, not integer; `<= 1` fails
  - ops_errors WHERE severity IN ('P0','P1') AND resolved = false  # ← column `resolved` does NOT exist

Verified:

moderation_violations.reviewed — does NOT exist (0 rows in information_schema.columns)
founder_action_items.priority — is TEXT, not integer; priority <= 1 will throw a type error
ops_errors.resolved — does NOT exist (0 rows in information_schema.columns)

Impact: Any agent or CI step that executes these queries against Supabase will fail with a Postgres error. The monitoring dimension of /ensure-solid is effectively broken for cwa.yaml.

Proposed corrections (pending founder sign-off on actual column names):

error_sources:
  - founder_action_items WHERE status = 'open' AND priority IN ('P0', 'P1')
  - moderation_violations WHERE is_reviewed = false     # or whatever the real column is
  - ops_errors WHERE severity IN ('P0', 'P1') AND resolved_at IS NULL  # or real column

An agent must run SELECT column_name FROM information_schema.columns WHERE table_name IN ('moderation_violations', 'founder_action_items', 'ops_errors') to confirm real column names before correcting the YAML.

C2. Four `commands` entries are `null`

commands:
  docs: null
  analytics: null
  marketing: null
  agents: null

These four dimensions are listed as enabled (dimensions_enabled.docs: true, etc.) but have no command defined. /ensure-solid cannot score these dimensions. They should either get commands or be set to enabled: false until commands are authored.

C3. Registry entries with `last_run: null` flagged as critical

The following critical_path: true entries in the registry have never been run:

cold-outreach-church — last_run: null
cold-outreach-director-transfer — last_run: null, last_break: 2026-04-29
voice-live-call — last_run: null
pro-website-cancelled-tombstone — last_run: null
voice-routing-integration — last_run: null (but last_break: 2026-04-22)
multi-item-self-serve — last_run: null (Phase 7 live 2026-05-12)
multi-item-stripe — last_run: null (Phase 7 live 2026-05-12)

Seven of the current critical-path entries have no verified green run. This means the CI gate has no baseline to compare against. These are paper gates, not real ones.

C4. `cold-outreach-director-transfer` has an unresolved last_break (2026-04-29)

The registry notes: last_break: 2026-04-29 with notes about a WebRTC↔SIP architectural fix being needed. founder_verified: null. This entry is marked critical_path: true and has never been run successfully. It should either be fixed or downgraded to critical_path: false until the WebRTC↔SIP fix ships.

C5. `cwa.yaml` does not reference `demo-prospect.md` anywhere

As of this audit, the acceptance spec knowledge/acceptance/demo-prospect.md did not exist (created 2026-05-20 as a DRAFT). It is not yet wired into any readiness config or registry entry. The wiring proposals in Parts A and B above address this.

C6. SKILL.md click-through example uses truncated token

churchwiseai-web/.claude/skills/demo-verify/SKILL.md shows:

node scripts/demo-verify/index.mjs click-through --token <token>

The intent is that <token> is the full starter_kit_token. However, every example in the skill docs and knowledge handoffs uses a short prefix like sprint1-71bf6b91e0 — which is not the actual token and will produce a redirect-to-/pro-website FAIL.

Evidence (2026-05-20 test):

--token sprint1-71bf6b91e0 → FAIL (redirects to /pro-website, chatbot widget absent)
--token sprint1-71bf6b91e0c148f1bedc4ab1eaae0b5a-6a393fed780b862b → 11/11 PASS

The SKILL.md should be updated to warn that the full token is required and show an example query to retrieve it from outreach_contacts.

Part D — Recommended Priority Order

Priority	Action	Owner	Effort
P0	Fix dim-6 SQL queries in cwa.yaml (schema-invalid)	Agent	30 min
P0	Update SKILL.md click-through example to warn about full token	Agent	15 min
P1	Wire demo-prospect.md into cwa.yaml acceptance_specs + critical_journeys	Agent	30 min
P1	Add demo-verify command to cwa.yaml commands block	Agent	15 min
P1	Add cold-outreach entries to registry_filter.covers_tokens	Agent	15 min
P2	Author and run e2e/cold-outreach-church-e2e.spec.ts to get first last_run	Agent	2 hr
P2	Assign null commands (docs, analytics, marketing, agents)	Agent	1 hr
P2	Resolve cold-outreach-director-transfer last_break before funeral/vet campaign	Agent	TBD
P3	Elevate cwa-preview-funeral + cwa-preview-vet to critical_path: true	Agent	15 min

Campaign-Readiness Verdict (as of 2026-05-20)

Church vertical (Sprint 1 cohort — 100 prospects):

11 GO, 26 HOLD, 63 NO-GO
10 emails already sent (all GO-tier: score 80–100)
demo-verify PASS on all 3 tested GO-tier demos (17/17 checks, including chat scenarios)
click-through PASS on full token; FAIL on truncated token (documentation bug, not a code bug)
Systematic data gap: even GO-tier (score=100) demos have logo_url=null, featured_video_url=null, hero_slideshow_keys=null

Funeral vertical: 0 prospects provisioned. No /preview/[slug] demos exist yet. Vet vertical: 0 prospects provisioned. No /preview/[slug] demos exist yet.

Overall verdict: Church demos that have been sent (GO-tier) are structurally PASS. The critical risk is the 89 provisioned-but-not-sent prospects — 63% are NO-GO and must not be sent until enriched and re-audited. The /ensure-solid skill has no mechanism to enforce this gate. That is the gap this proposal closes.

Context​

Part A — Specific Wiring Changes Proposed for knowledge/readiness/cwa.yaml​

A1. Add demo-prospect.md to acceptance_specs​

A2. Add a demo-prospect critical journey​

A3. Add cold-outreach entries to registry_filter.covers_tokens​

A4. Add a demo-prospect property token to registry_filter.property_tokens​

A5. Add demo-verify command to commands block​

Part B — Registry Changes Proposed for knowledge/tests/registry.yaml​

B1. Flip cwa-preview-funeral and cwa-preview-vet to critical_path: true​

B2. Set last_run on cold-outreach-church after first green Playwright run​

B3. Add cold-outreach-church to registry_filter.covers_tokens in cwa.yaml​

Part C — Additional /ensure-solid Staleness Found​

C1. CRITICAL — dim-6 monitoring SQL is schema-invalid (confirmed 2026-05-20 via Supabase MCP)​

C2. Four commands entries are null​

C3. Registry entries with last_run: null flagged as critical​

C4. cold-outreach-director-transfer has an unresolved last_break (2026-04-29)​

C5. cwa.yaml does not reference demo-prospect.md anywhere​

C6. SKILL.md click-through example uses truncated token​

Part D — Recommended Priority Order​

Campaign-Readiness Verdict (as of 2026-05-20)​