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

{sigit_code-1.6.8 → 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.8 → 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.8 → 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.8 → sigit_code-1.6.9}/.github/workflows/release-winget.yml

@@ -132,8 +132,11 @@ jobs:
       # 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
-      # replaces the old single WINGET_TOKEN.
+      # 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
@@ -182,6 +185,11 @@ jobs:
           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'
@@ -194,7 +202,7 @@ jobs:
           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 scope so wingetcreate can fork microsoft/winget-pkgs and open the manifest PR."
+            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 }}"
@@ -228,7 +236,7 @@ jobs:
           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 scope so wingetcreate can fork microsoft/winget-pkgs and open the manifest PR."
+            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 }}"

{sigit_code-1.6.8 → 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.8 → sigit_code-1.6.9}/CHANGELOG.md

@@ -1,5 +1,27 @@
 # 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

{sigit_code-1.6.8 → 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.8 → sigit_code-1.6.9}/Cargo.lock

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

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

@@ -1,6 +1,6 @@
 [package]
 name = "sigit"
-version = "1.6.8"
+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.8 → sigit_code-1.6.9}/PKG-INFO

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

{sigit_code-1.6.8 → sigit_code-1.6.9}/src/inline_tool_calls.rs

@@ -33,6 +33,10 @@
 //! malformed when what follows the marker looks like the start of a call (see
 //! [`looks_like_xml_call`] and [`looks_like_k3_call`]); otherwise it stays
 //! text, as it always did.
+//!
+//! One spelling difference is folded away before matching: DSML markers are
+//! built from fullwidth bars, and some stacks hand them back with each bar
+//! doubled (`<｜｜DSML｜｜invoke …>`). See [`fold_dsml_bars`].
 
 use std::collections::HashMap;
 
@@ -53,6 +57,13 @@ const K3_THINK_OPEN: &str = "<|open|>think<|sep|>";
 const K3_THINK_CLOSE: &str = "<|close|>think<|sep|>";
 const K3_SEP: &str = "<|sep|>";
 
+/// `｜` (U+FF5C), the bar every DSML marker above is built from.
+const FULLWIDTH_BAR: char = '｜';
+/// Two of them — the spelling [`fold_dsml_bars`] rewrites into one.
+const DOUBLED_BAR: &str = "｜｜";
+/// The name those markers wrap, and the only place [`fold_dsml_bars`] folds.
+const DSML_TAG_NAME: &str = "DSML";
+
 const DSML_TOOL_CALLS_OPEN: &str = "<｜DSML｜tool_calls>";
 const DSML_TOOL_CALLS_CLOSE: &str = "<｜DSML｜/tool_calls>";
 const DSML_INVOKE_OPEN: &str = "<｜DSML｜invoke";
@@ -447,6 +458,16 @@ impl<'a> StreamScanner<'a> {
     /// be empty if the chunk was absorbed into a tag that hasn't closed yet.
     pub fn push(&mut self, chunk: &str) -> Vec<ScanEvent> {
         self.pending.push_str(chunk);
+        // The fold runs on the whole buffer, not the chunk: a doubled bar split
+        // across two deltas is only visible once they are joined, and a marker
+        // is never emitted before then because a partial prefix is held back.
+        // Both the single- and doubled-bar spellings are partial prefixes
+        // (START_MARKERS is single-bar), so a doubled-bar prefix is flushed as
+        // text on this push; the fold then rewrites the buffer and the next
+        // push re-runs `drain` against canonical markers.
+        if let Some(folded) = fold_dsml_bars(&self.pending) {
+            self.pending = folded;
+        }
         self.drain()
     }
 
@@ -651,6 +672,71 @@ fn looks_like_dsml_call(after_marker: &str) -> bool {
     rest.is_empty() || rest.starts_with(DSML_INVOKE_OPEN)
 }
 
+/// Every DSML marker above carries exactly one fullwidth bar on each side of
+/// `DSML`. Some serving stacks emit each bar twice (`<｜｜DSML｜｜invoke …>`),
+/// which no marker matches, so the block falls through as text and renders raw
+/// in the editor.
+///
+/// Folding the run on both sides of `DSML` down to a single bar, rather than
+/// listing a doubled-bar constant next to each one, keeps the marker set at six
+/// and covers a run of any length. A bar run elsewhere is never touched, so a
+/// fullwidth bar used as prose or as a table rule passes through unchanged. The
+/// fold is not conditional on the block parsing, so a doubled-bar marker that
+/// turns out not to be a call comes back with single bars — markup either way.
+///
+/// Returns `None` when there is nothing to fold — in particular for any buffer
+/// without a doubled bar, which is the common case and costs no allocation.
+fn fold_dsml_bars(text: &str) -> Option<String> {
+    if !text.contains(DSML_TAG_NAME) {
+        return None;
+    }
+    // A DSML tag with only single bars is canonical; only the doubled-bar
+    // spelling needs rewriting, so the buffer-walking allocation can be
+    // skipped when the only defect isn't present.
+    if !text.contains(DOUBLED_BAR) {
+        return None;
+    }
+    let mut folded = String::with_capacity(text.len());
+    let mut changed = false;
+    let mut rest = text;
+    while let Some(idx) = rest.find(DSML_TAG_NAME) {
+        let (before, from_name) = rest.split_at(idx);
+        // The run of bars closing the tag being opened, i.e. `<｜｜` in
+        // `<｜｜DSML｜｜invoke`. Counted in bars, not bytes: a lone fullwidth bar
+        // is three bytes, so a byte count would read as a run of its own.
+        let opening_run = bar_run_len(before, false);
+        folded.push_str(&before[..before.len() - opening_run * FULLWIDTH_BAR.len_utf8()]);
+        if opening_run > 0 {
+            changed |= opening_run > 1;
+            folded.push(FULLWIDTH_BAR);
+        }
+        folded.push_str(DSML_TAG_NAME);
+        let after = &from_name[DSML_TAG_NAME.len()..];
+        // The run opening the tag being closed, i.e. `｜｜>` in
+        // `<｜DSML｜｜/invoke>`.
+        let closing_run = bar_run_len(after, true);
+        if closing_run > 0 {
+            changed |= closing_run > 1;
+            folded.push(FULLWIDTH_BAR);
+        }
+        rest = &after[closing_run * FULLWIDTH_BAR.len_utf8()..];
+    }
+    folded.push_str(rest);
+    changed.then_some(folded)
+}
+
+/// Number of fullwidth bars in the run at the end of `text`, or at its start
+/// when `leading` is set. The caller passes the slice anchored to `DSML`, so
+/// the run being counted always sits at the boundary, never in the middle.
+fn bar_run_len(text: &str, leading: bool) -> usize {
+    let bytes = if leading {
+        text.len() - text.trim_start_matches(FULLWIDTH_BAR).len()
+    } else {
+        text.len() - text.trim_end_matches(FULLWIDTH_BAR).len()
+    };
+    bytes / FULLWIDTH_BAR.len_utf8()
+}
+
 fn scan_complete_text(text: &str, tools: &[ToolSpec]) -> Vec<ScanEvent> {
     let mut scanner = StreamScanner::new(tools);
     let mut events = scanner.push(text);
@@ -1492,4 +1578,95 @@ mod tests {
             ))
         );
     }
+
+    #[test]
+    fn fold_dsml_bars_collapses_runs_glued_to_dsml_only() {
+        assert_eq!(
+            fold_dsml_bars("<｜｜DSML｜｜invoke name=\"run_command\">"),
+            Some("<｜DSML｜invoke name=\"run_command\">".to_string())
+        );
+        assert_eq!(
+            fold_dsml_bars("<｜｜｜｜DSML｜/tool_calls>"),
+            Some("<｜DSML｜/tool_calls>".to_string())
+        );
+        // Only the bar run adjacent to DSML folds; a doubled bar further along
+        // in the tag name or body is not part of the marker grammar.
+        assert_eq!(
+            fold_dsml_bars("<｜DSML｜｜param｜｜eter"),
+            Some("<｜DSML｜param｜｜eter".to_string())
+        );
+        // A bar run that isn't a marker, and single-bar markup, are left alone.
+        assert_eq!(fold_dsml_bars("a ｜｜ b <｜DSML｜invoke>"), None);
+        assert_eq!(fold_dsml_bars("<｜DSML｜invoke>"), None);
+        assert_eq!(fold_dsml_bars("plain text"), None);
+    }
+
+    #[test]
+    fn a_doubled_bar_dsml_call_is_recovered() {
+        let tools = vec![run_command_spec()];
+        let Extracted {
+            text,
+            calls,
+            malformed,
+        } = extract(
+            "before <｜｜DSML｜｜tool_calls><｜｜DSML｜｜invoke name=\"run_command\">\
+             <｜｜DSML｜｜parameter name=\"command\" string=\"true\">echo hi\
+             <｜｜DSML｜｜/parameter><｜｜DSML｜｜/invoke><｜｜DSML｜｜/tool_calls> after",
+            &tools,
+        );
+
+        assert_eq!(text, "before  after");
+        assert_eq!(malformed, 0);
+        assert_eq!(calls.len(), 1);
+        assert_eq!(calls[0].name, "run_command");
+        let args: serde_json::Value = serde_json::from_str(&calls[0].arguments).unwrap();
+        assert_eq!(args["command"], "echo hi");
+    }
+
+    #[test]
+    fn a_doubled_bar_split_across_pushes_is_recovered() {
+        let tools = vec![run_command_spec()];
+        let mut scanner = StreamScanner::new(&tools);
+        let mut text = String::new();
+        let mut calls = Vec::new();
+
+        for chunk in [
+            "pre <｜",
+            "｜DSML｜｜tool_calls><｜｜DSML｜｜invoke name=\"run_com",
+            "mand\"><｜｜DSML｜｜parameter name=\"command\" string=\"true\">echo hi\
+             <｜｜DSML｜｜/parameter><｜｜DSML｜｜/invoke><｜｜DSML｜｜/tool_calls>",
+            " post",
+        ] {
+            for event in scanner.push(chunk) {
+                match event {
+                    ScanEvent::Text(t) => text.push_str(&t),
+                    ScanEvent::ToolCall(call) => calls.push(call),
+                    ScanEvent::Malformed(block) => panic!("unexpected malformed block: {block}"),
+                }
+            }
+        }
+        if let Some(ScanEvent::Text(rest)) = scanner.finish() {
+            text.push_str(&rest);
+        }
+
+        assert_eq!(text, "pre  post");
+        assert_eq!(calls.len(), 1);
+        assert_eq!(calls[0].name, "run_command");
+        let args: serde_json::Value = serde_json::from_str(&calls[0].arguments).unwrap();
+        assert_eq!(args["command"], "echo hi");
+    }
+
+    #[test]
+    fn doubled_bar_markup_outside_a_call_returns_folded_as_text() {
+        let tools = vec![run_command_spec()];
+        let Extracted {
+            text,
+            calls,
+            malformed,
+        } = extract("the tag <｜｜DSML｜｜done> is not a call", &tools);
+
+        assert_eq!(text, "the tag <｜DSML｜done> is not a call");
+        assert!(calls.is_empty());
+        assert_eq!(malformed, 0);
+    }
 }