1 # AGENTS.md
2
3 This file provides guidance to AI coding agents when working with code in this repository.
4
5 ## What this is
6
7 `sigit` ("siGit Code") is a single Rust binary: a local-first AI coding agent that runs LLM
8 inference on-device (via the `onde` crate / GGUF models) or against a hosted/OpenAI-compatible
9 endpoint. It exposes itself two ways from the *same* binary, chosen at startup by whether stdin
10 is a TTY:
11
12 - **ACP mode** (stdin not a TTY): speaks the Agent Client Protocol over stdio for editor
13 integration (Zed, VS Code ACP Client). Cross-platform.
14 - **Interactive terminal mode** (stdin is a TTY): a full-screen ratatui chat UI. **Unix-only** —
15 it relies on fd redirection to keep logs out of the TUI, so Windows gets ACP mode only.
16
17 Before the TTY/ACP split, `main` also dispatches the account subcommands `sigit login`,
18 `sigit logout`, `sigit whoami` (see `src/main.rs` `main()`).
19
20 ## Working in this repo
21
22 **IMPORTANT — branch naming:** Prefix every working branch with `feature/` (new functionality)
23 or `fix/` (bug fixes) — never a tool- or agent-name prefix like `claude/`. Name the branch after
24 the *changes it contains*, as a short, descriptive, kebab-case slug that is self-explanatory
25 from the name alone (e.g. `feature/tool-permission-system`, `fix/glob-mtime-sort`), never after
26 a task, ticket, or session id (not `feature/task-q003hm`).
27
28 **IMPORTANT — pull request target:** Always open pull requests against the `development` branch,
29 never `main`. `main` is release-only; `development` is where day-to-day work integrates, and the
30 release merge (see the `sigit-code-release` skill) is the one thing that ever puts commits on
31 `main`.
32
33 This rule needs help to hold, because the repository's default branch is `main`: both
34 `gh pr create` and the GitHub web form pre-select it, so a PR lands on the wrong base unless the
35 base is passed explicitly. Pass it every time, and check that it took:
36
37 ```sh
38 gh pr create --base development --head <branch>
39 gh pr view <number> --json baseRefName
40 ```
41
42 Retargeting a PR that was opened against `main` costs nothing before it merges:
43 `gh pr edit <number> --base development`. After it merges it costs real work — the change sits on
44 `main` while `development`, which the next release is cut from, does not have it, and someone has
45 to carry it back by hand. PR #65 went in that way.
46
47 **IMPORTANT — branch off `development`:** Start every working branch from the latest
48 `origin/development`. Exception: when new work *depends on* a feature branch that has not merged
49 yet (e.g. it builds on tools or APIs that branch introduces), it may be stacked on top of that
50 branch instead. When stacking: merge the base PR into `development` first, then rebase the
51 stacked branch onto `development` before opening its pull request, so each PR shows only its own
52 commits.
53
54 **IMPORTANT — run CI before pushing:** Run the full CI gate locally and confirm it is green
55 *before* pushing a branch or opening a pull request — never push work that fails these:
56
57 ```sh
58 cargo fmt -- --check # formatting
59 cargo clippy --tests -- -D warnings # lint (warnings are errors)
60 cargo test --locked # tests
61 ```
62
63 ## Agent assets layout
64
65 `.agents/` is the canonical home for agent assets; every other agent path in
66 the repo is a symlink into it, never a copy:
67
68 - `.agents/AGENTS.md` — this file, the project instructions. The root
69 `AGENTS.md` and `CLAUDE.md` are symlinks to it, so agents.md-standard tools,
70 Claude Code, and sigit itself (via `src/instructions.rs`, which prefers
71 `AGENTS.md` over `CLAUDE.md` in the same directory and therefore reads it
72 once) all load the same content. Edit this file; never replace the root
73 symlinks with real files.
74 - `.agents/skills/` — all project skills. `.claude/skills` is a symlink to it,
75 which is how both Claude Code and sigit itself (via `src/skills.rs`) discover
76 them. Add new skills under `.agents/skills/<name>/SKILL.md`, never as real
77 files under `.claude/`.
78
79 ## Build / test / lint
80
81 ```sh
82 cargo build # debug build
83 cargo build --release # release binary at target/release/sigit
84 cargo run # launches interactive TUI (stdin is a TTY)
85 cargo test # CI runs: cargo test --locked --target <target>
86 cargo clippy --tests -- -D warnings # CI gate: clippy is -D warnings on all 4 targets
87 cargo fmt -- --check # CI gate (edition 2024)
88 ```
89
90 CI (`.github/workflows/ci.yml`) runs fmt + clippy + test across four targets:
91 `aarch64-apple-darwin`, `x86_64-apple-darwin`, `x86_64-unknown-linux-gnu`,
92 `x86_64-pc-windows-msvc`. Clippy is `-D warnings`, so warnings fail the build.
93
94 Run a single test: `cargo test <test_name>`.
95
96 ## Critical platform constraint: `#[cfg(unix)]` dead code
97
98 The interactive client is `#[cfg(unix)]`-only. The `InferenceBackend` seam (`backend.rs`) and
99 provider resolution (`provider.rs`) are consumed by both the interactive client and the ACP
100 server, but several of their items are reached only through the Unix-only interactive paths, so
101 the dead-code lint is suppressed *on non-Unix targets only*.
102
103 Consequence: code can pass clippy on macOS/Linux but fail on the Windows target (or vice versa).
104 When touching `backend.rs`, `provider.rs`, or the interactive path, keep the `cfg` gates intact —
105 don't "fix" an unused-warning by deleting code that's live on Unix.
106
107 ## Architecture
108
109 The agent loop is backend-agnostic. The flow: a turn (messages + tool specs) goes to an
110 `InferenceBackend`, which returns assistant text and/or tool calls; the loop executes tools and
111 feeds results back. Neither the loop nor ACP/TUI surfaces depend on a concrete backend.
112
113 - **`src/main.rs`** — entry point, mode dispatch, the full ACP `Agent` impl (session lifecycle:
114 new/load/fork/prompt/cancel, config options, slash-command advertisement), and the `SYSTEM_PROMPT`
115 (note: it bakes in smbCloud-specific context the agent should use when the repo is clearly
116 smbCloud, and stay general otherwise).
117 - **`src/backend.rs`** — the `InferenceBackend` trait and neutral types (`ToolSpec`, `ToolCall`,
118 `ToolResult`, `TurnResult`). Two impls: `LocalBackend` (on-device via `onde::ChatEngine`) and
119 `OpenAiBackend` (any OpenAI-compatible HTTP endpoint). A `BackendError` is user-facing: the
120 ACP prompt handler passes it to the client verbatim and the editor puts it in an error banner,
121 so `describe_api_error` unwraps the OpenAI `{"error":{"message":…}}` envelope and shows that
122 message on its own, falling back to the status only when there is nothing to unwrap. An
123 endpoint can also fail *after* the response is open, reporting it as a `data:` frame holding
124 the same envelope; that frame has no `choices`, so `consume_stream` has to check for it
125 explicitly or it parses as an empty chunk and the turn ends looking like an empty answer.
126 - **`src/provider.rs`** — decides *which* backend serves inference. Resolution order, first match
127 wins: (1) override via `OPENAI_BASE_URL`+`OPENAI_API_KEY` or active profile in
128 `~/.config/sigit/providers.toml`; (2) siGit Code Cloud when logged in; (3) on-device.
129 - **`src/tools.rs`** — agent tool schemas + execution: `read_file`, `create_directory`,
130 `list_directory`, `search_files`, `glob`, `read_website`, `create_file`, `edit_file`,
131 `multi_edit`, `delete_file`, `run_command`, `write_todos`, `remember`. Add a tool in both the
132 spec list (`all_tools`) and the execute `match` (`execute_tool`). `run_command` also enforces
133 commit attribution: when a command creates a new commit that lacks the
134 `Co-Authored-By: siGit Code` trailer (`COMMIT_CO_AUTHOR_TRAILER`), it amends the trailer in —
135 unless the commit already exists on a remote, which is never rewritten. Every child process it
136 spawns (`spawn_shell`, the `git` helpers, and `hooks.rs`) sets `stdin` to null and never
137 inherits it: in ACP mode sigit's stdin is the JSON-RPC pipe from the editor, so a command that
138 reads stdin both blocks forever and eats the client's next request, wedging the session past
139 any timeout. On Unix the shell also leads its own process group so the timeout kills the whole
140 tree, and stdout/stderr are drained on threads while the command runs — waiting first and
141 reading after deadlocks as soon as the output outgrows the pipe buffer. Also owns the `task`
142 tool: a nested agent loop in a fresh conversation, offered only when `subagent_available()`
143 (a subagent factory is registered — see `register_subagent_factory_for` in `main.rs`; on-device
144 registers a `None`-returning factory since onde has a single shared history). A subagent's
145 toolset is a hard-gated read-only allow-list (`SUBAGENT_TOOL_NAMES`) that is never expanded by a
146 configurable subagent type (see `src/subagents.rs`) — only ever narrowed — so a `.sigit/agents/*.md`
147 file can't grant itself `edit_file`/`run_command` and bypass the permission system. Also owns
148 `web_search`: a thin native wrapper around the official MCP server's Brave-Search-backed
149 `web_search` tool (`mcp__sigit__web_search`, implemented server-side in `sigit-si`'s
150 `WebSearchService` + `Mcp::Tools::WebSearch`), offered only when that MCP tool was actually
151 discovered (i.e. the user is signed in to siGit Code Cloud — see `web_search_available`).
152 Wrapping it natively rather than leaving it as a raw `mcp__*` tool matters for two reasons:
153 `permissions::classify` treats every `mcp__*` tool as mutating (an "ask" prompt on every call),
154 while `web_search` is read-only like `read_website`; and the raw delegate name is filtered out
155 of the assembled tool list (`is_web_search_delegate`) so the model sees one clean option, not
156 two names for the same tool. Execution still forwards verbatim to `mcp::call_tool` — no second
157 HTTP/JSON-RPC implementation.
158 - **`src/skills.rs`** — [Agent Skills](https://agentskills.io) support. Discovers skill
159 folders (each with a `SKILL.md`: YAML frontmatter `name` + `description`, then Markdown
160 instructions) from `.sigit/skills/` and `.claude/skills/` in every project root (see `src/workspace.rs`),
161 `$SIGIT_CONFIG_DIR/skills/`,
162 and `~/.claude/skills/`. Progressive disclosure: the discovery list (name + description) is
163 baked into the dynamically-built `skill` tool's description, and activating a skill (the model
164 calls `skill` with a name) loads the full `SKILL.md` body. The `skill` tool is appended in the
165 `*_as_specs`/`build_tool_specs` layer (not in `all_tools()`) so its description can be dynamic,
166 and only when at least one skill exists.
167 - **`src/commands.rs`** — user-defined slash commands. Discovers Markdown files (each an
168 optional YAML frontmatter block — `description`, `argument-hint` — followed by a prompt-template
169 body) from `.sigit/commands/` and `.claude/commands/` in every project root, `$SIGIT_CONFIG_DIR/commands/`,
170 and `~/.claude/commands/`. A subdirectory namespaces the command with `:`
171 (`.sigit/commands/git/commit.md` → `/git:commit`). Unlike skills there's no tool-call
172 indirection: invoking one works exactly like the built-in `/init` — `commands::render`
173 substitutes `$ARGUMENTS`/`$1..$9` in the body against whatever followed the command on the
174 input line, and the result is fed to the model as a normal turn through the ordinary tools and
175 permission checks. Resolution happens where each surface (`main.rs`/`chat.rs`) already
176 special-cases `/init`: an unrecognized slash command is tried against `commands::resolve_command`
177 before falling back to "unknown command". A custom command sharing a name with a built-in is
178 unreachable (built-ins match first in `parse_slash`) and is skipped when advertised to ACP
179 clients, with a warning logged.
180 - **`src/subagents.rs`** — configurable subagent types for the `task` tool. Discovers Markdown
181 files (YAML frontmatter `name` + `description`, optional comma-separated `tools:` allow-list,
182 then a Markdown body that becomes the subagent's system prompt) from `.sigit/agents/` and
183 `.claude/agents/` in every project root, `$SIGIT_CONFIG_DIR/agents/`, and `~/.claude/agents/`. Passing a
184 type's `name` as `task`'s `subagent_type` argument swaps in that system prompt and, if `tools:`
185 is set, narrows the offered toolset to its *intersection* with `SUBAGENT_TOOL_NAMES` — the
186 security-relevant narrowing logic lives in `tools.rs` next to that constant, not here; this
187 module only discovers and parses files. `SubagentFactory` (in `tools.rs`) takes the resolved
188 system prompt per call rather than baking one in at registration, so a single registered
189 factory serves both the default research subagent and every configured type.
190 - **`src/frontmatter.rs`** — shared "YAML frontmatter + Markdown body" parsing used by both
191 `src/skills.rs` (`SKILL.md`) and `src/commands.rs` (`.sigit/commands/*.md`).
192 - **`src/mcp.rs`** — [Model Context Protocol](https://modelcontextprotocol.io) *client*. Two
193 transports: **Streamable HTTP** (one JSON-RPC POST endpoint, `url` in `mcp.toml`; replies are
194 `application/json` or SSE) and **stdio** (`command` + optional `args`/`[server.env]` in
195 `mcp.toml`; sigit spawns the server and speaks newline-delimited JSON-RPC over its
196 stdin/stdout, stderr inherited into sigit's log). `url` and `command` are mutually exclusive —
197 both or neither is a config error, logged and skipped. Both transports run the same
198 `initialize`/`tools/list` handshake and forward `tools/call`. Discovery is best-effort at
199 startup (`mcp::init`, called from both branches of `main()`) and cached in a process-global so
200 the synchronous spec builders (`mcp::tool_specs`) and the async dispatch (`mcp::call_tool`) can
201 both read it; `/reload` does *not* re-run it, so config changes need a restart. stdio children
202 live for the process; a dead child fails calls with an in-band error string (no auto-restart).
203 Tools are namespaced `mcp__<server>__<tool>`, appended in the `*_as_specs`/`build_tool_specs`
204 layer and routed in `tools::execute_tool` via `mcp::is_mcp_tool`. Two servers are baked in:
205 the official server (`<cloud>/mcp`, default `https://sigit.si/api/v1/mcp`, always HTTP, authed
206 with the cloud session token) and the smbCloud CLI server (`smb --mcp`, stdio, added only when
207 the `smb` binary is on `PATH`; opt out with `smbcloud = false` in `mcp.toml` or
208 `SIGIT_MCP_SMBCLOUD=off`). A user-defined entry named `sigit` or `smbcloud` overrides the
209 corresponding baked-in one. Extra servers live in `mcp.toml` (global
210 `$SIGIT_CONFIG_DIR/mcp.toml` and project-local `.sigit/mcp.toml`). The stdio path is covered by
211 `tests/mcp_stdio.rs`, driven by the test-only `src/bin/mcp_stdio_stub.rs` helper binary
212 (excluded from the published crate via `exclude` in `Cargo.toml`). The baked-in official
213 server is *also* listed in the public MCP Registry as `si.sigit/sigit` — a **remote**
214 Streamable-HTTP listing owned by the [`getsigit/si`](https://github.com/getsigit/si) repo
215 (`server.json` at its root, published by its `release-mcp-registry.yml`), not this one. Because
216 it's a remote server, the registry's URL-match rule forces a domain namespace (`si.sigit` ↔
217 `sigit.si`) verified by a DNS TXT record, not the GitHub-OIDC scheme `smbcloud-cli` uses for its
218 package listing.
219 - **`src/permissions.rs`** — tool permission policy. Every tool call passes through
220 `decision_for` before executing: read-only tools always run; mutating tools (and all
221 `mcp__*`/unknown tools) are governed by, in order: per-session plan mode (`/plan` — deny all
222 mutating tools with a present-a-plan message), session "always allow" grants, per-tool
223 overrides and the default mode from `[permissions]` in `settings.toml` (`allow`/`ask`/`deny`,
224 default `ask`; `SIGIT_PERMISSIONS` env overrides the default). On `ask`, the ACP path sends
225 `session/request_permission` (allow once / allow for session / deny) and the TUI pauses the
226 inference task on a y/a/n prompt. Note: ACP turn-affecting handlers run in `cx.spawn`ed tasks
227 serialized by `SiGitAgent::turn_lock` so the dispatch loop can route the client's permission
228 answer mid-turn — don't move them back inline, and don't await client requests from inline
229 handlers (deadlock).
230 - **`src/instructions.rs`** — project instruction files, the always-on counterpart to skills.
231 Reads `AGENTS.md` (the cross-tool [agents.md](https://agents.md) standard) and `CLAUDE.md`,
232 walking from the session cwd up to the repo root (nearest ancestor with `.git`, never above it),
233 plus a global file under `$SIGIT_CONFIG_DIR`. Files are ordered outermost-first so the deepest
234 (most specific) wins. In a multi-root project that walk is repeated for every root
235 (`load_workspace_instructions`). The combined block is injected via `session_context_message`
236 in `main.rs` — pushed as a system message at every ACP session entry point (new/load/fork +
237 model switch) and appended to the system prompt on the cloud and TUI-startup paths.
238 - **`src/workspace.rs`** — the directories the session treats as project roots. An editor can
239 open several at once (Zed calls it a multi-root project) and ACP carries the extras as
240 `additional_directories` on every session request; the headless CLI takes them as repeatable
241 `--add-dir` flags. A client only sends those extras to an agent that advertises
242 `sessionCapabilities.additionalDirectories` in its `initialize` reply, so that capability in
243 `handle_initialize` is what makes the rest of this reachable — without it Zed keeps the first
244 root, drops the others, and shows "This agent doesn't currently support multi-root workspaces".
245 The process still has one working directory, so the extra roots live in a
246 process-global here and `project_dirs()` returns cwd-first, extras after. Project-local
247 discovery reads it: skills, slash commands, subagent types, and instruction files all scan
248 every root. MCP is deliberately not on that list — `mcp::init` runs once at startup, before
249 any session exists, so a second root's `.sigit/mcp.toml` has nobody to tell.
250 - **`src/chat.rs`** — the Unix-only ratatui TUI. Loading-spinner phase then chat; uses
251 `tokio::select!` to multiplex terminal events with streaming tokens.
252 - **`src/setup.rs`** — model cache location, local model discovery, selected-model persistence.
253 Must run (`setup_shared_model_cache`) *before* anything touches `ChatEngine`/`hf-hub`, since
254 those read env vars once at init.
255 - **`src/account.rs`** — siGit Code Cloud auth (`/login`, `/logout`, `/whoami`); authenticates
256 against the account API and stores a session token. Performs no console I/O.
257 - **`src/browser_auth.rs`** — browser sign-in, the path the editor's "Sign in to siGit Code"
258 button takes. sigit is a public OAuth client (client id `sigit-code-cli`, no secret, PKCE
259 S256) against the authorization server at `$SIGIT_API_URL/oauth`. Two ways the code gets
260 back: a loopback listener on `127.0.0.1:0` (the registration lists `http://127.0.0.1/callback`
261 with no port, and RFC 8252 §7.3 matching ignores the port, so one registration covers every
262 run), or the out-of-band URN, where the server renders the code and the user pastes it. The
263 resulting token goes into `credentials` like any other, and is served by `/api/v1/user` rather
264 than the deprecated `/api/v1/me` — OAuth tokens are rejected there. The scopes requested are
265 `user:read code:agent`; `code:agent` is what reaches `chat/completions` and the official MCP
266 server. Surfaces: ACP `authenticate` (loopback only — nowhere to show a code), a bare `/login`
267 in either chat surface, and `sigit login` (which adds the paste fallback, plus `--paste` to
268 force it and `--password` for the old email/password prompt).
269 - **`src/credentials.rs`** — local session-token store (TOML, `0600` on Unix).
270 - **`src/models.rs`** — model-picker types shared across platforms.
271
272 Slash commands (`/help`, `/models`, `/skills`, `/agents`, `/commands`, `/mcp`, `/login`, `/logout`,
273 `/whoami`, `/reload`, `/plan`, `/permissions`, `/init`, `/clear`, `/status`) are advertised via
274 `advertise_commands` in `main.rs` and handled in both the TUI and ACP sessions. `/init` is
275 special: instead of replying directly it substitutes `instructions::INIT_PROMPT` for the user
276 text and runs a normal agent turn that explores the repo and writes (or improves) `AGENTS.md`
277 through the ordinary tools and permission checks. User-defined commands (see `src/commands.rs`)
278 get the same treatment via the `SlashCommand::Unknown` fallback path, so anyone can add their own
279 `/name` commands without touching the built-in command list.
280
281 ## Model cache (macOS)
282
283 On macOS the HF model cache lives in an App Group container shared with the siGit desktop app:
284 `~/Library/Group Containers/group.com.ondeinference.apps/models/`. Other platforms fall back to
285 `~/.cache/huggingface/`. The CLI reuses a model the desktop app already downloaded. First run
286 downloads a GGUF model (~1–2 GB) from Hugging Face.
287
288 ## Logging
289
290 In TTY (interactive) mode, *all* output — `log`, `tracing`, stray `println!` — is redirected to
291 `$TMPDIR/sigit.log` so the ratatui surface stays clean; the TUI holds a separate fd to the real
292 terminal. In ACP mode, stdout is reserved for protocol JSON and logs go to stderr. Control
293 verbosity with `RUST_LOG`.
294
295 ## Relevant env vars
296
297 `OPENAI_BASE_URL` / `OPENAI_API_KEY` (provider override), `SIGIT_API_URL` (account API base,
298 default `https://sigit.si`), `SIGIT_CLOUD_URL`, `SIGIT_CONFIG_DIR` (default `~/.config/sigit`),
299 `SIGIT_MODEL`, `SIGIT_MCP` (`off` disables MCP), `SIGIT_MCP_SMBCLOUD` (`off` drops the baked-in
300 smbCloud CLI server), `SIGIT_MCP_OFFICIAL` (`off` drops the baked-in
301 server), `SIGIT_PERMISSIONS` (`allow`/`ask`/`deny` — overrides the default permission mode for
302 mutating tools; the escape hatch for clients without permission-request support),
303 `HF_HOME` / `HF_HUB_CACHE`, `RUST_LOG`.
304
305 ## Releasing
306
307 Version lives in `Cargo.toml`. Update `CHANGELOG.md` for releases.
308
309 Publishing splits into two groups. **Language registries** each get their own tag-triggered
310 workflow: `release-crates`, `release-npm`, `release-nuget`, `release-pypi`. The `npm/`, `nuget/`,
311 and `pypi/` dirs hold their wrapper-package templates.
312
313 npm and NuGet authenticate with OIDC (Trusted Publishing), so neither needs a stored token. On
314 npm that is configured per package, not per org: all seven `@getsigit/*` names carry a trusted
315 publisher pointing at `release-npm.yml`, and a package added later needs the same setup or its
316 publish step will fail. OIDC also requires npm >= 11.5.1 and Node >= 22.14.0, which is why the
317 workflow upgrades npm and why `.nvmrc` cannot drop below 22.
318
319 **OS package managers** all publish somewhere outside this repo and all need checksums from the
320 GitHub release, so `release-github` builds the binaries, attaches the assets, and then dispatches
321 `release-homebrew`, `release-scoop`, `release-winget`, and `release-aur`. A dispatch failure in one
322 is logged as a warning rather than failing the others, so an unconfigured channel does not block a
323 release. Their inputs live in `packaging/`.
324
325 Every release asset now carries a `.sha256` sidecar, not just the macOS Homebrew tarball. Scoop,
326 winget, and the AUR PKGBUILD each need one, and they consume the raw binaries rather than the
327 tarball. `release-github` also builds a `.deb` and `.rpm` per Linux target with nfpm
328 (`packaging/nfpm.yaml`), packaging the already-built binary rather than re-invoking cargo.
329
330 Re-pushing a tag fires every release workflow a second time, so each one is grouped by tag in a
331 `concurrency` block with `cancel-in-progress: false` — the duplicate queues behind the original
332 rather than interrupting a publish that is halfway through uploading. What keeps the queued run
333 from going red is the "is this version already published?" check each publishing workflow does
334 before it uploads. Those checks are load-bearing, not belt-and-braces: v1.5.6 published twice
335 because the crates.io one asked the API with curl's default User-Agent, which crates.io answers
336 with a 403, which read as "not published yet".
337
338 Three of these need credentials or a one-time manual step before they work:
339
340 - Scoop needs a `getsigit/scoop-bucket` repo and a `SCOOP_BUCKET_TOKEN` secret, mirroring the
341 Homebrew tap setup.
342 - winget needs a `WINGET_TOKEN` (PAT with `public_repo`) so `wingetcreate` can fork
343 `microsoft/winget-pkgs`. It is passed as `WINGET_CREATE_GITHUB_TOKEN` rather than `--token`,
344 which wingetcreate warns can leak the token into logs. `wingetcreate update` only works on a
345 package that already exists in `microsoft/winget-pkgs`, so the workflow checks the
346 `manifests/g/getSigit/siGitCode` path first and falls back to rendering
347 `packaging/winget/*.yaml.in` and running `wingetcreate submit` for a first submission. That
348 fallback runs once, then every later release takes the `update` path.
349 - The AUR needs `AUR_USERNAME`, `AUR_EMAIL`, and `AUR_SSH_PRIVATE_KEY`. It publishes `sigit-bin`
350 (a prebuilt binary) so Arch users are not compiling the on-device inference stack to install a
351 CLI.
352
353 `[profile.release]` sets `strip = "symbols"` because binary size is a distribution constraint, not
354 just a nicety. See the NuGet note below.
355
356 The NuGet package (`SiGit.Code`, installed with `dotnet tool install --global SiGit.Code`) is the
357 odd one out among the language registries: npm and PyPI publish one artifact per platform, but a
358 .NET tool is a single package, so `nuget/sigit/` bundles all six binaries under
359 `native/<os>-<arch>/` and a small managed shim (`Program.cs`) execs the right one. That shim leaves
360 stdin/stdout/stderr unredirected on purpose, since siGit Code chooses TUI or ACP mode by testing
361 whether stdin is a TTY. It also sets `RollForward=Major`: it targets `net8.0`, and without that a
362 machine carrying only the .NET 10 runtime installs a tool that refuses to start.
363
364 Bundling every target means the package is large, so `release-nuget.yml` fails the pack job if the
365 `.nupkg` crosses nuget.org's 250 MB limit. At v1.5.1 it lands around 160 MB. If a future release
366 trips that check, the fix is not to drop targets but to split into RID-specific tool packages
367 (.NET 10's `DotnetToolRidPackage`), which ship one binary per platform the way npm already does.
368 That also needs a fallback package for pre-.NET-10 SDKs.