sigit-code 1.5.5__tar.gz → 1.5.7__tar.gz

{sigit_code-1.5.5 → sigit_code-1.5.7}/.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
@@ -100,7 +116,13 @@ feeds results back. Neither the loop nor ACP/TUI surfaces depend on a concrete b
   smbCloud, and stay general otherwise).
 - **`src/backend.rs`** — the `InferenceBackend` trait and neutral types (`ToolSpec`, `ToolCall`,
   `ToolResult`, `TurnResult`). Two impls: `LocalBackend` (on-device via `onde::ChatEngine`) and
-  `OpenAiBackend` (any OpenAI-compatible HTTP endpoint).
+  `OpenAiBackend` (any OpenAI-compatible HTTP endpoint). A `BackendError` is user-facing: the
+  ACP prompt handler passes it to the client verbatim and the editor puts it in an error banner,
+  so `describe_api_error` unwraps the OpenAI `{"error":{"message":…}}` envelope and shows that
+  message on its own, falling back to the status only when there is nothing to unwrap. An
+  endpoint can also fail *after* the response is open, reporting it as a `data:` frame holding
+  the same envelope; that frame has no `choices`, so `consume_stream` has to check for it
+  explicitly or it parses as an empty chunk and the turn ends looking like an empty answer.
 - **`src/provider.rs`** — decides *which* backend serves inference. Resolution order, first match
   wins: (1) override via `OPENAI_BASE_URL`+`OPENAI_API_KEY` or active profile in
   `~/.config/sigit/providers.toml`; (2) siGit Code Cloud when logged in; (3) on-device.
@@ -110,7 +132,13 @@ feeds results back. Neither the loop nor ACP/TUI surfaces depend on a concrete b
   spec list (`all_tools`) and the execute `match` (`execute_tool`). `run_command` also enforces
   commit attribution: when a command creates a new commit that lacks the
   `Co-Authored-By: siGit Code` trailer (`COMMIT_CO_AUTHOR_TRAILER`), it amends the trailer in —
-  unless the commit already exists on a remote, which is never rewritten. Also owns the `task`
+  unless the commit already exists on a remote, which is never rewritten. Every child process it
+  spawns (`spawn_shell`, the `git` helpers, and `hooks.rs`) sets `stdin` to null and never
+  inherits it: in ACP mode sigit's stdin is the JSON-RPC pipe from the editor, so a command that
+  reads stdin both blocks forever and eats the client's next request, wedging the session past
+  any timeout. On Unix the shell also leads its own process group so the timeout kills the whole
+  tree, and stdout/stderr are drained on threads while the command runs — waiting first and
+  reading after deadlocks as soon as the output outgrows the pipe buffer. Also owns the `task`
   tool: a nested agent loop in a fresh conversation, offered only when `subagent_available()`
   (a subagent factory is registered — see `register_subagent_factory_for` in `main.rs`; on-device
   registers a `None`-returning factory since onde has a single shared history). A subagent's
@@ -129,7 +157,8 @@ feeds results back. Neither the loop nor ACP/TUI surfaces depend on a concrete b
   HTTP/JSON-RPC implementation.
 - **`src/skills.rs`** — [Agent Skills](https://agentskills.io) support. Discovers skill
   folders (each with a `SKILL.md`: YAML frontmatter `name` + `description`, then Markdown
-  instructions) from `.sigit/skills/` and `.claude/skills/` in the cwd, `$SIGIT_CONFIG_DIR/skills/`,
+  instructions) from `.sigit/skills/` and `.claude/skills/` in every project root (see `src/workspace.rs`),
+  `$SIGIT_CONFIG_DIR/skills/`,
   and `~/.claude/skills/`. Progressive disclosure: the discovery list (name + description) is
   baked into the dynamically-built `skill` tool's description, and activating a skill (the model
   calls `skill` with a name) loads the full `SKILL.md` body. The `skill` tool is appended in the
@@ -137,7 +166,7 @@ feeds results back. Neither the loop nor ACP/TUI surfaces depend on a concrete b
   and only when at least one skill exists.
 - **`src/commands.rs`** — user-defined slash commands. Discovers Markdown files (each an
   optional YAML frontmatter block — `description`, `argument-hint` — followed by a prompt-template
-  body) from `.sigit/commands/` and `.claude/commands/` in the cwd, `$SIGIT_CONFIG_DIR/commands/`,
+  body) from `.sigit/commands/` and `.claude/commands/` in every project root, `$SIGIT_CONFIG_DIR/commands/`,
   and `~/.claude/commands/`. A subdirectory namespaces the command with `:`
   (`.sigit/commands/git/commit.md` → `/git:commit`). Unlike skills there's no tool-call
   indirection: invoking one works exactly like the built-in `/init` — `commands::render`
@@ -151,7 +180,7 @@ feeds results back. Neither the loop nor ACP/TUI surfaces depend on a concrete b
 - **`src/subagents.rs`** — configurable subagent types for the `task` tool. Discovers Markdown
   files (YAML frontmatter `name` + `description`, optional comma-separated `tools:` allow-list,
   then a Markdown body that becomes the subagent's system prompt) from `.sigit/agents/` and
-  `.claude/agents/` in the cwd, `$SIGIT_CONFIG_DIR/agents/`, and `~/.claude/agents/`. Passing a
+  `.claude/agents/` in every project root, `$SIGIT_CONFIG_DIR/agents/`, and `~/.claude/agents/`. Passing a
   type's `name` as `task`'s `subagent_type` argument swaps in that system prompt and, if `tools:`
   is set, narrows the offered toolset to its *intersection* with `SUBAGENT_TOOL_NAMES` — the
   security-relevant narrowing logic lives in `tools.rs` next to that constant, not here; this
@@ -182,10 +211,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
@@ -201,9 +231,22 @@ feeds results back. Neither the loop nor ACP/TUI surfaces depend on a concrete b
   Reads `AGENTS.md` (the cross-tool [agents.md](https://agents.md) standard) and `CLAUDE.md`,
   walking from the session cwd up to the repo root (nearest ancestor with `.git`, never above it),
   plus a global file under `$SIGIT_CONFIG_DIR`. Files are ordered outermost-first so the deepest
-  (most specific) wins. The combined block is injected via `session_context_message` in `main.rs`
-  — pushed as a system message at every ACP session entry point (new/load/fork + model switch)
-  and appended to the system prompt on the cloud and TUI-startup paths.
+  (most specific) wins. In a multi-root project that walk is repeated for every root
+  (`load_workspace_instructions`). The combined block is injected via `session_context_message`
+  in `main.rs` — pushed as a system message at every ACP session entry point (new/load/fork +
+  model switch) and appended to the system prompt on the cloud and TUI-startup paths.
+- **`src/workspace.rs`** — the directories the session treats as project roots. An editor can
+  open several at once (Zed calls it a multi-root project) and ACP carries the extras as
+  `additional_directories` on every session request; the headless CLI takes them as repeatable
+  `--add-dir` flags. A client only sends those extras to an agent that advertises
+  `sessionCapabilities.additionalDirectories` in its `initialize` reply, so that capability in
+  `handle_initialize` is what makes the rest of this reachable — without it Zed keeps the first
+  root, drops the others, and shows "This agent doesn't currently support multi-root workspaces".
+  The process still has one working directory, so the extra roots live in a
+  process-global here and `project_dirs()` returns cwd-first, extras after. Project-local
+  discovery reads it: skills, slash commands, subagent types, and instruction files all scan
+  every root. MCP is deliberately not on that list — `mcp::init` runs once at startup, before
+  any session exists, so a second root's `.sigit/mcp.toml` has nobody to tell.
 - **`src/chat.rs`** — the Unix-only ratatui TUI. Loading-spinner phase then chat; uses
   `tokio::select!` to multiplex terminal events with streaming tokens.
 - **`src/setup.rs`** — model cache location, local model discovery, selected-model persistence.
@@ -284,6 +327,14 @@ winget, and the AUR PKGBUILD each need one, and they consume the raw binaries ra
 tarball. `release-github` also builds a `.deb` and `.rpm` per Linux target with nfpm
 (`packaging/nfpm.yaml`), packaging the already-built binary rather than re-invoking cargo.
 
+Re-pushing a tag fires every release workflow a second time, so each one is grouped by tag in a
+`concurrency` block with `cancel-in-progress: false` — the duplicate queues behind the original
+rather than interrupting a publish that is halfway through uploading. What keeps the queued run
+from going red is the "is this version already published?" check each publishing workflow does
+before it uploads. Those checks are load-bearing, not belt-and-braces: v1.5.6 published twice
+because the crates.io one asked the API with curl's default User-Agent, which crates.io answers
+with a 403, which read as "not published yet".
+
 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

{sigit_code-1.5.5/.claude → sigit_code-1.5.7/.agents}/skills/agent-client-protocol/SKILL.md

@@ -271,8 +271,14 @@ Ok(ForkSessionResponse::new(new_id).config_options(config_options))
 per-session picker (see Config options below).
 
 The session requests carry `cwd: PathBuf` and (with the feature)
-`additional_directories: Vec<PathBuf>`. siGit stashes `cwd`, `set_current_dir`s
-to it, and pushes a system message telling the model to use absolute paths under it.
+`additional_directories: Vec<PathBuf>` — the other directories of a multi-root
+project, sent only to an agent whose `initialize` reply carries
+`SessionCapabilities::new().additional_directories(SessionAdditionalDirectoriesCapabilities::new())`. `SiGitAgent::enter_session_roots` stashes `cwd`, `set_current_dir`s to
+it, hands the extras to `workspace::set_additional_roots`, and returns the ones
+that survived (a root that isn't a directory, repeats, or just names `cwd` again
+is dropped). `session_context_message` then names every root in the system
+message, and project-local discovery — skills, slash commands, subagent types,
+instruction files — scans all of them, primary root first.
 
 ### `PromptRequest` / blocks
 
@@ -555,8 +561,17 @@ Editor                                Agent
 10. **Zed re-fires the last config selection on connect** — make
     `setConfigOption` a no-op when the requested model is already active, and
     never start a model switch while a startup load is still in flight (GPU OOM).
-11. **Store `SessionId` as `SessionId`**, not `String`, so `==` is clean.
-12. **`SetSessionConfigOptionResponse::new(config_options)`** — the response
+11. **`additional_directories` is not decoration** — dropping it means a
+    multi-root project silently behaves as if only the first root existed, with
+    the other repositories' `AGENTS.md` and skills missing. Route it through
+    `workspace.rs`, not just the log line. Handling it is also only half the
+    job: Zed gates the field on
+    `agentCapabilities.sessionCapabilities.additionalDirectories` being present
+    in the `initialize` reply, so an agent that reads the field but never
+    advertises the capability is never sent one, and the user gets a banner
+    saying the agent has no multi-root support.
+12. **Store `SessionId` as `SessionId`**, not `String`, so `==` is clean.
+13. **`SetSessionConfigOptionResponse::new(config_options)`** — the response
     carries the *rebuilt* options so the picker reflects the new current value.
 
 ---

{sigit_code-1.5.5 → sigit_code-1.5.7}/.agents/skills/sigit-code-release/SKILL.md

@@ -28,9 +28,16 @@ Use this skill when preparing a release for this repository.
 - Update the root `sigit` package entry in `Cargo.lock` when the crate version changes.
 - 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.
+- Every npm package publishes twice, under `@getsigit` and under `@smbcloud`. `@smbcloud` is the pre-1.5.5 name, mirrored so an install predating the rename keeps updating; `@getsigit` is canonical and is what the README, the Homebrew tap, and the ACP registry entry point at. All fourteen names (two base packages, twelve platform packages) publish over OIDC and each needs its own Trusted Publisher on npm pointing at `release-npm.yml`.
+- The scope is a render-time argument, not a second copy of the packaging: `render-platform-package.cjs` takes it as a fifth argument, and the base package picks it up from `package-main.json.tmpl` versus `package-compat.json.tmpl`. `npm/sigit/src/index.ts` is built once and shipped under both names — it reads its own `package.json` at runtime to decide which scope to resolve the platform binary from, and prints the migration notice only when it finds itself running as `@smbcloud/sigit`.
 - 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 +49,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
@@ -51,10 +60,14 @@ Pushing the `v*.*.*` tag is what fires every release workflow, so create and pus
 - `CHANGELOG.md`
 - `README.md`
 - `npm/sigit/package.json`
+- `npm/package-main.json.tmpl`, `npm/package-compat.json.tmpl`, `npm/package.json.tmpl` (publish-time package metadata for both scopes)
 - `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 +80,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.5/.agents → sigit_code-1.5.7/.claude}/skills/agent-client-protocol/SKILL.md

@@ -271,8 +271,14 @@ Ok(ForkSessionResponse::new(new_id).config_options(config_options))
 per-session picker (see Config options below).
 
 The session requests carry `cwd: PathBuf` and (with the feature)
-`additional_directories: Vec<PathBuf>`. siGit stashes `cwd`, `set_current_dir`s
-to it, and pushes a system message telling the model to use absolute paths under it.
+`additional_directories: Vec<PathBuf>` — the other directories of a multi-root
+project, sent only to an agent whose `initialize` reply carries
+`SessionCapabilities::new().additional_directories(SessionAdditionalDirectoriesCapabilities::new())`. `SiGitAgent::enter_session_roots` stashes `cwd`, `set_current_dir`s to
+it, hands the extras to `workspace::set_additional_roots`, and returns the ones
+that survived (a root that isn't a directory, repeats, or just names `cwd` again
+is dropped). `session_context_message` then names every root in the system
+message, and project-local discovery — skills, slash commands, subagent types,
+instruction files — scans all of them, primary root first.
 
 ### `PromptRequest` / blocks
 
@@ -555,8 +561,17 @@ Editor                                Agent
 10. **Zed re-fires the last config selection on connect** — make
     `setConfigOption` a no-op when the requested model is already active, and
     never start a model switch while a startup load is still in flight (GPU OOM).
-11. **Store `SessionId` as `SessionId`**, not `String`, so `==` is clean.
-12. **`SetSessionConfigOptionResponse::new(config_options)`** — the response
+11. **`additional_directories` is not decoration** — dropping it means a
+    multi-root project silently behaves as if only the first root existed, with
+    the other repositories' `AGENTS.md` and skills missing. Route it through
+    `workspace.rs`, not just the log line. Handling it is also only half the
+    job: Zed gates the field on
+    `agentCapabilities.sessionCapabilities.additionalDirectories` being present
+    in the `initialize` reply, so an agent that reads the field but never
+    advertises the capability is never sent one, and the user gets a banner
+    saying the agent has no multi-root support.
+12. **Store `SessionId` as `SessionId`**, not `String`, so `==` is clean.
+13. **`SetSessionConfigOptionResponse::new(config_options)`** — the response
     carries the *rebuilt* options so the picker reflects the new current value.
 
 ---

{sigit_code-1.5.5 → sigit_code-1.5.7}/.claude/skills/sigit-code-release/SKILL.md

@@ -28,9 +28,16 @@ Use this skill when preparing a release for this repository.
 - Update the root `sigit` package entry in `Cargo.lock` when the crate version changes.
 - 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.
+- Every npm package publishes twice, under `@getsigit` and under `@smbcloud`. `@smbcloud` is the pre-1.5.5 name, mirrored so an install predating the rename keeps updating; `@getsigit` is canonical and is what the README, the Homebrew tap, and the ACP registry entry point at. All fourteen names (two base packages, twelve platform packages) publish over OIDC and each needs its own Trusted Publisher on npm pointing at `release-npm.yml`.
+- The scope is a render-time argument, not a second copy of the packaging: `render-platform-package.cjs` takes it as a fifth argument, and the base package picks it up from `package-main.json.tmpl` versus `package-compat.json.tmpl`. `npm/sigit/src/index.ts` is built once and shipped under both names — it reads its own `package.json` at runtime to decide which scope to resolve the platform binary from, and prints the migration notice only when it finds itself running as `@smbcloud/sigit`.
 - 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 +49,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
@@ -51,10 +60,14 @@ Pushing the `v*.*.*` tag is what fires every release workflow, so create and pus
 - `CHANGELOG.md`
 - `README.md`
 - `npm/sigit/package.json`
+- `npm/package-main.json.tmpl`, `npm/package-compat.json.tmpl`, `npm/package.json.tmpl` (publish-time package metadata for both scopes)
 - `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 +80,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.5 → sigit_code-1.5.7}/.github/workflows/release-aur.yml

@@ -12,6 +12,14 @@ on:
         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
 

{sigit_code-1.5.5 → sigit_code-1.5.7}/.github/workflows/release-crates.yml

@@ -10,6 +10,14 @@ on:
         description: "Release tag (e.g. v1.0.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
 
@@ -56,12 +64,32 @@ jobs:
             print(next(p['version'] for p in pkgs if p['name']=='sigit'))")
           echo "version=${VERSION}" >> "$GITHUB_OUTPUT"
 
-          if curl -fsS "https://crates.io/api/v1/crates/sigit/${VERSION}" >/dev/null 2>&1; then
-            echo "sigit ${VERSION} already exists on crates.io, skipping publish"
-            echo "exists=true" >> "$GITHUB_OUTPUT"
-          else
-            echo "exists=false" >> "$GITHUB_OUTPUT"
-          fi
+          # crates.io answers 403 to requests without a descriptive
+          # User-Agent, so curl's default one makes this look like a 404 and
+          # the publish below runs into "crate already exists on the index".
+          # Branch on the status code rather than on curl's exit status, so an
+          # answer we do not understand stops the job instead of quietly
+          # degrading into that same failure.
+          # Retry first, so a timeout or a 5xx costs a few seconds instead of
+          # the whole release.
+          STATUS=$(curl -sS -o /dev/null -w '%{http_code}' \
+            --retry 3 --retry-delay 2 --retry-all-errors \
+            -H "User-Agent: ${GITHUB_REPOSITORY} release workflow (https://github.com/${GITHUB_REPOSITORY})" \
+            "https://crates.io/api/v1/crates/sigit/${VERSION}")
+
+          case "$STATUS" in
+            200)
+              echo "sigit ${VERSION} already exists on crates.io, skipping publish"
+              echo "exists=true" >> "$GITHUB_OUTPUT"
+              ;;
+            404)
+              echo "exists=false" >> "$GITHUB_OUTPUT"
+              ;;
+            *)
+              echo "Unexpected ${STATUS} from crates.io while checking whether sigit ${VERSION} is published" >&2
+              exit 1
+              ;;
+          esac
 
       - name: Publish to crates.io
         if: steps.crates-check.outputs.exists != 'true'

{sigit_code-1.5.5 → sigit_code-1.5.7}/.github/workflows/release-github.yml

@@ -10,6 +10,14 @@ on:
         description: "Release tag (e.g. v0.1.1)"
         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: write
   actions: write

{sigit_code-1.5.5 → sigit_code-1.5.7}/.github/workflows/release-homebrew.yml

@@ -7,6 +7,14 @@ on:
         description: "Release tag (e.g. v0.1.1)"
         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
 

{sigit_code-1.5.5 → sigit_code-1.5.7}/.github/workflows/release-npm.yml

@@ -10,6 +10,14 @@ on:
         description: "Release tag (e.g. v0.1.1)"
         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:
   id-token: write
   contents: read
@@ -108,8 +116,10 @@ jobs:
         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.
+      # Authentication is OIDC: each @getsigit/* and @smbcloud/* package has a
+      # Trusted Publisher pointing at this workflow, so there is no token to
+      # leak. @smbcloud is the pre-1.5.5 scope, published alongside @getsigit
+      # so that an install made before the rename keeps updating.
       - name: Publish platform package to NPM
         shell: bash
         run: |
@@ -141,13 +151,6 @@ jobs:
           # Create the package directory
           mkdir -p "${node_pkg}/bin"
 
-          # Generate package.json + README for this platform slice
-          node ./scripts/render-platform-package.cjs \
-            "${node_pkg}" \
-            "${node_version}" \
-            "${node_os}" \
-            "${node_arch}"
-
           # Windows binaries carry a .exe extension
           if [ "${{ matrix.build.OS }}" = "windows-2022" ]; then
             cargo_bin="${cargo_bin}.exe"
@@ -155,18 +158,36 @@ jobs:
 
           cp "../target/${{ matrix.build.TARGET }}/release/${cargo_bin}" "${node_pkg}/bin"
 
-          cd "${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
+          # One binary, published under both scopes: re-render package.json and
+          # README for each, from the same directory.
+          for scope in "@getsigit" "@smbcloud"; do
+            node ./scripts/render-platform-package.cjs \
+              "${node_pkg}" \
+              "${node_version}" \
+              "${node_os}" \
+              "${node_arch}" \
+              "${scope}"
+
+            npm_package_name="${scope}/${node_pkg}"
+
+            # `npm view` exits non-zero both when the version is genuinely
+            # unpublished and when the registry could not be reached, so treat
+            # only an E404 as "not published yet". Anything else stops the job
+            # instead of publishing over a version that is already there.
+            if view_output=$(npm view "${npm_package_name}@${node_version}" version 2>&1); then
+              echo "${npm_package_name}@${node_version} already exists on npm, skipping publish"
+              continue
+            elif ! grep -q "E404" <<<"${view_output}"; then
+              echo "npm view failed while checking ${npm_package_name}@${node_version}:" >&2
+              echo "${view_output}" >&2
+              exit 1
+            fi
+
+            (cd "${node_pkg}" && npm publish --access public)
+          done
 
   publish-npm-base:
-    name: Publish base NPM package (@getsigit/sigit)
+    name: Publish base NPM packages (@getsigit/sigit, @smbcloud/sigit)
     needs: publish-npm-binaries
     runs-on: ubuntu-latest
 
@@ -200,25 +221,47 @@ jobs:
         shell: bash
         run: npm install -g npm@latest
 
-      - name: Publish base package to NPM
+      - name: Publish base packages to NPM
         shell: bash
         run: |
           cd npm/sigit
 
-          # Rewrite package.json with the correct release version and
-          # matching optionalDependency versions
-          node ../scripts/render-main-package.cjs \
-            "./package.json" \
-            "${{ env.RELEASE_VERSION }}"
-
-          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
-            echo "${npm_package_name}@${npm_package_version} already exists on npm, skipping publish"
-            exit 0
-          fi
+          # Rewrite package.json with the correct release version and matching
+          # optionalDependency versions, then build. The compiled launcher is
+          # scope-agnostic — it reads its own package.json at runtime to decide
+          # which scope to resolve the platform binary from — so both packages
+          # ship the same lib/ and it only needs building once.
+          node ../scripts/render-main-package.cjs \
+            "./package.json" \
+            "${npm_package_version}"
 
           npm install
           npm run build
-          npm publish --access public
+
+          # @getsigit/sigit is the canonical package; @smbcloud/sigit is the
+          # pre-1.5.5 name, kept publishing so installs predating the rename
+          # keep updating. Its template points optionalDependencies at the
+          # @smbcloud platform packages.
+          for template in "package-main.json.tmpl" "package-compat.json.tmpl"; do
+            node ../scripts/render-main-package.cjs \
+              "./package.json" \
+              "${npm_package_version}" \
+              "${template}"
+
+            npm_package_name=$(node -p "require('./package.json').name")
+
+            # Same E404-only reading as the platform packages above: a registry
+            # failure must not look like an unpublished version.
+            if view_output=$(npm view "${npm_package_name}@${npm_package_version}" version 2>&1); then
+              echo "${npm_package_name}@${npm_package_version} already exists on npm, skipping publish"
+              continue
+            elif ! grep -q "E404" <<<"${view_output}"; then
+              echo "npm view failed while checking ${npm_package_name}@${npm_package_version}:" >&2
+              echo "${view_output}" >&2
+              exit 1
+            fi
+
+            npm publish --access public
+          done