Add siGit Code vs Copilot CLI parity doc and next three specs

new file mode 100644 index 0000000..41ac2eb --- /dev/null +++ b/docs/product/sigit-code-copilot-cli-parity.md @@ -0,0 +1,170 @@ +# siGit Code vs GitHub Copilot CLI: parity and the three biggest wins + +Status: draft v1 (2026-07-04). Owner: product/eng. Audience: internal (private repo). +Scope: **siGit Code**, the Rust CLI / ACP agent. Companion to +[sigit-code-parity-roadmap.md](sigit-code-parity-roadmap.md), which compares +against Claude Code; this document compares against **GitHub Copilot CLI** and +specifies the next three features. Each spec is implementable on its own branch +off `development` in the `sigit` repo, independent of the others. + +Source basis: GitHub's Copilot CLI docs and changelog as of July 2026. Copilot +CLI went GA in February 2026 and shipped a redesigned terminal interface in June +2026, so this comparison is against a fast-moving GA product, not a preview. + +--- + +## 1. Where we stand + +Copilot CLI is the closest competitor in spirit: a terminal agent that also +speaks ACP and also ships skills, plan mode, MCP, and custom instructions. The +open PRs from the Claude Code roadmap (sigit #22 background commands, #23 +subagent tool, #24 durable sessions and compaction) already close three gaps +that used to be Copilot advantages. What remains: + +| Capability | Copilot CLI | siGit Code today | +|---|---|---| +| Plan mode | yes (Shift+Tab, agent picker) | yes (/plan) | +| Skills / custom instructions | yes | yes (Agent Skills + AGENTS.md/CLAUDE.md) | +| MCP | built-in GitHub server + custom, stdio | official sigit.si server + custom, HTTP only | +| ACP | yes | yes (it is our native protocol) | +| On-device inference | no (BYO endpoint only) | yes, in-process via onde | +| Model picker | Anthropic/OpenAI/Google + reasoning effort | local models + cloud tiers + BYO | +| Context compaction | auto at 95% + /compact + /context | in PR #24 | +| Session resume | yes, across machines + /remote | in PR #24 (local only) | +| Background commands | not first-class | in PR #22 | +| Subagents / custom agents | yes, with automatic delegation | task tool in PR #23 | +| Permission rules | allow/deny patterns like `shell(git push)` | mode + per-tool only | +| Headless / programmatic mode | yes (`copilot -p`, approval flags) | no | +| Git-host workflows in the terminal | Issues/PRs/Actions tabs, create/review/merge | none | +| Sandboxing | local `/sandbox` + cloud `--cloud` | no | +| Hooks | yes | no | +| Persistent memory | Copilot Memory | `remember` tool, no recall layer | + +siGit's edge is real: in-process on-device inference, and ACP as the native +protocol rather than an add-on. The three specs below are where Copilot CLI is +ahead in ways that matter most, ordered smallest to largest. + +--- + +## 2. Spec: permission rule patterns + +**Branch:** `feature/permission-rules` · **Touches:** `src/permissions.rs`, `src/settings.rs` + +### Problem + +The permission system (merged PR #20) knows three modes and per-tool overrides. +That makes autonomy all-or-nothing per tool: `run_command = "allow"` waves +through `rm -rf` along with `cargo test`. Copilot CLI's `--allow-tool +"shell(git push)"` granularity is what makes long unattended runs safe, and our +own longer-running sessions (PR #24 raises the round cap) make this urgent. + +### Design + +- `[permissions.rules]` in settings.toml: ordered lists `allow = [...]` and + `deny = [...]` of rule strings. A rule is `tool_name` or + `tool_name(argument_prefix)`, e.g. `run_command(git status)`, + `run_command(cargo *)`, `edit_file(src/*)`. Matching for `run_command` is + against the command string; for file tools against the path argument. `*` + is a glob-style wildcard (reuse the `glob_to_regex` helper in tools.rs). +- Evaluation order inside `decision_for`, after plan mode and session grants: + deny rules, then allow rules, then the existing per-tool override, then the + default mode. First match wins; deny always beats allow. +- Session grants gain the same granularity: the approval prompt's "always + allow" records `tool(prefix)` for `run_command` (the first token pair of the + command, e.g. `git push`) instead of the bare tool name, so one approval + covers the command family without opening the whole shell. +- `/permissions` prints the active rule lists. + +### Acceptance + +- With `deny = ["run_command(git push*)"]` and `allow = ["run_command(git *)"]`, + `git status` runs, `git push` is denied, everything else asks. +- Rules survive settings reload; unit tests cover ordering, wildcard matching, + and the deny-beats-allow invariant. + +--- + +## 3. Spec: headless programmatic mode + +**Branch:** `feature/headless-mode` · **Touches:** `src/main.rs` (arg parsing, new run mode) + +### Problem + +Copilot CLI's `copilot -p "prompt"` runs one task and exits, which is what CI, +scripts, and cron want. siGit has no equivalent: ACP needs a client and the TUI +needs a TTY. Our own [Cloud Agent plan](sigit-code-cloud-agent-plan.md) needs +exactly this entry point for its sandbox runner, so this spec is on the Cloud +Agent critical path. + +### Design + +- `sigit -p "<prompt>"` (long form `--prompt`): resolve the backend exactly like + the ACP path (provider override, cloud when signed in, on-device), run one + agent turn loop against the prompt with the full toolset, stream assistant + text to stdout, exit 0 on completion. Logs stay on stderr. `--quiet` prints + only the final message. +- Permissions in headless mode: default deny for anything that would ask (there + is nobody to ask). `--allow-tool <rule>` / `--deny-tool <rule>` flags feed the + rule engine from spec 2 for the run; `SIGIT_PERMISSIONS=allow` keeps working + as the blunt instrument. If spec 2 lands second, the flags start as bare tool + names and gain patterns when it lands. +- `--cwd <dir>` sets the working directory; instruction files load from there + like every other entry point. +- Exit codes: 0 success, 1 inference or tool-loop error, 2 bad invocation. + +### Acceptance + +- `sigit -p "list the rust files here and count the tests" --allow-tool + run_command` works in CI (no TTY) against a configured provider and exits 0. +- A prompt that needs a denied tool finishes with the denial surfaced in the + output rather than hanging. +- Integration test drives the built binary with `-p` against the scripted + OpenAI-compatible endpoint harness from `tests/acp_permissions.rs`. + +--- + +## 4. Spec: git-host workflows in the terminal + +**Branch:** `feature/githost-tools` · **Touches:** `src/tools.rs`, official MCP server (sigit-si side) + +### Problem + +Copilot CLI ships a built-in GitHub MCP server plus Issues and Pull requests +tabs: the agent reads issues, opens PRs, reviews and merges without leaving the +terminal. siGit Code has the official sigit.si MCP server baked in but exposes +no repository workflows through it, and sigit.si is literally our own git host. +Our agent should be the best terminal client sigit.si has. + +### Design + +- sigit-si side: extend the official MCP server (`/api/v1/mcp`) with repo + workflow tools for the authenticated user: `list_issues`, `get_issue`, + `create_issue`, `list_pull_requests`, `get_pull_request` (diff included), + `create_pull_request`, `comment_on_pull_request`. Repo defaults to the origin + remote of the session cwd when it points at sigit.si; the tools take an + explicit `repo` argument otherwise. +- siGit Code side: nothing structural, the MCP plumbing already namespaces and + routes these (`mcp__sigit__*`); the work is prompt-level. Teach the system + prompt that issue and PR workflows on sigit.si repos go through those tools, + and classify the read-only ones (`list_*`, `get_*`) as read-only in + `permissions.rs` so browsing issues never prompts. +- GitHub repos: not in scope here. The Git-host adapter direction from the + Cloud Agent plan covers it later; users can already add GitHub's own MCP + server in mcp.toml today, which becomes the documented recipe. + +### Acceptance + +- In a repo cloned from sigit.si, "what open issues mention auth, and open a PR + for this branch that references the right one" works end to end with only + the create/comment steps prompting for permission. +- Server-side request specs cover the new MCP tools; client-side unit tests + cover the read-only classification. + +--- + +## 5. Sequencing + +Permission rules first (smallest, and headless mode wants its flags), then +headless mode (Cloud Agent critical path), then git-host workflows (spans both +repos). Fast follows from the table: stdio MCP transport, hooks, local +sandboxing, and a recall layer over `remember`.