@@ -43,11 +43,19 @@ begin
 end;
 /
 
--- Negative control: explicit `on error continue` must survive equally.
-create microflow BugTest308.MF_CommitContinue (
-  $Item: BugTest308.Item
-)
-begin
-  commit $Item on error continue;
-end;
-/
+-- The `on error continue` case that used to sit here has been REMOVED, because
+-- it asserted something that does not build. Measured on 11.14.0: the statement
+-- stores `Continue` exactly as this file expected, and mxbuild then rejects it —
+--
+--   commit $Item on error continue;
+--   mx check -> [CE6035] "Error handling type is not supported"
+--                 at Commit object(s) activity 'Commit 'Item''
+--
+-- The example was written for round-trip fidelity and its Usage block never ran
+-- `mx check`, so a describe -> exec -> describe fixpoint was mistaken for a valid
+-- model. `mxcli check` now reports it as MDL076, which is why this file failed
+-- `make check-mdl` the moment that rule landed.
+--
+-- Continue IS supported on `retrieve`, `delete` and `call microflow`, and their
+-- round-trip is covered by `error-handling-continue.mdl` — which also carries the
+-- full per-action table.
@@ -0,0 +1,130 @@
+-- Two statements `mxcli check` passed, `exec` wrote without complaint, and only
+-- mxbuild refused — one of them by refusing to LOAD the project at all.
+-- ako/CapTrackV3 FINDINGS §9 and §46.
+--
+-- 1. AN UNASSIGNED CREATE (§9):
+--
+--      CREATE Mod.Region ( Name = 'North' ) COMMIT;   -- no `$Var =`
+--      mx check -> [CE6005] "The 'Entity' property is required."
+--                    at Create object activity 'Create Region (Name)'
+--
+--    The error names the wrong property. `Entity` IS stored. A field-level diff
+--    of the assigned and unassigned documents differs in ONE substantive field —
+--    `Action.VariableName`, "R" vs "" — everything else being identity (element
+--    IDs, flow pointers, StableId). A Mendix Create activity always names its
+--    output, and Studio Pro supplies the name itself when you drop one. Patching
+--    that single field took the project from 1 error to 0; restoring it took it
+--    back to 1.
+--
+--    mxcli now supplies it too, on Studio Pro's `New<Entity>` convention.
+--    Supplied rather than refused, because nothing is guessed: the author said
+--    create this entity and did not ask for a handle, which is exactly what an
+--    auto-named output is. The generated name is NOT registered as
+--    referenceable, so a later `change $NewRegion` stays the error it is.
+--
+-- 2. A TWO-PART SORT PATH (§46) — the severe one:
+--
+--      RETRIEVE $Rows FROM Mod.Item SORT BY System.createdDate ASC;
+--      mxcli check -> passed
+--      mxcli exec  -> succeeded, no complaint
+--      mx          -> System.ArgumentNullException: Value cannot be null.
+--                       at DomainModels.Refs.AttributeRef.set_AttributeId
+--
+--    Not a CE code — an unhandled exception with a stack trace. The project is
+--    UNLOADABLE, so Studio Pro cannot open it either. The report attributed the
+--    exception to `exec`; it is `mx` READING what exec wrote.
+--
+--    One guard caused it. The qualified branch validated `len(parts) >= 3`, so a
+--    two-part path fell through every check and was written verbatim as the
+--    sort's AttributeQualifiedName. `System.createdDate` reads as
+--    Module.Attribute, names no entity, and Mendix stores a null AttributeId.
+--
+--    Refused rather than repaired: `Module.Attribute` has no reading that names
+--    an entity, and the two candidate repairs — a bare member of the retrieved
+--    entity, or a member of the module's like-named entity — mean different
+--    things, and only the author knows which.
+--
+-- WHAT ACTUALLY WORKS FOR A SYSTEM MEMBER, measured on 11.14.0. This is narrower
+-- than the report suggests, and worth stating because the obvious reading is
+-- wrong:
+--
+--   sort by <a real attribute>                 0 errors
+--   sort by createdDate  (entity STORES it)    0 errors   <- the right spelling
+--   sort by createdDate  (entity does not)     CE1613     <- Mendix is right
+--   sort by CreatedDate  (wrong case)          CE1613     <- Mendix is right
+--   sort by System.createdDate                 UNLOADABLE <- the defect
+--
+-- A system member is spelled BARE and works. An earlier reading of this — that
+-- mxcli could not sort by a system member at all — came from testing against an
+-- entity that did not store one.
+--
+-- Verify:
+--
+--   mxcli exec  create-output-variable-and-sort-path.mdl -p app.mpr
+--   mx check -p app.mpr        -- 0 errors
+--
+-- Use `mx check` DIRECTLY, not `mxcli docker check`: that command runs
+-- `mx update-widgets` first and can mask a model-level failure.
+--
+-- Then perturb, one at a time:
+--
+--   stub freshCreateVariable to return ""
+--     -> CE6005 on every unassigned create, and mxcli check still passes.
+--
+--   change `sort by createdDate` to `sort by System.createdDate`
+--     -> refused by exec now. Before the fix: written, and the project could no
+--        longer be opened by mxbuild or Studio Pro.
+
+create module CrSort;
+/
+
+-- The entity must STORE createdDate for a sort on it to resolve — that is what
+-- the AutoCreatedDate pseudo-type sets.
+create or modify persistent entity CrSort.Item (
+  Code: String(20),
+  CreatedDate: AutoCreatedDate
+);
+/
+
+create or modify entity CrSort.Region ( Name: String(50) );
+/
+
+-- §9: the reported case, twice over. Two unassigned creates of the SAME entity
+-- must not end up sharing an output variable — Mendix reports that as CE0119, so
+-- a bare "New"+entity would trade one silent defect for another.
+create or modify microflow CrSort.ACT_Unassigned ()
+begin
+  CREATE CrSort.Region ( Name = 'North' ) COMMIT;
+  CREATE CrSort.Region ( Name = 'South' ) COMMIT;
+end;
+/
+
+-- CONTROL for §9: an assigned create keeps the AUTHOR's name, and that name is
+-- still referenceable afterwards. Without this a fix that always generated a name
+-- would look correct above.
+create or modify microflow CrSort.ACT_Assigned ()
+begin
+  $R = CREATE CrSort.Region ( Name = 'East' ) COMMIT;
+  CHANGE $R ( Name = 'West' );
+  COMMIT $R;
+end;
+/
+
+-- §46: the spelling that works. A bare system member on an entity that stores it.
+create or modify microflow CrSort.ACT_SortBare ()
+begin
+  RETRIEVE $Rows FROM CrSort.Item SORT BY createdDate ASC;
+  LOG INFO 'done';
+end;
+/
+
+-- CONTROL for §46: an ordinary attribute, and a fully qualified three-part path.
+-- The existing belongs-to-the-entity check owns the three-part case and must stay
+-- permissive; a fix that refused every dotted path would break this.
+create or modify microflow CrSort.ACT_SortOther ()
+begin
+  RETRIEVE $Rows FROM CrSort.Item SORT BY Code DESC;
+  RETRIEVE $Rows2 FROM CrSort.Item SORT BY CrSort.Item.Code ASC;
+  LOG INFO 'done';
+end;
+/
@@ -0,0 +1,129 @@
+-- `ON ERROR CONTINUE` was dropped on most statements and written INVALID on the
+-- rest (ako/CapTrackV3 FINDINGS §11).
+--
+-- The report: the clause parsed, `exec` said nothing, and
+-- `describe microflow` showed the retrieve with no error handler:
+--
+--   RETRIEVE $Users FROM System.User WHERE 'id = ''[%CurrentUser%]''' ON ERROR CONTINUE;
+--   describe -> retrieve $Users from System.User where id = '[%CurrentUser%]';
+--
+-- It vanished at the last hop. The visitor builds the clause and the flow builder
+-- set it on the ACTIVITY — a field the metamodel does not have on an
+-- ActionActivity and neither engine serializes — while both writers emitted a
+-- hardcoded literal "Rollback" on the ACTION, where errorHandlingType actually
+-- lives.
+--
+-- WHICH VALUES MENDIX ACCEPTS. Measured on 11.14.0 by writing each into a stored
+-- document of a 0-error project and building. The split is not guessable from the
+-- metamodel, where one enum covers every action type:
+--
+--   action           Rollback   Continue   Abort
+--   Retrieve            ok         ok        ok
+--   Delete              ok         ok        ok
+--   MicroflowCall       ok         ok      CE6035
+--   Log                 ok       CE6035    CE6035
+--   Create              ok       CE6035    CE6035
+--   Change              ok       CE6035    CE6035
+--   Commit              ok       CE6035    CE6035
+--   Aggregate           ok       CE6035    CE6035
+--
+-- Two things follow, and they point in opposite directions.
+--
+-- 1. THE HARDCODED "Rollback" WAS LOAD-BEARING. A nanoflow's no-clause default is
+--    Abort, and Abort is CE6035 on most types — so serializing the builder's
+--    value unconditionally would have broken every nanoflow that logs or creates.
+--    The clause is therefore carried ONLY when the author wrote one; an
+--    un-annotated activity keeps the exact document it has always had.
+--
+-- 2. CREATE AND COMMIT WERE ALREADY WRITING AN INVALID MODEL. Their builders did
+--    set the value on the action, so mxcli wrote `Continue` where mxbuild refuses
+--    it, and `mxcli check` passed:
+--
+--      $T = CREATE EH.Thing ( Code = 'a' ) COMMIT ON ERROR CONTINUE;
+--      mx check -> [CE6035] "Error handling type is not supported"
+--                    at Create object activity 'Create Thing (Code)'
+--
+--    Now MDL076, refused rather than downgraded: Continue swallows the error and
+--    carries on, Rollback aborts the flow, and an author who wrote the clause
+--    meant the first.
+--
+-- A MEASUREMENT TRAP worth keeping. The first version of that table was VACUOUS
+-- for Delete and said so only because the probe reported its own patch count: the
+-- Delete writer emits no ErrorHandlingType key at all, so setting it changed
+-- nothing and mxbuild's silence read as "accepted". The probe was changed to
+-- INSERT an absent key.
+--
+-- Verify:
+--
+--   mxcli exec  error-handling-continue.mdl -p app.mpr
+--   mx check -p app.mpr        -- 0 errors
+--   mxcli -p app.mpr -c "describe microflow ErrH.ACT_Handled"
+--     -- all three statements come back carrying `on error continue`
+--
+-- Then perturb:
+--
+--   ON ERROR CONTINUE on the retrieve  ->  stub the builder's action-level assignment
+--     describe drops the clause entirely — the reported symptom.
+--
+--   add `$T = CREATE ErrH.Thing ( Code = 'x' ) ON ERROR CONTINUE;`
+--     MDL076 at check time. Before the rule: check passed and mx check gave CE6035.
+
+create module ErrH;
+/
+
+create or modify entity ErrH.Thing ( Code: String(20) );
+/
+
+create or modify microflow ErrH.SUB_Noop ()
+begin
+  LOG INFO 'noop';
+end;
+/
+
+-- The three statements Mendix accepts Continue on. All three must round-trip.
+create or modify microflow ErrH.ACT_Handled ()
+begin
+  RETRIEVE $Rows FROM ErrH.Thing ON ERROR CONTINUE;
+  $T = HEAD($Rows);
+  DELETE $T ON ERROR CONTINUE;
+  CALL MICROFLOW ErrH.SUB_Noop () ON ERROR CONTINUE;
+end;
+/
+
+-- CONTROL: the same statements with NO clause. These must keep the document they
+-- have always had — the writers' literal — because the builder's value for "no
+-- clause" is not always one Mendix accepts. Without this control a fix that
+-- serialized the builder's value unconditionally would look correct above.
+create or modify microflow ErrH.ACT_Plain ()
+begin
+  RETRIEVE $Rows FROM ErrH.Thing;
+  $T = HEAD($Rows);
+  DELETE $T;
+  CALL MICROFLOW ErrH.SUB_Noop ();
+end;
+/
+
+-- CONTROL: a NANOFLOW, whose no-clause default is Abort — the value that would
+-- have broken the build had it been serialized. An explicit clause on a nanoflow
+-- is still the author's.
+create or modify nanoflow ErrH.NF_Plain ()
+begin
+  RETRIEVE $Rows FROM ErrH.Thing;
+  LOG INFO 'from a nanoflow';
+end;
+/
+
+-- CONTROL for MDL076: a CUSTOM handler is accepted on every action type measured,
+-- including the two the rule refuses Continue on. A rule that flagged the clause
+-- itself, rather than the Continue variant, would reject this working microflow —
+-- and a custom handler is the fix MDL076 suggests.
+create or modify microflow ErrH.ACT_CustomHandler ()
+begin
+  $T = CREATE ErrH.Thing ( Code = 'a' ) ON ERROR {
+    LOG ERROR 'create failed';
+  };
+  COMMIT $T ON ERROR {
+    LOG ERROR 'commit failed';
+  };
+end;
+/