Summary

pm schema add-field accepts reserved built-in field names (e.g. customer_impact, which is also the built-in --customer-impact create flag) with no warning. When a later extension registers the same name, creates break with a misleading "Extension item field 'X' collides with reserved item metadata" error that does not name the collision partner.

Impact

Two-part problem:

1. No early warning: add-field customer_impact succeeds silently even though customer_impact is reserved built-in metadata. A user/agent has no signal they've chosen a reserved name until much later.
2. Misleading runtime error: when the collision fires, the message says "collides with reserved item metadata" — accurate technically, but it doesn't tell the user that (a) the name is reserved, or (b) that a config field and an extension field are both claiming it. The user is left guessing.

In the ContextOps dogfood this combination broke all pm create Task calls (even creates that never used the field) once both the config field and the toolkit extension were present. Minimal reproduction was elusive (a minimal extension did not trigger the all-creates-break behavior), so the worst symptom appears to depend on fuller configuration; the misleading-error and no-early-warning problems reproduce reliably.

Environment

• pm 2026.7.4, Node v22.20.0, Linux x86_64.

Reproduction (reliable part)

export PM_PATH="$(mktemp -d)/.pm"
pm init --defaults --agent-guidance skip
pm create --help | grep customer-impact        # it IS a built-in flag
pm schema add-field customer_impact --type boolean --commands create,update --description "x"
# -> "Registered custom field customer_impact" with NO warning that the name is reserved

Expected

• add-field warns or rejects reserved names with a message like: "customer_impact is a reserved built-in field name; choose a different key."
• If a runtime collision does fire, the error names both registrants (config field vs extension field).

Actual

• add-field silently accepts reserved names.
• Runtime collision error is generic and doesn't name the collision partner.

Evidence

• reports/findings.jsonl slug add-field-accepts-reserved-name
• found in Phase 13 of the ContextOps dogfood after the toolkit extension was installed alongside the Phase 4 config field; resolved by renaming to ctxops_customer_impact.

Workaround

Namespace custom field names that might collide (e.g. ctxops_customer_impact instead of customer_impact).

Proposed improvement

1. Maintain a reserved-name set in the schema layer and warn/reject at add-field time.
2. In the collision error, name both the config field and the extension field involved.

Dogfood context

Found in Phase 13 of the ContextOps dogfood when pm create Task broke after installing the pm-contextops-toolkit extension that registered customer_impact (already a config custom field + a built-in flag).