Daily Digest: 2026-06-03

[github-actions]

We are given a daily digest for 2026-06-03. We need to structure the response as:

1. Highlights (1-3 bullet points of the most important changes)
2. Code Changes (summarize commits by theme, not individually)
3. Pull Requests (merged, opened, pending review)
4. Issues (new, closed, total open)
5. Repository Health (stars, forks, CI status)
6. Action Items (anything that needs attention: failing CI, stale PRs, unanswered issues)

Let's break down the provided data:

Repository Stats:

• Stars: 90
• Forks: 31
• Watchers: 6
• Open issues: 1 (but note: the issues list shows multiple issues opened and closed, so we'll have to compute the current open issues from the data)

Commits (last 24h):
We have a list of commits. We should group them by theme.

Pull Requests Merged (last 24h): None.

Pull Requests Opened (last 24h): None.

Currently Open PRs: Listed 4 PRs (#598, #596, #592, #386).

Issues Opened (last 24h): A long list from #634 down to #619 (16 issues).

Issues Closed (last 24h): #630 and #618 (2 issues).

CI Status (latest runs on main):

• One run named "Daily Project Digest" (which is likely the digest generation) - status not explicitly stated but we see it's listed without a success/failure emoji? Actually, the first one is:
  — Daily Project Digest [2026-06-03T11:50:58Z](https://github.com/mendixlabs/mxcli/actions/runs/26882865785)
  Then two successes:
  success — Configured Graph Update: go_modules in /. #1395095918 [2026-06-03T11:31:13Z](https://github.com/mendixlabs/mxcli/actions/runs/26881870878)
success — Build, Test & Lint [2026-06-03T11:50:13Z](https://github.com/mendixlabs/mxcli/actions/runs/26881868987)

  So the first one (Daily Project Digest) doesn't have a status emoji? But note: the digest is generated by an action, and it's likely that the action ran and succeeded (otherwise we wouldn't have the digest). However, the way it's written:
  " — Daily Project Digest 2026-06-03T11:50:58Z"
  without a success/failure indicator. But the next two have "success — ".

  Looking at the pattern, the first one might be missing the status because it's the digest run? But we are to report CI status. We'll note that the Build, Test & Lint and Configured Graph Update are success.

Dependency Changes (last 5 commits):
go.mod and go.sum (so dependency updates via Dependabot, which we see in the commits: several merges of Dependabot PRs).

Now, let's structure the response:

1. Highlights:

   • We had several commits related to fixing STYLING design properties (ALTER STYLING) based on issue ALTER STYLING cannot set design properties on widgets in pages and snippets #631, which was closed by a series of commits (including the fix and documentation updates).
   • Dependency updates: Go toolchain bumped to 1.26.4 for CVE fixes, and several dependency bumps (chroma, sqlite, go-runewidth) via Dependabot.
   • Documentation updates: examples for faceted-search, dev documentation for modelsdk backend pipeline, and styling corrections.

2. Code Changes:

   • We can group the commits:
     • Dependency updates:
       • build(deps): bump Go toolchain to 1.26.4 (0cfc2ac)
       • Merge of Dependabot PRs for chroma (78925d1), sqlite (56d2b44), go-runewidth (5e2056f)
     • STYLING fixes (related to issue ALTER STYLING cannot set design properties on widgets in pages and snippets #631):
       • fix: ToggleButtonGroup design properties use Option value-type (6e1e038)
       • fix: ALTER STYLING encodes design-property value-types (120b1c6)
       • fix: ALTER STYLING writes design properties on pages and snippets (98dd129)
       • docs: update feature matrix for STYLING (c29d0c0)
       • docs(styling): correct SetDesignProperty comments (65e1f6e)
     • Documentation:
       • docs(examples): faceted-search use-case (97672ee)
       • docs(dev): document modelsdk backend pipeline (5b48f7f)
     • Other:
       • Merge pull request fix: ALTER STYLING writes design properties on pages and snippets (#631) #632 (which appears to be the STYLING fixes) - 2f08a1a

   So themes: Dependency updates, STYLING fixes, Documentation.

3. Pull Requests:

   • Merged (last 24h): None.
   • Opened (last 24h): None.
   • Pending review: 4 open PRs (fix #594: preserve omitted scalar fields on create or modify external entity #598, fix #595: PublishedODataService EntityTypePointer wired by qualified entity name #596, fix #590: rewrite OData example Level 9.1 to use TripPin schema actions #592, docs: add manual test case documentation for all MDL command areas #386).

4. Issues:

   • New (last 24h): 16 issues opened (DESCRIBE output emits unquoted reserved-word identifiers that fail mxcli check #619 to DESCRIBE emits action: call_microflow/call_nanoflow for widget actions, which the parser rejects (roundtrip break) #634, but note: Daily Digest: 2026-06-02 #630 and Daily Digest: 2026-06-01 #618 were closed, so the opened ones are from DESCRIBE output emits unquoted reserved-word identifiers that fail mxcli check #619 to DESCRIBE emits action: call_microflow/call_nanoflow for widget actions, which the parser rejects (roundtrip break) #634 excluding the closed ones? Actually, the list of opened issues is from DESCRIBE emits action: call_microflow/call_nanoflow for widget actions, which the parser rejects (roundtrip break) #634 down to DESCRIBE output emits unquoted reserved-word identifiers that fail mxcli check #619, which is 16 issues: 634,633,632? Wait, we don't see fix: ALTER STYLING writes design properties on pages and snippets (#631) #632 in the opened list? Let me count:
     DESCRIBE emits action: call_microflow/call_nanoflow for widget actions, which the parser rejects (roundtrip break) #634, DESCRIBE emits over-qualified grant member names that fail to re-parse (roundtrip break) #633, ALTER STYLING cannot set design properties on widgets in pages and snippets #631, Add a no-Docker local run/test path (mxcli run --local) and document it in skills #629, DataGrid2 SELECTION binding may not persist; document pluggable vs built-in widget support scope #628, CONTAINER Visible expression produces CE0117 (needs repro; likely BSON serialization) #627, DESCRIBE PAGE output not guaranteed to roundtrip through mxcli check #626, Assign System module roles to user roles via MDL (resolve CE0156) #625, Add ALTER PROJECT SECURITY ADMIN PASSWORD (resolve CE0129 from MDL) #624, Add mxcli check --full: semantic validation equivalent to mx check (CE0111/CE0109/CE0053/CE0066) #623, CALL MICROFLOW: allow assigning return value to an existing variable (avoid CE0111) #622, Apply sensible page margin/padding defaults on CREATE PAGE #621, Allow editing projects while Studio Pro stays open (SQLite write-lock blocks develop→verify cycle) #620, DESCRIBE output emits unquoted reserved-word identifiers that fail mxcli check #619 -> that's 14?
     But the list provided:
     #634, #633, #631, #629, #628, #627, #626, #625, #624, #623, #622, #621, #620, #619
     That's 14 issues. However, note that the issue numbers are not consecutive because Daily Digest: 2026-06-02 #630 and Daily Digest: 2026-06-01 #618 were closed (and fix: ALTER STYLING writes design properties on pages and snippets (#631) #632 is not mentioned in the opened list? Actually, we see a commit that merged PR fix: ALTER STYLING writes design properties on pages and snippets (#631) #632, but that doesn't mean an issue was opened).

     The provided list of opened issues (last 24h) has 14 items.

   • Closed (last 24h): 2 issues (Daily Digest: 2026-06-02 #630, Daily Digest: 2026-06-01 #618).

   • Total open: The repository stats said "Open issues: 1", but that seems inconsistent with the activity. However, note that the repository stats might be from a different time? We are to report the current state.

     We have:
     Previously open issues (we don't know the exact number)

     • 14 new
     • 2 closed
       = net change of +12.

     But the repository stats at the top say "Open issues: 1". This is likely a mistake in the provided data? Or perhaps the repository stats are not up to date?

     However, the instructions say: "Generate a concise daily digest from the raw data provided." So we must use the provided data.

     The repository stats table says:
     Open issues | 1

     But then we see 14 new issues opened and 2 closed. This doesn't add up.

     Let me reexamine: the repository stats might be the state at the beginning of the day? Then during the day, we opened 14 and closed 2, so the current open issues would be: 1 (initial) + 14 - 2 = 13.

     However, the problem says: "Repository Stats" at the top of the digest. It's likely that these stats are current as of the digest generation. But then why does it say 1 open issue when we have just opened 14 and closed 2?

     Alternatively, the repository stats might be incorrect in the provided data? We have to go by what is given.

     Since the digest is for 2026-06-03, and the repository stats are provided at the top, we'll use that for the total open issues. But note: the issues section then lists new and closed.

     We'll report:
     New issues: 14
     Closed issues: 2
     Total open issues: 1 (as per the repository stats)

     However, this is confusing. Alternatively, the repository stats might be a typo? But we must use the data.

     Let's look at the issues closed: Daily Digest: 2026-06-02 #630 and Daily Digest: 2026-06-01 #618. These are two issues that were closed. The issues opened are 14. So if the total open issues is 1, then the day started with 1 - 14 + 2 = -11? That doesn't make sense.

     Another possibility: the repository stats are for the entire project and are not changing much? But 1 open issue seems too low given the activity.

     Given the confusion, I will report the repository stats as provided for the total open issues (1) and then in the issues section, note the new and closed.

     But note: the digest is called "Daily Project Digest: 2026-06-03", and the repository stats are at the top. It's likely that the stats are current as of the time of the digest. However, the commits and PRs and issues are from the last 24h. So the open issues count of 1 might be after the day's activity? Then we have to reconcile:

     Let O = open issues at start of day.
     During the day: opened 14, closed 2.
     Then open issues at end = O + 14 - 2 = O + 12.

     And we are told that at the time of the digest (end of day?) the open issues are 1.

     So: O + 12 = 1 => O = -11 -> impossible.

     Therefore, the repository stats must be incorrect or from a different time. Since we are to generate the digest from the raw data, we have two options:

     Option 1: Trust the repository stats for the total open issues (1) and note the discrepancy in the issues section.
     Option 2: Calculate the total open issues from the activity and the initial state (which we don't have).

     The problem says: "Repository Stats" is provided in the raw data. We must include it as is. Then in the issues section, we report the new and closed.

     We'll do:

     Total open issues: 1 (from repository stats)
     New issues (last 24h): 14
     Closed issues (last 24h): 2

     And note that this implies the number of open issues at the start of the period was 1 - 14 + 2 = -11, which is impossible, so there might be an error in the data. But we report what we see.

     Alternatively, the repository stats might be watchers? No, the table says:
     Stars | 90
     Forks | 31
     Watchers | 6
     Open issues | 1

     So we'll report open issues as 1.

5. Repository Health:

   • Stars: 90
   • Forks: 31
   • CI status:
     • Build, Test & Lint: success
     • Configured Graph Update: go_modules: success
     • The Daily Project Digest run: we don't have a status, but it ran (and produced this digest) so we can assume it succeeded? However, the log doesn't show a status. We'll note that the two main CI jobs are success.

6. Action Items:

   • We have 4 open PRs that are stale? The oldest is docs: add manual test case documentation for all MDL command areas #386 (from the list) which is quite old. We should check if any are stalled.

   • Also, we have many new issues (14) that need attention.

     Specifically:

     • The open PRs: fix #594: preserve omitted scalar fields on create or modify external entity #598, fix #595: PublishedODataService EntityTypePointer wired by qualified entity name #596, fix #590: rewrite OData example Level 9.1 to use TripPin schema actions #592, feat(tui): add agent channel for external automation #38

---

Daily digest generated automatically — workflow source