# Phase 0.0 — Guided start: the first thing you run

**Read this before anything else when a user invokes the skill.** It turns a 40-page playbook into a
conversation. Its job is to work out *where the user actually is*, ask only what changes the build,
and then get out of the way.

`00-operator-profile.md` is the **content** of the intake — the questions and why each one matters.
This file is the **choreography**: order, branching, batching, and what to detect instead of ask.

---

## Rule 1 — Detect before you ask

Never open with a questionnaire. Spend thirty seconds establishing the starting state, then ask only
what you could not determine. Nothing here changes anything.

```powershell
# Is there already a decision record from a previous run?
Test-Path "$env:USERPROFILE\.caldova-demo-profile.json"

# Is a Caldova auth profile already present?  (the * marks the active one)
pac auth list

# Which environments exist for that tenant?
pac env list
```

And if a Dataverse/Web API session is available, one call tells you how far a build already got:

```js
// counts across the whole demo surface — run in the org, F12 console or MCP
for (const s of ['leads','opportunities','incidents','msdyn_workorders','quotes',
                 'knowledgearticles','msdyn_liveworkstreams']) {
  const r = await fetch(`/api/data/v9.2/${s}?$count=true&$top=1`,{headers:{Accept:'application/json'}});
  console.log(s, r.ok ? (await r.json())['@odata.count'] : r.status);
}
```

Map the result to a branch:

| What you find | Branch |
|---|---|
| No auth profile, no tenant | **A — Claim a tenant** (start at the very beginning) |
| Auth profile exists, org empty | **B — Fresh build** (skip claiming, go to intake) |
| Org has records | **C — Resume** (summarise what exists, ask what is next) |
| Decision record exists | **D — Reuse** (confirm it still applies, do not re-interview) |

> **Say what you found before you ask anything.** "You've got a Caldova tenant with 421 leads and
> 133 opportunities already, so I'll skip the claiming steps" earns more trust than a cold list of
> thirteen questions.

---

## Rule 2 — Ask in themed batches, never all at once

Thirteen questions in one wall is a form, not a conversation, and people abandon forms. Group them
so each batch is one decision the user actually holds in their head.

In Microsoft Scout use `m_ask_user`. It takes **2–5 options**, so offer sensible presets with an
escape hatch rather than free text wherever you can — and put the reasoning in the message *before*
the call, never inside the question.

### Batch 1 — Who you sell to *(free text, one message)*

Ask together, because they are one thought:

> *"To make the demo data land, tell me: your industry (specific enough to name products — 'grocery
> and convenience retail', not 'retail'), your territory and segment, six to ten named accounts, and
> the roles you demo to."*

Then state the privacy default rather than asking an open question:

> **"I'll build fictional company names modelled on those accounts. A demo tenant carrying real
> account names shows Customer B's pipeline to Customer A the moment you present it. Say the word if
> you'd rather use real names."**

### Batch 2 — Which workloads *(multi-select)*

Lead with the cost, because two of these are genuinely expensive:

| Workload | Cost |
|---|---|
| D365 Sales | ~30 min |
| D365 Customer Service | ~20 min |
| Field Service | ~30 min, strict build order |
| Customer Insights – Journeys | **~3 h install** |
| Customer Insights – Data | **~14 h install, IRREVERSIBLE** |
| Finance & Operations | **~3 h 41 m, separate environment** |

> ⚠️ **CI – Data and F&O need an explicit, separate yes.** CI – Data cannot be cancelled mid-install.
> Do not let them ride along inside a multi-select the user skimmed. Confirm them on their own.

Offer a sensible default so a user with no strong view can move: **Sales + Customer Service** covers
most demos and finishes inside an hour.

### Batch 3 — Data depth *(single select)*

| Tier | Leads / Opps / Cases / WOs | Use when |
|---|---|---|
| Light | 60 / 40 / 30 / 20 | Quick screenshots |
| **Standard** *(default)* | 200 / 100 / 60 / 40 | Normal demoing |
| Deep | 420 / 130 / 120 / 80 | Predictive scoring, analytics |

Say the constraint out loud: **predictive scoring will not train on Light.**

### Batch 4 — The gated decisions

These three interrupt a long unattended run if you leave them until you reach them:

1. **Sales Premium trial** — predictive scoring sits behind a **terms acceptance** and ~1 h
   provisioning. *"Do you authorise accepting the Sales Premium trial terms on this tenant?"*
   **Never tick that box without an explicit yes — it is a licensing decision, not configuration.**
2. **Live email sends** — inert (nothing can send) or wired to your own mailbox for real open/click
   telemetry. Live needs plus-addressing, an inbox rule, and the org's verified sending domain.
3. **Journey shape** — single send, or branching (send → wait → conditional follow-up). Branching
   demos better; the branch only materialises after the wait elapses.

### Batch 5 — How to behave while it runs

1. **Recovery policy** — pre-authorise the common failure: *"If the F&O template deploys empty (a
   known silent failure), should I delete and redeploy automatically, or stop and report?"*
2. **Notifications** — Teams ping / email / nothing; on every milestone or only when blocked.

### Batch 6 — Sign-ins, batched into one sitting

Ask for the **admin UPN only** (`admin@<your-tenant>.onmicrosoft.com`, from CDX → My Dashboard →
Credentials). 🔒 **Never ask for, store, echo or write a password.**

Then have them complete every interactive sign-in in one go, before the build starts:

- `pac auth create --name caldova` → verify with `pac auth list`
- Browser: M365 admin portal, Power Platform admin center, Customer Insights portal
- **The F&O client** — forces a fresh password prompt even with a live session and **cannot be
  automated**
- Later, once the BYOT subscription lands: `az login --tenant <demo-tenant-id>`

> This single step removes the most common mid-build stall: a four-hour run pausing on a password box
> at 2am.

---

## Rule 3 — Branch A: no tenant yet

Only walk this when detection found nothing. Full detail in `00-claim-tenant.md`; the guided version
is four beats:

1. **Check for a free slot first.** Claiming fails late and unhelpfully if the user is at their
   tenant limit. Send them to CDX → My Dashboard before anything else.
2. **Claim the Caldova experience.** Then say the thing that saves a support ticket:
   > **"The launcher is not a progress bar. It can spin for 15–30 minutes after the tenant already
   > exists. Check My Dashboard, not the spinner."**
3. **Request a NET NEW Azure subscription** via MCAPS BYOT. Sequential, not parallel — the tenant
   must exist first. It gates Chapters 2 & 3, and it has real lead time, so file it early even if
   they think they will not need it.
4. **Collect credentials** from the tenant row and move to Batch 6.

While the tenant provisions, **run the intake** — it needs no tenant and turns dead waiting time into
progress.

---

## Rule 4 — Confirm the plan once, then run

Before starting, play the whole thing back as one summary and get a single approval:

```
CALDOVA BUILD PLAN
Industry      : specialty coffee retail        Segment : upper majors, UK&I
Accounts      : 8 archetypes (fictional names, modelled on your list)
Workloads     : Sales, Customer Service, Field Service
Data depth    : Standard  (200 leads / 100 opps / 60 cases / 40 work orders)
Sales Premium : YES - authorised to accept trial terms
Email         : live sends to you+demo@… , branching journey
Recovery      : auto-redeploy F&O on empty template
Notify        : Teams, on blockers only
Est. duration : ~2 h unattended, plus ~3 h if CI-Journeys is added later
```

Then state the operating contract plainly:

> **"From here I'll work unattended. I'll only interrupt for three things: an interactive password
> prompt, a destructive or commercial action you haven't pre-authorised, or a genuine dead end after
> I've finished everything not blocked by it."**

---

## Rule 5 — Write the decision record immediately

Persist it **before** the first build step, so a crash, a context reset or a new session does not
re-interview the user. `~/.caldova-demo-profile.json` works:

```jsonc
{
  "createdOn": "2026-09-01",
  "tenant":    { "adminUpn": "admin@<your-tenant>.onmicrosoft.com", "orgUrl": "https://<your-org>.crm.dynamics.com" },
  "narrative": { "industry": "…", "segment": "…", "accounts": ["…"], "audience": ["…"],
                 "useFictionalNames": true },
  "scope":     { "workloads": ["sales","customerService","fieldService"], "dataDepth": "standard" },
  "gated":     { "salesPremiumAuthorised": true, "emailMode": "live",
                 "liveSendAddress": "you+demo@…", "journeyShape": "branching" },
  "operating": { "recoveryPolicy": "auto-redeploy", "notify": "teams-blockers-only" }
}
```

**Never write a password into it.** Re-read it at the start of every later session and confirm rather
than re-ask: *"Still specialty coffee retail, upper majors UK&I?"*

---

## Rule 6 — Do not ask what you should decide

The point of a guided start is to remove decisions, not relay them. Choose the default and say what
you chose:

| Do not ask | Just do it, and say so |
|---|---|
| "What should I name the queues?" | Name them after their function and mention it |
| "Which products should I create?" | Derive from the industry answer; show the list once |
| "Should I verify after each step?" | Always verify; that is the whole point of this skill |
| "Shall I check licensing first?" | Yes, always — it is thirty seconds |
| "Real or fictional company names?" | Default fictional, state the reason, allow an override |

Reserve questions for things that are **irreversible, chargeable, or genuinely a matter of taste.**