03 · Learner — Account & Platform

Preconditions

Signed in as a learner with a display name on the main site.

Steps

1. Open /.
2. Read the header area: greeting, eyebrow date, lead sentence.
3. Open / again after 17:00 IST (or compare morning vs evening).

Expected

• Greeting reads "Good morning" (before 12:00 IST), "Good afternoon" (12:00–16:59) or "Good evening" (from 17:00), followed by the display name — the product's clock (IST), not the device's.
• The eyebrow shows the day only, e.g. "Tuesday 6 October" — no year, no ticking clock.
• The lead reads "Pick up where you left off, or start something new."
• With an account that has no display name, the greeting is just "Good evening" — no blank space or "undefined".

Also try

• Change the device clock to a wildly different time zone and reload — the greeting still follows IST.

Preconditions

A learner with at least two unfinished items (e.g. a started challenge with a saved draft and a part-read lesson).

Steps

1. Work on item A (type a draft, let it save), then work on item B.
2. Return to / and read the Continue card.
3. Finish item B (solve/complete it). Reload Home.

Expected

• The Continue card offers the most recently touched resumable item — item B first — with what it is and when it was last worked on ("Last worked on 6 Oct 2026, 14:05 IST").
• Following it lands on that item with the saved work intact.
• Once B is completed, it leaves the card; the next most recent resumable item (A) takes its place.
• Completed and withdrawn work is never offered. An archived item the learner still holds may remain resumable — that is intended, not a bug.

Also try

• A fresh account with no resumable work: the card shows an honest empty state, not a broken or fake "continue".

Preconditions

Signed in as a learner.

Steps

1. Find the launch tiles beside the Continue card.
2. Follow each tile.

Expected

• Four ways in, each with its space's shape and a plain line: Challenges ("By topic and difficulty"), Daily Challenges ("One a day, the same for everyone"), Debug Detective ("Find the bug, fix it"), Code Lab ("Write and run code, nothing graded").
• Each lands on its page. None 404s, none requires a second sign-in.

Also try

• With Focus Mode hiding an area (set it in Settings → Your learning), its tile leaves the launch list rather than dead-ending.

Preconditions

A learner who has solved at least one thing recently; today's Daily Challenge published (showcase seed covers today±).

Steps

1. Read the Today region's three cards.
2. Follow the Daily Challenge card, then the Suggestion card.

Expected

• The Daily card shows today's challenge standing (Not started / Tried / Solved), streak facts, and leads to /daily-challenges or today's daily.
• The activity card shows the recent-activity chart — real dated activity, honest about empty days.
• The Suggestion card names one curated thing with its kind word ("Course", "Lesson", "Challenge", "Track" or "Debug case") — never a random pick dressed as advice. When there is nothing to suggest, "Tests to take" stands here instead.
• Each leads where it says.

Also try

• Complete today's Daily, reload — the card's standing changes to Solved rather than still inviting you.

Preconditions

A learner with XP and at least one earned achievement.

Steps

1. Read Your record: eyebrow, Level card, Year card, achievements card.
2. Compare the level and XP figures with /xp-history's standing.

Expected

• The eyebrow reads "Since <month year>" when the membership start is known; absent it is simply not there — never "Since —" or a made-up date.
• The Level card's level and progress match the standing XP history computes (levels follow 250×(L−1)², display cap 100).
• The Year card teases the Annual Recap and links to /recap.
• Achievements shown are real earned badges with dates ("Earned 6 Oct"), linking to /achievements — never a preview of unearned ones presented as owned.

Also try

• A brand-new account: region shows honest zeros/empty states — but an unreadable figure must never render as "0".

Preconditions

A learner with some text saved in Quick Notes → Notes.

Steps

1. Read the My Notes card in Notes and news.
2. Press "Open Quick Notes".

Expected

• The card previews the start of the saved note — the confirmed saved text only, never the Scratchpad and never words still being typed.
• "Open Quick Notes" opens the one header panel, on the Notes mode — not a page, not a new route.
• With nothing saved: "Nothing saved in Notes yet."

Also try

• Type unsaved words into Notes, do not let them save, reload Home — the card still shows only the last confirmed text.

Preconditions

A learner with ≥5 unread announcements/notices (or stage by having staff send a broadcast — see doc 05 broadcasts; coordinate in team channel).

Steps

1. Note the bell's unread count.
2. Read the Announcements card on Home; count the rows.
3. Reload Home and re-check the bell count.

Expected

• At most the four newest announcements show, read-only — there is no "mark read" control on the card.
• Reading them on Home does not lower the bell's unread count; only the Inbox/bell does that.
• Empty state is honest when there is nothing ("Nothing here yet…" style), never a fake announcement.

Also try

• Follow an announcement that has a destination — it opens the destination (and marks that notice read, as an inbox row would).

Preconditions

A learner with a started track, a saved project, a sent topic request, and (ideally) one issued certificate.

Steps

1. Read Around your learning (eyebrow "Short and current").
2. Follow each widget's "see more" link (All tracks / My Projects / Your requests / Certificates).
3. Look for any Credits widget anywhere on Home.

Expected

• Tracks in progress shows real progress "N of M solved"; Recent projects shows projects with "saved <time>"; Topic requests shows your requests with status words (Pending/Approved/Implemented/Rejected/Archived).
• Your certificate appears only once one is issued, with its code and "Issued <date>" and "Copy verification link" (or "Hidden from verification" when hidden). No certificate earned → the widget is left out entirely, not shown empty.
• No Credits card exists anywhere on Home — generated assistance is off on this deployment (see §18).

Also try

• "Copy verification link" puts a full /certificates/verify/<code> address on the clipboard and says so in a toast.

Preconditions

Browser dev tools open; signed in as a learner.

Steps

1. On Home, open dev tools → Network. Block one page-part request (e.g. add /api/v1/analytics/around or the notifications read to the request blocking list) and reload.
2. Observe the affected region versus the rest.
3. Press the region's "Try again" after unblocking.

Expected

• Only the blocked region shows "This could not be read just now." with a Try again button; the rest of Home draws normally.
• No region invents values — no fake streak, no "0" for an unread count, no cached-looking dummy.
• After unblocking, Try again fills the region with real data.

Also try

• Block the whole page read — Home says the page itself could not be read, rather than rendering half-empty regions.

Preconditions

Needs staging: an account that earned a certificate before setting a certificate name (see §6 for how certificates are earned; staff can verify in the certificates admin).

Steps

1. With no certificate awaiting a name, open Home and inspect the header actions.
2. On an account whose certificate awaits a name, open Home.
3. Follow "Set certificate name".

Expected

• No button at all when nothing waits — it is not greyed out, it is absent.
• When a certificate waits, "Set certificate name" shows as a lit action leading to /profile/settings/certificates (the Certificates section of Settings).
• After the name is saved, the action disappears on the next Home read.

Preconditions

A fresh learner who has never answered the focus question (or reset via Settings → Your learning).

Steps

1. Open Home → the Focus card asks what to concentrate on.
2. Choose a focus that hides an area (e.g. hide Assessments), save, return to Home.
3. Open "Explore more of Wizly" at the foot.

Expected

• Hidden areas leave Home completely: their cards, facts and launch tiles are gone — no dead links.
• "Explore more of Wizly" lists the hidden areas, each one tap away to its page.
• Staff never see the Focus card or Explore more — staff have no focus.

Also try

• Widen the focus back to everything — all regions return with real data, not stale placeholders.

Preconditions

Signed in as a learner.

Steps

1. Open Home at 390 px, 768 px, 1280 px and 1440 px.
2. Repeat in the other theme (Settings → Appearance) and other mode.

Expected

• Regions reflow without horizontal scroll; cards keep their order (opening → Today → Your record → Notes and news → Around your learning → Explore).
• Nothing overlaps the WizBit corner or the header; text truncates rather than overflowing.

Also try

• Zoom to 200% at 1280 px — the page reflows and stays usable.

Preconditions

A learner with mixed history: some skills with test evidence, some with only practice, some untouched.

Steps

1. Open /skills.
2. Scan the skill list end to end.

Expected

• Each skill shows either a band (Needs practice / Developing / Strong) or a plain reason there is no band — "Not enough evidence yet: N items so far, worth X of the Y points a figure needs", "Studied for … with no practice or test evidence yet", or "Nothing recorded yet."
• Nothing reads as 0%, "0 points", "F" or a made-up grade.
• An unavailable reading says it could not be read — never renders as the lowest band.

Also try

• Compare the "Not enough evidence" counts to what you actually did — items and points should reconcile.

Preconditions

Same learner as TC-SKL-001.

Steps

1. Switch the period 7 → 90 → 365 days.
2. Watch the figures and the "The last N days" line.
3. Leave Skills, come back (same browser).

Expected

• The heading line says "The last N days · worked out at <time>" — a calculated figure says when it was worked out, in plain words.
• Wider periods never show fewer counted items silently; readings change consistently (old evidence falls out of "too old" windows, short-period figures may say "Before this period").
• While a new period is read, the previous reading stays shown rather than blanking — and the page never shows period A's numbers labelled as period B.
• Reopening Skills lands on the last chosen period (kept on this device, not the account).

Also try

• Open Skills in a second browser — it defaults to 30 days there (device preference).

Preconditions

A skill with a band.

Steps

1. Press "Why this result?" on a skill.
2. Read the panel; follow a piece of evidence; close the panel.
3. Check the address bar throughout.

Expected

• A panel opens on the page (the address does not become a new route) listing the evidence behind the reading: source areas in learner words (Challenges, Tracks, Daily Challenges, "Debug Detective, timed", Mock Test, Company Test) and each item's standing — Counts / Replaced by a newer result on the same item / Too old to count now / Before this period / Set aside: its test was invalidated.
• Hidden test cases still hide — the evidence names items and standings, never hidden inputs or expected outputs.
• The panel is labelled for assistive tech ("Why this result? for <skill>").

Also try

• Open the same panel for a "Not enough evidence" skill — the shortfall is explained in items and points.

Preconditions

A skill whose older results were weak and newer results stronger (e.g. fails then passes).

Steps

1. Read the trend line on that skill.
2. Compare with a skill having one result only.

Expected

• Improving evidence reads "Improving: up N points"; worsening reads "Declining: down N points"; level evidence reads "Stable"; too little dated evidence reads "Not enough recent practice to read a trend".
• Doing ten easy solves in one day does not manufacture "Improving" — the trend compares older and newer dated evidence, not counts.

Preconditions

A learner who has finished ≥2 Mock Tests in different months and ≥2 Company Tests in the last 180 days (otherwise stage or mark N/A honestly).

Steps

1. Read the assessment-owned region on Skills.
2. Check the recent-form band and its caption.

Expected

• The Mock figure shows this month against last — Assessments' own figure, never combined with skill bands into one score.
• Company readiness and Recent form show for the company whose test the learner finished most recently in the period; recent form counts tests in the last 180 days with results halving in weight each 60 days, and needs ≥2 tests.
• Band labels: <25% At risk (danger), 25–<50% Needs work (warning), 50–<75% On track (info), 75–100% Excellent (success), captioned "N% over M tests in the last 180 days".
• Under 2 tests: "Not enough yet: N of 2 tests in the last 180 days". No company test in the period: "No Company Test finished in this period." + a way to Company Tests.

Preconditions

Any learner.

Steps

1. Open the "How your stats work" panel on Skills.
2. Read it as a learner would.

Expected

• It explains what the readings are, what counts as evidence and how periods work — in plain words, with no spec sentences, state names or implementation facts.
• It is a panel on the page, not a route; closing it returns you to the same scroll position.

Preconditions

A nearly-new account (one solve) and your regular account.

Steps

1. Read Your numbers and Practice patterns on both accounts for the same period.

Expected

• On the fresh account: honest "Nothing first solved in this period." / "No graded submissions in the last N days" style lines — never invented averages.
• Practice patterns describe your own submissions (first-try pass rate, hints used, time) — never another learner's data and never a site-wide "acceptance rate" relabelled as yours.

Preconditions

Dev tools request blocking.

Steps

1. Block the skills read (/api/v1/analytics/skills*) and open /skills.
2. Unblock and retry.

Expected

• The page says its skills could not be read and offers to try again — it does not render every skill as "Nothing recorded yet."
• On retry the real readings arrive.

Preconditions

tester-staff-1; a learner with a focus that hides an area.

Steps

1. Open /skills as staff.
2. Open it as the focused learner.

Expected

• Staff see a working Skills page (staff carry no learner evidence, so honest non-figures are expected — the page must not error).
• For the focused learner the hidden area's skills are left out and the page says the view is narrowed ("… · in your focus"); the total XP elsewhere still counts everything.

Preconditions

A learner whose activity spans an eligible year.

Steps

1. Open /recap.
2. Choose an eligible year if a chooser is offered.
3. Read the figures against your own history (XP history, achievements, calendar).

Expected

• The recap presents that year's real record — solves, streaks, awards — never a template with invented highlights.
• A year with no activity either is not offered, or shows an honest nothing rather than fake milestones.
• Every figure reconciles with the domain that owns it (XP, badges, streaks).

Preconditions

Any learner.

Steps

1. Open the year chooser.
2. Look for the current year (if mid-year) and years before membership.

Expected

• Only years the learner is eligible to look back on are offered — no empty future years, no years before the membership began presented as recap-able.
• Choosing a year re-reads the recap rather than re-labeling the same figures.

Preconditions

Two learner accounts.

Steps

1. Open /recap on account A.
2. Try to reach A's recap from account B (address manipulation) and signed out.

Expected

• There is no public recap address — /recap always shows your own; any address probing yields not-found or your own recap, never another person's.
• Signed out, the address hands off to sign-in as any member page does.

Preconditions

Dev tools request blocking.

Steps

1. Block the recap read, open /recap, unblock, retry.

Expected

• An honest "could not be read" with retry — never a recap full of zeros.

Preconditions

Signed in as a learner with history.

Steps

1. Open /profile from the account menu.
2. Compare identity, stats and activity against Account settings and XP history.

Expected

• Name/avatar and identity match the account menu; stats and activity match the owning domains' figures.
• Where offered, the link to the main-site profile goes to the person's own page on sprinklejelly.com — Labs never shows a password or billing form.
• Nothing internal leaks: no user ids, emails or session metadata dressed as profile facts.

Preconditions

A learner with ≥1 certificate (any state).

Steps

1. Read the certificate summary on Profile.
2. Follow it.

Expected

• The summary reflects the real collection (counts/names/states match /profile/certificates) and links into it.
• With none yet, an honest empty state — not "0 certificates issued" presented as a failure, and never a fake preview.

Preconditions

A learner with kept solutions.

Steps

1. Read the recent solutions list on Profile.
2. Follow one.

Expected

• Entries are the learner's own accepted work; following one lands on its /solutions/entry/… page.
• Empty for a learner with no solutions, honestly.

Preconditions

Two learner accounts.

Steps

1. On account B, try /profile, /profile/anything, and guessed identifiers for account A.

Expected

• /profile always resolves to the signed-in person; probing addresses answer not-found — the same plain not-found as any missing page, giving away nothing about whether the thing exists.
• No learner-search or public-profile surface appears anywhere in the shell.

Preconditions

Dev tools request blocking.

Steps

1. Block one profile-part read; open /profile; unblock and retry.

Expected

• The failing part says it could not be read, with retry; the rest of the page stays whole and nothing invents values.

Preconditions

Signed in as a learner.

Steps

1. Open each of the eight addresses in turn (table above).
2. Compare the h1, the section list and the index.

Expected

• Every address renders the same page, h1 "Settings", eyebrow "Your account", lead "What you can change, and where each choice applies. Every change saves on its own."
• Each addressed address opens scrolled to its section (a deep link lands you at the section, not the top).
• No address is a different page with a different h1 — there are no "Notification settings"-titled pages.

Also try

• Share a deep link into a fresh tab — it still opens at its section.

Preconditions

Open /profile/settings.

Steps

1. Press "Notifications" in the Settings index.
2. Watch the address bar and the scroll position.
3. Press "Dailies", then Back.

Expected

• Clicking an index entry scrolls the page to that section; the address bar stays /profile/settings — the index moves the page, not the route.
• Back/Forward restore the place the page left, not a scroll fight.

Preconditions

Open /profile/settings.

Steps

1. Flip one switch; immediately flip another in a different section.
2. Look for any page-wide Save/Apply button.

Expected

• Each control applies itself with its own save state (saving → saved, or an honest failure beside that control) — a second change never cancels or batches the first.
• There is no global Save, Apply, or "unsaved changes" banner: the page's word is literal.

Preconditions

Open /profile/settings/notifications.

Steps

1. Read the switches and their captions.
2. Flip one off, then on.

Expected

• Exactly seven switches: Achievements, Level ups, Daily Challenges, Streaks, Mock Tests, Company Tests, System.
• Each says what it holds, e.g. System: "Announcements from the team, course changes, topic request updates, certificate notices and progress resets made by staff."
• Changes save per-switch with their own state; an off switch means new notices in that category are not created while it is off — existing inbox items are not deleted.

Also try

• The empty-category hint in the Inbox mentions the switch: "If you have switched this category off, new notices in it are not created while it is off."

Preconditions

A learner enrolled in a course's progress, with System notifications off; a staff account to publish a course change (coordinate; may be N/A if unstagable).

Steps

1. Switch System off.
2. Have staff change the course's published content.
3. Watch the learner's inbox.

Expected

• The course-change notice still arrives — that one exclusion survives the System switch, by spec.
• Ordinary System notices (broadcasts etc.) stop being created while the switch is off.

Preconditions

A learner with an active Daily Challenge streak (solve today's first if needed).

Steps

1. Open /profile/settings/dailies.
2. Switch the Daily Challenges daily off.
3. Read the ask, confirm.
4. Check the streak on /daily-challenges.

Expected

• With a streak in place, the switch asks first — switching off ends the streak at once, and the confirm says so before you commit.
• After confirming, the streak is gone immediately (not "from tomorrow"); the daily stays open as practice, with no streak and no reminders.
• With no streak, the switch turns off without asking.
• The section's lead reads: "Each daily's streak switch. Off, a daily stays open as practice, with no streak and no reminders."

Also try

• Switch it back on — a fresh streak can start, the old count is not resurrected.
• Typing Daily has its own switch in the same section; it behaves the same way.

Preconditions

Signed in as tester-staff-1.

Steps

1. Open /profile/settings and /profile/settings/dailies.
2. Compare the section index with a learner's.

Expected

• Staff are not shown the Dailies switches or the Your learning (Focus Mode) section — both are learners' alone. The sections are absent from the index and the page, not disabled.

Preconditions

Open /profile/settings/appearance.

Steps

1. Switch theme Prism → Halo; switch mode light → dark.
2. Watch the page and header change.

Expected

• The theme swaps the whole presentation at once: Prism (daylight, dock default, spring feel) vs Halo (night-first, sidebar default, glide feel) — colours, shapes, icon artwork and section colours all change.
• Mode flips light/dark at once everywhere, including the header switch — the header's mode control and this setting share one preference.
• No reload, no flash of the old theme on next page open.

Also try

• Change mode from the header switch instead — Settings shows the same choice.

Preconditions

Open /profile/settings/appearance at ≥1024 px.

Steps

1. Switch navigation Sidebar → Dock and back.
2. Navigate between spaces in each.

Expected

• Sidebar: the rail with collapsible space groups down the side; Dock: the bottom bar; the same six spaces + Bounties appear in both, with the same destinations.
• The choice applies at once and persists across pages and sign-out (device preference).
• In Dock, a space with more than one page opens a mini popover of its pages; a one-page space (Home) goes straight there.

Preconditions

Open /profile/settings/appearance; pins changed in the sidebar.

Steps

1. In Prism: change section colours; in Halo: change the accent.
2. Check the editor/terminal palette choice.
3. Reset the sidebar pins.

Expected

• Prism offers its section colours; Halo its accent — each theme's own option shows under the right theme only.
• The editor/terminal palette applies to code surfaces (Code Lab, Workspace) — verify it changes there.
• "Reset pins" restores the sidebar's Pinned group to its default — your drag order is gone, by design.

Preconditions

Open /profile/settings/appearance.

Steps

1. Turn reduced motion on.
2. Walk Home, Skills, a challenge page; watch Halo's sky / WizBit's idle / transitions.
3. Also set the OS-level reduced-motion preference and reload with the setting off.

Expected

• Under reduced motion (setting or OS preference): every decorative animation holds still — no looping sky, no idle motion, no glide; content still works, nothing essential is conveyed by motion alone.
• The setting is honest — it is not an "animations off" that also kills functional feedback (a saved tick can still appear).

Preconditions

Open /profile/settings/companion.

Steps

1. Switch Present → Quiet.
2. Walk several pages including Home.
3. Switch back.

Expected

• Quiet removes WizBit's corner presence and its companion moments; the setting takes effect immediately without a reload.
• Quiet is a presence choice, not a feature removal — help stays reachable where the page offers it; the corner simply stops showing up.
• Switching back restores the corner.

Preconditions

Open /profile/settings/companion.

Steps

1. Switch presentation Companion → Plain and back.
2. Rename WizBit to a custom name; open the help panel from the corner.
3. Reset the name.

Expected

• Plain swaps the companion's characterful presentation for a plain helper style — the same help, the same answers, only dressed differently (parity, not fewer features).
• The chosen name appears wherever the companion speaks or is named ("Ask <name> about …").
• Reset returns it to "WizBit" everywhere.

Preconditions

Open /profile/settings/companion; a low-level and a higher-level account if possible.

Steps

1. Open the dress-up choices (skin, decals, chest, lights).
2. Equip an unlocked look; try a level-locked one.
3. Replay the first-run orientation.

Expected

• Unlocked looks apply at once to the corner companion; locked looks are marked with what they need (a level), never silently dead or secretly equipable.
• "Replay orientation" runs the first-run introduction again on demand — the same one Home shows a new learner.

Preconditions

Open /profile/settings/certificates on an account whose name is not yet locked (no certificate made).

Steps

1. Try names that break each rule: test lowercase is fine; try A alone (too short), digits/symbols (Name123!), a web address (name.com), a name with no letters, and a 101-character name.
2. Watch the "Printed as" preview and error text.
3. Save a valid name.

Expected

• Rules: letters A–Z with spaces, apostrophes, hyphens and full stops; 2–100 characters; must contain a letter; no web address. The field's hint says exactly that.
• Invalid names show their specific error and "Save name" does not send; a valid name shows "Printed as <name>" before saving.
• Saving a valid name confirms "Saved." — and if certificates were waiting, "Saved. Your certificate is being prepared." / "Your N certificates are being prepared."

Also try

• Extra spaces and mixed case are tidied in the preview — check the printed form, not just the typed one.

Preconditions

An account with ≥1 certificate awaiting a name (staff may need to award one — coordinate; otherwise N/A).

Steps

1. Enter a valid name and press "Save name".
2. Read the confirm: "Print your certificates with this name?" → confirm "Save and prepare".
3. Return to the section after certificates generate.

Expected

• With waiting certificates the save asks first; the dialog names the printed name and warns the name locks once the first certificate is made.
• Confirming releases the waiting certificates into generation.
• After a certificate is made, the name shows as locked ("It is locked, because a certificate was made with it.") — editable no more; only a correction staff approve can change it.

Preconditions

Open /profile/settings/certificates.

Steps

1. Find the collection-visibility setting; change it; save.
2. Check its effect where it claims one (e.g. what the collection shows).

Expected

• The setting saves independently and says in plain words what it changes — visibility of the collection as shown to you/on your pages; it never claims to unpublish a certificate's public verification (hiding a certificate is per-certificate, §6).

Preconditions

Open /profile/settings/account (scroll to it — it reads when reached).

Steps

1. Read every fact shown: identity, email, role, membership, session.
2. Look for any edit field, password form, or billing control.

Expected

• Facts match the main site: display name, email, Labs role in plain words, membership level and end date as the main site supplies it ("Active when last checked, <time>" or an honest "It can't be checked just now.").
• No password field, no email edit, no billing form, no role editor — each points to the main site where the owner acts ("From the main site").
• Session facts (e.g. the current sign-in) are described, not editable.

Also try

• A lapsed-but-signed-in check is out of scope here; for the lapsed account see §19's privacy-only session cases.

Preconditions

Open /profile/settings/data-privacy; have device data present (a saved note, Code Lab draft, chosen filters).

Steps

1. Read what the page says this browser keeps.
2. Follow each policy link.

Expected

• It honestly lists what this browser/device holds (drafts, Code Lab, Tools state, project recovery copies, Scratchpad) and what clears at sign-out — matching Data and Privacy's rules.
• Policy links go to the main site's real policy pages — no 404s, no placeholder "#" links.
• Erasing account data is presented as the serious action it is, separate from device data.

Preconditions

A throwaway learner account if you intend to let it run — otherwise request then CANCEL within the window (safe, leaves no erasure). Requires a fresh main-site check (≤15 min): if your sign-in is old, expect the "Confirm on the main site" trip first.

Steps

1. Open /profile/settings/data-privacy → the erasure part.
2. Read what erasure removes (it names the record it deletes — on this deployment "XP and preferences" style wording, since Credits are off).
3. Type the required confirmation and send the request.
4. Read the status; cancel within the seven-day window.
5. Check status again.

Expected

• Requesting asks for explicit typed confirmation and a recently-checked main-site verification; a stale check offers "Confirm on the main site" and returns with your input held.
• Once sent, status shows the request live, with the seven-day cancellation window made plain.
• Cancelling stops it and the status reflects that — the request did not silently proceed.
• Throughout, wording is honest: erasure deletes learning records (XP, preferences, etc.) — it never pretends to keep or to delete more than it does.

Also try

• Sign in elsewhere after requesting — the pending request and its status follow the account.

Preconditions

A learner with certificates in ≥2 states (e.g. one issued, one awaiting name).

Steps

1. Open /profile/certificates.
2. Read each row's name, state word and what it offers.

Expected

• Each certificate shows what it was awarded for and its state word ("Waiting for your name" / "Being prepared" / "Not made yet" / "Issued" / "Revoked") with the matching tone.
• An empty collection is an honest empty state, never dummy certificates.

Preconditions

A certificate in "Waiting for your name" state (name not yet locked).

Steps

1. Open the certificate's entry; it says what it needs.
2. Set the certificate name (Settings → Certificates) and confirm.
3. Return to the collection and watch the state.

Expected

• The entry explains: "Set the name to print on it, and it will be prepared." — not a dead end.
• Saving the name releases the waiting certificate(s): the state moves to "Being prepared", then "Issued" within a few minutes (poll by reloading — do not expect a toast).
• Once any certificate is made, the name locks (TC-SET-016).

Preconditions

Hard to stage deliberately — mark N/A unless a generation genuinely fails. Staff can confirm in certificates admin.

Steps

1. If a certificate shows "Not made yet", open its entry.

Expected

• The wording blames the platform, not the learner: "Your certificate could not be made yet. This is a problem on our side, not anything you did, and the certificate is not lost: staff can make it again."
• The certificate is not deleted, not marked revoked, not silently retried forever.

Preconditions

An issued certificate.

Steps

1. Open /profile/certificates/:id/detail from the collection.
2. Read "The certificate", "Its details", and "Sharing it".
3. Press Download.

Expected

• On a computer the PDF renders in the page in a frame; on a touch device the button reads "Open the certificate (PDF)" and opens it in a new tab.
• "Its details" lists Printed name, Awarded for (linked to the content when it still opens), Completed, Issued, Code (mono), Status — all true.
• Download produces the real PDF with the printed name and code — text in the PDF, not an image of the page.
• A certificate still awaiting name or being prepared redirects /detail back to its entry page.

Also try

• The printed document's own layout matches the certificate — the name on it is the locked printed name, not your account name if they differ.

Preconditions

An issued certificate; a second browser or device signed OUT for the public check.

Steps

1. In "Sharing it", press "Hide it from the public check"; read the confirm ("Hide this certificate from verification?") and confirm "Hide it".
2. In the signed-out browser, open the certificate's verify address.
3. Back on the owner's detail page: confirm "Sharing it" now says hidden; press "Show it again".
4. Check the public verify address again.

Expected

• Hiding asks first and explains: "Anyone who checks its code, or scans the QR code on a copy you shared, is told no certificate can be verified, until you show it again. It stays valid, and you can still download it."
• While hidden, the public check answers "No certificate can be verified for this code" — the same words as an unknown code (deliberately indistinguishable).
• The certificate remains issued and downloadable — hiding never invalidates.
• "Show it again" restores verification without a confirm (hiding is the consequential one).

Preconditions

An issued, unhidden certificate.

Steps

1. In "Sharing it", press "Copy the verification link" — paste it somewhere.
2. Press "Open the verification page".

Expected

• The clipboard holds a full https://app.sprinklejelly.com/certificates/verify/<code> address; a toast confirms the copy.
• "Open the verification page" goes to the same public address — which answers valid while signed in or out (it is public).

Preconditions

A revoked certificate (staff-side revoke — coordinate in team channel; otherwise N/A).

Steps

1. Open the revoked certificate's detail.
2. Try its public verify address signed out.

Expected

• Detail shows the danger note "This certificate has been revoked and is no longer valid." and "Sharing it" says "Its check now says it is not valid, and it can no longer be downloaded." — no Download button.
• Public verify answers "This certificate is not valid" — "…was issued by Wizly Learning and is no longer valid." Old printed PDFs cannot be recalled, so the check is the source of truth.

Preconditions

A completed subject whose certificate already exists (or re-completing after archive/re-publish — coordinate).

Steps

1. Re-complete the awarding action for a subject you already hold a certificate for.
2. Check the collection.

Expected

• No duplicate: the same certificate is returned/kept — the collection gains nothing.

Preconditions

An account whose certificate name is locked (any issued certificate).

Steps

1. Settings → Certificates → "Propose a correction".
2. Send a corrected name with a reason.
3. While it waits: replace it, then cancel it.

Expected

• The correction form asks for the corrected name (same print rules) and "Why it needs correcting" — reason required; "Staff approve the name exactly as written, or say why not. No documents are asked for. Issued certificates keep the old name until staff reissue them."
• While pending it reads "Waiting for staff: <name>" with your reason, and offers "Cancel it" and "Replace it" — one proposal at a time.
• Cancel removes it; replace swaps the proposal, not a second request.

Preconditions

Two browsers: learner with a pending correction; a Super Admin (coordinate — owner accounts only) who can approve/reject and reissue.

Steps

1. Learner sends a correction.
2. Super Admin rejects it with a reason → learner sees "Your correction to “<name>” was not approved, on <date>: <reason>".
3. Send another; Super Admin approves → learner sees the approval note.
4. Super Admin explicitly reissues the certificate; learner checks the collection and public verify.

Expected

• Rejection and approval both surface to the learner in the section with the date and reason.
• Approval alone does not retcon issued certificates — the explicit reissue does; until then issued PDFs keep the old name.
• If the reissue fails, nothing reverses: the old issued certificate stays valid and verifiable — corrections never half-apply.

Preconditions

A signed-out (or private) browser.

Steps

1. Open https://app.sprinklejelly.com/certificates/verify signed out.
2. Note the page furniture.

Expected

• The page opens with no sign-in demand and no learner shell — a standalone page titled "Check a certificate": "Enter the code printed on a Wizly Learning certificate to see whether it is valid."
• No inbox, no navigation into member pages, nothing learner-private.

Preconditions

A real unhidden certificate code (copy it from TC-CRT-006).

Steps

1. Signed out, open /certificates/verify/<code> (or type it and press Check).
2. Read the answer panel.

Expected

• Title "This certificate is valid" with a Valid status; rows: Certificate (the code, mono), Name (printed name), Awarded for, Issued — then "Checked <date time>." in small text and the assurance line.
• Nothing else: no email, no score/percentage, no account name beyond the printed name, no staff reason, no history.
• The address itself carries the code — the answer is the same whether typed or addressed.

Preconditions

A hidden certificate's code (TC-CRT-005) plus invented codes.

Steps

1. Check: (a) the hidden code, (b) WZ-AAAA-BBBB-CCCC invented, (c) a malformed string, (d) an address with an over-long identifier.
2. Compare every answer word for word.

Expected

• All four answer identically: title "No certificate can be verified for this code" — "Check the code for mistakes. A certificate its owner has hidden cannot be verified either." plus "Checked <date time>."
• An identifier too long for the address also gets the unknown answer — never an error page, never a hint that the length itself failed.
• Nothing distinguishes "exists but hidden" from "never existed".

Preconditions

The verify page, signed out.

Steps

1. Type a valid code in lowercase → Check.
2. Type past 40 characters (the field caps); try an empty Check.
3. Note the placeholder.

Expected

• Codes are case-normalized — lowercase finds the certificate; the field auto-capitalizes and its placeholder reads WZ-XXXX-XXXX-XXXX.
• The field allows at most 40 characters.
• Check with nothing typed asks for it: "Type the code printed on the certificate." — no check is run on an empty code.

Also try

• Extra spaces around a pasted code are tidied before the check.

Preconditions

Dev tools request blocking, or genuinely hit the pace limit by checking repeatedly fast.

Steps

1. Block the verification api, check a valid code.
2. Unblock; hammer Check repeatedly to trigger throttling (or accept an organic failure).

Expected

• A failed check answers "Its validity can't be confirmed right now" with a "Check again" button — never "not valid", never the unknown-code wording.
• Throttled answers "Checking is paused for a moment" with Check again — again never mistaken for invalid.
• "Check again" actually re-runs the check; a successful retry shows the proper answer.

Preconditions

A valid code; a screen reader if available.

Steps

1. Check the same code twice in a row.
2. Have the answer region read out.

Expected

• Every Check asks afresh (no cached-forever answer), including re-checking the identical code.
• The answer region is aria-live="polite" — a screen reader announces the result when it lands.

Preconditions

Accounts with 0, some, and (if stageable) >99 unread notices.

Steps

1. Read the bell on each account.
2. Mark all read; watch the badge.

Expected

• Badge shows the exact unread count (Indian grouping if ever relevant); above 99 it reads "99+".
• At a confirmed zero the badge is gone entirely — not a grey "0".
• The button's accessible name carries the truth too: "Notifications. N unread." / "Notifications. Nothing unread." / "Notifications. Unread count unavailable right now."

Preconditions

Dev tools: block the unread-count read.

Steps

1. Block the unread read and reload any page.
2. Look at the bell.

Expected

• The badge shows a small hollow mark (amber-ringed dot) — not "0", not a guessed number; the button's name says the count is unavailable.
• Inside the panel: "The unread count could not be read just now." — while the notice list itself still loads honestly or says its own failure.

Preconditions

≥7 unread notices across ≥2 categories.

Steps

1. Open the bell. Count the rows.
2. Note the unread count, close the panel, check the badge again.
3. Switch the panel's All/category filter.

Expected

• At most the six newest show in the panel; "Open inbox" leads to the full list.
• Merely opening the panel marks nothing read — the badge is unchanged after closing.
• Category filtering works in the panel with per-category unread counts where shown.
• Focus lands on the newest notice row (or the panel's h2 when empty) — never on "Mark whole inbox read".

Preconditions

Several unread notices.

Steps

1. Open the bell → "Mark whole inbox read".
2. While the toast shows, press Undo.
3. Repeat and let the toast expire instead.

Expected

• The panel steps aside so the toast is reachable; the toast ("Every notice is marked as read") offers Undo for ~6 s.
• Undo restores the unread standings — the change is sent only when the Undo ends.
• With zero unread, "Mark whole inbox read" is disabled rather than doing a fake pass.

Preconditions

An unread notice that has a destination (e.g. an achievement → /achievements).

Steps

1. Open it from the bell panel.
2. Check the badge and the row's read standing.

Expected

• You land on the notice's valid internal destination — never an external site, never a raw api address.
• That one notice is now read: the badge drops by one, the row loses its unread mark.
• A notice with no destination opens in full (a sheet) rather than going nowhere.

Preconditions

>20 notices (use an older account or staff-seeded broadcast; N/A honestly if impossible).

Steps

1. Open /inbox; read the group headings and first rows.
2. Press "Load more".

Expected

• Notices group under Today, This week and Earlier; newest first within each, with plain times ("Today, 09:00" style, IST).
• Pages of 20; "Load more" appends without losing your place or re-showing rows.
• The foot notes retention: "Notices are kept for 90 days." (aging is real — expired items are gone, not greyed.)

Preconditions

Several notices, mixed read standing.

Steps

1. Row ⋯ → mark a read notice unread; verify the badge rises.
2. Mark it read again.
3. ⋯ → Delete; press Undo on the toast; delete again and let it send.

Expected

• Mark read/unread toggles the row's standing and the badge at once.
• Delete removes the row immediately with an Undo toast ("Notice deleted"); Undo restores the row where it was.
• Once the toast ends the delete is sent — after it, the notice is gone for good (its source — the award or result — is untouched).
• When a row leaves, focus lands on the next row's opener or ⋯ (or the page h1 if none) — never lost to the body.

Preconditions

Unread notices in ≥2 categories.

Steps

1. Filter the inbox to one category (e.g. Achievements).
2. "Mark all Achievements read" → let the toast send.
3. Check other categories and the address bar.

Expected

• The toast scopes itself: "Every Achievements notice is marked as read — Only Achievements; the other categories stay as they are." Other categories' unread stand.
• The chosen category lives in the address (so a filtered view is shareable/bookmarkable) and is remembered on this browser.
• An empty category says "No Achievements notices." plus the switch hint when relevant.

Preconditions

A populated inbox (a relief-grant notice would be staff-staged — N/A if none).

Steps

1. Inbox → Clear (all, or within a filtered category).
2. Read the confirm: "Delete every notice?" / "Delete every <category> notice?"
3. Confirm; read the outcome toast.

Expected

• The confirm spells out it deletes every notice including any not on this page — and that no award or result is taken back.
• The result toast tells the truth: "Deleted N notices." / "There was nothing to delete."
• Notices kept for a live relief grant survive and say why: "Kept until it ages out: it tells you about a relief grant you hold." (On this deployment relief grants belong to Mock Tests — see doc 02.)

Preconditions

Trigger a repeatable event (e.g. re-open the same achievement's moment, or a staff re-send of a broadcast — coordinate).

Steps

1. Trigger the same logical event twice (reload the earning page, re-finish the action).
2. Count the inbox items for it.

Expected

• One notice per event — replaying the moment or duplicating a tab never creates a second.

Preconditions

Two conditions you can stage: keep the learner's browser closed/offline while an event happens (e.g. staff broadcasts to all learners — coordinate in team channel).

Steps

1. Sign out / close the learner's tab.
2. Have the event fire.
3. Sign back in and open the inbox.

Expected

• The notice is waiting — delivery is not "live only"; anything missed while away arrives on the next visit.
• It shows its real time, not "just now" if it is old.

Preconditions

A notice announcing something real (achievement unlocked, result corrected).

Steps

1. Delete the notice.
2. Open the thing it announced (achievements page, test result).

Expected

• The award/result stands untouched — the inbox is a copy of news, not the record. A notice that could not be delivered never reverses the action it described.

Preconditions

A fresh account; dev tools to block the inbox read.

Steps

1. Open /inbox on the fresh account.
2. Block the inbox read on yours and open it.

Expected

• Empty: "Your inbox is empty." + "When something happens elsewhere — an achievement, a new level, a test result, a course update — the notice arrives here and stays for 90 days."
• Blocked: an honest "could not be read" with retry — never the empty state pretending.

Preconditions

tester-staff-1.

Steps

1. As staff, look for any console screen listing a learner's inbox/notices.
2. Check staff's own inbox — they hold one only for their own events.

Expected

• No staff surface browses a learner's inbox — notices are the person's own. (Broadcast composition in doc 05 is sending, not reading inboxes.)
• Broadcasts exclude staff accounts: staff do not receive learner-targeted broadcasts in their own inbox.

Preconditions

Any learner.

Steps

1. Trigger a notice; check the account's real mailbox and the OS for push prompts.
2. Look for notification-channel settings beyond the seven switches.

Expected

• Nothing leaves the product: no email, no browser-push prompt, no "email me" option in Settings — in-app is the design, not a gap.

Preconditions

A learner with ≥1 earned and ≥1 unearned badge.

Steps

1. Open /achievements; switch All → Earned → Not earned yet.
2. Leave and return (same browser); try a second browser.

Expected

• All shows the whole catalogue; Earned lists the newest earned first with "Earned <date>"; Not earned yet hides the earned.
• The last view is restored on return (device preference) — a different browser defaults to All.
• Empty earned view: "Nothing earned yet." + how badges unlock — never fake badges.
• Every badge earned: "Every badge in the catalogue is already earned."

Preconditions

A learner one step from a badge (e.g. first Mock completion pending).

Steps

1. Note the badge unearned; complete the requirement (finish the Mock).
2. Watch for the unlock; re-do the action.

Expected

• The badge unlocks by itself — typically announced by an earned-tone toast/moment; there is no Claim button anywhere.
• Unlocking happens once: repeating the requirement never produces a second badge or a second toast.
• A requirement line says in plain words what it takes ("A Daily streak of 100 days").

Preconditions

A learner part-way to ≥3 badges (e.g. 12-day streak toward 100, lessons toward a subject badge, a best Mock score).

Steps

1. Open the Closest to unlocking view.
2. Read each card's progress line against your real record.

Expected

• At most three badges, ordered by how much of each requirement is done — and only ones you have actually begun.
• Progress is exact: "12 of 100 days", "3 of 8 lessons", "Best 81.5% · needs 90%", "32 of 40 WPM" — matching the true record.
• No qualifying figure yet says so ("No Mock Test completed yet") rather than "0%".
• An unreadable progress says "Progress could not be read just now." — never a guessed bar.

Preconditions

An earned badge; (for the second half) a staff-invalidated test that had paid a badge — coordinate, else N/A.

Steps

1. Have staff reset some unrelated progress (or just observe over time).
2. Check the badge stays.
3. For invalidation: check the badge's card and XP history after a test is invalidated.

Expected

• Badges survive time, progress resets and content updates — the page says so: "Achievements stay earned through time passing, progress resets and content updates."
• When the fact behind one is invalidated, the correction stays visible (e.g. "Taken back with an invalidated test. The next Mock Test that meets the requirement pays +300 XP.") — the record never quietly disappears.

Preconditions

Any learner.

Steps

1. Scan the catalogue's family groupings and the "Completion badges" group.

Expected

• Families read: Mock Tests, Daily streak, Projects, Written subjects, Video subjects, Tracks, Typing Quest — learner words, no internal keys.
• Completion badges explain themselves: "One for each written subject you complete." / video subject / Track.
• "Recognition only" is marked on badges that are just that.

Preconditions

A learner who has not started a particular published subject/track; another who has.

Steps

1. Compare the completion-badge lists of both accounts.

Expected

• The second account's catalogue includes that subject's/track's badge; the first's does not (or does so per spec) — "the total grows as you take on more", so catalogue size differing between learners is correct, not a bug.

Preconditions

A learner about to finish a first Company Test.

Steps

1. Finish a Company Test.
2. Check achievements and inbox.

Expected

• No badge and no badge progress from the Company Test — on this deployment Company Tests earn "no XP or achievements" (the XP page's own note says it; see §9).

Preconditions

A learner with several awards of different kinds.

Steps

1. Open /xp-history.
2. Read the top entries: sign, area, what it was for, when.

Expected

• Entries are newest first, signed (+30 XP style; reversals negative), each naming the area (Challenges, Tracks, Daily Challenges, Debug Detective, Courses, Mock Tests, Workspace Projects, Typing Quest) and what it was for.
• Fresh account: "No entries yet." + "Your first XP comes with your first accepted solve."

Preconditions

An unsolved easy challenge ("Running Total of Marks") and an unsolved medium.

Steps

1. Solve the easy challenge → check the ledger's new entry.
2. Solve the medium.
3. Re-solve the easy challenge in another language.
4. Solve a challenge that also sits in a track, then solve it via the track.

Expected

• Easy pays +30, medium +60, hard +100, extreme +150 — the entry matches the difficulty paid.
• Re-solving the same owned item in any language pays nothing more.
• The standalone challenge and its track twin are different owned items — each pays its own first-accept.

Preconditions

A learner with awards.

Steps

1. Read the standing (Total XP, level, progress to next).
2. Sum the ledger entries and compare.
3. Read the "What pays XP" part.

Expected

• The total equals the sum of the entries — including reversals and corrections.
• "Level N begins at <X> XP." matches 250×(N−1)²; above level 100 the page still says "Levels are shown up to 100; XP keeps counting."
• "What pays XP" lists the real rates and the honest exclusions: "Lessons, quizzes, video subjects, Track completion, projects, Code Lab runs, hints, notes, typing tests and drills, and time spent pay nothing. Company Tests earn no XP or achievements. Re-solving something you have already solved pays nothing more, in any language." (On this deployment, no mention of Credits.)
• The note "These are the rates in force now. An award keeps the rate it was paid at; a later change reaches later awards only."

Preconditions

A learner who has not yet finished a Mock, completed a written subject, or done a Typing Daily.

Steps

1. Finish a first Mock (fail or pass) → check entries.
2. Pass a first Mock → check.
3. Complete a written subject; do today's Typing Daily.

Expected

• First Mock completed pays +200; first Mock passed pays +300 — each once, to their own entries.
• Completing a written subject pays +250; a Typing Daily pays +20 for its date (once per product date).
• Daily Challenge bonus lands within its documented 0–200 band.

Preconditions

A staff-invalidated test that had paid XP, or a staff correction — coordinate, else N/A.

Steps

1. After the invalidation/correction, read the ledger.

Expected

• A reversal appears as its own entry marked "Taken back by a later reversal" — the original award is not deleted or edited in place.
• A correction carries "Why: <reason>" and "Reference: <ref>" — a learner can tell what happened without staff lore.

Preconditions

A learner with a focus that hides an XP-earning area.

Steps

1. Open /xp-history under that focus.

Expected

• A line above the history says which areas' XP is left out and that "Your total and level count everything." — the ledger is filtered, the standing is not.

Preconditions

An account with a large XP total (or note as a review point); dev tools.

Steps

1. Read any figure ≥1,00,000 (or the largest available) — check grouping.
2. Block the ledger read; open the page.

Expected

• Large figures group the Indian way (12,34,567), and times read IST.
• A failed read says the history could not be read — never "Total XP: 0".

Preconditions

A learner with ≥1 request; another with none.

Steps

1. Open /requests on both.

Expected

• Lead: "What you've asked the content team for, newest first. Requests are suggestions, not promises."
• Each row: your title, where it was asked from, "sent <date>", and its standing word — Pending / Approved / Implemented / Rejected / Archived.
• Empty: "Nothing requested yet" — "Where a course, a practice topic or a template is missing, the page it's missing from offers a way to ask for it."
• Only your own requests — never another learner's.

Preconditions

Open the challenge catalogue; search for something absent (e.g. "quantum flux").

Steps

1. Search the catalogue for a term with no results → press the request offer.
2. Read the dialog: title, description, "Sent with your request" context rows.
3. Cancel; then open the dialog from a course subject page instead.

Expected

• The catalogue's empty result offers "Request a topic"; the dialog's title starts from your search (first letter capitalised) until you type your own.
• "Sent with your request" lists what goes with it — Asked from, About/Topic/Difficulty, "You searched for …" — or "Nothing else goes with it: only your title and description." when there is none.
• From a subject page the button says "Request a course"; on a lesson the heading reads "Ask for more on this lesson".
• A footer note: "For a problem with your account or with Wizly Learning itself, use the contact page on the main site instead."

Preconditions

The request dialog open.

Steps

1. Type a 121+ char title — watch the counter turn danger.
2. Paste a >2000-char description.
3. Try to send empty fields.

Expected

• Title shows a live "N / 120" count that warns past the limit; description holds ≤2000. Send refuses invalid fields with per-field errors — nothing is silently truncated.
• Hint text: title "What's missing, in a few words."; description "What you'd like to learn or practise, and why it would help."

Preconditions

The dialog open.

Steps

1. Send a real request ("QA-<initials> <date> — <topic>").
2. Send the same titled request again from the same place.
3. Send several quickly to find the daily cap (if reachable).

Expected

• Success reads "Your request has arrived." — "The content team will see it. Follow where it stands in Topic Requests; arriving is not a promise that it will be made." The row lands on /requests as Pending.
• The same open request again answers "You already asked for this here, and that request is still open." — "A differently titled request is welcome." It is not double-filed.
• At the daily cap the form says to "Try again shortly." — never a fake success.
• Failure keeps your words: "It could not be sent. Your words are still here; try again."

Preconditions

A Pending request of yours.

Steps

1. On /requests, press Retract on the pending row.
2. Read the ask: "Retract this request? Retracting is final. You can send a new request later."
3. Confirm Retract (or "Keep it" first to verify cancel works).

Expected

• Retract appears only while Pending (a decided request cannot be retracted — verify on an approved/rejected one if you have it).
• "Keep it" abandons; "Retract" archives at once — the standing reads Archived and the ask was honest that it is final.
• Retracting never deletes the request's record or pretends it was never sent.

Preconditions

Requests staff have approved/rejected/implemented (coordinate via doc 05 review page, or N/A).

Steps

1. Read the rows: decided ones show when the decision landed.
2. On an Implemented row, follow "Open content".
3. Check the inbox for the implemented notice.

Expected

• Approved/Rejected/Implemented rows show when that happened.
• "Open content" goes to the fulfilling content; if it was archived since: "The content that answered this request can no longer be opened."
• Implementation notifies the asker in-app.

Preconditions

A sent request.

Steps

1. Look for any way to edit the title/description of a sent request (row, dialog, address probing).

Expected

• None exists — the sent text stands as sent; the only actions are Retract (pending) and opening linked content. Staff edits happen in the console review, never silently on your row.

Preconditions

>20 requests (unlikely — N/A honestly) plus Home.

Steps

1. Open /requests; Load more.
2. Compare Home's "Topic requests" widget rows.

Expected

• 20 per page + Load more, no duplicates, no lost place.
• Home's widget shows the same newest few with matching standings and links "Your requests".

Preconditions

A request flow where linked content applies (staff link content during review; the learner side reads them).

Steps

1. On an implemented/approved request, read the linked items.
2. Try opening each.

Expected

• Links go to pages a learner can really open — never staff previews or drafts; at most five items anywhere they're listed.

Preconditions

Signed in as a learner.

Steps

1. Press the Quick Notes header button (or Ctrl+Alt+N).
2. Type in Notes; navigate to another page with the panel open.

Expected

• The panel opens over the page — the address never changes, there is no /notes route (an address probed for one is not-found).
• Navigating keeps the panel and its text — it is one shell-level panel, not a per-page widget.
• It can be minimised/restored and moved (arrow keys on its move control: "Move Quick Notes. Use the arrow keys.").

Preconditions

Two tabs on the same account/browser.

Steps

1. Type "scratch-123" in Scratchpad in tab A; open the panel in tab B.
2. Type "note-456" in Notes in tab A; wait for its save state; check tab B.
3. Close tab A entirely; reopen the product in a new tab.

Expected

• Scratchpad in tab B does not contain "scratch-123" — it is this tab's own, and says so: "Temporary. Kept in this tab until you close it or sign out, and never saved to your account."
• Notes' "note-456" appears in tab B once saved — it persists to the account.
• After closing the tab, the Scratchpad text is gone for good; the Note remains.

Preconditions

Panel open in Notes; dev tools for going offline.

Steps

1. Type and pause: watch "Saving…" → "Saved just now".
2. Go offline (dev tools → Network → Offline), type more.
3. Come back online; watch the recovery.

Expected

• Saving shows "Saving…" then "Saved just now" (then ages: "Saved N minutes ago", "Saved <date>").
• Offline writes read "Saved locally. Trying to save again…" (kept on this device) or "Work at risk: not saved, and not kept on this device. Trying again…" — the two are never blurred; locally-kept text is never described as saved to the account.
• Retry is pressable when it stalls ("Saved locally · Not saved, tap to retry").
• Back online it lands and says Saved — the panel's word is the truth.

Preconditions

A live test in progress (see doc 02) or N/A; a maintenance window if scheduled; a second browser to end the session.

Steps

1. During a live test, look for the Quick Notes button/panel.
2. During a maintenance window, check the panel's state.
3. End the session from another browser; return to this tab's panel.

Expected

• During a live test: "Quick Notes is closed while your test is running." — nothing of either mode is readable or writable.
• Maintenance: "Read only while maintenance is under way." — your text shows but cannot be changed; "Your latest words are saved locally and are saved once it ends."
• After the session ends: "Signed out, so nothing more is saved here." (or "Someone else signed in on this browser, so nothing more is saved here.") — and locally-kept words "come back when you sign in again."

Preconditions

Learner A with a saved note; staff account B.

Steps

1. As staff B, hunt the console for any way to read A's note.
2. Read the panel's own words about privacy.

Expected

• The panel declares "Only you can see these" / "Only you can see your notes." — and it is true: no staff surface can read learner notes (both staff roles are barred by spec).
• Home's My Notes card also only ever shows the owner's own note.

Preconditions

Panel open; a second tab/device for conflicts.

Steps

1. Paste a text far past the note's character limit.
2. In tab B edit the note while tab A holds an older copy, then type in A.

Expected

• Overflow says so: "That didn't fit: notes hold up to N characters." / "N characters were left out: notes hold up to M." — near the limit it warns "Approaching the limit".
• A cross-device conflict reads "A newer version was saved in another tab or device. Your next edit here will replace it." — one tab's save never silently erases another's.
• An unkeepable character: "Not saved: your notes hold a character they cannot keep."

Preconditions

Dev tools to block the note read; pages where the panel is suppressed.

Steps

1. Block the note read, open the panel → "Couldn't load your notes." + Retry.
2. Look for the button on suppressed pages (sign-in pages, live-test room, staff console).

Expected

• Load failure is honest with a Retry — never an empty note that then overwrites your real one.
• The button is absent where Quick Notes stays out of the way (test room, staff console, sign-in pages).

Preconditions

A tab with Scratchpad text and a saved Note; a way to end the session (main-site sign-out or second browser).

Steps

1. End the session; reopen the product signed in again on this browser.
2. Open the panel.

Expected

• The Scratchpad is gone (sign-out clears it, by spec); the saved Note returns from the account; locally-kept unconfirmed note text may return per "Your words are saved locally and come back when you sign in again."

Preconditions

Keyboard only.

Steps

1. Ctrl+Alt+N opens; tab through the panel's controls (mode switch, textarea, minimise, move, close).
2. Close it and check where focus lands.

Expected

• The shortcut works outside text fields; the panel is fully operable by keyboard; closing returns focus sensibly (to the header button).
• The mode switch labels itself ("Notes or Scratchpad").

Preconditions

Learner with WizBit Present.

Steps

1. Open Home, a challenge page, Code Lab, the catalogue.
2. Watch the corner on load and while scrolling — does anything open itself?
3. Measure its footprint roughly; check it never covers a control or content.

Expected

• The corner sits bottom-right: ~64 px on ordinary pages, ~48 px at phone width, ~44 px on quiet pages (solving, Code Lab, Workspace, paper practice).
• Nothing opens, pops or slides out uninvited — the panel opens only when you press the corner.
• It never blocks a button, a scroll area's end, or typed text; at phone width it does not collide with the dock.

Preconditions

A live test (doc 02), tester-staff-1, a signed-out view of /handoff and /certificates/verify.

Steps

1. Look for the corner in the test room; in the staff console; on standalone pages.

Expected

• Absent from the test room (a live test suppresses it entirely), the staff console, /handoff, /restricted, /unavailable, /not-found and /certificates/verify.

Preconditions

On a page with an authored guide (most pages have one).

Steps

1. Press the corner → "Guide to this page".
2. Step through; navigate to another page mid-guide; reopen; press Done then restart.

Expected

• The guide walks the page's own steps in order — real steps about this page, not a generic tour.
• Navigating resets the guide (a new page, a new guide — it does not resume the old one on the wrong page).
• After Done, the guide can be restarted from the top.

Preconditions

The help panel open on a content page.

Steps

1. Press a suggested chip; read the answer.
2. Type a product question ("how do mock tests work?", "what is a streak?").
3. Ask something the KB cannot know.

Expected

• Suggested chips match the page (not on hidden-area pages); each answers with the authored entry.
• Typed questions are answered from the authored knowledge base — clear, product-true answers with generated assistance off: authored guidance works, nothing claims to "think".
• Unanswerable questions get an honest "I don't know"/point to the right place — never a hallucinated feature.
• An answer about a coming-soon feature is marked "Coming soon" rather than described as live.

Preconditions

A learner; note the inbox count.

Steps

1. Use the panel: guides, questions, chips — every interaction.
2. Check the bell and inbox afterwards.

Expected

• Zero notices created — companion moments are on the page only and never land in the inbox or on the badge.

Preconditions

Settings → Companion.

Steps

1. Set Quiet: walk pages — the corner is gone; help entry points that the page itself offers still work where spec'd.
2. Set Plain: compare the panel's content with Companion mode on the same page.

Expected

• Quiet removes the corner and companion moments on every learner page.
• Plain shows the same guide steps, chips and answers in plain presentation — parity of function, only dressed differently.

Preconditions

A fresh learner (never seen orientation) and your account.

Steps

1. Fresh account: open Home → orientation introduces WizBit.
2. Dismiss it; reload — it does not nag again.
3. Your account: Settings → Companion → replay orientation.

Expected

• The first-run orientation shows once for a new learner on Home, and not again after being done/dismissed.
• Replay runs the same orientation on demand.

Preconditions

Phone viewport (390 px) and computer.

Steps

1. Open the panel at 390 px — it presents as a bottom sheet; dismiss by drag or close control.
2. On computer: keyboard-open the panel, escape, check focus return.

Expected

• Phone: a bottom sheet, dismissible by gesture/close, not overflowing the screen.
• Computer: the panel traps focus while open, Esc closes, focus returns to the corner.

Preconditions

The corner visible; time to watch.

Steps

1. Leave a page untouched for several minutes — the corner sleeps.
2. Use it again — it wakes.
3. During a live test it must not animate at all (verify with doc 02's test).

Expected

• After a long idle the character visibly sleeps; interaction wakes it — a state, never a broken render.
• Under reduced motion, lite mode, or a live test, its idle animation stills completely.

Preconditions

Rename the companion (Settings → Companion).

Steps

1. Open the panel and any place the companion is named.

Expected

• The custom name appears wherever the companion is named ("Ask <name> about …"); resetting returns "WizBit" everywhere — no stale name left in any surface.

Preconditions

Any page with animated decoration (Halo sky, WizBit idle) and a modal dialog open.

Steps

1. Open a modal (e.g. the retract confirm or a menu dialog) over an animated page.

Expected

• Decoration holds still while the modal is open — motion is not spent under a dialog, and nothing animates distractingly behind it.

Preconditions

Signed in as a learner, Sidebar presentation.

Steps

1. Open the You group; follow every link: Skills, Achievements, Certificates, XP history, Annual Recap, Topic Requests, Inbox.
2. Look specifically for a Credits link.

Expected

• All seven links open their page; the active link lights correctly on each, including nested addresses (a certificate's detail still lights Certificates).
• No Credits link exists — it is offered only while generated assistance is on (§18).
• Bounties sits outside the spaces as its own entry.

Preconditions

Sidebar presentation.

Steps

1. Collapse and expand space groups — state persists across pages.
2. Drag links into/out of Pinned; reload.
3. Reset pins (Settings → Appearance) and confirm the default returns.

Expected

• Folded groups stay folded across navigation (device state); Pinned keeps your order until reset.
• The active page's link is marked in whichever group holds it.

Preconditions

Dock presentation; 390 px and computer widths.

Steps

1. Press You (multi-page) → the mini popover lists its pages; pick Inbox.
2. Press Home (one page) → goes straight there.
3. Repeat at phone width.

Expected

• A space with >1 page opens its popover of pages; a one-page space navigates directly. The active space marks on the dock.
• On phone the dock stays usable — icons/labels readable, popover within screen, no overlap of the WizBit corner or content's bottom edge.

Preconditions

Signed in as a learner, computer width; then phone width.

Steps

1. Read the header end: Quick Notes, bell, mode switch, level/XP pill, account menu.
2. Open the account menu; on phone, check the mode switch moves into it.

Expected

• On computer: Quick Notes button, notifications bell, light/dark switch, the level/XP pill (real level, real XP — never "Lv 0" unless truly 0), and the account menu.
• Account menu: heading = display name + "User · Member since <month year>" (or just role when unknown); links Profile, Settings; on phone also "Switch to dark/light mode"; "Back to Wizly Learning" leading to the main site's front page. No Sign out — the main site owns that.
• On phone the header drops the mode switch into the account menu rather than crowding.

Preconditions

tester-staff-1.

Steps

1. In the learner shell, open the account menu → "Staff console".
2. In the console, account menu → "Learner view".

Expected

• Staff get the console link in the account menu (learners never do — no nav leak of /admin).
• The switch is a link each way, not a mode toggle that strands you.

Preconditions

Any learner page.

Steps

1. Press the wordmark.
2. On a nested page, read the space chip/header context.

Expected

• The wordmark always leads Home.
• Pages name their space ("You · Skills" style context) and offer the space's sibling pages as chips where spec'd — orientation never requires the browser's Back button.

Preconditions

A learner account.

Steps

1. Open /admin, /admin/people, /admin/anything as a learner.

Expected

• The same plain not-found page as any unknown address — no staff menu, no "you are not allowed" that confirms the pages exist, no redirect that leaks structure.

Preconditions

Any learner.

Steps

1. Deep-link into /profile/settings/dailies in a fresh tab.
2. Navigate around, then Back through several pages.
3. Refresh mid-page.

Expected

• Deep links land on their page/section with real data — no signed-out flicker, no redirect to Home.
• Back/Forward restore the pages actually visited with their scroll place; refresh rebuilds the page fresh and honestly (loading states, then real data).

Preconditions

A long page (Skills or Inbox), both themes.

Steps

1. Scroll slowly past the top; keep scrolling.
2. Watch the header for jank, jump or content clipping.

Expected

• The header stays put; its veil (shadow or glass, as the theme draws it) fades in once content scrolls under it — only the veil's opacity moves; no layout shift.
• Under lite mode (§15) the veil snaps without a fade and no blur is applied.

Preconditions

Keyboard only.

Steps

1. Tab from the browser chrome: wordmark → header tools → navigation → main content.
2. Look for a skip-to-content affordance and a main landmark.

Expected

• Tab order is sane (no traps before the content, focus always visible); the page's <main id="main"> is reachable by skip link or landmark navigation.
• Menus and popovers return focus to their trigger on close.

Preconditions

Signed in as a learner.

Steps

1. Open /bounties; read it end to end; follow every link.
2. Hunt for any interaction — form, button, progress bar.

Expected

• A text page inside the shell explaining the programme plainly — who it is for and what it means, in learner words.
• Every link goes somewhere real in the product (same-domain).
• No eligibility checker, no "enrol", no progress UI, no promise of a feature that is not there — its honesty is the test.

Preconditions

Signed in as a learner.

Steps

1. Open /aptitude from the Practice navigation.
2. Check it at phone width and for staff.

Expected

• The page renders "This page is coming soon." inside the shell — navigation, header and theme all present; it is a page that is not built yet, not a missing one.
• It offers same-domain ways onward (back to real pages) — never a dead end, an error, a blank page or a fake interface.
• Staff's /admin/aptitude behaves the same way inside the console.

Preconditions

Code Lab open.

Steps

1. Read the runtime list (TypeScript, Kotlin, Swift, Scala, React for Code Lab).

Expected

• Unready runtimes are listed "Coming soon" with their reason — shown, not selectable; never a runtime that errors mysteriously when run.
• This matches the pattern: unfinished things are named honestly, never faked.

Preconditions

Theme Prism.

Steps

1. Walk Home, Skills, Settings, Inbox, Achievements, XP history, Requests, a certificate detail in light mode.
2. Flip to dark mode (header switch); repeat.

Expected

• Every surface renders in-theme: backgrounds, cards, chips, statuses, editor panes — no stray white/black boxes, no unreadable text, no unthemed scrollbars or dialogs.
• Section colours mark the spaces as Prism defines them.

Preconditions

Theme Halo.

Steps

1. Repeat the TC-PLT-014 walk in Halo, both modes, including decorative areas (sky, glows).

Expected

• Halo's own presentation everywhere — accent, sidebar default, its decoration rendered only as the mode allows; nothing leaks Prism's look.

Preconditions

One browser; two learner accounts.

Steps

1. Set Halo dark on account A; sign out (main site); sign in as account B in the same browser.

Expected

• The browser still draws Halo dark — appearance is kept under the device, never cleared at sign-out and never copied between accounts.
• Sign-in screens and the first paint honour the stored preference (no light flash for a dark preference).

Preconditions

A live test (doc 02) or N/A; a code editor; a modal.

Steps

1. Watch decoration while: a live test runs; you type in an editor; a program runs; a modal is open.

Expected

• In each case decorative motion holds still automatically; it resumes when the condition ends — you never had to toggle anything.
• Functional feedback (a result arriving, a saved tick) still works — stillness is decoration-only.

Preconditions

Dev tools console.

Steps

1. Run document.documentElement.setAttribute("data-lite","").
2. Walk Home, Skills, Inbox: watch the header veil, background decoration, toast entrances, list reordering.

Expected

• No backdrop blur (the header veil becomes opaque), no looping decoration, no layout-glide animations — everything still works and reads the same.
• Remove the attribute (removeAttribute) — full motion returns without a reload.

Preconditions

Dev tools (Performance/Rendering) if available.

Steps

1. Scroll fast through long lists; watch for layout jank.
2. Check decoration below the fold does not burn cycles (Rendering → frame stats, or just CPU feel).

Expected

• No jank from layout-thrash animations; off-screen decoration is paused rather than animated invisibly.

Preconditions

Any status-heavy page (Skills bands, request standings, certificate states).

Steps

1. Squint / desaturate (dev tools → Rendering → emulate vision deficiencies if available).

Expected

• Every status is also words or shape — band names, status words, icons; colour is never the only carrier.

Preconditions

Any toast-raising action (e.g. "Copy the verification link", mark a notice read).

Steps

1. Raise one; time it.
2. Raise another; hover it; move focus into it.

Expected

• Top-right, slides in, leaves on its own in ~5 s.
• Hovering or focusing it pauses the countdown — it never vanishes while you are reading or reaching for its button.

Preconditions

Ways to raise several toasts quickly (repeated mark-read, copy actions, a forced failure for a warning).

Steps

1. Raise 4–5 toasts fast; watch the stack.
2. Raise the identical passing toast twice.
3. Trigger a warning toast — does it stay?

Expected

• At most three on screen; the rest queue and show in order — never dropped.
• The identical passing toast does not appear twice (a toast carrying an action is exempt — its Undo would be lost).
• Warning and danger toasts stay until dismissed — a failure is never a 5-second whisper.

Preconditions

An undoable action (delete a notice, mark all read).

Steps

1. Delete a notice; on another tab/device (or after reload) verify the delete has not yet been sent while the toast shows.
2. Let the toast expire; verify the delete lands.
3. Repeat: press Undo — it is never sent.

Expected

• ~6 s for an Undo toast; the destructive change is committed only when the toast ends without Undo (timeout, dismissal, or the page being hidden/left mid-wait).
• Undo is a real undo — the item returns, the control re-enables, focus returns to where it was.

Preconditions

A raised toast; a live test (doc 02) or N/A.

Steps

1. Raise a toast, press F8 — focus lands on it; Esc/dismiss returns focus to your place.
2. During a live test, cause a toast (e.g. an earned achievement on another tab — or observe whether none can arrive).

Expected

• F8 moves focus to the toast list without the toast ever grabbing focus on its own; after it leaves, focus comes back along the chain.
• During a live test no toast interrupts — every one is held and shown once the test ends.

Preconditions

Any outcome that toasts (save, delete, award).

Steps

1. Raise the outcome; let the toast pass; re-check where the outcome lives on the page.

Expected

• The page itself reflects the outcome durably (the row is gone, the switch is on, the badge earned) — the toast was a word about it, not the record. Missing the toast never means missing the fact.

Preconditions

Dev tools → Network filtered on the live-channel request.

Steps

1. Open the product in one tab; find the stream request.
2. Open two more tabs on live-updated pages; count the stream connections.
3. Close the tab that owns the stream; watch another take over.

Expected

• One connection per browser — tabs share it (Web Locks/BroadcastChannel), not one each.
• When the owning tab closes or hides long enough, another tab claims the stream; notices keep arriving in all tabs.

Preconditions

Dev tools Network; a second device/profile to trigger a notice.

Steps

1. Hide the tab for >60 s; check the stream state.
2. Throttle the network to drop the connection; time the reconnect.
3. Trigger a notice while reconnected — it still arrives.

Expected

• A hidden tab gives the stream up within about a minute; visible again, it resumes (or polls once) without stale ghosts.
• A dropped stream reconnects inside a minute; if the stream must stay down, the page says updates are paused — it never fakes liveness.
• Stream states are honest: opening → live → paused/reload → over is surfaced, not hidden.

Preconditions

Dev tools Network on a polling page (e.g. certificate "Being prepared" watch, unread count).

Steps

1. Watch poll cadence while visible; hide the tab — polls stop.
2. End the session in another browser; this tab stops polling entirely.
3. Force failures; watch the interval back off.

Expected

• No requests fire while the tab is hidden; a tab that learned it is signed out stops asking at all.
• Failing polls back off to at most ~5-minute intervals rather than hammering.

Preconditions

Dev tools network throttling + request blocking to simulate a hung api.

Steps

1. Delay a read past its timeout (block it ~35 s); watch the page.
2. Delay a write similarly.

Expected

• The request gives up at its timeout and the surface says the read/write could not be done — never an endless spinner, never a fake success.
• Retry offers a real second try.

Preconditions

Signed in as a learner.

Steps

1. Open /credits and /credits/history.

Expected

• The same plain not-found as any unknown address — not a Credits page, not a permission error, not a redirect that reveals the pages exist-but-are-off.

Preconditions

Signed in as a learner.

Steps

1. Inspect the header end for a balance/credits pill.
2. Open the You nav group, Home's regions, Settings' sections, the Data-and-privacy wording, the XP page's "what pays" note.

Expected

• No credit balance or Credits link anywhere: not in the header, not in You, not as a Home card, not as a Settings section.
• Wording agrees: XP's note reads "Company Tests earn no XP or achievements" (not "…Credits or achievements"); erasure names "XP and preferences" (not "XP, Credits and preferences").

Preconditions

Walk the likely places.

Steps

1. On a challenge page, lesson, Workspace, Code Lab and test review: hunt for "Analyse my code", "Explain", "Ask AI", priced buttons, or Credit confirmations.

Expected

• None — generated assistance has no entry point anywhere; nothing offers a feature and then asks for Credits.

Preconditions

tester-staff-1.

Steps

1. Open the console's Economy area and Settings-like pages; look for Credit configuration surfaces that make sense while off.

Expected

• Where the console still shows Economy administration, it presents the off state truthfully (configuration exists, no learner balances) — it never pretends the feature is live for learners.

Preconditions

A signed-out browser.

Steps

1. Open https://app.sprinklejelly.com/skills signed out.
2. Let the handoff run; sign in on the main site.

Expected

• You land on /handoff ("Signing you in") which goes to the main site once per tab, and returns you to /skills — not always Home.
• The handoff never redirects to an arbitrary external address.

Preconditions

Stage a failed handoff (abandon the main-site step, or block it).

Steps

1. Come back from the main site without a session (or let the handoff stall/fail).

Expected

• /handoff says the sign-in could not be finished — explicitly not a membership problem — and offers "Try again" for the same page rather than bouncing you round again.

Preconditions

Two browsers (or normal + private window) — same account.

Steps

1. Sign in on browser A; open a page.
2. Sign in with the same account on browser B.
3. On A, make any request (navigate or act).

Expected

• A's next request finds it signed out: the notice reads "Your account was opened on another browser or device, so it is signed out here." + "What is on this page stays until you leave it, but nothing more is saved until you sign in again." + "Sign in here".
• The page and whatever was typed stay visible — nothing is wiped before your eyes — but nothing more saves.
• A never signs itself back in (that would end B's newer session). Signing A back in ends B — newest always wins.

Preconditions

One browser: page open as account A; sign out at the main site; sign in as account B in the same browser.

Steps

1. Return to A's still-open page; make a request.

Expected

• The notice reads "Someone else signed in on this browser after this page opened." with "What is on this page stays until you leave it, but nothing more is saved from it." and a "Reload the page" button — B's session is not offered to "continue as A".
• Reloading draws the page as B.

Preconditions

End the session elsewhere while this tab sits idle.

Steps

1. Leave a page open with live updates; end the session from another browser.
2. Time how long until the tab is told; then try an action.

Expected

• The tab finds out on its next request, or within ~a minute while its live updates run — not instantly by magic polling, and not never.
• Once told, every later action in that tab refuses consistently — no half-signed-in limbo.

Preconditions

Device state present: Code Lab draft, a Scratchpad text, changed filters, dark mode.

Steps

1. Sign out at the main site; sign back in on this browser.
2. Check Code Lab, Scratchpad, filters, theme.

Expected

• Per-person device data under the labs. keys is cleared — drafts, Code Lab, Tools state, project recovery copies, Scratchpad are gone (the product clears them the moment it learns the sign-in ended).
• Appearance (theme/mode/nav) survives — it is the device's, not the person's.

Preconditions

The denied account: WordPress account, no membership.

Steps

1. Sign in on the main site as denied; arrive at the app.

Expected

• The gate refuses: /restricted explains access is required and points to the main site — it does not drop them into the product, does not call it an error, and does not fabricate a reason it cannot confirm.
• Every member address gives the same refusal — nothing partially opens.

Preconditions

The lapsed account: membership ended, and Labs let them in before.

Steps

1. Sign in as lapsed.
2. Read the page; try to open /, /skills, /inbox.
3. Use the erasure controls (request → cancel within 7 days → read status).

Expected

• The page says the membership is past its end and offers "Erasing your learning records" — request erasure, cancel within the seven-day window, and read its status — nothing else: no learning content, no member pages.
• Every other page and route answers as for someone not signed in.
• The sign-in ends when the main site's answer changes — a renewed member comes back through an ordinary sign-in.

Preconditions

Open /restricted (a) signed in and admitted, (b) with a crafted ?reason=banned address while admitted.

Steps

1. Open the address in both states; also /restricted?reason=erased&until=never.

Expected

• An admitted person goes to Home — the address never displays a refusal it has not confirmed, whatever reason/until the address claims.
• Real refusals are the gate's own: past-its-end (offers Renew on the main site + Try again), suspended (end shown when known + Try again), banned (getting in touch, no Try again), erasing/erased, no-access — each factual, none guessed.

Preconditions

Probe both; a hidden/another-person's object for not-found.

Steps

1. Open /unavailable; (if the platform genuinely degrades, observe the real one too).
2. Open /not-found, a gibberish address, a hidden certificate's detail as another learner, a deleted object's address.

Expected

• /unavailable says Wizly Learning is unavailable with an honest retry — never a fake "everything is fine".
• Missing page, hidden object, another person's private object and unmatched /admin/* all answer the same plain not-found — no hint which case it is, no stack trace, no nav leak.

Preconditions

Hard to stage live — review item; stage by leaving a session idle >2 h if the test window allows, else N/A.

Steps

1. Leave a session idle past its allowance; return and act.

Expected

• The notice matches the reason: idle → "You were away for a while, so you are signed out."; past its life → "Your sign-in reached the end of its time, so you are signed out." — each honest, never a random kick.

Preconditions

Any browser, signed out.

Steps

1. Open https://app.sprinklejelly.com/api/v1/readiness.

Expected

• 200 when serving / 503 when not — it answers without a session and never waits on one. Use it before a test session and whenever something looks down.

Preconditions

Dev tools → Network → Offline.

Steps

1. Go offline on Home, Inbox, Skills, Settings, a certificate detail.
2. Try actions; come back online.

Expected

• Each surface says the connection is down or the read could not run — never "0", never an empty list presented as the truth, never a fake save.
• Writes degrade per their own rule (Quick Notes "saved locally…trying again", settings showing their failure) — and recover honestly when the connection returns.

Preconditions

Ordinary connection (or Fast 4G throttle).

Steps

1. Cold-load Home, Skills, Inbox; time usable content.
2. Trigger in-page reads (filters, Load more, period switch); scroll long lists.

Expected

• Content usable around 3 s on first load; in-page reads around 1 s with real loading states (skeletons/placeholders), never silent hangs.
• Long lists scroll smoothly; "Load more" never jumps your place.

Preconditions

Device toolbar.

Steps

1. At each width: Home, Skills, Settings (index behaviour), Inbox, a certificate detail, Topic Requests, the help panel.
2. Repeat the worst page in the other theme.

Expected

• No horizontal scroll; panels/sheets reflow (WizBit's help becomes a bottom sheet on phone); the Settings index adapts (beside sections on wide, along the top on narrow); nothing overlaps the dock, header or WizBit corner.

Preconditions

Keyboard; a screen reader if available (NVDA/VoiceOver).

Steps

1. Keyboard-walk Home, Inbox, Settings, the verify page: tab order, focus rings, dialogs trap+return, F8 to toasts.
2. Screen-reader the inbox and certificate verify: headings, labels, the aria-live answer, toast announcements.

Expected

• Sane order everywhere; visible focus; dialogs trap and return; live regions announce results (verify answer, save states, notice arrivals).
• Controls are labelled in people words — "Notifications. N unread.", "Move Quick Notes. Use the arrow keys." — no raw state names.

Preconditions

Any page.

Steps

1. Scan user-facing text across this doc's pages for banned words: "Labs", "attempt", "expired", "surface", "frame", "sample" (for a visible test case), internal state names, spec sentences.
2. Check numbers and times.

Expected

• People text says "Wizly Learning" (title, verify page, toasts) — "Labs" never appears in interface text; the right-hand vocabulary words are absent.
• Numbers group the Indian way (12,34,567); dates/times carry IST where a clock matters; a calculated figure may say when it was worked out in plain words ("worked out at 14:05"), never raw internal metadata.