[ako]

Closes #1690. Closes #1646. Closes #1697 (mirror of mendixlabs#1650).

References to a member or association that does not exist passed check and exec; only mx check noticed — and in #1690 the model was written broken. One commit per issue on one shared core.

Shared core: memberVerdictOver (new member_verdict.go) is the single walk over an entity's generalization chain. Exec's builder reads each link from the backend (backendMemberModel), check from the script with the backend as fallback (scriptMemberModel) — the overlay changes how a link is read, never the rule. The existing CREATE/CHANGE member check (resolveMemberOnEntity, #1048) now delegates to it. Inherited members, System members and members of modules that are not loaded are not refused.

Measurement trap worth knowing: while any CE1613 exists in an app, mx check reports no CE0117 and no CE0226. Every control was re-measured in an otherwise clean app — one earlier "clean" result was masked (an aggregate over createdDate is CE0226, now refused).

#1690 — a bare association in a retrieve was stored with an empty module

retrieve $C from $O/Ord_Cust; passed check and exec and was stored as .Ord_Cust (CE1613; describe printed $O/.Ord_Cust, which does not parse). Cause: the builder built s.Source.Module + "." + s.Source.Name; check never looked at a bare retrieve association, and MDL-RETRIEVE03 guessed the start entity's module. Fix: a bare name resolves when exactly one association of that name has an end on the start entity's generalization chain (either end; specializations inherit) and is stored qualified; no match or several are refused by check and exec with the qualified spelling to write, and exec refuses a bare name it cannot resolve rather than writing .Name. Describe's speller and MDL-RETRIEVE03 use the same resolver, so a re-run is Unchanged.
Verified: PedApp tests (check and exec must agree): stored bytes, describe, re-run; owner side, TO side, specialization, inherited cross-module association, Administration.Account/UserRoles → System.UserRoles; script-declared association; missing, not-an-end, ambiguous, unknown start entity. Reverted: every case stores .Ord_Cust. 11.13.0: before CE1613 and AssociationId ".Ord_Cust"; after 0 errors, "Shop.Ord_Cust", describe $O/Shop.Ord_Cust.

#1646 — find / filter / sort / aggregate by a member the entity lacks

Cause: the builder fabricated <entity>.<name> for an unresolved member (resolveMemberChange fallback via resolveListOperationMember, sort, aggregate). Fix: the builder refuses a member established as missing with check's own message (listMemberRefusal, asserted identical); check's listMember uses the same verdict. Sibling fixed: the aggregate never walked the generalization chain — sum $sl by Total with Total inherited was stored as Shop.SubOrd.Total (CE1613) although the member exists; it now qualifies with the declaring entity. A sort may read createdDate/changedDate where the root stores them (clean); an aggregate cannot (CE0226, measured) — refused, naming CE0226.
Verified: refusals for the four reported shapes, maximum by a missing member, bare owner (hint System.owner), aggregate over createdDate; controls (own/inherited attributes, bare and inherited cross-module associations #1637, System.owner #1629, sorts on stored system dates, an untyped call-result list, a member the script adds with ALTER first). Reverted: refusals accepted, aggregate stores SubOrd.Total. 11.13.0: before 4× CE1613; after refused; an 11-statement control microflow builds at 0 errors.

#1697 — $Var/<member> in an expression for a member the entity lacks (incl. id)

Cause: nothing resolved an expression path's member steps (the type pass infers an unknown attribute as unknown, silently). Fix (check side, in the reference pass, which exec's preflight also runs): validate_flow_member_refs.go follows each $Var/... path through the same verdict across association hops and reports a missing attribute, a bare association, an association that does not exist or does not start at the entity, and id (hint: compare the objects, or CommunityCommons.getGUID). Paths are collected by reflecting over each statement's fields, so new statement kinds are covered. The builder still writes expressions verbatim, so exec --no-check does not refuse these.
Verified: the 12 shapes measured as CE0117 on 11.13.0 are reported; 11 measured-clean shapes are not (incl. $S/createdDate on a specialization, a bare hop target). Reverted: every report case fails. 11.13.0: before 2× CE0117; after refused by check and exec.

All

• All 81 non-.fail doctype scripts give identical output with baseline and fixed binaries (check, and check -p <blank 11.13> --references); 863 bug-test scripts swept — the one change (829-cross-module-assoc-expression, a bare hop target) was fixed.
• Full go test ./..., go vet, gofmt; CI's doc checks pass locally. Bug-tests references-{1690,1646,1697}-*.mdl; findings recorded; write-microflows/reference/data-operations.md, docs-site activity-types.md.
• Merging with fix: check misses CE1406 for Hidden entities of Protected modules and on call results (#1699, #1701) #1734: one textual conflict in validate_member_refs.go (fix: check misses CE1406 for Hidden entities of Protected modules and on call results (#1699, #1701) #1734 adds sc to a walkTypedFlow call; this PR adds a line inside its callback) — the combination was resolved in a scratch merge and passes mdl/executor + the conformance gate; once both land, these checks also judge call microflow results.

Noticed, not fixed

1. In an expression, $O/System.owner/Name is CE0117 (the builder does not insert the System.User step).
2. walkTypedFlow does not descend into enum-split / inheritance-split case bodies, so every member check is silent inside case bodies.
3. The Protected-module (fix: check misses CE1406 for Hidden entities of Protected modules and on call results (#1699, #1701) #1734) check skips a bare retrieve association; now that bare names resolve, a bare name to a Hidden association of a Protected module is not checked for CE1406.
4. walkTypedFlow does not type a bare-association retrieve's result.
5. Under exec --no-check, CREATE/CHANGE with a missing member and a bad expression member are still written as-is.
6. A bare association inside an expression is reported, not auto-qualified as a retrieve now is.

🤖 Generated with Claude Code