fix(check): refuse a list retrieved over an association used as an object (mendixlabs/mxcli#1516)

[ako]

Fixes mendixlabs#1516 (#1398).

Measured first (11.15.0 and 11.6.6 identical)

Line→Header Reference, retrieved from the Header (the "one" side):

Shape	mx check
retrieve $L from $h/Tmp.Line_Header; unused (the issue's literal repro)	clean
$n = count($L)	clean
declare $n Integer = $L/Qty	CE0117
change $L (Qty = 5)	CE7247 "… is of type List of Tmp.Line, but should be of type Object"
call microflow Tmp.Sub(line = $L) (Sub takes one Line)	CE0117

So the bare list retrieve and count are fine on 11.15 too. The build fails only once the list is used as an object, and that is what check passed.

1. Object use of an association list

• Cause: MDL-RETRIEVE03 only tracked database retrieves. The builder knew list vs object, but typed an object use leniently and wrote it.
• One shared rule: associationRetrieveYieldsList(refSet, ownerBoth, fromToSide), used by both the builder and the new check.
  • ReferenceSet: a list from either end.
  • Reference from the FROM side: one object.
  • Reference from the TO side: a list, unless owner is Both.
• Builder behaviour change: an owner-Both Reference followed from the TO side, and not used as a list, is now typed as an object (previously a list). This matches the MDL-ASSOCDS01 measurements and a control that builds clean on both versions.
• New check validateAssociationRetrieveListUse, in check -p, --references and exec preflight:
  • It tracks object variables' entities and resolves which end of the association the start variable is on.
  • It reports a member path, a change, or passing the list to a single-object parameter, as MDL-RETRIEVE03.
  • The suggested fix is retrieve … where [Assoc = $h] first; or head/loop; both measured clean.
  • Anything it cannot establish stays silent.
• No-project tier: MDL-RETRIEVE03 uses the same walk. flowParam gained a List field.

2. MDL043 on an enumeration declare

• Measured: declare $X Tmp.SomeEnum = empty, with the enumeration in the project, builds at 0 errors on 11.15. Describe prints declare $X enum Tmp.SomeEnum = empty, so MDL043 was refusing a valid script.
• Change: when the project or the script shows the name is an enumeration, MDL043 becomes a warning that leads with the enumeration message and describe's spelling.
• Unchanged: without -p, for an entity, or for a name that is both, it stays the object error. Its hint now mentions enum X.

3. Docs

• mxcli syntax microflow.variables: the conditional-create idiom and the enum declare spelling. Measured on 11.15: creating the same name in both branches is CE0111. The forms that build are one create with if … then … else values, or a sub-microflow that returns the object.
• MDL063 names the idiom when the duplicate is a create.
• microflow.retrieve: a note on what an association retrieve returns.
• Also updated: error-messages.md and the cheatsheet-variables skill.

Tests

• TestAssociationRetrieveListUsedAsObject: 5 failing shapes and 5 controls.
• TestAssociationRetrieveYieldsList.
• TestMDL043_EnumerationNamedBare: 2 cases and 3 controls.
• TestMDL063_ConditionalCreateNamesTheIdiom.

Revert check:

• With the list binding stubbed, the 5 MDL-RETRIEVE03 cases fail ("got 0").
• With the enum branch stubbed, the enum cases fail.

mx check:

	Before	After
11.6.6	3 errors (CE0117 ×2, CE7247)	exec refuses; 0 errors
11.15.0	3 errors (CE0117 ×2, CE7247)	exec refuses; 0 errors

make build, make test, make lint, make check-findings and make check-skill-mdl pass. A finding file and mdl-examples/bug-tests/1516-retrieve-list-over-association.mdl are included.

For review

• MDL043 severity: an enumeration named bare went from error to warning, because it builds. Keep it an error with only the wording changed?
• Not covered: a list passed to an object parameter is detected only when the argument is a bare $L and the callee's signature resolves.

🤖 Generated with Claude Code

https://claude.ai/code/session_01W3x8Fyvir8kLyPgJs1BDmF

---

Generated by Claude Code