history-author-acknowledge --all-actionable writes an irreversible audited disposition with no --dry-run, and the zero-selection error misnames the cause #1028

pm history-author-acknowledge --all-actionable commits an audited, immutable disposition over an unbounded selection with no way to preview it first.

What happened

I ran the command to find out what it would select — the help text describes the selector but not its size — using placeholder values I expected to be rejected or previewed:

$ pm --json history-author-acknowledge --all-actionable \
    --reviewer probe --reason probe --attributed-author probe
{
  "acknowledged": 108,
  "history_path": ".../.agents/pm/history/_workspace.jsonl"
}

That immediately appended a permanent disposition attributing 108 events across 60+ items to a reviewed principal named probe, with the review evidence recorded as the string probe.

Why this is worse than a normal accidental mutation

Every other destructive-ish surface in the CLI has a preview. pm delete has --dry-run, pm update-many has dry-run plans and rollback checkpoints, pm close-many has both, pm assurance has --dry-run, pm history-compact operates on bulk selectors. history-author-acknowledge has neither a --dry-run nor a rollback, and it is the one command whose entire purpose is to write audit records:

$ pm history-author-acknowledge --help | grep -c dry-run
0

The output is also the only signal of scope — acknowledged: 108 arrives after the write. There is no way to ask "what would --all-actionable select?" without selecting it.

The correction path is undiscoverable

--all-actionable cannot be used to fix it, because the events it selected are no longer actionable:

$ pm --json history-author-acknowledge --all-actionable \
    --attributed-author "..." --reviewer "..." --reason "..."
{
  "code": "history_author_acknowledge_required_values_missing",
  "detail": "Author acknowledgment requires events, reviewer, attributed_author, and reason."
}

The error names four missing values, three of which I passed. The real cause — the selection resolved to zero events — is not stated, so the obvious reading is "my flags are wrong" rather than "there is nothing left to select".

Re-acknowledging the same coordinates explicitly does work and is the actual fix, but only if you already know the coordinates. I recovered mine by parsing the context.author_acknowledgment.events array out of the disposition record in _workspace.jsonl and rebuilding 108 --event item:line flags. That works, and it is not something the CLI surface points you toward.

Requests

1. Add --dry-run to history-author-acknowledge, printing the resolved event coordinates and count without writing. This is the whole fix for the primary problem.
2. When a selector resolves to zero events, fail with a distinct code (e.g. history_author_acknowledge_no_actionable_events) rather than ..._required_values_missing. The current message misattributes the cause.
3. Consider requiring --reviewer/--attributed-author to be non-trivial, or at least echoing the resolved count and a confirmation-shaped receipt for selections above some size. An audited attribution over 108 events across 60+ items reads the same as one over a single event.
4. Document that a disposition can be superseded by re-acknowledging the same coordinates, and that context.author_acknowledgment.events in the workspace history is where the coordinates of a prior disposition can be recovered.

Why it matters for agents

An agent exploring an unfamiliar command surface will run it to see what it does — that is the normal discovery loop, and every other bulk command in this CLI makes that loop safe. Here the discovery step is itself an irreversible audited write, and the resulting record actively misinforms whoever later reads the audit trail. Point 1 alone removes the trap.

Reproduced on pm-cli 2026.8.15, Linux, an 682-item workspace with 1217 pre-authorship-recording unknown-author events.