feat(doctor): add Pgserve (canonical backbone) check section

[namastex888]

Summary

Adds a Pgserve (canonical backbone) section to genie doctor, mirroring omni doctor's pgserve-canonical check so operators see the same shared-backbone visibility from both halves of the canonical-stack.

Pgserve (canonical backbone):
  ✓ pgserve binary canonical port 8432
  ✓ pgserve under pm2 online — shared backbone for genie-serve + omni-api on :8432

…or, when something is off:

Pgserve (canonical backbone):
  ! pgserve binary not on PATH (or `pgserve port` failed)
    Install canonical pgserve: bun add -g pgserve@^2.1.0 (then run `pgserve install`...)
  ! pgserve under pm2 binary present but not registered under pm2
    Register canonical pgserve: pgserve install

Probes

• Binary detection via pgserve port (NOT --version — that flag doesn't exist in pgserve@^2.1.0 and false-negatived in historical doctor implementations; same lesson surfaced in omni doctor --fix on 2026-04-30 → omni#580).
• Pm2 registration + online status via pgserve status --json.

Severity

Both checks are WARN, never FAIL. Genie can auto-spawn its own daemon as a fallback for fingerprint-routed CLI commands, so a missing canonical pgserve doesn't break local development — it just means genie isn't sharing the backbone with omni and other automagik services on this host.

Live-validated

Tested on this canonical-pgserve-running server: both checks PASS, section renders cleanly, exit-code unchanged.

Pairs with

• fix(install): bake DATABASE_URL env into ecosystem config when canonical pgserve is detected #1604 — genie install bakes DATABASE_URL env into ecosystem config when canonical pgserve is detected. This PR is the "did it work?" surface for that one.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 9100964c-898d-4d3f-a47a-3fb8c48fd5a5

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/doctor-pgserve-canonical

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Code Review

This pull request adds a checkPgserveCanonical function to the doctor command to verify the pgserve binary's presence, its PM2 registration status, and its listening port. The review feedback recommends replacing synchronous execFileSync calls with Bun's asynchronous shell API to prevent blocking the event loop, which aligns with the function's asynchronous implementation.

[gemini-code-assist]

The checkPgserveCanonical function is marked as async, but it uses the synchronous execFileSync for probing the binary. For consistency with other async checks in this file (like checkTmux) and to avoid blocking the event loop unnecessarily, consider using Bun's asynchronous shell primitive ($). The use of a hardcoded timeout is acceptable here to prevent performance issues during the probe, as per repository guidelines.

    const out = await $("pgserve port").timeout(3000).quiet().text();

References

1. It is acceptable to use hardcoded numeric limits (magic numbers) in non-critical fallback logic, especially when they serve as intentional caps to prevent performance issues like excessive I/O.

[gemini-code-assist]

Similar to the binary probe above, consider using Bun's asynchronous shell primitive ($) instead of execFileSync to maintain consistency within this async function and the rest of the file's async check logic. The hardcoded timeout is permitted in this context to prevent the process from hanging.

    const status = await $("pgserve status --json").timeout(3000).quiet().text();

References

1. It is acceptable to use hardcoded numeric limits (magic numbers) in non-critical fallback logic, especially when they serve as intentional caps to prevent performance issues like excessive I/O.