Operate
Updating
There is no automatic updater. A new release is new files; your own state lives in a few files you must keep. This page lists them and a safe order of work.
Files that are yours#
| File | What it holds | In git? |
|---|---|---|
admin/.env | ADMIN_SECRET_KEY and any admin environment settings. | No. Back it up. |
admin/data/admin.sqlite | Every admin setting, members, audit log, history, encrypted secrets. | No. Back it up with .env. |
config/public.json | Your public settings, generated by the admin. | Yes |
scanner/data/pairs.jsonl | The pair database with your review decisions. | Yes (the refresh job commits it too) |
scanner/public/board.json, crossvenue-diag.json, terminal/public/data/tape.json | The latest data. Regenerated by every refresh run. | Yes |
.github/workflows/refresh.yml | Your schedule, if you turned it on. | Yes |
Update steps#
- Stop the admin and copy
admin/.envandadmin/data/somewhere safe. - Pull your repository so you have the refresh job's latest commits.
- Bring in the new release on a branch: copy the new files over your working copy, or merge them if you track the release in git. Keep your versions of
config/public.jsonandscanner/data/pairs.jsonl; if the release changesrefresh.yml, re-apply your schedule line. - Reinstall the admin's packages:
cd admin && npm install. Keep your.envanddata/. Runnpm test. - Start the admin and open Status. If the release changed the public contract, the
publicConfigcheck turns red until the admin rewrites the file; it rewrites it on start. - Read the Changelog for anything that needs your action, commit, push and let the next refresh run confirm the data job still passes.
When the matcher version changes#
If a release changes the matcher version, every pair you already decided is flagged needs_rereview on the next run and leaves the priced set until you look at it again in the admin. Your decision is kept, not overwritten; the flag just asks for a fresh look.
When the public schema changes#
config/public.json carries schema: "mikodes-prediction-public/1". Adding a field keeps /1. Renaming or removing a field bumps it to /2, and pages that do not know the new schema ignore the file and fall back to their defaults. Deploy the pages and the new file together.