screpdb

README

screpdb

screpdb is an advanced Starcraft replay reporting tool.

English | 한국어

▶️ Try it in your browser — the full dashboard on sample replays, no install, runs entirely client side.

_{28.88 ms/replay · corpus: 166 replays · GitHub-hosted 2-core runner · updated automatically on merge to main}

Features

Filtering and finding replays by high-level semantic features

Game summary: each player's noteworthy semantic events and unit composition

Rich game events browser with map overlays

Hotkey intel: what each player keeps on which key, all game long

…and the hotkeyed buildings drawn on the map where they were built

Build order detection, de-duped and charted against usual progamer timings

Built-in progamer profiles alongside the players in your own library

Skill proxies: viewport multitasking, unit production cadence, first unit efficiency

Per-player hotkey signature, including the built-in progamers

Alliance timeline and team stacking detection on multiplayer melee games

Installation

See CHANGELOG.md for release notes.

⚠️ Security: On Windows, screpdb runs its worker at Low integrity — the OS confines all of screpdb's writes to a single app-data folder, so even a compromised replay/map parser cannot write elsewhere on your machine (see Security / I/O model). On macOS and Linux there is no OS sandbox yet: screpdb routes all its own I/O through in-process facades (writes confined to the app-data dir and the replays folder, no outbound network calls beyond user-initiated self-update), but these are best-effort guardrails rather than an OS boundary, so exercise judgement before running it.

Windows — recommended: install with Scoop

👉 Recommended: install with Scoop. Open PowerShell and paste these commands:

scoop install git   # required by 'scoop bucket add' (skip if you already have git)
scoop bucket add screpdb https://github.com/marianogappa/screpdb
scoop install screpdb

That's it. Now run screpdb-gui (the app opens in your browser), or screpdb for the CLI.

To upgrade later, just run:

scoop update screpdb

💡 Seeing an old version, or install fails on a missing file? Your local copy of the bucket is a git clone that only refreshes on scoop update. Run scoop update (no package name) first to pull the latest manifest, then scoop install screpdb / scoop update screpdb.

Scoop is the happy path because it downloads without a browser, so Windows won't show the "unidentified developer" / SmartScreen warning, and upgrades are one command. Don't have Scoop yet? Install it first (one line, from scoop.sh):

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
irm get.scoop.sh | iex

Prefer a direct download? (expect a SmartScreen warning)

Grab screpdb-gui-windows-amd64.exe (the GUI; screpdb-windows-amd64.exe is the CLI) from the Releases page and double-click it.

The binaries are not code-signed, so on first launch Windows may warn you — none of these mean the binary is malicious:

• SmartScreen "Windows protected your PC". Click More info → Run anyway.
• Microsoft Defender or third-party antivirus may flag or silently quarantine the binary. Unsigned Go binaries that read files and make network requests are a known false-positive pattern. If the file vanishes from Downloads, check Defender's Protection History and restore it (or add an exclusion).
• Enterprise machines running AppLocker or Windows Defender Application Control may block it outright. There's no workaround without code signing.

The GUI binary is a windowed app with no console — if you dismiss the SmartScreen dialog it simply won't start and won't print an error. Scoop avoids all of this. You can also build from source.

💡 Want the in-app Update button to work? Put the .exe in a folder you can write to without admin rights — e.g. create %LOCALAPPDATA%\Programs\screpdb\ and drop it there. screpdb can only replace its own binary when its folder is user-writable, so C:\Program Files\ (needs admin) won't self-update. Otherwise the app just shows the download link instead.

The Scoop manifest lives at bucket/screpdb.json and is bumped automatically on each release.

Linux — one-line installer, or Homebrew

Install with one command (downloads the right binary, verifies it against the release's signed SHA256SUMS, drops it on your PATH):

curl -fsSL https://raw.githubusercontent.com/marianogappa/screpdb/main/install.sh | sh

Then run screpdb. To upgrade, re-run the same command (or use the in-app Update button).

🔍 Don't pipe scripts you haven't read. install.sh is deliberately short and dependency-free so you can audit it in under a minute — it only downloads the binary for your OS/arch, checks it against the release's signed SHA256SUMS, and copies it to ~/.local/bin. To read it first, then run your local copy:

curl -fsSL https://raw.githubusercontent.com/marianogappa/screpdb/main/install.sh -o screpdb-install.sh
less screpdb-install.sh   # audit it
sh screpdb-install.sh

Prefer Homebrew / Linuxbrew?

brew install marianogappa/screpdb/screpdb   # upgrade later: brew update && brew upgrade screpdb

Or download the binary for your architecture from the Releases page, make it executable, and move it onto your PATH — put it in a writable folder (not a Homebrew prefix) so the in-app Update button works:

chmod +x screpdb-linux-amd64                              # or screpdb-linux-arm64
mkdir -p ~/.local/bin && mv screpdb-linux-amd64 ~/.local/bin/screpdb

~/.local/bin is the one-line installer's default — any writable folder on your PATH works. Binaries fetched via curl/brew carry no quarantine flag, so they just run.

💡 screpdb self-updates only when its folder is user-writable and not owned by a package manager. A binary you run from ~/Downloads or a Homebrew prefix won't auto-update — the app falls back to showing the download command instead.

macOS — Homebrew, or one-line installer

Install with Homebrew:

brew install marianogappa/screpdb/screpdb   # upgrade later: brew update && brew upgrade screpdb

Or the one-line installer (verifies it against the release's signed SHA256SUMS, installs to ~/.local/bin):

curl -fsSL https://raw.githubusercontent.com/marianogappa/screpdb/main/install.sh | sh

Wary of piping to sh? It's the same install.sh shown in the Linux section above — read it first, then run your local copy.

Then run screpdb. No Gatekeeper "unidentified developer" block with either method — brew and curl don't attach the quarantine attribute that triggers it, so the binary just runs (no notarization needed).

Prefer a direct download? (this one does hit Gatekeeper)

Download the binary for your architecture from the Releases page, then clear the quarantine flag and move it onto your PATH — a writable folder (not a Homebrew prefix) so the in-app Update button works:

chmod +x screpdb-darwin-arm64                          # or screpdb-darwin-amd64
xattr -d com.apple.quarantine screpdb-darwin-arm64     # clear the browser-download quarantine
mkdir -p ~/.local/bin && mv screpdb-darwin-arm64 ~/.local/bin/screpdb

(Or right-click the binary → Open to approve it once.) ~/.local/bin matches the one-line installer's default.

💡 screpdb self-updates only when its folder is user-writable and not owned by a package manager. A binary you run straight from ~/Downloads or a Homebrew prefix won't auto-update — the app falls back to showing the download command instead.

Building from source

You'll need Go 1.25.2 or later. Use make build (not a bare go build) so the embedded dashboard UI assets are rebuilt first:

git clone https://github.com/marianogappa/screpdb.git
cd screpdb
make build

Uninstall

1. Remove the binary

Installed with	Command
Scoop (Windows)	scoop uninstall screpdb
Homebrew (macOS/Linux)	brew uninstall screpdb
One-line installer / manual	Delete the binary you placed (e.g. ~/.local/bin/screpdb)

2. Delete the data folder (optional — skip this to keep your data for a future reinstall).

# Windows (PowerShell)
Remove-Item -Recurse -Force "$env:LOCALAPPDATA\screpdb"

# macOS
rm -rf "$HOME/Library/Application Support/screpdb"

# Linux
rm -rf "${XDG_CONFIG_HOME:-$HOME/.config}/screpdb"

Developer features

MCP server and full OpenAPI — click to expand

• Server / API: ./screpdb dashboard (also the default when run with no subcommand) starts the HTTP server and opens the dashboard UI. All UI functionality is exposed as a JSON API — OpenAPI schema available. Run it headless as an API-only server (no UI, no browser) with --headless:

./screpdb dashboard --headless -p 8000
# then: curl http://localhost:8000/api/health

• MCP server: point an MCP client (Claude Desktop, Claude Code, Cursor, …) at your replays and ask questions in natural language about any game, player, matchup, build order, or event. A curated read-only subset of the API is reachable; nothing that changes local state is.

./screpdb mcp

If you want to build something on top of screpdb's API or MCP, let me know. I'm open to facilitating this, but I won't add untested features otherwise.

Specification — how the numbers are computed

Every golden value — unit stats, build times, expert timings, detection thresholds — is generated from source and test-backed (see SPECIFICATION.md)

screpdb makes a lot of derived claims: "this is a 9 Pool", "your Spawning Pool was 6s late", "a Zealot takes 25.2s". Skeptical? Audit them.

SPECIFICATION.md documents every golden value the app relies on — unit names, build times, expert timings, costs, tech-tree rules, detection thresholds, and more. It's:

• Generated from the Go source of truth (go generate ./...), so it can't drift from the code.
• Test-backed — CI fails if any value is wrong or the file is stale.

In short: not aspirational docs that rot, but a provably-accurate description of what the app actually does.

Verifying downloads — checksums + minisign signature

Each release publishes a SHA256SUMS file and a SHA256SUMS.minisig minisign signature alongside the binaries.

Verify the checksum (Linux/macOS):

sha256sum -c SHA256SUMS --ignore-missing

Verify the checksum (Windows PowerShell):

Get-FileHash screpdb-windows-amd64.exe -Algorithm SHA256
# Compare the printed hash against the line in SHA256SUMS

Verify the signature (requires minisign):

minisign -Vm SHA256SUMS -P 'RWS9gPPOydPD/tR8JBOelXKhif526NoAKY18dau7QHR4dqg84QMhJ5L/'

Security / I/O model

screpdb minimizes its attack surface by routing all I/O through facades and keeping dependencies small (see #135). On macOS and Linux this is a best-effort, in-process guard; on Windows a Low-integrity worker adds a real OS write boundary.

How the I/O model works — filesystem, Windows sandbox, network, self-update, enforcement

• Filesystem — all disk access goes through internal/iofacade, which permits reads/writes only within: a single per-OS app-data directory (%LOCALAPPDATA%\screpdb on Windows, ~/Library/Application Support/screpdb on macOS, $XDG_CONFIG_HOME/screpdb on Linux) that holds settings, the Battle.net and game-asset caches, logs, crash reports, and extracted sample replays; and the configured replays folder (read replays, write "watch me" replays). A narrow, read-only exception walks up from the replays folder to find StarCraft's CSettings.json.
• Windows OS sandbox — on Windows the app splits into a Medium-integrity launcher and a Low-integrity worker (#237). The launcher marks the app-data directory Low-writable and relaunches the real worker at Low integrity; the worker keeps read-down access to replays anywhere but can only write into that one Low-labeled folder — every other write is refused by the OS, even from a compromised screp/scmapanalyzer parser. The launcher retains self-update (it must overwrite the install .exe) and brokers the single "watch me" write into the read-only replays folder on the worker's behalf. This does not stop a compromised parser from reading private files (Low integrity can read up-level); blocking reads needs AppContainer + a broker process, a deferred "Tier 2" follow-up.
• Network — the dashboard server binds to localhost only. The binary's outbound calls are confined to three sanctioned packages: internal/selfupdate (#212) queries GitHub Releases for self-update, verifying every byte against a minisign-signed SHA256SUMS (embedded public key) before any swap; internal/bnetfacade (#317) talks to SC:R's local web-api bridge (loopback only, path-prefixed to /web-api/) and downloads replays from storage.googleapis.com (allowlisted to the single path prefix /starcraft-user-uploads-prod/S1-replays/, with length + seRS magic-byte validation on every download); internal/netfacade houses localhost readiness probes.
• Self-update — updates are always user-initiated, never automatic. Package-manager installs (Scoop on Windows, Homebrew/Linuxbrew on macOS/Linux) and non-writable install directories are detected and excluded so the updater never fights scoop update / brew upgrade or needs elevation; those installs are pointed back at their package manager. The curl | sh installer drops into a writable dir (~/.local/bin), so in-app self-update keeps working there. Self-written binaries carry no macOS quarantine xattr / Windows Mark-of-the-Web, so Gatekeeper/SmartScreen don't re-prompt after an update.
• Enforcement — TestNoDirectIOOutsideFacades (in internal/iofacade) parses the whole module on every go test run and fails the build if any package reaches the filesystem or network directly instead of through the facades. internal/selfupdate, internal/bnetfacade, and internal/winsandbox (the Windows process-spawn / integrity-labeling / broker surface) are the documented exceptions.

On macOS and Linux this is a best-effort, in-process guard, not an OS sandbox: paths handed to trusted dependencies (the screp parser, scmapanalyzer) are opened inside those libraries, and the facade only constrains screpdb's own code. On Windows the Low-integrity worker adds a real OS write boundary on top of the same facades.

I/O Safety Audit

The LLM that authors each change records a dated, one-line verdict on whether it could weaken the I/O rules above (see AGENTS.md); TestIOSafetyAuditPresent fails CI if the log is empty, and the enforcement test above stays the authoritative guard.

2026-09-20  OK. The WASM demo now writes its baked Battle.net data straight into the v2 store (<root>/bnet/profiles.v2.jsonl and games.v2.jsonl) instead of the pre-v2 per-payload tree it relied on the upgrade migration to convert, which drops 6.7 MB from the binary every visitor downloads. Same in-memory sandbox root, same iofacade calls, fewer of them. The new scripts/generate-demo-bnet is a build-time tool: it reads a local app-data root only when explicitly pointed at one and writes only into the repo checkout. No new roots, hosts, endpoints or facade exemptions, no enforcement-test weakening, and no DetectorVersion bump.

Older I/O safety audit entries (click to expand, five most recent)

2026-09-20  OK. Pure serialisation and rendering change for issue #333: API-derived Battle.net stats become pointers so a real zero is distinguishable from an unfetched value, ProfilesByToons stops filtering out miss rows it already held, and the fingerprint match carries the reason it is absent. No new reads or writes, no new roots, hosts, endpoints or facade exemptions, no enforcement-test weakening, and no DetectorVersion bump: nothing here changes APM, cadence or viewport aggregates.
2026-09-20  OK. Crash reports now write to <app-data>/crash/ instead of the app-data root, and pruneOldReports caps the subdirectory at 10 files after each write. appdata.Dir refuses to resolve the real per-OS root when testing.Testing() returns true unless SCREPDB_APPDATA_DIR is set, preventing any test from silently writing into the developer's real app-data directory. All writes stay inside the already-registered app-data root via iofacade; no new reads, roots, hosts, endpoints, facade exemptions, enforcement-test weakening, or DetectorVersion bump.
2026-09-19  OK. Closed the hole that left the complete-replay download declaring victory over a file rather than a result. fetchAndPlace's "complete copy already on disk" branch returned EnrichDone without ever asking whether that copy names a winner, which is the path most such games took; it now runs the same check, records the on-disk copy's md5 in the tried set, and continues to the next candidate. A one-shot startup pass reopens entries an older run closed by that exact reason (4 in the local queue, 1 genuinely unresolved), mirroring the existing schedule amnesty and bounded at 20 per process so a long history cannot become a startup sweep; entries that honestly exhausted their candidates say so and are left alone. The resolves-winner test reads the library's existing verdict via Snapshot.ByPath instead of re-parsing the replay, so the repair costs a stat and a map lookup rather than a full parse per entry, and returns the same answer the UI shows. Bridge spend is unchanged and still gated: every poll passes allowCall, so the 40-call daily ceiling bounds the retries, and the candidate list from one gameinfo response bounds them structurally. No new reads, roots, hosts, endpoints, facade exemptions, enforcement-test weakening, or DetectorVersion bump.
2026-09-19  OK. Three closures on game results. (1) Games against the computer are now their own state, models.OutcomeNotScored, decided before any rule runs: 285 of 2,898 corpus games, previously filed as "unknown" and inflating that bucket with games the default filter already hides. They are skipped by the player aggregates rather than counted as undecided. (2) The Battle.net complete-replay download stops measuring success as "a bigger file landed" and measures it as "the game now has a winner": internal/dashboard/bnet_enrich.go re-parses each placed copy and, if it still names nobody, records that md5 in the entry's tried list and takes the next-largest candidate on the following cycle. Termination is structural, not goal-based - the candidate URLs come from one gameinfo response, so the list is finite and each is fetched at most once, after which the entry goes terminal whether or not a winner was found. No extra bridge calls; the added work is free unauthenticated GCS HEADs and one GET per retry. (3) A saver's concession is downgraded to unknown when the last opponent still in the game had produced nothing for 45s or more: measured over 713 concessions, the liveliest remaining opponent had produced within 10s in 89% and within 45s in 99.3%, so past that the "opponent" was almost certainly a corpse and asserting a loss is worse than admitting ignorance. Affects 5 games. SPECIFICATION.md regenerated with all three, each Verify asserting the live constants. No new reads, roots, hosts, endpoints, facade exemptions, enforcement-test weakening, or DetectorVersion bump.
2026-09-16  OK. Folded the allied-collapse special case into the survivor rule it duplicated. The previous commit added a step that credited a single remaining coalition outright; it turned out to be reachable only because the "fewer than two coalitions" guard would otherwise reject it, and in every case it fired the ordinary "sole coalition still holding a player who never left" rule reaches the same answer. The guard now simply exempts alliance-derived groups, so the procedure loses a step. No behaviour change: a single allied coalition with a survivor is credited by the survivor rule, and one with none by the saver or last-leaver fallback, which name the same group. Also measured what the remaining guard actually rejects: 228 of 2,898 corpus games, every one of them humans against computers, since computer slots are excluded from the count and leave the humans as the only side. SPECIFICATION.md regenerated. No new reads, roots, hosts, endpoints, facade exemptions, enforcement-test weakening, or DetectorVersion bump.

License, Contributing & Acknowledgements

• This project is licensed under the MIT License. See the LICENSE file for details.
• Due to security safeguards I can no longer accept PRs or other code contributions, but please feel free to file an Issue, and you're more than welcome to contribute non-code improvements.
• Built using the github.com/icza/screp library for StarCraft replay parsing. This project would have been impossible without András Belicza's work.
• Country flags on platforms that lack them (Windows) are drawn with the Twemoji Country Flags font, whose artwork comes from Twemoji and is used under CC BY 4.0.