@zenuml/core 3.46.3 → 3.46.4

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -28,17 +28,39 @@ If any precondition fails, report which one and stop. Do not attempt to fix —
28
28
 
29
29
  Run the precondition checks above. If anything is not green, stop and report.
30
30
 
31
- ### 2. Squash merge
31
+ ### 2. Decide merge strategy
32
32
 
33
- This repo uses squash merges. The merge commit message should summarize the PR.
33
+ Inspect the branch's commit history to decide between squash and merge:
34
34
 
35
35
  ```bash
36
+ git log main..HEAD --oneline
37
+ ```
38
+
39
+ **Auto-squash if ANY of these are true:**
40
+ - Only 1 commit on the branch
41
+ - Commit messages contain noise patterns: "wip", "fixup", "temp", "oops", "try again", "fix lint", "fix test", duplicate messages
42
+ - More than half the commits have the same or very similar messages
43
+
44
+ **Merge (preserve commits) if ALL of these are true:**
45
+ - 2+ commits with distinct, meaningful messages
46
+ - Each commit describes a self-contained step (not just iterations on the same change)
47
+ - Commits follow a logical progression (e.g., "add X" → "refactor Y" → "delete Z")
48
+
49
+ Announce the decision and why: "Squashing — 3 of 5 commits are fixups" or "Merging — 8 clean commits with distinct steps".
50
+
51
+ ### 3. Execute merge
52
+
53
+ ```bash
54
+ # If squash:
36
55
  gh pr merge <PR_NUMBER> --squash --auto
56
+
57
+ # If merge:
58
+ gh pr merge <PR_NUMBER> --merge --auto
37
59
  ```
38
60
 
39
61
  Using `--auto` arms auto-merge so GitHub merges when all checks pass. If checks are already green, it merges immediately.
40
62
 
41
- ### 3. Wait for merge
63
+ ### 4. Wait for merge
42
64
 
43
65
  If auto-merge was armed, wait for it:
44
66
 
@@ -48,7 +70,7 @@ gh pr view <PR_NUMBER> --json state
48
70
 
49
71
  Poll until state is `MERGED`. Timeout after 5 minutes — if not merged by then, report and stop.
50
72
 
51
- ### 4. Monitor npm publish
73
+ ### 5. Monitor npm publish
52
74
 
53
75
  After merge, the `Build, Test, npm Publish, and Deploy` workflow runs on `main`. Watch it:
54
76
 
@@ -62,7 +84,7 @@ Wait for the run to complete:
62
84
  gh run watch <RUN_ID> --repo mermaid-js/zenuml-core
63
85
  ```
64
86
 
65
- ### 5. Verify npm publish
87
+ ### 6. Verify npm publish
66
88
 
67
89
  Check that the new version appeared on npm:
68
90
 
@@ -10,6 +10,8 @@ Orchestrate the full path from local branch to npm release. This skill composes
10
10
  ## Flow
11
11
 
12
12
  ```
13
+ rebase on origin/main → CONFLICT → stop, report
14
+ | CLEAN
13
15
  validate-branch → FAIL → stop, report
14
16
  | PASS
15
17
  submit-branch → FAIL → stop, report
@@ -25,6 +27,17 @@ land-pr → PUBLISH FAIL → alert, stop
25
27
 
26
28
  ## Steps
27
29
 
30
+ ### Step 0: Rebase on remote main
31
+
32
+ Fetch and rebase onto `origin/main` to ensure the branch is up to date before validating.
33
+
34
+ ```bash
35
+ git fetch origin main
36
+ git rebase origin/main
37
+ ```
38
+
39
+ If the rebase has conflicts, stop immediately and report. The developer must resolve conflicts manually before shipping.
40
+
28
41
  ### Step 1: Validate locally
29
42
 
30
43
  Invoke `/validate-branch`. If it reports FAIL, stop and show the failure. The developer needs to fix locally before shipping.