Run these checks after install to confirm every part of GBrain is working. Each check includes the command, expected output, and what to do if it fails.
The most important check is #4 (live sync). "Sync ran" is not the same as "sync worked." A sync that silently skips pages because of a pooler bug is worse than no sync at all, because you think it's working.
Command:
gbrain doctor --jsonExpected: All checks return "ok":
connection: connected, N pagespgvector: extension installedrls: enabled on all tablesschema_version: currentembeddings: coverage percentage
If it fails: The doctor output includes specific fix instructions for each
check. See skills/setup/SKILL.md Error Recovery table.
Check: Ask the agent: "What is the brain-agent loop?"
Expected: The agent references GBRAIN_SKILLPACK.md Section 2 and describes the read-write cycle: detect entities, read brain, respond with context, write brain, sync.
If it fails: The agent hasn't loaded the skillpack. Run step 6 from the
install paste (read docs/GBRAIN_SKILLPACK.md).
Command:
gbrain check-update --jsonExpected: Returns JSON with current_version, latest_version,
update_available (boolean). The cron gbrain-update-check is registered.
If it fails: Run step 7 from the install paste. See GBRAIN_SKILLPACK.md Section 17.
This is the most important check. Three parts.
Compare page count in the DB against syncable file count in the repo:
gbrain statsThen count syncable files:
find /data/brain -name '*.md' \
-not -path '*/.*' \
-not -path '*/.raw/*' \
-not -path '*/ops/*' \
-not -name 'README.md' \
-not -name 'index.md' \
-not -name 'schema.md' \
-not -name 'log.md' \
| wc -lExpected: Page count in gbrain stats should be close to the file count.
Some difference is normal (files added since last sync), but if page count is
less than half the file count, sync is silently skipping pages.
If page count is way too low: The #1 cause is the connection pooler bug.
Check your DATABASE_URL:
- If it contains
pooler.supabase.com:6543, verify it's using Session mode, not Transaction mode. - Transaction mode breaks
engine.transaction()and causes.begin() is not a functionerrors. - Fix: switch to Session mode pooler string, then run
gbrain sync --fullto reimport everything.
gbrain statsExpected: Embedded chunk count should be close to total chunk count.
If embedded is much lower than total:
gbrain embed --staleIf OPENAI_API_KEY is not set, embeddings can't be generated. Keyword search
still works without embeddings, but hybrid/semantic search won't.
This is the real test. Edit a brain page, push, wait, search.
- Edit a page in the brain repo (e.g., correct a fact on a person's page):
# Example: fix a line in Gustaf's page
cd /data/brain
# Make a small edit to any .md file
git add -A && git commit -m "test: verify live sync" && git push-
Wait for the next sync cycle (cron interval or
--watchpoll). -
Search for the corrected text:
gbrain search "<text from the correction>"Expected: The search returns the corrected text, not the old version.
If it returns old text: Sync failed silently. Check:
- Is the sync cron registered and running?
- Is
gbrain sync --watchstill alive (if using watch mode)? - Run
gbrain config get sync.last_runto see when sync last ran. - Run
gbrain sync --repo /data/brainmanually and check for errors. - If you see
.begin() is not a function, fix the pooler (see 4a above).
Command:
gbrain statsExpected: Embedded chunk count matches (or is close to) total chunk count.
If zero or very low: OPENAI_API_KEY may be missing or invalid. Check:
echo $OPENAI_API_KEY | head -c 10If blank, set the key. Then:
gbrain embed --staleCheck: Ask the agent about a person or concept that exists in the brain.
Expected: The agent uses gbrain search or gbrain query FIRST, not grep
or external APIs. The response includes brain-sourced context with source
attribution.
If it fails: The brain-first lookup protocol isn't injected into the agent's
system context. See skills/setup/SKILL.md Phase D.
The v0.12.0 graph layer needs to be populated for existing brains. New writes are auto-linked, but historical pages need a one-time backfill.
Command:
gbrain stats | grep -E 'links|timeline'Expected: Both links and timeline_entries are non-zero (assuming the brain
has content with entity references and dated markdown).
If it's zero on a brain with imported content: Run the backfill.
gbrain extract links --source db --dry-run | head -5 # preview
gbrain extract links --source db # commit
gbrain extract timeline --source db
gbrain stats # confirm > 0Bonus check — graph traversal works:
# Pick any well-connected slug from your brain
gbrain graph-query people/<some-person-slug> --depth 2Expected: Indented tree of typed edges (--attended-->, --works_at-->, etc.).
If the slug has no inbound or outbound links, try a different one or run extract
again.
If extract finds nothing: Your pages may not use entity-reference syntax. The
extractor matches [Name](people/slug), [Name](../people/slug.md), and bare
people/slug references. If your brain uses a different format, the auto-link
heuristics won't find them — file an issue with a sample page.
Postgres-backed brains created before v0.12.2 had double-encoded JSONB columns
(frontmatter->>'key' returned NULL, GIN indexes were inert). gbrain upgrade
runs gbrain repair-jsonb automatically via the v0_12_2 orchestrator.
Verify the repair succeeded.
Command:
gbrain repair-jsonb --dry-run --jsonExpected: totalRepaired: 0 across all 5 columns (pages.frontmatter,
raw_data.data, ingest_log.pages_updated, files.metadata,
page_versions.frontmatter). A zero count means every row is properly-typed
JSON objects, not string-encoded JSON.
If the count is > 0: The repair didn't run or was interrupted. Re-run
without --dry-run:
gbrain repair-jsonbIdempotent. PGLite brains always report 0 (unaffected by the original bug).
Bonus check — frontmatter-keyed queries actually resolve:
gbrain call list_pages '{"frontmatterKey": "type", "frontmatterValue": "person"}'If this returns rows on a brain with person pages, the JSONB path is healthy.
# 1. Schema
gbrain doctor --json
# 2. Sync recency
gbrain config get sync.last_run
# 3. Page count + embed coverage
gbrain stats
# 4. Search works
gbrain search "test query from your brain content"
# 5. Catch any unembedded chunks
gbrain embed --stale
# 6. Auto-update
gbrain check-update --json
# 7. Knowledge graph populated (links + timeline > 0)
gbrain stats | grep -E 'links|timeline'
# 8. JSONB integrity (v0.12.2 — Postgres only, PGLite always 0)
gbrain repair-jsonb --dry-run --jsonIf all eight return successfully, the installation is healthy. For the full end-to-end sync test (4c), push a real change and verify it appears in search.