- Deployment
    - automated changelog publishing
    - ci check golangci-lint docs
    - ~fix owner and perms and check on .env file for install~
    - ~PKGBUILD~
    - ~ci testing, lint, gosec, vulncheck~
    - ~graceful shutdown~
    - ~cd build binary, package~
- More complete sync(refresh packages on schedule with db, prefetch updates to pkgs we already have)
- clean cache of old files
- Add chi for mux
- Build server/tool
- Think about: arch doesn't like partial upgrades, round robin fetching the db files might be an issue
- ~implement streaming~
    - ~implementation~
    - ~refactor cache tests to match new interface using testify~
- ~Complete testing~
- ~Add better logging for errors, filename more deatail~
    - ~package main~
    - ~internal/cache~
    - ~api endpoint to change level~
- ~retry on failed fetch~
- ~Solve timeout issue large pkgs~
- ~Move project to github as primary~
- ~add a UA to get client, some servers are 403 the default go client~
- ~Basic config Testing~
- ~flag for loading non default config~
- ~add cli option for config location~
- ~Deployment(systemd, systemd.timer)~
- ~Basic testing for internal/cache~
- ~basic file server that fulfills pacman api~
- ~fetch requested files from mirror~
- ~DB sync from mirror~
- ~Config file and import~

Looking at what you've built and what's left on your TODO, here's how I'd think about the "done" line for a capstone:

**What you already have that's impressive:**
- Real concurrent systems work — singleflight, atomic ops, mutex
- Custom HTTP transport with timeout tuning
- Atomic file writes with the tmp-then-rename pattern
- Meaningful test suite with httptest, not just trivial unit tests
- Clean dependency injection, thoughtful package boundaries
- Config validation with proper error wrapping

**What would make it a complete capstone story:**
- The streaming solution for large packages — this is your most interesting unsolved technical problem and directly demonstrates you understand the HTTP layer
- At least one more meaningful feature working end-to-end, either the refresh scheduling via systemd timer or the prefetch-on-refresh logic
- Actually deployed and serving your home network — "running in production" is a strong closer

**What I'd leave out of the capstone scope:**
- The AUR builder — that's a whole second project honestly
- Chi middleware — nice but not substantive enough to matter

The through-line you want to be able to tell is: *I built a caching reverse proxy from scratch in Go, handling concurrency, filesystem atomicity, and HTTP semantics correctly, and deployed it on real hardware.* You're close to being able to say that. The streaming piece and a working deployment are the remaining gaps.

How far out is the capstone deadline?