CT-PBF-00: fresh empty-Brain load, build confirmed live
The plan: prove every way a founder can start or add to their Brain — pasting a website, sharing something with no website at all, adding to an already-set-up Brain, Google Docs/Sheets, Instagram, arbitrary links — all land in the same place (the playbook) and never on the old retired "confirm deck," plus that founders can always see and approve what got researched before it's saved.
What we tested: a real founder walk on the live site — read a real retreat center's website end to end (research → confirm → save, real money charged), shared a nameless new business with no site, added new material to an already-set-up Brain, tried an Instagram link, tried a broken/dead-end link, and tried a very short paste.
What we found — the core flow works: starting a Brain from a real website works well end to end — real progress messages, a genuine "does this look right?" pause before anything saves, and the resulting playbook is not a stub.
What we found — 3 things are seriously broken: (1) paid research disappears with no way to review it once a Brain already exists; (2) the old "read report" page is completely dead, both doors to it are broken; (3) sharing a brand-new nameless business never asks who it is — it silently hands back a nameless playbook.
Smaller bugs: Instagram paste in Teach shows no warning and its Read button does nothing; a plain page navigation (not a hard refresh) loses the in-progress research view; the account-reset script used between QA sittings misses two database tables, so an old business's research bled into a brand-new wiped account during this walk.
What we fixed: nothing this session — filed as 5 separate issues: #4352 (P0, invisible Teach-share content), #4353 (P1, dead /brain/read doors), #4354 (P1, nameless share no identity ask), #4355 (product question, not an assumed bug), #4356 (P2/P3 bundled). Also extended #4349 with a second confirmed table gap.
Readiness call: NOT ready. The core single-website path is solid, but the "add more later" path — the whole point of an ongoing Brain — silently swallows paid work, and the old-research lookback page is fully dead.
Bundle confirmed live: BrainPage-BgB1KMHB.js contains both required strings
("Save to Brain", "Auto-opening your business playbook"). Login via the #4339-fixed
magic-link tool worked cleanly — account header showed peytontianyan / $15.17 at start.
Site: kripalu.org (real, crawlable retreat-center site).
| Data In | kripalu.org (typed into the site-read URL field) |
|---|---|
| Data Out | Free peek ran (~40s, no charge) → Quick check gate self-opened with Business Name "Kripalu" pre-filled + a "you do" description from the crawl → clicked "That's me — run" → "Kickstarting your research" progress state → paid bundle ran ~2 min → landed on /brain#brain-landing-band, never /brain/read. |
Billing confirmed via ai_usage: brain_embed ×~11, brain_generate $0.4335, brain_read_note $0.1307, brain_reputation $0.1015 — total $2.51 debited, wallet $15.17→$12.66.
Landed state: TLDR block present (eyebrow "What we understand about your business", heading "The read, in one place", badge "ASSISTANT READS"), header bar verbatim "Sounds like you? Save this read to your Brain." with "Save to Brain" / "Not quite — re-read" buttons, plus "What we understood" and "How the web talks about you" sections with real content (12 mentions, TripAdvisor 4.0/5, Wikipedia, Yelp).
New bug found adjacent to this scenario — a plain in-app navigation to /brain right after a fresh read shows a blank "0% of required" template instead of the resume state; only a hard reload (Cmd+Shift+R) correctly restores it. brain_read_drafts row was confirmed unchanged in the DB throughout — client-side rendering gap, not data loss.
scenario: CT-PBF-01 (found adjacent to it) failed step: navigating to /brain via a plain route change right after a fresh unconfirmed read expected: same resumed/unconfirmed state a hard reload correctly shows actual: blank "0% of required" template, no resume banner, no drafted content frame ref: no-frame — prose oracle console: no errors network: only a brain_profile_personas GET fired; nothing that would fetch the resumable-read state layer guess: frontend — likely a missing fetch-on-mount for the resumable-read state on a plain route load PRD AC: AC-BRAIN-132(c) territory
Filed as #4356 (P2/P3, bundled with the Instagram dead-button bug).
DB verified (service-role REST, this tenant only): playbook_versions exactly 1 row, version_number=1, trigger='research_confirm'; brain_read_drafts=[] (deleted at confirm); brain_profile.about_story.tldr present and non-empty, distinct from .about. All data-trail assertions PASS.
Ran a fresh Sitting B wipe; discarded a stale draft that survived the wipe (see the reset-script finding below) before starting clean.
| Data In | "we sell handmade candles online, ships worldwide, family run. We started this a few years ago from our kitchen table and now ship all over the world to happy customers." (deliberately nameless, no proper noun) |
|---|---|
| Data Out | Pipeline ran directly as a plain Teach share ("READING WHAT YOU SHARED · done — 3 details found — Researched — ready to review — Open your playbook") and landed with business_name left OPEN and completely unaddressed. NO identify-me panel of any kind appeared — not even the plan's documented fallback failure state. |
scenario: CT-PBF-03 failed step: 3 (identify-me panel expected after submitting nameless paste) expected: IdentifyMePanel renders — share your website/Instagram, or type your business name actual: pipeline runs directly as a generic Teach share; lands with business_name left open, no ask of any kind frame ref: no-frame — prose oracle network: a lightweight research-shared-material-shaped dispatch, not the full site+reputation bundle layer guess: frontend (missing empty-name detection in classify-result handling) or backend (classify may not signal "no name found") PRD AC: AC-BRAIN-136
Filed as #4354 (P1).
Separate major finding surfaced in this same walk: the "What we understood" / "How the web talks about you" panels on this fresh nameless-candle draft still showed the OLD Kripalu content verbatim, because brain_read_notes was never cleared by either reset — directly caused by the reset-script gap (see below). A founder starting fresh could see an entirely unrelated business's analysis presented as their own.
Walked against the Kripalu-established account, sharing femalefoundersbreakfasts.com as new material via the Teach composer link paste.
PASS parts: no identity gate appeared (correct — established Brain skips it). Progress row order correct: "READING WHAT YOU SHARED" → "What you shared — read: femalefoundersbreakfasts.com — 8 details found" → "Researched — ready to review" — no Google/reviews/Instagram row (confirms AC-BRAIN-127a). Manual door text verbatim "Open your playbook →". Landed on /brain#brain-landing-band, never /brain/read. Billing: brain_generate $0.002, brain_research_synthesis $0.0024, brain_read_note $0.1192 — NO brain_reputation charge (confirms no public-lookup on Teach).
FAIL part (the significant one): zero trace of the new content appeared anywhere after landing — no new header bar, no drafted fields, "WHERE YOU STAND" unchanged. DB confirmed real content exists (brain_read_drafts new row, origin='teach') and real money was billed. Clicking "Resume" on the crash-recovery banner did not surface it either. Searched the DOM directly for any "Not quite — re-read"/"Save to Brain" button — zero matches.
scenario: CT-PBF-04 failed step: 5-6 (open playbook after a Teach share on an established Brain) expected: new unconfirmed drafted content visible + "Save to Brain"/"Not quite — re-read" header bar, per the same mechanism CT-PBF-01/02 demonstrated for a SITE-origin read actual: no visible trace of the new content anywhere, even after Resume; billed real money for content the founder can never see or confirm frame ref: no-frame — prose oracle console: no errors network: brain-ops dispatch fired and returned successfully (billing proves it) layer guess: frontend — most likely the header-bar/draft-display gate is scoped to origin==='site' or to a Brain with no prior confirmed content, and doesn't handle a Teach-origin draft arriving on top of an already-confirmed profile PRD AC: AC-BRAIN-127a / AC-BRAIN-137 territory
Filed as #4352 (P0).
Not executed as its own timed mid-progress interrupt. Indirect evidence gathered twice (after CT-PBF-01 and CT-PBF-04) via a hard reload — server-side brain_read_drafts row was intact both times, and the Resume/Discard banner appeared correctly on a hard reload (though NOT on a plain navigate — see CT-PBF-01's bug). The specific mid-flight (before completion) crash-resume case was not tested. Recommend a dedicated follow-up walk timed to interrupt a read mid-progress-row.
Requires clicking "Not quite — re-read" on a confirmed playbook — confirmed via direct DOM search that this button does not exist anywhere on the current established-Brain page. Same root cause as CT-PBF-04. Could not walk the reread_confirm-vs-research_confirm DB check this scenario needed.
The plan worried whether the read-only deck would leak confirm affordances. Instead: neither residual door works at all.
Tested the "open" link 3 ways (mouse coordinate click, click via element ref, JS-dispatched .click() on the actual button DOM node) — URL never changed, page content byte-identical before/after, zero console errors, zero new network requests. Also searched the live DOM for the PlaybookShelf "Our read" card by aria-label and text — zero matches; it does not render on this build even with brain_read_notes populated. Direct navigation to /brain/read silently redirects to /brain.
scenario: CT-PBF-07 failed step: 1 (click "open" on collapsed spine row) and 3 (direct /brain/read nav) expected: navigates to /brain/read, renders a read-only BrainReadReport deck actual: button does nothing (3 click methods, zero effect); direct URL redirects to /brain frame ref: no-frame — prose oracle (per plan) screenshot: screenshot-1788252092071-166.jpg, screenshot-1788252112178-167.jpg, screenshot-1788252273217-168.jpg console: no errors network: no new requests fired on click layer guess: frontend (dead click handler or a route guard that always redirects away) PRD AC: none dedicated — BrainPage.resumeLanding.test.ts's 3rd test case is the closest lock; worth checking if it exercises the real mounted component or a stale/orphaned one
Filed as #4353 (P1).
All five require entering a NEW website URL to research/probe on an ESTABLISHED Brain. No such entry point exists in the live UI — confirmed by reading source rather than guessing:
BrainIntakeScreen (src/pages/BrainPage.tsx:4280) — the only component
with the "Research my business" URL field these scenarios need — only renders when
!bare && surface !== 'workspace'.resolveBrainSurface() (src/lib/pagePreviewCache.ts:573) returns
'workspace' whenever the Brain isn't empty, regardless of completion % — confirmed live at 38%/75%
complete, still 'workspace'.BrainReadNudge, is gated behind 90 days since
last fetch, and even then only re-reads the SAME stored URL, never a new one.document.querySelectorAll('input') on an established /brain page
returns ZERO inputs outside the Teach composer.This isn't a click-through miss — the component that owns this behavior is architecturally unreachable once a Brain has any content. Open product question: is there supposed to be a way to research a brand-new different site once a Brain is established? Currently there is none. Recommend re-scoping these 5 scenarios to a genuinely empty-Brain precondition, or routing this as a product question. Filed as #4355.
Pasted "instagram.com/somehandle" into the Teach composer paste box (established Kripalu account).
Issue 1 — missing copy: expected sub-line "Instagram blocks most of our read..." never rendered (confirmed via document.body.innerText search). "Read this page" button DID stay enabled. Issue 2 — dead button: clicked via mouse coordinate AND element ref — no busy state, no network call (confirmed via network log), no error. Sanity-checked click capability immediately after via the sheet's Close button, which worked instantly. This dead-button issue is Instagram-specific — the same button worked correctly moments later for a normal business URL (CT-PBF-04) and for a non-existent blog link (CT-PBF-18, got an honest failure instead of silence).
scenario: CT-PBF-13 failed step: 2 (soft-warning copy) and 3-4 (Read this page click) expected: warning sub-line renders; clicking "Read this page" dispatches a scrape/read attempt actual: no warning text anywhere in the DOM; button click has zero effect (no network, no state change) specifically for an Instagram URL frame ref: no-frame — prose oracle console: no errors network: zero functions/v1 calls on click layer guess: frontend — likely the Instagram-detection branch (useBrainScrape.ts) isn't wired to render the sub-line, or an exception in that branch silently swallows the click handler PRD AC: AC-BRAIN-93
Filed as #4356 (P2/P3, bundled with the plain-nav resume gap).
Requires a real Instagram profile screenshot + a post screenshot with a visible caption. No image-capture tool for a live Instagram page was available in this Chrome session, and no pre-made fixture images were provided. Flagged as NOT WALKED (needs fixture assets), not BLOCKED or FAIL.
Confirmed live during CT-PBF-03: a 61-char paste showed "Add a little more — 40 to go" (matches the expected MIN_PASTE_LENGTH=100 math: 100-61+1≈40). The ~15,000-char long-paste truncation-warning check was not separately tested this session.
Pasted a real blog URL (a Lenny's Newsletter post — genuine non-business/non-IG/FB/Notion/Google page) → clicked "Read this page" (worked normally — busy state, network fired) → result: "We couldn't open that page. Add what's on it, or a file." — an honest, clear failure message, not a silent no-op or a false-success empty draft. Did not get a genuine SUCCESS case for a readable link, nor test a direct PDF link (no fixture on hand).
TLDR heading "What we understand about your business" IS present, seated FIRST on a freshly-landed SITE-origin read (confirmed via CT-PBF-01/02's own data — about_story.tldr non-empty and distinct from about_story.about).
New finding: a TEACH-origin draft does NOT get this TLDR treatment at all — no TLDR heading rendered for the femalefoundersbreakfasts.com Teach-share (CT-PBF-04), even though it also went through classify. TLDR seating appears gated on origin==='site', not universal to any fresh unconfirmed read as this scenario's own framing assumes.
Builds on CT-PBF-06's flow — blocked the same way (no reachable "Not quite — re-read" control).
Partial evidence obtained from CT-PBF-04's walk (an additive Teach share): network dispatch was the lightweight research-shared-material-shaped call (no brain_reputation, no site-crawl) — consistent with the code fact this scenario cites (useBrainSiteRead.ts:700-824, Teach never re-crawls/re-runs reputation on an established Brain). Did not get to run a CORRECTIVE share to compare against, since there was no working way to test contradiction without the confirm-and-reread door (CT-PBF-06) working. Recommend re-attempting CT-PBF-06/20/21 together once CT-PBF-04's bug is fixed.
Per the plan's own rule, each channel is scored independently, not averaged: