The Add Contact dialog prompted a question about the output area itself: why wasn’t the form just part of the shared display? The real answer split cleanly along blocking versus non-blocking, not text versus rich content — a task that needs focused user input to complete, a form or several required fields at once, is a dialog; everything else, whatever it is, belongs in the output area alongside narration and AI replies. That’s now written down in PIM’s architecture rules instead of living only in one conversation.

Calendar’s day/month view was the first real content built under that rule, and it needed almost no new plumbing. The output area was already rendering raw, unescaped HTML into a WebView, no markdown conversion and no sanitization — narration text just happens to be short plain sentences today. A calendar view is an HTML string built the same way, sent through the exact pipeline every other message already uses.

We chose plain HTML and CSS for it over a native JavaFX widget, on purpose, even expecting JavaFX would look more polished out of the box. PIM’s GUI is expected to eventually exist as a web frontend too, and HTML built server-side is directly reusable there; a native widget would have to be built twice. The visual gap closes with CSS, and later JS if it’s ever worth it — not by going back to native controls.

Building it also surfaced a bug that had nothing to do with Calendar. Any “/"-prefixed input was being intercepted as an operational command before it could reach the path /show’s own regex depended on, so /show had never actually worked from the app — not for Calendar, and not for Author, Diary, or Plan, who’d already written /show handling nobody had noticed was unreachable. Fixing the routing for Calendar fixed it for all four at once.

The design also settled where a shared visualization would live if a second pimi ever needed the same one — a Gantt chart usable by both Project and Worklog, say. The part that turns domain data into a generic shape stays with whichever pimi owns it; the generic renderer that draws the chart doesn’t know about appointments or tasks, and doesn’t belong duplicated in each pimi either. It would move into whichever shared module those pimis already depend on, the same way journal’s shared event-service base already works — once a second real consumer needs it, not in anticipation of one.