Changelog

Part of the Anaya Care Handbook. Every change to the handbook gets a dated entry here — newest first. An entry says what changed in plain language and names the it touched (added, changed, moved, or retired), so anyone can trace a rule's history.

Convention: when you change a handbook page, add an entry in the same change. One line is enough. Never rewrite or delete old entries.

2026-08-11

The Wallet becomes a real per-client balance, because the money never touches the platform. Anaya Wallet forbade a stored balance outright — ruled it out and the revolving fund was parked as a "Stage 2 / Future" behind money-transmitter licensing — and the reasoning was sound but rested on one assumption: that the platform would be the one holding the money. It will not be. Each agency is onboarded as its own merchant at the fintech partner (Stripe, now selected), and every top-up is a direct charge settling into that agency's own account and its own bank details in a single hop. Anaya never takes custody of a cent: Stripe is the money transmitter, the agency is the merchant of record and owns its refunds and chargebacks, and the balance the platform shows is a ledger of a prepayment the agency holds on the client's behalf — the obligation an agency would otherwise keep in a spreadsheet. So 's prohibition survives intact in spirit — the platform must never hold client funds — and what is revised is only the conclusion that had been drawn from it, that no balance may therefore exist. The two-stage framing is gone with it: there is one model, and fund-on-approval is now simply a top-up sized to a single request. The page adds – : one wallet per client, scoped to the agency that serves them (); approving a fund request draws the balance down even past zero, and the resulting negative balance is an agency receivable that must be shown to agency management and the responsible party rather than hidden, netted away, or clamped () — which adds no new risk, it writes down the fronting that already happens off-platform today; a percentage platform fee taken as Stripe's application fee, configured platform-wide in basis points (default zero) and snapshotted onto each transaction when its payment is raised, so a later rate change can never reach money already in flight (); a credit applied only on Stripe's own asynchronous webhook and never on the paying browser's report of success, processed idempotently per event so a redelivered confirmation credits exactly once (); whole cents only, with every ledger entry carrying the balance it produced (); and a correction as a new entry with a reason rather than an edit (, restating for a ledger that now carries a balance). (low-balance alert) and (return unused funds when care ends) lose their Stage 2 / Future markers and apply to a real balance now, and additionally requires a negative balance to be settled explicitly rather than silently zeroed. is reversed: exceeding the balance no longer refuses a request — it takes the balance negative, says so, and prompts a top-up. The charge-and-settle rules are reworded around a wallet instead of a single request — , , , , , , , (an underspend now restores to the balance rather than refunding a card) and (a request reaches a care provider only when the money is with the agency, whether from the wallet or from the agency knowingly carrying the receivable). Top-ups are collected on an embedded Stripe Payment Element in the web dashboard, card only in v1 and staff-assisted, because representatives are served only by the mobile app and the app has no essential-needs surface yet — recorded as a limitation rather than a preference. The cost of the reversal is stated on the page instead of glossed: a family's money can now sit with an agency for weeks, and Anaya cannot refund what it never held, so a family's recourse runs through their agency or their card issuer. Three decisions close (which fintech partner — Stripe; who pays the processing fee — a percentage platform fee on top-ups; does the revolving fund ever happen — yes, it is the model) and three open (bank transfer alongside cards, a self-serve top-up surface for representatives on mobile, and how far negative a wallet may go). The glossary rewrites the Anaya Wallet section, adding , , , , and , and rewrites from a deferred future concept into the balance itself. Every rule stays 🚧 Spec only — nothing has shipped. No rule IDs were renumbered and none were reused.
The fund-request chain gets a screen, and a bought-out item can be asked for again. The chain that decides how a client's essential needs get paid for — provider asks the agency, agency asks the family — has existed in the system since it was specified, and none of it was reachable: a request could be raised, reviewed, funded, and closed through the API while nobody could do any of it from a page. The client's Essential Needs page now has a second tab where a request is built by ticking needed items and watching the itemized estimate add up, sent for review, approved or declined with a reason, and closed against receipts with estimated and actual spend side by side. The actions a request offers are derived from the state machine itself rather than written out per status, so the page can never present a move the server would refuse. Approving is deliberately not called approval where a family is concerned: because the dashboard does not serve representatives at all, the funding step is labelled record the family's answer, warns that it is being recorded on their behalf, and carries that fact — and the name of whoever recorded it — onto the request (). The same change closes the loop the standing library was rebuilt for: a Purchased item can now be marked needed again from the list, which opens a new cycle and leaves the purchase history untouched, and the button is hidden on an item still bundled into an open request because restocking it would leave that request unable to close (). Essential Needs marks , , , and the retailer-snapshot rules , , and built, and narrows the rest to what is honestly true rather than dropping their badges: , , and are the dashboard only — the care provider who knows what the household is out of still cannot search a retailer or raise a request from the app they actually use. Three gaps are stated plainly instead of implied: a request notifies nobody ( — every step is logged and none of it is sent), a reviewer can approve or decline a bundle but cannot adjust it (), so one over-priced line costs the whole request, and a representative still has nowhere to answer for themselves.
Recording a family's approval now has to say how you reached them; recording their refusal does not. Marking a request funded on a responsible party's behalf commits money they were never shown a screen to approve, and the record left behind was a name and a timestamp — which does not assert anybody was actually asked, and is what the agency would have to stand on if a family later said they never agreed. now requires an account of how an off-platform approval was obtained: who gave the answer and how they were reached. A decline deliberately requires nothing, because it commits no money and returns the items to the list — the same asymmetry the handbook already accepts in , where declining is the direction that must be explained. The known gap is recorded with it rather than papered over: the account is free text with a minimum length, which stops a reflexive "ok" but is a speed bump, not evidence. The structural fix — a required channel (phone, email, in person) beside an optional note, one click and impossible to pad — needs a field on the fund decision and is not built.

2026-08-08

The catalog is gone: products are looked up live, and a client's list becomes a standing library. A stored catalog of items — even one curated from a real feed — was solving the wrong problem. What a household needs is not a shared library of everything an agency might ever buy; it is this household's own repeating list. So there is no catalog at all now: adding an item searches the retailer live, and only a is kept on that client's item — what the retailer said, and when. Anything the feed does not carry is still typed by hand. Two consequences follow, and both were the point. Prices are quoted from a store resolved from the client's own address rather than one platform-wide setting, because the care provider shops near the client's home; the same product can therefore be priced differently for two clients, which is correct, and where no store can be resolved the search returns photos with no prices and says so instead of showing $0. And a client's list is now a : an item stays on it after being bought and is restocked when the household runs out again, so every purchase is appended to a permanent history rather than overwriting the last one — which is what finally makes real rather than specified. Essential Needs rewrites (a recorded purchase is permanent; the item restocks), –, and , marks built, and replaces its catalog terms with Standing library, Retailer lookup, Product snapshot, Reference store, and Restock. The platform catalog page and the override catalog prices permission are both removed — the catalogue drops from 100 to 99 — and Identity & Access loses that entry. Three gaps are recorded rather than glossed: the fund-request chain still has no interface on web or mobile, retailer search and restocking are absent from the app care providers actually use, and no representative can yet approve a request themselves, so every funding decision is recorded on their behalf.
One feed covers the whole catalog; the second, paid one is dropped. The plan assumed a grocery feed for food and household items and a separate commercial feed for the medical half — incontinence, wound care, mobility aids — on the assumption a supermarket API would not carry them. Checked against a real Los Angeles store rather than assumed, the free feed returned photos and shelf prices for incontinence underwear, gauze pads, nitrile exam gloves, disposable bed pads, and cane tips. The second feed is therefore not needed, which removes a monthly cost and a blocking vendor decision, and the enrichment sweep now covers both item types instead of groceries alone. The same check surfaced why the confident-match rule matters: searching a grocery feed for "walker" returns shortbread and beer long before a mobility aid, so the threshold that refuses a weak match is what keeps a wrong photo off a care provider's shopping list. Essential Needs rewrites the feed decision and replaces the untested-coverage gap with the naming risk that survives it.
The catalog is curated from the live feed, not shipped as a list. A hand-authored seed list was the wrong shape twice over: it had no pictures, and it made a JSON file in the repository the source of truth for data that lives in the database — the same split that already lets the task-template catalogue drift. Catalog items are now added by Anaya through the platform dashboard, searching the live retailer feed and picking real products: the retailer supplies the name, photo, size, and price, and Anaya assigns the item type, category, and unit, because no retailer feed knows this catalog's eldercare classification. Adding the same retailer product twice is refused, and an item is never deleted — it is retired, which hides it from every agency's picker while the essential needs and requests that reference it keep pointing at it. is rewritten from "must ship a starter catalog" to "must maintain a curated catalog"; gains the retire rule.
Catalog photos and prices come from the retailer feed, and say so. The seeded catalog shipped with real names and estimate prices but no pictures — deliberately, because inventing retailer image URLs would have been fiction. Photos and prices are now pulled from the feeds instead, and each item records which feed, that feed's own product reference, and when it was taken, so an agency looking at a price can see who said so. Two rules keep the pull honest: an item the feed cannot confidently match keeps its placeholder rather than a plausible-but-wrong picture, and the price taken is always the shelf price, never a promotional one — a promotion expires, and a budget approved against one understates the real shop a week later. gains the provenance requirement.
The catalog belongs to the platform; an agency's only lever is its price — in the open. The same-day design pass sharpened the catalog model three ways. First, catalog items are platform-level only: seeded or feed-synced once and shared by every agency, with no agency able to add, edit, or remove them — an agency's sole customization is a price override, and even that never hides the platform's number, which stays visible beside the override to agency staff and representatives alike, so a family always sees the retailer reference price next to what their agency expects to pay. Second, an essential need created from the catalog keeps a permanent reference to its catalog item alongside the priced snapshot it was added with. Third, the existing essential-need record — a free-typed name and a hand-guessed cost, acknowledged as a temporary minimal design — is being rebuilt rather than migrated: the stored records are cleared and the schema redesigned around the catalog. Essential Needs rewrites and adds –; the glossary gains Price override. Three permissions enter the catalogue with the feature (): override catalog prices and review essential-needs requests for agency management, and approve fund requests, which joins the Representative's role-inherent responsibilities on Identity & Access ( updated) under the same hybrid model as meal approval — management may record the family's off-platform answer on their behalf.
The family's money now arrives before anyone shops, and the platform deliberately never holds it. Anaya Wallet was specified as a revolving fund — the family loads a pot of money, the agency draws against it — which is the version that requires the platform to hold other people's money and therefore money-transmitter licensing in nearly every state, an unresolved blocker that had the whole module parked as Future indefinitely. The real problem it was meant to solve is narrower and more urgent: today the agency buys a client's essential needs out of its own pocket and chases the family for reimbursement, and where the agency does not front it, the care provider standing in the store does. The Wallet is therefore redefined as the payment rail underneath the fund-request flow, not a replacement for it — Essential Needs still owns the conversation (provider asks the agency, agency asks the family), and the Wallet owns only the money — and it now ships in two stages. Stage 1, fund-on-approval, stores no balance at all: approving an itemized fund request charges the responsible party for that request and settles the funds to the agency's verified payout account before shopping begins, so money passes payer → fintech partner → agency and never rests with the platform. Because the charge is an estimate and receipts are the truth, every closed request reconciles — an underspend is refunded to the card it came from, an overspend raises a small top-up, and a difference is never quietly kept as a credit, because a retained credit is a stored balance and would undo the whole design. Stage 2, the revolving fund, is kept but explicitly deferred behind licensing, per-state coverage, and KYC on every responsible party. Anaya Wallet moves from Future to Planned, rescopes , , and as Stage 2 only, rewrites , , , , and around a fund request rather than a balance draw, and adds –: no resting client balance and custody with the partner (), charge-and-settle on approval (), one idempotent charge per request so a retry can never double-charge a family (), a failed payment leaving a request unfunded rather than funded-but-unpaid (), reconciliation of actual against charged (), an append-only ledger reconcilable to the partner's record (), settlement only to an agency account and never a care provider's personal one (), and the promise the module exists for — a care provider must never be asked to spend their own money (). The page's standing conflict over who raises a request is resolved by deferring to the Essential Needs chain: providers raise, agency management approves, and only the responsible party funds — care providers hold no Wallet permission and never touch money. Essential Needs rewrites and so the Wallet slots beneath the existing flow instead of replacing it with a "purchase request". The glossary rewrites the Anaya Wallet section, adding , , , , , , and , and retiring Purchase request. Settlement timing — immediate on approval, a held reversal window, or escrow until receipts — is the one open Stage 1 decision, because escrow would reintroduce the very fronting the module exists to remove. No rule IDs were renumbered and retired IDs were not reused.
Buying for a client now starts from a picture and a price, and the money is asked for before anyone shops. An essential need was a free-typed name with a hand-guessed cost, so a household's budget was only as accurate as whoever typed fastest — and the care provider in the home, the one person who actually knows what the household is out of, had no sanctioned way to get it paid for short of fronting their own money or chatting the family. The page now specifies a platform starter item catalog — the everyday consumables an elderly household runs out of, each with a photo, a category, a default unit, and a reference price an agency can adjust to its local stores, extend with items of its own, or hide from — so picking an item fills in its details and its estimated cost, and the budget estimates itself. A reference price is an estimate, never a quote, and an item keeps the estimated cost it was added with: re-pricing the catalog never rewrites an existing item or a request the family already signed off on. On top of the catalog sits the fund-request chain — the provider asks the agency, and the agency asks the family: the provider bundles needed items into an whose itemized, priced total is visible before it is sent; agency management reviews, adjusts, and approves it; approval becomes a the client's responsible party explicitly approves or declines; and receipts close the request with estimated and actual spend side by side. Until Anaya Wallet ships no money moves through the platform — the fund request records the ask, the sign-off, and the reconciliation while payment happens outside, and it becomes the Wallet purchase request when the Wallet arrives. Essential Needs adds – (all 🚧 spec ahead of code), folds its Wallet-future section into the new fund-request flow, and adds four open decisions. Two were settled the same day: the catalog's products, photos, and prices are sourced from external retailer feeds — the Kroger Products API for groceries, whose prices are keyed to an agency-chosen reference store, plus a commercial product-data feed for medical supplies, with Amazon's PA-API ruled out by its 2026 deprecation and affiliate-sales floor — and a responsible party's off-platform answer may be recorded on their behalf by agency management, clearly marked as recorded-on-behalf (), so a family that never opens the portal can never stall a purchase. The glossary gains Item catalog, Reference price, , and ; Anaya Wallet now points at the interim flow. No rule IDs were renumbered.

2026-08-07

A care proposal can now be handed to whoever actually writes proposals, not just to an Admin. Transferring authorship offered only staff holding the built-in Owner, Admin, or SuperAdmin role, and refused anyone else outright. But a custom role is a separate thing from a base role rather than a variety of Admin, so an agency that had moved its senior staff onto a custom role like Care Manager could not hand a proposal to the very people writing them — they were missing from the picker and rejected by the transfer. Eligibility is now stated as what a person is trusted to do rather than what their role is called: anyone active in the proposal's own agency who is allowed to create and edit care proposals can take authorship, which is the Admins by default plus any custom role granted that ability. The names offered and the check enforced now come from that one rule, so the list can never show somebody the transfer would then refuse. Two narrower corrections come with it: a proposal can no longer be handed to someone in a different agency, which nothing previously prevented, and platform-level accounts are no longer eligible to author an individual agency's proposal. Who may perform a transfer is unchanged. Care Proposals rewrites and its permissions row.

2026-08-06

A care document can now be opened in Google Docs, not just downloaded as Word. Every care document the platform produces — the care plan, the care proposal, the care summary, the shift report — could only leave the platform as a file on someone's laptop, which is where collaborative editing stopped: two people reviewing the same care plan meant two copies and a reconciliation. Each of those documents now also offers Open with Google Docs, which puts the same Word document the platform would have downloaded into that person's own Google account, converted, and opens it. Connecting is asked for at the moment it is first needed rather than on a settings page beforehand, and the platform asks only for permission to manage files it created itself — it can never read the rest of that person's Drive. Opening the same document twice reopens the same Doc so edits survive, while a republished care plan or an amended shift report produces a new one, so republishing can never overwrite what somebody wrote. Access deliberately gets no permission of its own: whoever may download a document as Word may open it, and nobody else, so the two can never drift apart. The signed care proposal stays PDF-only exactly as it already was. Integrations & API adds –, a Google Drive row in the integration register, two permission rows, and moves off "nothing on this page is implemented".
Exporting a care document to Google is recorded, but nothing after it is. The same change writes down a consequence worth stating plainly rather than discovering later: once a care document has been converted into someone's Google account it is theirs, and the agency can no longer recall it, see who it was shared with, or follow it in the activity log. That is why the connection is per-person and per-document rather than an agency-wide sync. requires the platform not to present this as equivalent to an in-platform download and never to export on someone's behalf unasked. Two gaps are recorded rather than papered over: the activity log stops at the export, and nothing yet restricts which Google account a document may land in — including a personal one, which carries no business agreement with Google covering client information. Whether an agency should be able to confine exports to Google accounts it controls is now an open decision on that page.

2026-08-03

Reviewing a shift now starts with what went wrong, and a shift will have an address of its own. A care manager opening one shift could land in any of four different views of it — an assignment sheet with no tasks or reflection, a narrow scorecard, a wide report with no management actions, or a thin calendar dialog that could only link back to a list — and which one they got depended on where they clicked rather than on what they wanted to know. None of them could be bookmarked, shared with a colleague, or linked from a notification, and a shift outside the currently loaded page of results silently opened nothing at all. Shift review is now defined as one ranked list of exceptions shown before any other detail, covering the whole span from nobody assigned through to a missing reflection, with each entry naming the part of the record that answers it and a clean shift saying so plainly. Exceptions are graded: critical means a care obligation went unmet or care was delivered without a required safeguard, warning means care happened and the deviation deserves review. Two gradings follow from rules already on this page rather than from preference — a missing reflection is a warning, because already closes such a shift as completed without reflection and the client still received care; and a clock-in later than the agency's no-show window is critical, because by that shift should already have been marked a no-show. The same signal is required on every shift list, computed only from what a list row already knows, and a row may under-report but may never claim a shift is clear. Scheduling & Shifts adds –, a "Reviewing a worked shift" section, a permissions row, and a note on the lapsed-unstaffed-shift known gap. Every shift now has its own page under its client, opening on that ranked list, and the four overlapping views are gone — the calendar keeps a peek whose job is to hand off to the page rather than dead-end on a list, and a bare shift id resolves to the right place for notification and email links. Both shift lists carry the same badge, computed from what the list already knows so no row costs an extra lookup, and All Shifts gained a "Needs attention" filter that states plainly it only covers the loaded page. , and are all in code.
Reading a shift by its id now checks who is asking. Giving shifts their own addresses turned a route nobody called into one that gets bookmarked and shared, and it carried no row-level check — every care provider could read every colleague's shift, including the clock-in and clock-out record. A care provider may now read a shift they are assigned to, or one that needs coverage (because the pickup flow legitimately opens an available shift before they have any claim on it); care managers and admins continue to read any shift in their agency, which was never in question. The clock record itself is also trimmed to the timing and geofence facts a reviewer needs, leaving raw coordinates and internal admin notes to the location view that has always been gated more tightly. The handover list route was gated to match — it enforced the same scope in its own code but never declared it, which is why the platform's route-coverage check had been failing. New .

2026-07-29

An accepted care provider is told they were hired, and their app now knows it. Accepting an applicant looked up their details with a query scoped to the reviewer's own agency — but the marketplace's whole point is applicants who belong to no agency yet, or to a different one. For those applicants the lookup came back empty and, worse, discarded the reference to the person entirely. Everything downstream then acted on nobody: the applicant received no in-app notification, no push and no email; they were never added to the hiring agency; and they were never put on the client's care team, so their phone kept showing the "no client yet" home screen indefinitely. The same empty lookup is why some applicants showed with blank details in the review list. The applicant is now identified before any of that work begins, so a filtered lookup cannot break it. Two ordering and reliability faults are fixed alongside: the acceptance notification was sent before the care-team record was written, so the phone's refresh could read "still no client" and cache that answer — it is now sent last; and a notification addressed to nobody used to be recorded as delivered, which is why none of this left a trace, so it now fails loudly and is retried. A care-team add that fails during acceptance now notifies the agency staff who can fix it, rather than only appearing in a server log. Job Postings marks and the surfacing clause of as in code, and drops the blank-provider-details known gap.

2026-07-28

An audit entry can no longer vanish, and the log always reads in true order. The activity log was written inline and its failures were swallowed twice over, so a failed write disappeared without trace — the entries most likely to be lost were exactly the ones written while the platform was struggling. Entries are now queued the moment an action completes and written by a background worker that retries with increasing delays, parks an entry an operator can re-run rather than dropping it, and falls back to writing directly if the queue itself is unavailable, so queuing can never be less reliable than not queuing. Because a retried write can land late, every entry now also records when the action happened rather than only when it was written, and the log orders by that. The audit queue is visible on the system health dashboard like every other background queue. (tamper-proof audit log) remains 🚧 — retryable is not tamper-proof. Platform Operations rewrites , adds and the Parked entry term.
A proposal's status and its history can no longer disagree. Status was stored only as the newest entry of a history array read newest-first, so every guard, filter, and sort re-derived it by indexing into that array — and one write path that appended without the others' assumptions would have left the record quietly wrong, with nothing to catch it. Care proposals, clients, and initial assessments now each carry their current status as its own field, written in the same atomic update as the history entry and refused outright if the two would disagree; the history reads oldest-first like an ordinary timeline, and a rolled-back transition removes both halves together. Two long-standing consequences are fixed along the way: editing a completed initial assessment no longer silently reverts it to draft (and so no longer blocks converting it to a proposal), and creating a client from a proposal can no longer be recorded twice by two people acting at once. Separately, a proposal's own timeline is now stated to be distinct from the platform activity log: the log is a compliance record with its own retention, never read to build a proposal screen. Care Proposals adds and updates .

2026-07-26

One shift nobody could work no longer strands a client's whole setup. Shift generation starts its window at the earliest schedule date rather than at today, so a batch is routinely created already containing shifts whose start time has passed — and nothing ever retires them, because the no-show sweep deliberately ignores shifts with no care provider. Final assignment demanded coverage for every shift in the batch, so a single lapsed shift blocked the commit permanently: it could not be staffed, cancelling it did not help, and deleting it left the batch referring to a shift that no longer existed and failed the same check. Both governing rules were already written as "every upcoming shift" (, ) — the code was simply stricter than the rule it claimed to implement. A shift that ends without a committed provider, or that was cancelled, is now excluded from the coverage requirement and kept as a historical record, never retroactively assigned; the refusal names the shifts still genuinely outstanding instead of only counting them. Scheduling & Shifts adds and two Known-gaps notes.
A published posting now reaches care providers by email too, and publishing can be kept quiet. A new posting alerted providers in the app and by push, but never by email — the channel a care provider between shifts is most likely to actually read — so postings sat unseen. Publishing now also sends email, using the same branded notification layout as every other alert. Publishing had no off switch either: any correction, test, or backfilled posting re-announced itself to every provider, which taught staff to avoid the feature. Publish now offers a choice to alert providers, on by default, that suppresses in-app, push, and email for that publish alone without changing the posting's visibility. A provider's own opt-out still wins over an agency choosing to alert. The audience is now taken from the posting's agency rather than the publisher's, so a platform administrator publishing on an agency's behalf no longer reaches every provider on the platform. Job Postings rewrites and adds .
Screening an applicant no longer means opening their profile. An application card showed a name, an email, a distance and a hidden menu — everything that decides a hire (do they have the skills we asked for? can they actually work the shifts they picked?) was one or two clicks away, so reviewers accepted on gut feel and discovered conflicts at the acceptance gate. Each application now carries its own screening summary — required skills tagged held or missing, distance from the work, and how many requested shifts their declared availability allows with the first blocking reason named — computed from the same evaluation the acceptance gate uses. Mark as Reviewed, Reject, and Accept are now visible buttons on each card rather than menu items. Job Postings adds .
Job postings now say when the work is in the same vocabulary care providers use for availability. A posting's schedule was an iCal recurrence rule with a duration, which nothing could compare against a provider's declared weekday-and-clock-time availability. Every posting now carries a — weekday plus clock times in one timezone — derived from the selected shifts on a coverage bundle and entered directly on a generic posting, so what is advertised can never drift from the work on offer. Matching is a direct comparison instead of a recurrence simulation, and the schedule is finally shown on posting cards and detail pages. Job Postings rewrites , , , , , , , and adds the term; Scheduling & Shifts updates and ; ARMI Marketplace updates and ; Glossary gains the same term.
Overnight shifts can be covered. A provider could not declare availability that crossed midnight, and the matcher rejected any shift whose start and end fell on different local dates, so every night shift was unfillable for everyone. A shift is now evaluated as one segment per local calendar day and matched against that day's declared availability, and 24:00 is accepted as an exclusive end-of-day sentinel so the two halves of an overnight stretch meet exactly. Both availability editors offer overnight entry and write the two segments themselves. New ; and state the segment model.
Coverage bundles are a chosen subset, and a drifted posting stays readable. A bundle previously had to contain every shift in the batch while every shift also had to be unassigned — two conditions that could not both hold once Shift Assignment began, which blocked creating, viewing, applying to, or accepting any posting for that client. Staff now select which uncovered shifts to advertise, defaulting to all of them, with covered shifts shown alongside and the reason given. Coverage health is reported on read rather than enforced, so a posting whose shifts were regenerated can still be opened and closed. , , .
Acceptance reliably puts the provider on the care team. The workflow gate that governs manual care-team additions was also being applied to job-application acceptance, and its failure was logged as "already assigned" — leaving the provider off the team and blocking final Shift Assignment with an unrelated message. Acceptance now bypasses that ordering gate, reactivates a previously removed membership instead of failing on the duplicate, and surfaces genuine failures. The care-team matching view also ranks by declared availability, as it always claimed to. , .
Postings are no longer hidden for being a poor fit. Marketplace lists filtered out postings a provider could not fully take, contradicting the requirement to show the reason instead. Fit is now annotated rather than filtered. , .

2026-07-24

Made care-provider work availability mobile-first while implementing the coverage workflow. Care providers can now edit weekly windows and date exceptions from Me → Work Availability in the mobile app; assigned and unassigned home screens show a setup banner until the record is complete, and coverage applications show only concrete eligible shifts. The web profile remains a secondary editor. Backend scenarios cover invalid windows, effective ranges, overrides, conflicts, reservations, hour limits, stale generation, and final commitment; mobile scenarios cover API, query, banner, and editor-navigation states. ARMI Marketplace updates – and – from specification to their current implementation status, with explicitly making mobile the primary provider surface.
Rebuilt client setup as a strict, coverage-first Care Operations workflow. The canonical sequence is now Schedule → Shift Generation → Care Plan → Care Team → Shift Assignment → Meal Plan → Engagement Bank → Care Task List → Meal Assignment → Engagement Assignment. Care Lifecycle adds the ordered backend and interface gates, record-derived progress, and dependency invalidation (–). Scheduling & Shifts separates unassigned 45-day generation batches from final staffing, introduces schedule revisions and staged coverage, and requires complete coverage before later steps unlock (, , –, new –). Care Plans records the generation batch and schedule revisions that ground a plan (–). Clients separates care-team membership from shift assignment (–). Job Postings replaces single-shift conversion with multi-shift : applicants select eligible shifts, reviewers approve a subset, acceptance stages coverage, and a posting closes when every bundled shift is staged (, , , , , –, , new –). ARMI Marketplace replaces vague preference availability with timezone-aware weekly windows, effective dates, date overrides, commitments, and staged reservations (–, new –). A dry-run-by-default reset migration is included for the one-time cutover; the remaining non-atomic reservation-release and regeneration-reconciliation gaps stay called out on their owning pages. No surviving rule IDs were renumbered and retired IDs were not reused.

2026-07-18

Reconciled the Initial Assessment and Care Proposal pages with the shipped shared-intake / Care Circle / GCS code (docs catching up to code). The initial assessment and care proposal now embed one shared client intake, so initial assessment → care proposal → client is a lossless clone with nothing re-entered. On Initial Assessments: re-scoped the page to the pre-client funnel entity, pointed the embedded inventory at Care Assessments as its single owner, replaced "contact person" with the and a resolved (, ), corrected the lock model — a Completed assessment reopens to Draft when edited and the only hard lock is "already converted" (; retired), documented durable clarification-only AI generation and the Guided Narrative ( reworded; new –), and retired the Independent/Set-up/Partial/Full + RTI-E/ACL/ADM inputs (, ). On Care Proposals: replaced "family contacts" with Care Circle / responsible party / addressees (, , ; new ), documented AI generation of the cover letter / care goal / care areas with clarification-only HITL (new –), the derived (new ), the canonical Word document with every PDF derived via Gotenberg (new ; / updated), the assessment-score rate formula (new ), the lossless convert clone (, ), and client activation carrying the Care Circle and seeding the inventory (), plus the permission precedence on . New rule IDs were appended; none renumbered.
Adopted "Care Circle" as the canonical model for a client's people, and flipped Assessment Mode from Planned to shipped. Clients now owns the definition (aligned with the care-proposal model): a Representative is a thin portal-access link keyed to a Care Circle member, the is a resolved-not-invented pointer, and new rules – cover the roster (the client is never a member), carry-over on convert with automatic portal provisioning, and the fixed six-value role set (, , updated). Care Assessments gained a dated audit banner and reworded to the GCS Capacity / Support now / Risk completion model (retiring the "independence score" term). Assessment Mode is no longer "Planned": it documents the shipped intake over the seven gated topics (care setting + the six Life's Milestones), re-auditing – (clarification-only HITL replaced the old review gate; agency-configurable domains and the disclaimer footer stay 🚧). The glossary gained Care Circle (with member and role), Capacity / Support now / Risk, cover-letter tone, and proposal addressee, broadened into one authoritative entry, and rewrote the Simplified Routine Task Inventory and Initial assessment entries; Base Rates now notes the initial assessment also prices from the catalog (cross-referencing ). No surviving rule IDs were renumbered.

2026-07-15

Reverted the routine-anchored scheduling epic (docs-first — matching the code rollback). Removed the 24-hour split coverage pairs, the paid handover overlap window, the co-present handover checklist (distinct from the async handover notes, which stay), the prep-window / prep-lead settings, the stored task phases (prep/routine/handover) and anchor reference, and the stale-schedule review flow (schedules flagged stale by a plan publish). Scheduling & Shifts lost SCH-43–SCH-46 and SCH-49, and the coverage-pair clauses on , , , and were reverted to their single-provider meaning; and now describe positioning a schedule from the client's routine times (a start before the wake time is preparation) with no agency prep-lead setting. Care Plans & Care Provider Tasks lost PLAN-40, and / / were rewritten: the care plan's Daily Routine section proposes the client's routine time anchors, publishing seeds the client's routine-times record (fill-if-empty), and task times come from the routine anchors with preparation inferred from the wake time and the shift start (no stored phase or anchor reference). Routine & Habit Tracking / and Care Assessments now point at the client's schedule-page routine times rather than a Daily Routine & Coverage section. The Care Lifecycle connective-trigger matrix lost row 9 ( → SCH-49 / PLAN-40). The glossary dropped Coverage pattern, Coverage pair, Handover overlap window, Handover checklist, Prep window, Task phase, and Anchor reference, generalized Routine anchor into , renamed Daily Routine & Coverage section to , and restored the entry to the async notes only. Routine times remain the schedule-page source of truth; the care plan proposes/seeds them; the AI task generator infers preparation from the wake time and shift start. Removed rule IDs: SCH-43, SCH-44, SCH-45, SCH-46, SCH-49, PLAN-40. No surviving rule IDs were renumbered.
A client's routine times move to the schedule page as the operational source of truth (docs-first — spec ahead of code). A care manager sets a client's — wake, sleep, and meal times — directly on the client schedule page, with no published care plan required; these drive shift start (the prep window), the coverage-pair day/night split, and AI task timing. / were reworded so anchored-schedule defaults come from the client's routine times (not "published routine anchors"), and SCH-49 now flags dependent schedules stale when the routine times change from either a direct edit or a care-plan publish. now frames the care plan's Daily Routine & Coverage section as a proposer that seeds empty routine-time fields on publish (fill-if-empty, never overwriting a set value), and reads task times from the routine times. / were reworded from "routine anchors owned by the care plan" to the client's schedule-page routine times as the single source a tracked habit reads. The glossary replaced Routine anchor with and reworded the Daily Routine & Coverage section entry. No rule IDs were renumbered.
Routine-anchored scheduling and 24-hour split coverage pairs (docs-first — spec ahead of code). The care plan gains a structured Daily Routine & Coverage section — routine anchors (wake, breakfast, lunch, dinner, nap, bedtime, or custom, each a client-local time plus care guidance) and a coverage recommendation — as the only place in the plan where clock times belong (); publishing denormalizes the anchors and coverage onto the client record, stamped with the source plan version (); every Care Task List task carries a phase (prep, routine, or handover) and may carry an anchor reference recording how its time was derived (); and a plan version that changes the anchors a task's time came from flags the dependent published Care Task List stale, extending (PLAN-40). Scheduling & Shifts gains the 24-hour split coverage pair — two linked 12-hour day/night shifts, always two different care providers, overlapping by the agency-configurable paid handover overlap window (default 30 minutes, 0 allowed) with a structured co-present handover checklist and its block-or-flag clock-out setting — plus the pre-wake prep window and anchor-based schedule defaults with a recorded anchor context, and the stale-for-review flag on anchor-linked schedules (SCH-43 – SCH-49, all 🚧); , , , and were amended with coverage-pair clauses (duplicate-skip, sanctioned overlap vs. double-booking, paid overlap hours, per-provider counting). Routine & Habit Tracking gains / (anchors are owned by the plan's section and a corresponding habit's expected schedule must never diverge from them; an anchor is not itself a logged habit — anchors drive scheduling, routines drive logging), and Care Assessments gains (the Montessori Profile's Daily routine area and the Meal Assessment's meal timing preferences are the AI's source signals for drafting the anchors — the assessments stay narrative). The Care Lifecycle connective-trigger matrix gained row 9 ( → SCH-49 / PLAN-40, 🚧): anchor or coverage changes flag dependent schedules and Care Task Lists stale for review — nothing auto-cascades. The glossary gained Coverage pattern, Coverage pair, Handover overlap window, Handover checklist, Prep window, Routine anchor, Daily Routine & Coverage section, Task phase, and Anchor reference, and the entry now notes the co-present checklist handover inside a pair's overlap window. No rule IDs were renumbered.

2026-07-10

Care assessments become versioned, and reassessment becomes a pure suggestion engine (docs-first — spec ahead of code). Care Assessments gains in-record versioning — every save keeps the prior content in the record's own history and increments a version, still one record per client per assessment (; was clarified to say so) — and a client-level : applying accepted reassessment suggestions writes the changes and cuts a synchronized generation across all six assessments, each bumping a version and keeping its status (Completed stays Completed — the documented exception to , which was reworded to name it) (). Reassessment is redefined as a suggestion engine: the agent proposes per-assessment, per-field changes — assessment, field, current value, suggested value, rationale — and never applies anything (); while AwaitingReview the care manager unticks what they reject and applies the rest in one action before recording the outcome, recomputing materiality (; was reworded from "changes a client's scores" to "finds that a client's scores have changed", gaining recompute-on-apply and moving ✅ → ⚠️). Care Plans & Care Provider Tasks closes the provenance chain: a post-outcome plan draft records the assessment generation that grounded it (), chaining generation → plan version → Care Task List (). The Care Lifecycle connective-trigger matrix gained row 8 ( → → , 🚧) and the reassessment cascade diagram now shows the Apply leg; the glossary gained and , and the entry was reworded (suggest → apply → generation). Two Care Assessments decisions were resolved: #1 (editing a Completed assessment — manual saves keep the Draft revert, history preserves the record, the Apply path is the sign-off exception) and #4 (assessments don't expire on a timer; every reassessment now re-reviews them field by field). No rule IDs were renumbered.
Catch-up entry: docs reconciled to shipped code (change made 2026-07-10, missed its changelog line). Reassessment moved ✅ → ⚠️ — the standalone hospitalization/ER trigger is not yet wired as its own signal (the hospital round-trip is reached through the return-from-discharge path); a Known-gaps bullet says so. Transition of Care / wording was corrected to match the shipped gate: the first post-discharge shift is hard-blocked until the updated plan and its regenerated Care Task List are published — the gate releases on the task-list republish (which necessarily post-dates the plan publish), not on the plan publish itself; the hospital-to-home diagrams on both pages now show that leg. No rule IDs were renumbered.

2026-07-09

Care lifecycle is now documented as built, not planned. The Care Lifecycle page was rewritten for readability and re-audited against the shipped code: it lost its "Planned" badge and gained a plain-language "loop at a glance", a "what the platform does vs. what you decide" split (), two simplified journey diagrams, and pointers to the real screens (the queue and the client Change of Conditions / tabs). All seven rows of the connective-trigger matrix now read ✅ — the contracts fire in the backend — and , , , , moved 🚧 → ✅ ( is a reference rule; was already ✅). The stale "one review object?" and "how automatic should triggers be?" decisions were marked resolved (one record; human-gated). No rule IDs were renumbered.
Re-audited the two hub pages behind the loop. Reassessment & Care Plan Review Cycle lost its "Planned" badge: – and – are now ✅ (routine scheduling, event triggers, review-and-record-outcome, the materiality-driven regeneration link); is ⚠️ (the due date is scheduled but the calendar marker is a pending web surface); and the comparative-period report – stays 🚧 pending Report Generation. Transition of Care lost its badge too: the hospital-to-home round-trip / / – is ✅ (discharge notes open a review; the first post-discharge shift is hard-blocked until the updated plan is published, enforced at shift creation and again at clock-in); is ⚠️ (all four transition types are defined but only hospital-to-home is wired); and agency-to-agency, home-to-facility, the within-agency provider change, and the transition checklist (, – ) stay 🚧.
Fixed handbook rule-ID popovers. Bare rule IDs in prose (e.g. LIFE-2, RAC-13, TOC-4, STEP-16) are meant to become clickable definition popovers, but the recognizer's prefix list had drifted behind the content — 28 in-use prefixes (LIFE, RAC, TOC, STEP, HOSP, MEM, PERSONA, CREQ, ESM, SEC, RPT, INT, AMODE, GAME, EVAL, COORD, WALK, TELE, ROUT, OFF, HEAL, WALLET, DATA, LANG, FB, AX, EVV, ADAPT) were unregistered and rendered as plain text. They are now recognized, so those IDs pop over across every page.

2026-07-07

Change-of-condition significance can now be set in the dashboard, and the care plan page prompts when a plan may be out of date (, /). The change-of-condition review dialog gained a Routine / Significant judgment (COC-8); marking a change significant fires the existing signal that flags the client's Care Task Lists for regeneration review and notifies managers — previously that path existed in the backend but had no way to trigger it from the UI. A new plan-currency notice on the care plan page (Care Lifecycle ) surfaces, in plain language, why the live plan may no longer match the client's condition — a stale Care Task List (condition change, plan update, or assessment change) or an unaddressed significant change of condition — with actions to generate an updated plan or review the change(s). Consistent with , it only prompts: nothing is regenerated automatically. This partly realizes the reconciliation loop's first legs; a formal reassessment (RAC) that re-scores the assessments, and a distinct care-plan-review object (), remain spec only. Statuses moved: 🚧 → ⚠️, and the connective-trigger matrix row 1. No rule IDs were renumbered.

2026-07-04

Replaced the client profile summary with Client Memory. Added a new page Client Memory (new prefix MEM, rules – ) defining an evolving, AI-maintained per-client narrative that is revised in place over time — carrying forward what is still true, updating what changed, adding new observations, dropping the obsolete — rather than the old one-shot blurb regenerated from scratch. It runs on the durable AI-generation framework (background job, generation dock, one run per client), updates manually and automatically when new signals land (shift note/observation, change of condition, incident, care-plan publish; automatic updates are debounced and never block on a human — ), draws on the client's static profile and ongoing record (), is versioned and correctable (), and grounds other AI generation for the client (). The term is retired (glossary + AI Features), and a note on Anaya — the AI Persona reconciles 's "no memory across conversations" (the chat persona) with the persistent per-client memory store. Care-feed posts are not yet a signal source (business-scoped, no client link — Known gaps). No existing rule IDs were renumbered.
Enforced the business-active block () and the idle sign-out (). Both rules had a mechanism that never ran: they lived in global guards that execute before sign-in is resolved, so they always deferred (the same latent-guard bug fixed for permissions in July 2026). The two checks moved to the single point every authenticated request passes through, where they cannot be bypassed: a person whose business is suspended or inactive is now blocked everywhere — including the Owner, until a platform operator reactivates it — with a typed "account inactive" response the apps show as a friendly screen; and a session with no activity for 15 minutes is signed out. Independent (business-less) providers and platform operators are unaffected. No rule IDs changed; the matching Known gaps on the identity page were removed.

2026-07-03 (later)

Closed the permission alias window. The capability catalogue ( – ) is now the only catalogue: the 64 superseded permission slugs were deleted from the platform's enum, resolution no longer emits legacy aliases, and stored role configurations were migrated on staging and production (with pre-migration backups). Legacy slugs arriving from any remaining stale data still upgrade transparently at read time — that normalization is permanent. The identity page's Known gaps were narrowed accordingly (the "documented ahead of code" and "role editor locked rows" gaps are resolved); the appendix stays as the historical mapping record. No rule IDs changed.

2026-07-03

Redesigned the permission catalogue around capabilities on Identity, Access & the Business. New rules – define the convention: every permission is feature : verb (: scope); the only verbs are view, manage (create + edit + delete + duplicate + AI-generate, at most one per feature, bounded by the holder's view scope), and a closed list of justified workflow verbs (); scoped view only where visibility genuinely differs (); a separate delete only for initial assessments, care proposals, job postings, and users (); and no permission may exist without gating something real (). A new appendix on the page is the authoritative migration contract for all 147 previous permissions: 79 unchanged, 42 folded or renamed (e.g. chat:access + calls:initiate → communication:access), 4 role-inherent, 22 removed (the unshipped appointments, emergency-response, and audit-log families — they return with their features). was corrected to the real default scopes.
Introduced role-inherent permissions (). Responsibilities that define a base role can no longer be revoked by configuration: a Representative always holds respond to care proposals, sign home inventories, approve meal plans, and approve engagement plans. The role editor will show these locked; they stay grantable to other roles. Cross-referenced from , , , and . Documented ahead of code (docs-first) — the Known gaps on the identity page track the distance.
Resolved the eight-verb reconciliation decision (old Decision 7 on the identity page): the PRD's View/Create/Edit/Delete/Approve/Assign/Configure/Export grid is the catalogue, folded — Create/Edit/Delete are manage, the rest survive as workflow verbs where a distinct actor performs them. Remaining decisions renumbered 7–9.
Repaired permission enforcement product-wide. Every action that declares a required permission now actually checks it — previously the check was silently skipped across large parts of the product (clients, shifts, care proposals, chat, posts, and more), because the permission gate only ran on surfaces that wired it explicitly. The repair kept real workflows working: representative proposal responses, the care feed, caregiver health observations and document uploads, and Care Manager supervision flows were re-floored to the permissions those people actually hold, and Care Manager roles gained the five operational permissions their daily flows require (task comments and concern triage, observation review, Care Lock access). A burn-down snapshot in code now guards against new unenforced actions; the identity page's first Known gap was narrowed accordingly.

2026-06-24

Care-plan generation can now be grounded in agency policy (). When a business opts in (settings.aiPolicyGroundingEnabled, default off), AI care-plan generation retrieves the agency's policy/procedure/clinical-guidance documents (those marked useForRetrieval, Published) and adds them as guarded context before drafting — so the plan reflects the agency's rules. Default-off and best-effort (a knowledge-base outage never blocks generation). Task, meal, and summary generation are not yet grounded.
Defined Anaya as a persona, not just a feature. Added a new page Anaya — the AI Persona (new prefix PERSONA, rules – ) that defines the single AI character shared across every AI surface — its role, four-word character (Grounded, Warm, Precise, Unhurried), honesty-first guardrail (: warmth as acknowledgment, never sycophancy), and self-awareness. The character is authored once as a shared character constitution and loaded first into the AI chat assistant's system prompt. reconciles the two ways Anaya answers: the anonymous general helper that keeps away from all business data, versus the permission-gated grounded assistant that may use a business's retrieval-eligible knowledge base and cite it. Also added knowledge-base tagging (category, audience, sensitivity, status, and the useForRetrieval switch) as the agency's control over the policy/knowledge Anaya consults; useForRetrieval and Published status now gate AI chat grounding, with existing documents backfilled to today's behavior. (Training-content generation stays driven by explicit document selection at generation time — — not a tag.) No rule IDs were renumbered.
Connected the client care lifecycle into one flow. Added a new spine page Care Lifecycle (End-to-End) (new prefix LIFE, rules – ) with a master state machine and a connective-trigger matrix that turns the previously-siloed client-care modules into one loop. The six broken links between them are now explicit rule contracts: (a changed RTI/ACL assessment flags instruction-step regeneration via ); (a significant change of condition triggers a reassessment via ) and (a discharge hands off to transition of care via ); (publishing a new care plan version flags dependent Care Task Lists stale) and (change-of-condition, discharge, and reassessment converge on one care-plan review); (the hospitalization round-trip — OnHold → transition → reassessment → resume — with the first post-discharge shift hard-blocked until the plan is updated); and (a hospice client's change of condition uses a comfort-care review). 's trigger list was extended (pattern-analysis via ), and was reworded so the regeneration link is mandatory while the materiality threshold is agency-configurable with a default; /16/17 ↔ CA/RAC cross-references were added both directions. No rule IDs were renumbered.
Renamed "task plan" → "Care Task List" across the handbook (page Care Plans & the Care Task List, the glossary, the index rule table, and cross-references) to end the constant confusion with "care plan", which now always means the narrative document. The PLAN prefix and rules are unchanged, and the in-code entity stays CareProviderTasks. This resolves the long-standing PLAN naming decision.
Corrected the status of AI-Generated Task Instruction Steps. Basic AI generation of a task's instruction steps is actually in code; the page's blanket "Spec only" banner was narrowed and re-tagged ⚠️ Partial, while the approval/versioning/flagging/pattern-analysis loop stays 🚧 Spec only.
Resolved "Decisions needed" into rules on Change of Conditions (significance → reassessment; discharge → transition), Care Plans (stale-task flag; the two-"care-plan" naming), Reassessment (materiality threshold default), and Transition of Care (hard-block the first post-discharge shift; discharge keeps its own track but shares the common review). The glossary gained a Care lifecycle section plus , , and .
Third low-risk known-gaps sweep (backend + web + mobile). Eleven resolved gaps removed or narrowed; no rule IDs were renumbered. The backend fixes are small, localized, and each carries a unit test, and the frontends were aligned so the resolutions are actually usable.
Frontend alignment: is now fully resolved on both clients — the web and mobile request-status controls resolve a custom role's allowed transitions from its permissions (previously they keyed off the role string, so a custom role holding the manage-requests permission saw no status buttons). The web reviews list also gained an "Unverified Only" filter option, exercising the both-directions verification filter the prior sweep added on the backend.
Resolved (removed): on Job Postings, a Closed posting could be quietly reverted to Draft and republished ( — publish/unpublish/update now refuse a Closed posting) and the always-zero per-status application counts (the aggregation now casts the posting id to an ObjectId); on Incident Reports, a resolved report could be reopened or re-resolved with stale resolution details ( — Resolved is now terminal server-side); on Medications, the server-side "discontinued" filter never worked (a boolean query param was mis-coerced), medication file attachments recorded the client instead of the uploading staff member, and adding a medication left no activity-log entry ( now fully met); on Engagement Activities, unapproved activities could still be scheduled into shifts ( — single, bulk, and dropdown paths are now approval-gated); on Client Requests, a custom role holding the manage-requests permission could not change a request's status ( — status transitions are now permission-based for custom roles); on Blog, agency administrators could manage the platform-wide blog ( — the admin endpoints are now SuperAdmin-only); on Care Proposals, an incomplete submitted proposal could not be withdrawn for editing ( now ✅ In code — the Pending Approval → Draft withdrawal is exempt from the completeness check, and 's note was updated to match); and on Platform Operations, a malformed Care Lock vault search returned a generic 500 instead of a clear 400.
Reconciled a stale gap: on Emergency Alerts, the note claiming emergency-alert recipients were chosen by a fixed role list was already out of date — the emergency-alert listener selects recipients by permission (so custom roles with full emergency permissions are notified); the stale bullet was removed.

2026-06-23

Reconciled the Known gaps against code fixes that shipped in the app (the "small known-gaps sweep" across backend/web/mobile). Resolved gaps were removed and partially-addressed ones narrowed; no rule IDs were renumbered.
Resolved (removed): the cross-agency caregiver-map leak on ARMI Marketplace ( — the map is now scoped to the caller's business); care assessments editable by any signed-in user on Care Assessments (); the 5000% care-summary metric on Clients; unit-blind weight/blood-sugar abnormal checks on Health Monitoring (); the "first ten" pending-meals cap on Meals; the unsanitized SOS device timestamp on Emergency Alerts; the no-top-up daily-motivation batch on Daily Motivations; and on Client Requests the missing "Other" label (), the zeroed per-status counts, and the Cancel button shown to non-creators.
Narrowed (partially resolved): caregiver assignment status changes are now permission-checked but still lack lifecycle checks on Clients (); the proposal Cancel action is now gated to viewers with cancel rights, leaving only the older status-move screens on Care Proposals ( done, remains); the special-character count/row mismatch is fixed, leaving only status sorting unreliable (Care Proposals); and body temperature & respiratory rate now appear in health-metric averages and trends but not yet in the abnormal-reading list on Health Monitoring ().
Removed a stray tool-output artifact (</content></invoke>) accidentally committed at the end of the ARMI Marketplace page.
Second low-risk known-gaps sweep (backend). Nine resolved gaps removed or narrowed; no rule IDs renumbered. Resolved (removed): the ineffective "show my birthday in the feed" toggle on Care Feed ( — opt-out is now honored); the non-working "send a greeting" button on the Celebrations page (greetings are now delivered as a comment on the celebrant's birthday post and notify them); any-user-can-be-rated on Skills, Ratings & Feature Requests ( — ratings are now restricted to care providers) and the missing unverified-only ratings filter (the verification filter now works in both directions); the abnormal-reading list omitting body temperature & respiratory rate on Health Monitoring ( now fully resolved, completing the partial note above) and the always-zero wound per-status counts (Health Monitoring); the never-persisted "active" marker on task plans on Care Plans & Tasks; and on Meals the unscoped agency-wide meal bank () and the rejected meal still appearing on already-assigned shift tasks ().

2026-06-19

Reconciled the handbook against the Developer Reference v4.2. A second gap pass against the latest reference: terms were renamed to the canonical product vocabulary, new feature pages were captured as Planned or Future stubs, the existing infrastructure stubs were extended, and the glossary grew to match.
Three renames. Social Feed is now Care Feed, with its page slug moved to /docs/15-care-feed; Lock Care vault is now wherever it appears, including Platform Operations; and Caregiver Map is now the (/docs/11-armi-marketplace), a slug move plus a major expansion into a vetted independent-provider marketplace (ARMI = Above and Beyond, Respect, Mission, Integrity). The index rule table and glossary were repointed; the FEED and MAP rule prefixes are unchanged.
New Planned pages added (marked Planned in the sidebar, rules tagged 🚧 Spec only) with their own rule prefixes: AI-Generated Task Instruction Steps (STEP), Assessment Mode (AMODE), Reassessment & Care Plan Review Cycle (RAC), Transition of Care (TOC), Routine & Habit Tracking (ROUT), Telehealth Services (TELE), Care Coordination & Provider Integration (COORD), Report Generation & Audience Management (RPT), Anaya Walk (WALK), Elder Services Marketplace (ESM), Feedback & Improvement System (FB), Multi-Language Support (LANG), and Accessibility (AX).
New Future stub pages added (marked Future): Anaya Healing Ally (HEAL), Hospice Care Support (HOSP), and Adaptive Technology Integration (ADAPT).
The PRD's "Clinical Snapshot" report template is documented non-clinically as the Health Snapshot. Anaya Care delivers non-skilled home care, so the report on Report Generation keeps a plain-language, non-clinical name.
The PRD's "Daily Login Quiz" is the existing Care Readiness Quiz. Confirmed again as the same pre-shift gate owned by Scheduling & Shifts; the glossary now carries the alias term.
The eight infrastructure stubs were re-badged and extended. The earlier "Not built yet" pages were re-badged Planned or Future to match the new status legend and had their rules and decisions extended during this reconciliation.
Glossary grew with the renamed entries plus new terms (ARMI, ARMI Marketplace, Elder Services Marketplace, Caregiver Level Badge, Anaya Walk, Assessment Mode, AI-Generated Task Instruction Steps, recurring time-anchored task, Time Performed, Methodology Configuration, Life's Milestones, Reassessment, Transition of Care, Discharge note, Routine & Habit Tracking, Telehealth, Care Coordination, Report Generation, report audience, content block, Health Snapshot, Welfare Status Banner, Wellbeing Summary, Professional Statement, Comparative Period Report, Tier 1 / Tier 2 family, Background check, Daily Login Quiz, and EVV data points).

2026-06-18

"Clinical Assessments" renamed to "Care Assessments". Anaya Care provides non-skilled home care, so the handbook drops the medical-sounding word clinical. The page is now , its slug moved from /docs/02-clinical-assessments to /docs/02-care-assessments, and the feature name, the glossary, the index rule table, and the sidebar were repointed. Cross-references to the page were updated on Clients, Initial Assessments, Change of Conditions, and Meals; separately, the standalone word clinical was removed in unrelated contexts on Care Plans & Tasks (care-plan narrative), Health Monitoring (wound analysis), Platform Operations (PDF reports and PHI audit), and Integrations & API (FHIR export). The CA rule prefix and – are unchanged — only the wording moved; the "clinician / Medical Professional" role term is kept.
"Requests" renamed to "Client Requests". The operational service-ticket feature is now called Client Requests everywhere (page title, glossary, index rule table, and cross-references on Communication and Skills, Ratings & Feature Requests). The new name disambiguates it from platform feature requests and account-deletion requests, which are separate features. Because the feature was not yet live, the page slug moved from /docs/13-requests to /docs/13-client-requests and the rule prefix changed: REQ-1 – REQ-17 → – (same rules, re-prefixed; nothing renumbered). "Request" remains the in-page shorthand.

2026-06-17

Care readiness quiz removed from the client assessment catalog for good. Resolved the Known gap where the quiz shared the six clinical assessments' status list and errored when its status was managed there. It is now structurally excluded from the client assessment types (only the six clinical assessments remain) and stays owned by Scheduling & Shifts (, ). No rule IDs changed.
Healing Ally removed from the clinical-assessment placeholders. Decision 3 on Clinical Assessments now lists three "coming soon" placeholders (Caring Touch, Always Fresh, Care Bliss); wound-care collaboration is delivered by Health Monitoring, not a clinical assessment.
The three remaining placeholder assessments now open a labeled "coming soon" page instead of leading nowhere; whether to build or remove them stays open under Decision 3.

2026-06-16

Reconciled the handbook against the PRD (Developer Reference Summary, PRD v4.1). A gap pass comparing the reference PRD with the handbook: missing modules were captured as stub pages, and partially-covered modules had the PRD's requirements folded into their Decisions needed / Known gaps. No existing rules were renumbered.
Eight "Planned modules" stub pages added, each marked Not built yet in the sidebar, with all rules tagged 🚧 Spec only: Offline Mode ( – ), Anaya Wallet ( – ), EVV Compliance Reporting ( – ), Security & Compliance ( – , the §4 non-functional requirements), Data Ownership & Retention ( – ), Integrations & API ( – ), Performance Evaluation ( – ), and Gamification ( – ).
Sidebar status badges added. Pages can now declare a status in frontmatter (e.g. status: "Not built yet") which renders as a small pill beside the sidebar item. Driven by a page-tree transformer in lib/source.ts; built pages omit status and show no badge.
PRD requirements folded into existing pages (Decisions needed / Known gaps only — no rule changes): clock-in hard-block + 15-minute no-show alert and the shift-reflection privacy/wellbeing model (SCH); ARMI availability/booking lifecycle (MAP, JOB); AI severity, family notification, and escalation on incidents (INC); the non-dismissible DNR/advance-directive banner and acknowledge-before-first-shift (HEALTH); Care Feed camera-only/no-download/face-opt-in controls (FEED); Home Inventory acknowledge-before-shift, PDF export, and audit trail (INV); the daily-motivation display/sourcing rules (MOT); the 30-day meal-plan → grocery-list flow (MEAL); the four-tier subscriber model and company-configured roles (ACCESS); and the §7 error/edge-case behaviours plus links to the new compliance pages (OPS).
The PRD's "Daily Login Quiz" is the existing Care Readiness Quiz. Identified as the same feature — the care readiness quiz (, , ), not a new module. Its remaining gaps — care-manager-visible scores, a link to the Performance Evaluation record (), and fresh non-repeating daily questions — are recorded on Scheduling & Shifts and Performance Evaluation; the glossary now notes the PRD name.
Glossary expanded with terms for the new modules (offline mode & sync, Anaya Wallet & responsible party, EVV, RTO/RPO, SOC 2, data owner/processor/custodian, webhooks, HL7 FHIR, and more).

2026-06-12

New Base Rates page. The pricing catalog behind proposal rate calculations (one base rate plus per-city overrides, with the six value-added service rates) documented for the first time: new rules – . Known gap recorded: rates are stored globally with no agency scoping. Decisions raised: per-agency pricing, and whether rate changes reprice existing proposals.
New Caregiver Map (ARMI) page. The dashboard caregiver map documented for the first time: new rules – . Known gap recorded: the map endpoint skips permission and agency-scoping checks and can expose every provider's home coordinates platform-wide. Decisions raised: cross-agency intent, location precision, gating permission, and the planned Directory.
Planned Survey feature noted on Skills, Ratings & Feature Requests as a decision to make when it is built.
Content & Community dissolved into four module pages. The page was retired into Trainings, Social Feed, Blog, and Skills, Ratings & Feature Requests. Rules CONTENT-1 – CONTENT-14 retired → – ; CONTENT-15 – CONTENT-20 → – ; CONTENT-21 – CONTENT-30 → – ; CONTENT-31 – CONTENT-35 → – .
AI Chat Assistant and Knowledge Base got their own pages. Split out of AI Features, which now covers only the generation framework, writing helpers, and shift summaries. Rules AI-10 – AI-13 retired → – ; AI-14 → ; AI-15 → ; new rule (a document must finish processing before use; failed processing is retryable).
Platform group moved to the top. The sidebar and index now read Platform → Intake & onboarding → Client care, putting platform-wide concepts (identity, communication, AI, trainings) before the care journey.
Renamed "Bible" to "Handbook". No rules changed — the document is now called the Anaya Care Handbook everywhere (page taglines, index, glossary, changelog, and homepage). Same source of truth, friendlier name.
New Client Calendar page. The per-client calendar (meals, engagement activities, doctor's appointments) documented for the first time: new rules – . New decisions raised: what else should the calendar show (shifts, task occurrences, medication doses, birthdays), and should family representatives see it.
Daily Motivations moved to the Platform group. The feature is agency-level (one quote per agency per day, no client scoping), so its page moved out of Client care to sit beside Content & Community. Rules – unchanged.
Daily Living split into Meals, Engagement Activities, and Daily Motivations. The Daily Living page was retired. Rules DAILY-1 – DAILY-11 retired → – (the meal halves of DAILY-7 and DAILY-10); DAILY-12 – DAILY-14 retired → – plus – (the activity halves of DAILY-7 and DAILY-10); DAILY-25 – DAILY-26 retired → – ; DAILY-27 retired → per-page visibility rules , , .
Emergency Alerts (SOS) got its own page. Split out of the incidents page, which was retitled to "Incident Reports". Rules INC-16 – INC-22 retired → – ; new rule (every alert belongs to one agency and one client); reworded to cover reports only.
Essential Needs and Home Inventory got their own pages. Split out of Daily Living. Rules DAILY-15 – DAILY-18 retired → – ; DAILY-19 – DAILY-24 retired → – ; new rules and (per-page visibility and agency scoping, formerly covered by DAILY-27).
Sidebar regrouped again. Client care lifecycle and Clinical & daily care merged into a single Client care group covering everything from Clients through Home Inventory.
Known gaps became internal. "Known gaps" sections are now shown only when the docs run locally — they are stripped from the published site, its search, the Ask AI corpus, and machine-readable exports.
Care readiness quiz moved to Scheduling & Shifts. The quiz is a pre-shift gate, not an intake step. Rules AS-23, AS-24 retired → , ; the intake page was retitled to "Initial Assessments".
Sidebar regrouped. New groups: Intake & onboarding (Initial Assessments, Care Proposals) and Client care lifecycle (Clients, Clinical Assessments, Change of Conditions, Care Plans & Tasks, Scheduling & Shifts, Job Postings).
Change of Conditions got its own page. Split out of the assessments page. Rules AS-18 – AS-22 retired → – ; new rules (every submitted note is evaluated for a handover exactly once) and (a note belongs to one client, one shift, one author).
New Clinical Assessments page. The six client assessments (Simplified & full Routine Task Inventory, Montessori Profile, Allen Cognitive Level, Home Safety, Meal Assessment) documented in detail — purpose, contents, scoring, and use. Rules AS-12 – AS-17 retired → – ; new rules – . New decision raised: should assessments expire / require reassessment after a change of conditions?
The handbook replaced the technical wiki. All 16 module pages rewritten as plain-language requirements: 419 numbered rules with stable IDs, per-page Decisions needed and Known gaps lists, and a platform-wide Glossary. The docs-first rule took effect: change the doc first, then the code.

2026-06-11

Documentation site created. Initial release of the docs site with the as-built product wiki, reverse-engineered from the codebase.

Changelog

On this page