pm init <name> in a directory under an existing tracker targets the ancestor, and the remediation does not mention the flag that fixes it #841

What happened

Creating a new package inside a directory that happens to sit under another tracker, I ran the obvious thing from inside the new package directory:

$ cd /path/to/parent/fleet/new-package
$ pm init new-package --yes
Error: Refusing to update existing tracker settings at /path/to/parent/.agents/pm without --force.

The refusal itself is correct and valuable — it stopped me from rewriting a long-lived tracker's id_prefix, which is exactly the corruption the guard describes. No complaint about the guard.

The problem is that pm init walked up to find a tracker, and the message never says so. Reading it, my first hypothesis was that a tracker already existed in the current directory. It did not; .agents/pm was absent. Nothing in the output distinguishes "you already have a tracker here" from "there is one four levels above you and that is the one I was about to write to".

The next steps offered are:

- If you meant to initialize a sandbox tracker, pass a path-like positional such as ./sandbox-pm or /tmp/pm-test.
- If you intentionally want to rewrite this existing tracker's init-managed settings, rerun with --force.

Neither is what I wanted. I wanted a new tracker in the current directory, which is the ordinary reason to run pm init with a name. The path-like positional creates a tracker at a subdirectory of the found root, not at $PWD/.agents/pm. What actually worked:

$ pm init new-package --yes --pm-path "$PWD/.agents/pm"

--pm-path is not mentioned anywhere in the error.

Why it matters for agents specifically

An agent bootstrapping a package cannot tell from this output whether the correct recovery is --force (destructive, and here it would have been wrong), a path positional (creates the tracker in the wrong place), or something not listed. Two of the three offered paths would have produced a bad outcome, and the safe one is absent. That is the shape of error message an agent guesses its way through.

What would help

1. Name the resolved root and say it was found by walking up: "No tracker in the current directory; found one at /path/to/parent/.agents/pm by searching ancestors." The distinction is the whole diagnosis.
2. Add the intent that is missing: "To create a new tracker in the current directory, pass --pm-path \"$PWD/.agents/pm\"."
3. Consider whether a bare pm init <name> in a directory with no tracker of its own should prefer the current directory rather than an ancestor. Ancestor discovery is right for every other command — it is how pm list finds your project from a subdirectory — but init is the one command whose purpose is to create, so inheriting the ancestor is surprising.

Environment

pm-cli 2026.7.29, Node 22. Reproducible with any nested layout: init a tracker at a parent, then mkdir child && cd child && pm init child --yes.