PhoebeOS

One shell, thirty-one modules

PhoebeOS is a single application that hosts thirty-one independent feature modules across macOS, iOS, watchOS and tvOS. Calendar, bills, tasks, sleep, nutrition, hydration, medication, media, notes, mood — each one is a separate module registered with a host, not a screen wired into a monolith.

The reason is boring and it's the whole point: every part of a life already lives in a different app with a different data model, and none of them agree. Putting them behind one assistant and one schema is the only way a question like "how did I sleep the week my medication changed" has an answer.

The sequencing decision

The obvious approach is to design the whole thing, then build it. I chose the opposite: structure the build into eight dependency-ordered domains — provider, persistence, context, memory, retrieval, tools, orchestration, features — and run a focused pass on each in order.

Nothing gets built on top of a foundation that doesn't exist yet. It's slower at the start and it means the interesting features come last, which is uncomfortable. It also means I have never had to tear out a layer because the thing underneath it changed shape.

The constraint that mattered most

There's a rule in the orchestration layer that everything else hangs off: the code branches on what a provider can do, never on which provider it is.

Checking capabilities instead of names is a small discipline that pays repeatedly. Adding a model means declaring what it supports. Nothing above it has to change, and there is no growing pile of special cases naming specific vendors.

The module I'd actually show you

Most of the thirty-one are conveniences. One isn't.

The clinical module exists because of a real recordkeeping problem: in any long diagnostic workup, the useful data lives between appointments and nobody captures it properly. So the module runs structured at-home testing, tracks vitals over time, and exports the result as a FHIR bundle using real LOINC codes — the interchange format a physician's own system already understands. It is the same problem as a rights registry, in a different domain: a record nobody maintains is a record nobody can rely on.

Not a PDF. Not a screenshot of a chart. A structured clinical document that goes into a record.

That module is the clearest example of what I think I'm good at: taking a messy real-world requirement, working out what the receiving system actually needs, and defining "done" as the point where it's usable by the person on the other end.

Honest status

This is in development, not finished. Signed and notarised builds are downloadable, but there is no company behind it, nothing is being sold, and it has no customers. 31 modules across four platforms — and a long way to go. I directed the build; Claude Code wrote the code.

Claude Code wrote all of that code. I decided what it was, what order it got built in, what each layer was allowed to depend on, and when a thing was actually done.