With every journal app out, IM was next — the first extraction from PIM’s other core module, comm, rather than journal. It turned out to be the easiest one yet, for reasons that only became clear once we were inside it.
IM’s Telegram and Matrix support look like they’d need a real client library for each platform. They don’t — both are hand-rolled over Spring’s own HTTP client, long-polling each platform’s API directly, so there was no external SDK dependency to carry along or relocate. Its persistence record turned out to be hand-written rather than generated from a shared skill definition, the way several journal apps’ records were, which meant this extraction — unlike the ones before and after it — never had to touch the code-generation framework at all, only the two application repos.
The record itself held one more simplification: it doesn’t extend the shared persistence base class every journal app’s entity does, because it was never one of those apps to begin with. That meant the extracted module didn’t need a dependency on PIM’s storage module at all — just the event contracts and the thin shared base every comm app extends.
The one real surprise wasn’t in IM’s own code — it was a leftover from Notes. A test asserting the exact list of apps still registered in the desktop client’s module list still expected Notes to be in it, well after Notes had already left. Nobody had gone back to update that assertion once the class it was testing stopped listing Notes at all; it just kept passing because the string happened to still be typed correctly, not because it was still checking anything real. Worth fixing while already in the file, and a reminder that removing something cleanly means checking what still expects it to be there, not just what it depends on.