Throwing some thoughts out there in no particular order:

Simple (or even fuzzy) question/answer checking should be relatively easy. We could borrow a pattern we use in other areas wherein there is a "Manager" role who has RW privs to puzzles. Users could submit their answers and have their results logged somewhere where they, the manager, or everyone could view them (leaderboard?). I did a quick test of the myus puzzle thing and it's pretty barebones, so I think we could adopt some of that pretty easily. Advantage to building within Twitarr is that users can use one account rather than needing to establish separate credentials.

I agree that "virtual Passporto stamps" is somewhat dubious. The fun is in the physical hunting and stamping. Though I think having a well-published list of stamps (maybe "official" plus "shadow" stamps for people who brought their own?) could be beneficial. If someone brought a stamp they could add it and the location to the list of stamps. I haven't done Passporto so idk if this is within the spirit of the quest.

We can seed the database at bootstrap time (usually early morning embarkation or in early February when the server ships) with a set of questions. Having a JSON blob would be best. If we establish a manager role as described above, questions could be CRUD'd at any time during the sailing. Or even on embarkation day once they board.

Is your idea that a single manager would have permission to edit all hunts, or anybody could create a hunt and they would be manager of that hunt?

Initially I was envisioning a single manager (or a group of managers) for all hunts. Thinking about it more I suppose there is little reason to limit that to specific users. That way any user could create a hunt. If we got fancy they could even delegate administrative rights to hunts they create.

One other random implementation thought - Hunts must be Reportable.

Is there currently any other Reportable that can be edited by someone other than the creator or a moderator? Would you expect I'd have to modify guardCanModifyContent to support that?

I do not believe we have any instances of that case today. guardCanModifyContent in User+Extensions.swift and UserCache.swift could be extended to include an optional array of extra authors that get checked. Or maybe the functions could be overloaded? Regardless I believe the answer is yes it would need modified.

Feels like that might be a thing I should pull out to a smaller PR to have the answer checker PR end up more focused. Had another thought about it: say I create a hunt, then give people permission to edit it, and one of them does, then the hunt gets reported. If the model doesn't contain the history, the moderator won't know who should get suspended.

That's a great point. We keep edit history for most Reportables (such as

Would it be more useful to you if I did this incrementally as a draft PR? I started out heading for a monolithic commit and have been bogged down, so if I tease it apart into incremental changes I can probably get to an MVP sooner. That also means I'd get feedback a little faster.

My initial plan was to have an edit experience, but to test the solver experience without the edit experience I'd probably want to support seeding anyways. That would give me the option of seeded only if I don't finish the edit experience in time.

Our last round of playtesting is scheduled for early February so we might miss the shipping deadline if we did it that way depending on if there are any last-minute changes, but if it could be emailed to someone and loaded on the boat then that deadline wouldn't be a problem.

Fully acknowledging that I have done mega PRs here in the past, I do suggest smaller more incremental stuff. Way easier to review and give feedback along the way.

Seeding would certainly remove the amount of edit logic endpoints you'd need to write. We already have well paved paths for "shove JSON in path or in browser and click button" (schedule, time zones, board games are a couple examples). We usually have a pile of seed files to load during setup the morning of embarkation day. Adding one more would be trivial.

Since this is net-new functionality and I doubt I (Tricordarr) or Chall (Kraken) will have app support in time anyway, you probably dont have to worry about the code frost too much. That timeline may be moved up anyway due to the impending user pre-registration (spoiler alert?) capability. Biggest thing that I see impacting you is any third-party dependencies. Those have to get locked before ship so that we can do builds on boat.