The card you can fix by hand
A dictated card always has one thing wrong, and until 12 May the only fix was to say it all again. That day every word on the card became tappable and rewritable, recipe steps could be ticked off, and the card could delete itself. Getting there meant redrawing a checkbox Android wouldn't render, and rescuing three times the last sentence the "Done" button kept swallowing.
A card you could only re-dictate
The day before, the card had learned to fill itself into declared slots: a title, badges, ingredient sections, steps. It displayed cleanly. It had one flaw nobody noticed until they used it for real: it was read-only.
And a dictated card is never quite right. "Eight hundred grams" comes out as "eight grams". A step lands in the wrong place. The prep badge says thirty minutes when the dough needs an hour with resting. These are one-second mistakes, and the only answer available was to speak again and repeat everything, hoping the second dictation wouldn't get something else wrong.
This is the kind of flaw that decides how an object actually gets used. A card you can't correct is a card you eventually stop opening, because you no longer trust what it says.
Morning: a recipe you actually cook from
The day started with the most concrete use case: cooking with the card open.
Ingredients already had checkboxes. Steps were just a numbered list. We made them tappable: touch a step and its number fades from blue to grey, its text is struck through and dimmed. The remaining steps keep their blue number, so the eye finds the next thing to do on its own. The two counters are deliberately separate: what you've taken out of the fridge and what you've already done don't mix.
One detail took more thought than it looks. A second progress bar, for steps, only appears the moment you tick the first one. Until you've started cooking, the card stays calm, with a single bar for ingredients. A card that shows two empty gauges on opening looks like a dashboard, and nobody wants a dashboard in their kitchen.
Two adjustments followed. The card now sits on a faintly off-white ground while its ingredient cards stay pure white, so the cards float instead of melting into the page. And memory received a strict instruction for its recipes: ingredients are grouped by family, meat, fish, vegetables, starches, dairy, spices, finishing touches, never as one flat list. A flat list of eighteen ingredients reads badly in a supermarket. Seven short lists read aisle by aisle.
The checkbox that didn't exist on Android
The day's first snag was visual, and it was instructive.
The ticked box was meant to show a small gradient, cyan to blue, with a white tick inside. It was drawn with a vector-graphics library, placed inside a frame that clipped anything past its rounded corners, and set on a soft shadow. On iPhone, perfect. On Android, the ticked box showed its blue halo and nothing inside: no gradient, no tick. An empty square with a shadow.
The cause is a combination well known to people who build Android apps and unknown to everyone else. On Android, a drop shadow is computed by the system from an elevation value, and that elevation doesn't get along with a frame that clips its content. The vector drawing inside was simply never rendered. Nothing crashed, nothing warned.
Rather than hunt for the combination of settings that satisfies both platforms, the box was redrawn in one piece with a graphics engine that paints straight to the screen: the rounded rectangle, the gradient and the tick stroke are drawn in a single canvas, in one native pass. The clipping frame is gone, the shadow stayed on the outer view, where Android expects it. The tick is a hand-drawn curve, three points joined by a rounded stroke, rather than a font character whose look changes from one phone to the next.
The lesson is simple: when two layers of an interface fight over the same pixel, it's better if only one of them paints it.
Tap a word to change it
Then came the editor, which is the heart of the day.
A small menu in the top-right corner of the card offers two things: edit, delete. "Edit" doesn't bring up a form. The card stays exactly as it is, except that everything that can be changed gets a faint dashed underline: the title, the original quote, the memory note, every badge, every section title, every ingredient name and its quantity, every step title, its text, its duration. You tap a word, it turns into an input field with the cursor inside. You type, you leave the field, it's saved.
Having a single active field at a time isn't only an aesthetic choice. An input field costs far more to display than plain text, especially on Android and especially when it accepts several lines. A recipe card with forty fields all live at once starts to stutter when you scroll, and the keyboard pops up the moment you brush against it. One field at a time means a card that stays a card until the precise moment you want to write in it.
Around that basic gesture, a few additions: one more badge, a cross to remove one, an extra ingredient or step in any section, a whole section removed, a brand-new list or sequence of steps at the bottom of the card. And a "Done" pill in the top-left corner to leave edit mode.
Every change goes to the server immediately. The route that until then only accepted a change of state for a memory, active, archived, muted, now also accepts its content, its metadata and its themes, under the same rule as before: you only change what belongs to you, and the server checks that itself. The deep transformation of a memory, the one that keeps its history in neural memory, still goes through conversation. This route is for touch-ups, not revisions.
Delete, finally, asks for confirmation, then erases the card for good and closes the panel. It's the only truly destructive operation of the whole day, and the only one that asks a question before acting.
The title that kept going back
The second snag was sneakier, because it looked like a failure while everything was working.
You tap the title, fix it, leave the field: the old title reappears. You close the card, reopen it: the new title is there. The change had been saved, it just refused to show up right away.
The explanation comes down to who owns the data on screen. The card kept a local copy of its content so it could display the correction without waiting for the server, and realigned itself on whatever its parent handed it every time the parent changed. But the parent redraws for a thousand reasons that have nothing to do with content, and each time it handed the card an object that was technically new with identical contents. The card took that new object for a real update and overwrote its fresh correction with the previous version. The correction only came back on reopening, once the parent had finally reloaded the real data.
The fix isn't a patch, it's a move. The local copy left the card and went up one floor, into the panel that displays it: the panel applies the correction on screen first, sends the save afterwards, and only resynchronises when you actually switch to a different memory. The card went back to being what it should always have been, a pure display of whatever it's given.
In the same pass, a slightly long quantity, "four pieces, eight hundred grams" next to an ingredient name that was slightly long too, overflowed its line and escaped the card. Name and quantity were stacked in a column instead of sitting side by side: the quantity goes under the name, and nothing sticks out anymore.
"Done" swallowed the last sentence
The third snag held out three times, and it's the most interesting of the day for anyone who builds interfaces.
The scenario: you edit a step's duration, type "forty minutes", and without leaving the field, tap "Done" straight away. The card returns to read mode. The duration shows the old value. Nothing went to the server.
What was happening: the input field saves its value at the moment it loses focus. But "Done" tears edit mode down in one go, and the field is removed from the screen before it has lost focus. The typed characters lived in a draft, and the draft disappeared with the field.
First answer: the field now watches its parent's edit signal. If it flips to "read" while the field still has focus, the field saves its draft before being removed. Second answer, belt and braces: the "Done" button starts by lowering the keyboard, which naturally makes the active field lose focus, and only then switches mode.
That was enough for the title, the badges, the ingredients. Not for the steps.
Steps had a peculiarity: in read mode, each step row is a tappable element, so it can be ticked. In edit mode, it's a plain container. Two different natures. When you switch from one to the other, the rendering system doesn't update the row, it destroys it and builds a new one. The input field inside is destroyed with it, before its watch on the edit signal has even had time to react. The first answer was right, it arrived too late.
The third answer runs at the very moment the field is destroyed: if the field had focus and its draft differs from its original value, it saves the draft with its last breath. One technical point matters here: at that instant, the state captured during the last render is no longer reliable, so the values have to be read from references kept up to date continuously. The same mechanism also covers deleting a section while you're writing in it, and any other case where the display tree changes shape around an active field.
Two crumbs to finish. A prep badge that said "thirty minutes, plus resting" was capped at twenty-eight characters and refused any more typing: the limit went up to sixty. And the server now writes a line in its log for every edit it receives, and another if the database rejects it. Next time a change "doesn't seem to have saved", one glance will tell whether the request never left or was refused on arrival. Those are two different failures, and until then they wore the same face.
What the day changed
These jobs look like interface tinkering. They hold together through one idea.
A card that memory fills in for you is only worth something if you can take it back into your own hands. Dictating is fast, and that's exactly why it leaves mistakes behind. The day fixing a mistake costs less than living with it, the card becomes something you rely on. The day a list gets ticked off step by step with hands covered in flour, it has left the phone and entered the kitchen.
The rest, the invisible checkbox, the title that stepped back, the swallowed sentence, is the cost of that promise. All three flaws had the same symptom, "my change didn't take", and three causes with nothing in common. That's what made the day long: every time the matter seemed closed, the same symptom came back through another door. We learned to stop trusting the symptom, and to look for the cause each time as if it were the first.