devhub-registry

DevHub Registry

Treat the configured DevHub instance as the operational map for its owner. Use available DevHub MCP tools for read-only catalog lookup and use the local filesystem plus reviewed Git changes for reconciliation. Never mutate a catalog through MCP.

Route the request

• For “set up DevHub from scratch”, “install DevHub in a blank Codex”, “set up my community DevHub”, or an equivalent first-run request: follow Community first-run bootstrap below before ordinary Connected Setup. Do the machine work yourself and ask only recognizable choices plus explicit write approvals; do not turn the installation guide into user homework.
• For “add my private Sites companion”, “show my DevHub in Sites”, or an equivalent request after community first run: follow Owner-only Sites companion below. Use the installed Sites building and hosting workflows, but keep create/reuse and publish as distinct explicit approvals.
• For “set up my DevHub”, “connect everything I can access”, “Build my map”, “refresh my DevHub”, or “подключи всё, к чему у меня есть доступ”: first verify the local workflow runtime under Verify the Connected Setup runtime below. Then run devhub setup --json, or its wrapper from the one explicitly supplied compatible checkout. Report recommended connectors, exact detection evidence and the Build-my-map plan. Detection is not authorization or account access: do not start OAuth, open provider pages, read credential values or modify the catalog. A planned connector remains planned even when its local marker is detected.
• For “where is it?”, “is it up?”, or “how do I open, start, or recover it?”: query an available DevHub MCP server and answer from catalog evidence.
• For “make this host live” or “configure host monitoring”: when an exact reviewed probe contains publish.type: tailscale-serve, preview it on that target with devhub setup-host-monitoring <host-id> --json. Use --apply only when the user asked to configure monitoring and the preview has no identity or path conflict. Never enable Funnel or run tailscale serve reset.
• For “register”, “sync”, “update”, or a reported project change: inspect the current project, find its DevHub record, and prepare a minimal reviewed catalog change.
• For “check drift”: compare repository evidence with the current record and report in-sync, drift, or unknown. Prefer unknown over an invented fact.
• For “is this safe?”, “how production-ready is it?”, or “create an App Passport”: inspect evidence for the selected readiness profile and propose explicit verified, declared, missing, not-applicable, or unknown checks.
• For “review everything I shipped” or “what should I fix first?”: use review-portfolio --json from an available checkout, treat every result as a catalog evidence question, and prioritize the highest-harm reversible next action. Do not report a percentage or imply that unknown proves a production defect.
• For “refresh provider evidence”: use collect-evidence <binding.json> --json, or pass reviewed binding files to review-portfolio --evidence-binding. Never accept a prebuilt normalized result as production evidence.
• For “what exists in Railway/provider?” or a remote-only project with no checkout: use inventory <binding.json> --json with an explicitly reviewed bounded scope. Treat repository, domain and name as possible-match evidence only; exact matching and reviewed-external classification require a reviewed decision in the binding document.