Yuvomi

Added

• Notes gain category management, a category picker and an AND filter. Manage personal categories and, when permitted, household categories on the Notes board, then select several categories to show notes that belong to every selection. Household categories remain assignable for members who cannot manage them. The dashboard Notes widget supports the same filter. Category badges stay on one line; a +N control reveals and correctly announces the remaining categories on hover, focus or tap, and category icons remain intact after switching between reading and editing.

• The holiday country list now includes the United States, Canada, the United Kingdom, Australia and New Zealand (#965). OpenHolidays, the free API behind Settings → Calendar’s holiday sync, doesn’t cover these five - their public holidays are computed locally instead (fixed dates, n-th-weekday rules, Easter offsets, and each country’s own documented weekend-observance rule), the same approach already used for Brazil. The United Kingdom is offered as three regions - England & Wales, Scotland, and Northern Ireland - since their holidays genuinely differ, not just their names. None of the five has school-holiday data available, so the school-holiday toggle is disabled with an explanation when one of them is selected, rather than silently syncing nothing. For any other country not covered by OpenHolidays or this local list, an ordinary ICS calendar subscription (Settings → Personal → Calendar subscriptions) can still bring in its public holidays - now mentioned there directly.

• A new event goes to the calendar of the person it is assigned to (#1060). A Google or CalDAV calendar that names a default assignee in the sync settings now works in both directions: events imported from it get that person, and a new event assigned to exactly that person gets that calendar as its target in the event dialog. Your own choice in the dialog always wins, and without a match the personal default target from Settings applies as before. Nothing is picked when two people are assigned, or when two calendars name the same person - the dialog says so instead of guessing. Existing events are never moved on their own, and Apple and Outlook calendars are not chosen this way; the sync settings say both where the default assignee is set.

• The calendar filter can hide a connected calendar or subscription, and show the events nobody is assigned to (#1064). The filter sheet lists every calendar and ICS subscription with events in the loaded range, each with its colour and a switch. Hiding one removes its events from all four views and the agenda, remembered on the device for each account. A hidden calendar stays in the list under its name even when none of its events is on screen, so it can always be switched back on. A new event created for a hidden calendar stays out right away, not only once it has synced. The person axis gains “Unassigned”: on its own it shows only the events and tasks nobody is assigned to, together with people it adds them. A person filter saved before this update keeps its behaviour - it does not contain the new entry, so unassigned events stay out, as they did.

• An event’s location opens in a map (#1110, from discussion #1047). The event detail carries an “Open in Maps” action whenever the event has a location; it opens an OpenStreetMap search for that text in a new tab, the same search Contacts already uses for an address. It is an explicit action rather than a link on the location itself, because the field is free text: “Zoom” or “Room 3B” is not an address, and the action never claims it is. The link is built on the device and used only when tapped - no geocoding, nothing looked up in advance. An address imported over CalDAV with escaped line breaks is searched as one line.

• A shopping item can carry a price and the shop it was bought at (#1003, first cut). Both sit in the item dialog, where the item is already open - the checkbox stays the fastest gesture in the app and gains no second step. The price is stored in whole minor units (cents, yen, fils) rather than as a decimal: the purchase history this is groundwork for adds these numbers up, and money in a floating point sums visibly wrong.

  The shop is a managed list, not free text on the row: two spellings of the same shop would split that history in half. The field is a combobox - choose an existing shop or type a new one, which is created on save - so the first shop in a fresh household has a place to come from without a second dialog over the first. Renaming and deleting live under “Manage shops” in the list menu, the same component that manages the categories. Deleting a shop keeps the prices and only clears the assignment: what was once paid stays true.

  What is not here yet is the matching of an item to its earlier purchases - whether the same list text is enough or something more stable is needed. Until that is decided, a price is a note on the item, and no history is derived from it.

• A budget entry can name who is responsible for it (#1057, first cut). One or more household members marked as looking after an entry - “who handles the water bill” - picked in the entry dialog and shown as avatars on the row. It moves no money. Marking someone responsible creates nothing they owe; settling up between people stays in Split Expenses, and the hint under the picker says so.

  It is deliberately not owner_id. That column is the privacy axis: it is fixed to the creating person and not editable, because the visibility of private entries hangs off it. Reusing it would have handed the responsible member the private-entry semantics of the row - a permissions bug that looks like a feature. Responsibility is a second axis, in its own table, so several people can share one entry.

  On a recurring series the label belongs to the series: newly materialised instances inherit it, and editing the series moves it on every instance from today onwards while already-booked months keep whoever was responsible then. Unlike the account, a virtual series inherits it too - the label cannot distort a balance. In a one-person household the picker does not appear at all.

  The overview can be filtered and grouped by responsible member: clicking the avatars on a row filters to that person, a chip clears it again, and a toggle groups the list. The groups are deliberately not disjoint - an entry two people share appears under both - so each group head carries a count rather than a sum; a per-group total would invite adding them up, and the total would be wrong.

  A handover to Split Expenses sits under the picker: it switches to that tab and opens a new expense with the title, amount and date filled in and the responsible members pre-selected as participants. The dialog is not skipped - the split method, the currency and the group are decisions Budget cannot make, and the claim only comes into existence once it is confirmed there. Responsible members who are not in the group are dropped from the pre-selection; if none are left, it falls back to the group’s default split rather than an expense with no participants.

• Inventory items and subscriptions can record the account they are registered under (#1004). One field per module: the e-mail address or username a device or a service runs on. It is deliberately not a password field and never will be - a username without its password is a phone-book entry, which is why it can live unencrypted in the normal database and be searched like any other text. The permanent boundary is in docs/SCOPE.md, section 2, and the field’s own hint says so where it is filled in.

  On inventory the field is household-wide, and that is a decision rather than an oversight: inventory_items carries neither an owner nor a visibility, access is decided once per member at module level (#467), and an owner-scoped field would have meant inventing an ownership model for the whole module just to hold one column. The reporter chose that himself - account names are usually e-mail addresses, and anyone already trusted on the network has seen those. On subscriptions the column sits in a row that already has owner_id and visibility, so it follows both without extra work. Inventory’s own search matches on it too, since “where is the device that runs on this address” is the question the field exists for.

• Planned meals show their recipe’s picture, for recipes mirrored from Mealie or Tandoor (#1059, step one). The thumbnail proxy has existed since the provider sync landed, but only the recipe list used it; the meal planner and the “today’s meals” tile rendered text. Both now show the picture where the recipe has one, so a household running a recipe manager gets a visual planner with no new field and no upload. Recipes typed into Yuvomi still have no image - that is step two, and it is the storage work.

  A card without a picture is untouched: no placeholder, no indent, the same title width it had before. The first cut gave every card an image slot so all of them would line up, which turned out to be exactly the layout change the issue rules out - measured in the week view, the slot cost 32px plus spacing out of a roughly 100px column, in every cell, and a household without a recipe manager would have paid a third of its title width for a meaningless cutlery icon. Row height is what stays equal: the same card measures 121px with a picture and 121px without.

• A recipe typed into Yuvomi can carry its own picture (#1059, step two - the part most households need, since most do not run a recipe manager). One image per recipe, chosen and cropped in the recipe dialog the same way an inventory photo is, and shown wherever the provider thumbnail already appeared: the planner and the “today’s meals” tile. Where a recipe has both, its own image wins - someone who uploads one has chosen that picture.

  The image is served from GET /api/v1/recipes/{id}/image rather than travelling with the recipe. The column holds a data URL of up to 5 MB; shipping that with every row of a recipe list, or with a week of meals, would have dwarfed the rest of the response for a 32-pixel preview. Lists carry a has_own_image flag instead, and the stored data URL never leaves the server as part of a record. Saving a recipe without touching the image leaves it alone; only an explicit clear removes it.

• A household can name the four meal slots itself (#1058). Breakfast, lunch, dinner and snack are now shown under whatever your household calls them - set in Settings → Modules → Kitchen, next to the switch that decides which slots appear at all, because which slots and what they are called is one setting. The name is not a translation: it shows in every language exactly as it was typed, which is the point - fr, fr-CA and fr-BE do not agree on what the evening meal is called, and no locale file can settle that per household. An empty field means the built-in word, so nothing changes for anyone who does not rename. The slot keys are untouched: recipe suitability, the Mealie and Tandoor mapping and the planner rows all keep working, and nothing migrates. The four slots now come from one place in the client rather than five copies, so the planner, the overview tile and the recipe form always say the same word.

• Marking a housekeeping visit as paid asks first, and an admin can take a payment back (#1136). “Mark paid” settled a visit with a single tap - in the report list, in the visit report and in the staff log alike - and checked off the visit’s payment task on the way. A paid visit is settled: from then on only an admin can edit or delete it, so a stray tap was not a small thing. All three buttons now open the same confirmation, and it names what happens: the linked payment task is checked off, and only an admin can undo it afterwards. Cancelling from the visit report leaves the report open. The way back sits in the visit report: on a paid visit an admin sees “Undo payment”, which marks the visit as pending again and reopens a linked payment task. Whether that button appears is decided by the server for each visit, and the server checks the role again when the payment is taken back.

Changed

• Dashboard widgets share one header grammar, and more section headings adopt the shared title style. Three widget header treatments coexisted on the dashboard: most widgets carried a module seal, a title and an optional “view all” link, but Weather and Clock opened straight into their content with no header at all. Both now open with the same seal+title header as their 15 neighbours - the large temperature and the clock face stay exactly as prominent as before, they just get a name above them like everywhere else. The metrics tile row is deliberately left alone: each tile already names a different module with its own seal and label, and forcing one title over several modules would misrepresent it, not fix it.

  Separately, Rewards’ four section headings and a genuinely unstyled Inventory category heading now use the shared u-section-title role instead of a private declaration that had drifted a few pixels off it (Inventory’s had no declared size at all - it inherited the browser default, not any design token). Notes’ and Budget’s section headings, already the right size through their own container rule, now say so directly in markup as well, growing u-section-title’s adoption beyond the two files it was previously confined to.

  .input and .form-input stay aliased to the same rule - renaming roughly 300 existing uses is not worth the review cost - but the alias site and DESIGN.md’s Inputs/Fields section now say which one is canonical for new code: .form-input, the name .form-group/.form-field/ .form-label already use.

• A scaled ingredient quantity is now written in the household’s own digits. Scaling a recipe wrote the number in Latin digits even where the rest of the line used Persian or Arabic ones, so a doubled “۲ x ۵۰۰ g” came back as “4 x ۵۰۰ g” - one line in two scripts. That was deliberate at the time: the server could only read Latin digits, and a quantity it could not read dropped out of the shopping list totals. Now that both sides share the same transliteration, the reason is gone.

  Quantities already stored stay readable, and so do quantities written before a household changes its region: reading gives the configured region’s digits precedence and falls back to every other system, the same way the server does. Without that, this change would have produced data the app itself could no longer read.

• The recurring-payment dialog now says that editing a series also rewrites its first booking (#1035). A series original is two things at once: the template every future occurrence is built from, and the first hand-entered booking. PUT /budget/:id/series writes title, amount, category and account to that one row with no date predicate, so raising the rent for all future months also rewrites what the very first month says - a booking that may be years old. Separating the two meanings of that row needs a migration and a decision about what recurrence_parent_id IS NULL should mean afterwards; until then the dialog where the choice is made states what happens. The delete dialog is unchanged: “Delete entire series” already says it.

Fixed

• Split Expenses no longer shows three ways to add an expense at once, or a second page title under Budget’s own heading. Viewed as Budget’s Split Expenses tab, the tab used to offer its own header button and its own floating button for adding an expense, on top of Budget’s own generic toolbar button and FAB - both of the latter only ever repeated the tab’s own button under the hood. Budget’s generic add action is now switched off for this tab, the same way it already is for Reports; the tab’s own floating button is the one primary action, and its header button steps back to a secondary one. The tab’s own <h1> - a second page title stacked under Budget’s - is now a section heading instead, matching how it already looked in a lighter type size. Deleting a group now gets the same restrained red treatment used for a destructive action elsewhere in the app, instead of looking identical to editing or archiving it.

• The demo data’s birthday reminders now come days ahead, not minutes before noon on the day. The demo seed wrote reminder lead times as 1d, 3d and 1w, while Yuvomi stores them as minutes and reads only the leading digits, so they became one minute, three minutes and one minute again: every demo birthday reminded shortly before noon on the birthday itself, and the birthday form showed a lead time it does not offer. The seed now uses the form’s own values (a day, two days, a week - the former three days became two), and a guard keeps it to those. Only a database filled by scripts/seed-demo.js is affected.

• A dismissed birthday reminder stays dismissed. Dismissing a due birthday reminder only lasted until the next check: the sync that keeps a birthday’s reminder in step looked for an active row, found none, removed the dismissed one and created the same reminder again - so it was back within a minute, and could be pushed a second time. The reminder now stays dismissed until its time actually changes: a different lead time, a changed date, or next year’s birthday.

• A housekeeper can check out again, and work a second session on the same day (#1133, #1138). The one button that carries both directions was disabled while someone was checked in, and it is the only thing that triggers the check-out path - so that path was unreachable: a household could check a housekeeper in and never close the session from the app. The button now offers “Check out” in that state. Behind it, two answers had collapsed into one: a worker’s “currently working” and “was here today” both reported the last session of the day, so someone stayed “checked in” after checking out. They are separate again. The check-in route matched the same mistake and refused a second check-in for the rest of the day, which made split shifts, a break with resumed work, and two separate visits impossible; it now only refuses while a session is actually open. Overlapping sessions stay blocked, and each session keeps its own rate, calendar event and payment task. The line under the name still shows today’s visit once it is closed.

• The formatting toolbar over a task’s note shows its icons again (#1141). Switching a task’s detail view into edit mode builds that form only then, but the icon-replacing pass over the whole overlay had already run before the form existed, so the 13 buttons of the markdown toolbar (bold, list, link, and so on) stayed blank. The edit form now gets its own icon pass right after it is built.

• An event moved to another CalDAV calendar can be deleted or edited right away (#593). A move creates the event in the new calendar and removes it from the old one, but until the next sync Yuvomi kept pointing at the old copy. Deleting the event in that window went to an address that no longer existed, counted as done, and the next sync brought the event back from the new calendar. An edit was dropped the same way, and moving the event back to where it came from was not recognised as a move. The event now points at the new calendar and its new copy as soon as the move succeeds, as moves to Google calendars already did. An event deleted while its move is still under way has its new copy deleted as well, and an edit or a move made while a change is still being sent to the server stays queued instead of being dropped.

• A change to a synced calendar no longer collides with a sync that is already running (#593). Every create, edit and delete tries to reach the server right away, and the scheduler runs its own sync every few minutes. Both did the same bookkeeping at the same time, so one could clear the other’s notes between two network calls: an event deleted while its move to another calendar was still under way left its new copy behind, and the next sync brought the deleted event back. A provider now runs one pass at a time - the immediate attempt, the scheduled sync and a second scheduled tick wait for each other instead of overlapping, and a burst of edits during a slow pass is followed by one catch-up pass rather than one per edit. This covers Google, CalDAV, iCloud and the CalDAV reminder lists behind Tasks and Shopping.

• Keyboard focus comes back after a confirmation, an input dialog or the calendar’s detail popover (#1083). Confirm a delete, rename a list or a subtask, pick a folder to move to, and the page reloads its list - which rebuilds the very button you came from. Focus fell to the page body, so keyboard and screen-reader users started over at the top. These paths now put focus back on the rebuilt control, or on the page itself when that control is gone: in Tasks, Shopping, Documents, Health, Subscriptions, Housekeeping, Inventory, Meals, Rewards, the Schedule, Split Expenses, the quick links and several Settings pages (API tokens, invitations, document storage, recipe providers, calendar subscriptions and accounts). On desktop, the calendar’s detail popover now returns focus to the event it was opened from when it closes through Escape or one of its actions; a click elsewhere still leaves focus where it went. Deleting a contact or an event from its detail view puts focus back on the page as well.

  Where a dialog appears on only some paths - rejecting a reward redemption asks, fulfilling it does not - focus is pulled back only on the path that asked. Otherwise it would land on the trigger of some earlier, unrelated dialog. The guard that holds all of this learned three shapes it could not see: dialogs that deliver their answer after closing (confirmModal, promptModal, selectModal, confirmOverModal), a reload inside a try block or after an if, and a callback handed in as a parameter.

• An edit or a move made while a change is still on its way to Google is no longer dropped (#593). A change to a synced Google event is sent in the background. If the event was edited again, or moved to another calendar, while that request was still under way, finishing it cleared the note that more was waiting: Google kept the older version, and the next sync could write it back over the newer edit. A second move made during a move was lost the same way, and moving the event back to its old calendar while the first move was running was not recognised at all. Only what actually reached Google now counts as done, and anything newer stays queued for the next attempt. An edit made while the event is being moved goes to its new calendar in the same run instead of waiting for the next sync.

• Choosing the calendar an event already sits in withdraws a move that has not gone out yet (#593). A move to another calendar is queued and carried out by the sync, and that attempt can fail - the server may be unreachable right then. Choosing the original calendar again in that window looked like no change at all, so the queued move stayed: the next sync moved the event into a calendar nobody had chosen any more, while the dialog showed the one that was. A target pointing back at the calendar the event sits in now withdraws the queued move, and a target pointing at a third calendar replaces it. Only the choice made in that edit counts: an edit that leaves the target alone keeps a queued move, and a target stored on an older event that differs from its actual calendar is still never read as a wish to move. Withdrawing also works while the sync is set to read-only or its account is gone - it changes nothing at the provider, and a move the user took back must not come back to life once writing is allowed again. Google and CalDAV alike.

• The event detail names the day a multi-day event ends (#1102). The “When” row showed the start date and, of the end, only the time: an event from 10 September 14:00 to 12 September 11:00 read as “14:00 - 11:00” on a single day that ends before it begins, and an all-day event across three days named only the first. When an event ends on another day, the row now carries that day as well - start date and time to end date and time, or first to last day for an all-day event. “Another day” is the rule the calendar grid already uses rather than a second one: a timed event that ends at 00:00 still belongs to the evening it started in (#804), and the end of an all-day event stays inclusive. The range separator now comes from the same locale string as the day view’s date range, a hyphen where the time range used to carry an en dash.

• Dialog content on a phone scrolls again with Reduce Motion turned on (#981). A freshly opened dialog stands at the top, so every swipe inside it began as a tracked swipe-to-close gesture, and on every upward frame that gesture wrote translateY(0) to the panel. Normally the sheet’s entrance animation holds its end state and outranks that inline style, so the write changed nothing. With Reduce Motion the animation is switched off, the write turned the panel’s transform from none into a matrix on every swipe, and iOS dropped the scroll. Measured in the iOS simulator with the setting on: the same upward swipe left the content 0 to 30 px down in three runs. An upward movement of more than 10 px before the sheet has been pulled is now content scrolling - the gesture lets go and never touches the panel’s style. Below that, the same threshold that already applied downwards, nothing is decided, so a finger that wobbles upward as it lands can still pull the sheet closed. A pull that has already started stays tracked when the finger reverses, so the panel still returns to rest. Under the same setting the swipe now ends 500 to 675 px down.

• The Module options settings page describes what it actually contains. Its description named only Budget, Health and Housekeeping - accurate when it was written, but Tasks and Schedule have since grown their own sections on the same page without the sentence ever being updated. Reworded to describe the page’s purpose instead of enumerating its sections, so it can’t go stale the same way again the next time a module gains a section here.

• The person filter in the task history is no longer a row of blank buttons on a phone (#1068). Below 640px the label-loss rule removes every .group-toggle__label; it is built on the assumption that an icon stays behind, which is true for the view switcher next to it. These chips had none, so nothing remained but the tinted surface of the active one. The loss was not only visual: display: none takes the text out of the accessibility tree as well, so the buttons were just as nameless to a screen reader. Each chip now carries what the rest of the module already uses to identify a person - their avatar, the same disc the history rows below it show - and “All” gets an icon from the same family as the switchers. The name itself moved onto the button as aria-label, where no media query can take it away.

• A recurring event synced from Google no longer shows an end time hours after its start (#1089). Every occurrence of a series is generated from the master, and its end was derived by adding the duration to the new start. Which format that end was written in depended on a test that asked the wrong value: it looked for a Z in the master’s start, while the occurrence’s own start may well carry a numeric offset (15:25:00-04:00, as Google sends it) or be rebuilt as UTC from the series timezone. Neither matched, so the end went down the wall-clock branch and was formatted with the SERVER’s local getters. The row then held two storage formats at once: an instant for the start, a zoneless wall-clock time for the end. The browser converts only the first, so the two stood side by side on different clocks - off by exactly the offset between the server and the viewer, which is why it stayed invisible wherever the two agree. Reported from a UTC server viewed in New York: 3:25pm to 3:30pm was displayed as 3:25pm to 7:30pm. The end now follows the storage format of the start it belongs to. Locally created series are unaffected: there both sides read the same server zone and the conversion cancels out.

• Late Notes saves no longer close a replacement dialog or hide a failed save. A save response now belongs to the editor that started it. If that editor has already closed or is waiting behind a discard confirmation, the current dialog and its unsaved fields stay intact; network failures remain visible in the global error toast. A late category-name conflict follows the same ownership rule: it offers the rejected name again only while the page and dialog flow that requested the rename are still current, and otherwise reports the conflict without replacing newer work.

• An ingredient written in the household’s own digits now counts towards the shopping list. Moving a meal plan to the shopping list adds up the same ingredient across meals. The server read the quantity with an ASCII-only pattern, so a Persian, Arabic, Hindi or Thai amount - “۲۵۰ g” - matched nothing at all, and the ingredient dropped out of the totals: the list showed it twice underneath itself instead of once with the sum. A household using its own digits quietly got a worse shopping list than one using Latin ones.

  The server has no locale, so it now accepts every digit system rather than one region’s. The mapping is derived from Intl rather than kept as a table - 770 digit characters across 77 systems is not something anyone would keep current by hand. Only real digits count: the one system whose “five” is an ordinary Chinese character is left out, so a 五 in an ingredient stays a word.

  Two details follow from what a character actually means. The Arabic thousands separator says so unambiguously, unlike a comma, so “١٬٠٠٠ g” now reads as a thousand grams; a plain “1,000 g” is left as it was, because there the server cannot tell grouping from a decimal point. And a fraction stays on the text path rather than being read as its numerator - “١/٢ kg” was never a quantity of one, and neither was “1/2 kg”, which had been getting that wrong unnoticed.

  Quantities written with foreign characters go through a stricter reading than plain ASCII ones, because they had no behaviour at all before: a grouping has to look like one along its whole length, several groups are read as one number, and a comma inside Bengali or Devanagari digits is refused rather than guessed - it groups there, so reading it as a decimal point would be off by a thousand, and the server cannot know which was meant. Plain ASCII quantities keep reading exactly as they always have; changing that is a decision of its own.

• An edit made while the list is refreshing is no longer thrown away. Checking an item off the shopping list, or stepping a pantry quantity up or down, marks the row immediately and sends the change to the server behind it. Both pages stay usable while a refresh is in flight - after managing categories or storage locations, after switching lists, after importing a meal plan. A refresh that had read the server before the edit arrived back after it, carrying the older value, and overwrote what had just been changed. The row jumped back, the counter beside the list tab disagreed with it, and the next tap sent the wrong value on - unchecking something the server considered unchecked already.

  The item was never actually lost - the server had it - which is what made this hard to see: a reload showed the right thing, so the wrong row only lasted until the next visit to the page.

  Pending edits now survive a refresh. Each one is remembered until a refresh comes back that demonstrably started after the server confirmed it, and only the affected rows are re-applied on top of the fresh data. Everything else in the response lands untouched, so the refresh still delivers what it ran for. Discarding the whole response instead would have taken the renamed categories with it - the very thing the refresh exists to bring. A refresh that is overtaken by a later one now steps aside rather than writing an older picture over a newer one.

  A refresh answered from the offline cache no longer counts as proof. /shopping is in the service worker’s read-only offline whitelist, so on a dropped connection the last cached response comes back with its original success status and is otherwise indistinguishable from a fresh one - while being arbitrarily old, since writing does not clear that cache. Taking it at face value put the pre-edit value straight back on the row, which is exactly the situation this is for: standing in the shop on a bad connection. The read now carries whether it came from the cache.

  If the change to the server does fail, the row goes back to what the server last said rather than to what it showed before the tap. Those are the same value in the ordinary case and differ exactly when someone else in the household changed the same row in the meantime - and then the value from before the tap is a number the server has never held.

  In the pantry the pending step also lost track of its own row: a refresh replaces the stored items with new objects, and the delayed request still held the old one, so the server’s answer was written into an item that no longer belonged to anything. The row and the item are now looked up again when the answer arrives.

• A saved filter no longer offers a category, tag or person that has been deleted. The Tasks filter bar keeps the last three filter sets as one-click chips. Nothing checked whether what they name still exists, so deleting a category, renaming or merging a tag, or removing a household member left a chip that put the dead value straight back into the query on click. The list then filtered on something the server has never heard of and stayed empty - and reloading did not help, because the value lives in the browser’s local storage.

  The chips are now filtered when they are read rather than cleaned up when they are written: a single place decides it, and it stays right even when the change happened in another tab or on another device. A set that has nothing left to offer disappears from the bar. Nothing is rewritten in storage, so a category that comes back brings its chip back with it, and a load error - where the app has no reliable list to compare against - leaves every chip alone rather than sweeping them away. Offline counts as such a case: the list of categories, tags and members can itself come from the offline cache and be arbitrarily old, which would hide a chip that is still valid just as readily as it would keep a dead one.

• Deleting a category now updates the page behind the dialog. Every module that offers “manage categories” kept showing the category you had just deleted: the filter chips in Contacts, the grouping in Shopping, the storage locations in Pantry, the places and categories in Inventory, plus Tasks and Budget. The server had deleted it, the screen had not noticed, and picking the stale entry afterwards ran into an error from a category that no longer existed. A reload fixed it, which is how it stayed hidden.

  The cause was a matter of order. Confirming the deletion closes the dialog first and sends the request second, so the “something changed” signal arrived after each page had already stopped listening. Refreshing now happens when the change actually lands rather than when the dialog closes.

  Shopping had a second version of the same staleness, and renaming triggered that one: it stores a category by its name rather than by an internal key, so both renaming and deleting rewrite the items themselves. The list only reloaded its categories, leaving the affected entries under their old heading at the bottom of the list. It now reloads the items with them.

• A fractional ingredient quantity with a stray separator is no longer scaled into a wrong number. Scaling a recipe reads a leading fraction like “1 1/2 cups” as well as a plain amount. Where a denominator ran straight into a separator - “1/2,5 cup” - only the “1/2” was read, the result was multiplied, and the leftover “,5 cup” was appended, so doubling it produced “1,5 cup”: a quantity that looks deliberate and is wrong. The check that already refused this for plain amounts now covers the fraction forms too, and such a line is left exactly as written.

• Scaling a recipe now reads and writes ingredient quantities in the region that is actually set. Applying a recipe to a meal and changing the servings factor rescales every ingredient, and that step parsed the number itself with the comma hard-wired as a decimal point. Under a region that groups thousands with a comma, “1,000 g” was therefore scaled up from 1, putting an ingredient in the recipe a thousandfold too small with nothing to show for it. Under Persian or Egyptian Arabic the number was not recognised at all, so that line stayed at its original amount between correctly scaled siblings - the recipe was simply wrong.

  The result was written the same way it was read: the separator was copied off the input, so a “1.5” mirrored in from Mealie or Tandoor stayed “1.5” in a German kitchen. Both directions now follow the set region - the reading side through the same transliteration as prices and shopping quantities, the writing side through the same number format - so a scaled quantity comes back out in the notation the household reads, and the app can read its own output again the next time. The separator is presentation and follows the region wherever the region uses one the server reads - a comma in German, French or Czech, a dot in US English or Swiss German. Persian and Arabic use a third one, and there readability wins and the dot is written.

  A grouped quantity is refused rather than guessed, and refusing here means the line is left exactly as it was: the quantity is the ingredient’s own text, and the original is the only answer that invents nothing. The same applies to a number that breaks off mid-separator - “1,5 kg” under a region where the comma separates nothing would otherwise have been read as 1. Fractions (“1 1/2 cups”), plain amounts and free text like “a pinch” keep behaving as they did.

• A quantity like “1,000 g” on the shopping list is no longer read as 1 before it goes into the pantry. Taking a checked item over to the pantry pre-fills the quantity field from the free text on the row, and that step parsed the number itself, with the comma hard-wired as a decimal point. Under a region that groups thousands with a comma - en-US among them - “1,000 g” therefore arrived as 1 g, off by a factor of a thousand, and nothing said so. Under Persian or Egyptian Arabic the number was not recognised at all: the field shows the region’s own digits, and a quantity typed in them fell back to “1 piece” no matter what it said.

  The number now goes through the same transliteration as the price fields (#1003): the digits and the decimal separator come from the region that is actually set, and a grouped number is refused rather than guessed - “1,000 g” could mean one gram or a thousand, both readings are defensible, and the wrong one is off by a factor of a thousand. Refused means the row falls back to “1 piece”, which says visibly that nothing was understood, in a dialog where the quantity sits in a field you can correct before it is saved. The same applies to a number that breaks off mid-separator, which a grouping check cannot catch: “٢٬٥٠” has only two digits after the separator, and under Persian the ASCII comma separates nothing at all. Only the leading number decides: “6 x 1.000 ml” is six bottles of a litre each, and the 1.000 further along - which is never read - does not make the line unreadable. “1,5 kg”, “250 g” and “6 x 1 l” keep reading exactly as they did.

• Closing a dialog no longer drops keyboard focus when the button that opened it was re-rendered meanwhile. The shared modal layer remembers the element that opened it and hands focus back on close. If the page had swapped that button out in the meantime - the category manager re-renders its section after every rename, reorder or new entry, while the dialog is still open - the remembered pointer referred to a node no longer in the document. Calling focus() on it does nothing at all, silently: focus fell to document.body, and anyone working by keyboard or screen reader lost their place in the page and had to tab in from the top.

  The layer now checks whether the remembered element is still connected, and falls back in two steps: it looks for a live element under the same id, which finds the button that was rebuilt in the same spot, and otherwise puts focus on the page root - the same target the skip link uses. Not a good place, but a place inside the page, which document.body is not. The root is made focusable first: the app shell gives it tabindex="-1", but the five auth pages render their own <main id="main-content"> without one, and focusing an element that cannot take focus is the very no-op this entry is about.

  The same break has a second, more common shape: a handler that re-renders after the dialog closed - closeModal() and renderGrid() on the next line. There the restore was correct and got re-rendered away a moment later, which no check at close time can see. Measured: 30 such places, and the typical trigger there is not a toolbar button but a list row - a note card, a meal cell - which carries data-id or data-action rather than an id. The layer now looks the element up again by those attributes, and where the target is destroyed right after the restore it takes a second pass on the next frame: only if the target really vanished, only if focus actually fell to document.body, and only if no dialog has opened in the meantime. Where nothing broke, nothing moves - the common path is unchanged.

  Eleven of those places re-render after an await, which is past that frame. There only the page knows when it is done, so it says so: refocusAfterRender() runs the same three checks and does nothing where nothing broke. A scanner in the test suite finds the pattern rather than a list of files, so a new place that re-renders after an await is caught without anyone editing the test.

  A third shape hides between the two and was found in review: a handler that re-renders asynchronously while the dialog is still open - await loadBudgetMeta(); renderBody(); in the category manager. Close the dialog while that request is in flight and the opening button is still connected, so the restore correctly lands on it and the re-render detaches it a moment later. Measured in the browser, focus ends up on document.body again. Eleven handlers of that shape now pull focus across their own re-render, with a second scanner holding the line.

  Where the trigger is a list row, the row itself is what identifies it: inventory and pantry put data-id on the row and only data-action on the button inside it, so every row looks alike from the button’s side. The lookup now carries the row it sat in, and where more than one candidate still matches it returns none and falls back to the page root, because a wrong focus target puts the reader somewhere they did not choose. Not every data- value carries identity, though: a subtask’s rename button also holds its title, and that is what just changed - so the lookup makes a second pass on the identifying fields alone, still insisting on a single match.

  The scanners look through wrappers as well: a handler that awaits reload() rebuilds the page just as much as one that calls renderContent() directly, and the name says nothing about it. Counting only names beginning with render left 25 places uncovered across six more modules. They follow those wrappers through nesting, too - reloadMedViews() calls reloadMeds(), and only that one reaches a render - and they count an awaited callback as a rebuild, since await onChanged() replaces the whole list without naming anything.

  Focus is now also checked for arrival rather than assumed: a rebuilt button can come back disabled - the redeem button in Rewards does, once the points no longer suffice - and focusing it is the same silent no-op the whole entry is about. Where it does not take, the page root does. And where that root was chosen as a stand-in, a later rebuild is allowed to take the focus off it again, so a loader that swaps its opener for a skeleton and rebuilds it after the request does not leave the reader stranded at the top of the page. What decides is whether the target still holds focus, not whether it is still in the document: deleting a task hides its row rather than removing it, and a hidden row keeps its place in the tree while dropping focus to body.

  Measured across the seven callers of the category manager, exactly one - the budget page - puts its button inside the very section it re-renders while the dialog is open. The others keep theirs in a toolbar their handler does not touch, and the shopping menu turned out to be a non-case: the popover hands focus back to its trigger before the page handler even runs.

• Paying extra on a loan now shortens the remaining term, not only the balance (#964). Since #954 the remaining principal follows the money you actually paid, but the remaining term beside it stayed plan-based and still said 100 installments after you had doubled a payment - the exact number the reporter was looking at. It now shows what the account balance implies, with the contractual figure in brackets: 98 (plan: 100).

  Only that one figure moves. Monthly payment and total interest genuinely describe the contract - the bank will not send a smaller invoice because you overpaid - and they stay as they are. The remaining term is the one number in the group where the contract and the balance disagree and the balance is what was being asked about. Both are shown so the contractual view does not quietly disappear.

  The projection is arithmetic, not advice: it carries the contractual annuity forward at the contractual rates, including the switch to the follow-up rate at the end of a fixed period. It says nothing about whether overpaying is worthwhile - early-repayment penalties keep that question out of scope (#935). Where the sum cannot be computed - an instalment that does not cover the interest - the plan figure stands alone rather than an invented one.

• A month-end series in its own timezone no longer drifts across a DST change (#985). A series imported over CalDAV or ICS carries the timezone it was created in. Its recurrence was computed on UTC days, and where the UTC day and the local day disagree - a late-evening event, say 23:30 in New York, stored as 04:30Z the next day - the month-end rule was suspended and the series ran on its fixed UTC day instead. That fixed offset tracks the local month end only while the UTC offset stays put. From the March transition onwards it does not: measured on a New York series at 23:30, every following occurrence landed on the 1st instead of the last day of the month - not one missed date, all of them.

  The recurrence now advances on the event’s local date and converts back to UTC per occurrence, so BYMONTHDAY applies again to the date it actually means, and the local time of day stays put across the transition. Events without their own timezone - everything created in Yuvomi - are unaffected and take the same path as before.

  Two dates now run side by side, deliberately: the rule advances locally, while the display window, the EXDATE exceptions and the emitted instance stay on the UTC day. Exceptions are normalized to the UTC day on import, so comparing them against the local one would have made them miss exactly the events this fix is about.

• A “last day of the month” series now leaves Yuvomi with a start date its own rule accepts (#986). A series created from a mid-month date stores DTSTART as entered - say 15 January - together with RRULE:FREQ=MONTHLY;BYMONTHDAY=-1. Internally that is unambiguous, and the calendar never shows the 15th. Outbound it was not: RFC 5545 3.8.5.3 calls the recurrence set of an unsynchronized DTSTART undefined, so a subscribing client was free to render the 15th and every month end - one occurrence more than Yuvomi shows. Every outbound path (ICS feed, CalDAV, Apple, Google, Outlook) now emits the first date the rule actually matches.

  The end moves with it. end_datetime is an absolute timestamp, not an offset: leaving it behind would have produced an event that ends before it starts. It shifts by the same number of days, so the duration and the stored time format survive untouched.

  Two things stay exactly as they were. An imported series is handed back word for word (#756) - a foreign calendar may carry an unsynchronized DTSTART on purpose, and Yuvomi is not the referee on a round trip. And a BYDAY rule is left alone (#549), where a start on a weekend is a deliberate, older decision. The transformation is read-only at the point of serialization: the stored value never changes, which is what made the write-time attempt in #984 unworkable.

• An event from a subscribed calendar now names its source everywhere an event is read (groundwork for #1064). A subscribed event already inherited its subscription’s colour, but the name came from external_calendars alone: the calendar list, the search and the dashboard all read cal_name as null for it, so it showed up in the subscription’s colour without ever saying which subscription that was. The detail endpoint went further and did not select the column at all, for any event - its own comment promised “the same event object as the read path”, and that promise held for the colour only, so a freshly created or edited event came back without its calendar name. All six queries now read the name from both sources, the way the colour already did. An event with no source keeps cal_name: null.

• The schedule overview now sets its blocks in the same size as the calendar (#1065). A block in the overview carries what a calendar tile carries - a title plus one line of time and custom field - but stood two type steps smaller than one, in narrower columns, which made a school timetable hard to read at a glance. It now uses the same --text-xs the calendar uses. The height was already there: a 45-minute lesson is 42px tall on the condensed hour scale, and two lines cost about 35px including padding; measured across 60 blocks, none clips in either direction. Putting the custom field on a third line of its own, as the report asked, would need about 51px per block and therefore a taller hour scale - that is a change to the scale, not to the block, and is not part of this fix.

• Editing one occurrence of a local recurring event now keeps it linked to its series (#975). The edited occurrence keeps all three series scopes when reopened, follows later series changes for fields that were not deliberately changed, and keeps its original recurrence slot even when moved to another date. The replacement and its skipped original slot are saved atomically, and the read-only ICS feed now exports the replacement with standard RECURRENCE-ID semantics. Imported series keep their existing whole-series behavior. Generated local series and local series targeted for outbound sync retain their previous standalone-edit and deletion scopes. Historic detached edits are left unchanged rather than guessed back into a series. iCloud auto-sync excludes linked replacements and their masters, without excluding ordinary deletion-only exceptions. Detaching a linked replacement retains its original-slot exception, so outbound targeting or a recurrence-rule round trip cannot resurrect a duplicate master occurrence. Changing a whole-series recurrence rule no longer forgets previously deleted occurrences. Truncating a series likewise retains later exclusions, and splitting a linked series transfers every later exclusion except the new anchor even when the successor rule cannot currently reach it, so a later extension cannot resurrect a deleted slot or duplicate a detached replacement. A no-difference only-this save removes an exclusion only when it also removes the linked replacement that owned that exclusion. Save confirmations preserve entered values on validation or server errors. Outlook checks actual writable push targets before accepting linked-series auto-sync, and MCP upcoming results retain their unrestricted future horizon while recurrence generation stops at the requested result count. ICS deletion exceptions keep the series’ local time across daylight-saving changes even when the stored UTC day differs; each exception needs at most three local-date candidates, not a series scan.