The command passes what it is given to WP_Query, so a good deal works that
nothing mentions. This documents the arguments that filter on what the
command displays, the way #642 did for `wp site list`.

Three of the fields it displays are named after the wp_posts column rather
than the WP_Query argument that filters on it, and passing the column name
reached WP_Query as an argument it does not know: it was dropped, and every
post came back - a filter that reads as if it works and quietly does not.

    $ wp post list --post_title='Hello world!' --format=count
    2

wp-cli resolves parameter aliases before a command runs, so declaring them
in the synopsis is enough to make the column spellings work:

- --title, with --post_title as an alias
- --name, with --post_name as an alias
- --author, with --post_author as an alias
- --p, with --ID as an alias

Everything else here already filtered and is only being written down. Each
one was checked against WP_Query rather than assumed: 'post__in',
'post_name__in' and 'author__in' are left out because they are only read as
arrays, so a comma-separated value would quietly match on the first entry
alone, and making them usable is more than documentation.

'--name' keeps WP_Query's behaviour of making the query a single-post one,
which returns a draft only to a user who can edit it. Running as no user,
WP-CLI cannot, so the note says to filter drafts another way rather than
rerouting the argument to mean something WP_Query does not.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014SSZzqMJRDTiLiDxQEPYcL

The note on `--name` said to filter drafts some other way, which was a
detour. WP_Query hands a draft from a single-post query to a user who can
edit it, and the global `--user` argument is how WP-CLI becomes one.

Checked rather than assumed, because the earlier advice happened to work for
the wrong reason:

    wp post list --name=beta --field=ID                 -> empty
    wp post list --name=beta --post_status=any --field=ID -> empty
    wp post list --name=beta --user=1 --field=ID        -> found

'--post_status=draft' also reaches it, but only because naming the post's own
status sidesteps the check rather than satisfying it, and '--post_status=any'
does not. '--user' is the answer to what the note is actually about.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014SSZzqMJRDTiLiDxQEPYcL

'any' is not "everything". WP_Query reads it as everything registered without
'exclude_from_search', for post types and post statuses alike, and this
command defaults post_status to it.

The practical consequence had gone unsaid: 'trash' and 'auto-draft' carry
that flag, so a trashed post is absent from `wp post list` until its status
is named. Checked rather than taken on faith:

    post_type=any, exclude_from_search=false type  -> included
    post_type=any, exclude_from_search=true  type  -> excluded
    post_status=any, draft                         -> included
    post_status=any, trashed                       -> excluded
    post_status=trash, trashed                     -> included

Raised by CodeRabbit on the pull request.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014SSZzqMJRDTiLiDxQEPYcL