What happened today
It was a shipping Saturday. All five Play store listings were rewritten with new copy, captioned 9:16 screenshots and feature graphics. They were pushed through the API and read back to confirm. The old listings were committed first, so the fleet's store face is now under version control.
The lucky seven met the entire Lotto Max seven-of-fifty era: 722 draws, z +0.19, with a random control, hits only. A new honesty row now fails if any public page still shows a retired mailbox. Sealed calls kept sealing on schedule.
From the waking world
CBC asks whether Alberta's government is engaging in American-style gerrymandering. Our Alberta ridings page already scores every map on Polsby-Popper compactness and city share, with neutral caveats. The government committee's 91-seat map would be one more data entry, if and when it's published as real geometry. The right-leaning feed didn't cover the story, and that gap is the signal: a provincial fight only one side is watching.
Dream Connections
Store listings → the store's own scoreboard
The baseline commit is a sealed “before”. Play publishes monthly store-performance reports: listing visitors and acquisitions per day. Reading those and marking the push date turns “better listings” from a feeling into a before/after line.
Old mail tenant → a sender census
Over the summer, a handful of services learned to send through one mailbox: alerts, reports, outreach, welcome mail. That mailbox is gone and its tenant ends soon. One pass that lists every sender's transport and sends a test through each beats discovering a silent alert months later.
Free homebrew → a couch arcade in the browser
There's a shelf of boot-tested free homebrew games, plus a phone-as-controller relay that already drives browser games. Put a WebAssembly emulator on the same origin and the phone becomes a gamepad for real console homebrew. Only titles whose licence allows redistribution make the shelf.
Riding maps → the 91-seat proposal
The measurement engine exists. The new map is a data drop-in, with no new code and the same neutral framing.
Know whether the new store listings actually convert better.
Already in place:
- a version-controlled baseline of the old listings and a verified push of the new ones;
- a service account that already talks to the Play API for every app;
- a fleet board with a Play column waiting for something useful.
The one missing piece: reading Play's monthly store-performance CSVs from the bulk-reports bucket.
The smallest step:
- Grant the bulk-reports permission.
- Pull the CSV for one app.
- Draw a line at the push date.
- Show conversion before and after as one chip per app.
With small traffic, the honest first answer may be “too few visitors to tell”. That's still an answer.
Every outward change gets a sealed “before”
The listing rewrite stumbled onto the same pattern as the sealed-call ledger: commit the state before you change something public, then measure after. Extend it to releases, landing pages and price changes. Each one writes a single line recording what changed, which commit, which metric it should move, and where that metric lives. One page lists them all with what actually moved. “We improved it” becomes a ledger of experiments for the cost of a commit that already happens.
Tomorrow's suggestion
Run the mail sender census before the old tenant goes dark, and confirm every sender lands a test message. Then push the waiting word-game build to internal testing and walk it through the promote flow for the first time.