Catalog follow-ups: total_activity_count in Starlark, one workflow walk, commit ref kind (#963)

[ako]

Closes #963 — all three items.

1. total_activity_count in Starlark

The microflow struct microflows() yields (microflows, nanoflows and rules share it) gains total_activity_count, the catalog's TotalActivityCount (loop bodies included, since #940). activity_count is unchanged and now says in the skill that a loop counts as one. Documented in write-lint-rules/SKILL.md (the coverage test enforces it). The hand-built microflows tables in four linter tests gained the column.

2. One workflow walk for list workflows, show structure and the catalog

The catalog's walk (#937) moves to mdl/backend/wfnames as WalkActivities / CountActivities. Both catalog and executor already import that package, so there is no cycle. countFlowActivities (cmd_workflows.go) and countStructureFlowActivities (cmd_structure.go) are gone. Each had its own recursion over outcomes only, which skipped boundary-event flows and event sub-processes. TestApp Workflow1 now lists 8 activities (it listed 5); Workflow1_2, which has no boundary events, still lists 4.

3. Decision: commit belongs in refs → new commit ref kind

Reasoning. refs already records how a flow acts on an entity: create, retrieve, change, delete. Commit is the remaining data action, and it is the one the lint asks in mendixlabs#1266 / mendixlabs#1267 start from ("which flows commit entity X", commit in a loop, commit without events). Without an edge, refs_to("M.Order") cannot answer that question, and the only workaround is joining activities to a variable's type, which the catalog does not store. The variable→entity resolution change/delete use already exists (loop iterators included, per mendixlabs#1266), so commit gets it at no extra cost.

What is emitted. commit (FLOW → ENTITY) comes from:

• a commit action, resolved through the intra-flow variable map;
• a create or change whose commit is Yes / YesWithoutEvents.

For a committing create or change, the commit edge is added beside its create / change edge, not instead of it, so existing create/change queries are unchanged. A variable whose entity the flow cannot tell gets no edge, as for change and delete.

Consumers checked:

• show callers excludes it. Commit is a use of a type, not an invocation, like create/change/delete; the comment in cmd_search.go now says so.
• graph_dead_assets gains inbound edges to entities, which is correct: a committed entity is in use.
• graphRefKinds excludes it. The committed variable comes from a parameter, create or retrieve that already links the flow to the entity, so including it would mostly double edge weights and shift communities and centrality.
• QUAL004's kind lists are unaffected.

Docs. The skill's ref_kind row and the catalog-schema.md RefKind table are updated. TestSkillDocumentsRealRefKinds now reads every RefKind* constant from builder_references.go and requires each one to be documented. It previously checked only that the documented kinds exist, so a new kind could ship undocumented. Catalog schema version 19, 19 (commit refs):.

Test plan

• go test ./mdl/catalog/... ./mdl/linter/... ./mdl/backend/wfnames/ ./mdl/executor/ ./cmd/mxcli/: all ok

• make build, make lint (Go + TS), make check-conformance, make check-findings: pass

• Item 1: TestStarlarkTotalActivityCount uses a microflow, nanoflow and rule with loops (total > top level) and a flat microflow as the control (equal). Revert check: without the struct field the rule fails with "microflow" struct has no .total_activity_count attribute. Removing the skill line fails TestLintSkillDocuments*. End to end, I ran a custom .star rule through mxcli lint on a TestApp copy with Lp.MF_Loop (top=1 total=3) and Lp.MF_Flat (top=2 total=2).

• Item 2: TestCountWorkflowActivities_BoundaryAndEventSubProcess uses a hand-built workflow with a boundary event and an ESP, plus an outcomes-only control. TestCountWorkflowActivities_TestAppWorkflow1 checks that Workflow1 = 8 and that the counts agree for every workflow. Both written first: before the fix they failed with (2,1,1) and Workflow1 activities = 5, while the control passed. mxcli list workflows on a TestApp copy shows 8 / 4.

• Item 3: TestCommitEmitsCommitRefs runs a full catalog build over a mock backend and covers:

  • commit of a loop iterator
  • commit of a list parameter
  • create with commit
  • change with commit YesWithoutEvents on an iterator
  • a nanoflow
  • a control flow whose create and change use commit No (it keeps create/change edges and gets no commit edge)

  Revert check: with the emit line stubbed out, the test fails and lists only the create/change rows. End to end, on a TestApp copy, a .star rule calling refs_to("Lp.Item") through mxcli lint shows Lp.MF_CommitEach commit Lp.Item (loop $It in $Items begin commit $It; end loop;); the non-committing change flows get no commit row.

Findings appended to mdl-executor.jsonl (item 2, a duplicate-resolver-drift instance) and mdl-other.jsonl (item 3). CHANGELOG entries are under Unreleased.

🤖 Generated with Claude Code