2026-09-12 — Non-Go dependencies: none

A single question, answered; no code touched, nothing in flight.

Question: does turbo-core depend on any non-Go library?

Finding: no, and here is the evidence so the next session need not re-run it.

go.mod: three direct (tcell/v2, BurntSushi/toml, golang.org/x/sys), five indirect (gdamore/encoding, go-colorful, uniseg, x/term, x/text). All pure Go.
grep -rn '"C"' --include='*.go' . → nothing. No cgo in this repository.
CGO_ENABLED=0 go build ./... → OK. That is the decisive check: it proves nothing in the graph requires cgo.
Scanning each module in GOMODCACHE for *.c/*.h: only x/sys has any — cpu/cpu_gccgo_x86.c and unix/gccgo_c.c. Both are for the gccgo compiler and are not built by the standard gc toolchain. Do not report these as a native dependency.
net shows up in go list -deps only through lsp/fakeserver_test.go and app/fakelsp_test.go. Test-only.

The distinction worth keeping: no link-time native dependency, but the running editor does exec external binaries — /bin/sh (tools/run.go:19, app/toolchain.go:35) for terminal windows and the tools menu, and the profile's LSP server command (lsp/server.go:92, profile.Profile.Command). If the question ever comes back phrased as "what does a user need installed", that is the answer; "what does it link against" is nothing.

Consequence: a statically linked, cross-compilable binary with no C toolchain needed.

Next steps: none opened by this session. summary.md's "Two direct dependencies plus one" decision (line ~94) still holds and was left byte-for-byte alone.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# 2026-09-12 — Non-Go dependencies: none

A single question, answered; no code touched, nothing in flight.

**Question**: does turbo-core depend on any non-Go library?

**Finding**: no, and here is the evidence so the next session need not re-run it.

- `go.mod`: three direct (`tcell/v2`, `BurntSushi/toml`, `golang.org/x/sys`), five indirect (`gdamore/encoding`, `go-colorful`, `uniseg`, `x/term`, `x/text`). All pure Go.
- `grep -rn '"C"' --include='*.go' .` → nothing. No cgo in this repository.
- `CGO_ENABLED=0 go build ./...` → OK. That is the decisive check: it proves nothing in the graph *requires* cgo.
- Scanning each module in `GOMODCACHE` for `*.c`/`*.h`: only `x/sys` has any — `cpu/cpu_gccgo_x86.c` and `unix/gccgo_c.c`. Both are for the **gccgo** compiler and are not built by the standard `gc` toolchain. Do not report these as a native dependency.
- `net` shows up in `go list -deps` only through `lsp/fakeserver_test.go` and `app/fakelsp_test.go`. Test-only.

**The distinction worth keeping**: no *link-time* native dependency, but the running editor does exec external *binaries* — `/bin/sh` (`tools/run.go:19`, `app/toolchain.go:35`) for terminal windows and the tools menu, and the profile's LSP server command (`lsp/server.go:92`, `profile.Profile.Command`). If the question ever comes back phrased as "what does a user need installed", that is the answer; "what does it link against" is nothing.

**Consequence**: a statically linked, cross-compilable binary with no C toolchain needed.

**Next steps**: none opened by this session. `summary.md`'s "Two direct dependencies plus one" decision (line ~94) still holds and was left byte-for-byte alone.