pm init .gitignore hardcodes .agents/pm/ prefix — custom-root workspaces commit runtime cache and conflict on every merge #598

Summary

pm init writes its managed runtime/cache .gitignore block with the tracker root hardcoded to .agents/pm/, ignoring the actually-resolved tracker root. Any workspace whose tracker lives somewhere else (via --pm-path, PM_PATH, or a custom id/root) therefore has its runtime cache committed to git, which produces guaranteed merge conflicts and index churn in multi-agent / multi-branch workflows.

This is a follow-up to #514 (which fixed the malformed concatenated line but only for the default .agents/pm root — the hardcoded prefix itself was not addressed).

Environment

• pm-cli 2026.7.18 (npm @unbrained/pm-cli)

Reproduction

Default root — works correctly:

mkdir def && cd def && git init -b main
pm init --yes
cat .gitignore
# pm-cli:runtime-cache:start
# .agents/pm/runtime/
# .agents/pm/search/
# .agents/pm/locks/
# pm-cli:runtime-cache:end
pm create "x" --type Task --author t
git add -A && git status --porcelain | grep runtime      # empty — correctly ignored
git check-ignore -v .agents/pm/runtime/context-usage.jsonl
# .gitignore:2:.agents/pm/runtime/   .agents/pm/runtime/context-usage.jsonl   ✅

Custom root — silently broken:

mkdir cust && cd cust && git init -b main
export PM_PATH="$PWD/pm"
pm init --yes
cat .gitignore          # STILL writes ".agents/pm/runtime/" etc — WRONG PREFIX
pm create "x" --type Task --author t
git add -A && git ls-files pm/runtime/
# pm/runtime/context-usage.jsonl   ← TRACKED (not ignored)

Now two agents on two branches each touch items → pm/runtime/context-usage.jsonl, pm/search/*, pm/locks/* all diverge and conflict on every merge:

CONFLICT (content): Merge conflict in pm/runtime/context-usage.jsonl

Root cause

The generated block is a constant string prefixed with .agents/pm/ rather than being derived from the resolved tracker root (the same value resolvePmRoot() / --pm-path produce). Confirmed by diffing the block across default vs. custom-root inits — the block is byte-identical regardless of where the tracker actually is.

Impact

• Runtime caches (runtime/, search/, locks/) are version-controlled for any non-default root → every pm command mutates tracked files → churn on git status.
• Guaranteed, content-level merge conflicts on these worthless-to-merge files whenever two agents/branches touch the project — directly undermining the multi-agent concurrent-branch workflow pm otherwise encourages (--author, per-item history, etc.).
• Silent: nothing warns the user their runtime cache is being committed.

Suggested fix

• Derive the ignore paths in the managed block from the resolved tracker root (relative to the repo root / .gitignore location), not a hardcoded .agents/pm/.
• For workspaces already affected, pm validate/pm gc could detect tracked runtime-cache files and offer git rm --cached remediation.
• Consider also emitting runtime/** search/** locks/** via a root-anchored glob so a relocated root can't leak.

Confidence: high (root-cause verified by inspecting generated .gitignore for both root layouts + git check-ignore).