You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: AGENTS.md
+113Lines changed: 113 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,6 +14,11 @@ The app should be treated as a trusted local control agent. Be conservative with
14
14
- Keep pull requests tightly scoped to one issue wherever possible.
15
15
- Do not mix implementation work with broad refactors unless the issue explicitly calls for it.
16
16
- Prefer existing project patterns once the app scaffold exists.
17
+
- Before creating a milestone, verify whether the intended milestone already exists.
18
+
- Reuse an existing open milestone instead of creating a duplicate.
19
+
- Create a release milestone only when it is missing.
20
+
- Do not create future release milestones casually. The active release milestone should normally be the next version after `package.json`.
21
+
- Before release work starts, verify the target milestone name exactly matches the version being released, for example `Release 0.1.8` for `package.json` version `0.1.8`.
17
22
18
23
## Development standards
19
24
@@ -82,6 +87,8 @@ Only the maintainer should publish releases.
82
87
83
88
Release builds are published from tags named `vX.Y.Z`, where `X.Y.Z` must match `package.json`.
84
89
90
+
Before creating a release milestone, verify whether the intended milestone already exists. Reuse an existing open milestone. Create the milestone only if it is missing. If the milestone exists but is closed, reopen it only when the work truly belongs in that release.
91
+
85
92
The release workflow is `.github/workflows/release.yml`. It runs on the self-hosted Windows signing runner with the `switchify-signing` label. The runner is expected to have:
gh api repos/switchifyapp/switchify-pc/milestones -f title=$nextMilestone
171
+
}
172
+
```
173
+
174
+
If the thumbprint is available only as a GitHub repository variable, the maintainer may verify that the variable exists without printing its value, then verify the local certificate with the thumbprint supplied privately.
175
+
104
176
The release workflow:
105
177
106
178
- installs dependencies with `npm ci`
@@ -136,6 +208,47 @@ git push origin vX.Y.Z
136
208
137
209
The workflow can also be dispatched manually by the maintainer with a `tag` input.
138
210
211
+
Do not push a release tag until the release PR with the matching version bump has merged to `main` and local `main` has been pulled.
212
+
213
+
Do not tag if:
214
+
215
+
-`package.json` does not match the intended tag.
216
+
- The release issue or PR milestone does not match `Release X.Y.Z`.
217
+
- The signing runner is offline or busy.
218
+
- The Certum certificate cannot be verified locally.
219
+
220
+
After the release workflow succeeds:
221
+
222
+
1. Verify the GitHub Release exists for `vX.Y.Z`.
223
+
2. Verify the release assets are present:
224
+
-`Switchify-PC-Setup-X.Y.Z-x64.exe`
225
+
-`latest.yml`
226
+
-`builder-debug.yml`
227
+
3. Verify there are no open issues in milestone `Release X.Y.Z`.
228
+
4. Close milestone `Release X.Y.Z`.
229
+
5. If issues remain open, do not close the milestone; report the blockers.
230
+
231
+
Use commands like these for post-release verification and milestone closure:
0 commit comments