Two related issues turned up while running /setup-gbrain for the first time on gstack v1.26.0.0. Filing together because they share root causes around the gstack ↔ gbrain integration boundary, but they're independently actionable.
Issue 1 (blocker): gstack-memory-ingest calls a CLI surface that doesn't exist on any released gbrain
Symptom
/setup-gbrain Step 7.5 (transcript & memory ingest) silently writes 0 pages on every page. Every per-page invocation prints:
Unknown command: put_page
Run gbrain --help for available commands.
[put-error] design-docs/<repo>/<date>-...: Command failed:
gbrain put_page --slug design-docs/<repo>/<date>-... \
--title 'design-doc — <repo> — <date> — ...' \
--type design-doc \
--tags design-doc,repo:<repo>,date:<date>
The orchestrator reports OK memory ingest pass complete (10.8s) because individual put errors aren't fatal, so setup looks GREEN. The headline v1.26 feature ("the agent already knows your past work") is non-functional.
Repro
# fresh gstack v1.26.0.0, fresh gbrain pin (v0.18.2 via gstack-gbrain-install)
/setup-gbrain # PGLite local
# pick any non-skip transcript-ingest option
# OR run directly:
bun ~/.claude/skills/gstack/bin/gstack-memory-ingest.ts --bulk --limit 3
In my run: 177/177 candidate files (167 transcript + 4 timeline + 4 design-doc + 1 learning + 1 builder-profile-entry) → 0 written, 177 failed.
Root cause
bin/gstack-memory-ingest.ts (writer block ~L748–905) generates this subprocess call:
gbrain put_page --slug <slug> --title <title> --type <type> --tags <tags> ...
But gbrain's CLI dispatcher (src/cli.ts) registers each operation under cliHints.name, not op.name. The put_page operation in src/core/operations.ts has:
cliHints: { name: 'put', positional: ['slug'], stdin: 'content' }
params: { slug: { required: true }, content: { required: true } }So the CLI surface is gbrain put <slug> with markdown content (incl. YAML frontmatter carrying title:, type:, tags:) on stdin. There is no CLI subcommand named put_page, and --title/--type/--tags aren't params anywhere — those properties live in frontmatter.
I scanned all 102 gbrain branches + master. None expose put_page as a top-level CLI subcommand or accept named-flag metadata. The mismatch is deterministic across every gbrain version.
Two clean fixes (either works on any gbrain ≥ v0.3.0)
Option A — CLI surface: stdin-based.
echo "<frontmatter>\n\n<body>" | gbrain put <slug>
Option B — generic op dispatch: gbrain call <op_name> '<json>' is a JSON-RPC-style passthrough that has existed since v0.1.0:
gbrain call put_page '{"slug":"<slug>","content":"<full markdown with frontmatter>"}'
Option B keeps the existing operation-name-as-protocol contract that the rest of gstack-memory-ingest seems to assume (writer.ts treats put_page like an MCP tool). Option A is closer to the user-facing CLI shape. Both are minimal diffs.
Workaround (none clean)
Setting transcript_ingest_mode=incremental lets setup complete cleanly, but ingest still fails on every new page going forward — so the brain stays empty regardless.
Versions
- gstack: 1.26.0.0
- gbrain: tested at v0.18.2 (the install-pin) and v0.26.0 (master). Same failure on both.
- macOS, Bun 1.3.13.
Issue 2 (release-coordination gap): /gstack-upgrade doesn't bump the gbrain install-pin
Observation
/gstack-upgrade cleanly upgrades ~/.claude/skills/gstack (1.17.0.0 → 1.26.0.0 in my run). It doesn't touch the gbrain install at ~/gbrain, which is pinned by bin/gstack-gbrain-install to commit 08b3698e90532b7b66c445e6b1d8cdfe71822802 = gbrain v0.18.2.
That v0.18.2 commit predates several gbrain releases that gstack v1.26 features arguably depend on (notably the schema migrations 24 → 32 added in v0.20–v0.22, the frontmatter-guard work, the new code-def/code-refs/reindex-code ops referenced in v1.26 manifests).
In my session, the user-visible failure mode was: /setup-gbrain installed gbrain v0.18.2, code-import ran, then gbrain doctor reported schema_version: Version 24, latest is 32. Fix: gbrain apply-migrations --yes — putting the user one extra manual step from a healthy state.
Why this isn't the cause of Issue 1
I want to be explicit: bumping the pin would NOT have fixed Issue 1. Both gbrain put (CLI) and gbrain call put_page (op dispatch) existed at v0.18.2 — gstack just isn't using either. Issue 2 is an adjacent reliability concern, not the call-format bug's underlying cause.
Request
/gstack-upgrade should either:
- (a) bump the gbrain pin in
gstack-gbrain-install whenever gstack releases new memory/manifest features that depend on newer gbrain ops or schema, OR
- (b) detect a stale pin during preamble and either auto-upgrade gbrain or print a one-line FIX hint, similar to how
gstack-update-check already handles gstack itself.
Either way, the pin file becomes a tracked release artifact that ships with gstack rather than a static constant.
What worked vs. didn't (for triage context)
| Surface |
Result |
/gstack-upgrade 1.17.0.0 → 1.26.0.0 |
OK |
gstack-gbrain-install (PGLite path) |
OK |
gbrain init --pglite |
OK |
gbrain doctor |
warnings only (expected on empty brain) |
claude mcp add user scope |
OK, ✓ Connected |
gstack-brain-init (private GitHub repo) |
OK |
gstack-gbrain-source-wireup |
OK, federated source registered |
gbrain put / gbrain search smoke test |
OK round-trip |
gbrain import . from this repo |
OK, 82 pages, 1691 chunks |
gstack-memory-ingest --bulk |
FAIL (Issue 1) |
gbrain apply-migrations --yes after gbrain master upgrade |
OK, schema 24 → 32 |
Two related issues turned up while running
/setup-gbrainfor the first time on gstack v1.26.0.0. Filing together because they share root causes around the gstack ↔ gbrain integration boundary, but they're independently actionable.Issue 1 (blocker):
gstack-memory-ingestcalls a CLI surface that doesn't exist on any released gbrainSymptom
/setup-gbrainStep 7.5 (transcript & memory ingest) silently writes 0 pages on every page. Every per-page invocation prints:The orchestrator reports
OK memory ingest pass complete (10.8s)because individual put errors aren't fatal, so setup looks GREEN. The headline v1.26 feature ("the agent already knows your past work") is non-functional.Repro
In my run: 177/177 candidate files (167 transcript + 4 timeline + 4 design-doc + 1 learning + 1 builder-profile-entry) → 0 written, 177 failed.
Root cause
bin/gstack-memory-ingest.ts(writer block ~L748–905) generates this subprocess call:But gbrain's CLI dispatcher (
src/cli.ts) registers each operation undercliHints.name, notop.name. Theput_pageoperation insrc/core/operations.tshas:So the CLI surface is
gbrain put <slug>with markdown content (incl. YAML frontmatter carryingtitle:,type:,tags:) on stdin. There is no CLI subcommand namedput_page, and--title/--type/--tagsaren't params anywhere — those properties live in frontmatter.I scanned all 102 gbrain branches + master. None expose
put_pageas a top-level CLI subcommand or accept named-flag metadata. The mismatch is deterministic across every gbrain version.Two clean fixes (either works on any gbrain ≥ v0.3.0)
Option A — CLI surface: stdin-based.
Option B — generic op dispatch:
gbrain call <op_name> '<json>'is a JSON-RPC-style passthrough that has existed since v0.1.0:Option B keeps the existing operation-name-as-protocol contract that the rest of
gstack-memory-ingestseems to assume (writer.ts treatsput_pagelike an MCP tool). Option A is closer to the user-facing CLI shape. Both are minimal diffs.Workaround (none clean)
Setting
transcript_ingest_mode=incrementallets setup complete cleanly, but ingest still fails on every new page going forward — so the brain stays empty regardless.Versions
Issue 2 (release-coordination gap):
/gstack-upgradedoesn't bump the gbrain install-pinObservation
/gstack-upgradecleanly upgrades~/.claude/skills/gstack(1.17.0.0 → 1.26.0.0 in my run). It doesn't touch the gbrain install at~/gbrain, which is pinned bybin/gstack-gbrain-installto commit08b3698e90532b7b66c445e6b1d8cdfe71822802= gbrain v0.18.2.That v0.18.2 commit predates several gbrain releases that gstack v1.26 features arguably depend on (notably the schema migrations 24 → 32 added in v0.20–v0.22, the
frontmatter-guardwork, the newcode-def/code-refs/reindex-codeops referenced in v1.26 manifests).In my session, the user-visible failure mode was:
/setup-gbraininstalled gbrain v0.18.2, code-import ran, thengbrain doctorreportedschema_version: Version 24, latest is 32. Fix: gbrain apply-migrations --yes— putting the user one extra manual step from a healthy state.Why this isn't the cause of Issue 1
I want to be explicit: bumping the pin would NOT have fixed Issue 1. Both
gbrain put(CLI) andgbrain call put_page(op dispatch) existed at v0.18.2 — gstack just isn't using either. Issue 2 is an adjacent reliability concern, not the call-format bug's underlying cause.Request
/gstack-upgradeshould either:gstack-gbrain-installwhenever gstack releases new memory/manifest features that depend on newer gbrain ops or schema, ORgstack-update-checkalready handles gstack itself.Either way, the pin file becomes a tracked release artifact that ships with gstack rather than a static constant.
What worked vs. didn't (for triage context)
/gstack-upgrade1.17.0.0 → 1.26.0.0gstack-gbrain-install(PGLite path)gbrain init --pglitegbrain doctorclaude mcp adduser scopegstack-brain-init(private GitHub repo)gstack-gbrain-source-wireupgbrain put/gbrain searchsmoke testgbrain import .from this repogstack-memory-ingest --bulkgbrain apply-migrations --yesafter gbrain master upgrade