sigit-code 1.6.7__tar.gz → 1.6.9__tar.gz

{sigit_code-1.6.7 → sigit_code-1.6.9}/.agents/AGENTS.md

@@ -502,8 +502,13 @@ Three of these need credentials or a one-time manual step before they work:
 
 - Scoop needs a `getsigit/scoop-bucket` repo and a `SCOOP_BUCKET_TOKEN` secret, mirroring the
   Homebrew tap setup.
-- winget needs a `WINGET_TOKEN` (PAT with `public_repo` scope) so `wingetcreate` can fork
-  `microsoft/winget-pkgs` and open the manifest PR. It is passed as
+- winget files a Package Request issue first and then opens the manifest PR that resolves it,
+  authored by two separate classic PATs (replacing the old single `WINGET_TOKEN`):
+  `WINGET_ISSUE_TOKEN` (`public_repo`) for the issue and `WINGET_PR_TOKEN` for the PR.
+  `WINGET_PR_TOKEN` needs `public_repo` plus `read:org` and `read:discussion`: `public_repo`
+  lets `wingetcreate` fork `microsoft/winget-pkgs` and open the PR, and the later `gh pr edit`
+  that sets the PR body runs a GraphQL query resolving org/team and discussion fields that
+  fails with a scope error on a `public_repo`-only token. The PR token is passed as
   `WINGET_CREATE_GITHUB_TOKEN` rather than `--token`, which wingetcreate warns can leak the
   token into logs. `wingetcreate update` only works on a package that already exists in
   `microsoft/winget-pkgs`, so the workflow checks the `manifests/g/getSigit/siGitCode` path

{sigit_code-1.6.7 → sigit_code-1.6.9}/.agents/skills/sigit-code-release/SKILL.md

@@ -38,12 +38,18 @@ Use this skill when preparing a release for this repository.
 - The GitHub release body is generated, not hand-written: `release-github.yml`'s release job checks out the tag, awk-extracts the `## <version>` section from `CHANGELOG.md` (a missing section is a hard failure), appends a full-changelog link and a `sigit.si/code` footnote, and publishes it via `body_path: release_notes.md`. The only file a release-prep change needs to touch is `CHANGELOG.md` — never edit release notes in the GitHub UI, because the next tag push would overwrite them.
 - npm and NuGet publish via OIDC trusted publishing — neither has a stored token in the repo. On npm this is configured per package (each `@getsigit/*` name has a trusted publisher pointing at `release-npm.yml`), so a new package needs the same setup before its first publish will work. OIDC requires npm >= 11.5.1 and Node >= 22.14.0.
 - The NuGet package (`SiGit.Code`, `dotnet tool install --global SiGit.Code`) bundles all six platform binaries under `native/<os>-<arch>/` behind a managed shim, rather than shipping one package per platform like npm/PyPI. Watch the nuget.org 250 MB package-size limit if it ever grows.
-- The winget channel (`release-winget.yml`) needs a `WINGET_TOKEN` secret that is a **classic PAT** with `public_repo` scope — not a fine-grained PAT. wingetcreate forks `microsoft/winget-pkgs` on first use and submits a PR from that fork; a fine-grained PAT scoped to `getsigit/sigit` cannot fork a repo outside its scope and every release fails with a 403/404 on the fork step. The token is passed as `WINGET_CREATE_GITHUB_TOKEN` (not `--token`) so it doesn't leak into logs. `wingetcreate update` only works on a package that already exists in `microsoft/winget-pkgs`, so the workflow checks `manifests/g/getSigit/siGitCode` first and falls back to `wingetcreate submit` with `packaging/winget/*.yaml.in` for the first release; every later release takes the `update` path. If a winget release fails with a fork/permission error, check the `WINGET_TOKEN` secret type before re-dispatching.
+- The winget channel (`release-winget.yml`) files a Package Request issue first and then opens the manifest PR that resolves it, authored by **two separate classic PATs** (not fine-grained) — `WINGET_ISSUE_TOKEN` for the issue and `WINGET_PR_TOKEN` for the PR, replacing the old single `WINGET_TOKEN`. `WINGET_ISSUE_TOKEN` needs `public_repo`. `WINGET_PR_TOKEN` needs `public_repo` **plus `read:org` and `read:discussion`**: wingetcreate forks `microsoft/winget-pkgs` and opens the PR (fork needs `public_repo`; a fine-grained PAT scoped to `getsigit/sigit` can't fork an outside repo and 403/404s), and the "Set the winget PR body" step then runs `gh pr edit`, whose GraphQL query resolves org/team and discussion fields and fails with a scope error on a `public_repo`-only token (CI run 38262301933). The PR token is passed as `WINGET_CREATE_GITHUB_TOKEN` (not `--token`) so it doesn't leak into logs. `wingetcreate update` only works on a package that already exists in `microsoft/winget-pkgs`, so the workflow checks `manifests/g/getSigit/siGitCode` first and falls back to `wingetcreate submit` with `packaging/winget/*.yaml.in` for the first release; every later release takes the `update` path. If a winget release fails on the fork step, check the token type; if it fails on the `gh pr edit` step with a scope error, check `WINGET_PR_TOKEN`'s scopes before re-dispatching.
 - The baked-in official MCP server is separately listed in the public MCP Registry as `si.sigit/sigit` (`release-mcp-registry.yml`, driven by `server.json` at the repo root). It's a remote Streamable-HTTP listing, so it's verified by a DNS TXT record on the `sigit.si` domain rather than the GitHub-OIDC scheme used for package listings.
 
 ## Git release flow
 
-Releases are cut from `development` and shipped on `main`. The published tags (`v1.2.0`, `v1.2.1`) point at the `main`-side merge commit, never at a release branch or at `development`. Follow this order:
+Releases are shipped on `main`, and the published tags (`v1.2.0`, `v1.2.1`) point at the
+`main`-side merge commit, never at a release branch or at `development`. There are two flows,
+and picking the wrong one ships the wrong set of commits. Decide first which this is.
+
+### Full release (minor/major — ships everything on `development`)
+
+Cut from `development` when the release is meant to carry all the work that has accumulated there.
 
 1. Branch `release/v<version>` off `development`.
 2. Apply the version bump and changelog edits, then commit (e.g. `Release v<version>`).
@@ -51,10 +57,38 @@ Releases are cut from `development` and shipped on `main`. The published tags (`
 4. Merge `development` into `main` (commit message: `Merge development into main for v<version> release`).
 5. Tag `v<version>` on that `main` merge commit, then push `main` and the tag.
 
-Step 4 is the only way commits are meant to reach `main`. A feature or fix PR targeting `main` breaks that: it puts work on the release branch that `development` does not have, so the next release is cut without it. Such PRs belong on `development` (see the pull request target rule in `AGENTS.md`).
+For a full release, step 4 is the only way commits are meant to reach `main`. A feature or fix
+PR targeting `main` breaks that: it puts work on the release branch that `development` does not
+have, so the next release is cut without it. Such PRs belong on `development` (see the pull
+request target rule in `AGENTS.md`).
+
+### Scoped patch (hotfix — ships only specific fixes on top of the last tag)
+
+Use this when the patch must ship **only** a named set of fixes on top of the last released tag,
+**not** the unreleased work sitting on `development` (e.g. a patch over `v1.6.7` that must carry
+just a winget/Windows hotfix while ACP features stay unreleased). The giveaway is wording like
+"scoped patch off `v<prev>`" or "hotfix" — if `development` is far ahead, a `development → main`
+merge would drag all of it out under a patch tag, which is wrong.
+
+1. Branch `release/v<version>` off the **last released tag** (`v<prev>`), not `development`.
+2. Cherry-pick (or commit) only the in-scope fixes, then the version bump + changelog, and commit
+   (e.g. `Release v<version>`).
+3. Merge `release/v<version>` back into `development` so the bump and changelog carry forward.
+4. Merge `release/v<version>` **directly into `main`** (commit message: `Release v<version>`) —
+   **never `development → main` for a scoped patch**, since that would pull `development`'s
+   unreleased work onto `main`.
+5. Tag `v<version>` on that `main` merge commit, then push `main` and the tag.
+
+Before tagging a scoped patch, audit the scope: `git log --oneline v<prev>^{commit}..main` and
+`git diff --stat v<prev>^{commit}..main` must show only the intended fixes and the release
+metadata files (`Cargo.toml`, `Cargo.lock`, `CHANGELOG.md`), nothing from `development`.
 
 Pushing the `v*.*.*` tag is what fires every release workflow, so create and push it only after the merge into `main` has landed. Do not commit, tag, or push until the user explicitly asks — confirm the version and that they want the release to go out first.
 
+Decide up front which flow you are in and confirm the exact scope with the user. If in doubt about
+whether a release ships everything on `development` or only a scoped set of fixes, ask — the two
+flows start from different base commits and are not interchangeable.
+
 ## Typical files to inspect
 
 - `Cargo.toml`
@@ -79,10 +113,12 @@ Pushing the `v*.*.*` tag is what fires every release workflow, so create and pus
 - `npm/sigit/package.json` is left at `0.0.0-dev` unless the packaging flow itself changed.
 - `pypi/pyproject.toml` still uses dynamic versioning unless there is a deliberate packaging change.
 - Release workflows still derive their version from the tag as expected.
-- Git flow followed: bump committed on `release/v<version>`, merged back to `development`, then `development` merged into `main`, with `v<version>` tagged on the `main` merge commit.
+- Correct git flow for the release type followed, with `v<version>` tagged on the `main` merge commit either way:
+  - **Full release:** bump committed on `release/v<version>` (off `development`), merged back to `development`, then `development` merged into `main`.
+  - **Scoped patch:** `release/v<version>` branched off the last tag `v<prev>`, in-scope fixes + bump committed, merged back to `development`, then `release/v<version>` merged **directly into `main`** (never `development → main`), and the scope audited (`git log --oneline v<prev>^{commit}..main` / `git diff --stat v<prev>^{commit}..main`) to show only the intended fixes plus release metadata.
 - Release notes or changelog entries match the actual changes.
 - CI-equivalent local checks pass for the relevant platform or target.
 - Package names, install commands, and branding stay consistent across npm, PyPI, crates.io, Homebrew, NuGet, Scoop, winget, AUR, and the `.deb`/`.rpm` packages.
 - Every release asset (including the new `.deb`/`.rpm`/raw binaries consumed by Scoop, winget, and AUR) has a matching `.sha256` sidecar.
 - Any known release limitations are called out explicitly, including a dispatch failure in `release-scoop`/`release-winget`/`release-aur` (non-fatal — logged as a warning by `release-github.yml`) versus a hard failure in a directly tag-triggered workflow like `release-nuget` or `release-mcp-registry`.
-- The `WINGET_TOKEN` secret is a classic PAT with `public_repo` scope (not fine-grained), so wingetcreate can fork `microsoft/winget-pkgs`. If a winget release fails on the fork step, verify the token type before re-dispatching.
+- The winget channel uses two classic PATs (not fine-grained): `WINGET_ISSUE_TOKEN` (`public_repo`) for the Package Request issue and `WINGET_PR_TOKEN` (`public_repo` + `read:org` + `read:discussion`) for the manifest PR, so wingetcreate can fork `microsoft/winget-pkgs` and `gh pr edit` can set the PR body. If a winget release fails on the fork step, verify the token type; if it fails on the `gh pr edit` step, verify `WINGET_PR_TOKEN`'s scopes before re-dispatching.

{sigit_code-1.6.7 → sigit_code-1.6.9}/.claude/skills/sigit-code-release/SKILL.md

@@ -38,12 +38,18 @@ Use this skill when preparing a release for this repository.
 - The GitHub release body is generated, not hand-written: `release-github.yml`'s release job checks out the tag, awk-extracts the `## <version>` section from `CHANGELOG.md` (a missing section is a hard failure), appends a full-changelog link and a `sigit.si/code` footnote, and publishes it via `body_path: release_notes.md`. The only file a release-prep change needs to touch is `CHANGELOG.md` — never edit release notes in the GitHub UI, because the next tag push would overwrite them.
 - npm and NuGet publish via OIDC trusted publishing — neither has a stored token in the repo. On npm this is configured per package (each `@getsigit/*` name has a trusted publisher pointing at `release-npm.yml`), so a new package needs the same setup before its first publish will work. OIDC requires npm >= 11.5.1 and Node >= 22.14.0.
 - The NuGet package (`SiGit.Code`, `dotnet tool install --global SiGit.Code`) bundles all six platform binaries under `native/<os>-<arch>/` behind a managed shim, rather than shipping one package per platform like npm/PyPI. Watch the nuget.org 250 MB package-size limit if it ever grows.
-- The winget channel (`release-winget.yml`) needs a `WINGET_TOKEN` secret that is a **classic PAT** with `public_repo` scope — not a fine-grained PAT. wingetcreate forks `microsoft/winget-pkgs` on first use and submits a PR from that fork; a fine-grained PAT scoped to `getsigit/sigit` cannot fork a repo outside its scope and every release fails with a 403/404 on the fork step. The token is passed as `WINGET_CREATE_GITHUB_TOKEN` (not `--token`) so it doesn't leak into logs. `wingetcreate update` only works on a package that already exists in `microsoft/winget-pkgs`, so the workflow checks `manifests/g/getSigit/siGitCode` first and falls back to `wingetcreate submit` with `packaging/winget/*.yaml.in` for the first release; every later release takes the `update` path. If a winget release fails with a fork/permission error, check the `WINGET_TOKEN` secret type before re-dispatching.
+- The winget channel (`release-winget.yml`) files a Package Request issue first and then opens the manifest PR that resolves it, authored by **two separate classic PATs** (not fine-grained) — `WINGET_ISSUE_TOKEN` for the issue and `WINGET_PR_TOKEN` for the PR, replacing the old single `WINGET_TOKEN`. `WINGET_ISSUE_TOKEN` needs `public_repo`. `WINGET_PR_TOKEN` needs `public_repo` **plus `read:org` and `read:discussion`**: wingetcreate forks `microsoft/winget-pkgs` and opens the PR (fork needs `public_repo`; a fine-grained PAT scoped to `getsigit/sigit` can't fork an outside repo and 403/404s), and the "Set the winget PR body" step then runs `gh pr edit`, whose GraphQL query resolves org/team and discussion fields and fails with a scope error on a `public_repo`-only token (CI run 38262301933). The PR token is passed as `WINGET_CREATE_GITHUB_TOKEN` (not `--token`) so it doesn't leak into logs. `wingetcreate update` only works on a package that already exists in `microsoft/winget-pkgs`, so the workflow checks `manifests/g/getSigit/siGitCode` first and falls back to `wingetcreate submit` with `packaging/winget/*.yaml.in` for the first release; every later release takes the `update` path. If a winget release fails on the fork step, check the token type; if it fails on the `gh pr edit` step with a scope error, check `WINGET_PR_TOKEN`'s scopes before re-dispatching.
 - The baked-in official MCP server is separately listed in the public MCP Registry as `si.sigit/sigit` (`release-mcp-registry.yml`, driven by `server.json` at the repo root). It's a remote Streamable-HTTP listing, so it's verified by a DNS TXT record on the `sigit.si` domain rather than the GitHub-OIDC scheme used for package listings.
 
 ## Git release flow
 
-Releases are cut from `development` and shipped on `main`. The published tags (`v1.2.0`, `v1.2.1`) point at the `main`-side merge commit, never at a release branch or at `development`. Follow this order:
+Releases are shipped on `main`, and the published tags (`v1.2.0`, `v1.2.1`) point at the
+`main`-side merge commit, never at a release branch or at `development`. There are two flows,
+and picking the wrong one ships the wrong set of commits. Decide first which this is.
+
+### Full release (minor/major — ships everything on `development`)
+
+Cut from `development` when the release is meant to carry all the work that has accumulated there.
 
 1. Branch `release/v<version>` off `development`.
 2. Apply the version bump and changelog edits, then commit (e.g. `Release v<version>`).
@@ -51,10 +57,38 @@ Releases are cut from `development` and shipped on `main`. The published tags (`
 4. Merge `development` into `main` (commit message: `Merge development into main for v<version> release`).
 5. Tag `v<version>` on that `main` merge commit, then push `main` and the tag.
 
-Step 4 is the only way commits are meant to reach `main`. A feature or fix PR targeting `main` breaks that: it puts work on the release branch that `development` does not have, so the next release is cut without it. Such PRs belong on `development` (see the pull request target rule in `AGENTS.md`).
+For a full release, step 4 is the only way commits are meant to reach `main`. A feature or fix
+PR targeting `main` breaks that: it puts work on the release branch that `development` does not
+have, so the next release is cut without it. Such PRs belong on `development` (see the pull
+request target rule in `AGENTS.md`).
+
+### Scoped patch (hotfix — ships only specific fixes on top of the last tag)
+
+Use this when the patch must ship **only** a named set of fixes on top of the last released tag,
+**not** the unreleased work sitting on `development` (e.g. a patch over `v1.6.7` that must carry
+just a winget/Windows hotfix while ACP features stay unreleased). The giveaway is wording like
+"scoped patch off `v<prev>`" or "hotfix" — if `development` is far ahead, a `development → main`
+merge would drag all of it out under a patch tag, which is wrong.
+
+1. Branch `release/v<version>` off the **last released tag** (`v<prev>`), not `development`.
+2. Cherry-pick (or commit) only the in-scope fixes, then the version bump + changelog, and commit
+   (e.g. `Release v<version>`).
+3. Merge `release/v<version>` back into `development` so the bump and changelog carry forward.
+4. Merge `release/v<version>` **directly into `main`** (commit message: `Release v<version>`) —
+   **never `development → main` for a scoped patch**, since that would pull `development`'s
+   unreleased work onto `main`.
+5. Tag `v<version>` on that `main` merge commit, then push `main` and the tag.
+
+Before tagging a scoped patch, audit the scope: `git log --oneline v<prev>^{commit}..main` and
+`git diff --stat v<prev>^{commit}..main` must show only the intended fixes and the release
+metadata files (`Cargo.toml`, `Cargo.lock`, `CHANGELOG.md`), nothing from `development`.
 
 Pushing the `v*.*.*` tag is what fires every release workflow, so create and push it only after the merge into `main` has landed. Do not commit, tag, or push until the user explicitly asks — confirm the version and that they want the release to go out first.
 
+Decide up front which flow you are in and confirm the exact scope with the user. If in doubt about
+whether a release ships everything on `development` or only a scoped set of fixes, ask — the two
+flows start from different base commits and are not interchangeable.
+
 ## Typical files to inspect
 
 - `Cargo.toml`
@@ -79,10 +113,12 @@ Pushing the `v*.*.*` tag is what fires every release workflow, so create and pus
 - `npm/sigit/package.json` is left at `0.0.0-dev` unless the packaging flow itself changed.
 - `pypi/pyproject.toml` still uses dynamic versioning unless there is a deliberate packaging change.
 - Release workflows still derive their version from the tag as expected.
-- Git flow followed: bump committed on `release/v<version>`, merged back to `development`, then `development` merged into `main`, with `v<version>` tagged on the `main` merge commit.
+- Correct git flow for the release type followed, with `v<version>` tagged on the `main` merge commit either way:
+  - **Full release:** bump committed on `release/v<version>` (off `development`), merged back to `development`, then `development` merged into `main`.
+  - **Scoped patch:** `release/v<version>` branched off the last tag `v<prev>`, in-scope fixes + bump committed, merged back to `development`, then `release/v<version>` merged **directly into `main`** (never `development → main`), and the scope audited (`git log --oneline v<prev>^{commit}..main` / `git diff --stat v<prev>^{commit}..main`) to show only the intended fixes plus release metadata.
 - Release notes or changelog entries match the actual changes.
 - CI-equivalent local checks pass for the relevant platform or target.
 - Package names, install commands, and branding stay consistent across npm, PyPI, crates.io, Homebrew, NuGet, Scoop, winget, AUR, and the `.deb`/`.rpm` packages.
 - Every release asset (including the new `.deb`/`.rpm`/raw binaries consumed by Scoop, winget, and AUR) has a matching `.sha256` sidecar.
 - Any known release limitations are called out explicitly, including a dispatch failure in `release-scoop`/`release-winget`/`release-aur` (non-fatal — logged as a warning by `release-github.yml`) versus a hard failure in a directly tag-triggered workflow like `release-nuget` or `release-mcp-registry`.
-- The `WINGET_TOKEN` secret is a classic PAT with `public_repo` scope (not fine-grained), so wingetcreate can fork `microsoft/winget-pkgs`. If a winget release fails on the fork step, verify the token type before re-dispatching.
+- The winget channel uses two classic PATs (not fine-grained): `WINGET_ISSUE_TOKEN` (`public_repo`) for the Package Request issue and `WINGET_PR_TOKEN` (`public_repo` + `read:org` + `read:discussion`) for the manifest PR, so wingetcreate can fork `microsoft/winget-pkgs` and `gh pr edit` can set the PR body. If a winget release fails on the fork step, verify the token type; if it fails on the `gh pr edit` step, verify `WINGET_PR_TOKEN`'s scopes before re-dispatching.

sigit_code-1.6.9/.github/workflows/release-winget.yml

@@ -0,0 +1,328 @@
+name: winget Release
+
+# Dispatched by release-github.yml once the release and its checksums exist.
+#
+# winget manifests live in microsoft/winget-pkgs, and `wingetcreate update`
+# only works on a package that is already there. So this workflow branches:
+#
+#   - package already in winget-pkgs -> `wingetcreate update`, which rewrites
+#     the URLs and re-hashes the installers for us.
+#   - package not there yet -> render the manifests in packaging/winget/ and
+#     `wingetcreate submit` them as a new package.
+#
+# The second path only runs once, but keeping it here means a first release
+# does not need someone to sit at a Windows box running `wingetcreate new`
+# interactively.
+on:
+  workflow_dispatch:
+    inputs:
+      tag:
+        description: "Release tag (e.g. v1.5.2)"
+        required: true
+
+concurrency:
+  # A re-pushed or re-dispatched tag fires this a second time. Queue the
+  # duplicate behind the original instead of cancelling it: cancelling a run
+  # mid-publish can leave a channel half-uploaded, whereas a queued duplicate
+  # just hits the "already published" check and exits clean.
+  group: ${{ github.workflow }}-${{ github.event.inputs.tag || github.ref_name }}
+  cancel-in-progress: false
+
+permissions:
+  contents: read
+
+env:
+  REPO: getsigit/sigit
+  PACKAGE_IDENTIFIER: getSigit.siGitCode
+
+jobs:
+  submit-winget-manifest:
+    name: Submit winget manifest
+    # wingetcreate is a Windows-only tool.
+    runs-on: windows-latest
+
+    steps:
+      - name: Check out repository
+        uses: actions/checkout@v6
+
+      - name: Resolve tag, version and release date
+        id: release
+        shell: bash
+        env:
+          GH_TOKEN: ${{ github.token }}
+        run: |
+          TAG="${{ github.event.inputs.tag }}"
+          VERSION="${TAG#v}"
+          # wingetcreate wants ReleaseDate as YYYY-MM-DD.
+          DATE=$(gh release view "$TAG" --repo "$REPO" --json publishedAt --jq '.publishedAt[0:10]')
+
+          echo "tag=${TAG}" >> "$GITHUB_OUTPUT"
+          echo "version=${VERSION}" >> "$GITHUB_OUTPUT"
+          echo "date=${DATE}" >> "$GITHUB_OUTPUT"
+
+      - name: Check whether the package is already in winget-pkgs
+        id: exists
+        shell: bash
+        env:
+          GH_TOKEN: ${{ github.token }}
+        run: |
+          # manifests are filed under the lowercased first letter of the
+          # publisher, e.g. manifests/g/getSigit/siGitCode.
+          PUBLISHER="${PACKAGE_IDENTIFIER%%.*}"
+          NAME="${PACKAGE_IDENTIFIER#*.}"
+          FIRST=$(echo "${PUBLISHER:0:1}" | tr '[:upper:]' '[:lower:]')
+          PATH_IN_REPO="manifests/${FIRST}/${PUBLISHER}/${NAME}"
+
+          if gh api "repos/microsoft/winget-pkgs/contents/${PATH_IN_REPO}" >/dev/null 2>&1; then
+            echo "Found ${PACKAGE_IDENTIFIER} at ${PATH_IN_REPO}; submitting an update."
+            echo "found=true" >> "$GITHUB_OUTPUT"
+          else
+            echo "No ${PACKAGE_IDENTIFIER} at ${PATH_IN_REPO}; submitting it as a new package."
+            echo "found=false" >> "$GITHUB_OUTPUT"
+          fi
+
+      - name: Render manifests for a first submission
+        if: steps.exists.outputs.found == 'false'
+        shell: bash
+        env:
+          GH_TOKEN: ${{ github.token }}
+        run: |
+          TAG="${{ steps.release.outputs.tag }}"
+          VERSION="${{ steps.release.outputs.version }}"
+
+          mkdir -p artifacts manifests
+
+          gh release download "$TAG" \
+            --repo "$REPO" \
+            --pattern "sigit-win-*.exe.sha256" \
+            --dir artifacts/
+
+          # The schema wants 64 hex characters; the community validation
+          # pipeline writes them uppercase, so match that.
+          SHA_AMD64=$(tr -d '[:space:]' < artifacts/sigit-win-amd64.exe.sha256 | tr '[:lower:]' '[:upper:]')
+          SHA_ARM64=$(tr -d '[:space:]' < artifacts/sigit-win-arm64.exe.sha256 | tr '[:lower:]' '[:upper:]')
+
+          RELEASE_DATE="${{ steps.release.outputs.date }}"
+
+          for template in packaging/winget/*.yaml.in; do
+            out="manifests/$(basename "$template" .in)"
+            sed \
+              -e "s|@VERSION@|${VERSION}|g" \
+              -e "s|@TAG@|${TAG}|g" \
+              -e "s|@REPO@|${REPO}|g" \
+              -e "s|@SHA_AMD64@|${SHA_AMD64}|g" \
+              -e "s|@SHA_ARM64@|${SHA_ARM64}|g" \
+              -e "s|@RELEASE_DATE@|${RELEASE_DATE}|g" \
+              "$template" > "$out"
+
+            echo "--- ${out} ---"
+            cat "$out"
+          done
+
+      - name: Download wingetcreate
+        shell: pwsh
+        run: Invoke-WebRequest -Uri "https://aka.ms/wingetcreate/latest" -OutFile wingetcreate.exe
+
+      # winget-pkgs convention: file the "please add/update this package"
+      # Package Request issue *first*, then open the manifest PR that fulfils
+      # it with "Resolves #N". Doing it the other way round (PR first, issue
+      # after) reads as "here's a request, and here's the PR that already did
+      # it", posted seconds apart.
+      #
+      # The issue and the PR are authored by two separate PATs, configured as
+      # the repo secrets WINGET_ISSUE_TOKEN (the Package Request issue) and
+      # WINGET_PR_TOKEN (the manifest PR). Both need public_repo scope on
+      # microsoft/winget-pkgs (fork + open issues/PRs). WINGET_PR_TOKEN also
+      # needs read:org and read:discussion: the "Set the winget PR body" step
+      # below calls `gh pr edit`, whose GraphQL query resolves org/team and
+      # discussion fields and fails with a scope error without them.
+      # WINGET_PR_TOKEN replaces the old single WINGET_TOKEN.
+      - name: File the winget Package Request issue
+        id: issue
+        shell: bash
+        env:
+          # Authored by the issue account for this repo.
+          GH_TOKEN: ${{ secrets.WINGET_ISSUE_TOKEN }}
+        run: |
+          set -euo pipefail
+
+          if [ -z "${GH_TOKEN:-}" ]; then
+            echo "WINGET_ISSUE_TOKEN is not set. It needs a PAT (public_repo) for the account that should author the Package Request issue." >&2
+            exit 1
+          fi
+
+          VERSION="${{ steps.release.outputs.version }}"
+          TAG="${{ steps.release.outputs.tag }}"
+
+          # The release assets, same URLs the update step feeds wingetcreate.
+          BASE="https://github.com/${REPO}/releases/download/${TAG}"
+          INSTALLER_AMD64="${BASE}/sigit-win-amd64.exe"
+          INSTALLER_ARM64="${BASE}/sigit-win-arm64.exe"
+
+          # winget-pkgs' Package Request is an issue *form*
+          # (.github/ISSUE_TEMPLATE/package_request.yml): the title must be
+          # "[Package Request]: ..." and the body has to carry the labelled
+          # fields below (Installer Url especially — without it a maintainer
+          # just replies "please provide the installer link"). A free-text
+          # body lands as Needs-Triage and can't be acted on.
+          ISSUE_BODY=$(cat <<EOF
+          Download Page Url: https://github.com/${REPO}/releases/tag/${TAG}
+          Publisher: getSigit
+          Package Name: siGit Code
+          Description: siGit Code, an AI coding agent that runs on your machine.
+          Package Version: ${VERSION}
+          Installer Url: ${INSTALLER_AMD64}
+          Installer Url: ${INSTALLER_ARM64}
+          EOF
+          )
+
+          ISSUE_URL=$(gh issue create \
+            --repo microsoft/winget-pkgs \
+            --title "[Package Request]: ${PACKAGE_IDENTIFIER} ${VERSION}" \
+            --body "$ISSUE_BODY")
+
+          echo "Opened issue ${ISSUE_URL}"
+          echo "issue_url=${ISSUE_URL}" >> "$GITHUB_OUTPUT"
+          echo "issue_number=${ISSUE_URL##*/}" >> "$GITHUB_OUTPUT"
+
+      - name: Sebat dulu ...
+        if: steps.issue.outputs.issue_number != ''
+        shell: bash
+        run: sleep $(( RANDOM % 61 + 150 ))
+
+      - name: Submit new package
+        id: submit_new
+        if: steps.exists.outputs.found == 'false'
+        shell: pwsh
+        env:
+          # wingetcreate reads the token from this variable. Passing it as
+          # --token instead makes the tool warn that the token can end up in
+          # logs, which on a shared runner is not a warning worth ignoring.
+          # This is the PR-author account for this repo (see mapping above).
+          WINGET_CREATE_GITHUB_TOKEN: ${{ secrets.WINGET_PR_TOKEN }}
+        run: |
+          if (-not $env:WINGET_CREATE_GITHUB_TOKEN) {
+            Write-Error "WINGET_PR_TOKEN is not set. It needs a PAT with public_repo, read:org, and read:discussion scopes so wingetcreate can fork microsoft/winget-pkgs and open the manifest PR, and gh can edit the PR body."
+          }
+
+          $version = "${{ steps.release.outputs.version }}"
+
+          # Tee stdout so we can scrape the PR URL afterwards. wingetcreate
+          # prints "Pull request can be found here: <url>" on success, and
+          # that line is the only handle we get on the PR it just opened.
+          # --no-open because the runner has no browser to open the PR in.
+          .\wingetcreate.exe submit manifests `
+            --prtitle "New package: $env:PACKAGE_IDENTIFIER version $version" `
+            --no-open 2>&1 | Tee-Object -Variable output
+
+          if ($LASTEXITCODE -ne 0) {
+            Write-Error "wingetcreate submit failed with exit code $LASTEXITCODE"
+          }
+
+          $match = [regex]::Match(($output -join "`n"), 'https://github\.com/microsoft/winget-pkgs/pull/(\d+)')
+          if ($match.Success) {
+            "pr_url=$($match.Value)"   | Out-File -FilePath $env:GITHUB_OUTPUT -Append
+            "pr_number=$($match.Groups[1].Value)" | Out-File -FilePath $env:GITHUB_OUTPUT -Append
+          } else {
+            Write-Warning "Could not find the PR URL in wingetcreate output; skipping issue linking."
+          }
+
+      - name: Submit manifest update
+        id: submit_update
+        if: steps.exists.outputs.found == 'true'
+        shell: pwsh
+        env:
+          # PR-author account for this repo (see mapping above).
+          WINGET_CREATE_GITHUB_TOKEN: ${{ secrets.WINGET_PR_TOKEN }}
+        run: |
+          if (-not $env:WINGET_CREATE_GITHUB_TOKEN) {
+            Write-Error "WINGET_PR_TOKEN is not set. It needs a PAT with public_repo, read:org, and read:discussion scopes so wingetcreate can fork microsoft/winget-pkgs and open the manifest PR, and gh can edit the PR body."
+          }
+
+          $tag = "${{ steps.release.outputs.tag }}"
+          $version = "${{ steps.release.outputs.version }}"
+          $base = "https://github.com/${env:REPO}/releases/download/$tag"
+
+          # The trailing |x64 and |arm64 tell wingetcreate which installer
+          # entry each URL replaces. Without them it guesses from the file
+          # name, and "sigit-win-amd64.exe" is not a spelling it recognises.
+          .\wingetcreate.exe update $env:PACKAGE_IDENTIFIER `
+            --version $version `
+            --urls "$base/sigit-win-amd64.exe|x64" "$base/sigit-win-arm64.exe|arm64" `
+            --release-notes-url "https://github.com/${env:REPO}/releases/tag/$tag" `
+            --release-date "${{ steps.release.outputs.date }}" `
+            --prtitle "Update $env:PACKAGE_IDENTIFIER to version $version" `
+            --submit `
+            --no-open 2>&1 | Tee-Object -Variable output
+
+          if ($LASTEXITCODE -ne 0) {
+            Write-Error "wingetcreate failed with exit code $LASTEXITCODE"
+          }
+
+          $match = [regex]::Match(($output -join "`n"), 'https://github\.com/microsoft/winget-pkgs/pull/(\d+)')
+          if ($match.Success) {
+            "pr_url=$($match.Value)"   | Out-File -FilePath $env:GITHUB_OUTPUT -Append
+            "pr_number=$($match.Groups[1].Value)" | Out-File -FilePath $env:GITHUB_OUTPUT -Append
+          } else {
+            Write-Warning "Could not find the PR URL in wingetcreate output; skipping issue linking."
+          }
+
+      # wingetcreate has no --prbody flag (only --prtitle), so it always opens
+      # the PR with the winget-pkgs template: an empty Description and an
+      # unticked "Linked to an issue" box next to a "Resolves #[Issue Number]"
+      # placeholder. The issue already exists (filed first, above), so this
+      # step just rewrites the body to point the PR at it with "Resolves #N".
+      #
+      # This must run as the PR author (WINGET_PR_TOKEN) — the account that
+      # opened the PR via wingetcreate — since only the author (or a repo
+      # maintainer) can edit it.
+      - name: Set the winget PR body and link the issue
+        id: link
+        if: >-
+          (steps.submit_new.outputs.pr_number != '') ||
+          (steps.submit_update.outputs.pr_number != '')
+        shell: bash
+        env:
+          GH_TOKEN: ${{ secrets.WINGET_PR_TOKEN }}
+        run: |
+          set -euo pipefail
+
+          PR_URL="${{ steps.submit_new.outputs.pr_url || steps.submit_update.outputs.pr_url }}"
+          ISSUE_NUMBER="${{ steps.issue.outputs.issue_number }}"
+          VERSION="${{ steps.release.outputs.version }}"
+          TAG="${{ steps.release.outputs.tag }}"
+
+          if [ -n "$ISSUE_NUMBER" ]; then
+            CHECKBOX="- [x] Linked to an issue (if applicable)"
+            RESOLVES="- Resolves #${ISSUE_NUMBER}"
+          else
+            CHECKBOX="- [ ] Linked to an issue (if applicable)"
+            RESOLVES=""
+          fi
+
+          if [ "${{ steps.exists.outputs.found }}" = "false" ]; then
+            DESC="Adds ${PACKAGE_IDENTIFIER} version ${VERSION} from ${TAG}."
+          else
+            DESC="Updates ${PACKAGE_IDENTIFIER} to version ${VERSION} from ${TAG}."
+          fi
+
+          # Mirrors the current .github/PULL_REQUEST_TEMPLATE.md; keep the
+          # checklist items in sync with it (e.g. the 1.12 schema line).
+          BODY=$(cat <<EOF
+          ## 📖 Description
+          ${DESC}
+          ## ✅ Checklist
+          - [x] Signed the [Contributor License Agreement](https://cla.opensource.microsoft.com)
+          ${CHECKBOX}
+          ${RESOLVES}
+          ## 📦 Manifest Checklist
+          - [x] Checked that there aren't other open [pull requests](https://github.com/microsoft/winget-pkgs/pulls) for the same manifest update/change
+          - [x] This PR only modifies one (1) manifest
+          - [x] Validated manifest locally with \`winget validate --manifest <directory>\`
+          - [x] Tested manifest locally with \`winget install --manifest <directory>\`
+          - [x] Manifest conforms to the [1.12 schema](https://github.com/microsoft/winget-pkgs/tree/master/doc/manifest/schema/1.12.0)
+          EOF
+          )
+
+          gh pr edit "$PR_URL" --body "$BODY"
+          echo "Linked ${PR_URL} to issue #${ISSUE_NUMBER:-<none>}"

{sigit_code-1.6.7 → sigit_code-1.6.9}/AGENTS.md

@@ -502,8 +502,13 @@ Three of these need credentials or a one-time manual step before they work:
 
 - Scoop needs a `getsigit/scoop-bucket` repo and a `SCOOP_BUCKET_TOKEN` secret, mirroring the
   Homebrew tap setup.
-- winget needs a `WINGET_TOKEN` (PAT with `public_repo` scope) so `wingetcreate` can fork
-  `microsoft/winget-pkgs` and open the manifest PR. It is passed as
+- winget files a Package Request issue first and then opens the manifest PR that resolves it,
+  authored by two separate classic PATs (replacing the old single `WINGET_TOKEN`):
+  `WINGET_ISSUE_TOKEN` (`public_repo`) for the issue and `WINGET_PR_TOKEN` for the PR.
+  `WINGET_PR_TOKEN` needs `public_repo` plus `read:org` and `read:discussion`: `public_repo`
+  lets `wingetcreate` fork `microsoft/winget-pkgs` and open the PR, and the later `gh pr edit`
+  that sets the PR body runs a GraphQL query resolving org/team and discussion fields that
+  fails with a scope error on a `public_repo`-only token. The PR token is passed as
   `WINGET_CREATE_GITHUB_TOKEN` rather than `--token`, which wingetcreate warns can leak the
   token into logs. `wingetcreate update` only works on a package that already exists in
   `microsoft/winget-pkgs`, so the workflow checks the `manifests/g/getSigit/siGitCode` path

{sigit_code-1.6.7 → sigit_code-1.6.9}/CHANGELOG.md

@@ -1,5 +1,51 @@
 # Changelog
 
+## 1.6.9
+
+### Fixed
+
+- **Doubled-bar DSML markers survive inline tool-call recovery.** Some models
+  write `||name||args||` (and single-bar `|name|args|`) instead of the
+  underscore-form `__name__args__` that `inline_tool_calls` was matching.
+  These were being dropped from the recovered reply and from history, so the
+  model thought its call had run. The scanner now accepts both forms, and
+  a buffer that contains no doubled bar skips the regex fold entirely
+  instead of allocating an empty `String`.
+
+### Changed
+
+- **The release workflow is split into full-release and scoped-patch flows.**
+  `sigit-code-release` now leads with a scoped-patch path for one or two
+  commits on top of the last tag (no new release skill, no ACP advert,
+  no `## $version` requirement), then a full-release path for normal
+  development → `main` releases. Winget CI also gets a blank line between
+  the issue body and the manifest PR body so the rendered issue no longer
+  runs the two together.
+
+## 1.6.8
+
+### Fixed
+
+- **A bare launch of `sigit.exe` on Windows exits 0 instead of bailing.** A
+  no-argument launch with a TTY stdin falls through to the non-Unix branch,
+  which has no TUI to start (the interactive client needs Unix-only fd
+  redirection). It now prints a short usage message pointing at ACP and
+  headless modes and exits 0, so winget's installer validator no longer reports
+  a `Validation-Executable-Error`.
+
+### Changed
+
+- **winget submissions link back to their Package Request issue.** The release
+  workflow scrapes the winget-pkgs PR URL from wingetcreate, opens a Package
+  Request issue on first submission, and rewrites the PR body to fill the
+  Description, tick the issue checkbox, and add `Resolves #NNN` — replacing the
+  manual per-PR edit that used to follow each release.
+- **The winget release workflow files its Package Request issue first and uses
+  two scoped tokens.** The Package Request issue is opened before the
+  winget-pkgs PR so the PR can reference it immediately, and issue creation and
+  PR submission now use separate tokens (`WINGET_ISSUE_TOKEN` and
+  `WINGET_PR_TOKEN`) rather than one shared token.
+
 ## 1.6.7
 
 ### Fixed

{sigit_code-1.6.7 → sigit_code-1.6.9}/CLAUDE.md

@@ -502,8 +502,13 @@ Three of these need credentials or a one-time manual step before they work:
 
 - Scoop needs a `getsigit/scoop-bucket` repo and a `SCOOP_BUCKET_TOKEN` secret, mirroring the
   Homebrew tap setup.
-- winget needs a `WINGET_TOKEN` (PAT with `public_repo` scope) so `wingetcreate` can fork
-  `microsoft/winget-pkgs` and open the manifest PR. It is passed as
+- winget files a Package Request issue first and then opens the manifest PR that resolves it,
+  authored by two separate classic PATs (replacing the old single `WINGET_TOKEN`):
+  `WINGET_ISSUE_TOKEN` (`public_repo`) for the issue and `WINGET_PR_TOKEN` for the PR.
+  `WINGET_PR_TOKEN` needs `public_repo` plus `read:org` and `read:discussion`: `public_repo`
+  lets `wingetcreate` fork `microsoft/winget-pkgs` and open the PR, and the later `gh pr edit`
+  that sets the PR body runs a GraphQL query resolving org/team and discussion fields that
+  fails with a scope error on a `public_repo`-only token. The PR token is passed as
   `WINGET_CREATE_GITHUB_TOKEN` rather than `--token`, which wingetcreate warns can leak the
   token into logs. `wingetcreate update` only works on a package that already exists in
   `microsoft/winget-pkgs`, so the workflow checks the `manifests/g/getSigit/siGitCode` path

{sigit_code-1.6.7 → sigit_code-1.6.9}/Cargo.lock

@@ -5901,7 +5901,7 @@ checksum = "f8fadd59c855ef2080decdef8ff161eb6661b86933c9d82e5ba29dc602a55aba"
 
 [[package]]
 name = "sigit"
-version = "1.6.7"
+version = "1.6.9"
 dependencies = [
  "agent-client-protocol",
  "anyhow",

{sigit_code-1.6.7 → sigit_code-1.6.9}/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "sigit"
-version = "1.6.7"
+version = "1.6.9"
 edition = "2024"
 description = "siGit Code — ACP-compatible AI coding agent. Sí, git."
 documentation = "https://github.com/getsigit/sigit"

{sigit_code-1.6.7 → sigit_code-1.6.9}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: sigit-code
-Version: 1.6.7
+Version: 1.6.9
 Classifier: Development Status :: 4 - Beta
 Classifier: Environment :: Console
 Classifier: Intended Audience :: Developers