clover's git

the-knife

1	---
2	name: changesets
3	description: Concise PR finalization changesets. Use when implementation scope is complete and focused validation has finished to classify release impact, consolidate the PR's existing changeset, or write its consumer release note.
4	---
5
6	Treat a changeset as the release note for the complete PR, not as a log of work
7	performed along the way. Finalize it after the current implementation scope and
8	focused validation are complete.
9
10	## Workflow
11
12	1. Inspect the complete diff from the merge base, including changeset files
13	already introduced by the PR, and identify directly affected published
14	packages.
15	2. Classify impact across source types, runtime behavior, entrypoints, required
16	services, lifecycle, and persisted or wire data.
17	3. Perform the breaking audit below.
18	4. Record a reason no changeset is required, or update the PR's existing
19	changeset. Create one only when the PR does not have one. When required, read
20	[authoring.md](authoring.md).
21	5. Validate package names, frontmatter, bump policy, and a concise
22	consumer-facing description.
23
24	Do not include unrelated worktree changes.
25
26	## PR-level consolidation
27
28	The default is one changeset file per PR. One file can name several packages and
29	summarize several related fixes or additions. Successive prompts, commits, and
30	subtasks within the same PR update that file. If implementation resumes after a
31	changeset was drafted, revise it during the next finalization pass.
32
33	Use separate files only when a maintainer requests the split or the PR contains
34	independent changes that need separate release notes.
35
36	## Requirement
37
38	Create a changeset for observable runtime behavior changes, including bug
39	fixes; exported value or public type changes; entrypoint or export-map changes;
40	changes to required services, errors, ownership, defaults, or lifecycle; and
41	persisted, serialization, protocol, or wire-format changes.
42
43	Tests-only changes, behavior-preserving internal refactors, documentation or
44	JSDoc maintenance, and unpublished tooling normally do not need one. When
45	unclear, inspect exports and consumer-visible declarations rather than inferring
46	from source location.
47
48	## Breaking Audit
49
50	A change is breaking when valid existing consumer code, configuration, or data
51	must change to keep compiling or behaving according to the previous contract.
52	Audit every surface:
53
54	- **Names and locations:** exports, entrypoints, compatibility exports, and
55	module paths.
56	- **Call compatibility:** parameters, accepted inputs, overload resolution,
57	generic parameters, and defaults.
58	- **Result compatibility:** return and error types, output narrowing, members,
59	inference, and required services.
60	- **Runtime contracts:** defaults, failures, interruption, concurrency,
61	ordering, resource lifetime, acquisition, cleanup, and mutation.
62	- **Data compatibility:** persisted schemas, encodings, database layouts,
63	protocols, and wire formats.
64
65	Additive exports, optional parameters, and behavior-preserving implementations
66	are normally non-breaking. A fix restoring the documented contract is normally
67	non-breaking but still needs a changeset when its operational impact is
68	consumer-visible. Verify representative existing calls when overload ordering,
69	structural assignability, or inference makes compatibility uncertain. API diff
70	output is mechanical evidence, not a semantic-version decision.
71
72	The task is complete when every affected contract and published package is
73	accounted for and either the no-changeset decision is explicit or the PR has one
74	consolidated, valid changeset by default. Its release note describes the consumer
75	impact and migration for every break without repeating the PR description.