pm list --all is an alias for --no-truncate, so it silently returns only open items while reporting completeness: complete #793

Summary

pm list has two unrelated options whose names both read as "everything":

• --all — an alias for --no-truncate, i.e. pagination only ("return every matched row,
  overriding any --limit").
• --status all — the actual "no status filter" switch.

pm list defaults to open statuses. So pm list --all returns only the open items, and
the JSON envelope labels that partial view "completeness": {"status": "complete"}.

An agent that types the intuitive thing gets a wrong answer plus an explicit assurance the
answer is complete. Every other command rejects --all outright, which makes pm list
accepting it read as confirmation that it means what it looks like.

Reproduction (2026.7.28)

Against a real repo — 26 items on disk, 1 open:

$ git clone --depth 1 https://github.com/unbraind/pm-ops.git && cd pm-ops
$ find .agents/pm -name '*.toon' | wc -l
26

$ pm list --all --json | jq -c '{count, total, completeness: .completeness.status}'
{"count":1,"total":1,"completeness":"complete"}

$ pm list --status all --json | jq -c '{count, total}'
{"count":26,"total":26}

--all is not rejected, and it is not in the flag list — it appears only as a parenthetical
on --no-truncate:

$ pm list --help | grep -n -- '--all'
46:                               (alias: --all)

Meanwhile the same flag on any sibling command errors cleanly:

$ pm show ops-g3br --all;  echo $?
{ "type": "urn:pm-cli:error:unknown_option", "code": "unknown_option", ... }
2
$ pm activity --all;       echo $?   # 2
$ pm notes ops-g3br --all; echo $?   # 2

So the failure mode is specific to pm list: exit 0, no diagnostic, silently narrowed result.

Why this matters

This is a context-integrity bug, not just a naming nit. The three signals an agent uses to
decide whether it has the whole picture all agree, and all are wrong:

total reporting the post-filter count is defensible on its own, but combined with
completeness: "complete" there is no field left that would let a caller notice the gap. An
agent summarizing "what is in this project" will confidently report the 1 open item and never
learn the other 25 exist.

The collision is also self-reinforcing: --status all establishes that "all" is this
command's word for "no filter", which makes bare --all look like the general form of it.

Suggested resolution

Preferred: drop the --all alias. --no-truncate already says what it does, and the
alias only exists to be misread. pm list --all would then error like it does on every other
command, and the error can suggest --status all.

If the alias must stay, either of these would defuse it:

1. Rename it to something scoped to pagination (--no-limit, --unpaginated) and list it as
   a first-class flag in --help rather than a parenthetical.
2. Make completeness account for the active status filter — e.g. a
   filtered_out_count, or status: "filtered" whenever a default (not user-specified)
   filter excluded rows. This is the more generally useful fix: it would also catch the case
   where an agent forgets --status all without using --all at all.

Independently, it would help if total were documented as post-filter, since alongside
count it reads as the workspace total.

Environment

• @unbrained/pm-cli 2026.7.28
• Node 24, Linux
• Reproduced on a fresh shallow clone of unbraind/pm-ops