Finishing Tome & Quill for both sides of the table
The recent v1 pass connects campaign flows, checks player-facing payloads, and makes a large procedural app reproducible locally.
Most of my earlier Tome & Quill work was on the world. It generates a map, replays history, and connects places to people and events. The v1 finishing pass had to make that world usable in a campaign.
The work is merged. It includes character creation, campaign invitations, session scheduling, DM and player hubs, tactical maps, and an expanded story bible. Version 1.0 is still in release preparation; I haven't verified a published release.
Follow the campaign through
After generating a settlement, the DM still needs to prepare the world, review characters, schedule a session, and decide what to reveal. A player has a different route through the app: join the campaign, bring or build a character, find the shared information, and check the next session.
The finishing pass connects those flows. Between sessions, players have recaps and journals, with reminders and a hub for the next session. On the tactical grid, the app handles tokens, initiative, HP, conditions, line of sight, fog, and explored memory.
Each page has to know which seat you're in.
Inspect what a player receives
A DM preview shows the player's presentation. I also need to inspect what the API sends. A page can look correct while its response includes enough data to reconstruct information the player hasn't been shown, whether that's the original generation seed, private notes, or the operation log.
The v1 work removes the original world seed and operation log from player payloads and tightens access to unrevealed information. Secret doors and NPC details need player-facing representations, as does battle information, because sending the DM's full data and hiding a few elements leaves the information in the response.
Authorization tests exercise requests as an anonymous visitor, a nonmember, and a wrong owner. A successful DM walkthrough doesn't encounter any of those cases.
Make the whole app reproducible
The local stack includes PostgreSQL, demo users, a demo campaign and world, and headless sign-in. It seeds the demo through real route handlers. That means the fixture exercises the application's own rules; directly inserting rows would bypass them.
Browser fixtures cover roles in both themes and at different viewport sizes. I can revisit a failure with the same campaign and seat state, including the case where something works for the DM but fails for one particular player.
Measure the expensive surfaces
The map and its initial payload received separate performance work. Zooming updates a transform during the gesture and commits the expensive work afterward. The editor also starts with a smaller payload.
Those measurements need to stay separate. Getting to a usable editor sooner doesn't necessarily improve first paint. A budget for each makes the tradeoff visible, including a regression that would disappear inside a single overall score.
The local fixtures now let me check those changes against the same world and campaign, including both DM and player requests.