[ako]

Syncs ako/mxcli:main into upstream: 6 commits from fork PRs ako#1816, ako#1817 and ako#1820.

Fixes #1680. Refs #580.

Incremental catalog refresh

Problem: every catalog refresh rebuilt every table from every document after any save. On a 4,753-unit app that was about 4.5 s of decoding and inserting, and 5.6–8 s end to end. This is the second step after the unit store.

Fix:

• Row ownership: each catalog row is recorded under the document it came from.

• What an incremental refresh rebuilds: it loads the cached catalog and deletes only:

  • the rows of the changed documents;
  • the rows of documents whose refs name a changed document;
  • the project-wide rows.

  It then rebuilds those.

• Full-build fallback: anything the plan can't vouch for falls back to a full build. That covers folder, module, settings, security and navigation changes, another mxcli build or catalog level, and FORCE.

Refresh after one entity edit	Before	After
refresh catalog full	5.6–5.8 s	0.70 s
refresh catalog full source	7.3–7.9 s	0.71 s

Correctness:

• Equivalence: TestCatalog_IncrementalBuildEqualsFullBuild and its fast-mode twin compare every table with a forced full build, across 19 kinds of edit. Each step runs a second time with no change.

• Ref coverage: cross-document reads are recorded, and coverage is checked. It is 100% on the fixture and 99.4% on two real projects.

  • The trace found that inheritance splits had no refs edge to their entity, so show references missed those flows too. They now get a new split edge.

• Performance guards: three tests fail if a rule of the incremental build is broken:

  • every row must belong to a document;
  • the decode budget;
  • no whole-project listings in the passes.

  Breaking one of these would leave the catalog correct but slow, so no correctness test would notice.

• Docs: ADR-0014 records the decision and its downsides. /mxcli-dev:review gains a "Catalog builder passes" checklist.

Notes:

• Row order and the internal Id columns of refs and permissions may differ from a full build.
• An incremental refresh prints one incremental: N units rebuilt, M carried over line instead of per-table counts.
• The Windows gain isn't measured.

E015: a String function's result compared with empty (refs #580)

The problem: if trim($Value) != empty then … passes check, exec and mx check, but is always true. These functions return '', never empty. Measured on 10.18.5 with mxcli test --local:

expression	empty	''	' '
trim	''	''	''
toLowerCase / toUpperCase / substring / replaceAll	''	''	text
toString(<empty Integer>)	''	—	—
$v + ''	'null'	''	text
$v (control)	empty	''	text

The new warning:

• E015 string-func-vs-empty is a warning, because the model is valid. It fires only for the measured functions.
• It is skipped when the same and/or chain also compares the call with '', the guard idiom. Otherwise it was noise on a Studio Pro-authored fixture.

Not a warning: + with an empty operand gives the text null. That is documented as pitfall #18 instead, because whether an operand is empty can't be known at check time.

Not measured: Mendix 11.x and nanoflows.

init: the bootstrap script downloads the Windows asset under Git Bash (#1680)

The problem: the script built the release asset name from uname -s. Under Git Bash, MSYS2 and Cygwin that gives mingw64_nt-…, never windows, so the download returned 404. The hook runs with || true, so the session started without mxcli and nothing said why.

The fix:

• MINGW*, MSYS* and CYGWIN* now map to windows, with the .exe suffix.
• The binary is kept as ./mxcli.exe on Windows.
• A stale Linux ./mxcli is removed first. Otherwise Git Bash resolves ./mxcli to that file.

Tests: they run the generated script with a fake uname and curl, for Git Bash (64- and 32-bit), MSYS2, Cygwin and Windows on ARM, with Linux and macOS as the controls.

Validation

make ci-local passes, except for two cmd/mxcli/docker TestSyncJavaDependencies_* tests that fail the same way on main in the authors' environment