# The Approval View (schema §5A) — render spec + template

STATUS: v1, 2026-06-15. Owner: atlas. The required render: the v1 deliverable is a human approving a plan, so this is what they see. Two explicit, ordered checklists.

## Rules
- **List 1 — "GHL Command will do automatically (once you approve)."** Every creatable object in the plan, grouped and counted, each line in plain English. These are what phase-2 `apply_build_plan` will stage in one shot.
- **List 2 — "You must do manually, in this order."** Every `handoffs[]` item, topologically ordered by dependency (`blocks`), each with owner (YOU-UI / YOU-EXT / TEAM), the instruction, the success check, and where it sits in the flow.
- The approver can **edit either list** before approving (rename, drop, reorder, adjust). The skill re-renders after edits.
- Nothing is built until the operator approves. Say so explicitly at the bottom, and say what happens next: a dry run that writes nothing, then the live build on their go.
- Operator voice. No em-dashes, no hype. Counts are exact (derived from the plan, never asserted loosely).
- Owner labels render as **YOU-UI** (in the GHL UI), **YOU-EXT** (external: carrier, Stripe), and **TEAM** (a team member) — the subscriber is "you" in their own account. The plan's `handoffs[].owner` field carries the canonical `OPERATOR-UI` / `OPERATOR-EXT` / `TEAM` enum; this render humanizes them. (The legacy `JERRY-UI`/`JERRY-EXT`/`SASHA` are deprecated — accepted + normalized by the MCP for back-compat, never emitted.)

## Ordering List 2
Topologically sort handoffs by their `blocks` edges and the objects they `produces`. A handoff that produces a custom value another step needs comes first. Ties break by: account-access steps (add staff) → integrations (Stripe, calendar, email) → compliance (A2P site → A2P brand/campaign) → operational (warming, list import). Each line states what it unblocks ("before any SMS can send").

## Template

```markdown
# Build Plan — <business.name>
<one-paragraph summary from plan.summary>

Generated from the **<presetTitle>** preset (v<presetVersion>) · brief source: <briefSource> · schema v<schemaVersion>.
This is a plan for your review. Nothing is built yet. Edit anything below, then approve.

---

## 1. GHL Command will build this automatically (once you approve)

**Pipeline**
- Build pipeline "<name>" with <n> stages: <stage names>.

**Custom fields (<n>)**
- <Field name> (<type>)
- ...

**Tags (<n>)**
- <bucket>: <tag names>
- ...

**Custom values (<n>)**
- <name> <(filled after <handoff>)>

**Calendar**
- <name> (<type>, <hours>) <requires a staff member — see step N below>

**Form**
- "<name>": <fields>, with <custom field> mapped.

**Funnel**
- "<name>": <page roles + what each feeds>. <For target:"ghl" (default): built inside GHL.>
- <For target:"external" — render the power-user path:> "<name>" — **external site you host on <host>** <at <domain>>, wired back to this GHL sub-account. **Not built in GHL.** You host it; you own the domain, the host secret, and uptime; a re-run never silently overwrites a live deployment. See step N below (you must own a host account + deploy it).

**Email + SMS assets**
- <n> emails: <names>
- <n> SMS: <names>  <(will not send until A2P is approved — step N)>

**Workflows (<n>)**
- "<name>" — <trigger> → <plain-English action summary> <(stops on reply)>
- ...

_Total: <X> objects across <Y> types._

---

## 2. You must do these yourself, in this order

1. **<title>** — **YOU-UI / YOU-EXT**
   - What: <instruction>
   - Why now: <what it unblocks, e.g. "the calendar can't be assigned until this">
   - Done when: <successCheck>
2. ...

---

_Nothing has been built yet. When you approve, the automatic list is staged for you: a dry run first, which writes nothing and reports exactly what it would create, then the live build on your go. Each step above is verified before the steps that depend on it run._
```

## Render notes
- Workflows: summarize actions in plain English, not raw action JSON. Mark `stopOnResponse` as "(stops on reply)".
- SMS lines and email lines that are blocked by a handoff get an inline "(will not send until step N)" so the approver sees the dependency without reading List 2.
- If the skill pruned items (a `conditionalOn` was false), do not list them; optionally add a one-line "Not included (not needed for this build): <X>" so the approver knows it was a deliberate choice, not an omission.
- Keep List 1 grouped and counted exactly as the plan contains; the counts are the headline ("a full pipeline, 6 fields, 14 tags, a calendar, a form, a funnel, 5 workflows" — the Module 7 recap energy, but honest).
- **External funnels (target:"external"):** add to List 2 the user-owned steps this path creates (these are not plan `handoffs[]` but belong in the manual list): (1) "Confirm you own a host account (Cloudflare/Vercel) + CLI and can run a one-time deploy" — the capability gate; (2) "Set your GHL Private Integration token as a host secret (`wrangler secret put GHL_PIT`)" — you hold the key, never the product; (3) "Deploy the site to a preview URL, confirm it, then promote to your production domain"; (4) "Verify on the live branded URL before it takes real traffic (the skill runs `verify_funnel` + you do one real submit + one burner booking)." Full detail: `references/external-funnel.md`. Ownership facts (host/domain/secret owner = you; re-run never clobbers live) render inline on the funnel line in List 1.