@cratis/pi 2.25.0 → 2.26.0
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.
|
@@ -22,6 +22,13 @@ requested-label, merge, and branch-cleanup effects. Do not pause to ask for sepa
|
|
|
22
22
|
each step. Follow the repository's Git commit and pull-request rules, use a true merge commit,
|
|
23
23
|
and verify required checks before merging.
|
|
24
24
|
|
|
25
|
+
**Exception: a `major` label does not carry merge authority.** Prepare the branch, commits, push,
|
|
26
|
+
and PR labeled `major` as usual, then stop before merging. Ask a human to confirm the breaking
|
|
27
|
+
change(s), who is affected, and the resulting version number, and merge only on an explicit
|
|
28
|
+
affirmative answer to that specific question — see
|
|
29
|
+
[`pull-requests.md`](../rules/pull-requests.md#a-major-release-needs-a-humans-explicit-go-ahead).
|
|
30
|
+
Every other label proceeds through merge under this prompt's ordinary authority.
|
|
31
|
+
|
|
25
32
|
This prompt is for an explicit request to ship or land. If the user asked only to commit, only to
|
|
26
33
|
push, or only to open a PR, stop after that step: the narrower request does not become authority
|
|
27
34
|
for the rest of the chain because this prompt happens to be loaded.
|
|
@@ -37,6 +37,31 @@ Confirm the current repository workflow contract before selecting release intent
|
|
|
37
37
|
- **minor** — new features, new slices, non-breaking additions
|
|
38
38
|
- **patch** — bug fixes, refactoring with identical behavior
|
|
39
39
|
|
|
40
|
+
### A major release needs a human's explicit go-ahead
|
|
41
|
+
|
|
42
|
+
A `major` label is the one release-intent label a ship request does not, by
|
|
43
|
+
itself, authorize through to merge. Breaking a public API is the most
|
|
44
|
+
consequential and hardest-to-reverse thing a release does — every downstream
|
|
45
|
+
consumer eventually has to act on it — so it gets a checkpoint the other two
|
|
46
|
+
intents do not.
|
|
47
|
+
|
|
48
|
+
- Prepare the branch, commits, push, and PR carrying the `major` label exactly
|
|
49
|
+
as any other ship request would.
|
|
50
|
+
- Before merging, stop and ask a human to confirm the major bump specifically:
|
|
51
|
+
name the exact breaking change(s), who is affected and how, and the
|
|
52
|
+
resulting version number. A generic "ready to ship?" is not this checkpoint —
|
|
53
|
+
say plainly that this release breaks compatibility and needs a yes.
|
|
54
|
+
- Proceed to merge only on an explicit, affirmative answer to that question.
|
|
55
|
+
A prior general instruction to "ship" or "land this" does not answer it,
|
|
56
|
+
even when it named `major` as the intended label.
|
|
57
|
+
- This checkpoint is per release, not per conversation — a human confirming
|
|
58
|
+
one major release does not pre-authorize the next one.
|
|
59
|
+
|
|
60
|
+
This narrows the general ship-changes authorization in
|
|
61
|
+
[`ship-changes.prompt.md`](../prompts/ship-changes.prompt.md) for exactly this
|
|
62
|
+
label; every other step of that workflow proceeds under its existing
|
|
63
|
+
authority.
|
|
64
|
+
|
|
40
65
|
### A pull request that changes nothing outward-facing carries `no-release`
|
|
41
66
|
|
|
42
67
|
**If nothing in the PR can change what a consumer compiles against, runs, or observes, propose repository-supported non-release intent, ordinarily `no-release`** — not `patch`. Confirm that the current workflow supports the label, requires exactly one release-intent label, and suppresses publication as intended before applying it with authorization.
|