Concurrent config/schema edits conflict (no merge driver) and pm validate reports ok:true by silently falling back to defaults — settings/schema silently lost #609

Summary

The workspace's shared JSON config/schema files — .agents/pm/settings.json and .agents/pm/schema/{types,statuses,fields,workflows}.json — are single git-tracked files with no merge driver. Two agents changing different config keys, or adding different custom types, both rewrite the same file → git conflict → invalid JSON with conflict markers. The failure is then masked: pm validate reports ok:true by silently falling back to defaults, so the merge gate is green while governance settings / custom schema silently revert or are lost entirely.

Distinct from #607 (item .toon files) — this is the config/schema layer.

Verified repro A — settings.json (pm 2026.7.18)

git checkout -b cfgA
pm config project set governance-metadata-validation-profile strict   --json >/dev/null
git add -A && git commit -m "A: profile strict"
git checkout -b cfgB main
pm config project set governance-require-close-reason disabled         --json >/dev/null
git add -A && git commit -m "B: close-reason disabled"
git checkout cfgA && git merge --no-edit cfgB          # CONFLICT in .agents/pm/settings.json (invalid JSON)
pm validate --json            # ok: true   (stderr: settings_read_invalid_json → fell back to defaults)
pm validate --strict-exit --json; echo $?   # rc=1   (this DOES catch it)
pm health --json              # ok: false  (also catches it)

Observed: default pm validate is blind (ok:true, silently using defaults — both agents' governance changes gone). --strict-exit returns rc=1 and pm health returns ok:false, so the corruption is detectable — but only if you know to use those, not via the obvious pm validate.

Verified repro B — schema add-type (data loss, no strict flag needed)

git checkout -b schA
pm schema add-type FeatureRequest --description A --folder featreqs --json >/dev/null
git add -A && git commit -m "A: add type"
git checkout -b schB main
pm schema add-type Hotfix --description B --folder hotfixes --json >/dev/null
git add -A && git commit -m "B: add type"
git checkout schA && git merge --no-edit schB          # CONFLICT in schema/types.json
pm validate --json      # ok: true
pm schema list --json   # neither FeatureRequest nor Hotfix present — BOTH custom types silently lost

Impact

Concurrent governance/schema evolution across branches is impossible without silent data loss, and the default integrity gate (pm validate) reports green on the corrupted result.

Suggested fixes

1. Generate .gitattributes entries + a JSON deep-merge driver for settings.json/schema/*.json (these are additive maps — key-level 3-way merge is well-defined and conflict-free for disjoint keys).
2. Make default pm validate fail (or at least warn loudly) when a config/schema file is present but unparseable, instead of silently substituting defaults and reporting ok:true. Falling back to defaults on invalid JSON is exactly the case a validator must surface.

Filed from a multi-agent merge stress test; reproduced independently on 2026.7.18.