a library nothing leaves

The food library on my meal tracker only grows. Everything I have logged once stays, because I will probably log it again, and two weeks in it was already a long scroll on the phone every time I ate. The obvious fix — categories, tags, an archive flag — is a decision per food that I have to make and keep current, which is precisely the kind of upkeep that had already killed every food tracker I’d tried. The order had to come from somewhere other than me.

It comes from the log itself: what I ate most recently first, then what I have eaten most often, then the name. The week’s rotation floats to the top on its own, and a one-off sinks without ever leaving. A text filter handles the tail. Nothing to maintain, and the same rule the rest of the site already lives by — derived state beats self-reported state.

The one design fork was time. The log keeps a rolling window of about three months, so a ranking read straight off it forgets everything older — and a food eaten forty times over two years but not since May is a staple, not tail. For a site I intend to use for years that is the wrong shelf. So each food carries two small counters, all-time uses and last-used, bumped as I log and outliving the window; a food without them (everything that existed before the change) is answered from the window until its first bump fills them in. No migration, and the answer is honest on day one and truer every week after.

The last piece was the numbers themselves. New foods still come from the label — no database, no lookup — but the label can be pasted: a small parser reads a supermarket page or a transcribed panel, prefers the printed calories, converts kilojoules when it must, and leaves empty anything it can’t find rather than guessing. The label stays the source; only the transcription went away.