trying to implement as much of rogue run management in sql as possible complete with rls

reference the rules from the wiki for that other game

stuff that you're pretty confident doesn't need relations can live inside json and use postgres json functions to avoid migrations today

investigating with flyway how to better support development stage migrations in sql - for example, should it be in its own schema until it is promoted to production? with normal columns, work with them in spellsource_development, then when you are done with everything, make the migration happen in the spellsource schema

or use "dash dash watch"

the end goal is to generate a graphql client whose mutations correspond to the actions people will take

document how to make changes to the business logic of the rogue run