gbrain put/import always use 'default' source — no way to specify source_id from CLI or per-project config

[aicloud-cpu]

What happened?

gbrain put and gbrain import CLI commands always write to the default source regardless of context. gbrain sync --strategy code creates per-project sources automatically, but any user-imported data (conversations, documents, etc.) is lumped into default.

In a multi-project setup, this means:

• Code is properly isolated per source (via sync --strategy code)
• But user-imported data from all projects is mixed in default
• MCP search with sourceIds filter cannot exclude cross-project conversation data, making source-level isolation ineffective for manually imported content

What did you expect?

gbrain put and gbrain import should support a --source flag to specify the target source:

gbrain put <slug> --content "..." --source my-project
gbrain import <dir> --source my-project

Alternatively, gbrain put could read source_id from the YAML frontmatter of the imported markdown content.

Better yet: support a per-project config file at <project-root>/.gbrain/config.json that overrides the global ~/.gbrain/config.json. Projects can then define their own source_id in this local config, and all put/import/query commands run inside that project directory will automatically use the configured source instead of default. This follows the same pattern as .env / eslintrc — local overrides global.

Steps to reproduce

1. Run gbrain sync --strategy code . — creates a source like repo-code-xxxx with code pages
2. Run gbrain put my-page --content "---\ntitle: test\n---\nhello" — page goes to default
3. Run mcp__gbrain__search with sourceIds: ["repo-code-xxxx"] — still returns default pages
4. The sourceIds filter cannot exclude cross-project content because user data is all in default

Environment

• gbrain version: 0.37.0.0
• OS: Windows 11
• Bun version: 1.3.14
• Database: self-hosted PostgreSQL 16 (pgvector)

gbrain doctor --json output

{
  "schema_version": 2,
  "status": "warnings",
  "health_score": 70,
  "checks": [
    {"name": "connection", "status": "ok", "message": "Connected, 500+ pages"},
    {"name": "embedding_provider", "status": "warn", "message": "local model (1024d)"},
    {"name": "schema_version", "status": "ok", "message": "Version 78 (latest: 78)"},
    {"name": "embedding_width_consistency", "status": "ok", "message": "Schema width (1024d) matches embedding_dimensions config"}
  ]
}

[rayers]

Hit this hard on a brain with 320K m365-mail pages. Same root cause from a different angle: cron-driven auto-ingest calling gbrain import "$dir" once per source. Without --source, every tick added new source_id='default' rows ALONGSIDE the canonical source='m365' rows — accumulated to 155K duplicate mail rows plus ~13K duplicate chats over the course of a few weeks. Doubling everything, all silent.

PR #836 fixes the engine layer (the underlying helper threads sourceId); it explicitly defers the CLI flag as a follow-up. This issue is the right place for it.

Workaround until the flag lands (~50 lines of bun + a bash wrapper, drop-in for gbrain import):

// ~/.local/lib/gbrain-patch/import-with-source.ts
import { configureGateway } from "/path/to/gbrain/src/core/ai/gateway.ts";
import { createEngine } from "/path/to/gbrain/src/core/engine-factory.ts";
import { loadConfig, toEngineConfig } from "/path/to/gbrain/src/core/config.ts";
import { runImport } from "/path/to/gbrain/src/commands/import.ts";

const { sourceId, rest } = parseSourceArg(process.argv.slice(2));
const config = loadConfig()!;
configureGateway(buildGatewayConfig(config));
const engine = await createEngine(toEngineConfig(config));
await engine.connect(toEngineConfig(config));
try {
  await runImport(engine, rest, sourceId ? { sourceId } : undefined);
} finally { await engine.disconnect(); }

Bash wrapper does what gbrain-with-keys does (sources 1P-backed API keys) then exec bun run on the .ts. Drop into auto-ingest scripts in place of gbrain import.

Tradeoff is brittleness on absolute file paths into ~/.bun/install/global/node_modules/gbrain/ — fine for personal-machine use, would break the moment upstream restructures. A native --source flag would be ~3 lines added to runImport's argv parser.

Cleanup, for anyone landing here mid-incident: DELETE FROM pages WHERE source_id='default' AND type='m365-mail' will drop the duplicates (cascades to chunks+links via FK). The canonical source='m365' rows stay intact. We lost ~10K legitimately-orphaned default rows in our case; the next cron tick re-imports them via the wrapper and they land in the correct source. Net page_count drop: ~155K (24% smaller brain), no semantic loss.

Happy to PR the CLI flag if it would help — looks like ~3 lines in src/commands/import.ts next to the existing --workers / --strategy parsing.