The terminal came first
The first thing that could create a todo in memoratu was not an app. It was a command line — and that was a decision about architecture, not taste.
The first client that could create a todo in memoratu was not an iPhone app or a web page. It was a command called mu, typed into a terminal.
That ordering was deliberate, and the reasons are less sentimental than they sound.
A terminal is an honest client
A graphical app can hide a surprising amount of product behind itself. Validation that only runs in the form. A rule that is really just a disabled button. A limit that is enforced by the fact that the screen does not offer the option. All of that can look like a working system right up until a second client appears and does none of it.
A command-line client has nowhere to hide. It is a plain HTTP client — it talks to the API over HTTPS and it touches nothing else, no database, no storage, no privileged back door. If a rule is not on the server, mu will cheerfully break it, loudly, the first time you try.
So building it first was a way of forcing an answer to a question that is easy to defer: where do the rules actually live? In memoratu the answer is the server, every time. Clients hold no business rules. The limit on how many todos a list can hold is checked on the server; so is what happens when you move a todo into a list that is already full; so is what a plan allows. A client that forgot to check would simply be told no.
That is not a slogan. It is the only arrangement that survives five different clients written at different times by different people.
The agent case, which is the real one
There is a second reason, and it is the one that actually drove the decision.
A todo system that can only be driven by a human tapping a screen is a todo system that an automated process cannot use. And a growing amount of real work is done by something that lives in a terminal — a script, a scheduled job, an AI agent working through a task list.
For any of those to participate, two things have to be true. There has to be a way to authenticate that is not "open a browser and type a password", and there has to be an interface that is text in and text out. A personal access token and a command line are exactly those two things.
So mu add "call the client back" is not a nostalgia feature. It is the proof that anything able to make an authenticated HTTPS request can create a todo and tick it off — which is a different and more useful claim than "there is a CLI".
What that forced us to get right early
Designing for a terminal first surfaced things that a GUI would have let us put off.
Every record needs a name you can say out loud. Tapping a row is a perfectly good way to identify a todo when you can see it. In a terminal you need to be able to refer to one unambiguously, in a script, a week later. So every record carries a readable identifier of the form mem:todo:<account>:<id> — one string that names exactly one thing.
Credentials have to be storable safely. mu keeps its token in the macOS Keychain rather than a dotfile, and signing in does not print the secret, because it has already stored it. A password is always prompted and never accepted as a flag, so it never lands in shell history. None of that is interesting in a GUI, where the platform handles it. In a terminal it is the whole problem.
Signing in again has to be predictable. Running mu auth login a second time on the same profile revokes the token it is replacing, and only that one — a token on another machine, or under another profile, lives in its own slot and is untouched. That rule had to be decided before anyone could reason about it, not discovered later.
Where this actually stands
Honesty, since everything above is written in the present tense.
mu is real, it works against the live API today, and on a Mac you can install it right now:
brew install subbutgs/memoratu/muThat is a public tap, and the v0.1.0 release carries binaries for macOS on both architectures and for Linux on both, with published checksums.
Two things it is not. It is not signed and not notarised — Homebrew does not need either, because it fetches over curl and nothing attaches a quarantine attribute, so the install is clean. That is a property of how brew works, though, not a claim that this binary has been through Apple's process. And the source is not public, so building it yourself is not an option.
It is also a paid-plan feature. Minting a CLI token on the free plan is refused, deliberately — and since there is no billing yet, that limit is real rather than theoretical.
So the terminal came first in the order things were built, and it has turned out to be the first thing you can actually install as well. The apps are what most people will use, and they are what is being built now. But they will be arriving at a system that was already being driven by something that could not take any shortcuts — and that is worth more than the time it cost.