@sigitcodereview / sigit / commits / 64e12ca

docs: align winget release docs with workflow details

Refine the winget section of AGENTS.md to match what release-winget.yml actually does: document the |x64/|arm64 URL suffix that wingetcreate needs to match installer entries (without it, 'sigit-win-amd64.exe' is not a spelling it recognises), the SHA256 uppercase convention for the first-submission render path, and the --release-date/--release-notes-url/ --submit/--no-open flags the update path passes explicitly. Simplify the PAT description — the classic-PAT requirement is already covered by the release skill. Co-Authored-By: siGit Code v1.5.12-acp <noreply@sigit.si>

Seto Elkahfi committed Oct 4, 2026 at 12:33 UTC 64e12cae9b5adeb80babf12ba7afcdec52440626

1 file changed +14 -10

.agents/AGENTS.md

+14 -10

@@ -376,16 +376,20 @@ Three of these need credentials or a one-time manual step before they work:

376

377 - Scoop needs a `getsigit/scoop-bucket` repo and a `SCOOP_BUCKET_TOKEN` secret, mirroring the

378 Homebrew tap setup.

379 -- winget needs a `WINGET_TOKEN` (**classic PAT** with `public_repo` scope, not a

380 - fine-grained PAT — a fine-grained PAT is scoped to specific repos and cannot fork

381 - `microsoft/winget-pkgs`, which lives outside its scope; v1.5.13 failed eight times on

382 - this) so `wingetcreate` can fork `microsoft/winget-pkgs`. It is passed as

383 - `WINGET_CREATE_GITHUB_TOKEN` rather than `--token`,

384 - which wingetcreate warns can leak the token into logs. `wingetcreate update` only works on a

385 - package that already exists in `microsoft/winget-pkgs`, so the workflow checks the

386 - `manifests/g/getSigit/siGitCode` path first and falls back to rendering

387 - `packaging/winget/*.yaml.in` and running `wingetcreate submit` for a first submission. That

388 - fallback runs once, then every later release takes the `update` path.

379 +- winget needs a `WINGET_TOKEN` (PAT with `public_repo` scope) so `wingetcreate` can fork

380 + `microsoft/winget-pkgs` and open the manifest PR. It is passed as

381 + `WINGET_CREATE_GITHUB_TOKEN` rather than `--token`, which wingetcreate warns can leak the

382 + token into logs. `wingetcreate update` only works on a package that already exists in

383 + `microsoft/winget-pkgs`, so the workflow checks the `manifests/g/getSigit/siGitCode` path

384 + first and falls back to rendering `packaging/winget/*.yaml.in` and running

385 + `wingetcreate submit` for a first submission. That fallback runs once, then every later

386 + release takes the `update` path. Two non-obvious things in the update path: the `--urls`

387 + arguments carry a trailing `|x64` / `|arm64` suffix that tells wingetcreate which installer

388 + entry each URL replaces — without it, wingetcreate guesses from the file name, and

389 + "sigit-win-amd64.exe" is not a spelling it recognises; and the first-submission render

390 + uppercases the SHA256 (`tr '[:lower:]' '[:upper:]'`) to match the community validation

391 + pipeline, which writes 64-hex checksums uppercase. The update path also passes

392 + `--release-date`, `--release-notes-url`, `--submit`, and `--no-open` explicitly.

393 - The AUR needs `AUR_USERNAME`, `AUR_EMAIL`, and `AUR_SSH_PRIVATE_KEY`. It publishes `sigit-bin`

394 (a prebuilt binary) so Arch users are not compiling the on-device inference stack to install a

395 CLI.