Turn the three-service surprise into a rollout map

Before writing much code, spend twenty minutes drawing the change as four lanes: the three services and the database. Mark which versions can coexist, which component owns the backfill, and the exact observation that makes each old path safe to remove. The useful design question is not merely “what must change?” but “what is the smallest independently deployable expand, migrate, and contract sequence?” This should expose whether the data migration is genuinely required up front or can run after compatible readers and writers are live.

A practical deliverable for Monday would be a one-page rollout note containing the order of deployments, rollback point for each stage, and two or three production checks. If any stage cannot be reversed, flag that explicitly rather than letting it hide inside the migration.

• Parallel Change — Martin Fowler
• Evolutionary Database Design — Martin Fowler
• Expand and contract pattern — AWS Prescriptive Guidance

Make SQLite configuration a connection invariant

The discovery that most pragmas are session-scoped suggests a small reusable experiment: open two fresh connections to a temporary database, inspect foreign_keys, busy_timeout, and journal_mode on each, then repeat through the application’s real connection pool. Turn the result into a startup assertion or connection-initialisation hook. That converts a documentation surprise into an executable guarantee, and it will catch the particularly awkward case where the first connection is configured correctly but later pooled connections are not.

It may also be worth writing a compact “SQLite production profile” beside the code: which settings are persistent, which are per connection, and who applies them. The sharper follow-up question is whether your driver offers a reliable per-connection hook—or whether settings belong in the connection string instead.

• SQLite PRAGMA reference
• Write-Ahead Logging
• Go database/sql connection pools

Build a tiny open-protocol litmus test

Your distinction between visible source and an independently implementable protocol is a good basis for a small conformance probe. Pick one narrow interaction—WebFinger discovery is ideal—and implement the client side solely from the published specifications, against two unrelated servers. Record every place where the spec is insufficient and implementation folklore is required. That produces a more useful measure of openness than a licence badge: can an unaffiliated implementer interoperate without privileged guidance?

This could grow into a short checklist for evaluating protocols: stable specification, royalty-free implementation terms, discoverable test vectors, multiple independent implementations, and a working path for reporting ambiguities. A local WebFinger endpoint for lmika.org would also make a pleasantly concrete weekend-sized test bed if you want to take it beyond the paper exercise.

• WebFinger — RFC 7033
• ActivityPub — W3C Recommendation
• ActivityPub and WebFinger — W3C SocialCG