sigit-code 1.5.4__tar.gz → 1.5.6__tar.gz

{sigit_code-1.5.4 → sigit_code-1.5.6}/.agents/AGENTS.md

@@ -26,7 +26,23 @@ from the name alone (e.g. `feature/tool-permission-system`, `fix/glob-mtime-sort
 a task, ticket, or session id (not `feature/task-q003hm`).
 
 **IMPORTANT — pull request target:** Always open pull requests against the `development` branch,
-never `main`. `main` is release-only; `development` is where day-to-day work integrates.
+never `main`. `main` is release-only; `development` is where day-to-day work integrates, and the
+release merge (see the `sigit-code-release` skill) is the one thing that ever puts commits on
+`main`.
+
+This rule needs help to hold, because the repository's default branch is `main`: both
+`gh pr create` and the GitHub web form pre-select it, so a PR lands on the wrong base unless the
+base is passed explicitly. Pass it every time, and check that it took:
+
+```sh
+gh pr create --base development --head <branch>
+gh pr view <number> --json baseRefName
+```
+
+Retargeting a PR that was opened against `main` costs nothing before it merges:
+`gh pr edit <number> --base development`. After it merges it costs real work — the change sits on
+`main` while `development`, which the next release is cut from, does not have it, and someone has
+to carry it back by hand. PR #65 went in that way.
 
 **IMPORTANT — branch off `development`:** Start every working branch from the latest
 `origin/development`. Exception: when new work *depends on* a feature branch that has not merged
@@ -182,10 +198,11 @@ feeds results back. Neither the loop nor ACP/TUI surfaces depend on a concrete b
   `tests/mcp_stdio.rs`, driven by the test-only `src/bin/mcp_stdio_stub.rs` helper binary
   (excluded from the published crate via `exclude` in `Cargo.toml`). The baked-in official
   server is *also* listed in the public MCP Registry as `si.sigit/sigit` — a **remote**
-  Streamable-HTTP listing (`server.json` at the repo root, published by
-  `release-mcp-registry.yml`). Because it's a remote server, the registry's URL-match rule
-  forces a domain namespace (`si.sigit` ↔ `sigit.si`) verified by a DNS TXT record, not the
-  GitHub-OIDC scheme `smbcloud-cli` uses for its package listing.
+  Streamable-HTTP listing owned by the [`getsigit/si`](https://github.com/getsigit/si) repo
+  (`server.json` at its root, published by its `release-mcp-registry.yml`), not this one. Because
+  it's a remote server, the registry's URL-match rule forces a domain namespace (`si.sigit` ↔
+  `sigit.si`) verified by a DNS TXT record, not the GitHub-OIDC scheme `smbcloud-cli` uses for its
+  package listing.
 - **`src/permissions.rs`** — tool permission policy. Every tool call passes through
   `decision_for` before executing: read-only tools always run; mutating tools (and all
   `mcp__*`/unknown tools) are governed by, in order: per-session plan mode (`/plan` — deny all
@@ -267,6 +284,12 @@ Publishing splits into two groups. **Language registries** each get their own ta
 workflow: `release-crates`, `release-npm`, `release-nuget`, `release-pypi`. The `npm/`, `nuget/`,
 and `pypi/` dirs hold their wrapper-package templates.
 
+npm and NuGet authenticate with OIDC (Trusted Publishing), so neither needs a stored token. On
+npm that is configured per package, not per org: all seven `@getsigit/*` names carry a trusted
+publisher pointing at `release-npm.yml`, and a package added later needs the same setup or its
+publish step will fail. OIDC also requires npm >= 11.5.1 and Node >= 22.14.0, which is why the
+workflow upgrades npm and why `.nvmrc` cannot drop below 22.
+
 **OS package managers** all publish somewhere outside this repo and all need checksums from the
 GitHub release, so `release-github` builds the binaries, attaches the assets, and then dispatches
 `release-homebrew`, `release-scoop`, `release-winget`, and `release-aur`. A dispatch failure in one
@@ -283,8 +306,12 @@ 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`) so `wingetcreate` can fork
-  `microsoft/winget-pkgs`. The workflow only handles *updates*; the first submission has to be made
-  by hand with `wingetcreate new`, since a package must exist before it can be updated.
+  `microsoft/winget-pkgs`. It 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 first and falls back to rendering
+  `packaging/winget/*.yaml.in` and running `wingetcreate submit` for a first submission. That
+  fallback runs once, then every later release takes the `update` path.
 - The AUR needs `AUR_USERNAME`, `AUR_EMAIL`, and `AUR_SSH_PRIVATE_KEY`. It publishes `sigit-bin`
   (a prebuilt binary) so Arch users are not compiling the on-device inference stack to install a
   CLI.

{sigit_code-1.5.4/.claude → sigit_code-1.5.6/.agents}/skills/branding/SKILL.md

@@ -14,7 +14,7 @@ The short version:
 - **Product / brand name:** `siGit Code`
 - **CLI command:** `sigit`
 - **Rust crate:** `sigit`
-- **npm package:** `@smbcloud/sigit`
+- **npm package:** `@getsigit/sigit`
 - **PyPI package:** `sigit-code`
 - **Company name:** `smbCloud`
 - **LLM backend name:** `Onde Inference`
@@ -38,7 +38,7 @@ These names are case-sensitive.
 - **CLI command:** `sigit`
 - **Rust crate:** `sigit`
 - **Repository slug:** `getsigit/sigit`
-- **npm package:** `@smbcloud/sigit`
+- **npm package:** `@getsigit/sigit`
 - **PyPI package:** `sigit-code`
 - **Company:** `smbCloud`
 - **LLM backend in prose:** `Onde Inference`
@@ -73,7 +73,7 @@ When you mean something users type, install, import, or clone, use the literal l
 That means:
 
 - `sigit` for the command, crate, and repo slug
-- `@smbcloud/sigit` for npm
+- `@getsigit/sigit` for npm
 - `sigit-code` for PyPI
 - `onde` for the Rust crate
 
@@ -81,7 +81,7 @@ Examples:
 
 - Run `sigit` in a terminal.
 - Install with `cargo install sigit`.
-- Install with `npm install -g @smbcloud/sigit`.
+- Install with `npm install -g @getsigit/sigit`.
 - Install with `pip install sigit-code`.
 - The repository is `getsigit/sigit`.
 
@@ -169,7 +169,7 @@ That includes:
 - `Onde Inference`
 - `ACP`
 - `sigit`
-- `@smbcloud/sigit`
+- `@getsigit/sigit`
 - `sigit-code`
 - `onde`
 
@@ -181,7 +181,7 @@ Before you finish any doc or release-note edit, check these:
 
 1. Did you use `siGit Code` when referring to the product?
 2. Did you keep `sigit` lowercase for commands, crates, and repo references?
-3. Did you keep `@smbcloud/sigit` and `sigit-code` exact?
+3. Did you keep `@getsigit/sigit` and `sigit-code` exact?
 4. Did you keep `smbCloud` and `Onde Inference` cased correctly?
 5. In setup examples, does the visible editor label say `siGit Code` while the command stays `sigit`?
 

{sigit_code-1.5.4 → sigit_code-1.5.6}/.agents/skills/sigit-code-release/SKILL.md

@@ -29,8 +29,13 @@ Use this skill when preparing a release for this repository.
 - Add or update the top changelog entry in `CHANGELOG.md` for the release being cut.
 - Do not treat `npm/sigit/package.json` `0.0.0-dev` as a bug by default. The npm release workflow rewrites it at publish time using `npm/scripts/render-main-package.cjs` and the release tag.
 - Do not add a hardcoded version to `pypi/pyproject.toml` for normal releases. PyPI uses `maturin` with `dynamic = ["version"]` and derives the published package version from `Cargo.toml`.
-- Release workflows are tag-driven. `release-github.yml`, `release-npm.yml`, `release-pypi.yml`, `release-crates.yml`, and `release-homebrew.yml` all derive `RELEASE_VERSION` from a `v*.*.*` tag or a manually supplied tag input.
+- Release workflows are tag-driven. `release-github.yml`, `release-npm.yml`, `release-pypi.yml`, `release-crates.yml`, `release-homebrew.yml`, `release-nuget.yml`, and `release-mcp-registry.yml` all derive `RELEASE_VERSION` from a `v*.*.*` tag or a manually supplied tag input.
 - The crate is published to crates.io (`release-crates.yml`) and the Homebrew tap is updated (`release-homebrew.yml`) as part of the tag-driven flow. Per the siGit release flow, Homebrew is auto-triggered — do not dispatch it manually.
+- `release-github.yml` builds the binaries, attaches them (plus a `.deb`/`.rpm` per Linux target built with nfpm from `packaging/nfpm.yaml`) to the GitHub release, then dispatches `release-homebrew`, `release-scoop`, `release-winget`, and `release-aur`. A dispatch failure in any one of those four is logged as a warning, not a hard failure — an unconfigured channel doesn't block the rest of the release. `release-nuget.yml` and `release-mcp-registry.yml`, by contrast, are tag-triggered directly like the other language-registry workflows, not dispatched from `release-github.yml`.
+- Every release asset carries a `.sha256` sidecar (not just the macOS Homebrew tarball). Scoop, winget, and the AUR PKGBUILD each consume the raw binaries plus their sidecar checksum, rather than the tarball.
+- 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 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
 
@@ -42,6 +47,8 @@ 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`).
+
 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.
 
 ## Typical files to inspect
@@ -54,7 +61,10 @@ Pushing the `v*.*.*` tag is what fires every release workflow, so create and pus
 - `npm/scripts/render-main-package.cjs`
 - `npm/`
 - `pypi/`
-- `.github/workflows/` (`release-github.yml`, `release-npm.yml`, `release-pypi.yml`, `release-crates.yml`, `release-homebrew.yml`)
+- `nuget/sigit/` (bundled-binary `.NET` tool packaging)
+- `packaging/` (`nfpm.yaml` for `.deb`/`.rpm`, plus `aur/` and `winget/` templates)
+- `server.json` (MCP Registry listing)
+- `.github/workflows/` (`release-github.yml`, `release-npm.yml`, `release-pypi.yml`, `release-crates.yml`, `release-homebrew.yml`, `release-scoop.yml`, `release-winget.yml`, `release-aur.yml`, `release-nuget.yml`, `release-mcp-registry.yml`)
 
 ## Release checklist
 
@@ -67,5 +77,6 @@ Pushing the `v*.*.*` tag is what fires every release workflow, so create and pus
 - 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.
 - 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.
-- Any known release limitations are called out explicitly.
+- 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`.

{sigit_code-1.5.4/.agents → sigit_code-1.5.6/.claude}/skills/branding/SKILL.md

@@ -14,7 +14,7 @@ The short version:
 - **Product / brand name:** `siGit Code`
 - **CLI command:** `sigit`
 - **Rust crate:** `sigit`
-- **npm package:** `@smbcloud/sigit`
+- **npm package:** `@getsigit/sigit`
 - **PyPI package:** `sigit-code`
 - **Company name:** `smbCloud`
 - **LLM backend name:** `Onde Inference`
@@ -38,7 +38,7 @@ These names are case-sensitive.
 - **CLI command:** `sigit`
 - **Rust crate:** `sigit`
 - **Repository slug:** `getsigit/sigit`
-- **npm package:** `@smbcloud/sigit`
+- **npm package:** `@getsigit/sigit`
 - **PyPI package:** `sigit-code`
 - **Company:** `smbCloud`
 - **LLM backend in prose:** `Onde Inference`
@@ -73,7 +73,7 @@ When you mean something users type, install, import, or clone, use the literal l
 That means:
 
 - `sigit` for the command, crate, and repo slug
-- `@smbcloud/sigit` for npm
+- `@getsigit/sigit` for npm
 - `sigit-code` for PyPI
 - `onde` for the Rust crate
 
@@ -81,7 +81,7 @@ Examples:
 
 - Run `sigit` in a terminal.
 - Install with `cargo install sigit`.
-- Install with `npm install -g @smbcloud/sigit`.
+- Install with `npm install -g @getsigit/sigit`.
 - Install with `pip install sigit-code`.
 - The repository is `getsigit/sigit`.
 
@@ -169,7 +169,7 @@ That includes:
 - `Onde Inference`
 - `ACP`
 - `sigit`
-- `@smbcloud/sigit`
+- `@getsigit/sigit`
 - `sigit-code`
 - `onde`
 
@@ -181,7 +181,7 @@ Before you finish any doc or release-note edit, check these:
 
 1. Did you use `siGit Code` when referring to the product?
 2. Did you keep `sigit` lowercase for commands, crates, and repo references?
-3. Did you keep `@smbcloud/sigit` and `sigit-code` exact?
+3. Did you keep `@getsigit/sigit` and `sigit-code` exact?
 4. Did you keep `smbCloud` and `Onde Inference` cased correctly?
 5. In setup examples, does the visible editor label say `siGit Code` while the command stays `sigit`?
 

{sigit_code-1.5.4 → sigit_code-1.5.6}/.claude/skills/sigit-code-release/SKILL.md

@@ -29,8 +29,13 @@ Use this skill when preparing a release for this repository.
 - Add or update the top changelog entry in `CHANGELOG.md` for the release being cut.
 - Do not treat `npm/sigit/package.json` `0.0.0-dev` as a bug by default. The npm release workflow rewrites it at publish time using `npm/scripts/render-main-package.cjs` and the release tag.
 - Do not add a hardcoded version to `pypi/pyproject.toml` for normal releases. PyPI uses `maturin` with `dynamic = ["version"]` and derives the published package version from `Cargo.toml`.
-- Release workflows are tag-driven. `release-github.yml`, `release-npm.yml`, `release-pypi.yml`, `release-crates.yml`, and `release-homebrew.yml` all derive `RELEASE_VERSION` from a `v*.*.*` tag or a manually supplied tag input.
+- Release workflows are tag-driven. `release-github.yml`, `release-npm.yml`, `release-pypi.yml`, `release-crates.yml`, `release-homebrew.yml`, `release-nuget.yml`, and `release-mcp-registry.yml` all derive `RELEASE_VERSION` from a `v*.*.*` tag or a manually supplied tag input.
 - The crate is published to crates.io (`release-crates.yml`) and the Homebrew tap is updated (`release-homebrew.yml`) as part of the tag-driven flow. Per the siGit release flow, Homebrew is auto-triggered — do not dispatch it manually.
+- `release-github.yml` builds the binaries, attaches them (plus a `.deb`/`.rpm` per Linux target built with nfpm from `packaging/nfpm.yaml`) to the GitHub release, then dispatches `release-homebrew`, `release-scoop`, `release-winget`, and `release-aur`. A dispatch failure in any one of those four is logged as a warning, not a hard failure — an unconfigured channel doesn't block the rest of the release. `release-nuget.yml` and `release-mcp-registry.yml`, by contrast, are tag-triggered directly like the other language-registry workflows, not dispatched from `release-github.yml`.
+- Every release asset carries a `.sha256` sidecar (not just the macOS Homebrew tarball). Scoop, winget, and the AUR PKGBUILD each consume the raw binaries plus their sidecar checksum, rather than the tarball.
+- 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 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
 
@@ -42,6 +47,8 @@ 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`).
+
 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.
 
 ## Typical files to inspect
@@ -54,7 +61,10 @@ Pushing the `v*.*.*` tag is what fires every release workflow, so create and pus
 - `npm/scripts/render-main-package.cjs`
 - `npm/`
 - `pypi/`
-- `.github/workflows/` (`release-github.yml`, `release-npm.yml`, `release-pypi.yml`, `release-crates.yml`, `release-homebrew.yml`)
+- `nuget/sigit/` (bundled-binary `.NET` tool packaging)
+- `packaging/` (`nfpm.yaml` for `.deb`/`.rpm`, plus `aur/` and `winget/` templates)
+- `server.json` (MCP Registry listing)
+- `.github/workflows/` (`release-github.yml`, `release-npm.yml`, `release-pypi.yml`, `release-crates.yml`, `release-homebrew.yml`, `release-scoop.yml`, `release-winget.yml`, `release-aur.yml`, `release-nuget.yml`, `release-mcp-registry.yml`)
 
 ## Release checklist
 
@@ -67,5 +77,6 @@ Pushing the `v*.*.*` tag is what fires every release workflow, so create and pus
 - 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.
 - 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.
-- Any known release limitations are called out explicitly.
+- 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`.

{sigit_code-1.5.4 → sigit_code-1.5.6}/.github/workflows/release-npm.yml

@@ -101,9 +101,16 @@ jobs:
           node-version-file: .nvmrc
           registry-url: "https://registry.npmjs.org"
 
+      # Trusted Publishing (OIDC) needs npm >= 11.5.1. .nvmrc pins the Node
+      # version (>= 22.14.0, also an OIDC requirement); npm still needs
+      # upgrading past whatever ships with it.
+      - name: Upgrade npm for Trusted Publishing
+        shell: bash
+        run: npm install -g npm@latest
+
+      # Authentication is OIDC: each @getsigit/* package has a Trusted
+      # Publisher pointing at this workflow, so there is no token to leak.
       - name: Publish platform package to NPM
-        env:
-          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
         shell: bash
         run: |
           cd npm
@@ -150,16 +157,16 @@ jobs:
 
           cd "${node_pkg}"
 
-          npm_package_name="@smbcloud/${node_pkg}"
+          npm_package_name="@getsigit/${node_pkg}"
           if npm view "${npm_package_name}@${node_version}" version >/dev/null 2>&1; then
             echo "${npm_package_name}@${node_version} already exists on npm, skipping publish"
             exit 0
           fi
 
-          npm publish --access public --provenance
+          npm publish --access public
 
   publish-npm-base:
-    name: Publish base NPM package (@smbcloud/sigit)
+    name: Publish base NPM package (@getsigit/sigit)
     needs: publish-npm-binaries
     runs-on: ubuntu-latest
 
@@ -186,9 +193,14 @@ jobs:
           node-version-file: .nvmrc
           registry-url: "https://registry.npmjs.org"
 
+      # Trusted Publishing (OIDC) needs npm >= 11.5.1. .nvmrc pins the Node
+      # version (>= 22.14.0, also an OIDC requirement); npm still needs
+      # upgrading past whatever ships with it.
+      - name: Upgrade npm for Trusted Publishing
+        shell: bash
+        run: npm install -g npm@latest
+
       - name: Publish base package to NPM
-        env:
-          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
         shell: bash
         run: |
           cd npm/sigit
@@ -199,7 +211,7 @@ jobs:
             "./package.json" \
             "${{ env.RELEASE_VERSION }}"
 
-          npm_package_name="@smbcloud/sigit"
+          npm_package_name="@getsigit/sigit"
           npm_package_version="${{ env.RELEASE_VERSION }}"
 
           if npm view "${npm_package_name}@${npm_package_version}" version >/dev/null 2>&1; then
@@ -209,4 +221,4 @@ jobs:
 
           npm install
           npm run build
-          npm publish --access public --provenance
+          npm publish --access public

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

@@ -0,0 +1,170 @@
+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
+
+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
+
+      - name: Submit new package
+        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.
+          WINGET_CREATE_GITHUB_TOKEN: ${{ secrets.WINGET_TOKEN }}
+        run: |
+          if (-not $env:WINGET_CREATE_GITHUB_TOKEN) {
+            Write-Error "WINGET_TOKEN is not set. It needs a PAT with public_repo scope so wingetcreate can fork microsoft/winget-pkgs and open the manifest PR."
+          }
+
+          $version = "${{ steps.release.outputs.version }}"
+
+          # --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
+
+          if ($LASTEXITCODE -ne 0) {
+            Write-Error "wingetcreate submit failed with exit code $LASTEXITCODE"
+          }
+
+      - name: Submit manifest update
+        if: steps.exists.outputs.found == 'true'
+        shell: pwsh
+        env:
+          WINGET_CREATE_GITHUB_TOKEN: ${{ secrets.WINGET_TOKEN }}
+        run: |
+          if (-not $env:WINGET_CREATE_GITHUB_TOKEN) {
+            Write-Error "WINGET_TOKEN is not set. It needs a PAT with public_repo scope so wingetcreate can fork microsoft/winget-pkgs and open the manifest PR."
+          }
+
+          $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
+
+          if ($LASTEXITCODE -ne 0) {
+            Write-Error "wingetcreate failed with exit code $LASTEXITCODE"
+          }

sigit_code-1.5.6/.nvmrc

@@ -0,0 +1 @@
+22

{sigit_code-1.5.4 → sigit_code-1.5.6}/AGENTS.md

@@ -26,7 +26,23 @@ from the name alone (e.g. `feature/tool-permission-system`, `fix/glob-mtime-sort
 a task, ticket, or session id (not `feature/task-q003hm`).
 
 **IMPORTANT — pull request target:** Always open pull requests against the `development` branch,
-never `main`. `main` is release-only; `development` is where day-to-day work integrates.
+never `main`. `main` is release-only; `development` is where day-to-day work integrates, and the
+release merge (see the `sigit-code-release` skill) is the one thing that ever puts commits on
+`main`.
+
+This rule needs help to hold, because the repository's default branch is `main`: both
+`gh pr create` and the GitHub web form pre-select it, so a PR lands on the wrong base unless the
+base is passed explicitly. Pass it every time, and check that it took:
+
+```sh
+gh pr create --base development --head <branch>
+gh pr view <number> --json baseRefName
+```
+
+Retargeting a PR that was opened against `main` costs nothing before it merges:
+`gh pr edit <number> --base development`. After it merges it costs real work — the change sits on
+`main` while `development`, which the next release is cut from, does not have it, and someone has
+to carry it back by hand. PR #65 went in that way.
 
 **IMPORTANT — branch off `development`:** Start every working branch from the latest
 `origin/development`. Exception: when new work *depends on* a feature branch that has not merged
@@ -182,10 +198,11 @@ feeds results back. Neither the loop nor ACP/TUI surfaces depend on a concrete b
   `tests/mcp_stdio.rs`, driven by the test-only `src/bin/mcp_stdio_stub.rs` helper binary
   (excluded from the published crate via `exclude` in `Cargo.toml`). The baked-in official
   server is *also* listed in the public MCP Registry as `si.sigit/sigit` — a **remote**
-  Streamable-HTTP listing (`server.json` at the repo root, published by
-  `release-mcp-registry.yml`). Because it's a remote server, the registry's URL-match rule
-  forces a domain namespace (`si.sigit` ↔ `sigit.si`) verified by a DNS TXT record, not the
-  GitHub-OIDC scheme `smbcloud-cli` uses for its package listing.
+  Streamable-HTTP listing owned by the [`getsigit/si`](https://github.com/getsigit/si) repo
+  (`server.json` at its root, published by its `release-mcp-registry.yml`), not this one. Because
+  it's a remote server, the registry's URL-match rule forces a domain namespace (`si.sigit` ↔
+  `sigit.si`) verified by a DNS TXT record, not the GitHub-OIDC scheme `smbcloud-cli` uses for its
+  package listing.
 - **`src/permissions.rs`** — tool permission policy. Every tool call passes through
   `decision_for` before executing: read-only tools always run; mutating tools (and all
   `mcp__*`/unknown tools) are governed by, in order: per-session plan mode (`/plan` — deny all
@@ -267,6 +284,12 @@ Publishing splits into two groups. **Language registries** each get their own ta
 workflow: `release-crates`, `release-npm`, `release-nuget`, `release-pypi`. The `npm/`, `nuget/`,
 and `pypi/` dirs hold their wrapper-package templates.
 
+npm and NuGet authenticate with OIDC (Trusted Publishing), so neither needs a stored token. On
+npm that is configured per package, not per org: all seven `@getsigit/*` names carry a trusted
+publisher pointing at `release-npm.yml`, and a package added later needs the same setup or its
+publish step will fail. OIDC also requires npm >= 11.5.1 and Node >= 22.14.0, which is why the
+workflow upgrades npm and why `.nvmrc` cannot drop below 22.
+
 **OS package managers** all publish somewhere outside this repo and all need checksums from the
 GitHub release, so `release-github` builds the binaries, attaches the assets, and then dispatches
 `release-homebrew`, `release-scoop`, `release-winget`, and `release-aur`. A dispatch failure in one
@@ -283,8 +306,12 @@ 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`) so `wingetcreate` can fork
-  `microsoft/winget-pkgs`. The workflow only handles *updates*; the first submission has to be made
-  by hand with `wingetcreate new`, since a package must exist before it can be updated.
+  `microsoft/winget-pkgs`. It 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 first and falls back to rendering
+  `packaging/winget/*.yaml.in` and running `wingetcreate submit` for a first submission. That
+  fallback runs once, then every later release takes the `update` path.
 - The AUR needs `AUR_USERNAME`, `AUR_EMAIL`, and `AUR_SSH_PRIVATE_KEY`. It publishes `sigit-bin`
   (a prebuilt binary) so Arch users are not compiling the on-device inference stack to install a
   CLI.

{sigit_code-1.5.4 → sigit_code-1.5.6}/CHANGELOG.md

@@ -1,5 +1,56 @@
 # Changelog
 
+## 1.5.6
+
+### What changed
+
+- **Switching models mid-conversation no longer restarts it.** Both switching
+  to a local GGUF model and picking a different cloud tier now carry the live
+  conversation history across, repairing any half-finished tool call so
+  strict OpenAI-compatible endpoints don't reject the session
+- **Long-running tools now show progress in ACP clients.** Synchronous tools
+  (shell commands, file operations, `read_website`, ...) run on a blocking
+  thread pool instead of the ACP connection's own task, so a slow command's
+  `in_progress` update reaches the client — and Zed's spinner — while the
+  command is still running instead of arriving with the result
+- **Text from consecutive tool rounds no longer runs together.** ACP and
+  headless clients concatenate consecutive message chunks, so a reply that
+  continued after a tool call used to glue onto the previous round's last
+  sentence with no space. A blank line now opens the next round's text
+- **New onde-cloud model tiers.** The model picker (`/models` in the TUI, the
+  config panel in editors) now offers five additional siGit Code Cloud tiers —
+  `flux`, `apex`, `aura`, `orbit`, and `nova` — alongside the existing Fast,
+  Balanced, Large, Mini, Air, Pro, and KKK options. The tier list mirrors
+  onde-cloud's router catalogue, so all three sides (the picker, the router,
+  and the cloud catalogue) have to be updated together when a tier is added
+- **MCP Registry listing moved to `getsigit/si`.** The `server.json` manifest
+  and its `release-mcp-registry.yml` publish workflow now live in the
+  [`getsigit/si`](https://github.com/getsigit/si) repo alongside the si CLI's
+  other code, since the registry entry describes the si platform rather than
+  the coding agent
+
+## 1.5.5
+
+A distribution release. siGit Code itself is unchanged. What moved is how it
+reaches you on npm and on Windows.
+
+### What changed
+
+- **The npm package is now `@getsigit/sigit`.** The six platform packages moved
+  with it. `@smbcloud/sigit` stays on the registry but stops receiving updates,
+  so upgrading means switching names:
+  `npm uninstall -g @smbcloud/sigit && npm install -g @getsigit/sigit`. The old
+  package had been stuck at 1.5.2, so this picks up 1.5.3 and 1.5.4 as well.
+- **npm publishes over OIDC.** Every `@getsigit/*` package has a trusted
+  publisher pointing at the release workflow, so no npm token is stored in the
+  repository. The release workflow moves to Node 22, which trusted publishing
+  requires.
+- **winget releases actually go out.** The workflow could only update a package
+  already present in `microsoft/winget-pkgs`, and siGit Code had never been
+  submitted there, so every dispatch failed. It now submits the package the
+  first time and updates it on later releases. The identifier is
+  `getSigit.siGitCode`.
+
 ## 1.5.4
 
 - **CI**: nfpm config expanded to include package version and binary path