release/v1.5.10
claude/github-issue-40-0au5ua
claude/linked-issue-acp-tui-u4vvpa
claude/minor-release-cut-vkugow
claude/sigit-acp-local-chat-cx6380
claude/sigit-cloud-agent-expansion-reox0a
claude/tool-permission-system
claude/zen-feynman-0u78dk
development
feature/acp-cancel-request
feature/acp-session-list-cursor
feature/acp-v1-conformance
feature/agent-tools-multiedit-glob-todos-remember
feature/cargo-workspace
feature/hooks
feature/load-local-model-explicitly
feature/sigit-agent-profile
feature/sigit-code-cloud
feature/xcode-mcp-server
fix/acp-replay-loaded-session-history
fix/acp-replay-reasoning-and-attachments
fix/dsml-doubled-bar-markers
main
release/v1.5.10
release/v1.5.6
release/v1.6.1
| 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. |