From f0d9a9284906836ac06dc7063f526aacd0425a4e Mon Sep 17 00:00:00 2001
From: Ako <andrej@koelewijn.net>
Date: Mon, 14 Sep 2026 14:50:53 +0000
Subject: [PATCH 1/9] fix(check): check a user task's page and targeting
 microflow signatures
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

A workflow user task hands work to two documents, and `check --references`
resolved both by name only. A task page typed to the context entity, one with
no parameters, or a targeting microflow missing the System.Workflow parameter
passed check, was written by exec, and failed only in the native build. A team
building workflows from MDL listed both among the reasons "a green CLI check
is not evidence for workflows".

Every rule is a row of an mxbuild measurement on 11.13.0, one user task per
shape, verdict = the literal `mx check` line:

  task page, no parameters                              CE7410
  task page, no WorkflowUserTask parameter              CE7412 (multi-user too)
  task page, WorkflowUserTask + an extra parameter      0 errors
  targeting (System.Workflow, Ctx) / (Ctx, Workflow)    0 errors
  targeting (Workflow) / () / (Workflow, Ctx, String)   CE6677
  targeting (Workflow, generalization of Ctx)           0 errors
  targeting (Workflow, specialization of Ctx)           CE6677
  groups targeting                                      same rule

Three rows are clean shapes a reading of the error text would refuse —
extra page parameters, reversed order, a generalization — and exec refuses on
a check error, so a wrong rule would block a valid workflow rather than warn.
An inheritance chain that leaves what can be resolved is "not proven", which
is not a refusal.

Covers CREATE WORKFLOW (nested and multi-user tasks) and ALTER WORKFLOW
(inserted tasks, SET ACTIVITY PAGE / TARGETING MICROFLOW, with the context
entity read off the stored workflow). Pages, flows and generalizations are
resolved from the script first — they are ordinarily one script with the
workflow — then the project; scriptContext now records page parameter
entities and entity generalizations beside flowParams. Gated on Mendix 11,
where it is measured.

check --references reports before anything is written. exec calls the same
function at the workflow statement, so the workflow is never written, though
earlier statements in the script already are.

Controls, one stub each: the page check, the targeting check, following the
generalization, treating an unresolved chain as a mismatch, and the version
gate — each fails exactly the cases it should. End to end on an 11.13 app:
check --references reports exactly the six measured-bad shapes and none of
the five clean ones, and the positive fixture execs and builds at 0 new
errors.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 .../fix-issue/findings/mdl-executor.jsonl     |   1 +
 ...low-task-page-and-targeting-signatures.mdl |  87 +++++
 mdl/executor/validate.go                      |  13 +
 mdl/executor/validate_workflow_refs.go        |  10 +-
 .../validate_workflow_task_signature.go       | 354 ++++++++++++++++++
 .../validate_workflow_task_signature_test.go  | 236 ++++++++++++
 6 files changed, 699 insertions(+), 2 deletions(-)
 create mode 100644 mdl-examples/bug-tests/workflow-task-page-and-targeting-signatures.mdl
 create mode 100644 mdl/executor/validate_workflow_task_signature.go
 create mode 100644 mdl/executor/validate_workflow_task_signature_test.go

diff --git a/.claude/skills/fix-issue/findings/mdl-executor.jsonl b/.claude/skills/fix-issue/findings/mdl-executor.jsonl
index d490dadc9..0effd8834 100644
--- a/.claude/skills/fix-issue/findings/mdl-executor.jsonl
+++ b/.claude/skills/fix-issue/findings/mdl-executor.jsonl
@@ -613,3 +613,4 @@
 {"area":"mdl-executor","date":"2026-09-14","symptom":"DESCRIBE flattens a microflow whose branches cross into nested ifs that mean something else, and warns MDL-FLOW01 'must not be re-executed' instead of describing it","cause":"Nested if/then/else is single-entry/single-exit. A merge reached by branches of two different splits has no place in a tree, so the describer walked past it and emitted the conjunction along one path.","file":"mdl/executor/cmd_microflows_show_crossed.go","fix":"Mode 2: label the shared-suffix entry AND the split's post-dominator, emit `join <label>` at every branch end, then declare each merge as a top-level section after the traversal. MDL-FLOW01 is retired per decision when the description actually declared the merge.","insight":"Three traps, each of which produced plausible-looking output. (1) A crossed merge must be emitted the OPPOSITE way from an error-rejoin merge -- rejoin is DECLARED where the traversal meets it, crossed is JOINED by each branch and declared once afterwards -- so the label alone cannot drive emission; carry a crossed set beside the names. (2) Emit the join BEFORE the visited guard: arriving twice is what 'crossed' MEANS, and the guard silently swallows the second branch's join, leaving that path falling off the end. (3) Retire a warning on what was EMITTED, not on what was labelled. An inheritance split has its own traversal that walks through a labelled merge without emitting a join, so the label goes unused and the reader still gets the nested rendering -- suppressing on the label alone silenced MDL-FLOW01 on Administration.ManageMyAccount, whose description is byte-identical with and without the feature. That forced warnings to be computed AFTER the body instead of before it. Method: keep a baseline binary (git stash -u; build) and diff `describe` over every microflow in a corpus -- the refactor step should be byte-identical (it was, 18 of 18) and the feature step should change only the microflows it targets (2 of 18). Anything else changing is the bug."}
 {"area": "mdl/executor", "date": "2026-09-13", "symptom": "describe page -> create or replace page broke a button's icon. An icon into an IMAGE collection came back as `Icon: 'DesignSystem.Icons_SVG.edit'` and the build failed [CE1613] \"The selected custom icon 'DesignSystem.Icons_SVG.edit' no longer exists.\" A GLYPH icon produced no describe output at all -- no clause, no comment -- and replay DELETED it at exit 0.", "cause": "Mendix stores three icon elements and two put a qualified name under the same BSON key: Forms$IconCollectionIcon{Image}->CustomIcons$CustomIcon, Forms$ImageIcon{Image}->Images$Image, Forms$GlyphIcon{Code}. extractIconRef read `Image` off whichever element was there and threw the $Type away, and the page builder writes Forms$IconCollectionIcon unconditionally -- so the two named variants were spelled identically on the way out and collapsed into one on the way back in.", "file": "mdl/executor/cmd_pages_describe_output.go (extractButtonIcon, widgetIconMDL, widgetIconNote), mdl/executor/cmd_pages_describe.go (rawWidget.IconType/IconCode), mdl/executor/cmd_pages_describe_parse.go; tests mdl/executor/cmd_pages_describe_icon_test.go", "insight": "The identical three-variant defect was fixed in NAVIGATION eight days earlier (2026-09-05, same area file) and the page path never received it -- so the cheapest possible diagnosis was `grep MenuIconKindOf`, and the fix reuses that resolver rather than adding a second one. **Generalisable: when a fix teaches a layer to distinguish polymorphic variants, grep for every OTHER reader of the same element.** The find was one `git grep Forms\\$ImageIcon` away all along. Two things the report got understandably wrong and that the fix depends on getting right: it is not about third-party vs native collections (a third-party ICON collection round-trips fine -- and CE1613 naming the reference is itself proof the name was never a custom icon, since mxbuild would otherwise have resolved it), and the reported image-icon case is the CHEAPER half -- the glyph case is silent on both sides, so nothing in the output even hints at the loss. **Measure the silence, not the wrong answer**: `grep -c icon` over describe output of a stock marketplace project's FeedbackModule pages returned 0 before and 3 after, which is the only form the glyph bug has. The note has to fire on an UNRECOGNISED $Type too, not a known-bad list, or the next variant Mendix adds is dropped the same way. Controls that matter: an icon-collection icon must still emit a bare `Icon:` and NO note (else the fix passes by flagging everything), and an iconless button must emit neither. No .mdl repro is possible -- mxcli cannot author an image or glyph icon on a button, so the input to the round trip cannot be constructed in MDL; the reproduction is a stored-widget map in the unit test. Also observed in passing and NOT fixed: a nameless `statictext` makes describe output unparseable (pre-existing, confirmed against the base binary), and NavigationList item / DropDownButton icons are never read at all, so they are dropped as silently as the glyph was.", "refs": ["#1059", "#1008", "#602"], "ce": ["CE1613"]}
 {"area": "mdl/executor", "date": "2026-09-13", "symptom": "Follow-on to #1059: a widget's image and glyph icons were readable but unwritable, so describe -> exec could only be made honest (a `-- NOT re-executable` note), not lossless. Authoring them needed the kind to reach the element $Type through grammar, AST, visitor, builder and BOTH engines.", "cause": "Three separate vocabularies for the same three Mendix icon elements: types.MenuIconKind (navigation), pages.IconType (the page model's own three-value enum), and a bare string in the widget property map. The page path had no kind at all, so it could not express one.", "file": "mdl/grammar/domains/MDLPage.g4 (widgetIconV3), mdl/ast/ast_page_v3.go (WidgetIcon), mdl/visitor/visitor_page_v3.go (buildWidgetIconV3), mdl/executor/cmd_pages_builder_v3_widgets.go (buildWidgetIcon), mdl/backend/modelsdk/widget_write.go (iconToGen), sdk/mpr/writer_widgets_display.go (buildWidgetIconBson), mdl/executor/validate_icon_refs.go, mdl/executor/validate_glyph_codes.go", "insight": "**Delete the second vocabulary as part of the fix, not after it.** pages.IconType existed for exactly the same three kinds as types.MenuIconKind and had drifted to a different value set; replacing it (2 call sites) is what made the writers a dispatch rather than an inference. A feature that adds a third copy would have re-created the bug in a new place. **The pre-existing tests of the OLD feature are the safety net for the new one**: MDL078's menu tests caught a python replace of mine that silently no-opped (anchor did not match, no assert), which nothing else would have. Always assert on the replacement count when editing by script. **Measure the premise, don't reason by analogy** — extending MDL078 to widget glyphs assumed mxbuild resolves a widget glyph the same way it resolves a menu one. It does, measured: `Icon: glyph 57562` fails `mxbuild --target=deploy` with `System.InvalidOperationException: Sequence contains no matching element` — but it names the **page**, not a layout, so the rule's own message was wrong and had to be corrected from the measurement. **The reference check had the mirror-image bug waiting**: resolving an image reference against the ICON collections reports a correct name as a typo, which is the same conflation pointed the other way — per-kind resolution plus an `otherKindHint` naming the remedy. **An empty listing is 'could not establish', not 'none'** — each half of the index is independent, so a project that yields icon collections but no image collections still resolves what it can. Verified on 11.13.0: all three authored, mx check 0 errors, deploy BUILD SUCCEEDED, right $Type on disk; controls reproduce CE1613 (image written without `image`) and the glyph build failure. Corpus sweep 531 clean.", "refs": ["#1059", "#1008", "#602"], "ce": ["CE1613"]}
+{"area": "mdl/executor", "date": "2026-09-14", "symptom": "A workflow user task whose task page takes the context entity instead of System.WorkflowUserTask (CE7412), takes no parameters (CE7410), or whose targeting microflow does not take exactly System.Workflow plus the context entity (CE6677) passed `mxcli check` AND `check --references`, was written by exec, and failed only under the native mx check. Reported in a team briefing on building workflows from MDL as two of the reasons 'a green CLI check is not evidence for workflows'.", "cause": "validateWorkflowReferences resolved the user task's page and targeting microflow by NAME only — it reported a document that does not exist, never one that exists with the wrong signature. Neither signature was in `mxcli syntax workflow` either, so authors had nothing to copy.", "fix": "validate_workflow_task_signature.go checks both signatures from the script's own definitions first (scriptContext now records page parameter entities and entity generalizations, beside flowParams) and then the project, for CREATE WORKFLOW (incl. nested and multi-user tasks) and ALTER WORKFLOW (inserted tasks, SET ACTIVITY PAGE / TARGETING MICROFLOW, context entity read off the stored workflow). Wired into validateWorkflowStatementRefs / validateAlterWorkflowRefs. check --references reports before anything is written; exec calls the same function at the workflow statement, so the workflow is never written but earlier statements in the script already are. Gated on Mendix 11, where it is measured.", "file": "mdl/executor/validate_workflow_task_signature.go", "insight": "Measure the CLEAN edges before writing a refusal — three of the nine rows would have been false refusals from a plausible reading of the error text: a task page MAY take extra parameters besides WorkflowUserTask, a targeting microflow MAY take its two parameters in either order, and its context parameter MAY be a generalization of the context entity (but not a specialization). Since exec refuses on a check error, a false refusal is a blocker. Where the inheritance chain leaves what can be resolved (a script entity extending something unknown), return 'not proven' rather than a mismatch. Also a harness caveat worth keeping: the control run that stubbed the version gate first reported 0 failures because the harness only counted `--- FAIL` lines containing '/', i.e. subtests; the gate test is top-level. A silent control is a claim about the harness before it is a claim about the test."}
diff --git a/mdl-examples/bug-tests/workflow-task-page-and-targeting-signatures.mdl b/mdl-examples/bug-tests/workflow-task-page-and-targeting-signatures.mdl
new file mode 100644
index 000000000..35555ef95
--- /dev/null
+++ b/mdl-examples/bug-tests/workflow-task-page-and-targeting-signatures.mdl
@@ -0,0 +1,87 @@
+-- A user task hands work to two documents — its task page and its targeting
+-- microflow — and both have a signature the platform enforces. `check
+-- --references` resolved them by name only, so a wrong signature passed check,
+-- was written by exec, and surfaced as a native build error. Reported by a team
+-- building workflows from MDL, among the reasons "a green CLI check is not
+-- evidence for workflows".
+--
+-- ============================================================================
+-- The rules, measured on 11.13.0 (one user task per shape, verdict = the
+-- literal `mx check` line)
+-- ============================================================================
+--
+-- Task page:
+--   no parameters                                   CE7410
+--   parameters, none typed System.WorkflowUserTask  CE7412 (multi-user task too)
+--   System.WorkflowUserTask plus an extra parameter 0 errors
+--
+-- Targeting microflow (users and groups alike):
+--   (System.Workflow, Ctx)                          0 errors
+--   (Ctx, System.Workflow)                          0 errors  <- order is free
+--   (System.Workflow) / () / (+ a third)            CE6677    <- exactly two
+--   (System.Workflow, <generalization of Ctx>)      0 errors
+--   (System.Workflow, <specialization of Ctx>)      CE6677
+--
+-- `check --references` now reports the CE rows before anything is written.
+-- exec refuses the workflow statement itself, so the workflow is never
+-- written; statements before it in the script already are.
+--
+-- This script is the POSITIVE half: every shape in it is one a plausible
+-- reading of the error text would refuse, and every one builds at 0 errors.
+-- They are the false refusals the check must not make — exec refuses a script
+-- with a check error, so a wrong refusal here would block a valid workflow.
+-- A negative fixture cannot live here: `make check-mdl` runs without a
+-- project, and this check needs one. The CE rows are covered by
+-- mdl/executor/validate_workflow_task_signature_test.go.
+
+create module WFSIG;
+
+create persistent entity WFSIG.Request ( Title: string(50) );
+/
+
+create persistent entity WFSIG.UrgentRequest extends WFSIG.Request ( Reason: string(200) );
+/
+
+-- A task page may take parameters besides the task.
+create page WFSIG.ReviewPage (
+  title: 'Review',
+  layout: Atlas_Core.Atlas_Default,
+  params: { $WorkflowUserTask: System.WorkflowUserTask, $Request: WFSIG.Request }
+) {
+  layoutgrid g1 { row r1 { column c1 (desktopwidth: 12) { dynamictext t1 (content: 'Review') } } }
+}
+/
+
+-- Parameters in the reverse order, and typed to a GENERALIZATION of the
+-- workflow's context entity (the workflow below runs on UrgentRequest).
+create microflow WFSIG.ACT_GetReviewers ( $Request: WFSIG.Request, $Workflow: System.Workflow )
+returns list of System.User as $Reviewers
+begin
+  @position(200,200) retrieve $Reviewers from System.User;
+  @position(400,200) return $Reviewers;
+end;
+/
+
+-- Groups targeting takes the same two parameters.
+create microflow WFSIG.ACT_GetReviewGroups ( $Workflow: System.Workflow, $Request: WFSIG.UrgentRequest )
+returns list of System.WorkflowGroup as $Groups
+begin
+  @position(200,200) retrieve $Groups from System.WorkflowGroup;
+  @position(400,200) return $Groups;
+end;
+/
+
+create workflow WFSIG.UrgentReview
+  parameter $Request: WFSIG.UrgentRequest
+begin
+  user task Review 'Review the request'
+    page WFSIG.ReviewPage
+    targeting microflow WFSIG.ACT_GetReviewers
+    outcomes 'Approve' { } 'Reject' { };
+
+  multi user task Assess 'Assess the request'
+    page WFSIG.ReviewPage
+    targeting groups microflow WFSIG.ACT_GetReviewGroups
+    outcomes 'Approve' { } 'Reject' { };
+end workflow;
+/
diff --git a/mdl/executor/validate.go b/mdl/executor/validate.go
index 957bd71bf..6ec444156 100644
--- a/mdl/executor/validate.go
+++ b/mdl/executor/validate.go
@@ -53,6 +53,14 @@ type scriptContext struct {
 	// nested in it.
 	flowParams map[string]*flowSignature // Module.Flow (lower-cased) -> signature
 
+	// Pages created in the script, mapped to their parameters' entity names, and
+	// entities created in the script, mapped to their generalization. Both for
+	// the workflow task signature checks, for the same reason as flowParams: the
+	// task page, the targeting microflow, the context entity and the workflow are
+	// ordinarily one script.
+	pageParams            map[string][]string // Module.Page (lower-cased) -> parameter entities
+	entityGeneralizations map[string]string   // Module.Entity (lower-cased) -> generalization, "" for none
+
 	// Associations and entity attributes declared in the script, for
 	// MDL-XPATH01. Same reason as flowParams above: the overwhelmingly common
 	// shape is ONE script that creates the entity, the association and the
@@ -85,6 +93,9 @@ func newScriptContext() *scriptContext {
 		entityAttrs:       map[string]map[string]bool{},
 		ambiguousAssc:     map[string]bool{},
 		flowParams:        make(map[string]*flowSignature),
+
+		pageParams:            make(map[string][]string),
+		entityGeneralizations: make(map[string]string),
 	}
 }
 
@@ -153,6 +164,7 @@ func (sc *scriptContext) collectSingle(stmt ast.Statement) {
 		if s.Name.Module != "" {
 			sc.entities[s.Name.String()] = true
 			sc.recordEntityAttrs(s)
+			sc.recordEntityGeneralization(s)
 		}
 	case *ast.CreateAssociationStmt:
 		sc.recordAssociation(s)
@@ -186,6 +198,7 @@ func (sc *scriptContext) collectSingle(stmt ast.Statement) {
 	case *ast.CreatePageStmtV3:
 		if s.Name.Module != "" {
 			sc.pages[s.Name.String()] = true
+			sc.recordPageParams(s.Name.String(), s.Parameters)
 		}
 	case *ast.CreateSnippetStmtV3:
 		if s.Name.Module != "" {
diff --git a/mdl/executor/validate_workflow_refs.go b/mdl/executor/validate_workflow_refs.go
index 4caf4e850..c4a870f40 100644
--- a/mdl/executor/validate_workflow_refs.go
+++ b/mdl/executor/validate_workflow_refs.go
@@ -174,7 +174,12 @@ func validateWorkflowStatementRefs(ctx *ExecContext, s *ast.CreateWorkflowStmt,
 		}
 	}
 	errs = append(errs, bareTimerBoundaryEventErrors(ctx, s.Activities, 0)...)
-	return append(errs, validateWorkflowReferences(ctx, s.Activities, sc)...)
+	errs = append(errs, validateWorkflowReferences(ctx, s.Activities, sc)...)
+	// Then the signatures of the page and targeting microflow each user task
+	// hands work to — names that resolve can still be the wrong shape (CE7410,
+	// CE7412, CE6677). A target that did not resolve is skipped there, so it is
+	// reported once, above.
+	return append(errs, validateWorkflowTaskSignatures(ctx, s.Activities, s.ParameterEntity.String(), sc)...)
 }
 
 // bareTimerBoundaryEventErrors refuses `boundary event timer` without a kind
@@ -314,5 +319,6 @@ func validateAlterWorkflowRefs(ctx *ExecContext, s *ast.AlterWorkflowStmt, sc *s
 	// cannot drift.
 	errs = append(errs, validateAlterWorkflowActivityKinds(ctx, s)...)
 
-	return append(errs, validateWorkflowReferences(ctx, added, sc)...)
+	errs = append(errs, validateWorkflowReferences(ctx, added, sc)...)
+	return append(errs, validateAlterWorkflowTaskSignatures(ctx, s, added, sc)...)
 }
diff --git a/mdl/executor/validate_workflow_task_signature.go b/mdl/executor/validate_workflow_task_signature.go
new file mode 100644
index 000000000..e0cc18789
--- /dev/null
+++ b/mdl/executor/validate_workflow_task_signature.go
@@ -0,0 +1,354 @@
+// SPDX-License-Identifier: Apache-2.0
+
+// Signature checks for the two documents a user task hands work to — its task
+// page and its targeting microflow. Both were resolved by name only, so a page
+// typed to the workflow's context entity, or a targeting microflow missing the
+// System.Workflow parameter, passed `check --references`, was written by exec,
+// and surfaced only under the native validator. A team building workflows from
+// MDL reported both, and put them among the reasons "a green CLI check is not
+// evidence for workflows".
+//
+// Every rule here is a row of an mxbuild measurement (11.13.0, one user task per
+// shape, verdict = the literal `mx check` line):
+//
+//	task page, no parameters                             CE7410
+//	task page, only a context-entity parameter           CE7412 (multi-user task too)
+//	task page, WorkflowUserTask + an extra parameter     0 errors
+//	targeting (System.Workflow, Ctx)                     0 errors
+//	targeting (Ctx, System.Workflow)                     0 errors — order is free
+//	targeting (System.Workflow) / () / (+ String)        CE6677 — exactly two
+//	targeting (System.Workflow, <generalization of Ctx>) 0 errors
+//	targeting (System.Workflow, <specialization of Ctx>) CE6677
+//	targeting groups microflow                           the same rule
+//
+// Three of those rows are clean shapes a plausible reading of the error text
+// would refuse — extra page parameters, reversed order, a generalization. They
+// are the reason the rules are measured rather than read off the messages:
+// exec refuses a script whose check reports an error, so a false refusal here
+// is not a warning but a blocker.
+package executor
+
+import (
+	"fmt"
+	"strings"
+
+	"github.com/mendixlabs/mxcli/mdl/ast"
+)
+
+const (
+	workflowUserTaskEntity = "System.WorkflowUserTask"
+	workflowEntity         = "System.Workflow"
+)
+
+// validateWorkflowTaskSignatures checks the task page and targeting microflow of
+// every user task in activities, including nested ones. contextEntity is the
+// workflow's context entity; with none known, only the page is checked.
+func validateWorkflowTaskSignatures(ctx *ExecContext, activities []ast.WorkflowActivityNode, contextEntity string, sc *scriptContext) []string {
+	c := newWorkflowTaskSignatureChecker(ctx, sc)
+	if c == nil {
+		return nil
+	}
+	return c.checkActivities(activities, contextEntity)
+}
+
+// validateAlterWorkflowTaskSignatures applies the same checks to ALTER WORKFLOW:
+// user tasks an operation introduces, and SET ACTIVITY … PAGE / TARGETING
+// MICROFLOW. The context entity is not in the statement, so it is read off the
+// stored workflow; a workflow that is not stored yet leaves targeting unchecked
+// rather than guessed at.
+func validateAlterWorkflowTaskSignatures(ctx *ExecContext, s *ast.AlterWorkflowStmt, added []ast.WorkflowActivityNode, sc *scriptContext) []string {
+	c := newWorkflowTaskSignatureChecker(ctx, sc)
+	if c == nil {
+		return nil
+	}
+	contextEntity := ""
+	if wf := findStoredWorkflow(ctx, s.Name); wf != nil && wf.Parameter != nil {
+		contextEntity = wf.Parameter.EntityRef
+	}
+	errs := c.checkActivities(added, contextEntity)
+	for _, op := range s.Operations {
+		o, ok := op.(*ast.SetActivityPropertyOp)
+		if !ok {
+			continue
+		}
+		label := fmt.Sprintf("activity '%s'", o.ActivityRef)
+		errs = appendIfSet(errs, c.checkPage(label, o.PageName.String()))
+		errs = appendIfSet(errs, c.checkTargeting(label, o.Microflow.String(), contextEntity))
+	}
+	return errs
+}
+
+// workflowTaskSignatureChecker resolves page and flow signatures lazily — from
+// the script first, because a script that redefines a document is describing
+// what will be written, then from the project.
+type workflowTaskSignatureChecker struct {
+	ctx   *ExecContext
+	sc    *scriptContext
+	pages map[string][]string
+	flows map[string]*flowSignature
+}
+
+// newWorkflowTaskSignatureChecker returns nil when the checks do not apply.
+//
+// Gated on Mendix 11 because that is where the rules are measured. Whether 10.x
+// agrees is unknown here, and applying a guess would be a false refusal on the
+// versions it is wrong for — the same reasoning as MDL-WF07.
+func newWorkflowTaskSignatureChecker(ctx *ExecContext, sc *scriptContext) *workflowTaskSignatureChecker {
+	if ctx == nil || ctx.Backend == nil || !ctx.Connected() {
+		return nil
+	}
+	pv := ctx.Backend.ProjectVersion()
+	if pv == nil || !pv.IsAtLeast(11, 0) {
+		return nil
+	}
+	return &workflowTaskSignatureChecker{ctx: ctx, sc: sc}
+}
+
+func (c *workflowTaskSignatureChecker) checkActivities(activities []ast.WorkflowActivityNode, contextEntity string) []string {
+	var errs []string
+	walkWorkflowActivities(activities, func(a ast.WorkflowActivityNode) {
+		n, ok := a.(*ast.WorkflowUserTaskNode)
+		if !ok {
+			return
+		}
+		kind := "user task"
+		if n.IsMultiUser {
+			kind = "multi user task"
+		}
+		label := kind + " " + workflowUserTaskLabel(n)
+		errs = appendIfSet(errs, c.checkPage(label, n.Page.String()))
+		// "microflow" and "group_microflow"; the XPath kinds name no document.
+		if strings.Contains(n.Targeting.Kind, "microflow") {
+			errs = appendIfSet(errs, c.checkTargeting(label, n.Targeting.Microflow.String(), contextEntity))
+		}
+	})
+	return errs
+}
+
+// checkPage reports a task page that cannot receive the task (CE7410, CE7412).
+// A page that does not resolve is left to the missing-reference check.
+func (c *workflowTaskSignatureChecker) checkPage(label, pageQN string) string {
+	if pageQN == "" || pageQN == "." {
+		return ""
+	}
+	params, ok := c.pageParams(pageQN)
+	if !ok {
+		return ""
+	}
+	if len(params) == 0 {
+		return fmt.Sprintf(
+			"%s: page %s takes no parameters — a task page is opened with the task, so it must take a %s parameter; "+
+				"the build fails CE7410 (add `params: { $WorkflowUserTask: %s }`)",
+			label, pageQN, workflowUserTaskEntity, workflowUserTaskEntity)
+	}
+	for _, e := range params {
+		if strings.EqualFold(e, workflowUserTaskEntity) {
+			return ""
+		}
+	}
+	return fmt.Sprintf(
+		"%s: page %s takes %s but no %s parameter — a task page receives the task, not the workflow's context object; "+
+			"the build fails CE7412 (add `$WorkflowUserTask: %s` — the other parameters may stay)",
+		label, pageQN, describeEntityList(params), workflowUserTaskEntity, workflowUserTaskEntity)
+}
+
+// checkTargeting reports a targeting microflow whose parameters are not exactly
+// System.Workflow plus the context entity or a generalization of it (CE6677).
+func (c *workflowTaskSignatureChecker) checkTargeting(label, mfQN, contextEntity string) string {
+	if mfQN == "" || mfQN == "." || contextEntity == "" || contextEntity == "." {
+		return ""
+	}
+	sig, ok := c.flowSignature(mfQN)
+	if !ok || sig == nil || !c.targetingMismatch(sig, contextEntity) {
+		return ""
+	}
+	return fmt.Sprintf(
+		"%s: targeting microflow %s takes %s — a targeting microflow must take exactly two parameters, %s and the "+
+			"workflow's context entity %s (or a generalization of it), in either order; the build fails CE6677",
+		label, mfQN, describeFlowParams(sig), workflowEntity, contextEntity)
+}
+
+// targetingMismatch reports a signature that is PROVABLY wrong. When the
+// context entity's inheritance chain leaves what can be resolved, the answer is
+// "not proven", which is not a refusal.
+func (c *workflowTaskSignatureChecker) targetingMismatch(sig *flowSignature, contextEntity string) bool {
+	if len(sig.Params) != 2 {
+		return true
+	}
+	for i, p := range sig.Params {
+		if !strings.EqualFold(p.Entity, workflowEntity) {
+			continue
+		}
+		other := sig.Params[1-i]
+		if other.Entity == "" {
+			continue
+		}
+		if c.contextAssignableTo(contextEntity, other.Entity) != inheritanceNo {
+			return false
+		}
+	}
+	return true
+}
+
+type inheritance int
+
+const (
+	inheritanceUnknown inheritance = iota
+	inheritanceYes
+	inheritanceNo
+)
+
+// contextAssignableTo reports whether an object of contextQN can be passed where
+// paramQN is declared: it IS paramQN, or derives from it. A specialization does
+// not qualify — measured, CE6677.
+func (c *workflowTaskSignatureChecker) contextAssignableTo(contextQN, paramQN string) inheritance {
+	seen := map[string]bool{}
+	for qn := contextQN; ; {
+		if strings.EqualFold(qn, paramQN) {
+			return inheritanceYes
+		}
+		key := strings.ToLower(qn)
+		if seen[key] {
+			return inheritanceUnknown // a cycle is not a model to judge
+		}
+		seen[key] = true
+		parent, resolved := c.generalizationOf(qn)
+		if !resolved {
+			return inheritanceUnknown
+		}
+		if parent == "" {
+			return inheritanceNo
+		}
+		qn = parent
+	}
+}
+
+func (c *workflowTaskSignatureChecker) generalizationOf(qn string) (string, bool) {
+	if c.sc != nil {
+		if g, ok := c.sc.entityGeneralizations[strings.ToLower(qn)]; ok {
+			return g, true
+		}
+	}
+	e, ok := findEntityByQN(c.ctx.Backend, qn)
+	if !ok || e == nil {
+		return "", false
+	}
+	return e.GeneralizationRef, true
+}
+
+func (c *workflowTaskSignatureChecker) pageParams(qn string) ([]string, bool) {
+	key := strings.ToLower(qn)
+	if c.sc != nil {
+		if p, ok := c.sc.pageParams[key]; ok {
+			return p, true
+		}
+	}
+	if c.pages == nil {
+		c.pages = buildPageParamEntities(c.ctx)
+	}
+	p, ok := c.pages[key]
+	return p, ok
+}
+
+func (c *workflowTaskSignatureChecker) flowSignature(qn string) (*flowSignature, bool) {
+	key := strings.ToLower(qn)
+	if c.sc != nil {
+		if s, ok := c.sc.flowParams[key]; ok {
+			return s, true
+		}
+	}
+	if c.flows == nil {
+		c.flows = buildFlowSignatures(c.ctx)
+	}
+	s, ok := c.flows[key]
+	return s, ok
+}
+
+// buildPageParamEntities maps each stored page (lower-cased qualified name) to
+// its parameters' entity names, "" for a non-entity parameter. A page with no
+// parameters is present with an empty list: "known, takes nothing" is CE7410,
+// "not found" is someone else's report.
+func buildPageParamEntities(ctx *ExecContext) map[string][]string {
+	out := map[string][]string{}
+	h, err := getHierarchy(ctx)
+	if err != nil || h == nil {
+		return out
+	}
+	all, err := ctx.Backend.ListPages()
+	if err != nil {
+		return out
+	}
+	for _, p := range all {
+		if p == nil {
+			continue
+		}
+		entities := make([]string, 0, len(p.Parameters))
+		for _, param := range p.Parameters {
+			if param != nil {
+				entities = append(entities, param.EntityName)
+			}
+		}
+		out[strings.ToLower(h.GetQualifiedName(p.ContainerID, p.Name))] = entities
+	}
+	return out
+}
+
+// recordPageParams stores a script-declared page's parameter entities, for the
+// task page check. Same reason as flowParams: the page and the workflow using it
+// are usually one script.
+func (sc *scriptContext) recordPageParams(qualifiedName string, params []ast.PageParameter) {
+	entities := make([]string, 0, len(params))
+	for _, p := range params {
+		entity := astDataTypeEntity(p.Type)
+		if entity == "" {
+			if qn := p.EntityType.String(); qn != "." {
+				entity = qn
+			}
+		}
+		entities = append(entities, entity)
+	}
+	sc.pageParams[strings.ToLower(qualifiedName)] = entities
+}
+
+// recordEntityGeneralization stores a script-declared entity's generalization
+// ("" for none), so the targeting check can walk an inheritance chain that
+// starts in the script and continues in the project.
+func (sc *scriptContext) recordEntityGeneralization(s *ast.CreateEntityStmt) {
+	parent := ""
+	if s.Generalization != nil {
+		parent = s.Generalization.String()
+	}
+	sc.entityGeneralizations[strings.ToLower(s.Name.String())] = parent
+}
+
+func describeEntityList(entities []string) string {
+	parts := make([]string, len(entities))
+	for i, e := range entities {
+		if e == "" {
+			e = "a non-entity value"
+		}
+		parts[i] = e
+	}
+	return strings.Join(parts, ", ")
+}
+
+func describeFlowParams(sig *flowSignature) string {
+	if len(sig.Params) == 0 {
+		return "no parameters"
+	}
+	parts := make([]string, len(sig.Params))
+	for i, p := range sig.Params {
+		parts[i] = p.Entity
+		if p.Entity == "" {
+			parts[i] = "a non-entity value"
+		}
+	}
+	return "(" + strings.Join(parts, ", ") + ")"
+}
+
+func appendIfSet(errs []string, msg string) []string {
+	if msg == "" {
+		return errs
+	}
+	return append(errs, msg)
+}
diff --git a/mdl/executor/validate_workflow_task_signature_test.go b/mdl/executor/validate_workflow_task_signature_test.go
new file mode 100644
index 000000000..21554dc7d
--- /dev/null
+++ b/mdl/executor/validate_workflow_task_signature_test.go
@@ -0,0 +1,236 @@
+// SPDX-License-Identifier: Apache-2.0
+
+package executor
+
+import (
+	"strings"
+	"testing"
+
+	"github.com/mendixlabs/mxcli/mdl/backend/mock"
+	"github.com/mendixlabs/mxcli/mdl/types"
+	"github.com/mendixlabs/mxcli/model"
+	"github.com/mendixlabs/mxcli/sdk/domainmodel"
+	"github.com/mendixlabs/mxcli/sdk/microflows"
+	"github.com/mendixlabs/mxcli/sdk/pages"
+	"github.com/mendixlabs/mxcli/sdk/workflows"
+)
+
+// wfSigCtx is a project shaped like the mxbuild measurements behind these rules
+// (11.13.0): one module M with a context entity Ctx and a Base <- Sub pair, a
+// task page per parameter shape, a targeting microflow per signature shape, and
+// one stored workflow for the ALTER cases.
+func wfSigCtx(t *testing.T, version string, major, minor int) *ExecContext {
+	t.Helper()
+	mod := &model.Module{Name: "M"}
+	mod.ID = "mod1"
+
+	ctxEnt := &domainmodel.Entity{Name: "Ctx"}
+	base := &domainmodel.Entity{Name: "Base"}
+	sub := &domainmodel.Entity{Name: "Sub", GeneralizationRef: "M.Base"}
+	for _, e := range []*domainmodel.Entity{ctxEnt, base, sub} {
+		e.ContainerID = "dm1"
+	}
+	dm := &domainmodel.DomainModel{Entities: []*domainmodel.Entity{ctxEnt, base, sub}}
+	dm.ID = "dm1"
+	dm.ContainerID = "mod1"
+
+	page := func(name string, paramEntities ...string) *pages.Page {
+		p := &pages.Page{Name: name}
+		p.ContainerID = "mod1"
+		for i, e := range paramEntities {
+			p.Parameters = append(p.Parameters, &pages.PageParameter{Name: "P" + string(rune('A'+i)), EntityName: e})
+		}
+		return p
+	}
+	obj := func(qn string) microflows.DataType { return &microflows.ObjectType{EntityQualifiedName: qn} }
+	mf := func(name string, types ...microflows.DataType) *microflows.Microflow {
+		m := &microflows.Microflow{Name: name}
+		m.ContainerID = "mod1"
+		for i, dt := range types {
+			m.Parameters = append(m.Parameters, &microflows.MicroflowParameter{Name: "p" + string(rune('a'+i)), Type: dt})
+		}
+		return m
+	}
+
+	stored := &workflows.Workflow{Name: "Stored", Parameter: &workflows.WorkflowParameter{EntityRef: "M.Ctx"}}
+	stored.ContainerID = "mod1"
+
+	mb := &mock.MockBackend{
+		IsConnectedFunc: func() bool { return true },
+		ProjectVersionFunc: func() *types.ProjectVersion {
+			return &types.ProjectVersion{ProductVersion: version, MajorVersion: major, MinorVersion: minor}
+		},
+		ListModulesFunc: func() ([]*model.Module, error) { return []*model.Module{mod}, nil },
+		GetModuleByNameFunc: func(name string) (*model.Module, error) {
+			if strings.EqualFold(name, "M") {
+				return mod, nil
+			}
+			return nil, nil
+		},
+		ListDomainModelsFunc: func() ([]*domainmodel.DomainModel, error) { return []*domainmodel.DomainModel{dm}, nil },
+		GetDomainModelFunc:   func(model.ID) (*domainmodel.DomainModel, error) { return dm, nil },
+		ListPagesFunc: func() ([]*pages.Page, error) {
+			return []*pages.Page{
+				page("PgGood", "System.WorkflowUserTask"),
+				page("PgNone"),
+				page("PgCtx", "M.Ctx"),
+				page("PgExtra", "System.WorkflowUserTask", "M.Ctx"),
+			}, nil
+		},
+		ListMicroflowsFunc: func() ([]*microflows.Microflow, error) {
+			return []*microflows.Microflow{
+				mf("MF_Good", obj("System.Workflow"), obj("M.Ctx")),
+				mf("MF_Reversed", obj("M.Ctx"), obj("System.Workflow")),
+				mf("MF_WfOnly", obj("System.Workflow")),
+				mf("MF_NoParams"),
+				mf("MF_Extra", obj("System.Workflow"), obj("M.Ctx"), &microflows.StringType{}),
+				mf("MF_TakesBase", obj("System.Workflow"), obj("M.Base")),
+				mf("MF_TakesSub", obj("System.Workflow"), obj("M.Sub")),
+			}, nil
+		},
+		ListWorkflowsFunc: func() ([]*workflows.Workflow, error) { return []*workflows.Workflow{stored}, nil },
+	}
+	ctx, _ := newMockCtx(t, withBackend(mb))
+	return ctx
+}
+
+// Each case is a row of the mxbuild measurement (11.13.0) — want is the CE code
+// the build reported, "" where it built at 0 errors. The clean rows are the ones
+// that keep the rule from being a false refusal, and two of them are not what a
+// plausible reading of the error message would predict: a task page may carry
+// extra parameters, and a targeting microflow may take its two in either order.
+func TestWorkflowTaskSignatures_Create(t *testing.T) {
+	ut := func(ctxEntity, clause string) string {
+		return `create workflow M.W parameter $C: ` + ctxEntity + ` begin ` + clause + ` end workflow;`
+	}
+	cases := []struct{ name, src, want string }{
+		// Task page (CE7410 no parameters, CE7412 no WorkflowUserTask parameter).
+		{"page takes WorkflowUserTask", ut("M.Ctx", `user task T 'c' page M.PgGood outcomes 'a' { } 'b' { };`), ""},
+		{"page takes WorkflowUserTask plus an extra param", ut("M.Ctx", `user task T 'c' page M.PgExtra outcomes 'a' { } 'b' { };`), ""},
+		{"page takes nothing", ut("M.Ctx", `user task T 'c' page M.PgNone outcomes 'a' { } 'b' { };`), "CE7410"},
+		{"page takes the context entity", ut("M.Ctx", `user task T 'c' page M.PgCtx outcomes 'a' { } 'b' { };`), "CE7412"},
+		{"multi user task, context page", ut("M.Ctx", `multi user task T 'c' page M.PgCtx outcomes 'a' { } 'b' { };`), "CE7412"},
+		{"nested in an outcome", ut("M.Ctx", `user task T 'c' page M.PgGood outcomes 'a' { user task U 'u' page M.PgCtx outcomes 'x' { } 'y' { }; } 'b' { };`), "CE7412"},
+
+		// Targeting microflow (CE6677): exactly System.Workflow + the context
+		// entity or a generalization of it, in either order.
+		{"targeting (Workflow, Ctx)", ut("M.Ctx", `user task T 'c' page M.PgGood targeting microflow M.MF_Good outcomes 'a' { } 'b' { };`), ""},
+		{"targeting (Ctx, Workflow) reversed", ut("M.Ctx", `user task T 'c' page M.PgGood targeting microflow M.MF_Reversed outcomes 'a' { } 'b' { };`), ""},
+		{"targeting (Workflow) only", ut("M.Ctx", `user task T 'c' page M.PgGood targeting microflow M.MF_WfOnly outcomes 'a' { } 'b' { };`), "CE6677"},
+		{"targeting no params", ut("M.Ctx", `user task T 'c' page M.PgGood targeting microflow M.MF_NoParams outcomes 'a' { } 'b' { };`), "CE6677"},
+		{"targeting extra param", ut("M.Ctx", `user task T 'c' page M.PgGood targeting microflow M.MF_Extra outcomes 'a' { } 'b' { };`), "CE6677"},
+		{"targeting users microflow", ut("M.Ctx", `user task T 'c' page M.PgGood targeting users microflow M.MF_WfOnly outcomes 'a' { } 'b' { };`), "CE6677"},
+		{"targeting groups microflow", ut("M.Ctx", `user task T 'c' page M.PgGood targeting groups microflow M.MF_WfOnly outcomes 'a' { } 'b' { };`), "CE6677"},
+		{"microflow takes a generalization of the context", ut("M.Sub", `user task T 'c' page M.PgGood targeting microflow M.MF_TakesBase outcomes 'a' { } 'b' { };`), ""},
+		{"microflow takes a specialization of the context", ut("M.Base", `user task T 'c' page M.PgGood targeting microflow M.MF_TakesSub outcomes 'a' { } 'b' { };`), "CE6677"},
+		{"xpath targeting is not a microflow", ut("M.Ctx", `user task T 'c' page M.PgGood targeting xpath '[true()]' outcomes 'a' { } 'b' { };`), ""},
+	}
+	for _, c := range cases {
+		t.Run(c.name, func(t *testing.T) {
+			got := checkScript(t, wfSigCtx(t, "11.13.0", 11, 13), c.src)
+			assertSignatureVerdict(t, got, c.want)
+		})
+	}
+}
+
+// The ordinary shape is ONE script that creates the page, the targeting
+// microflow and the workflow. A rule that could only see stored documents would
+// fire on the minority case, and the majority case is the one that reaches a
+// build half-written.
+func TestWorkflowTaskSignatures_ScriptDefined(t *testing.T) {
+	cases := []struct{ name, src, want string }{
+		{
+			"script page typed to the context",
+			`create page M.ScriptPg ( title: 'x', layout: Atlas_Core.Atlas_Default, params: { $C: M.Ctx } ) { };
+create workflow M.W parameter $C: M.Ctx begin user task T 'c' page M.ScriptPg outcomes 'a' { } 'b' { }; end workflow;`,
+			"CE7412",
+		},
+		{
+			"script page typed to WorkflowUserTask",
+			`create page M.ScriptPg ( title: 'x', layout: Atlas_Core.Atlas_Default, params: { $WorkflowUserTask: System.WorkflowUserTask } ) { };
+create workflow M.W parameter $C: M.Ctx begin user task T 'c' page M.ScriptPg outcomes 'a' { } 'b' { }; end workflow;`,
+			"",
+		},
+		{
+			"script microflow with one parameter",
+			`create microflow M.ScriptMF ( $workflow: System.Workflow ) returns list of System.User as $u begin return $u; end;
+create workflow M.W parameter $C: M.Ctx begin user task T 'c' page M.PgGood targeting microflow M.ScriptMF outcomes 'a' { } 'b' { }; end workflow;`,
+			"CE6677",
+		},
+		{
+			"script microflow reversed",
+			`create microflow M.ScriptMF ( $context: M.Ctx, $workflow: System.Workflow ) returns list of System.User as $u begin return $u; end;
+create workflow M.W parameter $C: M.Ctx begin user task T 'c' page M.PgGood targeting microflow M.ScriptMF outcomes 'a' { } 'b' { }; end workflow;`,
+			"",
+		},
+		{
+			// A script entity inheriting from a stored one: the chain is
+			// resolvable through the script, then the project.
+			"script context entity extends the microflow's entity",
+			`create persistent entity M.NewSub extends M.Base ( X: string(10) );
+create workflow M.W parameter $C: M.NewSub begin user task T 'c' page M.PgGood targeting microflow M.MF_TakesBase outcomes 'a' { } 'b' { }; end workflow;`,
+			"",
+		},
+		{
+			// The chain leaves what can be resolved. Unprovable is not a
+			// refusal: exec refuses on an error, so a guess here blocks a
+			// script mxbuild would build.
+			"unresolvable inheritance chain is not refused",
+			`create persistent entity M.Orphan extends Elsewhere.Unknown ( X: string(10) );
+create workflow M.W parameter $C: M.Orphan begin user task T 'c' page M.PgGood targeting microflow M.MF_TakesBase outcomes 'a' { } 'b' { }; end workflow;`,
+			"",
+		},
+	}
+	for _, c := range cases {
+		t.Run(c.name, func(t *testing.T) {
+			got := checkScript(t, wfSigCtx(t, "11.13.0", 11, 13), c.src)
+			assertSignatureVerdict(t, got, c.want)
+		})
+	}
+}
+
+// ALTER writes the same two references into a stored workflow, so it gets the
+// same rule. SET TARGETING MICROFLOW has no context entity in the statement —
+// it comes from the stored workflow's parameter.
+func TestWorkflowTaskSignatures_Alter(t *testing.T) {
+	cases := []struct{ name, src, want string }{
+		{"set page", `alter workflow M.Stored set activity T page M.PgCtx;`, "CE7412"},
+		{"set page (valid)", `alter workflow M.Stored set activity T page M.PgExtra;`, ""},
+		{"set targeting microflow", `alter workflow M.Stored set activity T targeting microflow M.MF_WfOnly;`, "CE6677"},
+		{"set targeting microflow (valid)", `alter workflow M.Stored set activity T targeting microflow M.MF_Reversed;`, ""},
+		{"insert user task", `alter workflow M.Stored insert after T user task U 'u' page M.PgNone outcomes 'a' { } 'b' { };`, "CE7410"},
+	}
+	for _, c := range cases {
+		t.Run(c.name, func(t *testing.T) {
+			got := checkScript(t, wfSigCtx(t, "11.13.0", 11, 13), c.src)
+			assertSignatureVerdict(t, got, c.want)
+		})
+	}
+}
+
+// The rules are measured on 11.13 only. On an older project the check stays
+// out of the way rather than applying a guess — the MDL-WF07 precedent.
+func TestWorkflowTaskSignatures_NotAppliedBeforeMendix11(t *testing.T) {
+	src := `create workflow M.W parameter $C: M.Ctx begin user task T 'c' page M.PgCtx targeting microflow M.MF_WfOnly outcomes 'a' { } 'b' { }; end workflow;`
+	got := checkScript(t, wfSigCtx(t, "10.24.0", 10, 24), src)
+	assertSignatureVerdict(t, got, "")
+}
+
+// assertSignatureVerdict checks for the CE code, or for the absence of every
+// code this rule reports. It does not demand an empty result: script-defined
+// pages trip unrelated checks in a mock project (no Atlas layout), and those
+// are not what these tests are about.
+func assertSignatureVerdict(t *testing.T, got, want string) {
+	t.Helper()
+	if want != "" {
+		if !strings.Contains(got, want) {
+			t.Errorf("expected %s, got:\n%s", want, got)
+		}
+		return
+	}
+	for _, code := range []string{"CE7410", "CE7412", "CE6677"} {
+		if strings.Contains(got, code) {
+			t.Errorf("expected no signature error, got %s:\n%s", code, got)
+		}
+	}
+}

From 58a20ca02e25bc14501a751611ee3a7151c74c00 Mon Sep 17 00:00:00 2001
From: Ako <andrej@koelewijn.net>
Date: Mon, 14 Sep 2026 14:50:53 +0000
Subject: [PATCH 2/9] docs(workflow): document the task page and targeting
 microflow signatures

Neither signature was anywhere in `mxcli syntax workflow`, so an author had
nothing to copy and found both rules by failing a build. The user-task topic
now states the page rule (a System.WorkflowUserTask parameter; others may sit
alongside it) and the targeting topic the microflow rule (exactly System.Workflow
plus the context entity or a generalization, either order), with the users /
groups forms and a runnable example of each.

Adds a `workflow.multi-user-task` topic. The grammar has accepted
`multi user task` for a long time, and a team shipped one fanning out to eight
assessors, but with no topic it read as unsupported. It says plainly that MDL
has no clause for the completion settings.

The skill and quick reference carry the same rules, including that `check
--references` reports them before anything is written while exec refuses only
the workflow statement.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 .../skills/mendix/write-workflows/SKILL.md    | 17 +++++
 CHANGELOG.md                                  |  8 ++
 cmd/mxcli/syntax/features_workflow.go         | 74 +++++++++++++++++--
 docs/01-project/MDL_QUICK_REFERENCE.md        |  5 +-
 4 files changed, 96 insertions(+), 8 deletions(-)

diff --git a/.claude/skills/mendix/write-workflows/SKILL.md b/.claude/skills/mendix/write-workflows/SKILL.md
index df0ec11db..4fab516a9 100644
--- a/.claude/skills/mendix/write-workflows/SKILL.md
+++ b/.claude/skills/mendix/write-workflows/SKILL.md
@@ -317,6 +317,23 @@ documented in `system-module`.
 
 - A user task needs a **task page** to be useful; without one Mendix flags the
   task (`CE1834`). Bind the page to `System.WorkflowUserTask`.
+- **The task page takes the TASK, not the workflow's context object.** It must
+  declare a `System.WorkflowUserTask` parameter: a page with no parameters is
+  `CE7410`, a page whose parameters are all something else (the usual mistake:
+  the context entity) is `CE7412`. Other parameters may sit alongside the task
+  one — that builds clean. Multi-user tasks follow the same rule.
+- **A targeting microflow takes exactly two parameters: `System.Workflow` and
+  the workflow's context entity**, in either order. One parameter, none, or a
+  third is `CE6677`. The context parameter may be typed to a *generalization* of
+  the context entity, not a specialization. `targeting groups microflow` takes
+  the same two and returns a list of `System.WorkflowGroup`; users targeting
+  returns a list of `System.User`.
+- `mxcli check --references` reports both signatures **before anything is
+  written**, for pages and microflows in the project or created earlier in the
+  same script (measured on Mendix 11.13; not applied to older projects). `exec`
+  refuses the workflow statement itself, so the workflow is never written — but
+  the statements before it in the script already are. Run `check --references`
+  first. Plain `mxcli check` without a project cannot see these.
 - A user task / decision with a single outcome and no activity can trip
   `CE1876` — give each branch a body or a distinct outcome.
 - **An enum decision's outcome must be `Module.Enumeration.Value`.** Mendix
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 7464617a8..b77b53a65 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -135,6 +135,14 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ### Fixed
 
+- **A wrong task page or targeting microflow signature passed `check --references`** — a workflow user task whose task page takes the context entity instead of the task, or whose targeting microflow does not take `System.Workflow` plus the context entity, was written by `exec` and failed only in the native build (CE7410, CE7412, CE6677). Reference checking resolved both documents by name and never looked at their parameters, and neither signature was in `mxcli syntax workflow`, so there was nothing to copy. Reported in a team briefing on building workflows from MDL, as two of the reasons "a green CLI check is not evidence for workflows".
+
+  Both are now checked, for CREATE WORKFLOW (nested and multi-user tasks included) and ALTER WORKFLOW (inserted tasks, and `set activity … page` / `targeting microflow`, where the context entity is read off the stored workflow). Pages and microflows are resolved from the script first — the page, the microflow and the workflow are ordinarily one script — then the project. `check --references` reports them before anything is written. `exec` runs the same function when it reaches the workflow statement, so the workflow with the wrong signature is never written — but statements before it in the script already are, as with any reference error `exec` meets mid-script.
+
+  Every rule is a row of an mxbuild measurement on 11.13, and three of the rows are clean shapes a reading of the error text would have refused: a task page **may** take parameters besides `System.WorkflowUserTask`, a targeting microflow **may** take its two parameters in either order, and its context parameter **may** be a generalization of the context entity (a specialization is CE6677). Since `exec` refuses on a check error, those would have been blockers, not warnings. An inheritance chain that leaves what can be resolved is treated as unproven rather than wrong. Gated on Mendix 11, where it is measured.
+
+  `mxcli syntax workflow` gains a **`multi-user-task`** topic — the grammar has accepted `multi user task` for a long time, but with no topic it read as unsupported — and the `user-task` and `targeting` topics now state both signatures, the `users`/`groups` targeting forms, and a runnable example of each.
+
 - **An empty graph-analysis table could not be told apart from one that was never computed** (mendixlabs/mxcli#1060). `CATALOG.GRAPH_CYCLES` answered `0 rows` on a project whose `CATALOG.GRAPH_MODULE_COUPLING` listed mutual module pairs, so it read as "no circular dependencies". The two are built by different things: coupling is a plain view over `refs` that any full catalog answers, while the cycles/communities/layers/centrality tables are written only by `REFRESH CATALOG COMMUNITIES` — and those six were in neither `fullOnlyTables` nor `sourceOnlyTables`, so nothing warned.
 
   The mode ladder could not carry the distinction. fast/full/source is a *level*, each containing the one below, which is what lets a rank comparison decide everything; the graph pass is orthogonal, augmenting whichever level is cached. It is now recorded as a flag plus the resolution it ran at. A query against one of the six says `requires refresh catalog communities (not run for this catalog)`; `SHOW CATALOG STATUS` reports `Graph analysis: ✓/✗` separately from the build mode; `DESCRIBE CATALOG.GRAPH_CYCLES` names the command that populates it.
diff --git a/cmd/mxcli/syntax/features_workflow.go b/cmd/mxcli/syntax/features_workflow.go
index a044d8ba4..eed9e6cbe 100644
--- a/cmd/mxcli/syntax/features_workflow.go
+++ b/cmd/mxcli/syntax/features_workflow.go
@@ -44,9 +44,27 @@ func init() {
 			"user task", "human task", "assign", "assignee",
 			"outcomes", "approve", "reject", "page",
 		},
-		Syntax:  "USER TASK <name> '<caption>'\n  [PAGE Module.Page]\n  [TARGETING MICROFLOW Module.MF | TARGETING XPATH '<xpath>']\n  [ENTITY Module.Entity]\n  OUTCOMES '<outcome1>' { <activities> } '<outcome2>' { <activities> };",
-		Example: "USER TASK ReviewTask 'Review the request'\n  PAGE HR.ReviewPage\n  TARGETING XPATH '[Module.Employee/Active = true()]'\n  OUTCOMES 'Approve' { } 'Reject' { };",
-		SeeAlso: []string{"workflow.user-task.targeting", "workflow.create"},
+		// The task page's parameter rule is the platform's, not MDL's, and it was
+		// nowhere in this help — a team building workflows from MDL found it by
+		// failing a build. Measured on 11.13: no parameters is CE7410, parameters
+		// without a WorkflowUserTask one is CE7412, and a WorkflowUserTask
+		// parameter PLUS others builds clean, so the help must not say "exactly".
+		Syntax: "[MULTI] USER TASK <name> '<caption>'\n" +
+			"  PAGE Module.TaskPage\n" +
+			"  [TARGETING [USERS | GROUPS] MICROFLOW Module.MF | TARGETING [USERS | GROUPS] XPATH '<xpath>']\n" +
+			"  [ENTITY Module.Entity]\n" +
+			"  [DUE DATE '<expression>']\n" +
+			"  [DESCRIPTION '<text>']\n" +
+			"  OUTCOMES '<outcome1>' { <activities> } '<outcome2>' { <activities> };\n\n" +
+			"-- The task page is opened with the TASK, not with the workflow's context\n" +
+			"-- object, so it must take a System.WorkflowUserTask parameter:\n" +
+			"--   page with no parameters              -> CE7410\n" +
+			"--   page without a WorkflowUserTask one  -> CE7412\n" +
+			"-- Other parameters may sit alongside it.",
+		Example: "-- The task page takes the task:\n" +
+			"CREATE PAGE HR.ReviewPage (\n  title: 'Review',\n  layout: Atlas_Core.Atlas_Default,\n  params: { $WorkflowUserTask: System.WorkflowUserTask }\n) { };\n\n" +
+			"USER TASK ReviewTask 'Review the request'\n  PAGE HR.ReviewPage\n  TARGETING XPATH '[Module.Employee/Active = true()]'\n  OUTCOMES 'Approve' { } 'Reject' { };",
+		SeeAlso: []string{"workflow.user-task.targeting", "workflow.multi-user-task", "workflow.create"},
 	})
 
 	Register(SyntaxFeature{
@@ -55,12 +73,54 @@ func init() {
 		Keywords: []string{
 			"targeting", "user targeting", "who can execute",
 			"assignee", "candidate", "xpath", "microflow",
-			"task assignment", "user filter",
+			"task assignment", "user filter", "workflow group",
+			"targeting microflow parameters", "targeting signature",
 		},
-		Syntax:     "TARGETING MICROFLOW Module.MF\nTARGETING XPATH '<xpath-expression>'",
-		Example:    "-- XPath targeting: only active managers\nUSER TASK Approve 'Approve request'\n  TARGETING XPATH '[HR.Employee/Role = \"Manager\" and Active = true()]'\n  OUTCOMES 'Done' { };\n\n-- Microflow targeting: custom logic\nUSER TASK Approve 'Approve request'\n  TARGETING MICROFLOW HR.GetApprovers\n  OUTCOMES 'Done' { };",
+		// The targeting microflow's signature was undocumented, and both of its
+		// traps are ones a reading of the error text gets wrong. Measured on
+		// 11.13: exactly TWO parameters (one, none, or a third is CE6677), in
+		// EITHER order, and the context parameter may be a GENERALIZATION of the
+		// context entity but not a specialization. Users and groups share it.
+		Syntax: "TARGETING [USERS] MICROFLOW Module.MF    -- returns a List of System.User\n" +
+			"TARGETING GROUPS MICROFLOW Module.MF     -- returns a List of System.WorkflowGroup\n" +
+			"TARGETING [USERS | GROUPS] XPATH '<xpath-expression>'\n\n" +
+			"-- A targeting microflow takes EXACTLY two parameters, in either order:\n" +
+			"--   System.Workflow\n" +
+			"--   the workflow's context entity, or a generalization of it\n" +
+			"-- One parameter, none, a third, or a specialization of the context\n" +
+			"-- entity is CE6677.",
+		Example: "-- XPath targeting: only active managers\nUSER TASK Approve 'Approve request'\n  TARGETING XPATH '[HR.Employee/Role = \"Manager\" and Active = true()]'\n  OUTCOMES 'Done' { };\n\n" +
+			"-- Microflow targeting: the microflow takes the workflow AND its context object\n" +
+			"CREATE MICROFLOW HR.GetApprovers ($Workflow: System.Workflow, $Request: HR.Request)\nRETURNS List of System.User AS $Approvers\nBEGIN\n  RETRIEVE $Approvers FROM System.User;\n  RETURN $Approvers;\nEND;\n\n" +
+			"USER TASK Approve 'Approve request'\n  TARGETING MICROFLOW HR.GetApprovers\n  OUTCOMES 'Done' { };",
 		MinVersion: "9.0.0",
-		SeeAlso:    []string{"workflow.user-task"},
+		SeeAlso:    []string{"workflow.user-task", "workflow.multi-user-task"},
+	})
+
+	Register(SyntaxFeature{
+		Path:    "workflow.multi-user-task",
+		Summary: "Multi-user task — one activity that several users each act on",
+		Keywords: []string{
+			"multi user task", "multi-user task", "several users", "multiple assignees",
+			"assessors", "voting", "parallel approval", "group approval",
+		},
+		// The grammar has accepted MULTI USER TASK since issue #8, and a team
+		// shipped one fanning out to eight assessors — but there was no topic for
+		// it, so it read as unsupported. It takes USER TASK's clauses and obeys the
+		// same page rule (measured: a context-typed page is CE7412 on a multi-user
+		// task too) and the same targeting rule.
+		Syntax: "MULTI USER TASK <name> '<caption>'\n" +
+			"  PAGE Module.TaskPage\n" +
+			"  [TARGETING [USERS | GROUPS] MICROFLOW Module.MF | TARGETING [USERS | GROUPS] XPATH '<xpath>']\n" +
+			"  [ENTITY Module.Entity]\n" +
+			"  [DUE DATE '<expression>']\n" +
+			"  [DESCRIPTION '<text>']\n" +
+			"  OUTCOMES '<outcome1>' { <activities> } '<outcome2>' { <activities> };\n\n" +
+			"-- Same clauses, task-page rule and targeting rule as USER TASK.\n" +
+			"-- MDL has no clause for a multi-user task's completion settings (how the\n" +
+			"-- individual answers decide the outcome); set those in Studio Pro.",
+		Example: "MULTI USER TASK ExpertAssessment 'Expert assessment'\n  PAGE MOC.AssessmentPage\n  TARGETING MICROFLOW MOC.GetAssessors\n  OUTCOMES 'Approve' { } 'Reject' { };",
+		SeeAlso: []string{"workflow.user-task", "workflow.user-task.targeting"},
 	})
 
 	Register(SyntaxFeature{
diff --git a/docs/01-project/MDL_QUICK_REFERENCE.md b/docs/01-project/MDL_QUICK_REFERENCE.md
index fa3d8e57d..49adcd9fc 100644
--- a/docs/01-project/MDL_QUICK_REFERENCE.md
+++ b/docs/01-project/MDL_QUICK_REFERENCE.md
@@ -663,7 +663,10 @@ Nested folders use `/` separator: `'Parent/Child/Grandchild'`. Missing folders a
 | Drop workflow | `drop workflow Module.Name;` | |
 
 **Workflow Activity Types:**
-- `user task <name> '<caption>' [page Mod.Page] [targeting [users|groups] microflow Mod.MF] [targeting [users|groups] xpath '<expr>'] [outcomes '<out>' { } ...];`
+- `[multi] user task <name> '<caption>' [page Mod.Page] [targeting [users|groups] microflow Mod.MF] [targeting [users|groups] xpath '<expr>'] [outcomes '<out>' { } ...];`
+  - The **task page** must take a `System.WorkflowUserTask` parameter — none at all is CE7410, none of that type is CE7412; extra parameters are allowed.
+  - A **targeting microflow** takes exactly `System.Workflow` + the context entity (or a generalization of it), in either order — anything else is CE6677. Users targeting returns a list of `System.User`, groups a list of `System.WorkflowGroup`.
+  - `check --references` reports both before anything is written; `exec` refuses the workflow statement itself (Mendix 11+).
 - `call microflow Mod.MF [as <name>] [comment '<text>'] [with (<Param> = '<expr>', ...)] [outcomes '<out>' -> { } ...];`
 - `call workflow Mod.WF [as <name>] [comment '<text>'] [with (<Param> = '<expr>', ...)];`
 - `decision [<name>] ['<expression>'] outcomes <true|false|'Module.Enum.Value'> -> { } ...;`

From 33c6130ce71b4189e7420aaa5dec31be20d8a406 Mon Sep 17 00:00:00 2001
From: Ako <andrej@koelewijn.net>
Date: Mon, 14 Sep 2026 14:52:34 +0000
Subject: [PATCH 3/9] fix(check): stop telling a workflow statement to move
 before itself
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Every exec / check --references error that named the workflow being created
ended with "hint: M.W is defined later in this script — move its create
statement before this one". annotateForwardRef draws its candidates from
scriptContext.allNames, which includes workflows, and excludes the failing
statement's own name and anything already created through scriptContext.has,
which answered for every kind a script can create except workflows. Two lists
over the same kinds, with nothing keeping them in step.

It surfaced through the task page / targeting signature errors, which name
their workflow on every refusal, but any workflow reference error had it.

Test first: the own-name and already-created cases failed with the reported
hint while the genuine forward reference was annotated as before; all three
pass with the fix.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 .../fix-issue/findings/mdl-executor.jsonl     |  1 +
 CHANGELOG.md                                  |  2 +
 mdl/executor/validate.go                      |  7 ++-
 mdl/executor/validate_forwardref_test.go      | 44 +++++++++++++++++++
 4 files changed, 53 insertions(+), 1 deletion(-)

diff --git a/.claude/skills/fix-issue/findings/mdl-executor.jsonl b/.claude/skills/fix-issue/findings/mdl-executor.jsonl
index 0effd8834..175b0e38a 100644
--- a/.claude/skills/fix-issue/findings/mdl-executor.jsonl
+++ b/.claude/skills/fix-issue/findings/mdl-executor.jsonl
@@ -614,3 +614,4 @@
 {"area": "mdl/executor", "date": "2026-09-13", "symptom": "describe page -> create or replace page broke a button's icon. An icon into an IMAGE collection came back as `Icon: 'DesignSystem.Icons_SVG.edit'` and the build failed [CE1613] \"The selected custom icon 'DesignSystem.Icons_SVG.edit' no longer exists.\" A GLYPH icon produced no describe output at all -- no clause, no comment -- and replay DELETED it at exit 0.", "cause": "Mendix stores three icon elements and two put a qualified name under the same BSON key: Forms$IconCollectionIcon{Image}->CustomIcons$CustomIcon, Forms$ImageIcon{Image}->Images$Image, Forms$GlyphIcon{Code}. extractIconRef read `Image` off whichever element was there and threw the $Type away, and the page builder writes Forms$IconCollectionIcon unconditionally -- so the two named variants were spelled identically on the way out and collapsed into one on the way back in.", "file": "mdl/executor/cmd_pages_describe_output.go (extractButtonIcon, widgetIconMDL, widgetIconNote), mdl/executor/cmd_pages_describe.go (rawWidget.IconType/IconCode), mdl/executor/cmd_pages_describe_parse.go; tests mdl/executor/cmd_pages_describe_icon_test.go", "insight": "The identical three-variant defect was fixed in NAVIGATION eight days earlier (2026-09-05, same area file) and the page path never received it -- so the cheapest possible diagnosis was `grep MenuIconKindOf`, and the fix reuses that resolver rather than adding a second one. **Generalisable: when a fix teaches a layer to distinguish polymorphic variants, grep for every OTHER reader of the same element.** The find was one `git grep Forms\\$ImageIcon` away all along. Two things the report got understandably wrong and that the fix depends on getting right: it is not about third-party vs native collections (a third-party ICON collection round-trips fine -- and CE1613 naming the reference is itself proof the name was never a custom icon, since mxbuild would otherwise have resolved it), and the reported image-icon case is the CHEAPER half -- the glyph case is silent on both sides, so nothing in the output even hints at the loss. **Measure the silence, not the wrong answer**: `grep -c icon` over describe output of a stock marketplace project's FeedbackModule pages returned 0 before and 3 after, which is the only form the glyph bug has. The note has to fire on an UNRECOGNISED $Type too, not a known-bad list, or the next variant Mendix adds is dropped the same way. Controls that matter: an icon-collection icon must still emit a bare `Icon:` and NO note (else the fix passes by flagging everything), and an iconless button must emit neither. No .mdl repro is possible -- mxcli cannot author an image or glyph icon on a button, so the input to the round trip cannot be constructed in MDL; the reproduction is a stored-widget map in the unit test. Also observed in passing and NOT fixed: a nameless `statictext` makes describe output unparseable (pre-existing, confirmed against the base binary), and NavigationList item / DropDownButton icons are never read at all, so they are dropped as silently as the glyph was.", "refs": ["#1059", "#1008", "#602"], "ce": ["CE1613"]}
 {"area": "mdl/executor", "date": "2026-09-13", "symptom": "Follow-on to #1059: a widget's image and glyph icons were readable but unwritable, so describe -> exec could only be made honest (a `-- NOT re-executable` note), not lossless. Authoring them needed the kind to reach the element $Type through grammar, AST, visitor, builder and BOTH engines.", "cause": "Three separate vocabularies for the same three Mendix icon elements: types.MenuIconKind (navigation), pages.IconType (the page model's own three-value enum), and a bare string in the widget property map. The page path had no kind at all, so it could not express one.", "file": "mdl/grammar/domains/MDLPage.g4 (widgetIconV3), mdl/ast/ast_page_v3.go (WidgetIcon), mdl/visitor/visitor_page_v3.go (buildWidgetIconV3), mdl/executor/cmd_pages_builder_v3_widgets.go (buildWidgetIcon), mdl/backend/modelsdk/widget_write.go (iconToGen), sdk/mpr/writer_widgets_display.go (buildWidgetIconBson), mdl/executor/validate_icon_refs.go, mdl/executor/validate_glyph_codes.go", "insight": "**Delete the second vocabulary as part of the fix, not after it.** pages.IconType existed for exactly the same three kinds as types.MenuIconKind and had drifted to a different value set; replacing it (2 call sites) is what made the writers a dispatch rather than an inference. A feature that adds a third copy would have re-created the bug in a new place. **The pre-existing tests of the OLD feature are the safety net for the new one**: MDL078's menu tests caught a python replace of mine that silently no-opped (anchor did not match, no assert), which nothing else would have. Always assert on the replacement count when editing by script. **Measure the premise, don't reason by analogy** — extending MDL078 to widget glyphs assumed mxbuild resolves a widget glyph the same way it resolves a menu one. It does, measured: `Icon: glyph 57562` fails `mxbuild --target=deploy` with `System.InvalidOperationException: Sequence contains no matching element` — but it names the **page**, not a layout, so the rule's own message was wrong and had to be corrected from the measurement. **The reference check had the mirror-image bug waiting**: resolving an image reference against the ICON collections reports a correct name as a typo, which is the same conflation pointed the other way — per-kind resolution plus an `otherKindHint` naming the remedy. **An empty listing is 'could not establish', not 'none'** — each half of the index is independent, so a project that yields icon collections but no image collections still resolves what it can. Verified on 11.13.0: all three authored, mx check 0 errors, deploy BUILD SUCCEEDED, right $Type on disk; controls reproduce CE1613 (image written without `image`) and the glyph build failure. Corpus sweep 531 clean.", "refs": ["#1059", "#1008", "#602"], "ce": ["CE1613"]}
 {"area": "mdl/executor", "date": "2026-09-14", "symptom": "A workflow user task whose task page takes the context entity instead of System.WorkflowUserTask (CE7412), takes no parameters (CE7410), or whose targeting microflow does not take exactly System.Workflow plus the context entity (CE6677) passed `mxcli check` AND `check --references`, was written by exec, and failed only under the native mx check. Reported in a team briefing on building workflows from MDL as two of the reasons 'a green CLI check is not evidence for workflows'.", "cause": "validateWorkflowReferences resolved the user task's page and targeting microflow by NAME only — it reported a document that does not exist, never one that exists with the wrong signature. Neither signature was in `mxcli syntax workflow` either, so authors had nothing to copy.", "fix": "validate_workflow_task_signature.go checks both signatures from the script's own definitions first (scriptContext now records page parameter entities and entity generalizations, beside flowParams) and then the project, for CREATE WORKFLOW (incl. nested and multi-user tasks) and ALTER WORKFLOW (inserted tasks, SET ACTIVITY PAGE / TARGETING MICROFLOW, context entity read off the stored workflow). Wired into validateWorkflowStatementRefs / validateAlterWorkflowRefs. check --references reports before anything is written; exec calls the same function at the workflow statement, so the workflow is never written but earlier statements in the script already are. Gated on Mendix 11, where it is measured.", "file": "mdl/executor/validate_workflow_task_signature.go", "insight": "Measure the CLEAN edges before writing a refusal — three of the nine rows would have been false refusals from a plausible reading of the error text: a task page MAY take extra parameters besides WorkflowUserTask, a targeting microflow MAY take its two parameters in either order, and its context parameter MAY be a generalization of the context entity (but not a specialization). Since exec refuses on a check error, a false refusal is a blocker. Where the inheritance chain leaves what can be resolved (a script entity extending something unknown), return 'not proven' rather than a mismatch. Also a harness caveat worth keeping: the control run that stubbed the version gate first reported 0 failures because the harness only counted `--- FAIL` lines containing '/', i.e. subtests; the gate test is top-level. A silent control is a claim about the harness before it is a claim about the test."}
+{"area": "mdl/executor", "date": "2026-09-14", "symptom": "An `exec` / `check --references` error on a CREATE WORKFLOW statement ends with 'hint: M.W is defined later in this script — move its create statement before this one', naming the failing workflow itself (or a workflow already created earlier in the script).", "cause": "annotateForwardRef draws candidate names from scriptContext.allNames (which includes workflows) and excludes the statement's own name and already-created names via scriptContext.has — which checked modules, entities, enumerations, microflows, nanoflows, pages, snippets and code actions but NOT workflows. A parallel list that drifted from the one it filters.", "fix": "scriptContext.has also answers for sc.workflows.", "file": "mdl/executor/validate.go", "insight": "Two lists over the same kinds (allNames and has) with nothing tying them together — the same drift shape as collectDefinitions/collectSingle. The misfire only became visible once an error routinely named its own workflow, i.e. a new rule surfaced a latent bug in how every rule's message is decorated. When adding a document kind to scriptContext, check every method that enumerates kinds, not just the collector."}
diff --git a/CHANGELOG.md b/CHANGELOG.md
index b77b53a65..cd06c251c 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -135,6 +135,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ### Fixed
 
+- **A failing workflow statement told the author to move it before itself** — every `exec` or `check --references` error naming the workflow being created carried *"hint: M.W is defined later in this script — move its create statement before this one"*. The reorder hint excludes the failing statement's own name and anything already created, but it asks `scriptContext.has()`, which answered for every kind a script can create except workflows, while the list the hint is drawn from includes them. It surfaced on the task page / targeting signature errors below, which name their workflow on every refusal; any workflow reference error had it.
+
 - **A wrong task page or targeting microflow signature passed `check --references`** — a workflow user task whose task page takes the context entity instead of the task, or whose targeting microflow does not take `System.Workflow` plus the context entity, was written by `exec` and failed only in the native build (CE7410, CE7412, CE6677). Reference checking resolved both documents by name and never looked at their parameters, and neither signature was in `mxcli syntax workflow`, so there was nothing to copy. Reported in a team briefing on building workflows from MDL, as two of the reasons "a green CLI check is not evidence for workflows".
 
   Both are now checked, for CREATE WORKFLOW (nested and multi-user tasks included) and ALTER WORKFLOW (inserted tasks, and `set activity … page` / `targeting microflow`, where the context entity is read off the stored workflow). Pages and microflows are resolved from the script first — the page, the microflow and the workflow are ordinarily one script — then the project. `check --references` reports them before anything is written. `exec` runs the same function when it reaches the workflow statement, so the workflow with the wrong signature is never written — but statements before it in the script already are, as with any reference error `exec` meets mid-script.
diff --git a/mdl/executor/validate.go b/mdl/executor/validate.go
index 6ec444156..35ee9fee3 100644
--- a/mdl/executor/validate.go
+++ b/mdl/executor/validate.go
@@ -287,8 +287,13 @@ func (sc *scriptContext) has(name string) bool {
 	if _, ok := sc.javaScriptActions[name]; ok {
 		return true
 	}
+	// Every kind allNames lists must be answerable here. allNames includes
+	// workflows and this did not, so annotateForwardRef could exclude neither a
+	// workflow's own name nor one already created, and told the author to move a
+	// workflow statement before itself.
 	return sc.modules[name] || sc.entities[name] || sc.enumerations[name] ||
-		sc.microflows[name] || sc.nanoflows[name] || sc.pages[name] || sc.snippets[name]
+		sc.microflows[name] || sc.nanoflows[name] || sc.pages[name] || sc.snippets[name] ||
+		sc.workflows[name]
 }
 
 // validateProgram validates all statements in a program, skipping references
diff --git a/mdl/executor/validate_forwardref_test.go b/mdl/executor/validate_forwardref_test.go
index 13d6f2318..12bb82ead 100644
--- a/mdl/executor/validate_forwardref_test.go
+++ b/mdl/executor/validate_forwardref_test.go
@@ -47,3 +47,47 @@ create microflow Test.Later () returns Boolean begin return true; end;`
 		}
 	})
 }
+
+// A workflow's own name is not a forward reference either. scriptContext.has
+// checked every kind a script can create EXCEPT workflows — while allNames, the
+// list the hint is drawn from, includes them — so every error naming the
+// workflow being created ("workflow 'X' has reference errors") told the author
+// to move the statement before itself. Found through the task page / targeting
+// signature errors, which name their workflow on every refusal.
+func TestAnnotateForwardRef_SkipsOwnWorkflowName(t *testing.T) {
+	script := `create workflow Test.Earlier parameter $C: Test.Ctx begin call microflow Test.ACT; end workflow;
+create workflow Test.Current parameter $C: Test.Ctx begin call microflow Test.ACT; end workflow;
+create workflow Test.Later parameter $C: Test.Ctx begin call microflow Test.ACT; end workflow;`
+	prog, errs := visitor.Build(script)
+	if len(errs) > 0 {
+		t.Fatalf("parse error: %v", errs[0])
+	}
+	allDefined := newScriptContext()
+	for _, s := range prog.Statements {
+		allDefined.collectSingle(s)
+	}
+	created := newScriptContext()
+	created.collectSingle(prog.Statements[0]) // Test.Earlier already exists
+	current := prog.Statements[1]
+
+	t.Run("own workflow name is not a forward reference", func(t *testing.T) {
+		err := errors.New("workflow 'Test.Current' has reference errors")
+		if got := annotateForwardRef(err, current, created, allDefined); strings.Contains(got.Error(), "defined later in this script") {
+			t.Errorf("workflow was annotated as referring forward to itself:\n%s", got.Error())
+		}
+	})
+
+	t.Run("an earlier workflow is not a forward reference", func(t *testing.T) {
+		err := errors.New("call workflow Test.Earlier: parameter is not mapped")
+		if got := annotateForwardRef(err, current, created, allDefined); strings.Contains(got.Error(), "defined later in this script") {
+			t.Errorf("an already-created workflow was annotated as a forward reference:\n%s", got.Error())
+		}
+	})
+
+	t.Run("a genuine forward reference to a workflow is still annotated", func(t *testing.T) {
+		err := errors.New("workflow not found: Test.Later")
+		if got := annotateForwardRef(err, current, created, allDefined); !strings.Contains(got.Error(), "defined later in this script") {
+			t.Errorf("expected a reorder hint for Test.Later, got:\n%s", got.Error())
+		}
+	})
+}

From a20bd8c034589ce17c9122983c9bdd0b8c7faeae Mon Sep 17 00:00:00 2001
From: Ako <andrej@koelewijn.net>
Date: Mon, 14 Sep 2026 17:40:01 +0000
Subject: [PATCH 4/9] =?UTF-8?q?docs(proposal):=20end=20workflow=20?=
 =?UTF-8?q?=E2=80=94=20ending=20a=20workflow=20from=20inside=20a=20branch?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

MDL could not end a workflow from a user-task outcome, a decision branch or a
boundary-event path, and `describe workflow` dropped every End it met, so a
Studio Pro workflow whose Reject outcome ends the process described as an empty
outcome that falls through into the main flow. A team building native
workflows from MDL named it the one structural gap left after four projects.

The proposal measures Mendix's placement rules before designing syntax — a
throwaway spike placed End activities through the existing (never wired)
builder on mxbuild 11.13.0, both engines — and settles `end workflow [comment
'<caption>'];` in any `{ }` block, with illegal placements refused by check
rules rather than the grammar. It records the discussion behind the spelling:
`end workflow` is a microflow `return`'s counterpart, but `return;` inside a
block reads as "rejoin the main flow", which is the fault being fixed; and
`comment` writes a caption, a keyword issue left to a separate change.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 .../PROPOSAL_workflow_end_activity.md         | 325 ++++++++++++++++++
 1 file changed, 325 insertions(+)
 create mode 100644 docs/11-proposals/PROPOSAL_workflow_end_activity.md

diff --git a/docs/11-proposals/PROPOSAL_workflow_end_activity.md b/docs/11-proposals/PROPOSAL_workflow_end_activity.md
new file mode 100644
index 000000000..8445b2fb0
--- /dev/null
+++ b/docs/11-proposals/PROPOSAL_workflow_end_activity.md
@@ -0,0 +1,325 @@
+---
+title: End activity for MDL workflows
+status: implemented
+date: 2026-09-14
+---
+
+# Proposal: End activity for MDL workflows
+
+**Status:** Implemented — grammar, builder naming, describe, MDL-WF08..11, the rewrite guard and ALTER, measured end to end. The open questions that remain are below.
+
+## Problem Statement
+
+MDL cannot end a workflow from inside a branch. A user-task outcome, a decision
+branch or a boundary-event path either continues into the main flow or jumps
+somewhere — there is no way to say *"on Reject, the workflow is over"*.
+
+It is the one structural gap a team building native workflows from MDL reported
+after four projects (briefing, 14 Sep 2026): *"ending a branch early is the one
+thing an approval workflow cannot say, and the fallthrough is silent at check
+time"*. Its consequences in their projects:
+
+- **Silent fallthrough.** An empty outcome block written to stop the instance
+  instead rejoins the main flow, and every later task is created for a request
+  that was rejected. `mxcli check`, `exec` and `mx check` all pass.
+- **Redesigned processes.** "Reject ends the workflow" had to be rebuilt as a
+  backward `jump to`, or the workflow split, or the End hand-added in Studio Pro
+  after every scripted rewrite.
+- **Interrupting boundary events are half-expressible.** Their path must end in
+  an End or a jump; only the jump can be written.
+
+The gap is older than it looks. The first workflow grammar (519de885) carried
+the note `// workflowEndStmt removed - END activities are implicit and conflict
+with END WORKFLOW`, while `ast.WorkflowEndNode` and `buildEndWorkflow` were
+written and never wired. The conflict is real — `workflowBody` is shared by the
+top-level `BEGIN … END WORKFLOW` and every nested `{ … }` — but it only exists at
+the top level, which is the one place an explicit End is never legal (below).
+
+**The read side is broken today, independently of the syntax.** `describe
+workflow` skips every `EndWorkflowActivity`, nested ones included, so a Studio
+Pro workflow whose `Reject` outcome ends the workflow describes as
+`'Reject' { }` — which, re-executed, *falls through*. Measured on both engines.
+This is the "DESCRIBE emits MDL that parses and rebuilds a different document"
+case from `docs-wiki/bug-patterns/capability-gap-as-parse-error.md`, and it is
+why the read side is part of this change rather than a follow-up.
+
+## Measured Platform Rules
+
+Settled before any syntax was designed, by a throwaway spike that placed an
+`EndWorkflowActivity` through the existing `buildEndWorkflow` wherever a script
+marked one, on Mendix 11.13.0, one workflow per placement, verdict = the literal
+`mx check` line. The first ten rows were run on **both** engines with identical
+results; rows 11–13 on the default (modelsdk) engine.
+
+| # | End placed … | mxbuild |
+|---|---|---|
+| 1 | closing a user-task outcome | **0 errors** |
+| 2 | closing a boolean decision branch | **0 errors** |
+| 3 | closing a call-microflow outcome | **0 errors** |
+| 4 | closing an **interrupting** boundary-event path | **0 errors** |
+| 12 | closing a user-task outcome nested inside a decision branch | **0 errors** — any depth |
+| 5 | closing a **non-interrupting** boundary-event path | **CE1844** "A 'End' cannot be used for a 'Non interrupting timer boundary event'" |
+| 6 | inside a parallel-split path | **CE1844** "A 'End' cannot be used for a 'Parallel split'" |
+| 13 | in an outcome nested inside a parallel-split path | **CE1844** — reaches through any depth |
+| 7 | followed by another activity in the same path | **CE6671** "An end activity can only be placed at the end of a path" + **CE6689** on what follows |
+| 10 | in the middle of the main flow | **CE6671** + **CE6689** |
+| 9 | as the last main-flow activity | **CE6671** + **CE6689** — mxcli appends the main End after it |
+| 11 | the only content of a **single-outcome** user task | **CE1876** (already MDL-WF02) + **CE6689** on the main End |
+| 8 | two nested Ends with the default caption | **CE0495** "Duplicate name 'End'" — an mxcli naming defect, not a platform rule |
+
+Read together:
+
+- **Where an End may go:** the last activity of a user-task outcome, a decision
+  branch, a call-microflow outcome or an interrupting boundary-event path, at any
+  nesting depth — **never** under a parallel split (a path cannot end the whole
+  instance while its siblings run; this is Mendix declining BPMN's terminate-end)
+  and never on a non-interrupting boundary path.
+- **The main flow's End is not authorable** — it is the one Mendix requires, and
+  `END WORKFLOW` already *is* it. That is why the closer conflict dissolves.
+- **A path that ends does not continue.** Row 11 shows the consequence for the
+  builder: when every path of the last main-flow activity ends, the End mxcli
+  appends is unreachable (CE6689).
+
+## BSON Structure
+
+No new storage. `Workflows$EndWorkflowActivity` is what both writers already emit
+as the main flow's last activity (`execCreateWorkflow` →
+`serializeEndWorkflow` / `simpleActivityToGen`), and the spike's nested Ends built
+under both engines. No Studio Pro reference with a nested End was available (see
+Open Questions), so per the capability-gap pattern the shape is derived from that
+proven sibling rather than guessed.
+
+| Field | Value written | Notes |
+|---|---|---|
+| `$Type` | `Workflows$EndWorkflowActivity` | |
+| `$ID` | fresh | |
+| `Name` | unique within the workflow | CE0495 otherwise — row 8 |
+| `Caption` | `End`, or the author's caption | shown on the canvas |
+| base activity fields | as for the main End | `appendActivityBaseFields` / `addActivityBaseFields` |
+
+Placement is the only new thing, and the existing path-marker code already
+expects it: `workflows.EndParallelSplitPath` and `EndBoundaryEventPath` do not
+append their end-of-path marker after an `EndWorkflowActivity`
+(`sdk/workflows/workflow.go`).
+
+## Proposed MDL Syntax
+
+One statement, valid inside any `{ … }` body of a workflow:
+
+```sql
+end workflow [comment '<caption>'];
+```
+
+```sql
+create workflow HR.LeaveApproval
+  parameter $Request: HR.LeaveRequest
+begin
+  decision '$WorkflowContext/IsDuplicate'
+    outcomes
+      true  -> { end workflow comment 'Duplicate'; }
+      false -> { };
+
+  user task Review 'Review the request'
+    page HR.ReviewPage
+    outcomes
+      'Approve' { }
+      'Reject' {
+        call microflow HR.ACT_NotifyRejected;
+        end workflow comment 'Rejected';
+      }
+    boundary event interrupting timer 'addDays([%CurrentDateTime%], 5)' {
+      call microflow HR.ACT_Escalate;
+      end workflow comment 'Expired';
+    };
+
+  call microflow HR.ACT_Book;
+end workflow;
+```
+
+Read aloud: *"on Reject, notify, then end workflow."* The same two words close the
+body because they mean the same thing — the main flow's End is `end workflow`;
+a branch's End is `end workflow` said early.
+
+- **`comment` is the caption**, exactly as on `jump to`, `decision` and the call
+  activities. Omitted → `End`.
+- **No name slot.** Every other activity takes one because `jump to` resolves by
+  name (ako/mxcli#408); an End is never a jump target (CE6681, and MDL-WF05's
+  `collectJumpableNames` already excludes it). A unique name is generated.
+- **ALTER needs nothing new.** Every insert that takes a body takes the statement:
+  `alter workflow HR.LeaveApproval insert outcome 'Withdraw' on Review { end workflow; };`
+
+### What `describe workflow` emits
+
+- A nested `EndWorkflowActivity` → `end workflow;`, with `comment '<caption>'`
+  when the caption is not `End`.
+- The main flow's final End and the two end-of-path markers stay implicit, as
+  today.
+
+### Refusals
+
+Illegal placements parse and are refused by check rules, not by the grammar — a
+platform rule reported as a parse error reads as "not implemented", which is the
+failure the capability-gap pattern documents. All three are no-project rules in
+`ValidateWorkflow`, so plain `mxcli check` catches them, and `exec` refuses a
+script they flag.
+
+| Rule | Refuses | Predicts |
+|---|---|---|
+| **MDL-WF08** | `end workflow` anywhere under a `parallel split`, or under a `non interrupting` boundary-event path — at any depth (measured for both) | CE1844 |
+| **MDL-WF09** | a statement after `end workflow` in the same block | CE6671 + CE6689 |
+| **MDL-WF10** | an activity whose every path ends — in `end workflow` or `jump to`, also through a nested decision — followed by anything, or last in the main flow; and a main flow ending in a direct `jump to` | CE6689 (+ CE6679 for the direct jump) |
+| **MDL-WF11** | `return;` in a workflow body | — (exec refuses too: nothing is built from it) |
+
+A single-outcome user task whose outcome holds only `end workflow` is CE1876 and
+CE6689 at once; it is reported once, as MDL-WF02, with advice that fits an End.
+ALTER: what the statement shows (an inserted path, an inserted non-interrupting
+boundary) is checked without a project; a target that already sits under a split
+or a non-interrupting boundary is found in the stored workflow by `check
+--references` and exec.
+
+Sample message (MDL-WF08):
+
+```
+✗ end workflow inside a parallel split path — a path cannot end the workflow
+  while the other paths run; the build fails CE1844 [MDL-WF08]
+  → end the workflow after the split, or leave the path with `jump to`
+```
+
+The one spelling that stays a parse error is `end workflow;` in the middle of the
+top-level body: there it is the closer, and Mendix refuses the placement anyway
+(row 10).
+
+### Rejected alternatives
+
+- **`return;`** — `end workflow` *is* the workflow counterpart of a microflow's
+  `return`: both are the End event of their flow, placed early in a branch, and
+  both must be last on their path. It still reads wrong where it matters: inside a
+  `{ }` block, `'Reject' { return; }` reads as "leave this block and rejoin the
+  main flow" — exactly the silent fallthrough this feature exists to prevent — and
+  a workflow End carries no value and, at the top level, has no caller. So the
+  analogy is documented rather than spelled, and `return;` in a workflow body
+  parses only so MDL-WF11 can point at `end workflow;` (it is the spelling a
+  microflow author, and an LLM, reaches for), with exec refusing it rather than
+  dropping it.
+- **`end;`** — "end of what" is unclear, it sits one token from the closer, and it
+  reads as a microflow block's `end`.
+- **`terminate workflow;`** — promises BPMN's terminate-end, which also stops
+  parallel siblings; Mendix refuses exactly that (CE1844, rows 6 and 13).
+- **`abort workflow`** — already means the microflow action that leaves an
+  instance **Aborted**; an End leaves it **Completed**.
+- **Grammar-enforced placement** (End only as the last statement of an outcome,
+  branch or interrupting boundary body) — simpler, but turns three platform rules
+  into `extraneous input` errors.
+
+## Implementation Plan
+
+1. **Grammar.** Add `workflowEndStmt : END WORKFLOW (COMMENT STRING_LITERAL)?` as
+   an alternative of the brace body only: `workflowBody` gains it, and the
+   top-level `BEGIN … END WORKFLOW` switches to a new `workflowMainBody :
+   workflowActivityStmt*`. That keeps every `ctx.WorkflowBody()` accessor for the
+   nine brace bodies and moves exactly one call site. `make grammar` must report
+   no ambiguity.
+2. **Visitor.** Build `ast.WorkflowEndNode{Caption}`; the top-level rule calls the
+   same body builder.
+3. **Builder naming.** Seed de-duplication with the main End's name before
+   `deduplicateActivityNames` runs over user activities, so a nested End is never
+   named `End` (row 8). The ALTER path's `wfnames.Dedup` already starts from
+   every stored name.
+4. **Describer.** Emit nested Ends; keep skipping the main End and path markers.
+   Round-trip test against a document built with nested Ends.
+5. **Check rules.** MDL-WF08/09/10 on a walker that carries *inside parallel
+   split* / *non-interrupting boundary path* context (`walkWorkflowActivities`
+   does not). MDL-WF02's suggestion ("move the activities to the main flow") is
+   wrong advice when the single outcome holds only `end workflow` — reword it for
+   that case. ALTER: `insert path` bodies and non-interrupting `insert boundary
+   event` bodies are refused by construction; `insert after` / `replace` into an
+   existing path resolve their target's ancestry from the stored workflow.
+6. **Docs.** `mxcli syntax workflow end` topic, the `write-workflows` skill, the
+   quick reference, and a note in `workflow.jump-to` that an End is not a target.
+
+### Files to modify/create
+
+| File | Change |
+|------|--------|
+| `mdl/grammar/domains/MDLWorkflow.g4` | `workflowEndStmt`; `workflowMainBody` for the top-level body |
+| `mdl/visitor/visitor_workflow.go` | build `WorkflowEndNode`; top-level body call site |
+| `mdl/ast/ast_workflow.go` | none — `WorkflowEndNode{Caption}` exists |
+| `mdl/executor/cmd_workflows_write.go` | seed name de-duplication with the main End |
+| `mdl/executor/cmd_workflows.go` | describe nested Ends |
+| `mdl/executor/validate_workflow_end.go` (new) | MDL-WF08/09/10 + context walker |
+| `mdl/executor/validate_workflow.go` | wire the rules; MDL-WF02 wording |
+| `mdl/executor/validate_workflow_refs.go` | ALTER insert placement |
+| `cmd/mxcli/syntax/features_workflow.go` | `workflow.end` topic |
+| `.claude/skills/mendix/write-workflows/SKILL.md`, `docs/01-project/MDL_QUICK_REFERENCE.md` | syntax and rules |
+| `mdl-examples/doctype-tests/24-workflow-examples.mdl` | End in each legal position, CREATE and ALTER |
+| `mdl-examples/bug-tests/workflow-end-*.mdl` | positive fixture + `.fail.mdl` per rule |
+
+No backend interface change: both engines already serialize the type.
+
+## Version Compatibility
+
+`Workflows$EndWorkflowActivity` has existed since workflows did (9.0), and mxcli
+writes it on every version today, so **the statement needs no version gate**.
+
+The **placement rules are measured on 11.13 only**, and they are **not
+version-gated** — a change from the draft, which proposed gating them like
+MDL-WF07. They run in the no-project check, where there is no project version to
+gate on, and that is where they are worth most: the fault they catch is the one a
+team reported plain `mxcli check` missing. They are graph-shape rules (where an
+End may sit, what can be reached) rather than a feature a later Mendix introduced,
+so a 9/10 difference is unlikely — but it is unmeasured, and a rule that is wrong
+for a version is a false refusal there.
+
+## Test Plan
+
+- **Parser:** `end workflow` with and without `comment` in every brace body; a
+  top-level mid-flow `end workflow;` stays a parse error; the closer still parses
+  with `;`, `/`, and neither.
+- **Builder:** two nested Ends plus the main End get three distinct names — the
+  control is row 8's CE0495.
+- **Rules:** each of MDL-WF08/09/10 with a stub control, and clean cases for
+  every legal row (1–4, 12), including deep nesting.
+- **Describe round-trip:** describe → exec → describe is stable for a workflow
+  with nested Ends; the pre-fix describer's `'Reject' { }` is the control.
+- **Doctype gate:** `TestMxCheck_DoctypeScripts` at 0 errors on both engines.
+- **Runtime** (`.claude/skills/verify-in-runtime.md`): the fault being fixed is a
+  runtime one, so boot the fixture under `run --local`, complete a task with its
+  ending outcome, and assert the instance is **Completed** and that no task of
+  a later activity was created. The pre-change fallthrough (empty outcome) is the
+  control.
+
+## Open Questions
+
+1. **Studio Pro's naming of nested Ends.** No Studio Pro reference was available;
+   its activities are named by type and ordinal (`decision1`, `callMicroflow1`),
+   so nested Ends are plausibly `end1`, `end2`. The name carries no references
+   (an End is not a jump target), so only describe/exec *identity* depends on it:
+   a re-executed workflow may rename its Ends. Settle with any Studio Pro
+   workflow that has one.
+2. **Runtime semantics are inferred, not measured.** An End in a branch is
+   expected to complete the instance; the runtime test above confirms it.
+3. ~~MDL-WF10 for two all-ending outcomes~~ — **settled** before shipping:
+   measured CE6689 for two outcomes that both End, a decision whose branches both
+   End, outcomes that all jump, End + jump, termination through a nested decision,
+   and the main flow's own End when such an activity is last. The same round
+   measured End nested under an interrupting boundary (clean) and a
+   non-interrupting one (CE1844), and a main flow ending in a direct jump
+   (CE6679 + CE6689).
+4. **Mendix 9/10 placement rules** are unmeasured (see Version Compatibility).
+5. **MCP backend.** `mdl/backend/mcp/workflow.go` strips a trailing End; whether a
+   nested End maps through Studio Pro's PED unchanged is unverified. Refuse there
+   until checked, per ADR-0004's refuse-don't-drop.
+6. **`comment` is the caption, and the keyword says otherwise.** Across every
+   workflow activity `comment '…'` writes `Caption` — model data shown on the
+   canvas, and for user tasks demonstrably visible at runtime
+   (`WorkflowUserTask.Name` holds the caption) — while it reads like a code
+   comment, and `describe` emits a derivable caption as a real `-- …` comment.
+   `end workflow` follows its siblings rather than introduce a second spelling;
+   renaming the keyword to `caption` across all workflow activities (with
+   `comment` as a deprecated alias) is a separate change.
+7. **Whether an End's caption reaches runtime data** is unmeasured. The runtime
+   records End executions (activity type `end`, event `EndEventExecuted`); the
+   runtime test should check whether the caption travels with them.
+8. **Out of scope:** boundary events on notifications (not in the grammar), event
+   sub-processes, and a user task's On-created handler — the briefing's other
+   hand-add rows.

From 598dddc036a9ec1655df69cf5ba4fb40a299d8a5 Mon Sep 17 00:00:00 2001
From: Ako <andrej@koelewijn.net>
Date: Mon, 14 Sep 2026 17:40:01 +0000
Subject: [PATCH 5/9] feat(workflow): end a workflow from inside a branch with
 `end workflow`
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

`end workflow [comment '<caption>'];` is legal in any `{ }` block of a workflow
and ends the whole workflow — the counterpart of a microflow's `return`, which
in a workflow body is refused with a pointer to it (MDL-WF11) and refused by
exec rather than dropped, since a dropped `return` falls through.

The first workflow grammar dropped the statement for colliding with the
closing END WORKFLOW. The collision only exists at the top level, the one
place Mendix refuses an explicit End, so the top-level body is its own rule
(workflowMainBody) and brace bodies are walked in child order.

Placement rules, each an mxbuild 11.13.0 measurement with the real syntax,
all checked without a project:
  under a parallel split or a non-interrupting boundary, any depth  CE1844  MDL-WF08
  anything after it in its block                                    CE6671  MDL-WF09
  every path of an activity ends (End or jump, also via a nested
  decision) with more after it or as the main flow's last activity,
  and a main flow ending in a direct jump                           CE6689  MDL-WF10
Clean: the last statement of an outcome, decision branch, call-microflow
outcome or interrupting boundary path, at any depth. ALTER inserts get the
same rules, plus the stored workflow's ancestry for their target.

Also fixed on the way, each caught by a measurement:
- describe skipped every End as implicit; only the main flow's is. A nested
  End now describes as `end workflow`, and describe -> exec -> describe is
  stable.
- create or modify refuses a rewrite that deletes stored nested Ends it does
  not restate (guard-don't-drop), so an older describe output cannot drop them.
- a nested End named "End" collided with the main flow's (CE0495); the
  implicit Start/End names are reserved.
- an End's name was its caption, and a caption with a space built CE7247; the
  name is now a fixed base name.
- two fixtures that claimed to be valid workflows ended their main flow in
  `jump to` (CE6679 + CE6689, measured); their jumps now sit in outcomes.

Verified: tests written first and failing; nine controls, one stub each,
fail exactly their cases; the positive fixture execs and builds at 0 new
errors, describe round-trips identically, and a rewrite without its Ends is
refused with nothing written; doctype mx check on both engines.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 .../fix-issue/findings/mdl-executor.jsonl     |   1 +
 .../skills/mendix/write-workflows/SKILL.md    |  30 +-
 CHANGELOG.md                                  |   6 +
 cmd/mxcli/syntax/features_workflow.go         |  38 +-
 docs/01-project/MDL_QUICK_REFERENCE.md        |  11 +-
 .../bug11-workflow-describe-roundtrip.mdl     |  17 +-
 .../bug-tests/workflow-end-activity.mdl       | 101 +++++
 .../workflow-end-every-path-ends.fail.mdl     |  20 +
 .../workflow-end-in-parallel-split.fail.mdl   |  22 +
 .../bug-tests/workflow-end-not-last.fail.mdl  |  19 +
 .../workflow-return-in-workflow.fail.mdl      |  18 +
 .../doctype-tests/24-workflow-examples.mdl    |  43 ++
 mdl/ast/ast_workflow.go                       |  12 +-
 mdl/executor/cmd_alter_workflow.go            |   3 +
 mdl/executor/cmd_workflows.go                 |  29 +-
 mdl/executor/cmd_workflows_describe_test.go   |  28 ++
 mdl/executor/cmd_workflows_write.go           |  27 +-
 .../issue1007_annotation_emit_test.go         |  16 +-
 mdl/executor/validate_workflow.go             |  26 +-
 mdl/executor/validate_workflow_end.go         | 406 ++++++++++++++++++
 mdl/executor/validate_workflow_end_test.go    | 306 +++++++++++++
 mdl/executor/validate_workflow_refs.go        |   3 +
 mdl/executor/validate_workflow_rewrite.go     |  55 +++
 .../validate_workflow_rewrite_test.go         |  73 ++++
 mdl/grammar/domains/MDLWorkflow.g4            |  35 +-
 mdl/visitor/visitor_workflow.go               |  51 ++-
 mdl/visitor/visitor_workflow_test.go          |  96 +++++
 27 files changed, 1466 insertions(+), 26 deletions(-)
 create mode 100644 mdl-examples/bug-tests/workflow-end-activity.mdl
 create mode 100644 mdl-examples/bug-tests/workflow-end-every-path-ends.fail.mdl
 create mode 100644 mdl-examples/bug-tests/workflow-end-in-parallel-split.fail.mdl
 create mode 100644 mdl-examples/bug-tests/workflow-end-not-last.fail.mdl
 create mode 100644 mdl-examples/bug-tests/workflow-return-in-workflow.fail.mdl
 create mode 100644 mdl/executor/validate_workflow_end.go
 create mode 100644 mdl/executor/validate_workflow_end_test.go

diff --git a/.claude/skills/fix-issue/findings/mdl-executor.jsonl b/.claude/skills/fix-issue/findings/mdl-executor.jsonl
index d490dadc9..d3b709b4d 100644
--- a/.claude/skills/fix-issue/findings/mdl-executor.jsonl
+++ b/.claude/skills/fix-issue/findings/mdl-executor.jsonl
@@ -613,3 +613,4 @@
 {"area":"mdl-executor","date":"2026-09-14","symptom":"DESCRIBE flattens a microflow whose branches cross into nested ifs that mean something else, and warns MDL-FLOW01 'must not be re-executed' instead of describing it","cause":"Nested if/then/else is single-entry/single-exit. A merge reached by branches of two different splits has no place in a tree, so the describer walked past it and emitted the conjunction along one path.","file":"mdl/executor/cmd_microflows_show_crossed.go","fix":"Mode 2: label the shared-suffix entry AND the split's post-dominator, emit `join <label>` at every branch end, then declare each merge as a top-level section after the traversal. MDL-FLOW01 is retired per decision when the description actually declared the merge.","insight":"Three traps, each of which produced plausible-looking output. (1) A crossed merge must be emitted the OPPOSITE way from an error-rejoin merge -- rejoin is DECLARED where the traversal meets it, crossed is JOINED by each branch and declared once afterwards -- so the label alone cannot drive emission; carry a crossed set beside the names. (2) Emit the join BEFORE the visited guard: arriving twice is what 'crossed' MEANS, and the guard silently swallows the second branch's join, leaving that path falling off the end. (3) Retire a warning on what was EMITTED, not on what was labelled. An inheritance split has its own traversal that walks through a labelled merge without emitting a join, so the label goes unused and the reader still gets the nested rendering -- suppressing on the label alone silenced MDL-FLOW01 on Administration.ManageMyAccount, whose description is byte-identical with and without the feature. That forced warnings to be computed AFTER the body instead of before it. Method: keep a baseline binary (git stash -u; build) and diff `describe` over every microflow in a corpus -- the refactor step should be byte-identical (it was, 18 of 18) and the feature step should change only the microflows it targets (2 of 18). Anything else changing is the bug."}
 {"area": "mdl/executor", "date": "2026-09-13", "symptom": "describe page -> create or replace page broke a button's icon. An icon into an IMAGE collection came back as `Icon: 'DesignSystem.Icons_SVG.edit'` and the build failed [CE1613] \"The selected custom icon 'DesignSystem.Icons_SVG.edit' no longer exists.\" A GLYPH icon produced no describe output at all -- no clause, no comment -- and replay DELETED it at exit 0.", "cause": "Mendix stores three icon elements and two put a qualified name under the same BSON key: Forms$IconCollectionIcon{Image}->CustomIcons$CustomIcon, Forms$ImageIcon{Image}->Images$Image, Forms$GlyphIcon{Code}. extractIconRef read `Image` off whichever element was there and threw the $Type away, and the page builder writes Forms$IconCollectionIcon unconditionally -- so the two named variants were spelled identically on the way out and collapsed into one on the way back in.", "file": "mdl/executor/cmd_pages_describe_output.go (extractButtonIcon, widgetIconMDL, widgetIconNote), mdl/executor/cmd_pages_describe.go (rawWidget.IconType/IconCode), mdl/executor/cmd_pages_describe_parse.go; tests mdl/executor/cmd_pages_describe_icon_test.go", "insight": "The identical three-variant defect was fixed in NAVIGATION eight days earlier (2026-09-05, same area file) and the page path never received it -- so the cheapest possible diagnosis was `grep MenuIconKindOf`, and the fix reuses that resolver rather than adding a second one. **Generalisable: when a fix teaches a layer to distinguish polymorphic variants, grep for every OTHER reader of the same element.** The find was one `git grep Forms\\$ImageIcon` away all along. Two things the report got understandably wrong and that the fix depends on getting right: it is not about third-party vs native collections (a third-party ICON collection round-trips fine -- and CE1613 naming the reference is itself proof the name was never a custom icon, since mxbuild would otherwise have resolved it), and the reported image-icon case is the CHEAPER half -- the glyph case is silent on both sides, so nothing in the output even hints at the loss. **Measure the silence, not the wrong answer**: `grep -c icon` over describe output of a stock marketplace project's FeedbackModule pages returned 0 before and 3 after, which is the only form the glyph bug has. The note has to fire on an UNRECOGNISED $Type too, not a known-bad list, or the next variant Mendix adds is dropped the same way. Controls that matter: an icon-collection icon must still emit a bare `Icon:` and NO note (else the fix passes by flagging everything), and an iconless button must emit neither. No .mdl repro is possible -- mxcli cannot author an image or glyph icon on a button, so the input to the round trip cannot be constructed in MDL; the reproduction is a stored-widget map in the unit test. Also observed in passing and NOT fixed: a nameless `statictext` makes describe output unparseable (pre-existing, confirmed against the base binary), and NavigationList item / DropDownButton icons are never read at all, so they are dropped as silently as the glyph was.", "refs": ["#1059", "#1008", "#602"], "ce": ["CE1613"]}
 {"area": "mdl/executor", "date": "2026-09-13", "symptom": "Follow-on to #1059: a widget's image and glyph icons were readable but unwritable, so describe -> exec could only be made honest (a `-- NOT re-executable` note), not lossless. Authoring them needed the kind to reach the element $Type through grammar, AST, visitor, builder and BOTH engines.", "cause": "Three separate vocabularies for the same three Mendix icon elements: types.MenuIconKind (navigation), pages.IconType (the page model's own three-value enum), and a bare string in the widget property map. The page path had no kind at all, so it could not express one.", "file": "mdl/grammar/domains/MDLPage.g4 (widgetIconV3), mdl/ast/ast_page_v3.go (WidgetIcon), mdl/visitor/visitor_page_v3.go (buildWidgetIconV3), mdl/executor/cmd_pages_builder_v3_widgets.go (buildWidgetIcon), mdl/backend/modelsdk/widget_write.go (iconToGen), sdk/mpr/writer_widgets_display.go (buildWidgetIconBson), mdl/executor/validate_icon_refs.go, mdl/executor/validate_glyph_codes.go", "insight": "**Delete the second vocabulary as part of the fix, not after it.** pages.IconType existed for exactly the same three kinds as types.MenuIconKind and had drifted to a different value set; replacing it (2 call sites) is what made the writers a dispatch rather than an inference. A feature that adds a third copy would have re-created the bug in a new place. **The pre-existing tests of the OLD feature are the safety net for the new one**: MDL078's menu tests caught a python replace of mine that silently no-opped (anchor did not match, no assert), which nothing else would have. Always assert on the replacement count when editing by script. **Measure the premise, don't reason by analogy** — extending MDL078 to widget glyphs assumed mxbuild resolves a widget glyph the same way it resolves a menu one. It does, measured: `Icon: glyph 57562` fails `mxbuild --target=deploy` with `System.InvalidOperationException: Sequence contains no matching element` — but it names the **page**, not a layout, so the rule's own message was wrong and had to be corrected from the measurement. **The reference check had the mirror-image bug waiting**: resolving an image reference against the ICON collections reports a correct name as a typo, which is the same conflation pointed the other way — per-kind resolution plus an `otherKindHint` naming the remedy. **An empty listing is 'could not establish', not 'none'** — each half of the index is independent, so a project that yields icon collections but no image collections still resolves what it can. Verified on 11.13.0: all three authored, mx check 0 errors, deploy BUILD SUCCEEDED, right $Type on disk; controls reproduce CE1613 (image written without `image`) and the glyph build failure. Corpus sweep 531 clean.", "refs": ["#1059", "#1008", "#602"], "ce": ["CE1613"]}
+{"area": "mdl/executor", "date": "2026-09-15", "symptom": "`describe workflow` of a workflow whose branch ends the workflow (Studio Pro: an End at the end of a user-task outcome) printed `'Reject' { }`. Re-executed, the branch fell through into the main flow — every later task was created for a request already rejected — with check, exec and mx check all clean. MDL also had no statement to write such an End, so authored workflows had the same fallthrough.", "cause": "formatWorkflowActivities skipped every EndWorkflowActivity as 'implicit', but only the main flow's End is implicit; the function is shared by the top level and every nested flow. On the write side, the first workflow grammar dropped `workflowEndStmt` for colliding with the closing END WORKFLOW, leaving ast.WorkflowEndNode and buildEndWorkflow unwired.", "fix": "Top-level body split into workflowMainBody (no End statement) and workflowBody for brace blocks (accepts `end workflow [comment '...']`, walked in child order); describer skips only the main flow's End; builder reserves the implicit Start/End names; MDL-WF08..11 (validate_workflow_end.go) predict CE1844/CE6671/CE6689/`return`; checkNoDroppedWorkflowConstructs refuses a rewrite that deletes stored nested Ends. An End's Name is a fixed base 'End' (de-duplicated), never its caption.", "file": "mdl/executor/cmd_workflows.go", "insight": "A shared formatter with a skip meant for one call site is a silent data-loss bug on every other call site — and the output still parsed, so round-trip tests that only re-parse cannot see it; the defect is semantic (fallthrough), visible only in the rebuilt graph or at runtime. Three measurement lessons: (1) a spike that swaps a placeholder `call microflow END_<caption>` for an AST node measured every placement before any grammar existed, with the caption doubling as attribution in mxbuild's messages; (2) the reachability rule needed rows a reading of CE6689 would not suggest — jumps terminate a path as surely as an End, termination reaches through a nested decision, and a main flow ending in a direct jump is CE6679 as well; (3) a test fixture called 'a valid workflow' (a main flow ending in `jump to`) was the second time a new rule proved that fixture invalid — measure the fixture, not the rule, before weakening either. (4) Deriving an activity Name from its caption, the pattern every other builder uses, was wrong for an End: `end workflow comment 'Rejected by manager'` built CE7247 'The name ... is not valid'. The end-to-end fixture passed because every caption in it was one word; the doctype script's spaced caption is what caught it. An End is never referenced by name, so a fixed base name removes the whole class instead of sanitising it — and a fixture's captions should include a space whenever a name may be derived from one."}
diff --git a/.claude/skills/mendix/write-workflows/SKILL.md b/.claude/skills/mendix/write-workflows/SKILL.md
index df0ec11db..609bcc01b 100644
--- a/.claude/skills/mendix/write-workflows/SKILL.md
+++ b/.claude/skills/mendix/write-workflows/SKILL.md
@@ -111,8 +111,15 @@ begin
   -- Wait for an external notification (e.g. an event)
   wait for notification waitForNotification1;
 
-  -- Jump back to an earlier activity by name (a loop)
-  jump to Review;
+  -- Loop back, or stop the whole workflow, from inside an outcome. A `jump to`
+  -- and an `end workflow` must each END their path, so neither can close the
+  -- main flow itself (CE6679 / CE6671).
+  user task Confirm 'Confirm the booking'
+    page Module.ReviewPage
+    outcomes
+      'Redo'   { jump to Review; }
+      'Cancel' { end workflow comment 'Cancelled'; }
+      'Done'   { };
 
   -- Call a sub-workflow
   call workflow Module.SubProcess as callWorkflow1 comment 'delegate';
@@ -315,6 +322,25 @@ documented in `system-module`.
 
 ## Platform rules
 
+- **`end workflow` ends the whole workflow from inside a branch** — the workflow
+  counterpart of a microflow's `return`. `return;` itself is refused in a workflow
+  (`MDL-WF11`): inside a `{ }` block it reads as "leave this block", which is
+  exactly the fallthrough `end workflow` prevents. Measured placement rules
+  (mxbuild 11.13, both engines), all checked without a project:
+  - legal as the **last** statement of a user-task outcome, a decision branch, a
+    call-microflow outcome or an **interrupting** boundary-event path, at any depth;
+  - refused under a **parallel split** or a **non-interrupting** boundary-event
+    path, at any depth — `CE1844`, `MDL-WF08` (a path cannot end the workflow
+    while the others run; jumping out of a path is refused too, `CE6682`);
+  - refused with anything after it in its block — `CE6671`, `MDL-WF09`;
+  - when **every** path of an activity ends — in `end workflow` or `jump to`,
+    also through a nested decision — nothing may follow it, not even the end of
+    the main flow: `CE6689`, `MDL-WF10`. Let one path continue; a path that
+    reaches the end of the workflow needs no `end workflow`.
+  - The main flow needs none: the body's closing `end workflow` is its End.
+  An outcome left **empty** does not stop anything — it rejoins the main flow.
+  `comment '…'` sets the End's caption, as on every workflow activity.
+
 - A user task needs a **task page** to be useful; without one Mendix flags the
   task (`CE1834`). Bind the page to `System.WorkflowUserTask`.
 - A user task / decision with a single outcome and no activity can trip
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 7464617a8..189697eec 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -8,6 +8,10 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ### Added
 
+- **`end workflow` — end a workflow from inside a branch** (docs/11-proposals/PROPOSAL_workflow_end_activity.md) — the one structural gap a team building native workflows from MDL reported after four projects: a user-task outcome, a decision branch or a boundary-event path could continue or jump, but not stop the process, so "Reject ends the workflow" was rebuilt as a backward jump or hand-added in Studio Pro after every scripted rewrite. `end workflow [comment '<caption>'];` is now legal in any `{ }` block and ends the whole workflow — the workflow counterpart of a microflow's `return`, which in a workflow body is refused with a pointer to it (MDL-WF11). The first workflow grammar had dropped the statement for colliding with the closing `END WORKFLOW`; the collision only exists at the top level, which is the one place Mendix refuses an explicit End, so the top-level body is now its own rule.
+
+  Where it may go was measured before any syntax was designed, one workflow per placement on mxbuild 11.13.0, both engines: legal as the last statement of an outcome, a decision branch, a call-microflow outcome or an **interrupting** boundary path, at any depth. Refused at check time, because a platform rule reported as a parse error reads as "not implemented": under a parallel split or a **non-interrupting** boundary path, at any depth (CE1844, MDL-WF08); followed by anything in its block (CE6671, MDL-WF09); and when every path of an activity ends — in an End or a jump, also through a nested decision — with anything after it or as the main flow's last activity (CE6689, MDL-WF10), which also covers a main flow ending in a direct `jump to` (CE6679 + CE6689). All four run without a project; ALTER inserts are checked too, including a target that already sits under a split in the stored workflow. The End's name is generated and reserved against the main flow's own End, which the measurement caught as CE0495.
+
 - **`CATALOG.GRAPH_MODULE_CYCLES` — the modules that depend on each other** (mendixlabs/mxcli#1060), plus a `module_cycles()` Starlark builtin for enforcing a no-circular-modules policy. Not a rollup of `GRAPH_CYCLES`: modules reference each other through documents that need form no cycle themselves, which is the ordinary shape and why the document-level table is legitimately empty for a genuinely tangled pair. Computed over **every** reference kind, matching `GRAPH_MODULE_COUPLING` — the table it is read beside — rather than the structural subset the clustering uses; on a blank Mendix app `Administration → Atlas_Core` is a `layout` edge and nothing else, so a module-cycle table on the structural subset would answer "none" for exactly the pair that gets reported. Each row carries `RefKinds`: the kinds on that module's edges **into the rest of the cycle**, not everything it points at.
 
 - **`CATALOG.GRAPH_ANALYSIS_SCOPE` — which reference kinds reach the computed graph.** The two graph families disagree by construction and there was no way to see it from SQL: `GRAPH_MODULE_COUPLING` and friends read every kind straight off `refs`, while the computed pass (communities, cycles, layers, centrality) is restricted to the structural kinds. On a stock 11.14 app that is 110 of 316 edges. One row per kind with its edge count and whether it is in the asset graph; the `IN` list is generated from the filter itself, so the view cannot drift from what it describes.
@@ -135,6 +139,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ### Fixed
 
+- **`describe workflow` dropped every End inside a branch** — they were skipped as "implicit" along with the main flow's, so Studio Pro's `Reject -> End` described as `'Reject' { }`, which re-executed **falls through** into the main flow and creates every later task for a request that was rejected. Measured on both engines. A nested End now describes as `end workflow;` (with `comment` when it has a caption), and `create or modify` refuses a rewrite that would delete stored nested Ends it does not restate (guard-don't-drop, ADR-0005), so a script generated from an older describe output cannot silently remove them.
+
 - **An empty graph-analysis table could not be told apart from one that was never computed** (mendixlabs/mxcli#1060). `CATALOG.GRAPH_CYCLES` answered `0 rows` on a project whose `CATALOG.GRAPH_MODULE_COUPLING` listed mutual module pairs, so it read as "no circular dependencies". The two are built by different things: coupling is a plain view over `refs` that any full catalog answers, while the cycles/communities/layers/centrality tables are written only by `REFRESH CATALOG COMMUNITIES` — and those six were in neither `fullOnlyTables` nor `sourceOnlyTables`, so nothing warned.
 
   The mode ladder could not carry the distinction. fast/full/source is a *level*, each containing the one below, which is what lets a rank comparison decide everything; the graph pass is orthogonal, augmenting whichever level is cached. It is now recorded as a flag plus the resolution it ran at. A query against one of the six says `requires refresh catalog communities (not run for this catalog)`; `SHOW CATALOG STATUS` reports `Graph analysis: ✓/✗` separately from the build mode; `DESCRIBE CATALOG.GRAPH_CYCLES` names the command that populates it.
diff --git a/cmd/mxcli/syntax/features_workflow.go b/cmd/mxcli/syntax/features_workflow.go
index a044d8ba4..fd5d3e266 100644
--- a/cmd/mxcli/syntax/features_workflow.go
+++ b/cmd/mxcli/syntax/features_workflow.go
@@ -147,7 +147,43 @@ func init() {
 		Example: "DECISION decision1 '$WorkflowContext/Total > 1000'\n" +
 			"  OUTCOMES\n    true -> { }\n    false -> { };\n\n" +
 			"PARALLEL SPLIT split1\n  PATH 1 { JUMP TO decision1; }\n  PATH 2 { };",
-		SeeAlso: []string{"workflow.create", "workflow.decision", "workflow.parallel-split"},
+		SeeAlso: []string{"workflow.create", "workflow.decision", "workflow.parallel-split", "workflow.end"},
+	})
+
+	Register(SyntaxFeature{
+		Path:    "workflow.end",
+		Summary: "End the workflow from inside a branch — the workflow counterpart of a microflow's return",
+		Keywords: []string{
+			"end workflow", "end event", "end activity", "stop workflow", "terminate",
+			"early exit", "reject ends the workflow", "return",
+		},
+		// Every placement rule below is an mxbuild measurement (11.13.0), not a
+		// reading of the error text. See docs/11-proposals/PROPOSAL_workflow_end_activity.md.
+		Syntax: "end workflow [comment '<caption>'];\n\n" +
+			"-- Legal as the LAST statement of a user-task outcome, a decision branch,\n" +
+			"-- a call-microflow outcome or an interrupting boundary-event path, at any depth.\n" +
+			"-- It ends the WHOLE workflow, not the block it is written in.\n" +
+			"--\n" +
+			"-- Refused:\n" +
+			"--   under a parallel split or a non-interrupting boundary path   CE1844  MDL-WF08\n" +
+			"--   followed by anything in the same block                        CE6671  MDL-WF09\n" +
+			"--   when every path of an activity ends and more follows          CE6689  MDL-WF10\n" +
+			"--   `return;` — a microflow's spelling                            MDL-WF11\n" +
+			"--\n" +
+			"-- The main flow needs none: the body's own closing `end workflow` is its End.\n" +
+			"-- `comment` sets the End's caption on the canvas. An End is not a jump target.",
+		Example: "USER TASK Review 'Review the request'\n" +
+			"  PAGE HR.ReviewPage\n" +
+			"  OUTCOMES\n" +
+			"    'Approve' { }\n" +
+			"    'Reject' {\n" +
+			"      CALL MICROFLOW HR.ACT_NotifyRejected;\n" +
+			"      END WORKFLOW COMMENT 'Rejected';\n" +
+			"    }\n" +
+			"  BOUNDARY EVENT INTERRUPTING TIMER 'addDays([%CurrentDateTime%], 5)' {\n" +
+			"    END WORKFLOW COMMENT 'Expired';\n" +
+			"  };",
+		SeeAlso: []string{"workflow.user-task", "workflow.decision", "workflow.boundary-event", "workflow.jump-to"},
 	})
 
 	Register(SyntaxFeature{
diff --git a/docs/01-project/MDL_QUICK_REFERENCE.md b/docs/01-project/MDL_QUICK_REFERENCE.md
index fa3d8e57d..47cef013c 100644
--- a/docs/01-project/MDL_QUICK_REFERENCE.md
+++ b/docs/01-project/MDL_QUICK_REFERENCE.md
@@ -671,7 +671,16 @@ Nested folders use `/` separator: `'Parent/Child/Grandchild'`. Missing folders a
 - `jump to <activity-name>;`
 - `wait for timer [<name>] ['<expr>'];`
 - `wait for notification [<name>];`
-- `end;`
+- `end workflow [comment '<caption>'];` — only inside a `{ }` block; ends the whole workflow
+
+**Ending a workflow early.** `end workflow` inside an outcome, a decision branch, a
+call-microflow outcome or an interrupting boundary-event path ends the whole
+workflow — the workflow counterpart of a microflow's `return` (which a workflow
+refuses, MDL-WF11). It must be the last statement of its block (MDL-WF09, CE6671),
+is refused under a parallel split or a non-interrupting boundary path (MDL-WF08,
+CE1844), and when every path of an activity ends — in `end workflow` or `jump to` —
+nothing may follow it, including the end of the main flow (MDL-WF10, CE6689). The
+main flow needs none: the body's closing `end workflow` is its End.
 
 **Activity names.** Every activity has a name, and `jump to` resolves against it
 — Mendix stores `JumpToActivity.TargetActivity` as a name string, not a pointer.
diff --git a/mdl-examples/bug-tests/bug11-workflow-describe-roundtrip.mdl b/mdl-examples/bug-tests/bug11-workflow-describe-roundtrip.mdl
index 3408b8dc5..41dcb90b2 100644
--- a/mdl-examples/bug-tests/bug11-workflow-describe-roundtrip.mdl
+++ b/mdl-examples/bug-tests/bug11-workflow-describe-roundtrip.mdl
@@ -44,12 +44,27 @@ begin
 end;
 /
 
+create microflow WF11.ACT_Check ()
+  returns boolean as $Result
+begin
+  return true;
+end;
+/
+
 create or replace workflow WF11.WF_RoundTrip
   parameter $Context: WF11.Request
 begin
   call microflow WF11.ACT_Noop;
   wait for timer 'addHours([%CurrentDateTime%], 1)';
   wait for notification;
-  jump to ACT_Noop;
+  -- The jump sits in an outcome. It used to close the main flow, which this
+  -- fixture's own claim ("a workflow that docker build accepts") did not
+  -- survive: measured on mxbuild 11.13.0, a main flow ending in `jump to` fails
+  -- CE6679 (a jump must end a path — the implicit End follows it) and CE6689
+  -- (that End is unreachable), and MDL-WF10 now reports it at check time.
+  call microflow WF11.ACT_Check
+    outcomes
+      true -> { }
+      false -> { jump to ACT_Noop; };
 end workflow;
 /
diff --git a/mdl-examples/bug-tests/workflow-end-activity.mdl b/mdl-examples/bug-tests/workflow-end-activity.mdl
new file mode 100644
index 000000000..27da19602
--- /dev/null
+++ b/mdl-examples/bug-tests/workflow-end-activity.mdl
@@ -0,0 +1,101 @@
+-- `end workflow` — ending a workflow from inside a branch.
+-- docs/11-proposals/PROPOSAL_workflow_end_activity.md
+--
+-- Symptom: MDL could not end a workflow from a branch, so a workflow whose
+-- "Reject" outcome should stop the process instead fell through into the main
+-- flow, and every later task was created for a request already rejected —
+-- `mxcli check`, `exec` and `mx check` all passed. `describe workflow` had the
+-- same fault on the read side: it skipped every End, so Studio Pro's
+-- `Reject -> End` described as `'Reject' { }`, which re-executed falls through.
+--
+-- A caption with a space is deliberate: the End's name used to be its caption,
+-- and `comment 'Rejected by reviewer'` built CE7247 (an invalid name).
+--
+-- POSITIVE fixture: every shape here builds at 0 errors (mxbuild 11.13.0, both
+-- engines). The refusals — CE1844, CE6671, CE6689, and `return` — each have a
+-- `.fail.mdl` sibling: workflow-end-*.fail.mdl.
+
+create module WFEND;
+
+create persistent entity WFEND.Request (
+  Title: string(200),
+  IsDuplicate: boolean
+);
+/
+
+create page WFEND.TaskPage (
+  title: 'Task',
+  layout: Atlas_Core.Atlas_Default,
+  params: { $WorkflowUserTask: System.WorkflowUserTask }
+) {
+  layoutgrid g1 { row r1 { column c1 (desktopwidth: 12) { dynamictext t1 (content: 'Task') } } }
+}
+/
+
+create microflow WFEND.ACT_Notify ($Request: WFEND.Request)
+begin
+  @position(200,200) return;
+end;
+/
+
+create microflow WFEND.ACT_IsComplete ($Request: WFEND.Request)
+returns Boolean
+begin
+  @position(200,200) return true;
+end;
+/
+
+create workflow WFEND.Approval
+  parameter $Request: WFEND.Request
+begin
+  -- A decision branch that ends the workflow.
+  decision decision1 '$WorkflowContext/IsDuplicate'
+    outcomes
+      true  -> { end workflow comment 'Duplicate'; }
+      false -> { };
+
+  -- A call-microflow outcome that ends it.
+  call microflow WFEND.ACT_IsComplete as callMicroflow1 with (Request = '$WorkflowContext')
+    outcomes
+      true  -> { }
+      false -> { end workflow comment 'Incomplete'; };
+
+  -- An outcome that ends it after an activity, and an interrupting boundary
+  -- event whose path ends it.
+  user task Review 'Review the request'
+    page WFEND.TaskPage
+    outcomes
+      'Approve' { }
+      'Reject' {
+        call microflow WFEND.ACT_Notify as callMicroflow2 with (Request = '$WorkflowContext') outcomes default -> { };
+        end workflow comment 'Rejected by reviewer';
+      }
+    boundary event interrupting timer 'addDays([%CurrentDateTime%], 5)' {
+      end workflow comment 'Expired';
+    };
+
+  -- An End nested at depth: inside an outcome, inside a decision branch.
+  decision decision2 '$WorkflowContext/IsDuplicate'
+    outcomes
+      true -> {
+        user task Confirm 'Confirm the duplicate'
+          page WFEND.TaskPage
+          outcomes
+            'Discard' { end workflow; }
+            'Keep' { };
+      }
+      false -> { };
+
+  user task Book 'Book the request'
+    page WFEND.TaskPage
+    outcomes
+      'Done' { }
+      'Later' { };
+end workflow;
+/
+
+-- ALTER takes the same statement in any inserted block.
+alter workflow WFEND.Approval
+  insert outcome 'Withdraw' on Book {
+    end workflow comment 'Withdrawn';
+  };
diff --git a/mdl-examples/bug-tests/workflow-end-every-path-ends.fail.mdl b/mdl-examples/bug-tests/workflow-end-every-path-ends.fail.mdl
new file mode 100644
index 000000000..862bf08a1
--- /dev/null
+++ b/mdl-examples/bug-tests/workflow-end-every-path-ends.fail.mdl
@@ -0,0 +1,20 @@
+-- NEGATIVE TEST (.fail.mdl) — EXPECTED to fail `mxcli check` with MDL-WF10.
+--
+-- When every path of an activity ends the workflow or jumps away, nothing after
+-- it can run: CE6689 ("cannot be reached because of the activities before
+-- it"). Measured on mxbuild 11.13.0 for outcomes that all End, a decision whose
+-- branches all End, outcomes that all jump, a mix, and termination through a
+-- nested decision — and for the main flow's own End when such an activity is
+-- last.
+
+create persistent entity WFEND.Ctx ( Title: string(50) );
+create page WFEND.TaskPage ( title: 'T', layout: Atlas_Core.Atlas_Default, params: { $WorkflowUserTask: System.WorkflowUserTask } ) { };
+
+create workflow WFEND.EveryPathEnds parameter $Ctx: WFEND.Ctx
+begin
+  user task Review 'Review' page WFEND.TaskPage
+    outcomes
+      'Reject' { end workflow comment 'Rejected'; }
+      'Cancel' { end workflow comment 'Cancelled'; };
+  user task Book 'Book' page WFEND.TaskPage outcomes 'Done' { } 'Later' { };
+end workflow;
diff --git a/mdl-examples/bug-tests/workflow-end-in-parallel-split.fail.mdl b/mdl-examples/bug-tests/workflow-end-in-parallel-split.fail.mdl
new file mode 100644
index 000000000..8e7a92d07
--- /dev/null
+++ b/mdl-examples/bug-tests/workflow-end-in-parallel-split.fail.mdl
@@ -0,0 +1,22 @@
+-- NEGATIVE TEST (.fail.mdl) — EXPECTED to fail `mxcli check` with MDL-WF08.
+--
+-- `end workflow` under a parallel split, at any depth, is CE1844 ("A 'End'
+-- cannot be used for a 'Parallel split'"): one path cannot end the workflow
+-- while the other paths are still running. Measured on mxbuild 11.13.0 both
+-- directly in a path and in an outcome nested inside one.
+
+create persistent entity WFEND.Ctx ( Title: string(50) );
+create page WFEND.TaskPage ( title: 'T', layout: Atlas_Core.Atlas_Default, params: { $WorkflowUserTask: System.WorkflowUserTask } ) { };
+
+create workflow WFEND.EndInSplit parameter $Ctx: WFEND.Ctx
+begin
+  parallel split
+    path 1 {
+      user task Legal 'Legal review' page WFEND.TaskPage
+        outcomes 'Reject' { end workflow; } 'Approve' { };
+    }
+    path 2 {
+      user task Tech 'Technical review' page WFEND.TaskPage
+        outcomes 'Done' { } 'Skip' { };
+    };
+end workflow;
diff --git a/mdl-examples/bug-tests/workflow-end-not-last.fail.mdl b/mdl-examples/bug-tests/workflow-end-not-last.fail.mdl
new file mode 100644
index 000000000..673ef3388
--- /dev/null
+++ b/mdl-examples/bug-tests/workflow-end-not-last.fail.mdl
@@ -0,0 +1,19 @@
+-- NEGATIVE TEST (.fail.mdl) — EXPECTED to fail `mxcli check` with MDL-WF09.
+--
+-- An activity after `end workflow` in the same block can never run: CE6671
+-- ("An end activity can only be placed at the end of a path") plus CE6689 on
+-- what follows. Measured on mxbuild 11.13.0.
+
+create persistent entity WFEND.Ctx ( Title: string(50) );
+create page WFEND.TaskPage ( title: 'T', layout: Atlas_Core.Atlas_Default, params: { $WorkflowUserTask: System.WorkflowUserTask } ) { };
+
+create workflow WFEND.EndNotLast parameter $Ctx: WFEND.Ctx
+begin
+  user task Review 'Review' page WFEND.TaskPage
+    outcomes
+      'Reject' {
+        end workflow;
+        user task Appeal 'Appeal' page WFEND.TaskPage outcomes 'Yes' { } 'No' { };
+      }
+      'Approve' { };
+end workflow;
diff --git a/mdl-examples/bug-tests/workflow-return-in-workflow.fail.mdl b/mdl-examples/bug-tests/workflow-return-in-workflow.fail.mdl
new file mode 100644
index 000000000..b942fd019
--- /dev/null
+++ b/mdl-examples/bug-tests/workflow-return-in-workflow.fail.mdl
@@ -0,0 +1,18 @@
+-- NEGATIVE TEST (.fail.mdl) — EXPECTED to fail `mxcli check` with MDL-WF11.
+--
+-- `return` is how a microflow ends. In a workflow body it builds nothing, so
+-- before MDL-WF11 an author who reached for it (an LLM, reliably) would have got
+-- a branch that silently fell through into the main flow. A workflow ends with
+-- `end workflow;` — which, like a microflow's `return`, ends the whole workflow
+-- rather than the block it is written in.
+
+create persistent entity WFEND.Ctx ( Title: string(50) );
+create page WFEND.TaskPage ( title: 'T', layout: Atlas_Core.Atlas_Default, params: { $WorkflowUserTask: System.WorkflowUserTask } ) { };
+
+create workflow WFEND.ReturnInWorkflow parameter $Ctx: WFEND.Ctx
+begin
+  user task Review 'Review' page WFEND.TaskPage
+    outcomes
+      'Reject' { return; }
+      'Approve' { };
+end workflow;
diff --git a/mdl-examples/doctype-tests/24-workflow-examples.mdl b/mdl-examples/doctype-tests/24-workflow-examples.mdl
index 92691ce7d..387d76d9c 100644
--- a/mdl-examples/doctype-tests/24-workflow-examples.mdl
+++ b/mdl-examples/doctype-tests/24-workflow-examples.mdl
@@ -529,3 +529,46 @@ begin
   wait for notification waitForNotification1;
 end workflow;
 /
+
+
+-- ############################################################################
+-- PART E: END WORKFLOW — ending the workflow from inside a branch
+-- ############################################################################
+--
+-- `end workflow [comment '<caption>'];` is legal as the last statement of a
+-- user-task outcome, a decision branch, a call-microflow outcome or an
+-- interrupting boundary-event path, at any depth. It ends the whole workflow.
+-- The main flow needs none — the body's closing `end workflow` is its End.
+-- See docs/11-proposals/PROPOSAL_workflow_end_activity.md.
+
+create workflow WFTest.EndInBranches
+  parameter $OrderContext: WFTest.OrderContext
+begin
+  decision decision1 '$WorkflowContext/Total > 1000'
+    outcomes
+      true -> {
+        user task ManagerReview 'Manager review'
+          page WFTest.TaskPage
+          outcomes
+            'Reject' { end workflow comment 'Rejected by manager'; }
+            'Approve' { };
+      }
+      false -> { };
+
+  user task FinalCheck 'Final check'
+    page WFTest.TaskPage
+    outcomes
+      'Cancel' { end workflow; }
+      'Confirm' { }
+    boundary event interrupting timer 'addDays([%CurrentDateTime%], 3)' {
+      end workflow comment 'Expired';
+    };
+
+  wait for timer timer1 'addHours([%CurrentDateTime%], 1)';
+end workflow;
+/
+
+alter workflow WFTest.EndInBranches
+  insert outcome 'Withdraw' on FinalCheck {
+    end workflow comment 'Withdrawn';
+  };
diff --git a/mdl/ast/ast_workflow.go b/mdl/ast/ast_workflow.go
index 46843dc62..b0bbb37aa 100644
--- a/mdl/ast/ast_workflow.go
+++ b/mdl/ast/ast_workflow.go
@@ -150,13 +150,23 @@ type WorkflowWaitForNotificationNode struct {
 
 func (n *WorkflowWaitForNotificationNode) workflowActivityNode() {}
 
-// WorkflowEndNode represents an END activity.
+// WorkflowEndNode is `end workflow [comment '<caption>']` inside a branch: it
+// ends the whole workflow there. The main flow's End is not a node — the body's
+// closing `end workflow` is it.
 type WorkflowEndNode struct {
 	Caption string
 }
 
 func (n *WorkflowEndNode) workflowActivityNode() {}
 
+// WorkflowReturnNode is a `return;` written in a workflow body. Nothing is built
+// from it: it exists so MDL-WF11 can tell a microflow author that a workflow ends
+// with `end workflow;`, and so exec can refuse it rather than drop it — dropped,
+// the branch would fall through, the fault `end workflow` exists to prevent.
+type WorkflowReturnNode struct{}
+
+func (n *WorkflowReturnNode) workflowActivityNode() {}
+
 // WorkflowBoundaryEventNode represents a BOUNDARY EVENT clause on a user task.
 // Issue #7
 type WorkflowBoundaryEventNode struct {
diff --git a/mdl/executor/cmd_alter_workflow.go b/mdl/executor/cmd_alter_workflow.go
index c1881b892..97a781654 100644
--- a/mdl/executor/cmd_alter_workflow.go
+++ b/mdl/executor/cmd_alter_workflow.go
@@ -31,6 +31,9 @@ func execAlterWorkflow(ctx *ExecContext, s *ast.AlterWorkflowStmt) error {
 	// Same exec-side guard as CREATE WORKFLOW: ALTER had no reference validation
 	// at all, so an inserted activity could name a microflow that exists nowhere
 	// and still be written (issue #943).
+	if err := refuseWorkflowReturn(alterWorkflowAddedActivities(s)); err != nil {
+		return err
+	}
 	if refErrors := validateAlterWorkflowRefs(ctx, s, nil); len(refErrors) > 0 {
 		return mdlerrors.NewValidationf("workflow '%s' has reference errors:\n  - %s",
 			s.Name.String(), strings.Join(refErrors, "\n  - "))
diff --git a/mdl/executor/cmd_workflows.go b/mdl/executor/cmd_workflows.go
index 72c799a16..5b470c806 100644
--- a/mdl/executor/cmd_workflows.go
+++ b/mdl/executor/cmd_workflows.go
@@ -225,7 +225,7 @@ func describeWorkflowToString(ctx *ExecContext, name ast.QualifiedName) (string,
 	lines = append(lines, "begin")
 	// Activities
 	if targetWf.Flow != nil {
-		actLines := formatWorkflowActivities(targetWf.Flow, "  ")
+		actLines := formatMainFlowActivities(targetWf.Flow, "  ")
 		lines = append(lines, actLines...)
 	}
 
@@ -319,7 +319,19 @@ func formatBoundaryEvents(events []*workflows.BoundaryEvent, indent string) []st
 }
 
 // formatWorkflowActivities generates MDL-like output for workflow activities.
+// formatWorkflowActivities formats a nested flow — an outcome, a branch, a path,
+// a boundary-event path — where an End is an `end workflow` the author wrote.
 func formatWorkflowActivities(flow *workflows.Flow, indent string) []string {
+	return formatFlowActivities(flow, indent, false)
+}
+
+// formatMainFlowActivities formats the top-level flow, whose Start and End are
+// implicit: the body's own `begin` and `end workflow` stand for them.
+func formatMainFlowActivities(flow *workflows.Flow, indent string) []string {
+	return formatFlowActivities(flow, indent, true)
+}
+
+func formatFlowActivities(flow *workflows.Flow, indent string, mainFlow bool) []string {
 	if flow == nil {
 		return nil
 	}
@@ -390,8 +402,19 @@ func formatWorkflowActivities(flow *workflows.Flow, indent string) []string {
 			// Skip start activities - they are implicit
 			continue
 		case *workflows.EndWorkflowActivity:
-			// Skip end activities - they are implicit
-			continue
+			if mainFlow {
+				// The main flow's End is implicit: `end workflow` closes the body.
+				continue
+			}
+			// An End inside a branch ends the workflow early. This used to be
+			// skipped like the main one, which described Studio Pro's
+			// `Reject -> End` as `'Reject' { }` — and that, re-executed, falls
+			// through into the main flow.
+			if a.Caption != "" && a.Caption != "End" {
+				actLines = []string{fmt.Sprintf("%send workflow comment %s", indent, mdlQuoted(a.Caption))}
+			} else {
+				actLines = []string{indent + "end workflow"}
+			}
 		case *workflows.EndOfParallelSplitPathActivity:
 			// Skip - auto-generated by Mendix, implicit in MDL syntax
 			continue
diff --git a/mdl/executor/cmd_workflows_describe_test.go b/mdl/executor/cmd_workflows_describe_test.go
index 6061ec072..27f6d4f1e 100644
--- a/mdl/executor/cmd_workflows_describe_test.go
+++ b/mdl/executor/cmd_workflows_describe_test.go
@@ -298,3 +298,31 @@ func TestContextExprNormalizer_AliasesDeclaredParameterName(t *testing.T) {
 		})
 	}
 }
+
+// A workflow whose branch ends the workflow described as if it did not: every
+// EndWorkflowActivity was skipped as "implicit", nested ones included, so Studio
+// Pro's `Reject -> End` came out as `'Reject' { }` — which, re-executed, falls
+// through into the main flow. Only the main flow's own End is implicit.
+func TestDescribeWorkflow_NestedEndIsEmitted(t *testing.T) {
+	end := func(caption string) *workflows.Flow {
+		e := &workflows.EndWorkflowActivity{}
+		e.Name = "end1"
+		e.Caption = caption
+		return &workflows.Flow{Activities: []workflows.WorkflowActivity{e}}
+	}
+	decision := &workflows.ExclusiveSplitActivity{Expression: "$WorkflowContext/Flag"}
+	decision.Name = "decision1"
+	decision.Caption = "Decision"
+	decision.Outcomes = []workflows.ConditionOutcome{
+		&workflows.BooleanConditionOutcome{Value: true, Flow: end("Rejected")},
+		&workflows.BooleanConditionOutcome{Value: false, Flow: end("End")},
+	}
+
+	out := strings.Join(formatSingleActivity(decision, "  "), "\n")
+	if !strings.Contains(out, "end workflow comment 'Rejected';") {
+		t.Errorf("a captioned nested End must describe as `end workflow comment 'Rejected';`, got:\n%s", out)
+	}
+	if strings.Count(out, "end workflow") != 2 || !strings.Contains(out, "end workflow;") {
+		t.Errorf("a nested End with the default caption must describe as a bare `end workflow;`, got:\n%s", out)
+	}
+}
diff --git a/mdl/executor/cmd_workflows_write.go b/mdl/executor/cmd_workflows_write.go
index 96f2b1827..6896034a8 100644
--- a/mdl/executor/cmd_workflows_write.go
+++ b/mdl/executor/cmd_workflows_write.go
@@ -49,6 +49,13 @@ func execCreateWorkflow(ctx *ExecContext, s *ast.CreateWorkflowStmt) error {
 			s.Name.String(), vs[0].Message, vs[0].Suggestion)
 	}
 
+	// A `return;` builds nothing, so exec would drop it and the branch it ends
+	// would fall through. Refused here for the #833 reason — exec is reachable
+	// without check — as well as at check time (MDL-WF11).
+	if err := refuseWorkflowReturn(s.Activities); err != nil {
+		return err
+	}
+
 	// Refuse a broken reference here as well as at check time. `check
 	// --references` reports these, but exec runs a different pass and wrote the
 	// workflow anyway, so a script that skipped check produced a model the build
@@ -170,7 +177,10 @@ func execCreateWorkflow(ctx *ExecContext, s *ast.CreateWorkflowStmt) error {
 	autoBindWorkflowParameters(ctx, userActivities, s.ParameterVar)
 
 	// Deduplicate activity names to avoid CE0495
-	deduplicateActivityNames(userActivities)
+	// The implicit Start and End take part: an `end workflow` inside a branch is
+	// named after its caption, "End" by default, and colliding with the main
+	// flow's End is CE0495 "Duplicate name 'End'".
+	deduplicateActivityNames(userActivities, startAct.Name, endAct.Name)
 
 	// Compose: start + user activities + end
 	flow.Activities = make([]workflows.WorkflowActivity, 0, len(userActivities)+2)
@@ -622,15 +632,26 @@ func buildEndWorkflow(n *ast.WorkflowEndNode) *workflows.EndWorkflowActivity {
 	if act.Caption == "" {
 		act.Caption = "End"
 	}
-	act.Name = act.Caption
+	// The name is NOT the caption, unlike the other activities. A caption is
+	// free text — `end workflow comment 'Rejected by manager'` named the End
+	// "Rejected by manager", and mxbuild refused it as CE7247 "The name ... is
+	// not valid". An End is never referenced by name (it cannot be a jump
+	// target, CE6681), so a fixed base name, made unique by
+	// deduplicateActivityNames, removes the problem instead of sanitising it.
+	act.Name = "End"
 
 	return act
 }
 
 // deduplicateActivityNames ensures all activity names within a workflow are unique.
 // Mendix Studio Pro requires unique activity names (CE0495).
-func deduplicateActivityNames(activities []workflows.WorkflowActivity) {
+func deduplicateActivityNames(activities []workflows.WorkflowActivity, reserved ...string) {
 	nameCount := make(map[string]int)
+	// Names already held by activities outside this list — the main flow's
+	// implicit Start and End — count as seen, so nothing in the list takes them.
+	for _, name := range reserved {
+		nameCount[name]++
+	}
 	// Two passes, jumps LAST.
 	//
 	// A jump is not a jump target (Mendix refuses that, CE6681), so it has no
diff --git a/mdl/executor/issue1007_annotation_emit_test.go b/mdl/executor/issue1007_annotation_emit_test.go
index b01c8885c..775320dee 100644
--- a/mdl/executor/issue1007_annotation_emit_test.go
+++ b/mdl/executor/issue1007_annotation_emit_test.go
@@ -129,6 +129,12 @@ func TestDescribeWorkflow_MultiLineAnnotationCommentsEveryLine(t *testing.T) {
 // correctly reported the dangling target. Both PRs were green alone and red
 // together, because neither CI run saw the other's change; a fixture that is a
 // VALID workflow is what makes the assertion mean what it says.
+//
+// The same thing happened a second time. The jump sat at the end of the main
+// flow, and MDL-WF10 reported it: measured on mxbuild 11.13.0, a main flow that
+// ends in `jump to` fails CE6679 (a jump must end a path — the implicit End
+// follows it) and CE6689 (that End is unreachable), while the same jump inside
+// an outcome builds clean. So the jump now lives in an outcome.
 func TestDescribeWorkflow_NoAnnotationEmitsNoComment(t *testing.T) {
 	target := &workflows.UserTask{}
 	target.Name = "Review"
@@ -138,7 +144,15 @@ func TestDescribeWorkflow_NoAnnotationEmitsNoComment(t *testing.T) {
 	jump := &workflows.JumpToActivity{TargetActivity: "Review"}
 	jump.Name = "j1"
 
-	src, parseErrs, rules := describeAndValidate(t, target, jump)
+	approve := &workflows.UserTask{Outcomes: []*workflows.UserTaskOutcome{
+		{Name: "Again", Caption: "Again", Value: "Again", Flow: &workflows.Flow{Activities: []workflows.WorkflowActivity{jump}}},
+		{Name: "Done", Caption: "Done", Value: "Done"},
+	}}
+	approve.Name = "Approve"
+	approve.Caption = "Approve"
+	approve.Page = "M.ReviewPage"
+
+	src, parseErrs, rules := describeAndValidate(t, target, approve)
 	if parseErrs != nil {
 		t.Fatalf("parse: %v\n%s", parseErrs, src)
 	}
diff --git a/mdl/executor/validate_workflow.go b/mdl/executor/validate_workflow.go
index 9c7bd09a5..1834886e1 100644
--- a/mdl/executor/validate_workflow.go
+++ b/mdl/executor/validate_workflow.go
@@ -58,6 +58,7 @@ var (
 //   - MDL-WF06: enumeration outcomes with no empty-valued branch (CE6686)
 //   - MDL-WF04: standalone `annotation` in a workflow body (unloadable model)
 //   - MDL-WF05: `jump to` a target that names no activity (see validate_workflow_jump.go)
+//   - MDL-WF08..11: where `end workflow` may go, and `return` (see validate_workflow_end.go)
 func ValidateWorkflow(stmt *ast.CreateWorkflowStmt) []linter.Violation {
 	var out []linter.Violation
 	loc := linter.Location{
@@ -81,12 +82,21 @@ func ValidateWorkflow(stmt *ast.CreateWorkflowStmt) []linter.Violation {
 			}
 			// MDL-WF02 — a single outcome must not carry a nested flow.
 			if len(n.Outcomes) == 1 && len(n.Outcomes[0].Activities) > 0 {
+				msg := fmt.Sprintf("user task %s has a single outcome with nested activities — MxBuild rejects this (CE1876)", label)
+				suggestion := "Move the activities to the workflow's main flow after the user task, or add a second outcome."
+				// "Move them to the main flow" is wrong advice for an End: moved
+				// there it is a parse error, and the workflow ends at its own
+				// `end workflow` anyway.
+				if onlyEnd(n.Outcomes[0].Activities) {
+					msg = fmt.Sprintf("user task %s has a single outcome that holds `end workflow` — a single outcome may not hold activities at all, so MxBuild rejects this (CE1876), and nothing after the task could be reached", label)
+					suggestion = "Add a second outcome that continues, if the task is meant to decide whether the workflow ends; otherwise remove `end workflow;` — the workflow ends at its own `end workflow` after the task."
+				}
 				out = append(out, linter.Violation{
 					RuleID:     "MDL-WF02",
 					Severity:   linter.SeverityError,
 					Location:   loc,
-					Message:    fmt.Sprintf("user task %s has a single outcome with nested activities — MxBuild rejects this (CE1876)", label),
-					Suggestion: "Move the activities to the workflow's main flow after the user task, or add a second outcome.",
+					Message:    msg,
+					Suggestion: suggestion,
 				})
 			}
 		case *ast.WorkflowDecisionNode:
@@ -111,9 +121,19 @@ func ValidateWorkflow(stmt *ast.CreateWorkflowStmt) []linter.Violation {
 		}
 	})
 	out = append(out, ValidateWorkflowJumpTargets(stmt)...)
+	out = append(out, ValidateWorkflowEnds(stmt)...)
 	return out
 }
 
+// onlyEnd reports whether a block holds nothing but `end workflow`.
+func onlyEnd(acts []ast.WorkflowActivityNode) bool {
+	if len(acts) != 1 {
+		return false
+	}
+	_, ok := acts[0].(*ast.WorkflowEndNode)
+	return ok
+}
+
 // checkWorkflowOutcomeNames flags condition-outcome values (decision / call
 // microflow branches) that Mendix cannot load as an EnumerationValueIdentifier
 // (MDL-WF03). See the regex block above for the measurements.
@@ -390,5 +410,5 @@ func ValidateAlterWorkflow(stmt *ast.AlterWorkflowStmt) []linter.Violation {
 			out = append(out, *v)
 		}
 	}
-	return out
+	return append(out, ValidateAlterWorkflowEnds(stmt)...)
 }
diff --git a/mdl/executor/validate_workflow_end.go b/mdl/executor/validate_workflow_end.go
new file mode 100644
index 000000000..56ca6468c
--- /dev/null
+++ b/mdl/executor/validate_workflow_end.go
@@ -0,0 +1,406 @@
+// SPDX-License-Identifier: Apache-2.0
+
+// Ending a workflow from inside a branch — `end workflow` — and `return`, the
+// spelling a microflow author reaches for. See
+// docs/11-proposals/PROPOSAL_workflow_end_activity.md.
+//
+// Every rule here is a placement measured against mxbuild 11.13.0 with the real
+// syntax, one workflow per shape, verdict = the literal `mx check` line:
+//
+//	End closing an outcome / decision branch / call-microflow outcome   0 errors
+//	End closing an interrupting boundary path, at any depth              0 errors
+//	End under a parallel split, at any depth                             CE1844  MDL-WF08
+//	End under a non-interrupting boundary path, at any depth             CE1844  MDL-WF08
+//	an activity after End in the same block                              CE6671  MDL-WF09
+//	every path of an activity ends (End or jump, also via a nested
+//	  decision), then another activity — or the main flow's own End      CE6689  MDL-WF10
+//
+// A single-outcome user task whose outcome holds only `end workflow` is CE1876
+// and CE6689 at once; it is reported once, as MDL-WF02.
+package executor
+
+import (
+	"fmt"
+
+	"github.com/mendixlabs/mxcli/mdl/ast"
+	mdlerrors "github.com/mendixlabs/mxcli/mdl/errors"
+	"github.com/mendixlabs/mxcli/mdl/linter"
+	"github.com/mendixlabs/mxcli/sdk/workflows"
+)
+
+// endBody is one block of activities and where it sits. The End rules are about
+// blocks — what is last in one, what is under a split — which the per-activity
+// walkWorkflowActivities cannot answer.
+type endBody struct {
+	activities           []ast.WorkflowActivityNode
+	mainFlow             bool // the top-level body, followed by the implicit End
+	underSplit           bool // inside a parallel-split path, at any depth
+	underNonInterrupting bool // inside a non-interrupting boundary-event path, at any depth
+}
+
+// collectEndBodies lists b and every block nested in it, carrying the context
+// down: once under a split or a non-interrupting boundary, always under one.
+func collectEndBodies(b endBody, out *[]endBody) {
+	*out = append(*out, b)
+	child := func(acts []ast.WorkflowActivityNode, split, nonInterrupting bool) {
+		collectEndBodies(endBody{
+			activities:           acts,
+			underSplit:           b.underSplit || split,
+			underNonInterrupting: b.underNonInterrupting || nonInterrupting,
+		}, out)
+	}
+	boundary := func(events []ast.WorkflowBoundaryEventNode) {
+		for _, e := range events {
+			child(e.Activities, false, e.EventType == "NonInterruptingTimer")
+		}
+	}
+	for _, a := range b.activities {
+		switch n := a.(type) {
+		case *ast.WorkflowUserTaskNode:
+			for _, o := range n.Outcomes {
+				child(o.Activities, false, false)
+			}
+			boundary(n.BoundaryEvents)
+		case *ast.WorkflowDecisionNode:
+			for _, o := range n.Outcomes {
+				child(o.Activities, false, false)
+			}
+		case *ast.WorkflowCallMicroflowNode:
+			for _, o := range n.Outcomes {
+				child(o.Activities, false, false)
+			}
+			boundary(n.BoundaryEvents)
+		case *ast.WorkflowParallelSplitNode:
+			for _, p := range n.Paths {
+				child(p.Activities, true, false)
+			}
+		case *ast.WorkflowWaitForNotificationNode:
+			boundary(n.BoundaryEvents)
+		}
+	}
+}
+
+// flowEnds reports whether control can never leave the end of a block.
+func flowEnds(acts []ast.WorkflowActivityNode) bool {
+	return len(acts) > 0 && activityEnds(acts[len(acts)-1])
+}
+
+// activityEnds reports whether no path continues past an activity: it is an End
+// or a jump, or it branches and every branch ends. Measured, a jump ends a path
+// as surely as an End, and termination reaches through a nested decision.
+// Boundary events do not count — the task's own outcomes still continue.
+func activityEnds(a ast.WorkflowActivityNode) bool {
+	switch n := a.(type) {
+	case *ast.WorkflowEndNode, *ast.WorkflowJumpToNode:
+		return true
+	case *ast.WorkflowUserTaskNode:
+		// A single outcome may not hold activities at all (CE1876, MDL-WF02);
+		// counting it here reported one mistake twice.
+		if len(n.Outcomes) < 2 {
+			return false
+		}
+		for _, o := range n.Outcomes {
+			if !flowEnds(o.Activities) {
+				return false
+			}
+		}
+		return true
+	case *ast.WorkflowDecisionNode:
+		return conditionOutcomesEnd(n.Outcomes)
+	case *ast.WorkflowCallMicroflowNode:
+		return conditionOutcomesEnd(n.Outcomes)
+	}
+	return false
+}
+
+func conditionOutcomesEnd(outcomes []ast.WorkflowConditionOutcomeNode) bool {
+	if len(outcomes) == 0 {
+		return false
+	}
+	for _, o := range outcomes {
+		if !flowEnds(o.Activities) {
+			return false
+		}
+	}
+	return true
+}
+
+// branchingLabel names an activity that has paths, "" for one that does not.
+func branchingLabel(a ast.WorkflowActivityNode) string {
+	switch n := a.(type) {
+	case *ast.WorkflowUserTaskNode:
+		return "user task " + workflowUserTaskLabel(n)
+	case *ast.WorkflowDecisionNode:
+		return "decision " + workflowDecisionLabel(n)
+	case *ast.WorkflowCallMicroflowNode:
+		return "call microflow " + workflowCallMicroflowLabel(n)
+	}
+	return ""
+}
+
+// ValidateWorkflowEnds applies MDL-WF08..11 to a CREATE WORKFLOW body.
+func ValidateWorkflowEnds(stmt *ast.CreateWorkflowStmt) []linter.Violation {
+	var bodies []endBody
+	collectEndBodies(endBody{activities: stmt.Activities, mainFlow: true}, &bodies)
+	return checkEndBodies(bodies, workflowLocation(stmt.Name))
+}
+
+// ValidateAlterWorkflowEnds applies the same rules to what ALTER WORKFLOW
+// inserts, with the context the statement itself decides: a path body is under
+// a split, a non-interrupting boundary body is what it says. What only the
+// stored workflow knows — the target already sitting under one — is
+// validateAlterWorkflowEndAncestry's.
+func ValidateAlterWorkflowEnds(stmt *ast.AlterWorkflowStmt) []linter.Violation {
+	var bodies []endBody
+	for _, op := range stmt.Operations {
+		switch o := op.(type) {
+		case *ast.InsertAfterOp:
+			collectEndBodies(endBody{activities: []ast.WorkflowActivityNode{o.NewActivity}}, &bodies)
+		case *ast.ReplaceActivityOp:
+			collectEndBodies(endBody{activities: []ast.WorkflowActivityNode{o.NewActivity}}, &bodies)
+		case *ast.InsertOutcomeOp:
+			collectEndBodies(endBody{activities: o.Activities}, &bodies)
+		case *ast.InsertBranchOp:
+			collectEndBodies(endBody{activities: o.Activities}, &bodies)
+		case *ast.InsertPathOp:
+			collectEndBodies(endBody{activities: o.Activities, underSplit: true}, &bodies)
+		case *ast.InsertBoundaryEventOp:
+			collectEndBodies(endBody{activities: o.Activities, underNonInterrupting: o.EventType == "NonInterruptingTimer"}, &bodies)
+		}
+	}
+	return checkEndBodies(bodies, workflowLocation(stmt.Name))
+}
+
+func workflowLocation(name ast.QualifiedName) linter.Location {
+	return linter.Location{Module: name.Module, DocumentType: "workflow", DocumentName: name.Name}
+}
+
+func checkEndBodies(bodies []endBody, loc linter.Location) []linter.Violation {
+	var out []linter.Violation
+	add := func(rule, msg, suggestion string) {
+		out = append(out, linter.Violation{
+			RuleID: rule, Severity: linter.SeverityError, Location: loc, Message: msg, Suggestion: suggestion,
+		})
+	}
+	for _, b := range bodies {
+		for i, a := range b.activities {
+			last := i == len(b.activities)-1
+			switch n := a.(type) {
+			case *ast.WorkflowReturnNode:
+				suggestion := "Write `end workflow;`. Like a microflow's `return` it ends the whole workflow, not the block it is written in."
+				if b.mainFlow {
+					suggestion = "Remove it: the main flow already ends at the body's own `end workflow`."
+				}
+				add("MDL-WF11", "`return` is how a microflow ends — a workflow ends with `end workflow;`", suggestion)
+
+			case *ast.WorkflowEndNode:
+				switch {
+				case b.underSplit:
+					add("MDL-WF08",
+						"`end workflow` inside a parallel split path — one path cannot end the workflow while the other paths are still running; the build fails CE1844",
+						"End the workflow after the split instead, deciding on what the paths recorded. A jump out of a path is refused too (CE6682).")
+				case b.underNonInterrupting:
+					add("MDL-WF08",
+						"`end workflow` inside a non-interrupting boundary event path — that path runs alongside the task instead of replacing it, so it cannot end the workflow; the build fails CE1844",
+						"Make the boundary event `interrupting` if the timeout should end the workflow, or end it from one of the task's outcomes.")
+				}
+				if !last {
+					add("MDL-WF09",
+						"an activity after `end workflow` in the same block can never run — the build fails CE6671 (\"an end activity can only be placed at the end of a path\")",
+						"Put `end workflow;` last in its block, and move what came after it before it.")
+				}
+
+			default:
+				label := branchingLabel(a)
+				if label == "" || !activityEnds(n) {
+					continue
+				}
+				switch {
+				case !last:
+					add("MDL-WF10",
+						fmt.Sprintf("every path of %s ends the workflow or jumps away, so the activities after it can never run — the build fails CE6689", label),
+						"Let at least one path continue (a block without `end workflow` or `jump to` carries on after the activity), or remove what follows.")
+				case b.mainFlow:
+					add("MDL-WF10",
+						fmt.Sprintf("every path of %s ends the workflow or jumps away, so the workflow's own End after it can never be reached — the build fails CE6689", label),
+						"Let at least one path continue: a path that reaches the end of the workflow needs no `end workflow`.")
+				}
+			}
+		}
+		if b.mainFlow && len(b.activities) > 0 {
+			if j, ok := b.activities[len(b.activities)-1].(*ast.WorkflowJumpToNode); ok {
+				add("MDL-WF10",
+					fmt.Sprintf("the main flow ends in `jump to %s` — a jump must end a path, and the workflow's own End follows it and can never be reached; the build fails CE6679 and CE6689", j.Target),
+					"Put the jump inside an outcome, so that another path reaches the end of the workflow.")
+			}
+		}
+	}
+	return out
+}
+
+// validateAlterWorkflowEndAncestry refuses an ALTER that puts `end workflow`
+// somewhere the statement cannot show is illegal: its target activity already
+// sits under a parallel split or a non-interrupting boundary event in the stored
+// workflow (CE1844). What the statement does show — an inserted path, an
+// inserted non-interrupting boundary — ValidateAlterWorkflowEnds reports.
+func validateAlterWorkflowEndAncestry(ctx *ExecContext, s *ast.AlterWorkflowStmt) []string {
+	wf := findStoredWorkflow(ctx, s.Name)
+	if wf == nil || wf.Flow == nil {
+		return nil
+	}
+	var errs []string
+	check := func(op, ref string, atPos int, acts []ast.WorkflowActivityNode) {
+		if countAuthoredEnds(acts) == 0 {
+			return
+		}
+		place, ok := resolveStoredPlacement(wf.Flow, ref, atPos)
+		if !ok {
+			return
+		}
+		switch {
+		case place.underSplit:
+			errs = append(errs, fmt.Sprintf(
+				"%s on '%s' puts `end workflow` inside a parallel split path — '%s' is in one in the stored workflow, "+
+					"and one path cannot end the workflow while the others run; the build fails CE1844 [MDL-WF08]", op, ref, ref))
+		case place.underNonInterrupting:
+			errs = append(errs, fmt.Sprintf(
+				"%s on '%s' puts `end workflow` inside a non-interrupting boundary event path — '%s' is in one in the stored "+
+					"workflow, and that path runs alongside its task rather than ending it; the build fails CE1844 [MDL-WF08]", op, ref, ref))
+		}
+	}
+	for _, op := range s.Operations {
+		switch o := op.(type) {
+		case *ast.InsertAfterOp:
+			check("insert after", o.ActivityRef, o.AtPosition, []ast.WorkflowActivityNode{o.NewActivity})
+		case *ast.ReplaceActivityOp:
+			check("replace activity", o.ActivityRef, o.AtPosition, []ast.WorkflowActivityNode{o.NewActivity})
+		case *ast.InsertOutcomeOp:
+			check("insert outcome", o.ActivityRef, o.AtPosition, o.Activities)
+		case *ast.InsertBranchOp:
+			check("insert condition", o.ActivityRef, o.AtPosition, o.Activities)
+		case *ast.InsertBoundaryEventOp:
+			if o.EventType != "NonInterruptingTimer" { // that one is reported without a project
+				check("insert boundary event", o.ActivityRef, o.AtPosition, o.Activities)
+			}
+		}
+	}
+	return errs
+}
+
+type storedPlacement struct {
+	underSplit           bool
+	underNonInterrupting bool
+}
+
+// resolveStoredPlacement finds an activity the way resolveStoredActivity does —
+// by Name or Caption, in the same traversal order, @N among several, nothing
+// when ambiguous — and reports where it sits.
+func resolveStoredPlacement(flow *workflows.Flow, ref string, atPos int) (storedPlacement, bool) {
+	var matches []storedPlacement
+	collectStoredPlacements(flow, ref, storedPlacement{}, &matches)
+	switch {
+	case len(matches) == 0:
+		return storedPlacement{}, false
+	case atPos > 0:
+		if atPos > len(matches) {
+			return storedPlacement{}, false
+		}
+		return matches[atPos-1], true
+	case len(matches) == 1:
+		return matches[0], true
+	}
+	return storedPlacement{}, false
+}
+
+func collectStoredPlacements(flow *workflows.Flow, ref string, at storedPlacement, out *[]storedPlacement) {
+	if flow == nil {
+		return
+	}
+	boundary := func(events []*workflows.BoundaryEvent) {
+		for _, b := range events {
+			if b != nil {
+				nested := at
+				nested.underNonInterrupting = at.underNonInterrupting || b.EventType == "NonInterruptingTimer"
+				collectStoredPlacements(b.Flow, ref, nested, out)
+			}
+		}
+	}
+	for _, a := range flow.Activities {
+		if a == nil {
+			continue
+		}
+		if a.GetName() == ref || a.GetCaption() == ref {
+			*out = append(*out, at)
+		}
+		switch t := a.(type) {
+		case *workflows.ParallelSplitActivity:
+			inPath := at
+			inPath.underSplit = true
+			for _, o := range t.Outcomes {
+				if o != nil {
+					collectStoredPlacements(o.Flow, ref, inPath, out)
+				}
+			}
+		case *workflows.UserTask:
+			for _, o := range t.Outcomes {
+				if o != nil {
+					collectStoredPlacements(o.Flow, ref, at, out)
+				}
+			}
+			boundary(t.BoundaryEvents)
+		case *workflows.CallMicroflowTask:
+			for _, o := range t.Outcomes {
+				collectStoredPlacements(o.GetFlow(), ref, at, out)
+			}
+			boundary(t.BoundaryEvents)
+		case *workflows.WaitForNotificationActivity:
+			boundary(t.BoundaryEvents)
+		default:
+			for _, f := range storedNestedFlows(a) {
+				collectStoredPlacements(f, ref, at, out)
+			}
+		}
+	}
+}
+
+// refuseWorkflowReturn is exec's guard against `return;` in a workflow body.
+// Nothing is built from it, so without this `exec --no-check` would drop it —
+// and a dropped `return` in a branch falls through into the main flow, the
+// exact fault `end workflow` exists to prevent. MDL-WF11 reports the same
+// thing at check time.
+func refuseWorkflowReturn(activities []ast.WorkflowActivityNode) error {
+	found := false
+	walkWorkflowActivities(activities, func(a ast.WorkflowActivityNode) {
+		if _, ok := a.(*ast.WorkflowReturnNode); ok {
+			found = true
+		}
+	})
+	if !found {
+		return nil
+	}
+	return mdlerrors.NewValidationf("`return` is how a microflow ends — a workflow ends with `end workflow;`, " +
+		"which ends the whole workflow rather than the branch it is written in [MDL-WF11]")
+}
+
+// alterWorkflowAddedActivities returns the activities an ALTER WORKFLOW statement
+// introduces, in operation order.
+func alterWorkflowAddedActivities(s *ast.AlterWorkflowStmt) []ast.WorkflowActivityNode {
+	var added []ast.WorkflowActivityNode
+	for _, op := range s.Operations {
+		switch o := op.(type) {
+		case *ast.InsertAfterOp:
+			added = append(added, o.NewActivity)
+		case *ast.ReplaceActivityOp:
+			added = append(added, o.NewActivity)
+		case *ast.InsertOutcomeOp:
+			added = append(added, o.Activities...)
+		case *ast.InsertPathOp:
+			added = append(added, o.Activities...)
+		case *ast.InsertBranchOp:
+			added = append(added, o.Activities...)
+		case *ast.InsertBoundaryEventOp:
+			added = append(added, o.Activities...)
+		}
+	}
+	return added
+}
diff --git a/mdl/executor/validate_workflow_end_test.go b/mdl/executor/validate_workflow_end_test.go
new file mode 100644
index 000000000..3315a3157
--- /dev/null
+++ b/mdl/executor/validate_workflow_end_test.go
@@ -0,0 +1,306 @@
+// SPDX-License-Identifier: Apache-2.0
+
+package executor
+
+import (
+	"strings"
+	"testing"
+
+	"github.com/mendixlabs/mxcli/mdl/ast"
+	"github.com/mendixlabs/mxcli/mdl/backend/mock"
+	"github.com/mendixlabs/mxcli/mdl/visitor"
+	"github.com/mendixlabs/mxcli/model"
+	"github.com/mendixlabs/mxcli/sdk/workflows"
+)
+
+// An `end workflow` is named after its caption, "End" by default — the name of
+// the End mxcli appends to the main flow. Measured before the fix: two nested
+// Ends plus the main one built as CE0495 "Duplicate name 'End'". The implicit
+// Start and End are reserved, so nothing in the user activities takes them.
+func TestDeduplicateActivityNames_ReservesImplicitStartAndEnd(t *testing.T) {
+	end := func() *workflows.EndWorkflowActivity {
+		e := &workflows.EndWorkflowActivity{}
+		e.Name = "End"
+		return e
+	}
+	a, b := end(), end()
+	deduplicateActivityNames([]workflows.WorkflowActivity{a, b}, "Start", "End")
+	if a.Name == "End" || b.Name == "End" || a.Name == b.Name {
+		t.Errorf("nested Ends must not take the main End's name or each other's: got %q, %q", a.Name, b.Name)
+	}
+
+	// Control: without the reservation the first one takes "End".
+	c := end()
+	deduplicateActivityNames([]workflows.WorkflowActivity{c})
+	if c.Name != "End" {
+		t.Fatalf("control: expected the unreserved list to keep %q, got %q", "End", c.Name)
+	}
+}
+
+// Only the main flow's End is implicit. A nested one is emitted (see
+// TestDescribeWorkflow_NestedEndIsEmitted); this one must not be, or every
+// describe would print a stray `end workflow;` before the closer.
+func TestDescribeWorkflow_MainFlowEndStaysImplicit(t *testing.T) {
+	start := &workflows.StartWorkflowActivity{}
+	end := &workflows.EndWorkflowActivity{}
+	end.Name, end.Caption = "End", "End"
+	out := strings.Join(formatMainFlowActivities(&workflows.Flow{Activities: []workflows.WorkflowActivity{start, end}}, "  "), "\n")
+	if strings.Contains(out, "end workflow") {
+		t.Errorf("the main flow's End must stay implicit, got:\n%s", out)
+	}
+}
+
+// exec builds nothing from a `return;`, so without the guard `exec --no-check`
+// would drop it and the branch would fall through.
+func TestRefuseWorkflowReturn(t *testing.T) {
+	nested := []ast.WorkflowActivityNode{&ast.WorkflowUserTaskNode{
+		Outcomes: []ast.WorkflowUserTaskOutcomeNode{{Caption: "Reject", Activities: []ast.WorkflowActivityNode{&ast.WorkflowReturnNode{}}}},
+	}}
+	err := refuseWorkflowReturn(nested)
+	if err == nil || !strings.Contains(err.Error(), "end workflow") || !strings.Contains(err.Error(), "MDL-WF11") {
+		t.Errorf("a nested `return` must be refused with a pointer to `end workflow` [MDL-WF11], got %v", err)
+	}
+	if err := refuseWorkflowReturn([]ast.WorkflowActivityNode{&ast.WorkflowEndNode{}}); err != nil {
+		t.Errorf("`end workflow` must not be refused as a return: %v", err)
+	}
+}
+
+var endRules = []string{"MDL-WF08", "MDL-WF09", "MDL-WF10", "MDL-WF11"}
+
+// firedEndRules returns which of the End rules fired, in endRules order.
+func firedEndRules(vs [][2]string) []string {
+	var out []string
+	for _, id := range endRules {
+		if hasRule(vs, id) {
+			out = append(out, id)
+		}
+	}
+	return out
+}
+
+func endWF(body string) string {
+	return wfPreamble + "create workflow WF.W parameter $Ctx: WF.Ctx\nbegin\n" + body + "\nend workflow;"
+}
+
+const endNextTask = `user task Next 'Next' page WF.TaskPage outcomes 'ok' { } 'no' { };`
+
+// Every row is a placement measured against mxbuild (11.13.0) with the real
+// syntax — want is the one End rule that predicts its CE code, "" where the
+// build was clean. The clean rows are what keep the rules from refusing valid
+// workflows, and each case checks that ONLY its rule fires.
+func TestValidateWorkflow_EndPlacement(t *testing.T) {
+	cases := []struct{ name, body, want string }{
+		// Measured clean.
+		{"outcome ends", `user task A 'a' page WF.TaskPage outcomes 'Reject' { end workflow; } 'Approve' { };` + endNextTask, ""},
+		{"decision branch ends", `decision '$Ctx/Total > 1000' outcomes true -> { end workflow; } false -> { };` + endNextTask, ""},
+		{"call microflow outcome ends", `call microflow WF.ACT outcomes true -> { end workflow; } false -> { };` + endNextTask, ""},
+		{"interrupting boundary path ends", `user task A 'a' page WF.TaskPage outcomes 'x' { } 'y' { }
+  boundary event interrupting timer 'addDays([%CurrentDateTime%], 3)' { end workflow; };`, ""},
+		{"deep inside a decision branch", `decision '$Ctx/Total > 1000' outcomes
+  true -> { user task N 'n' page WF.TaskPage outcomes 'Reject' { end workflow; } 'Approve' { }; }
+  false -> { };` + endNextTask, ""},
+		{"nested under an interrupting boundary", `user task A 'a' page WF.TaskPage outcomes 'x' { } 'y' { }
+  boundary event interrupting timer 'addDays([%CurrentDateTime%], 3)' {
+    user task N 'n' page WF.TaskPage outcomes 'Reject' { end workflow; } 'Approve' { };
+  };`, ""},
+		{"two ends, one branch continues", `user task A 'a' page WF.TaskPage outcomes 'Reject' { end workflow; } 'Cancel' { end workflow; } 'Approve' { };` + endNextTask, ""},
+
+		// CE1844.
+		{"parallel path", `parallel split
+  path 1 { user task P1 'p1' page WF.TaskPage outcomes 'x' { } 'y' { }; end workflow; }
+  path 2 { user task P2 'p2' page WF.TaskPage outcomes 'x' { } 'y' { }; };`, "MDL-WF08"},
+		{"outcome nested in a parallel path", `parallel split
+  path 1 { user task P1 'p1' page WF.TaskPage outcomes 'Reject' { end workflow; } 'Approve' { }; }
+  path 2 { user task P2 'p2' page WF.TaskPage outcomes 'x' { } 'y' { }; };`, "MDL-WF08"},
+		{"non-interrupting boundary path", `user task A 'a' page WF.TaskPage outcomes 'x' { } 'y' { }
+  boundary event non interrupting timer 'addDays([%CurrentDateTime%], 3)' { end workflow; };`, "MDL-WF08"},
+		{"outcome nested under a non-interrupting boundary", `user task A 'a' page WF.TaskPage outcomes 'x' { } 'y' { }
+  boundary event non interrupting timer 'addDays([%CurrentDateTime%], 3)' {
+    user task N 'n' page WF.TaskPage outcomes 'Reject' { end workflow; } 'Approve' { };
+  };`, "MDL-WF08"},
+
+		// CE6671.
+		{"activity after end workflow", `user task A 'a' page WF.TaskPage outcomes 'Reject' { end workflow; call microflow WF.ACT; } 'Approve' { };` + endNextTask, "MDL-WF09"},
+
+		// CE6689.
+		{"both outcomes end, then an activity", `user task A 'a' page WF.TaskPage outcomes 'x' { end workflow; } 'y' { end workflow; };` + endNextTask, "MDL-WF10"},
+		{"both outcomes end, last in the main flow", `user task A 'a' page WF.TaskPage outcomes 'x' { end workflow; } 'y' { end workflow; };`, "MDL-WF10"},
+		{"decision branches both end, then an activity", `decision '$Ctx/Total > 1000' outcomes true -> { end workflow; } false -> { end workflow; };` + endNextTask, "MDL-WF10"},
+		{"every outcome jumps, then an activity", `user task A 'a' page WF.TaskPage outcomes 'x' { } 'y' { };
+user task B 'b' page WF.TaskPage outcomes 'x' { jump to A; } 'y' { jump to A; };` + endNextTask, "MDL-WF10"},
+		{"one ends and one jumps, then an activity", `user task A 'a' page WF.TaskPage outcomes 'x' { } 'y' { };
+user task B 'b' page WF.TaskPage outcomes 'x' { end workflow; } 'y' { jump to A; };` + endNextTask, "MDL-WF10"},
+		{"termination through a nested decision", `user task A 'a' page WF.TaskPage outcomes
+  'x' { decision '$Ctx/Total > 1000' outcomes true -> { end workflow; } false -> { end workflow; }; }
+  'y' { end workflow; };` + endNextTask, "MDL-WF10"},
+		{"main flow ends in a jump", `user task A 'a' page WF.TaskPage outcomes 'x' { } 'y' { };
+user task B 'b' page WF.TaskPage outcomes 'x' { } 'y' { };
+jump to A;`, "MDL-WF10"},
+
+		// `return` is a microflow's.
+		{"return in a branch", `user task A 'a' page WF.TaskPage outcomes 'Reject' { return; } 'Approve' { };` + endNextTask, "MDL-WF11"},
+		{"return in the main flow", `user task A 'a' page WF.TaskPage outcomes 'x' { } 'y' { };
+return;`, "MDL-WF11"},
+	}
+	for _, c := range cases {
+		t.Run(c.name, func(t *testing.T) {
+			vs := workflowViolations(t, endWF(c.body))
+			got := strings.Join(firedEndRules(vs), ",")
+			if got != c.want {
+				t.Errorf("End rules fired = [%s], want [%s]\nviolations: %v", got, c.want, vs)
+			}
+		})
+	}
+}
+
+// A single outcome may not carry activities at all (CE1876, MDL-WF02), `end
+// workflow` included — measured, the build reports that AND CE6689 for the main
+// End. One mistake gets one report: MDL-WF02, with advice that fits an End,
+// rather than "move the activities to the main flow".
+func TestValidateWorkflow_SingleOutcomeEndIsMDLWF02Only(t *testing.T) {
+	vs := workflowViolations(t, endWF(`user task A 'a' page WF.TaskPage outcomes 'Done' { end workflow; };`+endNextTask))
+	if !hasRule(vs, "MDL-WF02") {
+		t.Fatalf("expected MDL-WF02, got %v", vs)
+	}
+	if fired := firedEndRules(vs); len(fired) > 0 {
+		t.Errorf("a single-outcome End is MDL-WF02's to report, but %v also fired", fired)
+	}
+	for _, v := range vs {
+		if v[0] == "MDL-WF02" && !strings.Contains(v[1], "end workflow") {
+			t.Errorf("MDL-WF02 for an End-only outcome should say so, got %q", v[1])
+		}
+	}
+}
+
+func alterViolations(t *testing.T, src string) [][2]string {
+	t.Helper()
+	prog, errs := visitor.Build(src)
+	if len(errs) > 0 {
+		t.Fatalf("parse errors: %v", errs)
+	}
+	var out [][2]string
+	for _, stmt := range prog.Statements {
+		if s, ok := stmt.(*ast.AlterWorkflowStmt); ok {
+			for _, v := range ValidateAlterWorkflow(s) {
+				out = append(out, [2]string{v.RuleID, v.Message})
+			}
+		}
+	}
+	return out
+}
+
+// ALTER inserts take a body too. What the statement alone decides — a path
+// body is under a split, a non-interrupting boundary body is what it says — is
+// checked without a project.
+func TestValidateAlterWorkflow_EndPlacement(t *testing.T) {
+	cases := []struct{ name, src, want string }{
+		{"insert outcome that ends", `alter workflow WF.W insert outcome 'Stop' on T { end workflow; };`, ""},
+		{"insert path that ends", `alter workflow WF.W insert path on split1 { end workflow; };`, "MDL-WF08"},
+		{"insert non-interrupting boundary that ends", `alter workflow WF.W insert boundary event on T non interrupting timer 'addDays([%CurrentDateTime%], 3)' { end workflow; };`, "MDL-WF08"},
+		{"insert interrupting boundary that ends", `alter workflow WF.W insert boundary event on T interrupting timer 'addDays([%CurrentDateTime%], 3)' { end workflow; };`, ""},
+		{"insert outcome with an activity after the end", `alter workflow WF.W insert outcome 'Stop' on T { end workflow; call microflow WF.ACT; };`, "MDL-WF09"},
+		{"insert outcome with return", `alter workflow WF.W insert outcome 'Stop' on T { return; };`, "MDL-WF11"},
+	}
+	for _, c := range cases {
+		t.Run(c.name, func(t *testing.T) {
+			vs := alterViolations(t, c.src)
+			if got := strings.Join(firedEndRules(vs), ","); got != c.want {
+				t.Errorf("End rules fired = [%s], want [%s]\nviolations: %v", got, c.want, vs)
+			}
+		})
+	}
+}
+
+// storedEndAncestryCtx is a project holding WF.W: a top-level task, a task inside a
+// parallel split path, and a task inside a non-interrupting boundary event path.
+func storedEndAncestryCtx(t *testing.T) *ExecContext {
+	t.Helper()
+	task := func(name string) *workflows.UserTask {
+		ut := &workflows.UserTask{Outcomes: []*workflows.UserTaskOutcome{{Value: "a"}, {Value: "b"}}}
+		ut.Name = name
+		return ut
+	}
+	top := task("Top")
+	top.BoundaryEvents = []*workflows.BoundaryEvent{{
+		EventType: "NonInterruptingTimer",
+		Flow:      &workflows.Flow{Activities: []workflows.WorkflowActivity{task("InBoundary")}},
+	}}
+	split := &workflows.ParallelSplitActivity{Outcomes: []*workflows.ParallelSplitOutcome{
+		{Flow: &workflows.Flow{Activities: []workflows.WorkflowActivity{task("InPath")}}},
+	}}
+	split.Name = "split1"
+	wf := &workflows.Workflow{Name: "W", Flow: &workflows.Flow{Activities: []workflows.WorkflowActivity{top, split}}}
+	wf.ContainerID = "mod1"
+	mod := &model.Module{Name: "WF"}
+	mod.ID = "mod1"
+	mb := &mock.MockBackend{
+		IsConnectedFunc:   func() bool { return true },
+		ListModulesFunc:   func() ([]*model.Module, error) { return []*model.Module{mod}, nil },
+		ListWorkflowsFunc: func() ([]*workflows.Workflow, error) { return []*workflows.Workflow{wf}, nil },
+	}
+	ctx, _ := newMockCtx(t, withBackend(mb))
+	return ctx
+}
+
+// An inserted outcome looks harmless in the statement; whether its `end
+// workflow` is legal depends on where its task already sits (CE1844).
+func TestValidateAlterWorkflow_EndAncestryFromStoredWorkflow(t *testing.T) {
+	cases := []struct {
+		name, src string
+		refused   bool
+	}{
+		{"task in a parallel path", `alter workflow WF.W insert outcome 'Stop' on InPath { end workflow; };`, true},
+		{"task in a non-interrupting boundary path", `alter workflow WF.W insert outcome 'Stop' on InBoundary { end workflow; };`, true},
+		{"top-level task", `alter workflow WF.W insert outcome 'Stop' on Top { end workflow; };`, false},
+		// Control: the same target, nothing that ends.
+		{"task in a parallel path, no end", `alter workflow WF.W insert outcome 'Stop' on InPath { };`, false},
+	}
+	for _, c := range cases {
+		t.Run(c.name, func(t *testing.T) {
+			prog, errs := visitor.Build(c.src)
+			if len(errs) > 0 {
+				t.Fatalf("parse errors: %v", errs)
+			}
+			got := validateAlterWorkflowEndAncestry(storedEndAncestryCtx(t), prog.Statements[0].(*ast.AlterWorkflowStmt))
+			if refused := len(got) > 0; refused != c.refused {
+				t.Errorf("refused = %v, want %v: %v", refused, c.refused, got)
+			}
+			if c.refused && (len(got) != 1 || !strings.Contains(got[0], "CE1844")) {
+				t.Errorf("expected one CE1844 refusal, got %v", got)
+			}
+		})
+	}
+}
+
+// A caption is free text and a name is an identifier. The End's name was its
+// caption, so `end workflow comment 'Rejected by manager'` built CE7247 on both
+// engines — caught by the doctype script, not by the end-to-end fixture, whose
+// captions were all one word.
+func TestBuildEndWorkflow_NameIsAnIdentifierWhateverTheCaption(t *testing.T) {
+	valid := func(name string) bool {
+		if name == "" {
+			return false
+		}
+		for i, r := range name {
+			letter := r == '_' || (r >= 'A' && r <= 'Z') || (r >= 'a' && r <= 'z')
+			digit := r >= '0' && r <= '9'
+			if !letter && !(digit && i > 0) {
+				return false
+			}
+		}
+		return true
+	}
+	for _, caption := range []string{"", "Rejected", "Rejected by manager", "3 days passed", "Überschritten!"} {
+		end := buildEndWorkflow(&ast.WorkflowEndNode{Caption: caption})
+		if !valid(end.Name) {
+			t.Errorf("caption %q built the name %q, which mxbuild refuses (CE7247)", caption, end.Name)
+		}
+		want := caption
+		if want == "" {
+			want = "End"
+		}
+		if end.Caption != want {
+			t.Errorf("caption %q must be kept as written, got %q", caption, end.Caption)
+		}
+	}
+}
diff --git a/mdl/executor/validate_workflow_refs.go b/mdl/executor/validate_workflow_refs.go
index 4caf4e850..226eedf77 100644
--- a/mdl/executor/validate_workflow_refs.go
+++ b/mdl/executor/validate_workflow_refs.go
@@ -313,6 +313,9 @@ func validateAlterWorkflowRefs(ctx *ExecContext, s *ast.AlterWorkflowStmt, sc *s
 	// loading. Same function for both passes, so `check --references` and `exec`
 	// cannot drift.
 	errs = append(errs, validateAlterWorkflowActivityKinds(ctx, s)...)
+	// And an inserted `end workflow` must not land under a parallel split or a
+	// non-interrupting boundary event that only the stored workflow shows.
+	errs = append(errs, validateAlterWorkflowEndAncestry(ctx, s)...)
 
 	return append(errs, validateWorkflowReferences(ctx, added, sc)...)
 }
diff --git a/mdl/executor/validate_workflow_rewrite.go b/mdl/executor/validate_workflow_rewrite.go
index 563c32da6..88692a9cc 100644
--- a/mdl/executor/validate_workflow_rewrite.go
+++ b/mdl/executor/validate_workflow_rewrite.go
@@ -50,6 +50,23 @@ func checkNoDroppedWorkflowConstructs(ctx *ExecContext, workflowID model.ID, qua
 			qualifiedName, n))
 	}
 
+	// Ends inside branches. MDL could not state one until `end workflow`, and
+	// describe dropped them, so a rewrite from an older describe output would
+	// delete every one — and a branch that ended the workflow would silently
+	// fall through into the main flow instead. The main flow's own End is not
+	// counted: the builder always writes it.
+	if storedEnds := countRawWorkflowNodesExact(raw, "Workflows$EndWorkflowActivity") - 1; storedEnds > 0 {
+		if authored := countAuthoredEnds(stmt.Activities); authored < storedEnds {
+			return mdlerrors.NewUnsupported(fmt.Sprintf(
+				"workflow %s has %d stored `end workflow` inside its branches but this statement declares %d — "+
+					"rewriting it would delete the difference, and each branch that ended the workflow would fall "+
+					"through into the main flow instead.\n"+
+					"  Restate them (`end workflow;`), which `describe workflow %s` now emits, or use ALTER WORKFLOW "+
+					"to change one activity at a time.",
+				qualifiedName, storedEnds, authored, qualifiedName))
+		}
+	}
+
 	storedBE := countRawBoundaryEvents(raw)
 	if storedBE == 0 {
 		return nil
@@ -145,3 +162,41 @@ func countAuthoredBoundaryEvents(activities []ast.WorkflowActivityNode) int {
 	})
 	return n
 }
+
+// countRawWorkflowNodesExact counts BSON sub-documents whose $Type is exactly
+// the given one. The substring match countRawWorkflowNodes uses would also count
+// Workflows$EndOfParallelSplitPathActivity and EndOfBoundaryEventPathActivity,
+// the markers mxcli writes at the end of every path.
+func countRawWorkflowNodesExact(v any, typeName string) int {
+	switch t := v.(type) {
+	case map[string]any:
+		n := 0
+		if s, ok := t["$Type"].(string); ok && s == typeName {
+			n++
+		}
+		for k, child := range t {
+			if k != "$Type" {
+				n += countRawWorkflowNodesExact(child, typeName)
+			}
+		}
+		return n
+	case []any:
+		n := 0
+		for _, e := range t {
+			n += countRawWorkflowNodesExact(e, typeName)
+		}
+		return n
+	}
+	return 0
+}
+
+// countAuthoredEnds counts the `end workflow` statements inside branches.
+func countAuthoredEnds(activities []ast.WorkflowActivityNode) int {
+	n := 0
+	walkWorkflowActivities(activities, func(act ast.WorkflowActivityNode) {
+		if _, ok := act.(*ast.WorkflowEndNode); ok {
+			n++
+		}
+	})
+	return n
+}
diff --git a/mdl/executor/validate_workflow_rewrite_test.go b/mdl/executor/validate_workflow_rewrite_test.go
index edf5cef61..07c6df105 100644
--- a/mdl/executor/validate_workflow_rewrite_test.go
+++ b/mdl/executor/validate_workflow_rewrite_test.go
@@ -172,3 +172,76 @@ end workflow;`
 			"should still emit the documented order")
 	}
 }
+
+// storedWorkflowWithEnds returns a context whose stored workflow has the main
+// flow's End plus `nested` Ends inside a user task's outcomes, and one of each
+// end-of-path marker, which must not be mistaken for an End.
+func storedWorkflowWithEnds(t *testing.T, nested int) *ExecContext {
+	t.Helper()
+	outcomes := make([]any, 0, nested)
+	for i := 0; i < nested; i++ {
+		outcomes = append(outcomes, map[string]any{
+			"$Type": "Workflows$UserTaskOutcome",
+			"Flow": map[string]any{
+				"$Type":      "Workflows$Flow",
+				"Activities": []any{map[string]any{"$Type": "Workflows$EndWorkflowActivity"}},
+			},
+		})
+	}
+	raw := map[string]any{
+		"$Type": "Workflows$Workflow",
+		"Flow": map[string]any{
+			"$Type": "Workflows$Flow",
+			"Activities": []any{
+				map[string]any{"$Type": "Workflows$StartWorkflowActivity"},
+				map[string]any{"$Type": "Workflows$SingleUserTaskActivity", "Outcomes": outcomes},
+				map[string]any{"$Type": "Workflows$EndOfParallelSplitPathActivity"},
+				map[string]any{"$Type": "Workflows$EndOfBoundaryEventPathActivity"},
+				map[string]any{"$Type": "Workflows$EndWorkflowActivity"},
+			},
+		},
+	}
+	mb := &mock.MockBackend{
+		IsConnectedFunc: func() bool { return true },
+		GetRawUnitFunc:  func(model.ID) (map[string]any, error) { return raw, nil },
+	}
+	ctx, _ := newMockCtx(t, withBackend(mb))
+	return ctx
+}
+
+// A branch that ended the workflow could not be stated in MDL, and describe
+// dropped it, so a rewrite deleted it without a word — and the branch then fell
+// through into the main flow. Guard-don't-drop, as for boundary events.
+func TestWorkflowRewrite_RefusesDroppingNestedEnd(t *testing.T) {
+	stmt := parseWorkflowStmt(t, `create or replace workflow M.W parameter $C: M.Ctx
+begin
+  user task T 'c' page M.P outcomes 'Reject' { } 'Approve' { };
+end workflow;`)
+	err := checkNoDroppedWorkflowConstructs(storedWorkflowWithEnds(t, 1), "wf1", "M.W", stmt)
+	if err == nil || !strings.Contains(err.Error(), "end workflow") {
+		t.Fatalf("a rewrite that drops a stored nested End must be refused, got %v", err)
+	}
+}
+
+func TestWorkflowRewrite_AllowsRestatedNestedEnd(t *testing.T) {
+	stmt := parseWorkflowStmt(t, `create or replace workflow M.W parameter $C: M.Ctx
+begin
+  user task T 'c' page M.P outcomes 'Reject' { end workflow; } 'Approve' { };
+end workflow;`)
+	if err := checkNoDroppedWorkflowConstructs(storedWorkflowWithEnds(t, 1), "wf1", "M.W", stmt); err != nil {
+		t.Fatalf("a rewrite that restates the nested End must be allowed, got %v", err)
+	}
+}
+
+// The control for both: the main flow's End and the two end-of-path markers are
+// always present and are not branch Ends — counting them would refuse every
+// rewrite of every workflow.
+func TestWorkflowRewrite_MainEndAndPathMarkersAreNotNestedEnds(t *testing.T) {
+	stmt := parseWorkflowStmt(t, `create or replace workflow M.W parameter $C: M.Ctx
+begin
+  user task T 'c' page M.P outcomes 'Reject' { } 'Approve' { };
+end workflow;`)
+	if err := checkNoDroppedWorkflowConstructs(storedWorkflowWithEnds(t, 0), "wf1", "M.W", stmt); err != nil {
+		t.Fatalf("no nested End is stored, so nothing can be dropped, got %v", err)
+	}
+}
diff --git a/mdl/grammar/domains/MDLWorkflow.g4 b/mdl/grammar/domains/MDLWorkflow.g4
index 1904ab35a..3be46fa5d 100644
--- a/mdl/grammar/domains/MDLWorkflow.g4
+++ b/mdl/grammar/domains/MDLWorkflow.g4
@@ -21,11 +21,42 @@ createWorkflowStatement
       (EXPORT LEVEL (IDENTIFIER | API))?
       (OVERVIEW PAGE qualifiedName)?
       (DUE DATE_TYPE dueDate=STRING_LITERAL)?
-      BEGIN workflowBody END WORKFLOW SEMICOLON? SLASH?
+      BEGIN workflowMainBody END WORKFLOW SEMICOLON? SLASH?
     ;
 
+/**
+ * The top-level body. It cannot hold `end workflow;` as a statement: there those
+ * words close the body, and they ARE the main flow's End — Mendix refuses an End
+ * anywhere else in the main flow (CE6671). Keeping the statement out of this rule
+ * is what lets it exist at all; the first workflow grammar dropped it for the
+ * conflict with the closer. See docs/11-proposals/PROPOSAL_workflow_end_activity.md.
+ */
+workflowMainBody
+    : (workflowActivityStmt | workflowReturnStmt SEMICOLON)*
+    ;
+
+/**
+ * A brace body: an outcome, a decision branch, a parallel path, a boundary-event
+ * path, or an ALTER insert. `end workflow;` is accepted in every one and refused
+ * by check rules where Mendix refuses it (MDL-WF08/09/10), because a platform
+ * rule reported as a parse error reads as "not implemented".
+ */
 workflowBody
-    : workflowActivityStmt*
+    : (workflowActivityStmt | workflowEndStmt SEMICOLON | workflowReturnStmt SEMICOLON)*
+    ;
+
+/** Ends the whole workflow from inside a branch; `comment` sets the End's caption. */
+workflowEndStmt
+    : END WORKFLOW (COMMENT STRING_LITERAL)?
+    ;
+
+/**
+ * `return` belongs to microflows. It is parsed only so MDL-WF11 can say that a
+ * workflow ends with `end workflow;` — it is the spelling a microflow author, or
+ * an LLM, reaches for — and exec refuses it rather than dropping it.
+ */
+workflowReturnStmt
+    : RETURN
     ;
 
 workflowActivityStmt
diff --git a/mdl/visitor/visitor_workflow.go b/mdl/visitor/visitor_workflow.go
index 1526df227..d1614a8f0 100644
--- a/mdl/visitor/visitor_workflow.go
+++ b/mdl/visitor/visitor_workflow.go
@@ -5,6 +5,8 @@ package visitor
 import (
 	"strings"
 
+	"github.com/antlr4-go/antlr/v4"
+
 	"github.com/mendixlabs/mxcli/mdl/ast"
 	"github.com/mendixlabs/mxcli/mdl/grammar/parser"
 )
@@ -84,8 +86,8 @@ func (b *Builder) ExitCreateWorkflowStatement(ctx *parser.CreateWorkflowStatemen
 	stmt.Documentation, stmt.DocumentationSet = findDocComment(ctx)
 
 	// Parse body
-	if body := ctx.WorkflowBody(); body != nil {
-		stmt.Activities = buildWorkflowBody(body)
+	if body := ctx.WorkflowMainBody(); body != nil {
+		stmt.Activities = buildWorkflowMainBody(body)
 	}
 
 	b.statements = append(b.statements, stmt)
@@ -389,24 +391,57 @@ func parseAlterActivityRef(ctx *parser.AlterActivityRefContext) (string, int) {
 	return name, atPos
 }
 
-// buildWorkflowBody converts a workflow body context to activity nodes.
+// buildWorkflowBody builds a brace body — an outcome, a decision branch, a
+// parallel path, a boundary-event path or an ALTER insert — which may contain
+// `end workflow`.
 func buildWorkflowBody(ctx parser.IWorkflowBodyContext) []ast.WorkflowActivityNode {
 	if ctx == nil {
 		return nil
 	}
-	bodyCtx := ctx.(*parser.WorkflowBodyContext)
-	var activities []ast.WorkflowActivityNode
+	return buildWorkflowStatements(ctx.GetChildren())
+}
+
+// buildWorkflowMainBody builds the top-level body, where `end workflow` is the
+// closer rather than a statement.
+func buildWorkflowMainBody(ctx parser.IWorkflowMainBodyContext) []ast.WorkflowActivityNode {
+	if ctx == nil {
+		return nil
+	}
+	return buildWorkflowStatements(ctx.GetChildren())
+}
 
-	for _, actCtx := range bodyCtx.AllWorkflowActivityStmt() {
-		act := buildWorkflowActivityStmt(actCtx)
+// buildWorkflowStatements walks a body's children in source order. A body holds
+// more than one rule since `end workflow` and `return` are not
+// workflowActivityStmt alternatives, and collecting each with its own All…()
+// accessor would move every End to the end of its block.
+func buildWorkflowStatements(children []antlr.Tree) []ast.WorkflowActivityNode {
+	var activities []ast.WorkflowActivityNode
+	for _, child := range children {
+		var act ast.WorkflowActivityNode
+		switch c := child.(type) {
+		case *parser.WorkflowActivityStmtContext:
+			act = buildWorkflowActivityStmt(c)
+		case *parser.WorkflowEndStmtContext:
+			act = buildWorkflowEnd(c)
+		case *parser.WorkflowReturnStmtContext:
+			act = &ast.WorkflowReturnNode{}
+		}
 		if act != nil {
 			activities = append(activities, act)
 		}
 	}
-
 	return activities
 }
 
+// buildWorkflowEnd builds `end workflow [comment '<caption>']`.
+func buildWorkflowEnd(ctx *parser.WorkflowEndStmtContext) *ast.WorkflowEndNode {
+	node := &ast.WorkflowEndNode{}
+	if ctx.COMMENT() != nil && ctx.STRING_LITERAL() != nil {
+		node.Caption = unquoteString(ctx.STRING_LITERAL().GetText())
+	}
+	return node
+}
+
 // buildWorkflowActivityStmt dispatches to the appropriate builder.
 func buildWorkflowActivityStmt(ctx parser.IWorkflowActivityStmtContext) ast.WorkflowActivityNode {
 	if ctx == nil {
diff --git a/mdl/visitor/visitor_workflow_test.go b/mdl/visitor/visitor_workflow_test.go
index 2f1e93235..6af2e2a77 100644
--- a/mdl/visitor/visitor_workflow_test.go
+++ b/mdl/visitor/visitor_workflow_test.go
@@ -1303,3 +1303,99 @@ END WORKFLOW;`
 		t.Errorf("mapping = %+v, want {Ctx $WorkflowContext}", got)
 	}
 }
+
+// `end workflow` ends a workflow from inside a branch. It is accepted in every
+// brace body and builds in statement order, so an End after a call stays after
+// it. See docs/11-proposals/PROPOSAL_workflow_end_activity.md.
+func TestWorkflowVisitor_EndWorkflowInBranches(t *testing.T) {
+	input := `create workflow M.W parameter $C: M.E
+begin
+  user task T 'Review' page M.P
+    outcomes
+      'Approve' { }
+      'Reject' { call microflow M.Notify; end workflow comment 'Rejected'; }
+    boundary event interrupting timer 'addDays([%CurrentDateTime%], 3)' { end workflow; };
+  decision '$WorkflowContext/Flag'
+    outcomes
+      true -> { end workflow; }
+      false -> { };
+end workflow;`
+	prog, errs := Build(input)
+	if len(errs) > 0 {
+		t.Fatalf("parse errors: %v", errs)
+	}
+	stmt := prog.Statements[0].(*ast.CreateWorkflowStmt)
+	if len(stmt.Activities) != 2 {
+		t.Fatalf("expected 2 main-flow activities, got %d", len(stmt.Activities))
+	}
+
+	task := stmt.Activities[0].(*ast.WorkflowUserTaskNode)
+	reject := task.Outcomes[1].Activities
+	if len(reject) != 2 {
+		t.Fatalf("Reject outcome: expected [call microflow, end workflow], got %d activities", len(reject))
+	}
+	if _, ok := reject[0].(*ast.WorkflowCallMicroflowNode); !ok {
+		t.Errorf("Reject[0] = %T, want the call microflow (statement order lost)", reject[0])
+	}
+	if end, ok := reject[1].(*ast.WorkflowEndNode); !ok || end.Caption != "Rejected" {
+		t.Errorf("Reject[1] = %#v, want an End captioned 'Rejected'", reject[1])
+	}
+	if len(task.BoundaryEvents) != 1 || len(task.BoundaryEvents[0].Activities) != 1 {
+		t.Fatalf("boundary event path: expected one activity")
+	}
+	if end, ok := task.BoundaryEvents[0].Activities[0].(*ast.WorkflowEndNode); !ok || end.Caption != "" {
+		t.Errorf("boundary path = %#v, want an uncaptioned End", task.BoundaryEvents[0].Activities[0])
+	}
+
+	decision := stmt.Activities[1].(*ast.WorkflowDecisionNode)
+	if _, ok := decision.Outcomes[0].Activities[0].(*ast.WorkflowEndNode); !ok {
+		t.Errorf("decision true branch = %T, want an End", decision.Outcomes[0].Activities[0])
+	}
+}
+
+// In the top-level body `end workflow` is the closer — it IS the main flow's End —
+// so one written in the middle stays a parse error. Mendix refuses an End there
+// anyway (CE6671). The closer keeps its optional `;` and `/`.
+func TestWorkflowVisitor_EndWorkflowOnlyClosesTheMainFlow(t *testing.T) {
+	mid := `create workflow M.W parameter $C: M.E
+begin
+  user task T 'c' page M.P outcomes 'a' { } 'b' { };
+  end workflow;
+  user task U 'u' page M.P outcomes 'a' { } 'b' { };
+end workflow;`
+	if _, errs := Build(mid); len(errs) == 0 {
+		t.Error("a top-level `end workflow;` followed by more activities must not parse")
+	}
+	for _, closer := range []string{"end workflow;", "end workflow\n/", "end workflow"} {
+		src := "create workflow M.W parameter $C: M.E\nbegin\n  user task T 'c' page M.P outcomes 'a' { } 'b' { };\n" + closer
+		if _, errs := Build(src); len(errs) > 0 {
+			t.Errorf("closer %q must still parse: %v", closer, errs)
+		}
+	}
+}
+
+// `return;` is how a microflow ends. In a workflow it is parsed — in a branch and
+// in the main flow — so MDL-WF11 can point at `end workflow;` instead of a bare
+// parse error, and so exec can refuse it rather than drop it.
+func TestWorkflowVisitor_ReturnIsParsedForItsHint(t *testing.T) {
+	input := `create workflow M.W parameter $C: M.E
+begin
+  user task T 'c' page M.P outcomes 'a' { return; } 'b' { };
+  return;
+end workflow;`
+	prog, errs := Build(input)
+	if len(errs) > 0 {
+		t.Fatalf("parse errors: %v", errs)
+	}
+	stmt := prog.Statements[0].(*ast.CreateWorkflowStmt)
+	if len(stmt.Activities) != 2 {
+		t.Fatalf("expected [user task, return], got %d activities", len(stmt.Activities))
+	}
+	if _, ok := stmt.Activities[1].(*ast.WorkflowReturnNode); !ok {
+		t.Errorf("main flow [1] = %T, want a WorkflowReturnNode", stmt.Activities[1])
+	}
+	task := stmt.Activities[0].(*ast.WorkflowUserTaskNode)
+	if _, ok := task.Outcomes[0].Activities[0].(*ast.WorkflowReturnNode); !ok {
+		t.Errorf("outcome 'a' = %T, want a WorkflowReturnNode", task.Outcomes[0].Activities[0])
+	}
+}

From db61b94925428c12315b258550db3caa642284ee Mon Sep 17 00:00:00 2001
From: Ako <andrej@koelewijn.net>
Date: Mon, 14 Sep 2026 18:10:05 +0000
Subject: [PATCH 6/9] test(workflow): make the round-trip fixtures valid task
 pages and targeting microflows

CI's integration job failed four workflow round-trip tests on this PR:
exec now checks a user task's page and targeting microflow signatures, and
the shared fixtures had never been valid. createTaskPages made task pages with
no parameters (CE7410 on mxbuild 11.13.0), and the Comprehensive test's
targeting microflows took no parameters and returned a String (CE6677). The
round-trip tests only compare describe output, so nothing had built them.

The pages now take $WorkflowUserTask: System.WorkflowUserTask, and the
targeting microflows take System.Workflow plus the workflow's context entity
and return the candidate users.

The unit suite could not have caught this: the rule is gated on the project
version, and its mock projects have none. Verified locally on both engines
with a real 11.13 project (-v shows all four running, not skipped); restoring
a parameterless page reproduces CI's exact CE7410 refusal.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 .../fix-issue/findings/mdl-executor.jsonl     |  2 +-
 mdl/executor/roundtrip_workflow_test.go       | 24 ++++++++++++++++---
 2 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/.claude/skills/fix-issue/findings/mdl-executor.jsonl b/.claude/skills/fix-issue/findings/mdl-executor.jsonl
index 175b0e38a..ffcc860c0 100644
--- a/.claude/skills/fix-issue/findings/mdl-executor.jsonl
+++ b/.claude/skills/fix-issue/findings/mdl-executor.jsonl
@@ -613,5 +613,5 @@
 {"area":"mdl-executor","date":"2026-09-14","symptom":"DESCRIBE flattens a microflow whose branches cross into nested ifs that mean something else, and warns MDL-FLOW01 'must not be re-executed' instead of describing it","cause":"Nested if/then/else is single-entry/single-exit. A merge reached by branches of two different splits has no place in a tree, so the describer walked past it and emitted the conjunction along one path.","file":"mdl/executor/cmd_microflows_show_crossed.go","fix":"Mode 2: label the shared-suffix entry AND the split's post-dominator, emit `join <label>` at every branch end, then declare each merge as a top-level section after the traversal. MDL-FLOW01 is retired per decision when the description actually declared the merge.","insight":"Three traps, each of which produced plausible-looking output. (1) A crossed merge must be emitted the OPPOSITE way from an error-rejoin merge -- rejoin is DECLARED where the traversal meets it, crossed is JOINED by each branch and declared once afterwards -- so the label alone cannot drive emission; carry a crossed set beside the names. (2) Emit the join BEFORE the visited guard: arriving twice is what 'crossed' MEANS, and the guard silently swallows the second branch's join, leaving that path falling off the end. (3) Retire a warning on what was EMITTED, not on what was labelled. An inheritance split has its own traversal that walks through a labelled merge without emitting a join, so the label goes unused and the reader still gets the nested rendering -- suppressing on the label alone silenced MDL-FLOW01 on Administration.ManageMyAccount, whose description is byte-identical with and without the feature. That forced warnings to be computed AFTER the body instead of before it. Method: keep a baseline binary (git stash -u; build) and diff `describe` over every microflow in a corpus -- the refactor step should be byte-identical (it was, 18 of 18) and the feature step should change only the microflows it targets (2 of 18). Anything else changing is the bug."}
 {"area": "mdl/executor", "date": "2026-09-13", "symptom": "describe page -> create or replace page broke a button's icon. An icon into an IMAGE collection came back as `Icon: 'DesignSystem.Icons_SVG.edit'` and the build failed [CE1613] \"The selected custom icon 'DesignSystem.Icons_SVG.edit' no longer exists.\" A GLYPH icon produced no describe output at all -- no clause, no comment -- and replay DELETED it at exit 0.", "cause": "Mendix stores three icon elements and two put a qualified name under the same BSON key: Forms$IconCollectionIcon{Image}->CustomIcons$CustomIcon, Forms$ImageIcon{Image}->Images$Image, Forms$GlyphIcon{Code}. extractIconRef read `Image` off whichever element was there and threw the $Type away, and the page builder writes Forms$IconCollectionIcon unconditionally -- so the two named variants were spelled identically on the way out and collapsed into one on the way back in.", "file": "mdl/executor/cmd_pages_describe_output.go (extractButtonIcon, widgetIconMDL, widgetIconNote), mdl/executor/cmd_pages_describe.go (rawWidget.IconType/IconCode), mdl/executor/cmd_pages_describe_parse.go; tests mdl/executor/cmd_pages_describe_icon_test.go", "insight": "The identical three-variant defect was fixed in NAVIGATION eight days earlier (2026-09-05, same area file) and the page path never received it -- so the cheapest possible diagnosis was `grep MenuIconKindOf`, and the fix reuses that resolver rather than adding a second one. **Generalisable: when a fix teaches a layer to distinguish polymorphic variants, grep for every OTHER reader of the same element.** The find was one `git grep Forms\\$ImageIcon` away all along. Two things the report got understandably wrong and that the fix depends on getting right: it is not about third-party vs native collections (a third-party ICON collection round-trips fine -- and CE1613 naming the reference is itself proof the name was never a custom icon, since mxbuild would otherwise have resolved it), and the reported image-icon case is the CHEAPER half -- the glyph case is silent on both sides, so nothing in the output even hints at the loss. **Measure the silence, not the wrong answer**: `grep -c icon` over describe output of a stock marketplace project's FeedbackModule pages returned 0 before and 3 after, which is the only form the glyph bug has. The note has to fire on an UNRECOGNISED $Type too, not a known-bad list, or the next variant Mendix adds is dropped the same way. Controls that matter: an icon-collection icon must still emit a bare `Icon:` and NO note (else the fix passes by flagging everything), and an iconless button must emit neither. No .mdl repro is possible -- mxcli cannot author an image or glyph icon on a button, so the input to the round trip cannot be constructed in MDL; the reproduction is a stored-widget map in the unit test. Also observed in passing and NOT fixed: a nameless `statictext` makes describe output unparseable (pre-existing, confirmed against the base binary), and NavigationList item / DropDownButton icons are never read at all, so they are dropped as silently as the glyph was.", "refs": ["#1059", "#1008", "#602"], "ce": ["CE1613"]}
 {"area": "mdl/executor", "date": "2026-09-13", "symptom": "Follow-on to #1059: a widget's image and glyph icons were readable but unwritable, so describe -> exec could only be made honest (a `-- NOT re-executable` note), not lossless. Authoring them needed the kind to reach the element $Type through grammar, AST, visitor, builder and BOTH engines.", "cause": "Three separate vocabularies for the same three Mendix icon elements: types.MenuIconKind (navigation), pages.IconType (the page model's own three-value enum), and a bare string in the widget property map. The page path had no kind at all, so it could not express one.", "file": "mdl/grammar/domains/MDLPage.g4 (widgetIconV3), mdl/ast/ast_page_v3.go (WidgetIcon), mdl/visitor/visitor_page_v3.go (buildWidgetIconV3), mdl/executor/cmd_pages_builder_v3_widgets.go (buildWidgetIcon), mdl/backend/modelsdk/widget_write.go (iconToGen), sdk/mpr/writer_widgets_display.go (buildWidgetIconBson), mdl/executor/validate_icon_refs.go, mdl/executor/validate_glyph_codes.go", "insight": "**Delete the second vocabulary as part of the fix, not after it.** pages.IconType existed for exactly the same three kinds as types.MenuIconKind and had drifted to a different value set; replacing it (2 call sites) is what made the writers a dispatch rather than an inference. A feature that adds a third copy would have re-created the bug in a new place. **The pre-existing tests of the OLD feature are the safety net for the new one**: MDL078's menu tests caught a python replace of mine that silently no-opped (anchor did not match, no assert), which nothing else would have. Always assert on the replacement count when editing by script. **Measure the premise, don't reason by analogy** — extending MDL078 to widget glyphs assumed mxbuild resolves a widget glyph the same way it resolves a menu one. It does, measured: `Icon: glyph 57562` fails `mxbuild --target=deploy` with `System.InvalidOperationException: Sequence contains no matching element` — but it names the **page**, not a layout, so the rule's own message was wrong and had to be corrected from the measurement. **The reference check had the mirror-image bug waiting**: resolving an image reference against the ICON collections reports a correct name as a typo, which is the same conflation pointed the other way — per-kind resolution plus an `otherKindHint` naming the remedy. **An empty listing is 'could not establish', not 'none'** — each half of the index is independent, so a project that yields icon collections but no image collections still resolves what it can. Verified on 11.13.0: all three authored, mx check 0 errors, deploy BUILD SUCCEEDED, right $Type on disk; controls reproduce CE1613 (image written without `image`) and the glyph build failure. Corpus sweep 531 clean.", "refs": ["#1059", "#1008", "#602"], "ce": ["CE1613"]}
-{"area": "mdl/executor", "date": "2026-09-14", "symptom": "A workflow user task whose task page takes the context entity instead of System.WorkflowUserTask (CE7412), takes no parameters (CE7410), or whose targeting microflow does not take exactly System.Workflow plus the context entity (CE6677) passed `mxcli check` AND `check --references`, was written by exec, and failed only under the native mx check. Reported in a team briefing on building workflows from MDL as two of the reasons 'a green CLI check is not evidence for workflows'.", "cause": "validateWorkflowReferences resolved the user task's page and targeting microflow by NAME only — it reported a document that does not exist, never one that exists with the wrong signature. Neither signature was in `mxcli syntax workflow` either, so authors had nothing to copy.", "fix": "validate_workflow_task_signature.go checks both signatures from the script's own definitions first (scriptContext now records page parameter entities and entity generalizations, beside flowParams) and then the project, for CREATE WORKFLOW (incl. nested and multi-user tasks) and ALTER WORKFLOW (inserted tasks, SET ACTIVITY PAGE / TARGETING MICROFLOW, context entity read off the stored workflow). Wired into validateWorkflowStatementRefs / validateAlterWorkflowRefs. check --references reports before anything is written; exec calls the same function at the workflow statement, so the workflow is never written but earlier statements in the script already are. Gated on Mendix 11, where it is measured.", "file": "mdl/executor/validate_workflow_task_signature.go", "insight": "Measure the CLEAN edges before writing a refusal — three of the nine rows would have been false refusals from a plausible reading of the error text: a task page MAY take extra parameters besides WorkflowUserTask, a targeting microflow MAY take its two parameters in either order, and its context parameter MAY be a generalization of the context entity (but not a specialization). Since exec refuses on a check error, a false refusal is a blocker. Where the inheritance chain leaves what can be resolved (a script entity extending something unknown), return 'not proven' rather than a mismatch. Also a harness caveat worth keeping: the control run that stubbed the version gate first reported 0 failures because the harness only counted `--- FAIL` lines containing '/', i.e. subtests; the gate test is top-level. A silent control is a claim about the harness before it is a claim about the test."}
+{"area": "mdl/executor", "date": "2026-09-14", "symptom": "A workflow user task whose task page takes the context entity instead of System.WorkflowUserTask (CE7412), takes no parameters (CE7410), or whose targeting microflow does not take exactly System.Workflow plus the context entity (CE6677) passed `mxcli check` AND `check --references`, was written by exec, and failed only under the native mx check. Reported in a team briefing on building workflows from MDL as two of the reasons 'a green CLI check is not evidence for workflows'.", "cause": "validateWorkflowReferences resolved the user task's page and targeting microflow by NAME only — it reported a document that does not exist, never one that exists with the wrong signature. Neither signature was in `mxcli syntax workflow` either, so authors had nothing to copy.", "fix": "validate_workflow_task_signature.go checks both signatures from the script's own definitions first (scriptContext now records page parameter entities and entity generalizations, beside flowParams) and then the project, for CREATE WORKFLOW (incl. nested and multi-user tasks) and ALTER WORKFLOW (inserted tasks, SET ACTIVITY PAGE / TARGETING MICROFLOW, context entity read off the stored workflow). Wired into validateWorkflowStatementRefs / validateAlterWorkflowRefs. check --references reports before anything is written; exec calls the same function at the workflow statement, so the workflow is never written but earlier statements in the script already are. Gated on Mendix 11, where it is measured.", "file": "mdl/executor/validate_workflow_task_signature.go", "insight": "Measure the CLEAN edges before writing a refusal — three of the nine rows would have been false refusals from a plausible reading of the error text: a task page MAY take extra parameters besides WorkflowUserTask, a targeting microflow MAY take its two parameters in either order, and its context parameter MAY be a generalization of the context entity (but not a specialization). Since exec refuses on a check error, a false refusal is a blocker. Where the inheritance chain leaves what can be resolved (a script entity extending something unknown), return 'not proven' rather than a mismatch. Also a harness caveat worth keeping: the control run that stubbed the version gate first reported 0 failures because the harness only counted `--- FAIL` lines containing '/', i.e. subtests; the gate test is top-level. A silent control is a claim about the harness before it is a claim about the test. And run `make test-integration` before pushing a reference-path rule: the unit suite gates the rule on a mock project with no version, so it never fired there, while the integration round-trip tests exec against a real 11.x project — and their shared helper created task pages with no parameters and targeting microflows with none, which CI refused. Those fixtures had never been built; the rule was right, they were repaired."}
 {"area": "mdl/executor", "date": "2026-09-14", "symptom": "An `exec` / `check --references` error on a CREATE WORKFLOW statement ends with 'hint: M.W is defined later in this script — move its create statement before this one', naming the failing workflow itself (or a workflow already created earlier in the script).", "cause": "annotateForwardRef draws candidate names from scriptContext.allNames (which includes workflows) and excludes the statement's own name and already-created names via scriptContext.has — which checked modules, entities, enumerations, microflows, nanoflows, pages, snippets and code actions but NOT workflows. A parallel list that drifted from the one it filters.", "fix": "scriptContext.has also answers for sc.workflows.", "file": "mdl/executor/validate.go", "insight": "Two lists over the same kinds (allNames and has) with nothing tying them together — the same drift shape as collectDefinitions/collectSingle. The misfire only became visible once an error routinely named its own workflow, i.e. a new rule surfaced a latent bug in how every rule's message is decorated. When adding a document kind to scriptContext, check every method that enumerates kinds, not just the collector."}
diff --git a/mdl/executor/roundtrip_workflow_test.go b/mdl/executor/roundtrip_workflow_test.go
index c9a629a79..53193a43e 100644
--- a/mdl/executor/roundtrip_workflow_test.go
+++ b/mdl/executor/roundtrip_workflow_test.go
@@ -29,12 +29,17 @@ import (
 // exec now resolve a workflow's page references (issue #943), so the missing
 // page is reported rather than written into the model — which is the point of
 // that check: Mendix rejects the same workflow with CE1613.
+//
+// And the page must take the task. These pages took no parameters, which
+// mxbuild refuses as CE7410 (measured on 11.13.0); exec now checks the task
+// page's signature and refused them, so the fixture is a valid task page.
 func createTaskPages(t *testing.T, env *testEnv, mod string, names ...string) {
 	t.Helper()
 	for _, name := range names {
 		mdl := `create page ` + mod + `.` + name + ` (
 			Title: '` + name + `',
-			Layout: Atlas_Core.Atlas_Default
+			Layout: Atlas_Core.Atlas_Default,
+			Params: { $WorkflowUserTask: System.WorkflowUserTask }
 		) {
 			layoutgrid g { row r { column c (DesktopWidth: 12) {
 				dynamictext dt (Content: '` + name + `')
@@ -62,13 +67,26 @@ func TestRoundtripWorkflow_Comprehensive(t *testing.T) {
 		t.Fatalf("create WfCtxEntity: %v", err)
 	}
 
+	// Targeting microflows take exactly System.Workflow and the workflow's
+	// context entity and return the candidate users. These took no parameters
+	// and returned a String, which mxbuild refuses as CE6677 (measured on
+	// 11.13.0), and exec now checks the signature.
+	targeting := func(name string) string {
+		return `create microflow ` + mod + `.` + name + ` ($Workflow: System.Workflow, $Context: ` + mod + `.WfCtxEntity)
+returns List of System.User as $Reviewers
+begin
+  retrieve $Reviewers from System.User;
+  return $Reviewers;
+end;`
+	}
+
 	// Microflow: single-user targeting
-	if err := env.executeMDL(`create microflow ` + mod + `.GetSingleReviewer () returns String begin end;`); err != nil {
+	if err := env.executeMDL(targeting("GetSingleReviewer")); err != nil {
 		t.Fatalf("create GetSingleReviewer: %v", err)
 	}
 
 	// Microflow: multi-user targeting
-	if err := env.executeMDL(`create microflow ` + mod + `.GetMultiReviewers () returns String begin end;`); err != nil {
+	if err := env.executeMDL(targeting("GetMultiReviewers")); err != nil {
 		t.Fatalf("create GetMultiReviewers: %v", err)
 	}
 

From 361e96e1e9c15754c141e087dadf0c2eeb385bdc Mon Sep 17 00:00:00 2001
From: Ako <andrej@koelewijn.net>
Date: Mon, 14 Sep 2026 18:53:06 +0000
Subject: [PATCH 7/9] fix(workflow): refuse rewrites that would reset what
 Studio Pro configured
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Measured on a Studio Pro reference workflow (ako/TestApp, Mendix 11.14.0,
0 errors under mxbuild): ALTER WORKFLOW ... REPLACE ACTIVITY with an identical
user task reset the task's on-created microflow (MicroflowBasedEvent ->
NoEvent) while exec reported "Altered workflow". SET ACTIVITY, which edits the
stored document in place, kept it — the control that pins the loss on the
rebuild.

Every rebuild writes a default for what MDL has no spelling for: OnCreatedEvent
= NoEvent, OnWorkflowEvent = an empty list, CompletionCriteria = Consensus on
the first outcome; describe prints an AI agent task only as a comment. None of
it was guarded, so `create or modify` would lose it the same way.

create or modify now refuses a workflow holding any of these, listing every
reason at once — the rule event sub-processes already had — and REPLACE
ACTIVITY refuses an activity holding one (found in the raw unit by name, unique
per CE0495). Consensus falling back to the first outcome is allowed: it is what
the rebuild writes and what the reference stores.

Also counts an event sub-process once: the substring match counted its start
activity too, and the reference's single sub-process was reported as two.

Tests written first and failing; controls for the REPLACE refusal and the
Consensus allowance each fail their cases. On the reference: check
--references and exec refuse the REPLACE with the unit byte-identical, SET
ACTIVITY still works, and create or modify is refused with the full list.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 .../fix-issue/findings/mdl-executor.jsonl     |   1 +
 .../skills/mendix/write-workflows/SKILL.md    |   9 +
 mdl/executor/validate_workflow_refs.go        |   4 +
 mdl/executor/validate_workflow_rewrite.go     | 203 +++++++++++++++++-
 .../validate_workflow_rewrite_test.go         | 184 ++++++++++++++++
 5 files changed, 396 insertions(+), 5 deletions(-)

diff --git a/.claude/skills/fix-issue/findings/mdl-executor.jsonl b/.claude/skills/fix-issue/findings/mdl-executor.jsonl
index d490dadc9..3bbb60a93 100644
--- a/.claude/skills/fix-issue/findings/mdl-executor.jsonl
+++ b/.claude/skills/fix-issue/findings/mdl-executor.jsonl
@@ -613,3 +613,4 @@
 {"area":"mdl-executor","date":"2026-09-14","symptom":"DESCRIBE flattens a microflow whose branches cross into nested ifs that mean something else, and warns MDL-FLOW01 'must not be re-executed' instead of describing it","cause":"Nested if/then/else is single-entry/single-exit. A merge reached by branches of two different splits has no place in a tree, so the describer walked past it and emitted the conjunction along one path.","file":"mdl/executor/cmd_microflows_show_crossed.go","fix":"Mode 2: label the shared-suffix entry AND the split's post-dominator, emit `join <label>` at every branch end, then declare each merge as a top-level section after the traversal. MDL-FLOW01 is retired per decision when the description actually declared the merge.","insight":"Three traps, each of which produced plausible-looking output. (1) A crossed merge must be emitted the OPPOSITE way from an error-rejoin merge -- rejoin is DECLARED where the traversal meets it, crossed is JOINED by each branch and declared once afterwards -- so the label alone cannot drive emission; carry a crossed set beside the names. (2) Emit the join BEFORE the visited guard: arriving twice is what 'crossed' MEANS, and the guard silently swallows the second branch's join, leaving that path falling off the end. (3) Retire a warning on what was EMITTED, not on what was labelled. An inheritance split has its own traversal that walks through a labelled merge without emitting a join, so the label goes unused and the reader still gets the nested rendering -- suppressing on the label alone silenced MDL-FLOW01 on Administration.ManageMyAccount, whose description is byte-identical with and without the feature. That forced warnings to be computed AFTER the body instead of before it. Method: keep a baseline binary (git stash -u; build) and diff `describe` over every microflow in a corpus -- the refactor step should be byte-identical (it was, 18 of 18) and the feature step should change only the microflows it targets (2 of 18). Anything else changing is the bug."}
 {"area": "mdl/executor", "date": "2026-09-13", "symptom": "describe page -> create or replace page broke a button's icon. An icon into an IMAGE collection came back as `Icon: 'DesignSystem.Icons_SVG.edit'` and the build failed [CE1613] \"The selected custom icon 'DesignSystem.Icons_SVG.edit' no longer exists.\" A GLYPH icon produced no describe output at all -- no clause, no comment -- and replay DELETED it at exit 0.", "cause": "Mendix stores three icon elements and two put a qualified name under the same BSON key: Forms$IconCollectionIcon{Image}->CustomIcons$CustomIcon, Forms$ImageIcon{Image}->Images$Image, Forms$GlyphIcon{Code}. extractIconRef read `Image` off whichever element was there and threw the $Type away, and the page builder writes Forms$IconCollectionIcon unconditionally -- so the two named variants were spelled identically on the way out and collapsed into one on the way back in.", "file": "mdl/executor/cmd_pages_describe_output.go (extractButtonIcon, widgetIconMDL, widgetIconNote), mdl/executor/cmd_pages_describe.go (rawWidget.IconType/IconCode), mdl/executor/cmd_pages_describe_parse.go; tests mdl/executor/cmd_pages_describe_icon_test.go", "insight": "The identical three-variant defect was fixed in NAVIGATION eight days earlier (2026-09-05, same area file) and the page path never received it -- so the cheapest possible diagnosis was `grep MenuIconKindOf`, and the fix reuses that resolver rather than adding a second one. **Generalisable: when a fix teaches a layer to distinguish polymorphic variants, grep for every OTHER reader of the same element.** The find was one `git grep Forms\\$ImageIcon` away all along. Two things the report got understandably wrong and that the fix depends on getting right: it is not about third-party vs native collections (a third-party ICON collection round-trips fine -- and CE1613 naming the reference is itself proof the name was never a custom icon, since mxbuild would otherwise have resolved it), and the reported image-icon case is the CHEAPER half -- the glyph case is silent on both sides, so nothing in the output even hints at the loss. **Measure the silence, not the wrong answer**: `grep -c icon` over describe output of a stock marketplace project's FeedbackModule pages returned 0 before and 3 after, which is the only form the glyph bug has. The note has to fire on an UNRECOGNISED $Type too, not a known-bad list, or the next variant Mendix adds is dropped the same way. Controls that matter: an icon-collection icon must still emit a bare `Icon:` and NO note (else the fix passes by flagging everything), and an iconless button must emit neither. No .mdl repro is possible -- mxcli cannot author an image or glyph icon on a button, so the input to the round trip cannot be constructed in MDL; the reproduction is a stored-widget map in the unit test. Also observed in passing and NOT fixed: a nameless `statictext` makes describe output unparseable (pre-existing, confirmed against the base binary), and NavigationList item / DropDownButton icons are never read at all, so they are dropped as silently as the glyph was.", "refs": ["#1059", "#1008", "#602"], "ce": ["CE1613"]}
 {"area": "mdl/executor", "date": "2026-09-13", "symptom": "Follow-on to #1059: a widget's image and glyph icons were readable but unwritable, so describe -> exec could only be made honest (a `-- NOT re-executable` note), not lossless. Authoring them needed the kind to reach the element $Type through grammar, AST, visitor, builder and BOTH engines.", "cause": "Three separate vocabularies for the same three Mendix icon elements: types.MenuIconKind (navigation), pages.IconType (the page model's own three-value enum), and a bare string in the widget property map. The page path had no kind at all, so it could not express one.", "file": "mdl/grammar/domains/MDLPage.g4 (widgetIconV3), mdl/ast/ast_page_v3.go (WidgetIcon), mdl/visitor/visitor_page_v3.go (buildWidgetIconV3), mdl/executor/cmd_pages_builder_v3_widgets.go (buildWidgetIcon), mdl/backend/modelsdk/widget_write.go (iconToGen), sdk/mpr/writer_widgets_display.go (buildWidgetIconBson), mdl/executor/validate_icon_refs.go, mdl/executor/validate_glyph_codes.go", "insight": "**Delete the second vocabulary as part of the fix, not after it.** pages.IconType existed for exactly the same three kinds as types.MenuIconKind and had drifted to a different value set; replacing it (2 call sites) is what made the writers a dispatch rather than an inference. A feature that adds a third copy would have re-created the bug in a new place. **The pre-existing tests of the OLD feature are the safety net for the new one**: MDL078's menu tests caught a python replace of mine that silently no-opped (anchor did not match, no assert), which nothing else would have. Always assert on the replacement count when editing by script. **Measure the premise, don't reason by analogy** — extending MDL078 to widget glyphs assumed mxbuild resolves a widget glyph the same way it resolves a menu one. It does, measured: `Icon: glyph 57562` fails `mxbuild --target=deploy` with `System.InvalidOperationException: Sequence contains no matching element` — but it names the **page**, not a layout, so the rule's own message was wrong and had to be corrected from the measurement. **The reference check had the mirror-image bug waiting**: resolving an image reference against the ICON collections reports a correct name as a typo, which is the same conflation pointed the other way — per-kind resolution plus an `otherKindHint` naming the remedy. **An empty listing is 'could not establish', not 'none'** — each half of the index is independent, so a project that yields icon collections but no image collections still resolves what it can. Verified on 11.13.0: all three authored, mx check 0 errors, deploy BUILD SUCCEEDED, right $Type on disk; controls reproduce CE1613 (image written without `image`) and the glyph build failure. Corpus sweep 531 clean.", "refs": ["#1059", "#1008", "#602"], "ce": ["CE1613"]}
+{"area": "mdl/executor", "date": "2026-09-15", "symptom": "`ALTER WORKFLOW ... REPLACE ACTIVITY userTask1 WITH <identical user task>` reported 'Altered workflow' and reset the task's on-created microflow (Workflows$MicroflowBasedEvent -> NoEvent). A `create or modify` of a workflow with an on-created microflow, workflow event handlers, a non-default multi-user completion rule or an AI agent task would lose them the same way: check, exec and mx check all clean.", "cause": "Both writers rebuild a workflow activity from the AST and write a default for every property MDL has no spelling for: OnCreatedEvent = NoEvent, CompletionCriteria = Consensus on the first outcome, OnWorkflowEvent = empty list; describe prints an AIAgentTaskActivity as a `-- [Workflows$...]` comment. checkNoDroppedWorkflowConstructs guarded only event sub-processes and boundary events.", "fix": "checkNoDroppedWorkflowConstructs collects every inexpressible construct from the raw unit (studioProOnlyWorkflowState / rawActivityState) and refuses the rewrite listing them all; validateAlterReplaceKeepsStudioProState refuses REPLACE ACTIVITY on an activity whose raw document holds one (matched by Name, unique per CE0495). Consensus falling back to the first outcome is not refused — it is what the rebuild writes and what the reference stores.", "file": "mdl/executor/validate_workflow_rewrite.go", "insight": "Guard-don't-drop needs a Studio Pro reference to be anything but a guess: until one existed the risk was code-derived, and the reference both confirmed the loss (REPLACE, measured) and set the exact threshold — its Consensus fallback points at the FIRST outcome, which is what mxcli writes, so refusing every Consensus would have refused every multi-user rewrite. Measure the control on the same document: SET ACTIVITY kept the microflow, which is what proves REPLACE's rebuild is the cause rather than ALTER as a whole. A raw-unit walk of `$Type` strings is also how to guard constructs the semantic model does not carry at all (completion criteria, workflow event handlers)."}
diff --git a/.claude/skills/mendix/write-workflows/SKILL.md b/.claude/skills/mendix/write-workflows/SKILL.md
index df0ec11db..bc27de026 100644
--- a/.claude/skills/mendix/write-workflows/SKILL.md
+++ b/.claude/skills/mendix/write-workflows/SKILL.md
@@ -315,6 +315,15 @@ documented in `system-module`.
 
 ## Platform rules
 
+- **Some workflow state has no MDL spelling, and a rewrite refuses rather than
+  reset it.** An event sub-process, a workflow event handler, an AI agent task, a
+  user task's on-created microflow, and a multi-user task's completion rule other
+  than consensus falling back to its first outcome are set in Studio Pro.
+  `create or modify` on a workflow that holds any of them is refused with the
+  list, and so is `alter workflow … replace activity` on an activity that holds
+  one. Change such a workflow with `alter workflow … set activity …` (it edits
+  the stored document and keeps the rest) or in Studio Pro.
+
 - A user task needs a **task page** to be useful; without one Mendix flags the
   task (`CE1834`). Bind the page to `System.WorkflowUserTask`.
 - A user task / decision with a single outcome and no activity can trip
diff --git a/mdl/executor/validate_workflow_refs.go b/mdl/executor/validate_workflow_refs.go
index 4caf4e850..dedcfe1b1 100644
--- a/mdl/executor/validate_workflow_refs.go
+++ b/mdl/executor/validate_workflow_refs.go
@@ -313,6 +313,10 @@ func validateAlterWorkflowRefs(ctx *ExecContext, s *ast.AlterWorkflowStmt, sc *s
 	// loading. Same function for both passes, so `check --references` and `exec`
 	// cannot drift.
 	errs = append(errs, validateAlterWorkflowActivityKinds(ctx, s)...)
+	// REPLACE ACTIVITY rebuilds the activity from the statement, so state MDL
+	// cannot express — an on-created microflow, a completion rule — would be
+	// reset; refused like the same loss in a whole-workflow rewrite.
+	errs = append(errs, validateAlterReplaceKeepsStudioProState(ctx, s)...)
 
 	return append(errs, validateWorkflowReferences(ctx, added, sc)...)
 }
diff --git a/mdl/executor/validate_workflow_rewrite.go b/mdl/executor/validate_workflow_rewrite.go
index 563c32da6..ec9b80679 100644
--- a/mdl/executor/validate_workflow_rewrite.go
+++ b/mdl/executor/validate_workflow_rewrite.go
@@ -4,6 +4,7 @@ package executor
 
 import (
 	"fmt"
+	"reflect"
 	"sort"
 	"strings"
 
@@ -42,12 +43,23 @@ func checkNoDroppedWorkflowConstructs(ctx *ExecContext, workflowID model.ID, qua
 		return nil
 	}
 
-	if n := countRawWorkflowNodes(raw, "EventSubProcess"); n > 0 {
+	// Constructs MDL cannot express at all. A rebuild writes the default for
+	// each — measured on ako/TestApp (11.14.0): an on-created microflow becomes
+	// NoEvent, workflow event handlers an empty list, a completion rule
+	// Consensus on the first outcome, and describe shows an AI agent task only as
+	// a comment — so a rewrite loses them without a word. Refused outright, like
+	// an event sub-process, and every reason is listed at once.
+	var cannotExpress []string
+	if n := countEventSubProcesses(raw); n > 0 {
+		cannotExpress = append(cannotExpress, fmt.Sprintf("%d event sub-process(es), which it would delete", n))
+	}
+	cannotExpress = append(cannotExpress, studioProOnlyWorkflowState(raw)...)
+	if len(cannotExpress) > 0 {
 		return mdlerrors.NewUnsupported(fmt.Sprintf(
-			"workflow %s has %d event sub-process(es), and MDL cannot express one — "+
-				"rewriting the workflow would delete it.\n"+
-				"  Edit the workflow in Studio Pro, or use ALTER WORKFLOW to change one activity at a time.",
-			qualifiedName, n))
+			"workflow %s holds state MDL cannot express, and rewriting it would delete or reset it silently:\n  - %s\n"+
+				"  Edit the workflow in Studio Pro, or use ALTER WORKFLOW to change one activity at a time — ALTER edits "+
+				"the stored document and keeps what it does not touch.",
+			qualifiedName, strings.Join(cannotExpress, "\n  - ")))
 	}
 
 	storedBE := countRawBoundaryEvents(raw)
@@ -145,3 +157,184 @@ func countAuthoredBoundaryEvents(activities []ast.WorkflowActivityNode) int {
 	})
 	return n
 }
+
+// studioProOnlyWorkflowState lists what a stored workflow holds that a rebuild
+// from MDL would reset: workflow event handlers, AI agent tasks, and per activity
+// an on-created microflow or a completion rule other than the one mxcli writes.
+func studioProOnlyWorkflowState(raw map[string]any) []string {
+	var out []string
+	for _, h := range rawList(raw["OnWorkflowEvent"]) {
+		if hm, ok := h.(map[string]any); ok {
+			microflow := ""
+			if mh, ok := hm["MicroflowEventHandler"].(map[string]any); ok {
+				microflow, _ = mh["Microflow"].(string)
+			}
+			out = append(out, fmt.Sprintf("a workflow event handler running %s, which it would delete", orUnnamed(microflow)))
+		}
+	}
+	walkRawDocs(raw, func(d map[string]any) {
+		if t, _ := d["$Type"].(string); t == "Workflows$AIAgentTaskActivity" {
+			name, _ := d["Name"].(string)
+			out = append(out, fmt.Sprintf("AI agent task '%s', which describe shows only as a comment and it would delete", name))
+			return
+		}
+		out = append(out, rawActivityState(d)...)
+	})
+	return out
+}
+
+// rawActivityState lists what one stored activity holds that rebuilding it would
+// reset. Both the workflow rewrite and REPLACE ACTIVITY ask.
+func rawActivityState(d map[string]any) []string {
+	var out []string
+	name, _ := d["Name"].(string)
+	if ev, ok := d["OnCreatedEvent"].(map[string]any); ok {
+		if t, _ := ev["$Type"].(string); t == "Workflows$MicroflowBasedEvent" {
+			microflow, _ := ev["Microflow"].(string)
+			out = append(out, fmt.Sprintf("user task '%s' runs on-created microflow %s, which it would reset to none", name, orUnnamed(microflow)))
+		}
+	}
+	cc, ok := d["CompletionCriteria"].(map[string]any)
+	if !ok {
+		return out
+	}
+	kind, _ := cc["$Type"].(string)
+	var outcomes []map[string]any
+	for _, o := range rawList(d["Outcomes"]) {
+		if om, ok := o.(map[string]any); ok {
+			outcomes = append(outcomes, om)
+		}
+	}
+	switch kind {
+	case "Workflows$ConsensusCompletionCriteria":
+		// What mxcli writes: Consensus falling back to the first outcome.
+		if len(outcomes) > 0 && reflect.DeepEqual(cc["FallbackOutcomePointer"], outcomes[0]["$ID"]) {
+			return out
+		}
+		fallback := "another outcome"
+		for _, o := range outcomes {
+			if reflect.DeepEqual(cc["FallbackOutcomePointer"], o["$ID"]) {
+				fallback = "outcome '" + rawOutcomeLabel(o) + "'"
+			}
+		}
+		out = append(out, fmt.Sprintf("multi user task '%s' falls back to %s when consensus fails, which it would move to the first outcome", name, fallback))
+	default:
+		rule := strings.ToLower(strings.TrimSuffix(strings.TrimPrefix(kind, "Workflows$"), "CompletionCriteria"))
+		out = append(out, fmt.Sprintf("multi user task '%s' decides by %s, which it would reset to consensus", name, rule))
+	}
+	return out
+}
+
+// validateAlterReplaceKeepsStudioProState refuses REPLACE ACTIVITY on an activity
+// whose stored document holds state the replacement is rebuilt without. Measured
+// on ako/TestApp: replacing a user task with an identical one reset its
+// on-created microflow to NoEvent while exec reported "Altered workflow"; SET
+// ACTIVITY, which edits the stored document in place, kept it.
+func validateAlterReplaceKeepsStudioProState(ctx *ExecContext, s *ast.AlterWorkflowStmt) []string {
+	var replaces []*ast.ReplaceActivityOp
+	for _, op := range s.Operations {
+		if o, ok := op.(*ast.ReplaceActivityOp); ok {
+			replaces = append(replaces, o)
+		}
+	}
+	if len(replaces) == 0 || ctx == nil || ctx.Backend == nil {
+		return nil
+	}
+	wf := findStoredWorkflow(ctx, s.Name)
+	if wf == nil || wf.Flow == nil {
+		return nil
+	}
+	raw, err := ctx.Backend.GetRawUnit(wf.ID)
+	if err != nil || raw == nil {
+		return nil
+	}
+	var errs []string
+	for _, o := range replaces {
+		act := resolveStoredActivity(wf.Flow, o.ActivityRef, o.AtPosition)
+		if act == nil {
+			continue
+		}
+		var reasons []string
+		walkRawDocs(raw, func(d map[string]any) {
+			if n, _ := d["Name"].(string); n != "" && n == act.GetName() {
+				reasons = append(reasons, rawActivityState(d)...)
+			}
+		})
+		if len(reasons) > 0 {
+			errs = append(errs, fmt.Sprintf(
+				"replace activity '%s' is refused: the activity is rebuilt from the statement, and MDL cannot express what it "+
+					"holds — %s. Change it with SET ACTIVITY, which edits it in place, or in Studio Pro.",
+				o.ActivityRef, strings.Join(reasons, "; ")))
+		}
+	}
+	return errs
+}
+
+// walkRawDocs visits every sub-document of a raw unit, keys in sorted order so
+// the reasons come out the same way every time.
+func walkRawDocs(v any, visit func(map[string]any)) {
+	switch t := v.(type) {
+	case map[string]any:
+		visit(t)
+		keys := make([]string, 0, len(t))
+		for k := range t {
+			keys = append(keys, k)
+		}
+		sort.Strings(keys)
+		for _, k := range keys {
+			walkRawDocs(t[k], visit)
+		}
+	case []any:
+		for _, e := range t {
+			walkRawDocs(e, visit)
+		}
+	}
+}
+
+// rawList returns a stored list's elements; a list's first element may be the
+// typed-array marker, which is not a map and is skipped by callers.
+func rawList(v any) []any {
+	if l, ok := v.([]any); ok {
+		return l
+	}
+	return nil
+}
+
+func rawOutcomeLabel(o map[string]any) string {
+	for _, k := range []string{"Value", "Caption", "Name"} {
+		if s, _ := o[k].(string); s != "" {
+			return s
+		}
+	}
+	return "?"
+}
+
+func orUnnamed(s string) string {
+	if s == "" {
+		return "(unnamed)"
+	}
+	return s
+}
+
+// countEventSubProcesses counts a workflow's event sub-processes. The substring
+// match countRawWorkflowNodes uses also counts each one's start activity
+// (…NotificationEventSubProcessStartActivity lives inside it), so the reference
+// workflow's single sub-process was reported as two. The exact type is counted;
+// start activities stand in only when no sub-process document is present, one
+// start per sub-process.
+func countEventSubProcesses(raw map[string]any) int {
+	subProcesses, starts := 0, 0
+	walkRawDocs(raw, func(d map[string]any) {
+		t, _ := d["$Type"].(string)
+		switch {
+		case t == "Workflows$EventSubProcess":
+			subProcesses++
+		case strings.HasSuffix(t, "EventSubProcessStartActivity"):
+			starts++
+		}
+	})
+	if subProcesses > 0 {
+		return subProcesses
+	}
+	return starts
+}
diff --git a/mdl/executor/validate_workflow_rewrite_test.go b/mdl/executor/validate_workflow_rewrite_test.go
index edf5cef61..36843d067 100644
--- a/mdl/executor/validate_workflow_rewrite_test.go
+++ b/mdl/executor/validate_workflow_rewrite_test.go
@@ -3,6 +3,7 @@
 package executor
 
 import (
+	"github.com/mendixlabs/mxcli/sdk/workflows"
 	"strings"
 	"testing"
 
@@ -172,3 +173,186 @@ end workflow;`
 			"should still emit the documented order")
 	}
 }
+
+// rawWorkflowCtx returns a context whose stored workflow unit is exactly raw.
+func rawWorkflowCtx(t *testing.T, raw map[string]any) *ExecContext {
+	t.Helper()
+	mb := &mock.MockBackend{
+		IsConnectedFunc: func() bool { return true },
+		GetRawUnitFunc:  func(model.ID) (map[string]any, error) { return raw, nil },
+	}
+	ctx, _ := newMockCtx(t, withBackend(mb))
+	return ctx
+}
+
+// studioProWorkflow is the shape of ako/TestApp's workflow.Workflow1 (Mendix
+// 11.14.0, 0 errors under mxbuild), reduced to what a rewrite can lose. Each
+// option adds one construct MDL cannot express.
+func studioProWorkflow(onCreated, handler, agentTask bool, criteria string, fallbackFirst bool) map[string]any {
+	onCreatedEvent := map[string]any{"$Type": "Workflows$NoEvent"}
+	if onCreated {
+		onCreatedEvent = map[string]any{"$Type": "Workflows$MicroflowBasedEvent", "Microflow": "workflow.UserTaskEventHandle"}
+	}
+	first := map[string]any{"$ID": "outcome-fast", "$Type": "Workflows$UserTaskOutcome", "Value": "Fast"}
+	second := map[string]any{"$ID": "outcome-furious", "$Type": "Workflows$UserTaskOutcome", "Value": "Furious"}
+	fallback := "outcome-fast"
+	if !fallbackFirst {
+		fallback = "outcome-furious"
+	}
+	activities := []any{
+		3,
+		map[string]any{"$Type": "Workflows$StartWorkflowActivity", "Name": "start1"},
+		map[string]any{"$Type": "Workflows$SingleUserTaskActivity", "Name": "userTask1", "OnCreatedEvent": onCreatedEvent},
+		map[string]any{
+			"$Type":              "Workflows$MultiUserTaskActivity",
+			"Name":               "userTask2",
+			"OnCreatedEvent":     map[string]any{"$Type": "Workflows$NoEvent"},
+			"Outcomes":           []any{3, first, second},
+			"CompletionCriteria": map[string]any{"$Type": "Workflows$" + criteria, "FallbackOutcomePointer": fallback},
+		},
+	}
+	if agentTask {
+		activities = append(activities, map[string]any{"$Type": "Workflows$AIAgentTaskActivity", "Name": "aiAgentTask1", "Microflow": "workflow.InvokeAgent"})
+	}
+	activities = append(activities, map[string]any{"$Type": "Workflows$EndWorkflowActivity", "Name": "end1"})
+	events := []any{2}
+	if handler {
+		events = append(events, map[string]any{
+			"$Type":                 "Workflows$WorkflowEventHandler",
+			"Description":           "OnAnyEvent",
+			"MicroflowEventHandler": map[string]any{"$Type": "Workflows$MicroflowEventHandler", "Microflow": "workflow.WorkflowEventHandle"},
+		})
+	}
+	return map[string]any{
+		"$Type":           "Workflows$Workflow",
+		"Flow":            map[string]any{"$Type": "Workflows$Flow", "Activities": activities},
+		"OnWorkflowEvent": events,
+	}
+}
+
+const wfRewriteTwoTasks = `create or modify workflow M.W parameter $C: M.Ctx
+begin
+  user task userTask1 'User Task' page M.P outcomes 'Good' { } 'Bad' { };
+  multi user task userTask2 'Multi' page M.P outcomes 'Fast' { } 'Furious' { };
+end workflow;`
+
+// Measured on ako/TestApp: every rebuild writes a user task's OnCreatedEvent as
+// NoEvent, a multi-user task's completion criteria as Consensus on its first
+// outcome, OnWorkflowEvent as an empty list, and describe prints an AI agent task
+// only as a comment. MDL can express none of them, so a rewrite that would lose
+// one is refused — the event sub-process rule, applied to the rest.
+func TestWorkflowRewrite_RefusesDroppingStudioProOnlyState(t *testing.T) {
+	cases := []struct {
+		name string
+		raw  map[string]any
+		want string
+	}{
+		{"on-created microflow", studioProWorkflow(true, false, false, "ConsensusCompletionCriteria", true), "workflow.UserTaskEventHandle"},
+		{"workflow event handler", studioProWorkflow(false, true, false, "ConsensusCompletionCriteria", true), "workflow.WorkflowEventHandle"},
+		{"AI agent task", studioProWorkflow(false, false, true, "ConsensusCompletionCriteria", true), "AI agent task"},
+		{"majority completion", studioProWorkflow(false, false, false, "MajorityCompletionCriteria", true), "majority"},
+		{"veto completion", studioProWorkflow(false, false, false, "VetoCompletionCriteria", true), "veto"},
+		{"consensus falling back to another outcome", studioProWorkflow(false, false, false, "ConsensusCompletionCriteria", false), "Furious"},
+	}
+	stmt := parseWorkflowStmt(t, wfRewriteTwoTasks)
+	for _, c := range cases {
+		t.Run(c.name, func(t *testing.T) {
+			err := checkNoDroppedWorkflowConstructs(rawWorkflowCtx(t, c.raw), "wf1", "M.W", stmt)
+			if err == nil || !strings.Contains(err.Error(), c.want) {
+				t.Errorf("rewrite must be refused naming %q, got %v", c.want, err)
+			}
+		})
+	}
+}
+
+// The controls: what mxcli writes anyway — NoEvent, no handlers, no agent task,
+// Consensus falling back to the first outcome — must not be refused, or every
+// rewrite of every multi-user workflow would be.
+func TestWorkflowRewrite_AllowsWhatARebuildReproduces(t *testing.T) {
+	stmt := parseWorkflowStmt(t, wfRewriteTwoTasks)
+	raw := studioProWorkflow(false, false, false, "ConsensusCompletionCriteria", true)
+	if err := checkNoDroppedWorkflowConstructs(rawWorkflowCtx(t, raw), "wf1", "M.W", stmt); err != nil {
+		t.Fatalf("a rewrite that loses nothing must be allowed, got %v", err)
+	}
+}
+
+// storedReplaceCtx is a project holding M.W: the semantic workflow ALTER resolves
+// its target against, and the raw unit the REPLACE refusal reads.
+func storedReplaceCtx(t *testing.T, raw map[string]any) *ExecContext {
+	t.Helper()
+	single := &workflows.UserTask{}
+	single.Name = "userTask1"
+	multi := &workflows.UserTask{IsMulti: true}
+	multi.Name = "userTask2"
+	wf := &workflows.Workflow{Name: "W", Flow: &workflows.Flow{Activities: []workflows.WorkflowActivity{single, multi}}}
+	wf.ID = "wf1"
+	wf.ContainerID = "mod1"
+	mod := &model.Module{Name: "M"}
+	mod.ID = "mod1"
+	mb := &mock.MockBackend{
+		IsConnectedFunc:   func() bool { return true },
+		ListModulesFunc:   func() ([]*model.Module, error) { return []*model.Module{mod}, nil },
+		ListWorkflowsFunc: func() ([]*workflows.Workflow, error) { return []*workflows.Workflow{wf}, nil },
+		GetRawUnitFunc:    func(model.ID) (map[string]any, error) { return raw, nil },
+	}
+	ctx, _ := newMockCtx(t, withBackend(mb))
+	return ctx
+}
+
+// Measured on ako/TestApp: REPLACE ACTIVITY with an identical user task reset its
+// on-created microflow to NoEvent while exec reported "Altered workflow".
+func TestAlterWorkflow_ReplaceRefusesToResetStudioProState(t *testing.T) {
+	replaceTask := func(name string) *ast.AlterWorkflowStmt {
+		prog, errs := visitor.Build(`alter workflow M.W replace activity ` + name + ` with user task ` + name + ` 'Task' page M.P outcomes 'Fast' { } 'Furious' { };`)
+		if len(errs) > 0 {
+			t.Fatalf("parse errors: %v", errs)
+		}
+		return prog.Statements[0].(*ast.AlterWorkflowStmt)
+	}
+	cases := []struct {
+		name, target string
+		raw          map[string]any
+		want         string // "" = allowed
+	}{
+		{"on-created microflow", "userTask1", studioProWorkflow(true, false, false, "ConsensusCompletionCriteria", true), "workflow.UserTaskEventHandle"},
+		{"majority rule", "userTask2", studioProWorkflow(false, false, false, "MajorityCompletionCriteria", true), "majority"},
+		// Controls: the same replacements where the stored activity holds only
+		// what a rebuild writes anyway.
+		{"plain user task", "userTask1", studioProWorkflow(false, false, false, "ConsensusCompletionCriteria", true), ""},
+		{"consensus on the first outcome", "userTask2", studioProWorkflow(false, false, false, "ConsensusCompletionCriteria", true), ""},
+		// A workflow-level handler is not the replaced activity's to lose.
+		{"handler elsewhere in the workflow", "userTask1", studioProWorkflow(false, true, false, "ConsensusCompletionCriteria", true), ""},
+	}
+	for _, c := range cases {
+		t.Run(c.name, func(t *testing.T) {
+			got := validateAlterReplaceKeepsStudioProState(storedReplaceCtx(t, c.raw), replaceTask(c.target))
+			switch {
+			case c.want == "" && len(got) > 0:
+				t.Errorf("must be allowed, got %v", got)
+			case c.want != "" && (len(got) != 1 || !strings.Contains(got[0], c.want)):
+				t.Errorf("must be refused naming %q, got %v", c.want, got)
+			}
+		})
+	}
+}
+
+// The reference workflow has ONE event sub-process, whose flow starts with an
+// InterruptingNotificationEventSubProcessStartActivity. A substring count of
+// "EventSubProcess" matched both and reported two.
+func TestWorkflowRewrite_CountsAnEventSubProcessOnce(t *testing.T) {
+	raw := map[string]any{
+		"$Type": "Workflows$Workflow",
+		"EventSubProcesses": []any{2, map[string]any{
+			"$Type": "Workflows$EventSubProcess",
+			"Name":  "eventSubProcess1",
+			"Flow": map[string]any{"$Type": "Workflows$Flow", "Activities": []any{3,
+				map[string]any{"$Type": "Workflows$InterruptingNotificationEventSubProcessStartActivity", "Name": "start"},
+				map[string]any{"$Type": "Workflows$EndWorkflowActivity", "Name": "end2"},
+			}},
+		}},
+	}
+	err := checkNoDroppedWorkflowConstructs(rawWorkflowCtx(t, raw), "wf1", "M.W", parseWorkflowStmt(t, wfRewriteTwoTasks))
+	if err == nil || !strings.Contains(err.Error(), "1 event sub-process") {
+		t.Fatalf("expected one event sub-process to be reported, got %v", err)
+	}
+}

From 2e5a06da8951806de21099ea30cd8beef803b5b4 Mon Sep 17 00:00:00 2001
From: Ako <andrej@koelewijn.net>
Date: Mon, 14 Sep 2026 18:53:06 +0000
Subject: [PATCH 8/9] fix(workflow): describe boundary events on a wait for
 notification, and let them re-parse
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Two defects behind one round trip.

The default engine read a wait for notification's boundary events as absent:
workflowActivityFromGen had no typed case for it, so it fell to the untyped
path, which reads only name and caption. Describe dropped every timer and its
handler flow while the legacy engine described them. Gen has had
WaitForNotificationActivity with BoundaryEventsItems() for some time; the
fallback's comment ("no genWf struct") had gone stale.

And describe output with two boundary events did not parse on either engine:
describe writes `boundary event …` before each event, as the syntax topic
documents, but the grammar took the keyword once and then all clauses
(`mismatched input 'boundary' expecting ';'`). The grammar now accepts the
keyword per clause and still accepts the shared form.

The second was found because the first round trip was vacuous: it diffed two
describes around an exec that had died on the parse error, and the second
describe read the unchanged document. The integration round trips have the
same blind spot — they never re-parse describe output — so a test that does
(TestWorkflowDescribe_TwoBoundaryEventsReparse) is added.

Verified: tests written first and failing; on an 11.13 app the fixture execs
and builds, both engines describe both boundary clauses, and the describe
output re-executes with 0 parse errors and describes identically afterwards.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 .../fix-issue/findings/mdl-backend.jsonl      |  1 +
 .../fix-issue/findings/mdl-grammar.jsonl      |  1 +
 ...orkflow-wait-for-notification-boundary.mdl | 59 +++++++++++++++++++
 .../modelsdk/workflow_boundary_read_test.go   | 41 +++++++++++++
 mdl/backend/modelsdk/workflow_read.go         | 11 ++++
 mdl/executor/cmd_workflows_describe_test.go   | 41 +++++++++++++
 mdl/grammar/domains/MDLWorkflow.g4            | 15 +++--
 mdl/visitor/visitor_workflow_test.go          | 52 ++++++++++++++++
 8 files changed, 217 insertions(+), 4 deletions(-)
 create mode 100644 mdl-examples/bug-tests/workflow-wait-for-notification-boundary.mdl

diff --git a/.claude/skills/fix-issue/findings/mdl-backend.jsonl b/.claude/skills/fix-issue/findings/mdl-backend.jsonl
index c213aee76..71727447b 100644
--- a/.claude/skills/fix-issue/findings/mdl-backend.jsonl
+++ b/.claude/skills/fix-issue/findings/mdl-backend.jsonl
@@ -94,3 +94,4 @@
 {"area": "mdl/backend", "date": "2026-09-12", "symptom": "Four plain widget keywords were refused by the DEFAULT engine with \"widget *pages.X not yet supported by the modelsdk engine — rerun with MXCLI_ENGINE=legacy\": statictext, dropdown, staticimage, dynamicimage (plus NanoflowSource as a list data source). Nothing in mdl-examples/ or in any skill used those keywords, so the doctype gate ran green the whole time. Then, closing the gap: `statictext` on EITHER engine produced a project that could not be loaded at all — `mx check` aborts with TypeCacheUnknownTypeException for Forms$Text before running any validation, and Studio Pro fails the same way", "cause": "Two unrelated things. (1) The modelsdk widget dispatch simply had no case arms for those five types — reachable set measured at five, not the twenty-three a name scan suggests: nineteen pages.* widget structs are constructed by nothing, and EntityPathSource / ShowHomePageClientAction are written by NEITHER engine, so their fallback named a path legacy could not take either. (2) `Forms$Text` is not a Mendix type. It is absent from modelsdk/gen, from generated/metamodel, and from all 3,257 Studio Pro Texts$Text holders in ako/TestApp; `buildTextWidgetV3` minted it for both `text` and `statictext`. Writing it is worse than a build error — the project is unopenable and unfixable in the modeler", "file": "`mdl/backend/modelsdk/widget_write_legacy_gaps.go` (new), `mdl/backend/modelsdk/widget_write.go`, `sdk/mpr/writer_widgets_display.go`, `mdl/executor/validate_widget_retired.go` (new), `mdl/executor/cmd_pages_builder_v3_widgets.go`", "insight": "**\"Parity with the other engine\" is the wrong bar until you have checked whether the other engine is right.** That was the starting assumption here and measuring overturned it: ako/TestApp carries three Studio-Pro-authored Forms$StaticImageViewer widgets (FeedbackModule) and legacy disagreed with all three — it omitted AlternativeText (non-omitempty in generated/metamodel) and wrote BSON null for the unset Image. Legacy's dynamic image was worse: a hand-rolled AlternativeText carrying a FallbackValue key that Forms$ClientTemplate does not have, four lines after a comment in the SHARED serializer saying exactly that (\"Must be Fallback object, not FallbackValue string\"). sdk/mpr was corrected to match rather than pinned as truth. **Look for a Studio Pro reference inside the fixture before concluding there is none** — `bson.Unmarshal` every mprcontents unit and count instances of the $Type; the marketplace modules a blank app ships are Studio Pro output. The same 40-line scanner settles value-shape questions no doc answers: measured 0 nulls against 4,400+ empty strings for by-name references, so an unset QualifiedName is \"\", never null; and marker 3 in 3,257 of 3,257 Texts$Text lists, so legacy's marker 2 for a non-empty one is the wrong side of that divergence, not modelsdk's 3. **A widget keyword the example corpus never uses is a keyword nothing tests**, whatever the coverage numbers say. **Check that the project still LOADS, not just that it builds** — a load failure aborts `mx check` before the error list, so grepping for CE-codes finds nothing and reads like success", "refs": []}
 {"area": "mdl/backend", "date": "2026-09-12", "symptom": "The modelsdk (default) engine leaves 19 of FullBackend's 276 methods to the errUnimplemented stub, which tells the user to \"rerun with MXCLI_ENGINE=legacy\" — the engine being retired. Nineteen unported methods reads as nineteen reasons legacy has to stay shipped and tested", "cause": "Seventeen of the nineteen cannot be reached at all: they are interface surface that only the MPR backend's own delegation and callers holding a concrete *mpr.Reader / *mpr.Writer (api/, examples/, cmd/mxcli commands that open a reader directly) ever touch, so the stub can never fire. The two that ARE reachable — GetRawUnitByName and ParseMicroflowBSON, four call sites in mdl/executor/cmd_microflows_builder.go — were invisible because each is a fast path with a working slow-path fallback: the stub errored, the code fell through to an O(n) module walk, and the result was identical", "file": "`mdl/backend/modelsdk/raw_lookup.go` (new), `mdl/backend/modelsdk/unimplemented_reachability_test.go` (new), `scripts/backend-reachability.sh` (new)", "insight": "**Grep cannot answer \"is this interface method reachable\" and the compiler can.** `b.reader.GetRawUnitByName(...)` inside the MPR backend and `ctx.Backend.GetRawUnitByName(...)` in the executor are indistinguishable to a regex, and receiver names vary, so a grep-based count said all nineteen had callers. Deleting one method from its interface at a time and rebuilding gives a yes/no per method with no judgement involved: 17 DEAD, 2 LIVE. Slow (one `go build ./...` each, minutes for the set) but decisive — script it, commit it, and pin its OUTPUT in a test rather than re-running it in CI. **A fallback hides an unimplemented method completely.** Nothing was broken and no test failed, because the fast path's failure was indistinguishable from a cache miss; the only symptom was work being done twice. Look for `if x, err := …; err == nil` fast paths when auditing what an engine cannot do. **Measure the speedup before claiming one**: restoring the fast path made no measurable difference (620ms vs 608ms over three runs on a 138-microflow project, within noise), because `mxcli exec` runs `check` first and check's own helpers load ListMicroflows anyway — so the cache the slow path builds is already warm. The value here is the removal of the errUnimplemented cliff, not speed", "refs": []}
 {"area": "mdl/backend", "date": "2026-09-11", "symptom": "`ALTER PAGE REPLACE`/`INSERT` inside a data view bound `datasource: selection <list>` re-scopes the new widget's attribute binding to the OUTER data view's entity (**CE1613** \"The selected attribute 'Mod.Outer.Attr' no longer exists\"), and inside a Gallery/DataGrid 2 sourced by a **microflow/nanoflow** drops it entirely (**CE0402** \"No value specified\", `describe` shows `ContentParams: [{1} = <unbound>]`). `mxcli check --references` and `exec` both report success; `CREATE PAGE` binds the same widget in the same position correctly", "cause": "The mutator resolved a widget's scope in TWO walks that each knew a different subset of the ten Forms$*Source kinds. `Forms$ListenTargetSource` carries no EntityRef at all \u2014 only the listen target's NAME \u2014 so the entity walk saw no source on the selection data view and left the context at the enclosing one. The flow walk (`findNearestDataSourceDoc`) read only a widget's TOP-LEVEL `DataSource` key, so a pluggable list \u2014 whose source sits at `Object.Properties[datasource].Value.DataSource` \u2014 contributed nothing, and its `Objects[].Properties[].Value.Widgets` descent (the one the entity walk gained in #935) was missing too", "file": "`mdl/backend/pagemutator/mutator.go` (`resolveSourceScope`/`resolveSourceScopeVia`, `listenTargetDataSource`, `widgetOwnDataSourceDoc`, `pluggableDataSourceDoc`; `EnclosingEntity`/`EnclosingEntityForChildren`/`EnclosingDataSourceFlow` now share the one walk `findNearestDataSourceDoc`, and `findEnclosingEntityContext` + its two helpers are deleted)", "insight": "**Count the source kinds before fixing one.** `generated/metamodel/types.go`'s `DataSource is implemented by` list closes the set at ten, and they divide exactly three ways \u2014 seven carry an EntityRef, two are flows, one (ListenTarget) borrows the scope of the widget it names \u2014 so one resolver can be complete, where three successive per-kind patches (FINDINGS #55 association+flow, #935 pluggable, this one) each left a hole. **A nearer source that resolves to no entity must SHADOW the outer one**: inheriting is what wrote the wrong entity, and it also mis-scoped a flow-sourced list nested in an entity-bound data view \u2014 a case the report did not name and the old code got wrong. The listen target is found by a shape-independent search for \"a document with this Name that has a data source\", which is what makes it work when the target is a pluggable widget keeping its source three levels inside its Object; a visited-set guards a hand-written listen cycle. **Measurement trap: a CE1613 SUPPRESSES the CE0402s in the same `mx check` run** \u2014 the first reading said mxbuild tolerated the unbound parameter, and the CE0402s only appeared once the re-scoped binding was fixed, so count bindings in `describe`, not errors. The issue's own second repro (a Gallery over a DATABASE source) no longer reproduced \u2014 #935 had fixed it \u2014 and the live defect was its flow-sourced variant, so re-measure a report against main before trusting its class. Tests `mdl/backend/pagemutator/mutator_selection_source_test.go` (7, incl. dangling/cyclic listen targets and the shadowing control); repro `mdl-examples/bug-tests/1076-alter-page-selection-and-flow-scope.mdl` \u2014 2 \u00d7 CE1613 + 3 unbound before, 0 errors after, on mxbuild 11.10.0. Each half proven load-bearing by stubbing it alone and rebuilding the CLI", "refs": ["mendixlabs/mxcli#1076", "#55", "#935"], "ce": ["CE0402", "CE1613"]}
+{"area": "mdl/backend", "date": "2026-09-15", "symptom": "On the default engine, `describe workflow` printed `wait for notification x;` without its boundary events (and their handler flows); the legacy engine described them. A describe -> exec round trip lost them.", "cause": "workflowActivityFromGen's typed switch had no case for *genWf.WaitForNotificationActivity, so it fell to workflowSimpleActivityFromGen, which reads only Name and Caption from raw BSON. That path's comment said the wait activities 'have no genWf struct' — true once, stale by the time gen gained WaitForNotificationActivity with BoundaryEventsItems().", "fix": "Typed case reading boundaryEventsFromGen(a.BoundaryEventsItems()), like the five other activities that carry boundary events.", "file": "mdl/backend/modelsdk/workflow_read.go", "insight": "A fallback path documented as 'for types gen does not model' silently keeps catching a type after gen starts modelling it; the reader then under-reads without any error. When gen is re-vendored, grep the typed switches for types that newly have structs. The bug surfaced only because a probe described what it had just written — reading back your own write, per activity type, is the cheap check."}
diff --git a/.claude/skills/fix-issue/findings/mdl-grammar.jsonl b/.claude/skills/fix-issue/findings/mdl-grammar.jsonl
index 8a67e077f..6c570cbd9 100644
--- a/.claude/skills/fix-issue/findings/mdl-grammar.jsonl
+++ b/.claude/skills/fix-issue/findings/mdl-grammar.jsonl
@@ -55,3 +55,4 @@
 {"area": "mdl/grammar", "date": "2026-09-05", "symptom": "After adding a generic (IDENTIFIER | keyword) alternative to widgetTypeV3, `slot body` parsed as a widget of type `slot` and `placeholder Main { ... }` as a widget named Main. Both still parsed, `mxcli check` still exited 0, and a diff of check output across all 515 mdl-examples scripts showed ZERO difference.", "cause": "pageBodyV3 listed widgetV3 FIRST, before useFragmentRef / placeholderBlockV3 / slotMarkerV3. SLOT, PLACEHOLDER and USE are all inside the `keyword` rule (655 tokens), so the generic widget alternative matched them before the specific alternative could.", "file": "mdl/grammar/domains/MDLPage.g4", "insight": "Put the specific alternatives BEFORE widgetV3 in pageBodyV3, the same ordering fix widgetV3 already applies internally for `template for`. The transferable lesson is about the MEASUREMENT, not the grammar: a corpus diff of `mxcli check` output compares DIAGNOSTICS, so it is blind to a construct that parses into the wrong AST shape. 515 scripts said nothing; two visitor unit tests caught it immediately. When a grammar change could reinterpret existing syntax rather than reject it, assert on the AST, not on the diagnostics. CONTROL: reorder pageBodyV3 back and TestSpecificPageBodyFormsWinOverTheGenericWidget / TestSlotMarkerWinsOverTheGenericWidget fail.", "issue": "mendixlabs/mxcli#1036"}
 {"area": "mdl/grammar", "date": "2026-09-07", "symptom": "`drop demo user` and `drop user role` had no idempotent form, so a one-time cleanup either broke every later run of its slice script or had to be commented out (ako/CapTrackV4 R5, 024).", "cause": "Neither statement accepted IF EXISTS, though the grammar already had an ifExists rule used by ALTER ENTITY's DROP ATTRIBUTE / DROP INDEX / DROP VALUE. Added `ifExists?` to both statements, an IfExists field to each AST node, and a skip-with-message branch in each handler.", "file": "`mdl/grammar/domains/MDLSecurity.g4`; `mdl/ast/ast_security.go`; `mdl/visitor/visitor_security.go`; `mdl/executor/cmd_security_write.go`; tests `mdl/visitor/drop_if_exists_test.go`; example `mdl-examples/bug-tests/drop-security-if-exists.mdl`", "insight": "The check that finds this whole class is one loop — `for f in $(ls mdlsource/*.mdl | sort); do mxcli exec \"$f\" -p app.mpr; done` — which is exactly what a fresh clone does and what nobody runs. It found five non-idempotent statement forms in the reporting project; four already had a `create or modify` spelling, and the two with no idempotent form at all are the ones that ended up commented out. When adding a DROP statement, check whether the grammar's existing ifExists rule should apply rather than deciding idempotence is the author's problem."}
 {"area": "mdl/grammar", "date": "2026-09-08", "symptom": "Adding lexer tokens for a new feature broke an unrelated, previously-passing MDL example: `editable: never` on a list view stopped parsing after NEVER became a keyword", "cause": "A new lexer token steals every existing use of that word as an identifier or property value unless it is also added to the `keyword` rule in MDLSettings.g4. NEVER, ONLINE, SYNC and PRESERVE were added for offline sync; NEVER was already a real page property value", "file": "`mdl/grammar/domains/MDLSettings.g4` (keyword rule)", "insight": "Before adding a lexer token, grep the examples for that word as a value or name — the collision is with EXISTING scripts, so nothing in the new feature's own tests can find it. TestKeywordRuleCoverage catches the omission but only asserts the rule LISTS the token; add a test that the word still parses as an identifier, which is the property that actually matters. Here the two failures had one cause: the coverage test named the tokens and check-mdl named the victim file, and the file name (maint2-editable-never-create-page.mdl) said which word", "refs": ["PROPOSAL_offline_sync_configuration.md"]}
+{"area": "mdl/grammar", "date": "2026-09-15", "symptom": "Re-executing `describe workflow` output failed with `mismatched input 'boundary' expecting ';'` for any user task, call microflow or wait for notification that has two or more boundary events.", "cause": "formatBoundaryEvents emits `boundary event <kind> timer '…' { … }` per event (boundaryEventKeyword includes the prefix), and the syntax topic documents that per-clause form, but MDLWorkflow.g4 had `(BOUNDARY EVENT workflowBoundaryEventClause+)?` — one keyword, then clauses.", "fix": "All four sites accept `(BOUNDARY EVENT workflowBoundaryEventClause ((BOUNDARY EVENT)? workflowBoundaryEventClause)*)?`, so both the per-clause and the shared form parse; the visitor is unchanged.", "file": "mdl/grammar/domains/MDLWorkflow.g4", "insight": "A round trip that ends in `diff describe-1 describe-2` is vacuous when the exec in between fails: the second describe reads the unchanged document and matches. It reported IDENTICAL here while the exec had died on a parse error that a grep filter hid. Assert the exec itself — zero parse errors and a rewrite verb — before diffing. The integration round-trip tests had the same blind spot: they compare describe output but never feed it back to the parser, so a grammar/describer disagreement on a construct with more than one instance could not be seen. A test that re-parses describe output (TestWorkflowDescribe_TwoBoundaryEventsReparse) is the cheap guard."}
diff --git a/mdl-examples/bug-tests/workflow-wait-for-notification-boundary.mdl b/mdl-examples/bug-tests/workflow-wait-for-notification-boundary.mdl
new file mode 100644
index 000000000..4625f7b75
--- /dev/null
+++ b/mdl-examples/bug-tests/workflow-wait-for-notification-boundary.mdl
@@ -0,0 +1,59 @@
+-- describe dropped the boundary events of a wait for notification on the default
+-- engine.
+--
+-- Symptom: `describe workflow` printed `wait for notification awaitReply;`
+-- without its timers — and without the handler flow inside each — while the
+-- legacy engine (MXCLI_ENGINE=legacy) described them. A describe -> exec round
+-- trip therefore lost them.
+--
+-- Root cause: the default engine's reader (mdl/backend/modelsdk/workflow_read.go)
+-- had no typed case for WaitForNotificationActivity, so it went through the path
+-- for untyped activities, which reads only the name and caption.
+--
+-- Both engines WRITE these events and mxbuild accepts them (measured on 11.13.0:
+-- interrupting and non-interrupting timers on a wait for notification).
+--
+-- Verify:
+--   mxcli exec mdl-examples/bug-tests/workflow-wait-for-notification-boundary.mdl -p app.mpr
+--   mxcli -p app.mpr -c "describe workflow WFWN.AwaitReply"
+--   Expect both `boundary event` clauses under `wait for notification awaitReply`.
+
+create module WFWN;
+
+create persistent entity WFWN.Request ( Title: string(100) );
+/
+
+create page WFWN.TaskPage (
+  title: 'Task',
+  layout: Atlas_Core.Atlas_Default,
+  params: { $WorkflowUserTask: System.WorkflowUserTask }
+) {
+  layoutgrid g1 { row r1 { column c1 (desktopwidth: 12) { dynamictext t1 (content: 'Task') } } }
+}
+/
+
+create workflow WFWN.AwaitReply
+  parameter $Request: WFWN.Request
+begin
+  user task Ask 'Ask the requester'
+    page WFWN.TaskPage
+    outcomes 'Sent' { } 'Cancelled' { };
+
+  wait for notification awaitReply
+    -- `boundary event` before each clause — the form describe emits. The
+    -- grammar used to take the keyword once, so describe -> exec of this
+    -- activity failed to parse; both forms parse now.
+    boundary event interrupting timer 'addDays([%CurrentDateTime%], 5)' {
+      jump to Ask;
+    }
+    boundary event non interrupting timer 'addDays([%CurrentDateTime%], 2)' {
+      user task Remind 'Send a reminder'
+        page WFWN.TaskPage
+        outcomes 'Done' { } 'Skip' { };
+    };
+
+  user task Handle 'Handle the reply'
+    page WFWN.TaskPage
+    outcomes 'Done' { } 'Reject' { };
+end workflow;
+/
diff --git a/mdl/backend/modelsdk/workflow_boundary_read_test.go b/mdl/backend/modelsdk/workflow_boundary_read_test.go
index a49ce2266..f94909dae 100644
--- a/mdl/backend/modelsdk/workflow_boundary_read_test.go
+++ b/mdl/backend/modelsdk/workflow_boundary_read_test.go
@@ -150,3 +150,44 @@ func TestWorkflowRead_UserTaskBoundaryEvents(t *testing.T) {
 		t.Errorf("TimerDelay = %q, want ${PT1H}", got)
 	}
 }
+
+// A wait for notification carries boundary events too, and the default engine
+// read them as absent: the typed reader switch had no case for it, so it fell
+// through to the untyped "simple" path, which sets only the name and caption.
+// DESCRIBE printed `wait for notification x;` with its timers — and any `end
+// workflow` inside them — gone, while the legacy engine described them.
+// Measured on 11.13.0: both engines write them and mxbuild accepts them.
+func TestWorkflowRead_WaitForNotificationBoundaryEvents(t *testing.T) {
+	end := &workflows.EndWorkflowActivity{}
+	end.Name, end.Caption = "End2", "NoReply"
+	wait := &workflows.WaitForNotificationActivity{}
+	wait.Name, wait.Caption = "notify1", "Wait for reply"
+	wait.BoundaryEvents = []*workflows.BoundaryEvent{
+		{
+			EventType:  "InterruptingTimer",
+			TimerDelay: "addDays([%CurrentDateTime%], 3)",
+			Flow:       &workflows.Flow{Activities: []workflows.WorkflowActivity{end}},
+		},
+		{
+			EventType:  "NonInterruptingTimer",
+			TimerDelay: "addDays([%CurrentDateTime%], 1)",
+		},
+	}
+
+	rt, ok := roundTripWorkflowActivity(t, wait).(*workflows.WaitForNotificationActivity)
+	if !ok {
+		t.Fatalf("round-tripped to %T, want *workflows.WaitForNotificationActivity", roundTripWorkflowActivity(t, wait))
+	}
+	if rt.Name != "notify1" || rt.Caption != "Wait for reply" {
+		t.Errorf("name/caption = %q/%q, want notify1/Wait for reply", rt.Name, rt.Caption)
+	}
+	if len(rt.BoundaryEvents) != 2 {
+		t.Fatalf("boundary events after round trip = %d, want 2 (the reader dropped them)", len(rt.BoundaryEvents))
+	}
+	if rt.BoundaryEvents[0].EventType != "InterruptingTimer" || rt.BoundaryEvents[1].EventType != "NonInterruptingTimer" {
+		t.Errorf("event types = %q, %q", rt.BoundaryEvents[0].EventType, rt.BoundaryEvents[1].EventType)
+	}
+	if f := rt.BoundaryEvents[0].Flow; f == nil || len(f.Activities) == 0 {
+		t.Errorf("the interrupting event's handler flow (with its End) was lost")
+	}
+}
diff --git a/mdl/backend/modelsdk/workflow_read.go b/mdl/backend/modelsdk/workflow_read.go
index 4f19ca03c..ac5fdc279 100644
--- a/mdl/backend/modelsdk/workflow_read.go
+++ b/mdl/backend/modelsdk/workflow_read.go
@@ -158,6 +158,17 @@ func workflowActivityFromGen(el element.Element) workflows.WorkflowActivity {
 			}
 		}
 		return t
+	case *genWf.WaitForNotificationActivity:
+		// A wait for notification carries boundary events, like a user task or a
+		// call microflow. It had no case here, so it went through
+		// workflowSimpleActivityFromGen, which reads only the name and caption:
+		// describe printed it with every timer — and any `end workflow` inside
+		// one — gone, while the legacy engine read them. Measured on 11.13.0,
+		// both engines write them and mxbuild accepts them.
+		t := &workflows.WaitForNotificationActivity{}
+		setWfBase(&t.BaseWorkflowActivity, a.ID(), a.Name(), a.Caption(), a.Annotation(), "Workflows$WaitForNotificationActivity")
+		t.BoundaryEvents = boundaryEventsFromGen(a.BoundaryEventsItems())
+		return t
 	default:
 		return workflowSimpleActivityFromGen(el)
 	}
diff --git a/mdl/executor/cmd_workflows_describe_test.go b/mdl/executor/cmd_workflows_describe_test.go
index 6061ec072..512a12937 100644
--- a/mdl/executor/cmd_workflows_describe_test.go
+++ b/mdl/executor/cmd_workflows_describe_test.go
@@ -3,6 +3,8 @@
 package executor
 
 import (
+	"github.com/mendixlabs/mxcli/mdl/ast"
+	"github.com/mendixlabs/mxcli/mdl/visitor"
 	"strings"
 	"testing"
 
@@ -298,3 +300,42 @@ func TestContextExprNormalizer_AliasesDeclaredParameterName(t *testing.T) {
 		})
 	}
 }
+
+// Describe output must re-parse with every boundary event intact. The integration
+// round trips compare describe output but never feed it back, which is how an
+// activity with two boundary events described into MDL that did not parse.
+func TestWorkflowDescribe_TwoBoundaryEventsReparse(t *testing.T) {
+	events := func() []*workflows.BoundaryEvent {
+		return []*workflows.BoundaryEvent{
+			{EventType: "InterruptingTimer", TimerDelay: "addDays([%CurrentDateTime%], 3)"},
+			{EventType: "NonInterruptingTimer", TimerDelay: "addDays([%CurrentDateTime%], 1)"},
+		}
+	}
+	task := &workflows.UserTask{Page: "M.P", Outcomes: []*workflows.UserTaskOutcome{{Value: "Ok"}, {Value: "No"}}}
+	task.Name, task.Caption = "T", "Task"
+	task.BoundaryEvents = events()
+	wait := &workflows.WaitForNotificationActivity{}
+	wait.Name, wait.Caption = "w1", "Wait"
+	wait.BoundaryEvents = events()
+
+	for name, act := range map[string]workflows.WorkflowActivity{"user task": task, "wait for notification": wait} {
+		t.Run(name, func(t *testing.T) {
+			body := strings.Join(formatSingleActivity(act, "  "), "\n")
+			src := "create workflow M.W parameter $C: M.E\nbegin\n" + body + "\nend workflow;"
+			prog, errs := visitor.Build(src)
+			if len(errs) > 0 {
+				t.Fatalf("describe output does not parse: %v\n%s", errs, src)
+			}
+			var n int
+			switch a := prog.Statements[0].(*ast.CreateWorkflowStmt).Activities[0].(type) {
+			case *ast.WorkflowUserTaskNode:
+				n = len(a.BoundaryEvents)
+			case *ast.WorkflowWaitForNotificationNode:
+				n = len(a.BoundaryEvents)
+			}
+			if n != 2 {
+				t.Errorf("boundary events after re-parse = %d, want 2\n%s", n, src)
+			}
+		})
+	}
+}
diff --git a/mdl/grammar/domains/MDLWorkflow.g4 b/mdl/grammar/domains/MDLWorkflow.g4
index 1904ab35a..f16698f21 100644
--- a/mdl/grammar/domains/MDLWorkflow.g4
+++ b/mdl/grammar/domains/MDLWorkflow.g4
@@ -61,7 +61,7 @@ workflowUserTaskStmt
       (DUE DATE_TYPE STRING_LITERAL)?
       (DESCRIPTION STRING_LITERAL)?
       (OUTCOMES workflowUserTaskOutcome+)?
-      (BOUNDARY EVENT workflowBoundaryEventClause+)?
+      (BOUNDARY EVENT workflowBoundaryEventClause ((BOUNDARY EVENT)? workflowBoundaryEventClause)*)?
     | MULTI USER TASK (IDENTIFIER | QUOTED_IDENTIFIER) STRING_LITERAL
       (PAGE qualifiedName)?
       (TARGETING (USERS | GROUPS)? MICROFLOW qualifiedName)?
@@ -70,9 +70,16 @@ workflowUserTaskStmt
       (DUE DATE_TYPE STRING_LITERAL)?
       (DESCRIPTION STRING_LITERAL)?
       (OUTCOMES workflowUserTaskOutcome+)?
-      (BOUNDARY EVENT workflowBoundaryEventClause+)?
+      (BOUNDARY EVENT workflowBoundaryEventClause ((BOUNDARY EVENT)? workflowBoundaryEventClause)*)?
     ;
 
+/**
+ * One boundary event. An activity's clauses may each repeat `boundary event`
+ * (the form describe emits and the syntax topic documents) or share one
+ * (`boundary event interrupting timer '…' non interrupting timer '…'`). The
+ * grammar accepted only the shared form, so the describe output of an activity
+ * with two boundary events did not parse.
+ */
 workflowBoundaryEventClause
     : INTERRUPTING TIMER STRING_LITERAL? (LBRACE workflowBody RBRACE)?
     | NON INTERRUPTING TIMER STRING_LITERAL? (LBRACE workflowBody RBRACE)?
@@ -87,7 +94,7 @@ workflowCallMicroflowStmt
     : CALL MICROFLOW qualifiedName (AS workflowActivityName)? (COMMENT STRING_LITERAL)?
       (WITH LPAREN workflowParameterMapping (COMMA workflowParameterMapping)* RPAREN)?
       (OUTCOMES workflowConditionOutcome+)?
-      (BOUNDARY EVENT workflowBoundaryEventClause+)?
+      (BOUNDARY EVENT workflowBoundaryEventClause ((BOUNDARY EVENT)? workflowBoundaryEventClause)*)?
     ;
 
 workflowParameterMapping
@@ -127,7 +134,7 @@ workflowWaitForTimerStmt
 
 workflowWaitForNotificationStmt
     : WAIT FOR NOTIFICATION workflowActivityName? (COMMENT STRING_LITERAL)?
-      (BOUNDARY EVENT workflowBoundaryEventClause+)?
+      (BOUNDARY EVENT workflowBoundaryEventClause ((BOUNDARY EVENT)? workflowBoundaryEventClause)*)?
     ;
 
 workflowAnnotationStmt
diff --git a/mdl/visitor/visitor_workflow_test.go b/mdl/visitor/visitor_workflow_test.go
index 2f1e93235..332f2a64e 100644
--- a/mdl/visitor/visitor_workflow_test.go
+++ b/mdl/visitor/visitor_workflow_test.go
@@ -1303,3 +1303,55 @@ END WORKFLOW;`
 		t.Errorf("mapping = %+v, want {Ctx $WorkflowContext}", got)
 	}
 }
+
+// Describe writes `boundary event` before EVERY boundary event, and the syntax
+// topic documents that form, but the grammar took the keyword once and then all
+// clauses — so the describe output of any activity with two boundary events did
+// not parse (`mismatched input 'boundary' expecting ';'`). Both forms parse now.
+func TestWorkflowVisitor_BoundaryEventKeywordPerClause(t *testing.T) {
+	cases := map[string]string{
+		"user task": `create workflow M.W parameter $C: M.E
+begin
+  user task T 'c' page M.P outcomes 'a' { } 'b' { }
+    boundary event interrupting timer 'addDays([%CurrentDateTime%], 3)' { jump to T; }
+    boundary event non interrupting timer 'addDays([%CurrentDateTime%], 1)';
+end workflow;`,
+		"call microflow": `create workflow M.W parameter $C: M.E
+begin
+  call microflow M.ACT
+    boundary event interrupting timer 'addHours([%CurrentDateTime%], 1)'
+    boundary event non interrupting timer 'addHours([%CurrentDateTime%], 2)';
+end workflow;`,
+		"wait for notification": `create workflow M.W parameter $C: M.E
+begin
+  wait for notification w1
+    boundary event interrupting timer 'addDays([%CurrentDateTime%], 5)'
+    boundary event non interrupting timer 'addDays([%CurrentDateTime%], 2)';
+end workflow;`,
+		"one keyword, several clauses (the older form)": `create workflow M.W parameter $C: M.E
+begin
+  user task T 'c' page M.P outcomes 'a' { } 'b' { }
+    boundary event interrupting timer '${PT24H}' non interrupting timer '${PT1H}';
+end workflow;`,
+	}
+	for name, src := range cases {
+		t.Run(name, func(t *testing.T) {
+			prog, errs := Build(src)
+			if len(errs) > 0 {
+				t.Fatalf("parse errors: %v", errs)
+			}
+			var n int
+			switch a := prog.Statements[0].(*ast.CreateWorkflowStmt).Activities[0].(type) {
+			case *ast.WorkflowUserTaskNode:
+				n = len(a.BoundaryEvents)
+			case *ast.WorkflowCallMicroflowNode:
+				n = len(a.BoundaryEvents)
+			case *ast.WorkflowWaitForNotificationNode:
+				n = len(a.BoundaryEvents)
+			}
+			if n != 2 {
+				t.Errorf("boundary events = %d, want 2", n)
+			}
+		})
+	}
+}

From 8a264cab7c40c01aa1b1c6dfd382c52c3c6be889 Mon Sep 17 00:00:00 2001
From: Ako <andrej@koelewijn.net>
Date: Mon, 14 Sep 2026 18:53:06 +0000
Subject: [PATCH 9/9] docs(changelog): workflow rewrite guard and boundary
 event describe fixes

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 CHANGELOG.md | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 7464617a8..097b9c598 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -135,6 +135,12 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ### Fixed
 
+- **Rewriting a workflow silently reset what Studio Pro configured and MDL cannot express** — measured on a Studio Pro reference workflow (ako/TestApp, Mendix 11.14.0, 0 errors under mxbuild): `ALTER WORKFLOW … REPLACE ACTIVITY` with an identical user task reset its **on-created microflow** to none while exec reported "Altered workflow" (`SET ACTIVITY`, which edits the stored document in place, kept it). A rebuild writes a default for everything MDL has no spelling for — a user task's on-created microflow becomes `NoEvent`, **workflow event handlers** an empty list, a multi-user task's **completion rule** Consensus on its first outcome — and `describe` shows an **AI agent task** only as a comment. `create or modify` now refuses a workflow that holds any of these, listing every reason at once (the rule an event sub-process already had), and `REPLACE ACTIVITY` refuses an activity that holds one. What a rebuild reproduces exactly — no handler, `NoEvent`, Consensus falling back to the first outcome, which is what the reference stores — is not refused.
+
+- **The `describe` output of an activity with two boundary events did not parse** — describe writes `boundary event …` before every event, and `mxcli syntax workflow boundary-event` documents that form, but the grammar took the keyword once followed by all the clauses (`mismatched input 'boundary' expecting ';'`). So describe → exec of any user task, call microflow or wait for notification with more than one boundary event failed, on both engines. The grammar now accepts the keyword before each clause and still accepts the shared form. The workflow round-trip integration tests compare describe output but never re-parse it, which is how this survived.
+
+- **`describe workflow` dropped the boundary events of a wait for notification** on the default engine — along with each one's handler flow — while the legacy engine read them. The default engine's reader had no case for the activity, so it fell through to a path that reads only the name and caption. Both engines write these events and mxbuild accepts them (measured: interrupting and non-interrupting timers on a wait for notification, 11.13.0), so a describe → exec round trip lost them.
+
 - **An empty graph-analysis table could not be told apart from one that was never computed** (mendixlabs/mxcli#1060). `CATALOG.GRAPH_CYCLES` answered `0 rows` on a project whose `CATALOG.GRAPH_MODULE_COUPLING` listed mutual module pairs, so it read as "no circular dependencies". The two are built by different things: coupling is a plain view over `refs` that any full catalog answers, while the cycles/communities/layers/centrality tables are written only by `REFRESH CATALOG COMMUNITIES` — and those six were in neither `fullOnlyTables` nor `sourceOnlyTables`, so nothing warned.
 
   The mode ladder could not carry the distinction. fast/full/source is a *level*, each containing the one below, which is what lets a rank comparison decide everything; the graph pass is orthogonal, augmenting whichever level is cached. It is now recorded as a flag plus the resolution it ran at. A query against one of the six says `requires refresh catalog communities (not run for this catalog)`; `SHOW CATALOG STATUS` reports `Graph analysis: ✓/✗` separately from the build mode; `DESCRIBE CATALOG.GRAPH_CYCLES` names the command that populates it.