Understand favorite states
Customer App can conditionally present favorite Products, Businesses, and Orders for a signed-in account. A highlighted icon, missing card, success toast, or updated list is not an authoritative favorite-operation receipt.
:::warning Important boundary
Do not tap a favorite control repeatedly to make the icon or list agree with an expected result. A request, local flag, list removal, analytics event, and later read can settle separately.
:::
The three tabs have different owners
| Tab | Current visible class | What it does not prove |
|---|---|---|
| Businesses | Saved business cards resolved against current location and order context | Business availability, open status, menu eligibility, or current favorite flag |
| Products | Saved product cards resolved against current product/business data | Current catalog, inventory, options, price, or cart readiness |
| Orders | Saved order cards with current status presentation and possible Reorder handoff | Order ownership, minimal data, reorder safety, cart reconstruction, or payment readiness |
The tabs are separate reads and mutation surfaces. A result in one does not authorize or settle another.
Add, remove, icon, and list state differ
Favorite controls can appear on business cards, product cards, Product Details, and order cards. The request direction can depend on the local favorite flag.
| State | Safe interpretation |
|---|---|
| Outline/inactive icon | Local item state does not currently mark the item as favorite |
| Filled/active icon | Local state marks it as favorite; server/list freshness remains separate |
| Action loading | One controller considers a request pending |
| Success toast | One response layer reported success |
| Card removed from Favorites | Local list reacted to a remove-like update |
| Card remains or returns | Local flag, list read, original resource, or a later response disagrees |
| Error | Favorite relation is unresolved; do not repeat automatically |
Product Details currently passes its favorite flag into the mutation handler in a way that can invert add and remove intent. Do not use Product Details favorite behavior as a success reference until that defect is resolved.
Loading, empty, and error can converge
Direct entry initializes the active tab with a loading state. Each tab can then fetch favorite relations and resolve the corresponding original resources. The visible list shows loading placeholders and a generic empty state, but a controller error with no rows can look like an ordinary empty list.
An empty tab therefore does not prove that the account has no favorites, that a remove succeeded, or that a product, business, or order no longer exists. It also must not disclose whether a foreign resource exists.
Query, filtering, and original-resource boundaries
Favorite relation reads and original resource reads are separate. The source builds conditional location, franchise, order-type, and resource filters before resolving cards. One conditional query branch can include a malformed prefix, and returned relation rows can lack a reliable favorite flag after the original resource is resolved.
A Favorite card must remain bound to the current account, project, session, resource type, resource owner, and revision. Missing or malformed filters must fail closed; they must not broaden a list, reveal another account's resource, or silently convert an error into empty state.
Card navigation is a handoff
| Card/action | Handoff | Boundary |
|---|---|---|
| Favorite business body | Business page | Current menu, location, fulfillment, open state, and availability are re-evaluated |
| Favorite product body | Product Details | Current product, business, category, options, inventory, and favorite state are re-evaluated |
| Favorite order card | Order presentation | Current account/order authorization and minimal projection remain required |
| Reorder | Reorder/cart workflow | Destructive existing-cart decisions and reconstruction settle separately |
Card body navigation is not a favorite add/remove action, and navigation does not prove the destination is authorized, current, or ready for cart mutation.
Rapid taps, duplicate work, and analytics
Favorite controllers maintain local loading state, but one server-side idempotency or uniqueness receipt and complete rapid-tap suppression are not established across every surface. Duplicate, reordered, or lost responses can leave the icon, card list, and relation state inconsistent.
Some product-favorite actions emit wishlist analytics after a successful response. Analytics is a separate purpose and effect. It must not include sensitive product, order, customer, or inference context without an accepted consent and minimization contract, and it is not proof that the favorite state persisted.
Favorite Orders require stronger authorization
Favorite-order relations must be limited to orders owned by the current authorized account and returned through a purpose-minimal projection. A favorite relation or order reference is not capability to read another customer's order, products, address, payment, student, gift, message, location, or provider state.
The current Favorite Orders path also exposes a Reorder handoff. Reorder can replace existing carts and rebuild products through a separate destructive, multi-stage process. Favorite status does not prove reorder eligibility, fidelity, complete cart reconstruction, Checkout readiness, or success.
Unknown outcomes and safe troubleshooting
| Situation | Safe response |
|---|---|
| Icon and list disagree | Treat favorite settlement as unknown; do not tap again |
| Success toast but card remains | Preserve the mismatch without refreshing as a test |
| Empty state appears after an error | Do not infer successful removal or resource absence |
| Product Details behaves opposite to the icon | Stop; the current action direction is unsafe |
| Business card opens but is unavailable | Treat navigation and business readiness separately |
| Favorite order is missing or too detailed | Treat ownership/projection as unresolved and do not use Reorder |
| Reorder opens or returns unexpectedly | Keep cart/order outcome unknown; do not continue to Checkout or payment |
| Account or project changed | Reject prior lists, icons, requests, analytics, order and reorder callbacks |
Support reports should use only a value-free state class such as “favorite state unresolved.” Do not include favorite contents, product/business/order or customer details, account/order/cart identifiers, analytics payloads, links, or private screenshots.
Privacy and accessibility
- Favorite businesses, products, orders, and inferred interests can reveal private behavior. Keep them out of documentation, diagnostics, analytics, and support evidence unless an accepted purpose requires them.
- Tabs need selected state and scope; lists need loading, empty, error, stale, pagination, and unknown semantics.
- Favorite controls need accessible names, current state, busy/disabled state, add/remove intent, and completion/error announcements.
- Card-body navigation and favorite controls need distinct names and focus targets. Reorder must be identified as a separate destructive cart handoff.
- At large text sizes, cards, status, errors, and actions should reflow without hiding the favorite or Reorder boundary. Screen-reader, keyboard, switch, safe-area, Back, and reduced-motion behavior require current-platform review.
Recertification triggers
Revalidate after changes to Favorites entry or tabs, favorite relation/original resource reads, conditional filters, loading/empty/error rendering, local favorite flags, Product Details action direction, business/product/order card navigation, rapid-tap handling, server uniqueness/idempotency, analytics, Favorite Order authorization/projection, Reorder/cart replacement, account/ project/session cleanup, privacy, or accessibility.
Also recertify after changes to API deployment authority, owner/resource binding, operation receipts, stale-response rejection, analytics consent, or downstream cart/order recovery.