Summary

On gbrain 0.26.6, gbrain doctor --fast --json reports resolver_health warnings from shipped GBrain skills even when the runtime is otherwise healthy.

Observed warning set in a Railway/Postgres deployment pinned to upstream 9e2093fc9bb6cb46520e58b0c95b807e788d9606:

• 37 issue(s): 0 error(s), 37 warning(s)
• warning type: routing_miss
• affected shipped skills include archive-crawler, brain-pdf, perplexity-research, voice-note-ingest, strategic-reading, concept-synthesis, book-mirror, media-ingest, academic-verify, and article-enrichment
• recommended action in doctor output: Update routing-eval.jsonl fixture or broaden resolver triggers in RESOLVER.md

Why this matters

For production readiness automation, doctor --json is the natural gate. A deployment can have green DB, pgvector, RLS, schema, embeddings, queue, and supervisor checks, but still cannot honestly claim strict FULL PASS because status remains warnings.

Expected path

One of these would unblock strict readiness gates:

1. Update the affected shipped skills/*/routing-eval.jsonl fixtures so structural routing passes.
2. Broaden skills/RESOLVER.md and/or skill frontmatter triggers for the affected intents.
3. If these are expected until an LLM tie-break layer exists, classify them separately from production-readiness doctor warnings or document a stable allowlist/status code.

Notes

The changelog already mentions that some new-skill routing warnings are real and that routing-eval --llm is currently a placeholder. This issue is specifically about the operational implication: doctor --json cannot be used as a strict green readiness gate while shipped skill fixtures produce warnings.