pm health returns ok:false with exit code 0 for a warn-only result, so every fresh clone fails a .ok gate that GH-775 was meant to fix #785

Summary

On 2026.7.28, pm health --json reports ok: false when the only finding is a warn-severity check, while simultaneously exiting 0. A caller gating on .ok fails; a caller gating on $? passes. Both are documented ways to consume the command.

Because empty directories cannot be tracked by git, this fires on every fresh clone of every pm repo, which I believe is the exact scenario GH-775 set out to fix.

Reproduction (2026.7.28, clean workspace)

$ pm init --prefix wt
$ pm health --json | jq '.ok, [.checks[] | select(.status != "ok")]'
true
[]

$ rmdir .agents/pm/epics          # what a fresh clone looks like: git drops empty dirs
$ pm health --json | jq '{ok, warnings, directories: [.checks[] | select(.name=="directories") | .status]}'
{
  "ok": false,
  "warnings": ["missing_directory:epics"],
  "directories": ["warn"]
}

$ pm health --json > /dev/null; echo "exit=$?"
exit=0

Every other check is ok. The single warn sinks the top-level ok.

Why this is a problem

GH-775 correctly reclassified absent empty type folders as non-material — the directories check is now warn rather than an error, and the exit code is 0. But the top-level ok field was not brought along, so the headline signal still says the workspace is unhealthy.

The practical effect is that a pm health-based CI gate can never go green on a fresh checkout. In our fleet the affected directories are epics and extensions — both legitimately empty in most repos, both therefore absent after clone, both permanently reported.

The two signals disagreeing is the sharper half of the bug. From one invocation:

An agent has no way to know which to trust, and the two are equally reachable from the docs.

Suggested resolution

Make ok mean "no blocking finding", consistent with the exit code — i.e. ok: false only when some check is error-severity, with warn surfacing through warnings[] and the per-check status as it already does.

If ok is instead intended to mean "perfectly clean, warnings included", then the exit code should match it, and there should be a separate blocking-only field for gating — but the first reading seems much more useful, and matches what GH-775 was aiming at.

Either way it would help to state in pm health --explain which field is the supported gate, since right now .ok and $? are both plausible and they disagree.

Environment

• @unbrained/pm-cli 2026.7.28
• Node 24, Linux
• Reproduced in a workspace created fresh by pm init in this session, no extensions installed