gstack misclassifies a gbrain thin-client (remote-HTTP MCP, no local engine) as broken-config, suppressing brain-aware planning blocks #2051

Summary

On a machine where gbrain runs as a thin-client — the engine lives on a remote host and the agent talks to it purely over a remote-HTTP MCP server, with no local Postgres/PGLite engine — ./setup prints:

gbrain not detected — brain-aware blocks suppressed in planning-skill SKILL.md files.

and gstack-config gbrain-refresh reports local-status: broken-config. The brain is fully functional over MCP (reads/writes work in-session), but gstack decides it's absent and strips the brain-aware blocks from the planning skills (office-hours, plan-ceo-review, etc.).

Root cause

Two independent assumptions in the detector both assume a local engine and a hardcoded MCP name:

1. detectMcpMode() in bin/gstack-gbrain-detect hardcodes the MCP server name gbrain.
All three tiers look up a server literally named gbrain:

• claude mcp get gbrain --json
• grep for ^gbrain: in claude mcp list
• mcpServers.gbrain in ~/.claude.json

A thin-client whose MCP server is registered under any other name returns gbrain_mcp_mode: "none", even though a perfectly good remote-HTTP gbrain MCP is connected.

2. freshClassify() in lib/gbrain-local-status.ts only probes a local engine.
It runs gbrain sources list --json against a local DB. On a thin-client there is no local database_url, so the probe fails and the function hits its defensive default:

// Defensive default per codex #8: unrecognized failures classify as
// broken-config so the user sees the raw stderr surfaced upstream.
return "broken-config";

There is no state representing "no local engine, but a healthy remote brain over MCP."

Combined, a legitimate thin-client lands on mcp_mode: none + local_status: broken-config → "gbrain not detected" → brain-aware blocks suppressed, despite the brain being live.

Impact

Thin-client / remote-engine setups (a documented gbrain topology) silently lose brain-aware planning in gstack, with a misleading "broken-config" signal that suggests the user's gbrain install is broken when it isn't.

Suggested fix

• detectMcpMode(): don't hardcode the server name gbrain. Detect any MCP server whose endpoint/command resolves to gbrain, or allow the server name to be configured.
• freshClassify(): add a state for a healthy remote/thin-client brain (e.g. remote-ok). When a remote-HTTP gbrain MCP is present (or the config points at a remote endpoint with no local engine), treat the brain as available and keep the brain-aware blocks, instead of falling through to broken-config.

Environment

• gstack v1.58.3.0
• gbrain v0.42.51.0 (thin-client; remote engine, remote-HTTP MCP)
• macOS