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-13  OK. Players-list facets and session stat tiles. Three new players-list filters (race, APM band, games-played band) are computed by the same in-memory pass over player aggregates that already served the name and last-played filters (internal/dashboard/db/libstore_player_facets.go), with facet counts taken with each facet's own filter cleared so the bar never dead-ends; they are declared in api/openapi/dashboard.v1.yaml, regenerated, and added to the MCP read-only surface's param list. The redundant boolean 5+ games axis is retired from the UI while only_5_plus stays accepted by the API. Session tiles gain per-race APM and an undecided count, both derived from data already in the response, and the win rate's denominator becomes every game of the sitting. No new reads, roots, hosts, endpoints, facade exemptions, enforcement-test weakening, or DetectorVersion bump.

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

2026-09-13  OK. Regulars freshness is now dated by its own observation. internal/dashboard/session_regulars.go reads BnetProfile.FetchedAt (already in the distilled profile store, no new read) alongside the archived game times, and regularFreshness takes that observation age as a second axis: the live tier needs an answer newer than regularsObservationWindow, and past regularsObservationMaxAge (two sweeps, not two days) the row is dropped rather than asserted, because a stale look omits everyone who started playing since and so yields a biased list rather than merely an old one. Keying off when Battle.net last answered, never off bridge connection state, means a brief disconnect changes nothing and a long silence degrades smoothly. A failed sweep leaves FetchedAt untouched, so it correctly never counts as an observation. No change to polling volume (same 30-minute sweep, same paced facade), and no new roots, hosts, endpoints, facade exemptions, enforcement-test weakening, or DetectorVersion bump.
2026-09-13  OK. Session players table: P/W/L split, sortable columns, identity badge column. Frontend-only except one field: gamingSessionPlayer now carries PrimaryBadge, filled by the existing in-memory d.primaryIdentityBadge resolver (memoised fingerprint match plus the embedded scfingerprint registry), the same call the games and players list endpoints already make. Sorting is client side over the rows already sent. No reads, writes, roots, hosts, endpoints, facade exemptions, enforcement-test weakening, or DetectorVersion bump.
2026-09-12  OK. Session regulars and their Battle.net freshness. The ranked, account-merged co-player list is computed from the in-memory library (new LibStore.ListCoPlayerCounts, one pass over the same snapshot every other list endpoint reads) and annotated from data already on disk: the distilled profile store for account identity and the game archive for each account's newest published game. The only new outbound work is a freshness sweep that refetches at most regularsMax profiles, at most once every 30 minutes, through the existing rate-limited bnetfacade bridge client at PriorityBackground, on the exact (toon, gateway) pairs already cached, so it opens no new host, path or gateway-guessing behaviour and is paced by the same token bucket as every other bridge call. The goroutine is crashreport.GuardNonFatal-guarded per the panic architecture. Time-in-game now sums the user's own leave stamps rather than replay length, which is a correctness fix, not I/O. No new roots, hosts, endpoints, facade exemptions, enforcement-test weakening, or DetectorVersion bump.
2026-09-12  OK. Last Gaming Session (#402). Pure logic split inside internal/dashboard/endpoint_gaming_session.go: gamingSessionWindow drops its recency early-return so it only reports the bounds of the most recent sitting, and two new pure predicates (gamingSessionIsLive, gamingSessionIsRecentEnough) decide liveness and a 90-day outer bound; the response gains has_session alongside active, and the nav entry and panel gate on it. The candidate scan is byte-for-byte the same call (ListRecentAutosaveGamesForPlayers over the in-memory library, same 300-row cap, same autosaveOnly path filter), so no new reads, roots, hosts, endpoints, facade exemptions, enforcement-test weakening, or DetectorVersion bump.
2026-09-12  OK. Battle.net daily request cap removed. internal/bnetfacade/ratelimit.go drops bridgeDailyCap/downloadDailyCap and the two ErrBudgetExhausted refusals; the token buckets (1 per 2s, burst 12/6), the priority queues and the exponential cooldown on the server's own "Rate Limited" signal are unchanged and are now the whole of the enforcement. The day counters and their persisted file survive as reporting only, so the dashboard meter still shows requests today; the bnet status payload drops daily_cap and the tooltip drops the "/600". No new roots, hosts, endpoints, facade exemptions, enforcement-test weakening, or DetectorVersion bump: the same allowlisted loopback and GCS surfaces, reached at the same pace, with no ceiling that stopped legitimate work partway.

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.