Step 1 — profile + 3 post screenshots staged, "Before we save" confirm shown, Save to my Brain enabled.
PASS — #4092 closed
What we tested: a founder shares Instagram screenshots (no website), confirms their business identity, and the platform should save what it learned instead of losing it.
What we found: the fix works. Business name and description now persist to the database, survive a hard refresh and a full sign-out/sign-in, and nothing was invented — both values trace directly to what was shared. Services stays empty today — that's expected, a separate known follow-up, not a new bug.
One real gap: the "Our Read" note (the plain-English summary of what the platform found) is not freshly generated for a share-only founder — documented, not a regression.
PR #4160 "fix(brain): upsert-safe identity persist on empty-Brain Share-anything path (#4092)" — MERGED 2026-08-26T08:27:16Z, SHA b26752adb8727.... This walk evaluates the shipped fix.
Data-trail (REST, service-role, filtered to this tenant):
brain_profile: {
business_name: "The Offline Club",
description: "Swap screen time for real time",
services: [],
updated_at: "2026-08-26T22:33:33Z"
}
Charge trail (ai_usage, 9 rows, 22:32:55–22:33:57 UTC):
| Surface | Count | Total |
|---|---|---|
| screenshot_vision_extract | 4 | $0.40 |
| brain_generate | 4 | ~$0.0047 |
| brain_reputation | 1 | $0.45 |
| Total | 9 | $0.854691 |
Matches the plan's "~$0.86 seen in the diagnosed case" almost exactly. brain_profile.updated_at lands right after the organize step, before the reputation charge — the persist fires on Save/organize, independent of the reputation pass.
Hard refresh: real playbook card survived. Sign out → sign in (Google OAuth) → /brain: same — survived a full session teardown. Confirms server-side persistence, not client React state.
An 11-card note deck was visible at /brain/read right after the identity confirm — initially looked like a freshly-minted note, but the brain_read_notes table has exactly 2 rows for this tenant, both dated 2026-08-25 (before this session's wipe; the reset script doesn't cover this table). No new row was created by this walk. This confirms the plan's Code-state note 2 exactly: the share-origin path does not mint a note. Documented gap, not a regression — PR #4160 never claimed note parity.
Both persisted values trace directly to the shared material — the business name is visible on the profile screenshot, and the tagline is the literal copy the reputation pass cites from the business's own public site. Nothing invented.
reset-brain-data.sh doesn't cover: (1) a paid draft-read "Resume" state that survived the wipe (had to Discard manually before CT-SHRP-01), and (2) the brain_read_notes table (2 stale rows from a prior walk on the same fixture business survived the wipe and could be mistaken for a fresh CT-SHRP-04 result). Worth folding into the reset script's table coverage.