Skip to content

[bug] A bundled lint-rule refresh shows up as a lint rise on the next exec #264

Closed

Description

@AlvinnYeo

What broke:
At session start mxcli rewrote .claude/lint-rules (the conv010 rule, 205 lines changed). CONV010 rose 26 -> 169 on microflows no script had touched. The first exec after the refresh (a pages-only script) showed the rise, as if that script had caused it.

Command / script run (exact invocation):
Session start (mxcli rule refresh), then bin/exec.sh <pages-only script>.mdl.

Expected vs. actual:
Expected: the lint delta reflects only the model change.
Actual: CONV010 +143 attributed to an unrelated exec.

Field evidence:
A consuming project (Mendix 11.14.0, macOS, toolkit 9dd9be4, mxcli v0.25.0), 2026-10-11. The new baseline was accepted by hand with a reason.

Proposed fix (hypothesis):
When the bundled rules are rewritten, re-take the lint baseline at that moment and log it ("lint rules refreshed: CONV010 26 -> 169, no model change"), so the next exec's delta uses the new rules. Or have exec.sh's lint delta flag "rules changed since baseline".

Activity

  1. MendixMau commented on Oct 12, 2026

    @MendixMau
    Owner

    Same class, seen in another toolkit-built app (mxcli v0.25.0, toolkit 69b223c). This time it persisted for days, because nothing ran sync afterwards.

    What happened:

    • On 2026-10-07 at 23:34, 26 minutes after a sync-project.sh commit, .claude/lint-rules/ was re-seeded. Three toolkit rules reverted to stock and lost the mxtk-lint-rule header: conv010, data_change_microflows and entity_business_key.
    • The working-tree md5s equal the v0.25.0 stock hashes already in lint-rules/STOCK-HASHES.txt (de7463c1…, 4f8194a1…, d66528c9…).
    • Effects:
      • CONV010 went back to one row per activity: 31 rows for 14 microflows, one microflow alone giving 8.
      • CONV010 lost its "inspected NOTHING" self-check.
      • ARCH002 lost its System/Administration skip.
    • The baseline absorbed the noisier counts on the next exec.
    • The edits stayed uncommitted in the working tree for five days.

    What I checked: sync-project.sh would repair it. I ran mxtk_install_lint_rules from master on a copy of that project's .claude/lint-rules and receipt. Output: REVERTED TO STOCK … Restoring it for conv010 and data_change, headered for entity_business_key, and all three md5s equal the toolkit's afterwards. So the installer is fine. The gap is that nothing notices a re-seed between syncs.

    Concrete proposal (extends yours): lint-gate.sh already runs on every exec. Before linting, it compares each rule listed in .claude/.mxtk-lint-receipt with its md5. If a file no longer matches its receipt and the header line is gone, print lint rules reverted to stock (mxcli init?): <files> — run sync-project.sh; this run's delta is not attributable and exit with the blind code, not a rise. The receipt already survives mxcli init (verified in the installer header). That makes it the cheapest tripwire available.

  2. MendixMau commented on Oct 14, 2026

    @MendixMau
    Owner

    Fixed by #308, which landed on master in the integration squash #329 (commit 31e90ae) after independent review. Closing; reopen if it still reproduces on master.


    Generated by Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions