docs(model-apps): answer 'what does this gain over verify' - and correct my own ranking

Challenged on why a probe adds anything when the SDK already verifies everything
is persisted to Dataverse. Checked, and the answer sharpened the design - partly
against it.

Every loop in verifySpec is or (const X of spec.Y): THE SPEC IS THE ORACLE.
So verify answers 'did we build what we were told', never 'were we told the right
thing'. If the spec is wrong, verify is green and the app is wrong. Roadmap #6 is
the proof case already in this repo: lifecycle authored as plain Choices, so a
Sold listing is still statecode=Active - the view exists, has the right columns
and a valid filter, verify passes, and it lists sold properties.

Two corrections to what I wrote yesterday, both against my own proposal:

1. Verify's role check is SHALLOW - it proves a role row exists with our marker,
   and never compares the role's privileges to the spec. That comparison is a
   plain metadata read: cheap, deterministic, no browser. It should land BEFORE
   any probe work, and it was missing from the design entirely.
2. My value ranking was wrong. Driving as the AUTHOR (an admin) cannot test
   privilege sufficiency, which is the one thing metadata can never reach. So
   persona-as-test-user is the core of rungs 2-3, not a deferred nicety, and
   admin-driven probing is the LOWEST-value rung rather than the payoff.

Also records the anti-case: anything verify already asserts is not worth a
browser. Precedent - the corrupt-app bug (ADO 6612527) was fixed by asserting
metadata harder, not by driving a browser.

Docs only. Plugin suite 1446 pass.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 42626da2-b66f-4162-acaa-b1127ef23d89

Author: akshay-viz

plugins/model-apps/docs/jtbd-probe-design.md

@@ -53,6 +53,49 @@ Note the last clause: validation is loose **on purpose**, because a surface may
 artifact this spec never authors. That is a real constraint, and it is why Rung 0 below resolves
 against the spec and reports a **warning** rather than tightening validation into an error.
 
+---
+
+## 3a. What verify already covers — and the one thing it structurally cannot
+
+Fair challenge to this whole note: **the SDK already verifies everything is persisted to Dataverse.**
+It does, and that is exactly where its limit is.
+
+Every loop in `verifySpec` is `for (const X of spec.Y)`. **The spec is the oracle.** So verify
+answers *"did we build what we were told?"* — it can never answer *"were we told the right thing?"*
+If the spec is wrong, verify is green and the app is wrong.
+
+Three classes it cannot catch, all evidenced from this repo's own roadmap:
+
+1. **The spec was semantically wrong.** Roadmap #6: lifecycle status was authored as plain Choices,
+   so a *Sold* listing still has `statecode = Active`. The "Active Listings" view exists ✅, has the
+   right columns ✅, carries a valid filter ✅ — verify passes. The view lists sold properties. A
+   human found that by opening it.
+2. **Declared privileges are insufficient.** The schema is explicit that *"the builder never infers
+   privileges from a job's text"* — a human declares them. Verify then checks that a role **row
+   exists** carrying the SDK marker. Whether that declared set is *enough to finish the job* is not
+   knowable from the spec, because the spec is what is being questioned.
+3. **Runtime-only failures.** Roadmap #4 concedes the generated `.tsx` is *"only structurally
+   grep-checked; the user never sees the page (they hit the double-render live)."*
+
+**One line:** verify proves the *build* is faithful; a probe proves the *plan* was right. Today
+nothing tests the plan — and the plan is authored by an LLM from a sentence.
+
+## 3b. What a probe does NOT gain (and what to do instead)
+
+Recorded because it changes the sequencing below, and because the cheaper option should win:
+
+- **Anything verify already asserts is not worth a browser.** Artifact existence, view column sets,
+  icons, sitemap wiring, AI override rows — metadata assertions are fast, deterministic and cheap;
+  browser probes are slow and flaky. Precedent: the corrupt-app bug (ADO 6612527) was fixed by
+  asserting **metadata harder** (reading components back), not by driving a browser.
+- **Verify's `role` check is currently shallow — fix that first.** It proves the role *exists* with
+  our marker; it does not compare the role's actual privileges against the spec. That comparison is
+  a plain metadata read: cheap, deterministic, no browser, and it should land **before** any probe
+  work. It is not one of the rungs below because it is not a probe — but it is the first thing to do.
+- **Driving as an admin does not test authorization.** See §6b: it proves reachability only. If
+  privilege sufficiency is the top prize, a test user per persona is the *core* of rungs 2–3, not a
+  deferred nicety.
+
 That means the first increment is not browser automation at all. It is **resolution** — and it is
 pure, offline, and independently valuable.
 
@@ -190,13 +233,18 @@ persona; `full` = every job.
 
 ## 7. Suggested sequence
 
-| Step | Needs a live org? | Value if the next step never happens |
+Corrected after §3b: the cheapest high-value item is **not** a probe at all, and driving as an admin
+is the *lowest*-value rung rather than the payoff.
+
+| Step | Needs a live org? | Why here |
 |---|---|---|
+| **Deepen verify's `role` check** — compare actual privileges to the spec | yes, cheap | pure metadata, no browser; closes a real gap today |
 | Verify the deep-link forms (§6c) | yes, brief | unblocks Rung 1 |
 | Prototype unattended browser auth (§6a) | yes | decides whether Rungs 2–3 are viable at all |
 | **Rung 0** — resolve surfaces | **no** | closes the static half of the spec's Category 2 eval |
 | **Rung 1** — route | **no** | deep links usable by humans and docs immediately |
-| **Rung 2–3** — drive + assert | yes | the offline loop closes |
+| **Rungs 2–3 driven as a persona test user** | yes | the top prize: proves the declared privileges are *sufficient* |
+| Rungs 2–3 driven as the author (admin) | yes | lowest value — catches semantic/render bugs only, most flake |
 
 Rungs 0 and 1 are worth doing regardless of how (a) resolves, which is why they are sequenced to not
 depend on it.