an XPath constraint naming a member that does not exist (`[Mod.Entity_Attr = …]`) passes `check --references`; `exec` writes the page; `mx check` → CE1613 "The selected association … no longer exists"

[marclehane-creator]

Seen first on a real app (harness eval row 56: a 20B wrote WHERE [AgencyAndProgram.Program_IsArchived = true],
qualifying an attribute as if it were an association), then reproduced in isolation on
the isolation probe:

CREATE PAGE Bench.Probe_XPathBadMember
( Title: 'Probe XPath bad member', Layout: Atlas_Core.Atlas_Default )
{
  DATAGRID dg (DataSource: DATABASE Bench.Order WHERE [Bench.Order_Status = 'Open']) {
    COLUMN colOrderNo (Attribute: OrderNo, Caption: 'OrderNo')
  }
}

rung	result
check … --references	exit 0
exec	Created page Bench.Probe_XPathBadMember
mx check	[error] [CE1613] "The selected association 'Bench.Order_Status' no longer exists." at Data grid 2 'dg'

Bench.Order_Status is neither an attribute nor an association of Bench.Order (the attribute is
Status). --references validates the entity in the datasource but not the members named inside the
XPath constraint, although its catalog has them (✓ Attributes: 232, ✓ Associations: 48). Same
family as Issue 86 (CHANGE member) and Issue 84 (ContentParams path): the reference check stops at
the document/entity level and does not descend into member positions. Ask: resolve XPath member
names against the entity in --references mode — a qualified name that matches no attribute and no
association of the constrained entity is an error at rung 2.

---

mxcli 0.20.0, Mendix 11.12.x, Windows 11. Found while evaluating a self-hosted agent loop that drives check → check --references → exec → mx check; each item above was reproduced on a fresh copy of the fixture or app named.