pm test --remove reports ok:true and removes nothing when the linked test's command contains a comma or equals sign, so an entry pm itself wrote cannot be removed

Reproduced on 2026.8.7; the selector grammar is unchanged on 2026.8.11.

Reproduction

pm init rm --pm-path /tmp/w/.pm
ID=$(pm create --type Task --title Probe --pm-path /tmp/w/.pm --json | jq -r .id)
pm test $ID --add-json '[{"command":"npm test"},{"command":"name=x,result=pass"}]' --pm-path /tmp/w/.pm
# 2 linked tests

pm test $ID --remove "command=npm test"            --pm-path /tmp/w/.pm   # ok: true → 1 left  ✅
pm test $ID --remove "command=name=x,result=pass"  --pm-path /tmp/w/.pm   # ok: true → 1 left  ❌

The second call reports success and changes nothing. Every selector form behaves the same way — bare value, command= prefix, and - for stdin:

selector	result
`command=name=x,result=pass`	`ok: true`, no removal
`name=x,result=pass` (bare)	`Invalid argument value`
`-` with the same text on stdin	`ok: true`, no removal

Why this is worse than a selector limitation

The unremovable value is one pm produced. --add-json accepted {"command":"name=x,result=pass"} without complaint and stored it verbatim, and the name=…,result=… shape is what the linked-test records in real trackers look like. So the CLI writes an entry through one command that a sibling command can never select. Add and remove disagree about the grammar, and add is the permissive one.

The cause looks like the selector being parsed as key=value pairs on , before the value is taken: command=name=x,result=pass splits into command=name plus a stray result=pass, which matches no entry. There is no escaping or quoting documented in pm test --help that would let a value containing , or = through.

The part that costs the most

ok: true on a no-op mutation. An agent has no way to tell a removal that matched nothing from one that succeeded — the receipt is identical. I only noticed because I re-read the .toon afterwards; a script that trusts the receipt reports the record as cleaned and moves on.

The concrete case: pm-rl-cnc0 carried a linked test named promotion rethrows a non-race claim failure on the approval item recording result=pass. That test was deleted when the implementation it covered was replaced, so the item asserts a passing result for a test that no longer exists — the exact stale-current-state problem a code reviewer flagged the file notes for. The file notes were fixable with pm files --remove/--add. The test entry cannot be fixed through the CLI at all, and hand-editing the .toon would break the history chain that pm health --strict-exit verifies. So the item stays wrong, with a note explaining why.

Suggested fixes, in order of value

Never report ok: true for a removal that matched nothing. Either fail with no linked test matched <selector>, or return a receipt that distinguishes them (removed: 0). This is the part that turns a selector bug into silent data rot, and it applies to pm files --remove and pm docs --remove equally.
Make the selector able to address anything --add/--add-json accepts. An index selector (--remove-index <n>, matching the 1-based --list order that --only-index already uses) sidesteps the grammar entirely and is the smallest complete fix.
Failing that, document an escape for , and = in pm test --help, or have --add-json reject a command containing the delimiters rather than storing something unaddressable.

Related in spirit: #979 (a collection command misdiagnosing its own argument grammar).

Environment

@unbrained/pm-cli 2026.8.7, Node 22/26, Linux.

🔗 Related PRs

#40 - Never block agents: close-via-update, semantic fallback, create form, calendar --date crash [closed]
#51 - Polish CLI ergonomics, delete safety, and templates dedup [closed]
#260 - Strict unknown-key rejection across structured CSV/markdown parsers (GH-258) [closed]
#475 - Improve package install and annotation agent UX [merged]
#499 - Harden SDK schema-driven input fidelity and package preflight [merged]

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

Create Plan

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

Canonical pm item: pm-m0b7h8. It is the open SDK/CLI lossless linked-test mutation owner and is linked to the structured-parser, append-order, annotation-recovery, and CLI ergonomics lineage.

Still reproduces on 2026.8.13, and the documented stdin escape hatch does not work either.

Hit this today trying to remove two entries I had just written with --add-json:

# CSV form
pm test pm-rl-g3k0 --remove "command=name=a blank or whitespace-only parent normalizes to null before the seed check,result=pass"
# -> ok: true, entry count unchanged (4 -> 4)

# stdin form, per --remove's own help text ("or - for stdin")
printf 'command=name=a blank...,result=pass\n' | pm test pm-rl-g3k0 --remove -
# -> ok: true, spawn_error: 0, entry count unchanged (4 -> 4)

Both report success. Neither removes anything.

What makes this bite harder than a normal parsing bug: the value that cannot be removed is the cohort's own documented convention. command: "name=<test title>,result=pass" necessarily contains both a comma and an equals sign, so every entry written in the recommended form is unremovable. --add-json exists precisely because --add misparses that form — but there is no --remove-json counterpart, so entries can be created safely and never deleted.

The practical consequence is that a mistake in a linked-test name is permanent. In my case two entries recorded descriptions of assertions rather than real test titles. The assertions are real and passing, but the names do not match any test("...") in the suite — exactly the kind of untraceable claim linked tests exist to prevent. I could add the two correct titles; I could not remove the two wrong ones, so the record now carries both plus a note explaining why.

Suggested fixes, in order of preference:

--remove-json, mirroring --add-json. Unambiguous, and symmetric with the creation path that already had to solve this.
Index-based removal — --remove-index <n> against --list order. --only-index already exists for --run, so the addressing concept is present.
At minimum, make a no-op removal report ok: false with a message naming the delimiter problem. Silent success is what turns this from an annoyance into permanent bad data — nothing in the output suggests re-reading the .toon is necessary.

Environment: pm-cli 2026.8.13 (also reproduced on the 2026.8.7 pin), Node 22, Linux.

Record the real test titles behind two claims, and note the two that …

Record test commands with a portable pm path, not an absolute host path

merge: never commit a conflicted tree; leave durable unmerged state (#27

Implement recursive self-improvement: generation lineage, an approved…

Resolved and verified in PR #1016's delivered lineage. Canonical tracker evidence: pm-m0b7h8. The supported removal contract preserves delimiter-bearing commands, exposes stable index removal and effective counts, and refuses zero matches.

Data point from pm 2026.8.23: pm test --remove did remove a command containing both , and = for me, so whatever the residual case is, it is narrower than "the command holds a comma or an equals sign".

The command I removed successfully:

for d in fleet/pm-*/; do n=$(node -p "require(\"./$d/package.json\").name" 2>/dev/null) || continue; m=$(git -C $d show origin/main:package.json | python3 -c "import json,sys;print(json.load(sys.stdin)[\"version\"])"); r=$(npm view "$n" version 2>/dev/null); [ "$m" = "$r" ] || echo "DIVERGED $n main=$m npm=$r"; done

Passed to --remove verbatim (read back out of --json and shell-quoted), it went from 1 recorded test to 0. A simpler sibling (bash scripts/check-registry-vs-main.sh, no comma or equals) also removed correctly in the same session.

Not claiming the issue is fixed — I did not reproduce the original failing shape, and I only exercised the single-entry case. But if the fix landed, the reproducer in the issue body may now need a more specific trigger than the punctuation to still demonstrate it. Happy to test a specific candidate shape if one is posted.

Navigation Menu

Repository navigation

pm test --remove reports ok:true and removes nothing when the linked test's command contains a comma or equals sign, so an entry pm itself wrote cannot be removed #982

Reproduction

Why this is worse than a selector limitation

The part that costs the most

Suggested fixes, in order of value

Environment

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

pm test --remove reports ok:true and removes nothing when the linked test's command contains a comma or equals sign, so an entry pm itself wrote cannot be removed #982

Description

Reproduction

Why this is worse than a selector limitation

The part that costs the most

Suggested fixes, in order of value

Environment

Activity

coderabbitai commented on Aug 11, 2026

unbraind commented on Aug 11, 2026

unbraind commented on Aug 13, 2026

unbraind commented on Aug 15, 2026

unbraind commented on Aug 26, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions