The only awkward part now is that chessground doesn't have a promotion UI by default when you move a pawn to the last rank, so we need to add that. Right now it just assumes auto-queen but that's especially dopy since it doesn't actually even queen lol and you just get left with a pawn on the back rank.

Here's one that reproduces it: http://localhost:3030/tactics/single/yxW8g

Currently your rating starts at 1000 and increases by 1 for each puzzle completion. This is an extremely simple scheme which doesn't really reflect whether your tactics skill is improving or not, as it ignores the difficulty of puzzles you're completing, and in theory just reviewing puzzles daily for long enough will result in a higher rating without seeing any new/harder puzzles.

Additionally from testing it just increases too fast also. After 1000 reviews you'd be at 2000 rating and seeing much harder puzzles, even though you may only have seen a few hundred unique puzzles at that point and they might all be fairly easy ones.

It might be worth treating each puzzle completion as a 'game' against an opponent of the puzzle's rating, and calculating a glicko2 rating for the player over a certain period https://en.wikipedia.org/wiki/Glicko_rating_system - that's probably what lichess is doing anyway.

The goal would be that the difficulty increases steadily over time, but repeated repetitions of the same puzzles don't increase the player's rating artificially. Additionally, using a rating system like glicko2 would probably be good for calibrating initial rating levels, and we could implement a 'calibration' mode where each puzzle done counts towards your rating but doesn't necessarily add the puzzle to your review queue (unless you get it correct the first time.) New puzzles could then also be shown in the rating range according to your Glicko rating's uncertainty instead of the current arbitrary +-5%.

The proof of concept is working really well now, the next things to do aren't really needed as much, but might be nice to do.

1. ~~Switch database over to a dbal (like diesel) to simplify the database code, support migrations, support different backends other than sqlite etc~~ Done, but used sqlx instead of diesel, because I don't like ORMs tbh.
2. ~~Add a config file for e.g. the bind address and port, and any other global options~~
3. Add a settings page for any user settings e.g. the % range for new puzzles to show seems a bit arbitrary to be hard-coded
4. ~~Reimport lichess puzzle db with all the fields (I was being lazy originally) and then we can use the puzzle's rating deviation in the rating calculation (another thing that's hardcoded with all puzzles having a rating deviation of 50, whereas newer puzzles might actually have quite a high deviation and be inaccurately rated as a result)~~
5. Add an account system so that this thing could have a hosted version (and maybe we could also support OAuth with lichess as an option)
6. Add e.g. graphs for a user's rating, and maybe utilise the puzzle themes from lichess's full database to have graphs for each rating. We already store all of the user's past reviews in the database, so this could be calculated as needed (or in batches), rather than having to store all of a user's previous data points.
7. The main page could have these graphs and info as extra panels instead of just one tiny panel in the middle for stats.
8. Add the ability for the 'random puzzles' page to show you puzzles by theme instead of just any puzzles.
9. ~~Perhaps the standalone version could embed a browser like servo, and then it would just start like a desktop app. It could still be possible to run the 'server version' with sqlite and in local-user-only-mode anyway.~~ The feature/embedded-browser branch does this as a prototype and it was pretty easy but it needs some extra UX refinement before we actually do it for sure.
10. Add versioning to the asset URLs so we don't have any problems with browsers caching old versions of them.
11. It could remember the puzzle you were looking at previously when showing you a random puzzle, and it could provide a 'skip' button for cards.
12. Technically the 'random puzzle' page could show you a puzzle you've already reviewed before and make you review it ahead of time. It's not a deal breaker but it is weird behavior we should try to make less likely (like maybe we try to get 3 puzzles and then give up and just return the one we have, it's probably best to have that as a fallback anyway in case the pool of puzzles we're choosing from is so shallow that it's likely to happen more than once or every time).
13. Left/right buttons on the puzzle interface so you can look over the moves that have already been made, and what move the computer just made initially. The right button should be greyed out by default and enabled when you're looking at an old move so you know, and the pieces shouldn't be movable while you aren't at the latest move.
14. ~~An about page with information about what it is, how to use it, and to credit our dependencies/provide license info.~~

A bit of general cleanup leading to the ability to run a hosted version seems like a nice way to go, but we should maintain the ability for it to be run as a standalone app too.