MendixMau · MendixMau · Sep 28, 2026 · Sep 28, 2026
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -16,6 +16,7 @@ three commits past it), and a bug report can name a release instead of a sha nob
 Sections dated before 2026-09-19 predate the cycle and stay as they are.
 
 ## Unreleased
+- log(bug-logs/mxcli-bugs.md, bug-logs/pending-github-issues/marketplace-install-not-grouped-in-studio-pro.md, bug-logs/submitted-prs/mxcli/2026-09-28-marketplace-install-fromappstore/, skills/learned-mdl-preflight.md row 27): **a module installed by `mxcli marketplace install` shows up in Studio Pro among the app's own modules, not under "Marketplace modules".** The installer stamps 3 of the 5 marketplace identity fields on the module (`AppStoreVersionGuid` and `AppStorePackageIdString` stay empty) and `--file` stamps none; Studio Pro reads all five. Measured on a fresh Mendix 11.13.0 probe (`--file`: `FromAppStore` false, four empty strings) against a real project's Studio Pro-installed Encryption module (all five set). Ledger entry, paste-ready issue draft (NOT YET FILED), a fix patch for upstream on `main` 95091765 (content id threaded into the stamp, all five fields written, 3 unit tests, marketplace + cmd packages green; Studio Pro regrouping not yet proven), preflight STOP row 27 (install by content id, then read the `SHOW MODULES` Source column) and a fifth trap on the #879 entry. — Maurits Visser, field report 2026-09-28
 - fix(tests/wave2/test-mxbuild-version-match.sh): **master CI had been red since 2026-09-28 on one check-portability violation** — the test probed `python3`/`python` by name; it now sources `bin/lib/portable.sh` and uses `resolve_py`, keeping its SKIP when no Python 3 with sqlite3 is found. check-portability: 1 violation -> clean (164 files). The test's own PASS=15 FAIL=3 on a Mac with a Studio Pro 11.12.2 Beta in /Applications is unchanged by this and is a fixture-isolation gap (find_mxbuild sees the real /Applications), not a regression.
 - process(privacy): scrubbed a customer name and an internal project name that reached master through GitHub-merged PRs, where the pre-commit leak guard never runs (bin/check-no-client-data.sh: 32 files hit on master, 0 after). The customer is now "a customer" in prose and the placeholder `acme` in eval identifiers and grader patterns (the graders say to substitute the real prefix before regrading); the project is "a field project", and its inbox patch file is now `contrib/inbox/2026-09-27-field-project-patches.md`. Git history still holds the old text.
 - log(bug-logs/upstream-log-2026-09.md, bug-logs/pending-github-issues/2026-09-27-*.md): **one index of what went upstream this month.** It lists 4 filed mxcli issues (#1198–#1201; #1199 is already fixed upstream), 1 PR package ready to send, and 7 issue drafts that are not filed yet. The drafts use placeholders for project names. — field project, 2026-09-27 guest-groups build

diff --git a/bug-logs/mxcli-bugs.md b/bug-logs/mxcli-bugs.md
@@ -919,6 +919,15 @@ no `mxcli fix security`, and forcing a recompute with an MDL `GRANT` on a UserCo
 tried and **does not clear it**. Plan that module for a Studio Pro session; do not install it into a
 project that must stay buildable headlessly in the meantime.
 
+**5. (added 2026-09-28) A headless install is not a Studio Pro install in the model's eyes — check the
+Source column, and know what it cannot tell you.** `marketplace install <content-id>` stamps three of the
+five marketplace identity fields on the module (`FromAppStore`, `AppStoreVersion`, `AppStoreGuid`);
+`--file` stamps none. Studio Pro reads all five, so the module lands among the app's own modules in the
+App Explorer instead of under "Marketplace modules". After every install read `SHOW MODULES`: Source
+must say `Marketplace v<version>` (a `--file` install shows nothing there, and that is the first sign).
+Even when it does, on ≤ v0.24.0 the Studio Pro grouping is still wrong — see
+`BUG-DRAFT-marketplace-install-not-grouped-in-studio-pro` for the fix package.
+
 ---
 
 ### HISTORICAL RECORD (the bug as it was, kept because a ledger entry that vanishes reads as a bug never found)
@@ -6095,3 +6104,60 @@ filed upstream.
   and not probed here. The toolkit repeats the claim without evidence in
   `skills/learned-workflow-patterns.md` (the MPR006 row and the page-patterns note). Treat it as
   unconfirmed until someone runs an empty container. Ask upstream what the crash is.
+
+---
+
+## BUG-DRAFT-marketplace-install-not-grouped-in-studio-pro: a module installed by `marketplace install` is listed among the app's own modules in Studio Pro, not under "Marketplace modules" — the stamp writes 3 of 5 identity fields, and `--file` writes none (2026-09-28)
+
+> **NOT YET FILED** — paste-ready draft in `bug-logs/pending-github-issues/marketplace-install-not-grouped-in-studio-pro.md`.
+> Fix patch ready in `bug-logs/submitted-prs/mxcli/2026-09-28-marketplace-install-fromappstore/` (file the issue first, then the PR).
+
+> **Status:** reported 2026-09-28 from a field project on v0.24.0 (modules installed by mxcli showed up
+> in Studio Pro among the app's modules). Cause read from source on upstream `main` 95091765 and
+> measured on a fresh 11.13.0 probe project plus a real project that has a Studio Pro-installed module.
+> The Studio Pro regrouping after the fix is **not yet proven** — it needs a content-id install with the
+> patched binary and a Studio Pro open.
+
+**Family:** the #879 entry above (its fix added the stamp this entry is about; trap 5 there is the
+field rule), BUG-132 (`fix design-properties` on marketplace packages), BUG-133 (`_USE_ME` flows).
+
+**Discovered:** 2026-09-28. **mxcli version:** v0.24.0 (same code on `main` 95091765). **Severity:**
+Medium. Nothing fails to build; the module is simply not a Marketplace module to Studio Pro, so it is
+not shown as one, not offered updates there, and reads as the app's own code in every review.
+
+**Repro:**
+```
+mxcli marketplace install 1011 -p App.mpr        # Encryption, by content id
+mxcli -p App.mpr -c "SHOW MODULES"               # Source: Marketplace v11.x.y  (looks right)
+# open in Studio Pro: Encryption is among the app's own modules
+```
+
+**Expected:** the module carries the five fields a Studio Pro install writes on `Projects$ModuleImpl`
+(`FromAppStore`, `AppStoreVersion`, `AppStoreGuid`, `AppStoreVersionGuid`, `AppStorePackageIdString`)
+and is listed under "Marketplace modules".
+
+**Actual (measured):**
+- Content-id install / `marketplace update`: `StampMarketplaceVersion` (`cmd/mxcli/marketplace/update.go`)
+  writes `FromAppStore`, `AppStoreVersion`, `AppStoreGuid` only. `AppStoreVersionGuid` and
+  `AppStorePackageIdString` stay empty. The content id is never passed down to the stamp.
+- `--file` install: nothing is stamped. `FromAppStore` false, four empty strings (fresh 11.13.0 probe,
+  BusinessEvents package, unit decoded from `mprcontents`). `SHOW MODULES` shows no Source at all.
+- Studio Pro-installed reference (Encryption in a real project): all five set, `AppStoreGuid` equals
+  `AppStoreVersionGuid` (the version UUID), `AppStorePackageIdString` is `"1011"`.
+- `SHOW MODULES` and the catalog render `Marketplace v<x>` from `FromAppStore` alone
+  (`mdl/catalog/builder_modules.go`, `mdl/executor/cmd_modules.go`), so the CLI cannot show the gap.
+
+**Impact:** every module installed headlessly on a project reads as the app's own module the first time
+someone opens it in Studio Pro. Reviews count it as project code; Studio Pro's Marketplace pane does not
+list it for update. The `--file` route is worse: the module is not a marketplace module even to mxcli.
+
+**Workaround (≤ v0.24.0):** install by content id, never `--file`, and read `SHOW MODULES` Source after
+every install (preflight STOP row 27). That fixes the `--file` half. The grouping half needs the patch,
+or a one-off model patch that copies `AppStoreGuid` into `AppStoreVersionGuid` and writes the content id
+into `AppStorePackageIdString` (run it through `./bin/exec.sh --patch` so it is gated and restorable).
+
+**Fix (proposed upstream):** thread the content id through `installModule` → `PerformInstall` and the
+update command → `PerformUpdate`; one helper `stampModuleDoc` writes all five, still only on keys the
+document already has (ADR-0005). Unit tests for the helper; marketplace and cmd packages pass.
+Scope B (`--file --content-id --version` resolving the UUID through the marketplace client) is a
+separate ask in the issue draft.
diff --git a/bug-logs/pending-github-issues/marketplace-install-not-grouped-in-studio-pro.md b/bug-logs/pending-github-issues/marketplace-install-not-grouped-in-studio-pro.md
@@ -0,0 +1,71 @@
+**Repo:** `mendixlabs/mxcli`
+**Source:** `bug-logs/mxcli-bugs.md`, `## BUG-DRAFT-marketplace-install-not-grouped-in-studio-pro` — found 2026-09-28 (field report on v0.24.0; cause read from source on upstream `main` 95091765)
+**Status:** NOT YET FILED — fix patch ready in `bug-logs/submitted-prs/mxcli/2026-09-28-marketplace-install-fromappstore/`; file this first, then open the PR with "closes #<n>"
+**Suggested labels:** bug, marketplace
+**Duplicate check:** searched 2026-09-28 (`marketplace install FromAppStore`, `Marketplace modules App Explorer`, `AppStoreVersionGuid`). No match. #879 (closed, v0.21.0) was the format collapse; the stamp that this issue is about was added by its fix and has always written three fields.
+
+---
+
+**Title:** `marketplace install` / `update` stamp 3 of 5 marketplace identity fields, so Studio Pro lists the module among the app's own modules instead of under "Marketplace modules"
+
+**Body:**
+
+## Summary
+
+A module Studio Pro installs from the Marketplace carries five fields on its `Projects$ModuleImpl`: `FromAppStore`, `AppStoreVersion`, `AppStoreGuid`, `AppStoreVersionGuid`, `AppStorePackageIdString`. `StampMarketplaceVersion` (`cmd/mxcli/marketplace/update.go`) writes only the first three, so a module installed by `mxcli marketplace install <content-id>` or updated by `marketplace update` has an empty `AppStoreVersionGuid` and `AppStorePackageIdString`. Studio Pro reads all five: the module is shown in the App Explorer among the app's own modules instead of under "Marketplace modules", and it is treated as the app's own code from then on. `marketplace install --file <package.mpk>` writes none of the five (`FromAppStore` stays `false`), so the same happens there, and `SHOW MODULES` (which reads `FromAppStore` only) shows `Marketplace v<x>` in the first case and nothing in the second — neither says what Studio Pro will do.
+
+**Version:** mxcli v0.24.0 (`StampMarketplaceVersion` on `main` 95091765 is the same), Mendix 11.13.0, MPR v2.
+
+## Repro
+
+```
+mxcli new App --mendix-version 11.13.0
+mxcli marketplace install 1011 -p App/app/App.mpr          # Encryption
+mxcli -p App/app/App.mpr -c "SHOW MODULES"                 # Source: Marketplace v11.x.y
+```
+
+Open `App.mpr` in Studio Pro 11.13.0 → App Explorer: Encryption is listed among the app's modules, not under "Marketplace modules".
+
+The module's unit shows why (`mprcontents/<xx>/<yy>/<unit>.mxunit`, decoded BSON of the `Projects$ModuleImpl`):
+
+```
+FromAppStore             true
+AppStoreVersion          "11.x.y"
+AppStoreGuid             "<version uuid>"
+AppStoreVersionGuid      ""            <- empty
+AppStorePackageIdString  ""            <- empty
+```
+
+The same module installed by Studio Pro in another project:
+
+```
+FromAppStore             true
+AppStoreVersion          "11.1.1"
+AppStoreGuid             "<version uuid>"
+AppStoreVersionGuid      "<the same version uuid>"
+AppStorePackageIdString  "1011"
+```
+
+With `marketplace install --file Encryption.mpk` all five stay at their defaults (`FromAppStore` false, four empty strings).
+
+## Measured
+
+- Fresh 11.13.0 project, `--file` install of a marketplace package: module unit has `FromAppStore=false` and all four strings empty (read with a BSON decoder over the `.mxunit`).
+- A Studio Pro-installed module in a real project: all five set, `AppStoreGuid == AppStoreVersionGuid`, `AppStorePackageIdString` is the content id as decimal text.
+- Reading `cmd/mxcli/marketplace/update.go` on `main`: the stamp is three `set*Field` calls; the content id is not threaded into `PerformInstall` / `PerformUpdate` at all.
+
+## Expected
+
+After `marketplace install <content-id>` or `marketplace update`, the module carries the same five fields a Studio Pro install writes, and Studio Pro lists it under "Marketplace modules".
+
+## Proposed fix (PR follows)
+
+Thread the resolved content id into `PerformInstall` / `PerformUpdate` and have the stamp write the version UUID into both `AppStoreGuid` and `AppStoreVersionGuid` and the content id into `AppStorePackageIdString`, still only assigning keys the document already has (ADR-0005). One helper, unit-tested. `--file` stays unstamped in that PR (a package on disk has no identity).
+
+## Follow-up ask (separate)
+
+Let `marketplace install --file` take `--content-id <n>` and `--version <x.y.z>` and resolve the version UUID through the marketplace client, so an offline install can carry the same identity. Until then the workaround is to install by content id.
+
+## Workaround
+
+Install by content id, never `--file`, for a module that must read as a Marketplace module. Check `SHOW MODULES` Source reads `Marketplace v<version>`. The Studio Pro grouping cannot be fixed from mxcli ≤ v0.24.0; a one-off BSON patch that copies `AppStoreGuid` into `AppStoreVersionGuid` and writes the content id into `AppStorePackageIdString` is what the fix does.