Environment

• gbrain serve --http on a remote host (Railway), Supabase Postgres backend, single user.
• No local brain checkout on the client (thin client; all ops route via MCP/CLI to the remote engine).
• Active source is a named source (not default).
• The brain (~1.3k pages) uses flat namespaces: people/, companies/, concepts/, originals/, etc. No wiki/ pages exist.

Symptom: synthesize has never produced a page here

Every dream-cycle run for two weeks writes the same summary:

# Dream cycle YYYY-MM-DD
**Children:** 0 completed, 2 failed/timeout.
**Pages written:** 0.

• 13 consecutive runs, 2026-05-16 → 2026-05-28, all identical: 2 children dispatched, 0 completed, all failed/timeout, 0 pages written.
• So there WAS corpus to process (children were dispatched), but the synthesis children never complete.
• The dream-cycle summary page itself is written correctly (to the named source), so the orchestrator + summary writer work; it is the synthesis child subagents that fail.

Likely root cause (hypothesis, not confirmed)

This strongly correlates with #1471, whose title literally describes the mechanism: "resolveLintContentSanity disconnects shared module-level db singleton, killing the cycle's main engine connection." The cycle runs lint before synthesize; if the synthesize children inherit/share the engine connection that the lint phase tears down, a fail/timeout with 0 writes is the expected shape. (Happy to pull worker logs if useful.)

Compounding issues — synthesize would mis-file even if children succeeded

Even after the fail/timeout is fixed, synthesize output would not land usefully on this deployment:

1. Hard-coded source_id: 'default' (dream synthesize writes synthesized pages to 'default' source, ignoring the resolved brain source #1586). The child put_page slugs are returned with source_id: 'default' (src/core/cycle/synthesize.ts, ~L871: .map(slug => ({ slug, source_id: 'default' }))), and a code comment acknowledges the gap (...default to default for current dream-cycle product behavior). On a brain whose active source is not default, synthesized pages would land in the wrong source (a multi-source-drift symptom; see also doctor multi_source_drift recommendation references missing CLI surfaces (gbrain delete --source, gbrain sources rehome) #1123 on the missing remediation CLI surfaces). The orchestrator's own summary writer does NOT have this problem (it used the correct source).

2. Hard-coded wiki/ output paths, not configurable. buildSynthesisPrompt instructs children to write to literal wiki/personal/reflections/... and wiki/originals/ideas/... (src/core/cycle/synthesize.ts, ~L989/L992). The allow-list (_brain-filing-rules.json → dream_synthesize_paths.globs) is also wiki/-only and is enforcement-only (it does not redirect the prompt). On a brain that files into flat namespaces (originals/, people/, concepts/), this means synthesized content lands in a separate wiki/ namespace with no reconciliation (verified: (source_id, slug) is the unique key; slug_aliases only handles explicit registered redirects; no automatic prefix collapse). Result: a permanently fragmented brain (wiki/originals/x vs originals/x are two unrelated pages). There is currently no way to align synthesize's output paths to a brain's filing convention without patching buildSynthesisPrompt (the prompt uses literals, not config).

Requests

1. Investigate the child fail/timeout (is it resolveLintContentSanity disconnects shared module-level db singleton, killing the cycle's main engine connection #1471, or a separate child-timeout)? This is the blocker — synthesize produces nothing.
2. Make synthesize source-aware (resolve the active source instead of hard-coding default) — dream synthesize writes synthesized pages to 'default' source, ignoring the resolved brain source #1586.
3. Make synthesize output paths configurable (read target prefixes from _brain-filing-rules.json / config in buildSynthesisPrompt) so deployments with flat namespaces don't fragment. At minimum, document that synthesize requires the wiki/ convention.