There is no such thing as a loose todo
Most todo apps quietly allow a task to belong to nothing at all. We removed that state, and it turned out to settle a surprising number of other arguments.
Open almost any todo app and move a task out of its list. Where does it go?
In a lot of them, the honest answer is nowhere in particular. It still exists. It is still yours. But it now belongs to nothing, and the only way to see it again is to remember it exists and go looking. Apps handle this differently and most handle it reasonably, but the state itself — a task that belongs to nothing — is almost always allowed to exist.
memoratu does not have that state. Not as a rule enforced on top, but as something the system cannot express.
The floor
There is a list called Inbox. It is created with your account and it cannot be deleted, renamed, archived or moved into a project. It is not a folder you happen to have. It is the floor.
When you add a todo with no ceremony — no project, no list, no decision about where it should live — it lands in Inbox. That is the common case and it is the one that has to be fast.
The part that matters more is what happens at the other end. If you take a todo out of its last parent — remove it from the list it was in, or archive the project around it — it does not become unparented. It moves to Inbox. Clearing the last thing that held it is not an operation that leaves it floating; it is an operation that returns it to the floor.
So "a todo that belongs to nothing" is not a state you have to handle carefully. It is a state that does not occur.
Why this is more than tidiness
It would be easy to read this as housekeeping. It is not, and the reason is that every other part of the system gets simpler when a thing cannot be nowhere.
Consider what has to be answered otherwise. If a todo can belong to nothing, then every screen that lists todos needs a policy: does it show the orphans? Every count needs a policy: does an orphan count against your plan? Every sync needs a policy: if one device thinks a todo is in a list and another thinks it is nowhere, which is right? Every export needs a policy. Every search needs a policy.
None of those policies is hard on its own. The problem is that there are a dozen of them, they are written at different times by different people, and they only have to disagree once to produce a todo that is visible in one place and invisible in another. That is the kind of defect you do not find by testing, because nobody writes a test for a state they did not realise was reachable.
Removing the state removes all dozen questions at once. There is no orphan case to decide, because there are no orphans.
It costs you nothing
A fair objection: if Inbox is a permanent list, does it eat into what my plan allows?
No. Inbox sits outside every project and does not count against your project limit or your lists-per-project limit. On the free plan, which allows a single project, that project is entirely yours — Inbox is not quietly occupying it.
The per-list ceiling does still apply to Inbox itself, the same as any other list. It is a real list with real limits; it just is not one you paid for or can lose.
What it feels like
Mostly, it feels like nothing, which is the point. You type a thing, it is in your Inbox, done. You never set up a destination. You never make a filing decision at the moment you are trying to get a thought out of your head, which is the worst possible moment to ask anyone to make one.
And later, when you do want structure — when a list of todos has quietly become a project — you can build it, and nothing you captured earlier is stranded by the change. It came from the floor and it can always go back to it.
The design rule underneath all of it is one sentence: make the bad state unrepresentable rather than handling it everywhere. That is not a new idea and we did not invent it. It is just unusually easy to see the value of, in a product whose entire job is to not lose the things you asked it to remember.