Appearance
Dealership Vendor Journey, round 1: the ten SPECIFIC steps
Reviewed 2026-08-24 against
prototype/mobile-console/vendor-core.jsand the renderedprototype/vendor-journeys/dealership.dc.html, fetched rather than read from the screenshot. Applies the inverted gate from core vs industry-specific capabilities.
✅ What round 1 got right, and it is the important part
🧮 The verdict mechanism works and it fired honestly. 25 steps · 3 shared · 12 configured · 10 specific · 25 no-screen · 0/25 parity (⚠ the last two figures are WRONG, see §2) — and the page raised its own warning: "10 steps are specific, which is more than two and therefore a warning: the widget and capability model is carrying too little."
🔎 A build that reports its own bad news is worth more than one that looks finished. Two things deserve credit: parity is counted per persona rather than as one number for the product, and vendor-core.js's own comment frames the classification correctly —
"
reuseis a declaration of INTENT … and every SPECIFIC one is a claim that the shared model cannot carry it, which is exactly the claim worth arguing with in a later round."
This page is that argument.
⚠ The verdict: ZERO of the ten are genuinely industry-specific capabilities
And the finding is not ten separate misjudgements. It is TWO systematic errors, which is a much cheaper thing to fix:
| Error | Steps | Count | |
|---|---|---|---|
| A | ⚠ ENTERPRISE SCOPE mistaken for INDUSTRY. These are org/subtree capabilities that any multi-outlet tenant needs. They read as dealership-specific only because the dealership is the first tenant to need them | 1 · 3 · 4 · 7 · 17 · 22 · 23 · 25 | 8 |
| B | ⚠ ABSENT SUBSTRATE mistaken for SPECIFICITY. Core walk-in capabilities that simply have no tables yet. "Nothing exists for this" is not "only this industry wants it" | 8 · 9 | 2 |
🔎 Error A is hazard §3.1 of the classification page, occurring in the wild within hours of being written down. "Ask at what SCOPE before asking for which INDUSTRY."
1 · The ten, argued individually
| # | Step | Design's claim | My verdict |
|---|---|---|---|
| 1 | org-onboarding | "existing onboarding creates ONE business; this creates an organisation that holds a tree" | 🟢 CORE, enterprise scope. True and not dealership-shaped. A salon chain, clinic group or franchise needs the identical intake. 🧮 CLAUDE.md already logs "no write path to organizations anywhere in the product" as a platform gap |
| 3 | outlet-setup | "an OUTLET runs its own P&L and is what a plan is priced per; a LOCATION is only an address" | 🟢 CORE. ⚠ That is verbatim ADR-0022's own definition of workspace-vs-location. The step is create a child workspace. Nothing about it is automotive |
| 4 | people-cards | "the card follows the TARGET, not the title" | 🟢 CORE, enterprise scope. Member-card issuance plus seat accounting serves every org_owned tenant. Target not title is a policy, not a vertical. ⚠ Blocked on D1 — setu_cards has no user column at all |
| 7 | standees | "the best adoption mechanic in the product… a QR that merely opens the card is printing" | 🟢 CORE, and the clearest miss of the ten. ⚠ A Ganapati stall wants a standee MORE than a dealership does — same direction as Google Business. What makes it worth ₹225 is the placement-attributed, reassignable touchpoint, and 🧮 CLAUDE.md already tracks the missing QR placement registry as QRS-576, a platform gap |
| 8 | log-visitor | "a walk-in written in a notebook is invisible by the afternoon" | 🟢 CORE (Party + a visit event). Clinic, salon, boutique, gym. The insight is excellent and the scoping is wrong |
| 9 | visitor-queue | (no note) | 🟢 CORE. A queue over visits with a duration threshold |
| 17 | my-performance | "the fix is not a leaderboard: it is the person seeing their own causal chain" | 🟢 CORE (Targets, subtree-scoped). ✅ The product insight is the best sentence in the file and I would keep it verbatim. The metrics are industry config; the capability is not |
| 22 | campaigns | "~14 lakh a year per outlet goes on advertising, so the comparison is against that spend" | 🟢 CORE, org scope. ADR-0025 already models central-publish + subtree-target; ADR-0029/0030 model WhatsApp. 🔎 The ₹14 lakh figure is a commercial argument for the dealership, not a technical distinction |
| 23 | group-overview | "oversight flows UP and is READ ONLY… no OEM-facing view of dealer discount, ever" | 🟡 SPLIT — two things in one step. The oversight rollup is CORE (ADR-0024). ⚠ The OEM restriction is the ONE genuinely industry-specific item in the whole vertical — and it is a compliance_profile, not a capability. Separating them is the fix |
| 25 | audit-log | (no note) | 🟢 CORE, and already BUILT. 🧮 public.audit_log shipped 2026-08-08 with actor_user_id ON DELETE SET NULL and a denormalised actor_role. Classifying the most-built thing on the list as industry-specific is the plainest error here |
2 · ⚠⚠ The bigger finding: 0/25 parity and 25 no screen are both WRONG
🧮 Measured by fetching the project's own file list and every step's href, not read off the page: all 25 steps carry href: null and desktopHref: null — set by a blanket rule, on the stated grounds that "no dealership screen exists yet, on either surface."
⚠ But screens that serve those steps DO exist, on both surfaces:
| Step | reuse | Mobile | Desktop |
|---|---|---|---|
12 conversations | shared | mobile-console/Messages.dc.html | desktop-console/Messages.dc.html |
6 vehicle-catalogue | configured | Catalogue.dc.html | Catalogue.dc.html |
11 my-card | configured | CardEditor.dc.html | CardEditor.dc.html |
24 subscription | configured | PlanBilling.dc.html | PlanBilling.dc.html |
…plus single-surface screens for enquiry-inbox (Enquiries), leads-sla (Leads), test-drives (Bookings), reputation (Reputation + Reviews) and signin (desktop-console/Auth).
⚠ A
sharedstep withhref: nullcontradicts its own reuse verdict. Shared means the generic screen is the dealership screen —Messages.dc.htmlserves a dealership rep's conversations unchanged, which is exactly what the classification asserts. So the step is at full parity and is being counted as zero.
🔎 The parity number is honest arithmetic over inputs that were set by a blanket rule. That is a different and more interesting failure than a wrong calculation: the verdict mechanism is sound and its data is not. A computed verdict is only as trustworthy as the field it folds over.
Corrected reading, conservatively: parity is at least 4/25 on both surfaces, not 0/25, and the no-screen count is closer to 16 than 25.
The fix per reuse class:
shared→ pointhref/desktopHrefat the existing screen. By definition it already serves.configured→ point at the existing SHELL with a note naming what industry data it still needs. The shell existing is the whole meaning of configured.specific→href: nullis correct. This is the only class where the blanket rule was right.
3 · ⚠ The mechanical cause, and it is a one-line fix per step
🧮 Measured across all 25 steps: cap: null on 8 of the 10 SPECIFIC ones. The two exceptions carry real keys (qr_tools, campaigns). Meanwhile only 3 of the 15 shared/configured steps have a null cap.
🔎 So the missing capability key is doing the classification work. The design's own warning said the capability model "is carrying too little" — that diagnosis is exactly right, and it is more actionable than it looks: most of these reclassify to
configuredthe moment they are given a key.
The keys that are missing and that ≥3 industries want:organisation · outlets · member_cards · visits · targets · oversight · audit
⚠ None of them is a new PRIMITIVE, so none needs the ≥3-industry justification gate — they are capabilities over Party, Location, Schedule and Ledger, which already exist in the closed set.
2.1 · ✅ And the design project ALREADY agrees with the classification
🧮 The project's own prototype/platform/ directory holds reputation.js, reputation.prompt.md, wa-templates.js, entitlements.js, capabilities.js, audiences.js, contacts.js, commitments.js, controls.js and leads-core.js.
🔎 So reputation, WhatsApp templates, contacts and leads are already placed at PLATFORM level by the design project itself — and Reputation.dc.html and Reviews.dc.html are already designed screens. ⚠ This is independent corroboration I should have cited instead of arguing from first principles, and it makes the classification argument in §1 much less contentious than it reads: the project's own directory structure had already reached the same conclusion for four of the capabilities in question.
4 · What I would NOT change
- The 25-step list itself. The journey is right; only the
reusecolumn is wrong. 0/25parity, counted per persona. Honest, and the per-persona split is the correct denominator.- Every
href: null. A burn-down that names what is missing beats a link to a screen that is not there. - The commercial and product notes. ₹225 standees, ₹14 lakh ad spend, "not a leaderboard", "a walk-in written in a notebook is invisible by the afternoon" — these are the best content in the file and they should survive the reclassification untouched.
- ✅ The
specificcount as a WARNING rather than an error. A threshold that flags rather than blocks is the right posture for a judgement call.
5 · Cross-check against the Receptionist spec
⚠ How the "no Receptionist screen exists" claim was reached, and why that matters
The Receptionist specification states that no Receptionist screen exists in either Claude Design project. 🧮 That claim is TRUE — verified 2026-08-24 against the project's own list_files, which contains no Receptionist.dc.html anywhere.
⚠ But it was originally written from grepping LOCAL transcribed ledgers, and asserted as a statement about the design project. 🔎 Right answer, wrong evidence — and the same session had already told the owner "next: send the prompt to Claude Design" when round 1 had in fact been delivered the day before. Both are the same failure: assuming the design project's state instead of fetching it, which CLAUDE.md's own rule forbids ("local design files are a cache only and may be stale"). Recorded here rather than quietly corrected, because a correct conclusion from the wrong source is the hardest kind of error to notice next time.
The journey gives Receptionist 5 steps: signin · log-visitor · visitor-queue · enquiry-inbox, plus sign-in shared. ✅ That maps cleanly onto the four screens in the Receptionist specification — Today's desk covers visitor-queue, Log a visit covers log-visitor, Visit detail covers enquiry-inbox, and Ready for handover is the seam to the Sales Manager. No contradiction, and no missing step.
⚠ One thing to confirm in round 2: visitor-queue is named "Visitor queue and assignment", but the owner decided 2026-08-24 that the receptionist never assigns — they capture and suggest, and the Sales Manager assigns. The step name should lose "and assignment", or the assignment half should move to the Sales Manager's leads-sla step.
6 · The prompt for round 2
Copy-paste prompt
Round 1 of the dealership journey is good and its warning branch fired correctly. Do go through the ten SPECIFIC steps — and the conclusion is stronger than "some could be shared": ZERO of the ten are genuinely industry-specific capabilities. The finding is two systematic errors rather than ten judgements.
Error A — enterprise SCOPE mistaken for INDUSTRY (8 steps: 1, 3, 4, 7, 17, 22, 23, 25). These are organisation and subtree capabilities that any multi-outlet tenant needs: a salon chain, a clinic group, a franchise. They read as dealership-specific only because the dealership is the first tenant that needs them. Ask at what scope before asking for which industry. Specifically: outlet-setup is verbatim ADR-0022's workspace-vs-location definition; audit-log is already BUILT (public.audit_log, shipped 2026-08-08); and standees is the clearest miss, because a single-stall vendor wants a standee MORE than a dealership does.
Error B — absent SUBSTRATE mistaken for SPECIFICITY (2 steps: 8, 9). The visitor register and queue are core walk-in capabilities that happen to have no tables yet. "Nothing exists for this" is not "only this industry wants it."
The one genuine exception, and it is not a capability: step 23 bundles two things. The oversight rollup is core; the OEM-facing restriction on discount and margin data is genuinely car-industry specific because it is LAW, not product. Split it: keep the rollup as configured, and move the OEM restriction to a compliance_profile on the industry.
The mechanical cause, which makes this cheap: cap: null on 8 of the 10 specific steps, versus only 3 of the 15 shared/configured ones. The missing capability key is doing the classification work. Adding these keys reclassifies most of them to configured with no other change: organisation, outlets, member_cards, visits, targets, oversight, audit. None is a new primitive.
Keep unchanged: the 25-step list, the per-persona parity counting, every href: null, the specific-count-as-warning posture, and all the commercial and product notes (₹225 standees, ₹14 lakh ad spend, "not a leaderboard", "a walk-in written in a notebook is invisible by the afternoon"). Those are the best content in the file.
One correction to a step name: visitor-queue is "Visitor queue and assignment", but the receptionist never assigns — they capture and suggest, and the Sales Manager assigns. Drop "and assignment" or move that half to the Sales Manager's step.
And a second, larger correction: the 0/25 parity figure and the 25-no-screen count are both wrong. All 25 steps carry href null and desktopHref null, set by a blanket rule, but screens that serve those steps already exist on BOTH surfaces: conversations to Messages, vehicle-catalogue to Catalogue, my-card to CardEditor, subscription to PlanBilling. Several more exist on one surface: Enquiries, Leads, Bookings, Reputation, Auth. A SHARED step with href null contradicts its own reuse verdict, because shared means the generic screen IS the dealership screen. The parity number is honest arithmetic over data set by a blanket rule, so the mechanism is sound and its input is not.
Fix per class: shared points at the existing screen; configured points at the existing SHELL with a note naming the industry data it still needs; specific keeps href null, which is the only class where the blanket rule was right. Parity should then read at least 4 of 25 on both surfaces, and the no-screen count closer to 16 than 25.
Copy: no em dashes or en dashes anywhere.
Not verified
❓ The persona step-counts were read off the rendered page, not recomputed from journeyFor(). ❓ My reclassification is an argument from the primitive model, not a measurement — five of the seven primitives this vertical declares still have no tables, so "core" here means where it belongs, not what exists.