Understand student account states

Customer App can conditionally present a signed-in My students area, student selectors on school businesses, and student context in Checkout. These surfaces contain private minor, school, and health-adjacent data. Visibility does not prove that the current account is authorized for every displayed record or that the selected student was assigned to a cart.

The current customer surfaces support list, add, edit, and selection. They do not provide a customer delete action. This is a state and privacy reference, not a student or cart procedure.

List, add, edit, selection, and delete boundary

Surface/state	Current source boundary	What it does not prove
My students loading	Student inventory request is unresolved	No records exist or prior rows are current
Empty list	Current returned list contains no rows	Global absence, deletion, or another account's state
Student cards	Returned identity and school/class/grade presentation	Current authorization, freshness, or complete/minimal data
Add form	New-student fields and school/class/grade/advisory tags	Save eligibility, authorization, or created record
Edit form	Existing record values and save action	Ownership, settled update, or current cart propagation
School selector	Business-scoped local selection	Cart assignment, product filtering, Checkout, or order settlement
Customer delete	No current list/form control or delete request is established	That deletion exists through a hidden route or another action

Opening or closing a form, seeing a success message, refreshing the list, or changing a selector is not an authoritative mutation receipt.

Authorized and versioned minor identity

Every student read or write must derive the current guardian/account, project, session, student, school, and revision on the server. A student reference, cached row, business-scoped local selection, cart relation, or navigation parameter is not authorization.

Responses must be purpose-minimal. A list/card does not need allergy, dietary, health-adjacent, cart, order, provider, or broad school graph data. Edit and Checkout can require additional fields only for a current explicit purpose.

Foreign, missing, stale, or disabled records must return a generic unavailable state without revealing student or school existence.

Cached rows and selection must be account-partitioned

Previously shown rows, pending work, and local selection are not established as one current account/project/session generation. A list that appears loaded or a selector that appears chosen does not prove that its rows and selection belong to the current signed-in context.

Without explicit account/project partitioning and synchronous logout cleanup, cached student state or a prior selection can appear in another context.

A future accepted contract must:

• partition list/cache/in-flight work by immutable account, project, and session generation;
• partition selection by account, project, school/business, and student revision;
• abort or ignore delayed responses from old generations;
• synchronously clear private rows, selections, forms, listeners, and pending operations on logout/account/project change; and
• never write prior rows into a newly signed-in account.

Stale and delayed responses

Situation	Safe interpretation
Account changes while list loads	The old response is foreign and must be ignored
Another list read starts while work is pending	An older result can satisfy the wrong context unless generation-bound
Old rows remain during error/loading	Their authorization and freshness are unknown
Form saves then refreshes	Save, list refresh, selector, cart assignment, and UI close can settle separately
Logout occurs with a selected student	Selection and list/cache must clear before another account can render
Delayed response arrives after logout	It must not repopulate shared state or expose minor data

Do not refresh, switch accounts, reopen forms, or change selection repeatedly to test stale-state behavior.

Automatic selection and cart assignment effects

School selectors and Checkout student details can automatically select the sole eligible student, adopt a returned cart student, clear an invalid selection, or request student assignment/clearing on a cart. These are effectful operations, not read-only presentation.

Local selection, persisted selection, student list, cart student, filtered menu, Checkout gate, and order student relation are separate states. They require one authorized version and explicit/recoverable assignment receipt before Place.

Changing or clearing a student can also invalidate products, advisory warnings, cart totals, payment readiness, and downstream order context. A changed dropdown or cart refresh does not prove those effects settled.

School and health-adjacent privacy

Student names, school, classroom, grade, allergies, dietary tags, health-adjacent context, cart contents, and order relationships are private minor data. Dietary or allergy fields are advisory preferences, not medical records or a safety guarantee.

Do not place real values in screenshots, logs, fixtures, analytics, URLs, clipboard, support notes, or documentation. Use value-free state descriptions such as “student list stale,” “selection foreign,” or “cart assignment unknown.”

Customer-facing delete is absent, so documentation must not imply erasure, retention, or deletion rights from an edit/save flow. Retention and deletion require a separately approved product/privacy contract.

Errors and unknown outcomes

Outcome	Safe interpretation
List error	Student existence and prior rows remain private/unknown
Add/edit validation error	Local form did not accept current state; no write settlement follows
Save error or lost response	Record creation/update and later refresh are unknown; do not repeat automatically
Success toast but row unchanged	One layer reported success; cache/list/revision can remain stale
Selection changes but cart does not	Local/persisted selector and cart assignment disagree
Cart changes but selector does not	Returned cart and local student generation disagree
Student becomes invalid for school	Clear/block context without falling back to another student
Account/project/session changes	Reject prior rows, forms, selections, cart effects, and late callbacks

Troubleshoot safely

• Confirm only value-free state classes; never copy student or school details.
• Do not switch accounts/projects or repeatedly refresh to test cache isolation.
• Do not add/edit another record, change selection, or alter a cart to diagnose an unknown result.
• Do not infer delete availability from edit, clearing, logout, or a missing row.
• If list, selector, cart, Checkout, and order context disagree, stop and preserve the mismatch without acting on it.
• Treat allergy/dietary fields as advisory and never as medical or safety proof.

Accessibility

List loading/empty/error, student cards, Add/Edit forms, school/class/grade fields, advisory chips, selected/stale/foreign state, save busy/error/success, selector, cart assignment, no-delete boundary, and unknown outcome need clear semantic names, roles, values, consequences, focus order, and announcements.

Large text, keyboard, screen reader, modal focus, safe area, reduced motion, and Back behavior must not expose private values, close before settlement, or trigger automatic student/cart effects. These are verification requirements, not current accessibility, privacy, identity, school, or health certification.

Recertification triggers

Revalidate after changes to My Students entry/list/add/edit, customer delete, guardian/student/school authorization, list projection, cached rows/pending work, local selection, logout/account/project clearing, form save/list update, sole-student auto-selection, cart assignment/clearing, Checkout/order propagation, retention/privacy policy, advisory fields, or accessibility.

Related guides: Understand school order context · Browse a business menu · Review your cart before checkout · Review customer and delivery details · Profile and account overview · Understand privacy and consent