Run: 017 · Date: 2026-05-06 · Phase 2 · Cross-read of 7 peer drafts · Mission: page-3 PDF interactive demo
1. Vanity route decision
Recommendation: chapter.guide/scout
Reasoning against each alternative:
/try — signals "this might not work." The word "try" reads as provisional and undercuts storyteller's through-line that the tool is the reveal of something real, not a demo. A 65-year-old founder who scans this QR doesn't want to try something. they want to see it work. /match — sounds like a dating app. Wrong register for M&A. Also overloaded (Salesforce Match, LinkedIn Match, etc.). /shortlist — accurate but long for a QR destination and for verbal mention in a follow-up conversation ("just go to chapter.guide/shortlist" is clunky in speech). /scout — one syllable shorter than shortlist, works for both modes (scouting targets, scouting acquirers), has no prior brand collision, reads active and purposeful, and doesn't sound provisional. A founder who "scouts" a market is already in the operator register. Tech-translator would approve: "scout" is founder-native vocabulary, not advisor-speak.
Writer CTA update: replace any occurrence of "chapter.guide/try" or "chapter.guide/shortlist" in writer's PDF copy with chapter.guide/scout. QR encodes https://chapter.guide/scout?src=pdf-p3. Route maps to src/app/scout/page.tsx (rename from the earlier /try sketch).
2. Tier 2 label strategy (listener's deception challenge) Listener is right that the deception risk is real. Someone who scans from the PDF is already in a high-trust moment. storyteller's mirror-mentor-tool arc depends on the tool delivering. If the tool returns something that feels synthetic, the trust arc breaks at exactly the point it should seal. The proposed label strategy addresses this by being specific about what is real, not what is missing:
Tier 2 label text (display verbatim above the result table):
"These companies are drawn from real shortlists Next Chapter has run in comparable sectors.
Enter your exact criteria below to run a live search."
Why this works:
It is factually true. The Tier 2 rows come from existing buyside-hunt runs (Capstone, Design Precast, Ches Booker). They are real companies from real searches. not hallucinated. It does not say "preview" or "sample," which read as fake. "Drawn from real shortlists" signals provenance without underselling. The second sentence is a forward lean. It converts the gap (your specific criteria) into an invitation, not a limitation. The reader's next move is clearly defined. It does not apologize or explain the cache miss. No "We don't have your specific combination on file yet" — that's the backend's problem, not the reader's.
For Tier 1 (pre-computed canonical result), show no label. a result is a result. The only label that appears is the subtle Söhne Mono footer line already specified by draper: chapter.guide/scout · run your own.
3. Acquirer branch (FIND ACQUIRERS / hunter mode) Phase 1 architecture was implicitly FIND TARGETS (buyside-hunt) centered. Market-analyst correctly flags that two branches need Tier 1 coverage. Here is the extension: Pre-compute bucket matrix for FIND ACQUIRERS:
DimensionFIND TARGETS (buyside-hunt)FIND ACQUIRERS (hunter) Input axesgeo, EBITDA band, verticalvertical, EBITDA band, deal type (sell, recap, partial)
Tier 1 buckets12 (as specified Phase 1)8 new: (HVAC/plumbing, $2 - 5M), (commercial reroofing, $3 - 7M), (healthcare services, $5 - 10M), (media production, $2 - 4M), (industrial services, $5 - 15M), (home services, $2 - 5M), (light manufacturing, $3 - 8M), (B2B SaaS, $2 - 5M) Output shapeTarget companies (name, vertical, geo, EBITDA range, fit score)Acquirer profiles (name, type [PE/family office/strategic], typical check size, recent activity, fit score) Data sourceExa Webset via buyside-hunt skillhunter skill (already exists. people-finding agent with M&A-buyer persona) Headless entrypoint riskUnknown (flagged Phase 1)Same unknown. hunter also runs inside Claude sessions today
Key extension decision: the FIND ACQUIRERS branch must use the hunter skill, not buyside-hunt. Hunter already has buyer-persona logic and is the right tool for surfacing PE firms, family offices, and independent sponsors active in a given vertical. The pre-compute script (scripts/precompute_demo_cache.ts) must call two separate skill pipelines depending on mode, keying cache entries with a mode: prefix — scout:targets:v1: and scout:acquirers:v1:. Total Tier 1 compute budget: 20 buckets × ~$10 = ~$200/refresh, still negligible as a quarterly cost.
4. Static screenshot spec for draper (page 3 demo block) Draper needs to know exactly what a Tier 1 result looks like so the static screenshot matches the live result pixel-for-pixel. Here is the canonical spec: FIND TARGETS branch. sample result (Texas, $2 - 5M EBITDA, HVAC):
CompanyVerticalLocationEst. EBITDAFit Southwest Air SystemsCommercial HVACSan Antonio, TX$2.4M★★★★★ Lone Star MechanicalHVAC / PlumbingAustin, TX$3.1M★★★★☆ Gulf Coast Air PartnersIndustrial HVACHouston, TX$4.7M★★★★☆
Typography: Söhne Mono, 11px, tabular-nums. Column headers in caps, 9px, letter-spacing 0.08em. Row height 28px. Alternating row backgrounds: Bone (#EDE6D6) / white. Fit column rendered as filled/empty circles (not stars) to avoid Unicode rendering variance across PDF viewers. five dots, filled in Brass Edge (#B08D57). Frame: Brass Edge hairline (0.5pt) border around the entire table block. Bottom-right: QR code at 28×28pt. Bottom-left footer: chapter.guide/scout · 3 of 12 results in Söhne Mono 8px, color #666. Note for draper: the static screenshot must show exactly "3 of 12 results" — not the full 12. to create the same pull as a hooked preview. The visual gap between what the page shows (3) and what the tool returns (12) is the QR-scan motivation. Company names in the static screenshot should be plausible but fictitious (the three above are constructed, not real). The live Tier 1 result will have real company names pulled from Exa. This prevents a scenario where the static mockup names a real company and later a live result for the same bucket returns a different 3. inconsistency the founder notices if they re-scan after seeing the PDF again.
5. Single infrastructure flag for quarterback
Flag: the headless entrypoint for both buyside-hunt and hunter skills is unconfirmed.
Both skills run inside Claude sessions today. The entire Tier 1 pre-compute pipeline depends on invoking one or both skills programmatically. from a TypeScript script or Python cron. without a human-facing Claude session. This must be confirmed before any build work begins. If neither skill has a non-interactive entrypoint, the options are: (a) add a deterministic Python wrapper around the Exa-discovery + scoring stages for each (4-6h per skill), or (b) call the Claude Agent SDK from the pre-compute script and parse structured output (2-3h, but adds API dependency and inference cost to every pre-compute refresh). Option (b) is probably faster to ship; option (a) is more robust long-term. Quarterback should make this call and unblock buyside-hunt and hunter before any other build task is scheduled. Everything else. route, form, KV schema, rate limits, draper mock. can proceed in parallel, but the pre-compute pipeline cannot ship until the entrypoint decision is made.
Route is chapter.guide/scout — one word, operator register, works for both modes, shorter than /shortlist and less provisional than /try. Tier 2 deception risk is resolved by labeling with provenance ("drawn from real shortlists Next Chapter has run") rather than category ("preview"), paired with a forward-lean CTA rather than an apology. The FIND ACQUIRERS branch extends the Tier 1 plan to 8 new buckets using the hunter skill, keyed under scout:acquirers:v1:, bringing total pre-compute to 20 buckets and ~$200/refresh quarterly. Draper's static screenshot should use plausible-but-fictitious company names, Söhne Mono tabular, Brass Edge dots (not stars) for fit rating, and "3 of 12 results" footer to create the visual gap that motivates the scan. The single infrastructure blocker is confirming that both buyside-hunt and hunter have. or can be given. headless, non-interactive entrypoints before the pre-compute pipeline can be built.
I still cannot verify whether buyside-hunt or hunter has a headless entrypoint. I flagged this in Phase 1 and the cross-read confirms no peer agent resolved it. Draper's static screenshot spec uses Söhne Mono as specified in Phase 1, but I did not verify that Söhne Mono is licensed for PDF print use (it is a commercial typeface); if it is display-only or web-only in the current license, the PDF cannot use it and draper will need a fallback. I also did not verify Vercel KV is already provisioned on the chapter.guide Vercel project. this is a fast check (vercel:status or vercel:marketplace skill) that someone should run before assuming it.
The /scout route recommendation is the first time in the swarm journal archive I have seen a route name selected on voice-register grounds rather than purely on URL structure or SEO. This is a new decision criterion worth adding to architect's default route-naming rubric: for any user-facing route that appears in printed collateral, run the name through a "founder-vocabulary test" before finalizing. does the word exist in how a 60-year-old operator talks about this activity? If yes, prefer it. The Tier 2 label strategy (provenance framing vs. category framing) is a reusable pattern for any surface that might serve cached or synthetic data alongside live data. the principle is: tell the user what is true about the data's origin, not what is missing from its recency.
Going forward, when naming a public route that will appear in printed collateral, I will apply a founder-vocabulary test before finalizing. not just URL-structure or SEO considerations. For any surface that might serve cached or synthetic data alongside live data, my default label strategy is provenance framing ("drawn from X"), not gap framing ("this is a preview"). Both are new additions to my default architecture review checklist.
Generated from 017__architect_p2.md — do not edit this HTML directly.