- README = map + anti-slop placement rules - BUSINESS_PLAN at docs/ (sole strategy SoT); absorb beyond-NAP - Fold owner workflow, surfaces, MCP distribution - research/ → evidence/; drop stub READMEs + LAYERS twin - Fix dead main ghosts; Desk = sole scribe
2.0 KiB
Genre packs
Structural direction (working): three layers when surfacing work to owners — not one giant schema dump.
| Layer | What | Owner hears |
|---|---|---|
| A — Universal | Discovery foundation: NAP + Core 3 claimed + hours + website + description + service-area mode + no duplicates/contradictions | Everyone’s first punch list |
| B — Genre pack | Thin ranked list for that vertical (secondaries, high-value attributes, services/menu shape, booking/links, maybe one vertical directory) | “For salons like yours, next is X” — never “schema” |
| C — Known-for | From the owner’s own words | Extra attributes/photos/proof + later AI-readiness queries |
Surface rule: scorecard ladder first (exist → know what you do → would recommend), then 3–7 actions max, sorted by impact. Genre pack ranks the backlog.
Core 3 coverage rule: GBP is richest; Apple Business Connect mid; Bing Places thinnest. Pack actions: set on GBP; mirror on Apple/Bing where the field exists.
Not the same as “beyond NAP”: A/B/C = what work we show the owner. Beyond-NAP (in docs/BUSINESS_PLAN.md) = provider capability ladder (basics → extras → stacks).
Sourced Core 3 map + deep examples
- Core 3 sourced field map — SoT for fields (no guessing)
- Core 3 source URLs — GBP / Apple / Bing links to reopen
- Salon — genre application notes (illustrative only)
- Bakery — same
Later packs (not started on this branch)
Auto repair, beauty (reconcile with salon), home services, tourism activity, local retail — add only when we go deep; no placeholder shells.
Why this matters
Assistants evaluate helpfulness by whether the business answers the right questions for its category. Salon booking ≠ bakery known-for products.
Plan pointer: docs/BUSINESS_PLAN.md.