Re-probe BUG-76 and BUG-121 on mxcli v0.21.0 — both still open, and BUG-76's diagnosis was wrong

[MendixMau]

Direct lane (changes to skills/, bug-logs/, bin/, project-bin/, project-tests/, pipelines)

What changed and why (one paragraph):

mxcli v0.21.0 shipped on 2026-09-06, and a project that has been building around two workflow
blockers needed to know whether it could stop. It cannot: both are still open, and this PR records
that with the evidence, plus one correction to a diagnosis this log has been carrying since
2026-08-13. BUG-121 (PARALLEL SPLIT) is unchanged in the strongest sense available — the same
probe script executed through v0.20.0 and v0.21.0 on two separate throwaway copies produces a
byte-identical workflow unit, zero diff lines from bson dump after blanking the $ID GUIDs,
so the runtime behaviour cannot have changed and no live run was needed to settle it. That probe
also turned up something worth handing to whoever fixes it: the path contents are present in the
stored BSON on both versions (ParallelSplitActivity → ParallelSplitOutcome → Flow →
SingleUserTaskActivity), so the entry's own title names the symptom rather than the mechanism, and
the mechanism is still unidentified. BUG-76 (DECISION) is not the unconditional storage
corruption this log describes: it is a pincer between two spellings, where a bare outcome passes
mxcli check and makes the model unloadable, and a qualified one is rejected by mxcli's own
MDL-WF03 yet loads clean via exec --no-check with a single CE0117 for the empty expression.
mxcli mandates the spelling the loader rejects and rejects the spelling it accepts — which is
exactly why this read as corruption when first filed, and which implies two independent fixes rather
than one. That correction was made on the source project on 2026-09-02 and never promoted here.

Field evidence — which real project this ran against / was observed in, and what it measured
or fixed there:

Observed on the same topbar-titled portal project the BUG-120–126 harvest came from, whose Phase-19
approval workflow is built sequentially because of these two defects. Probes ran on mxcli
v0.21.0 against Mendix 11.13.0, on throwaway full copies of the project — never the real
.mpr, since BUG-76's failure mode is a model that will not load at all. What each probe measured:

• BUG-121 — identical two-path split script through both binaries on two copies, then
  mxcli bson dump --type workflow on each and a normalised diff: 0 lines.
• BUG-76 — bare spelling: mxcli check passes, native mx check (11.13.0) throws
  StorageLoadException — "Enumeration value condition outcome in has an invalid value '' for
  property Value. The text 'Yes' is not a valid EnumerationValueIdentifier." Qualified spelling:
  MDL-WF03 rejects at check; exec --no-check then mx check gives 1 error, CE0117 at the
  decision. A deliberately non-existent enum value returned CE1613 while its valid sibling in
  the same decision resolved silently — which is how we know the qualified form genuinely binds
  rather than merely being tolerated.
• Not run: the toolkit test suites and any pipeline. Nothing here touches an instrument — the
  diff is three prose files plus the changelog line.

Two notes for the reviewer:

• This branch's earlier seven commits are already on master (the BUG-120–126 harvest, merged
  while this session was working, including the renumber from 113–119). The branch was reset onto
  that merged head and only this commit is new, so the PR is a single commit. My own genericisation
  pass was dropped as redundant — the merge review had already done it.

• BUG-76 is already filed upstream as CREATE WORKFLOW ... DECISION writes the outcome label as a raw string instead of an EnumerationValueIdentifier — project fails to load with StorageLoadException mendixlabs/mxcli#1031, so its update goes into the draft
  as a clearly-marked comment to post on #1031, rather than rewriting a body that no longer
  matches what is public. BUG-121's draft is still unfiled and carries the re-probe as a section to
  include when it is filed.

• No client data anywhere in the diff — verified with a grep for the project name and .mpr
  filename across the changed files; zero hits. The leak-guard pre-commit hook is not installed
  in this cloud clone, so it did not run and did not fire; bin/check-pr-discipline.sh was run
  manually and reports clean (changelog rides along, no BUG-number collisions vs origin/master).

• For a new/changed instrument: n/a — no instrument changed

• For a new skill: n/a — no new skill

• CHANGELOG.md line appended in this PR, crediting the source project

• New bug entries headed ## BUG-DRAFT-<slug>: — n/a: no new entries, this amends the existing
  BUG-76 and BUG-121 and takes no new number

---

Generated by Claude Code