05 · Admin — Operations & People

Preconditions

Signed in as Admin (tester-staff-1).

Steps

1. Open /admin.
2. Read the page top to bottom.
3. Press Read again.

Expected

• Five regions in order: Needs attention, Signals, Owner alerts, Background work, Waiting for recovery.
• The header says "Read HH:MM IST" and updates on Read again; the lead explains unknown is never counted as clear.
• Each region stands alone — no region blanks the others.

Preconditions

Operations hub open as Super Admin.

Steps

1. Read each row of Needs attention.
2. Follow several rows' Open arrows (erasure, submissions, topic requests, Daily Challenges).

Expected

• Each row shows an icon, a linked name (its page), a Detail line (e.g. "2 past due · 1 stopped by a failure", "Waiting for approval"), a Since time where one applies, and a count with its unit ("1 erasure", "3 submissions").
• Links land on the owning page — erasure → /admin/lifecycle?stage=attention already narrowed, Daily Challenges → /admin/daily-challenges/schedule-health, grading waiting scrolls to #background-work.
• Priority order is as listed above — operational attention only: no learner-performance, low-balance or content-inventory rows.

Also try

• Where nothing waits for a row, it folds into the single "Also clear: …" line naming each clear area as a link.

Preconditions

Hub open; needs one attention part to fail its read (hard to stage — mark N/A if it never happens, or catch it during a partial outage).

Steps

1. Observe the hub while a backend read is failing (or during deployment hiccup), then restore.

Expected

• The affected row keeps its place and shows "Couldn't be read" as its count badge and "Couldn't be read. Read again." as detail — it never folds into "Also clear".
• Other rows keep their real counts; the page keeps working.

Preconditions

Both staff accounts available; compare the hub in two sessions.

Steps

1. Open /admin as Super Admin; note the Main-site changes row and the header.
2. Open it as Admin; compare.

Expected

• Super Admin: the Main-site changes row links to /admin/identity-delivery and details "N could not be verified · M waiting longer than they should"; the header shows "Admins publish: On|Off" linking to /admin/settings/publishing.
• Admin: the same row shows the count but is not a link, and its detail reads "A Super Admin follows these up"; no publishing fact in the header.

Preconditions

Hub open.

Steps

1. Read the Signals region row by row.
2. Note order, status chips and the per-signal line.

Expected

• Ten signals: Main-site access · File storage · Grading · Interactive programs · Background work · Notice delivery · Scheduled summaries · Maintenance · Backup and restore · WizBit.
• Each shows a plain-words line about what was observed and "Measured …" or "Never measured" beneath.
• Ordering is problems first: Down → Degraded → Unknown → Healthy. Unknown never reads Healthy.
• Backup and restore and WizBit read Unknown with an honest "not recorded yet"-style line — not a fabricated Healthy.

Preconditions

Needs the interactive execution service down while standard grading is healthy — stage only if the team has arranged it; otherwise mark N/A.

Steps

1. While the interactive service is unreachable, open the hub and read Grading vs Interactive programs.

Expected

• Interactive programs reads Down (or Degraded) on its own; Grading stays Healthy — one failed lane is not presented as all execution down.
• The console health light reflects the worst state honestly.

Preconditions

Hub open.

Steps

1. Open the "By area, over the last 24 hours" disclosure under Background work.
2. Read a few areas' rows.

Expected

• The disclosure is folded away when nothing is overdue or waiting for recovery — and opens itself when anything is.
• Areas are named in staff words (Sign-ins, Mock and Company Tests, XP and Credits, Account erasure, Notifications, Worker upkeep…), never raw job kinds.
• Columns: Waiting (with a "N overdue" danger chip when any), Running, Succeeded, Failed, For recovery, Queue wait (middle · slowest twentieth), Running time (middle · slowest twentieth).
• Unmeasured timing reads "Not measured", never 0; waiting/running are current readings, the rest are the last 24 hours — the explainer line says so.

Preconditions

Hub open; ideally a real failed job exists (a paused reward notice or parked certificate works). If none exists, mark N/A — do not manufacture failures.

Steps

1. Open the Waiting for recovery disclosure.
2. Read each row; follow the link on one that has one.

Expected

• "No failed work waits for recovery." is the healthy empty state.
• Each row names the work in words ("A reward notice", "Making a certificate's document", "One part of an erasure", "Checking a main-site change"), the producing area, failed/queued times, tries and the last failure class in words.
• Rows with an owning page link there: main-site change → /admin/identity-delivery, certificate document → /admin/certificates/parked-generations, reward notice → /admin/economy/failed-rewards, erasure part → /admin/lifecycle?stage=attention.
• No generic resume button — the note says each is recovered on its owner's own page, never by editing the work.
• As Admin, a Super-Admin-owned kind shows "A Super Admin follows it up" with no link.

Preconditions

Hub open.

Steps

1. Read the Owner alerts region: the delivery line, the condition list, and any "would have been sent" disclosure.

Expected

• "Delivery to the owner is not set up yet, so no alert is sent." — no claim that alerts reach anyone.
• Conditions ordered: Standing → Clear → "Cannot be checked yet". Standing ones say "standing since …"; checked ones "checked …".
• Five conditions legitimately read "Cannot be checked yet", each saying why (platform reachability needs an outside check; backup/restore; disk space; video processing; WizBit silence).
• When notices were kept, a disclosure lists the newest 20: the condition in owner words, what was found, when, and Began · Still standing · Recovered.

Preconditions

Hub open for several minutes; dev tools network panel available.

Steps

1. Watch the network calls for ~3 minutes without touching the page.
2. Hide the tab for a minute and return.

Expected

• The page re-reads about once a minute; the "Read …" timestamp advances.
• While the tab is hidden, the health light is not re-read.
• After a failed read the polling backs off rather than hammering; previously read figures can stay with their freshness.

Preconditions

Any staff page open.

Steps

1. Find the compact health indicator in the console header.
2. Compare it to the hub's worst signal; navigate between staff pages.

Expected

• One state is shown, matching the hub (Healthy/Degraded/Down/Unknown) — read once a minute, never while the tab is hidden.
• When the hub cannot be read the light reads Unknown, never Healthy.
• It costs nothing extra visually: same reading shared, no per-page probe.

Preconditions

Signed in as Admin, then Super Admin.

Steps

1. Read the console navigation as Admin.
2. As Super Admin, compare.
3. Type a Super-Admin-only address directly as Admin.

Expected

• Seven spaces: Operations · Content · People · WizBit · Messages · Insights · System, with breadcrumb and account/actions.
• Destinations appear only when the role permits: Admin sees no links to Super-Admin-only pages (e.g. Publishing, Maintenance, Economy settings).
• A direct SA address as Admin reads "Only a Super Admin can open this page." — same decision as the nav, no title/count leaks.

Also try

• Keyboard: tab through the console nav; focus is visible and order sane.

Preconditions

Signed in as tester-learner-1.

Steps

1. Open /admin and /admin/people directly.

Expected

• The same plain not-found as any unknown address — no staff navigation, no hint the pages exist, no counts.

Preconditions

A phone-width viewport (~390 px) as staff.

Steps

1. Open the console on a narrow window.
2. Navigate into People and open a person's panel; open an audit entry.

Expected

• Bottom dock: Operations · Content · People · More; More opens the other four spaces. No drawer.
• The breadcrumb folds to one link to the nearest page above; a page with its own way back never shows two ways back.
• Side panels (person, audit entry, broadcast, erasure) slide over the list's right side on narrow windows and sit between the header and dock, which stay usable.

Preconditions

Signed in as staff.

Steps

1. Open /admin/people.
2. Read the rows and the match count; use Load more if offered.

Expected

• Columns: Name, Role, Standing, Membership ("Since …" or "Never"), Last checked with the main site (IST).
• Default order is last-checked, newest first; the view says how many it holds ("N people") — only when actually counted.
• Roles shown are the normalized Labs roles (User / Admin / Super Admin); "Not known" where the role is unread, never guessed.

Steps

1. Search "tester-learner".
2. Search part of a name ("learner-1", a fragment).
3. Clear the search.

Expected

• Rows narrow to name matches; the count is of the same filtered set.
• No matches → "No people match these filters" with a way to clear — distinct from an empty directory and from a failed read.
• The search text lives in the address; reloading keeps it.

Steps

1. Cycle the segmented view control through the three views.
2. Compare each view's count.

Expected

• Each view shows its own whole-directory count beside its label.
• "Suspended or banned" lists only restricted people with their standing badge; "Main-site check failing" lists genuine verification faults (rows tagged "Check failing").
• An empty view says "Nobody is in this view" and points back to All people — honest, not an error.

Steps

1. Set Role = User.
2. Add Standing = In good standing.
3. Add Membership = Has held a membership.
4. Reload the page; remove chips one by one.

Expected

• Role offers exactly User / Admin / Super Admin; Standing: any · in good standing · suspended · banned; Membership: any · has held · never held.
• Filters combine (staff without learner membership, and Users without staff access, stay findable under the right combination).
• Applied filters appear as removable chips under the bar; every filter and the search are in the address — a reload reproduces the exact list.

Steps

1. Click the Name column header to sort by name.
2. Click Last checked to return to the default order.

Expected

• Server-side sort: name ascending with people who have no name ("No name given yet") last.
• The sort lives in the address; changing it does not lose the filters.

Preconditions

A suspended/banned person and, if one exists, someone mid-erasure or with a failing check.

Steps

1. Read the Standing column across the directory and the Suspended-or-banned view.

Expected

• Suspended/banned rows carry the standing badge; a failing main-site check tags "Check failing"; an account being erased is tagged "Erasure in progress" (danger tone).

Steps

1. Open five different people in turn, then return to /admin/people with no person open.
2. Click a Recently opened chip.

Expected

• "Recently opened" chips above the table name the last five opened, kept on this device until sign-out.
• A chip reopens that person's panel carrying the list's current filters back on return.
• Nobody whose account is being erased is kept there; a person no longer found at their address drops out.

Steps

1. Click a person (e.g. tester-learner-1).
2. Note the address, the panel and the list state; close the panel.

Expected

• The panel opens beside the list at /admin/people/<identity>, titled with the person's name (or "No name given yet (xxxxxxxx)").
• "Opening this is recorded in the audit history." is stated; the read happens once per opening — nothing in it polls again by itself.
• On a window ≥1280 px the list makes room for the panel (covers nothing); on a narrower one it slides over the list's right side.
• Closing returns to the list with its filters/search intact (the person's address carried the list's state).

Steps

1. Open a person's panel and read the Access section and the badge row.

Expected

• Badges: one Labs role chip, the standing badge, "Erasure in progress" where it applies, and "This is you" on your own account.
• Access shows: Role "…, set on the main site" (or "Not known yet"), Membership ("Member since …"/"Has not been a member yet"), Last checked (IST), Main-site check "Working" or "Failing since …".
• "Manage on the main site" opens the main site's user administration in a new tab — Labs has no role editor, and nothing here changes identity or membership.
• A stale or unreadable fact says so plainly rather than implying an inactive or banned account.

Steps

1. Open a learner with real activity (tester-learner-1); read Headlines.

Expected

• Figures: Level (with total XP, or "No XP yet"), Daily streak (current + longest), Lessons done, Solutions saved.
• Below: "Skills: N strong · N developing · N needs practice".
• Each figure that cannot be read says "Couldn't be read" alone — the rest still show.

Steps

1. Open the panel of a learner with code, notes and project files.
2. Look for any path into their private work.

Expected

• The page itself states: "Their code, notes, project files and answers are never shown here."
• No section offers submitted/saved code, typed input, clipboard content, terminal output, Notes, Workspace files, generated prompts, or a download/impersonation route into their work.
• No last-seen or live facts are shown.

Preconditions

A person with at least one past or current restriction (run TC-PPL-019 first if none exists).

Steps

1. Open their panel; read Standing and its history list.

Expected

• Current standing reads explicitly: "In good standing", "Suspended until …" or "Banned since …" — never inferred absence.
• "No suspensions or bans." when none; otherwise each entry: "Suspended for N days" or "Banned", the reason, any private note, who placed it (name + role), when it started, and how it ended ("In force until …", lifted, reached its end, or "Replaced by a ban").

Preconditions

A person holding a certificate; a person mid-erasure if available.

Steps

1. Read the Certificates section of a certificate holder.
2. Read the Erasure and legal holds section on someone mid-erasure and on someone with a hold.

Expected

• Certificates: course, "Issued …" or "Not issued yet", state chip (Waiting for a name · Being made · Not made yet · Issued · Revoked); each opens its record. "No certificates yet." when empty; "Couldn't be read." on failure.
• Erasure under way shows a meter "Erasure: N of M parts done" (or "Erasure: starting") + started time + "Open in Erasure and holds" → /admin/lifecycle?erasure=….
• Holds list each: "Legal hold placed …", "Review by …" / "Ends by …" or Released with when and by whom; "In force" chip while active.

Preconditions

A person with several kinds of actions recorded (a suspension + a hold + a correction, e.g. after earlier cases).

Steps

1. As Admin, open their panel and read "Administrative actions".
2. As Super Admin, compare.

Expected

• Both roles see each action's name, who took it ("The platform" for automatic ones) and when.
• Admin reads reasons only for a suspension, its early lift, a ban and an erasure — a hold's, a reset's, a reversal's or a correction's reason never reaches the Admin's browser; the section lead says "…the rest are for Super Admins."
• Super Admin reads every reason.
• "No administrative actions involve this person." when none. Support-view openings are not listed here.

Steps

1. As Admin (tester-staff-1), open another person's panel.
2. Try a moderation address directly, e.g. /admin/people/<id>/suspend.

Expected

• The panel shows "Actions on people are for Super Admins." — no Suspend/Ban/More actions.
• The SA-only address shows the SA-only page message, not the dialog.

Preconditions

An account past its cancellation window being erased (after TC-LFC-011, or an existing one). Super Admin.

Steps

1. Open the person's panel while erasure runs.
2. Open their /suspend address directly.

Expected

• The panel still opens, says Erasure in progress with the parts meter, and offers exactly one action: "Place a legal hold…" — "Their account is being erased. A legal hold, which pauses it, is the one action left."
• A moderation address says "Their account is being erased, so their standing is not changed here." — no dialog.

Preconditions

Signed in as Super Admin; an unrestricted learner chosen (coordinate — tester-learner-2).

Steps

1. From their panel, choose Suspend (or open …/suspend).
2. Pick each duration preset; choose Other and try 0 and 366 days.
3. Type and remove the reason; watch the confirm button.

Expected

• Dialog titled "Suspend <name>" — the person's own name.
• Presets 1 · 7 · 30 · 90 days plus Other → a day count 1–365; "They can come back in on …" shows the concrete end date/time and ticks as the choice changes.
• Reason is required (confirm stays unavailable until typed); private note is optional and labelled staff-only.
• Consequences stated before confirming: sign-ins end now, a live test ends scored on saved answers, programs stop; records and main-site membership stay untouched.

Steps

1. Complete TC-PPL-017 with a reason and a private note; confirm.
2. Return to the person's panel; check Standing and history.
3. Check /admin/audit (as Super Admin).

Expected

• Outcome toast/line confirms the suspension and its parts (access ended, live test ended on saved answers where one was live, programs stopped).
• Panel shows Suspended until the stated time; the history gains the entry: by whom, when, reason, the private note visible to staff.
• The audit entry exists (suspension action) under the acting staff member's name.

Preconditions

The learner suspended in TC-PPL-018, signed in in another browser/profile.

Steps

1. As the suspended learner, open any app page; use Try again.

Expected

• A restricted page: "Your access to Wizly Learning is suspended" with when it ends and a route to the main site — never the reason, the private note, or who placed it.
• Try again keeps showing the restricted page until the suspension ends or is lifted; after it ends the app admits at once.

Also try

• Lift early (next case), then Try again — the learner gets straight back in.

Steps

1. Open /admin/people/<the suspended learner>/lift-suspension.
2. Type a reason; confirm.

Expected

• Title "Lift <name>'s suspension early"; a reason is required; wording is restorative (they can come back in now), recorded with your name.
• Standing returns to "In good standing" immediately; history marks the suspension as lifted early, and the lift is its own history row + audit entry.

Preconditions

An unrestricted learner chosen (coordinate — tester-learner-3).

Steps

1. Open …/ban.
2. Type the wrong name — confirm stays unavailable.
3. Type the exact name, add reason + optional note, confirm.
4. As the banned learner, open the app.

Expected

• Title "Ban <name>"; the confirm needs the exact typed name (the name as shown, or the address start where the person is nameless) plus a reason.
• Consequences add "cannot come back until unbanned"; sign-ins end as with suspension.
• The learner's page reads "Your access to Wizly Learning is banned." — no end date, no reason, no note.
• History gains the Ban row; audit entry under your name.

Steps

1. Suspend a learner (reason + days), confirm.
2. Immediately ban the same learner (typed name + reason), confirm.
3. Read their Standing history.

Expected

• The ban succeeds and stands; the earlier suspension entry reads "Replaced by a ban" — it did not "reach its end" and is not shown as lifted.
• Two history rows, one standing: Banned.

Steps

1. Open …/unban for the learner banned in TC-PPL-021/022.
2. Type the name; confirm.
3. As the learner, open the app.

Expected

• Title "Unban <name>"; typed name required, no reason asked.
• "They are unbanned and can come back in now. This is recorded with your name." — learner is admitted on their next request.
• History shows the ban and the unban as two rows; the ban keeps its reason.

Steps

1. Open …/lift-suspension on someone not suspended.
2. Open …/suspend on someone already suspended; …/ban on someone banned; …/unban on someone not banned.

Expected

• Each address explains in words instead of showing a form: "They are not suspended, so there is nothing to lift." / "They are suspended already." / "They are banned already." / "They are not banned, so there is nothing to undo."
• The support view still shows behind/beside the message — the address never errors.

Steps

1. As Super Admin, open your own person panel.
2. Open your own /suspend, /ban, /unban, /lift-suspension addresses directly.

Expected

• Your panel says "This is you"; no moderation actions are offered.
• Each direct address refuses in words ("Nobody can suspend their own account." etc.) — no dialog, and the api refuses the same way.

Steps

1. Open Ban for a learner; type a near-miss name (case change, extra space).
2. Leave the reason empty and inspect confirm.
3. Cancel — check nothing changed.

Expected

• Confirm is unavailable until the typed name matches exactly and the reason is non-empty.
• Cancelling or navigating away writes nothing: no audit entry, no history row, learner untouched.

Preconditions

Super Admin session idle long enough that the main-site check is older than 15 minutes (or freshly signed in without one).

Steps

1. Open Suspend for a learner; fill reason, note, 7 days.
2. Press the confirm button.

Expected

• The button reads "Confirm on the main site"; pressing it hands off to the main site for verification and returns to this same dialog.
• Reason, note and chosen days are held across the round trip; a typed-name field is typed again by design.
• Only after a fresh check does the write go through.

Steps

1. Suspend a learner with a distinctive private note (e.g. "internal ref ZZ-9").
2. As the learner, read the restricted page.
3. As staff, read the audit entry for the suspension.

Expected

• The learner's page shows the end time and the factual wording only — not the reason, not the note, not the moderator.
• The audit entry keeps the reason but never the private note; the note is readable only inside the staff history.

Steps

1. Open Suspend; complete the form; double-click the confirm quickly / press Enter twice.
2. Re-open the same dialog address and try again against the already-changed standing.

Expected

• Exactly one suspension entry and one audit row — the repeated submit is folded into the same recorded operation.
• A later action attempted against a standing that has since changed is refused by the not-offered wording rather than applied again.

Preconditions

A 1-day suspension placed (or a short "Other" duration where staging allows).

Steps

1. Suspend; let the end pass (or coordinate a short duration).
2. After the end: check Standing, history, and whether the learner was told anything.

Expected

• At the end time the person is free at once — no staff step needed.
• History shows the suspension "Reached its end" (attributed to the platform, not a person); no notice is sent to anyone for the expiry itself.

Steps

1. Open /admin/people/<tester-learner-4>/reset.
2. Read every scope's description; select a subset.

Expected

• Step "Choose what to reset" lists nine scopes grouped (Learn / Practise / Assessments / Build / You): Courses, Workspace Projects, Skills, Learning preferences and Continue, Challenges and Tracks, Daily Challenges, Timed Debug, Mock Tests, Company Tests.
• Each scope names what resets and what stays (solved items, submissions, completed tracks, paid rewards, quiz results, certificates, files, project last-edited time).
• A scope not available for this person is disabled with "not available" wording rather than hidden silently.

Steps

1. With scopes chosen, proceed to "What would change".
2. Use Back and change the selection; return.

Expected

• The page states the counts were "Counted just now, for this person" — nothing estimated; each scope shows its own item counts.
• Back keeps the choices; Next stays unavailable while any selected scope cannot be counted.

Preconditions

A scope that cannot be counted right now, or a learner inside a running timed window / live test.

Steps

1. Select the affected scope; try to proceed.

Expected

• The scope is reported as unable to run ("Could not be counted just now" / the blocked reason in words) and confirmation cannot proceed while it stays selected.
• The message names the scope; deselecting it unblocks the rest.

Steps

1. Proceed to Confirm.
2. Try confirming without the reason, then with a mistyped name.
3. Complete correctly and confirm.

Expected

• Confirm requires a reason and the person's exact typed name; the button is danger-styled ("Reset these parts").
• "This cannot be undone. They are told once it is done." is stated; the confirm passes the main-site check.
• On success the run screen appears — one row per scope.

Steps

1. Confirm a multi-scope reset and watch the run screen.

Expected

• Each scope reports independently: Waiting → Running → Done with "N changed", or Failed with its failure in words.
• Headline reads "Still running" until all settle, then names the outcome honestly including "Some parts failed".
• A scope that changed nothing reports done without pretending it removed rows.

Preconditions

A run with a failed scope (mark N/A if no failure occurs naturally).

Steps

1. On a run with Failed scopes, use "Try the failed parts again".

Expected

• Only the failed scopes run again; Done scopes are untouched.
• The retry itself is a recorded action; a lost worker attempt is not reported as "0 changed".

Steps

1. After a reset with changes, check the learner's notifications as that learner.
2. Run a reset where every selected scope changes nothing.

Expected

• Exactly one System notice once all changed scopes complete, naming what was reset and what stays — not one per scope, and none on an empty reset ("Nothing needed changing, so they were not told.").

Steps

1. Open /admin/people/<your own identity>/reset.
2. Open /admin/people/<a person mid-erasure>/reset.

Expected

• Own account: "Nobody can reset their own progress." — no form.
• Being-erased: the uniform refusal ("Their account is being erased, so nothing more is changed for them.") — no form.

Preconditions

A completed reset on a learner who had XP, certificates, achievements, solved challenges and paid rewards.

Steps

1. As the learner, check level/XP, certificates, achievements, solutions, rewards and profile after the reset.

Expected

• Level/XP, certificates, achievements, solve facts, paid rewards, saved files, quiz results and last-edited times all survive exactly as the scope text promised.

Steps

1. Open /admin/people/<identity>/reset?scope=skills directly.

Expected

• The Skills scope arrives preselected; every other behaviour is identical (same preview, same confirm, same audit) — the address never grants a different operation.

Preconditions

A learner holding at least one certificate whose access you may end (coordinate — tester-learner-5).

Steps

1. Open /admin/people/<the learner>/payment-reversal.
2. Step 1: enter a main-site reference and a reason.
3. Step 2: read the certificate list; tick a subset.
4. Step 3: read the consequence list; try confirm without the typed name, then correctly.

Expected

• Step 1 asks for the main-site reference (bounded ~120 chars) and a reason — and states Labs does not process payments: this records a reversal the main site already made.
• Step 2 lists the person's un-revoked certificates as checkboxes; none is pre-ticked; already-revoked ones are absent.
• Step 3 lists consequences: every selected certificate revoked, all sign-ins ended, next entry asks the main site — plus typed-name confirm and the main-site check.

Steps

1. Complete TC-PPL-041 with two certificates selected.
2. Read the outcome; check the learner's certificates, audit and the person panel.

Expected

• Outcome reports in one breath: "The reversal is recorded. 2 certificates revoked; N sign-ins ended."
• Each selected certificate now reads Revoked (public verification invalid); unselected ones are untouched.
• The audit carries the reversal entry; the person's action history lists it.
• The learner's sessions end; their next sign-in asks the main site.

Steps

1. Repeat TC-PPL-041/042 entering the same main-site reference for the same person.

Expected

• The page returns the already-recorded result: "This reference was confirmed <date>. Nothing happened again." — no second revocation, no second audit write, no extra sign-out storm.

Steps

1. Read the form and the resulting history/audit entries after a reversal.

Expected

• No field or record asks for or stores an amount, invoice number or payment method.
• History rows show reference, reason, who, when, and the certificate count.

Steps

1. Open /admin/people/<own identity>/payment-reversal.
2. Open it for an account being erased.

Expected

• Own account refuses in words — no form.
• Being-erased refuses with the same "being erased" sentence used everywhere else.

Preconditions

At least one erasure exists (a learner's own request or one begun by staff).

Steps

1. Open /admin/lifecycle; read the Erasures table rows.

Expected

• Each row: the person (link, or "An erased person (xxxxxxxx)" once gone), asked-for source and time, stage chip with the seven possible states, an "Overdue" chip where it applies, the parts meter ("N of M parts done"), due-by/erased dates, and — for failed rows — the failure in words.
• Order leads with the oldest unfinished work.

Steps

1. Set the stage filter to "Overdue or failed", then a single stage.
2. Set the holds filter to "Due for review".
3. From the Operations hub, follow the erasure and legal-hold rows.

Expected

• Stage select offers every stage plus aggregates like "overdue or failed"; the holds filter offers "every hold" / "due for review".
• Filters persist in the address; the hub's needs-attention links land already narrowed (?stage=attention, ?hold=overdue) with matching counts.

Steps

1. Click an erasure row; read the side panel (address gains ?erasure=…).
2. Compare an early-stage erasure with a finished one.

Expected

• Panel shows the person, the stage, who asked (learner themselves / staff name), the reason where the role permits, the cancel-until time during its window, and Due by / Erased dates.
• A part-by-part list: each part's state and "N removed" count, with failure detail in words on failed parts.
• An erasure never reads "Erased" before its last part finishes; in-progress and held states name themselves.

Preconditions

A learner-initiated erasure inside its cancel window ("Learner can still cancel").

Steps

1. As both roles, open that erasure's row and panel and look for approve/reject/cancel controls.

Expected

• No staff control exists to approve, reject or cancel the learner's request — the panel states the learner can cancel until the given time.
• "Cancelled by the learner" is a stage the system reaches, not a staff action.

Preconditions

An erasure in the Failed stage (mark N/A if none exists — do not break one deliberately).

Steps

1. Open the failed erasure's panel; use "Try again from this part".
2. Repeat as Admin — no control.

Expected

• Super Admin sees the retry on the failed part, gated by the main-site check, and the retry is recorded.
• Admin sees the failed stage and its detail but no retry control.

Steps

1. Read the Legal holds table.

Expected

• Rows: person link, placed-by + when, "Review by …" or "Released …", "Ends by …" or "No end date", and state (In force / Due for review / Released).
• When there are more than the newest hundred, a line says "Showing the newest N" rather than implying the list is complete.

Preconditions

A hold in force with a reason and authorizer.

Steps

1. As Admin, read the hold row and open its panel.
2. As Super Admin, compare.

Expected

• Admin sees the hold exists, who placed it, and its dates — the reason, the basis and the authorizer never reach the Admin's browser (check the network response, not just the UI).
• Super Admin reads reason and authorizer in the row/panel and in the Review/Release dialogs.

Steps

1. On a learner's panel, open ?act=hold.
2. Try a review date of today, of 91+ days out, then a valid one; optional end date before today.
3. Complete with reason + named authorizer; confirm through the main-site check.

Expected

• Dialog names the person; asks for reason, the named authorizer, a review-by date (after today, at most 90 days ahead — a valid default is offered), and an optional end-by date that must be after today.
• Invalid dates are called out under the field immediately and refused again at the server — not silently corrected.
• Consequences are stated (the hold pauses erasure work and is confidential); on confirm, the hold appears In force.

Preconditions

A hold in force.

Steps

1. Open the hold's Review dialog.
2. Confirm the basis, set the next review date, confirm.

Expected

• The dialog shows the hold's basis (person, reason, authorized-by, ends-by) before asking for the next review date — again ≤90 days, validated live and server-side.
• The review is recorded; the hold stays In force with the new review date.

Preconditions

A hold whose review date has passed (coordinate setting one with a near date, or use an existing overdue hold).

Steps

1. Read the holds table and the hub's legal-hold row.

Expected

• The hold shows "Due for review" / review overdue and remains In force — an overdue review never releases or lapses a hold by itself.
• The Operations hub's legal-hold row counts it.

Preconditions

A hold pausing an in-progress erasure.

Steps

1. Open the hold's Release dialog; read its resumption note.
2. Type a reason; confirm through the main-site check.
3. Watch the erasure row.

Expected

• Release asks for a reason and a fresh main-site check.
• Releasing the last applicable hold resumes the erasure from its first unfinished part — the erasure leaves "Held" and progresses.
• The released hold remains listed as Released (muted), with when and by whom; already-erased parts are never restored.

Steps

1. Release a hold that is already Released.
2. Where possible, have two staff sessions release the same hold at once.

Expected

• The second release changes nothing and reports so; two simultaneous releases still produce exactly one resumption and no lost state.

Steps

1. On the agreed learner's panel, open ?act=erase.
2. Read the consequences; type a reason and the exact name; confirm.

Expected

• Dialog "Erase this account" states: erasure begins at once (no seven-day wait), the sign-in ends, certificates stop being found; reason + typed name required; main-site check on confirm.
• After the toast ("Erasure has begun"), the person panel reads "Erasure in progress" and only the legal-hold action remains.

Preconditions

An account mid-erasure.

Steps

1. As Super Admin, open each person-action address: suspend, ban, unban, lift-suspension, reset, payment-reversal, correction, extra, certificate actions, invalidate.

Expected

• Every one refuses with the same meaning: "Their account is being erased, so nothing more is changed for them." — only a legal hold can still be placed.
• The refusal is server-enforced, not just a hidden button.

Steps

1. Compare an erasure's parts with any retention/age-based cleanup mentioned on the page or in audit.

Expected

• Erasure rows name their own parts and source; nothing conflates a requested erasure with routine age-based pruning, and one does not silently stand in for the other.

Steps

1. Open /admin/certificates.
2. Search by learner name and by certificate code; filter by awarded item, state and completion period where offered.

Expected

• Awaiting-attention figures up top (name corrections waiting, documents needing attention), per-item counts (pending/issued/revoked), and the list.
• Search finds by learner and by code; filters combine; staff-awarded records are labelled as staff and excluded from learner-facing counts.
• The page is a reading desk — "nothing here makes one": no create control.

Steps

1. Open an issued certificate's record.
2. Open a revoked one and one hidden from verification, if any exist.

Expected

• Status chip (+ "Hidden from verification" / "Replacement on its way" where true), the code in mono, printed name vs the learner's current name, completed and issued dates, and a staff flag note where the holder is staff.
• A revoked certificate shows a danger note: revoked by, when, the permitted reason, and the staff private note.
• History groups by day: earned, name set, issued, document events, revocation — each attributed to a person or "The platform".

Steps

1. As Admin, open a certificate record, the name-corrections queue and parked-generations.

Expected

• All readable; the record states "Only a Super Admin can change a certificate." — no Revoke, retry or reissue buttons for Admin, and no approve/reject in the queue.
• Reading is not the same as power: no write control is merely hidden — the role note is displayed.

Steps

1. On an issued certificate, open …/revoke.
2. Read the reasons; pick one, type a private note; confirm through the main-site check.
3. Check the public verify page for the code and the learner's notifications.

Expected

• Two steps; the reason list is exactly: the awarding record is invalid · duplicate issue · defective award · issuance error; a private staff note (≤500) is required.
• On confirm: the record stays, the certificate reads Revoked, public verification answers invalid at once, download stops, and the learner is told once.
• Revocation does not delete — the record and its history remain.

Steps

1. Open …/revoke on the certificate revoked in TC-CAD-004.

Expected

• "Already revoked" plus who revoked it and when — no form, no second learner notice.

Steps

1. On a revoked certificate, use "Make it valid again" with a private reason; confirm.
2. Check public verification once the document is ready.

Expected

• Requires a private reason + main-site check; the certificate keeps its code and its completed/issued dates.
• Verification becomes valid once the new document is made — not instantly claimed valid.

Preconditions

A certificate whose document failed to generate (parked-generations row).

Steps

1. Open its record; read the document failure line.
2. Use "Try making it again" through the check.

Expected

• The failure is shown in words with when it happened; retry is tied to this certificate, not a generic job queue.
• A failed replacement leaves the earlier document usable — the record never claims a document that does not exist.

Preconditions

At least one pending name-correction request.

Steps

1. Open /admin/certificates/name-corrections.
2. Approve one: read the confirm text first.
3. Reject another with a reason.

Expected

• Oldest first; each row: learner, current → proposed name, their reason, how many issued certificates are affected, Approve and Reject.
• Approving states what happens: certificates not yet made will print the new name; issued documents keep the old name until an explicit reissue.
• Rejecting requires a reason the learner can read; approval applies the learner's exact current name, not a staff-typed variant.

Preconditions

TC-CAD-008's approved correction with issued certificates.

Steps

1. Open an affected issued certificate — check the printed name.
2. Use Reissue: read the preview count; confirm.

Expected

• After approval, issued documents still show the old name — the record explains they keep it until reissued.
• Reissue previews the affected count ("Reissue N certificates with the corrected name"), confirms through the check, and lists each certificate with its code; old documents stay usable until their replacements are ready.

Steps

1. Open /admin/certificates/parked-generations as Admin, then Super Admin.
2. As Super Admin, retry one row through the check.

Expected

• Each row: awarded for, learner, which document (first vs replacement), why it paused in words, waiting since, tries.
• Admin reads the list; only Super Admin gets "Try again", gated by the fresh main-site check — matching the hub's certificate-documents row.

Steps

1. Retry a parked generation; then check the learner's certificates and the list counts.

Expected

• A successful retry produces the document for the existing certificate — never a second certificate, never a doubled count.

Steps

1. On the public verification page, check a revoked code and an erased person's code.

Expected

• A revoked code answers invalid with no certificate detail; an erased account's certificate is not found — each honest, neither pretending the certificate never existed in the staff record.

Steps

1. Open /admin/economy/operations.
2. Read every figure group; press Read again.

Expected

• "Worked out …" stamp and a Read again control; every figure states its window (current Credit months, ended months in the last 31 days, etc.).
• Figures include: months running (count, base granted, continuation granted + grants), Credits captured by action, holds released, cleared unused Credits, failed grants, and paused reward notices with the oldest's age.
• Nobody is named or ranked anywhere on the page.

Preconditions

Catch the page while a read fails, or note the behaviour wherever a figure cannot load (mark N/A if unreachable).

Steps

1. Observe a figure whose source is unavailable.

Expected

• That figure says "Could not be read just now." — a failure is never rendered as 0, and a genuine zero still shows as 0.

Steps

1. On this deployment, read the Credits figures.

Expected

• With generated assistance off, Credit figures may read zero or empty — stated honestly (e.g. no months running), never populated with invented activity; the screens still exist and still read.

Steps

1. Open /admin/economy/failed-rewards.
2. Read rows; Load more if offered.

Expected

• Rows: the reward and its category (Achievement / Level-up), the learner's name linking to their person ("A learner with no name on record" otherwise), what's owed, when it paused, tries, and the last failure in words.
• Paginated oldest-first (50 a page); the Operations hub's failed-rewards row counts the same set.
• Admin reads the whole list; there is no write-off option.

Preconditions

A row in the failed-rewards list.

Steps

1. Retry one row through the main-site check.
2. Check the learner's notices and balance.

Expected

• On success the row leaves the list and the same notice delivers once; on another failure it stays, with a new try counted.
• The retry can never pay a learner twice for one reward.

Steps

1. With several failed rows, use Retry all (with a stale main-site check, then a fresh one).

Expected

• A stale check asks first ("Confirm on the main site first.") before anything runs.
• Retries proceed in bounded batches (100 a transaction, page after page); the run stops at the first refusal and reports where it stopped — it never ploughs through a refusal.

Steps

1. Open /admin/economy/configuration.
2. Read all three groups and the Progress-owned values.

Expected

• Three groups: membership allowance (base 0–5,000, continuation 0–5,000), first-solve XP (Easy/Medium/Hard/Extreme, each 0–500), other awards (default Daily bonus 0–200; written-subject award 0–1,000).
• Each setting shows the in-force value, the standard value, its allowed range, its effective scope, and who/when last changed it.
• Progress-owned settings (active time 15–480 default 120; practice evidence 0–100) are visibly labelled as owned elsewhere — readable, not editable here.
• Each group states its changes govern later occasions only — not existing grants, cycles or results.

Steps

1. Change two values and type a reason; inspect the save bar.
2. Confirm through the main-site check; read the resulting entries.

Expected

• The save bar counts the changed values; confirm lists each change old → new before it applies; a reason and the fresh main-site check are required.
• The audit records the settings change with old/new values and the reason.

Steps

1. Enter one valid change plus one out-of-range value (e.g. base allowance 6000, or Easy XP 501).
2. Try to save.
3. Set a value back to its standard and save.

Expected

• The set is rejected as a whole, naming the invalid field — nothing is half-saved, and your typed values remain to fix.
• A stale preview must be rechecked: if the in-force values changed since you read them, the save asks again rather than overwriting blindly.
• Saving a value equal to the standard removes the override — the setting reads "The standard value is in force."

Steps

1. Open /admin/economy/correction; pick a learner (search or ?person=).
2. Read "Account now"; enter a direction and amount; watch the preview; apply with incident/reference + reason through the check.

Expected

• Steps: the person → the account now → the correction with a live preview (current, signed change, resulting balance/level) → Apply.
• Apply restates the typed change in words ("deduct 300 XP" / "add 50 Credits"), asks for an incident or reference where applicable plus a reason, and passes the main-site check.
• It repairs one accounting error — it is never presented as a gift, a test result or an achievement.

Steps

1. Try XP −100,001 and Credits +10,001.
2. Try a deduction taking the balance below zero.
3. Enter a non-number.

Expected

• Over-limit amounts are refused with the allowed bound stated — the number is never quietly trimmed to fit.
• A deduction below zero is refused; an invalid amount shows a field problem and no preview.

Steps

1. Apply a correction; then apply the same form again (re-submit).
2. Read the learner's XP history and the audit.

Expected

• The original entry is never edited — the correction is a new entry beside it; audit records economy-corrected with the reason.
• Re-applying the identical form returns the same recorded result (idempotent) — the balance moves once.
• The learner sees the reason and reference, never who applied it.

Steps

1. Pick your own account; pick an account being erased; where staging allows, a Credits correction on a learner with no open Credit month.

Expected

• Own account and being-erased refuse in words (including inside the preview).
• No open Credit month is stated plainly instead of silently creating one.

Steps

1. Open /admin/economy/extra for a learner.
2. Read the month figure and the extras added so far; try an amount over the headroom (max 5,000 a cycle).
3. Add a valid amount with a reason.

Expected

• The page shows the learner's current Credit month and how much extra has been added so far; an amount beyond the remaining headroom is refused with what's left — never trimmed.
• A reason is required; the write is gated and audited (economy-credits-added); the learner's history labels it "Extra Credits added by staff" without the reason or the name (and, while generated assistance is off, the learner may never see it — honesty either way).
• It is not a correction and not an ordinary reward; repeated identical applies are idempotent.
• Refusals: picking your own account or a being-erased account refuses in words — no form submits.

Steps

1. Open /admin/topic-requests.
2. Search title and description text; cycle the status filter.

Expected

• Newest first; search matches title and description; the count is of the filtered set.
• Retracted requests are omitted by default and appear under their filter state only; every status's count is shown when actually counted.

Steps

1. Open a request from the queue.

Expected

• Panel beside the queue at ?request=…: title, where it was asked from (topic, difficulty, the words searched "…"), filed date, status-changed date, a "staff" mark on staff-filed requests, and the full description.

Steps

1. Approve one request; within ~6 s press Undo on the toast.
2. Approve another and let the toast lapse; check the learner's notices.

Expected

• The status flips immediately and a toast offers Undo for roughly six seconds.
• The learner notice goes only after the Undo lapses; an undone move reads "undone" in the request's history and notifies nobody.

Steps

1. Move a request backward (e.g. approved → pending); read the confirm.
2. Select the status the request already has.
3. Make a transition that requires a reason, leaving it empty.

Expected

• Non-approve/reject moves ask for confirmation and a reason where the transition needs one.
• Choosing the current status is a no-op — no change, no notification, no history row.
• A missing reason leaves the state unchanged.

Steps

1. Edit the team note on a request (≤2000 chars); save.
2. As the requesting learner, view the request.

Expected

• The note saves when changed (save disabled until it differs); the learner never sees it — their view carries title, status and linked content only.

Steps

1. On an approved request, find published learner-openable content by title and link it.
2. Try "Mark implemented" with no links, then with one openable link.

Expected

• Only approved learner-openable content is offered; up to five items link while pending/approved.
• "Mark implemented" is disabled until at least one linked item is openable — the state cannot be set on dead links alone.
• On implementing, the requester's notice names the linked content.

Steps

1. As Admin, open an implemented request — look for link editing.
2. As Super Admin, replace a link with a reason through the main-site check; try removing all links.

Expected

• Admin reads the links without Remove or search controls.
• Super Admin replaces links with a reason and a fresh main-site check; the set can never drop to zero valid links — the last one is protected.
• The change is audited with the reason.

Steps

1. Read a request's history after several transitions and an undo.

Expected

• Grouped by day: who moved it, from → to status, note edits, link changes, reasons — each with a time; undone moves are shown muted as "undone".

Preconditions

A request filed by an account that has since been erased (mark N/A if none).

Steps

1. Open that request's panel and history.

Expected

• Team notes and change reasons are erased; statuses, dates and links remain — the history reads that honestly rather than showing blanks.

Steps

1. Approve → undo → approve again; watch the requester's notices after each lapse.

Expected

• The learner gets one notice per effective decision — undos and no-change re-selections never stack duplicates.

Steps

1. Open /admin/broadcasts.
2. Type a title >120 chars and a message >4000; then valid text.

Expected

• Over-limit text stays whole in the field, the field says it's too long, and Send is disabled — nothing is truncated silently.
• The preview shows exactly what learners see — the bell row and the opened notice.
• The audience estimate reads "up to N learners" or honestly "could not be estimated" — never a fake count.

Steps

1. Compose a valid broadcast; press Send; read the confirmation.
2. With a large or unestimated audience, read the second confirm.

Expected

• The confirm states it goes "as a System notice, sent in your name" and "Delivered notices stay: they cannot be edited or recalled."
• A large or unestimated audience asks once more ("Confirm once more … Send to them all").
• The confirm passes the main-site check; the typed words and the broadcast id survive the handoff.

Steps

1. Confirm a send; re-press send / double-click during the operation.
2. Check a staff account's bell and a learner's bell.

Expected

• "It is sending. Follow its delivery on Broadcasts." — delivery continues if you close the page.
• Re-pressing the same form produces the one broadcast (same id), not two.
• Staff accounts receive nothing; learners with System notifications off are counted under "System off" rather than delivered.

Steps

1. Open /admin/broadcasts/history as Admin.
2. Open a broadcast's side panel (?broadcast=…).

Expected

• Table: title, sent-by, sent time (IST), estimate ("Not estimated" where so), Delivered (a meter while delivering), System off, and state chip Delivering / Delivered / Stopped / Failed.
• Side panel adds the body, sender, all timestamps, delivered count, System-off count, finish time, and stop-by/when/reason where stopped.
• No recipient identity and no read/open tracking anywhere.

Steps

1. While a broadcast is Delivering, open its panel and choose Stop.
2. Type a reason; confirm through the main-site check.

Expected

• The confirm states: "Delivery to the learners it has not reached yet stops. What was delivered stays: this is not a recall, and it cannot be resumed."
• The state becomes Stopped with the reason and your name; delivered notices remain; no resume control exists.
• Stopping an already-finished broadcast reports "It had already finished delivering … nothing was stopped."

Steps

1. Stop the same broadcast twice; re-submit a sent form.

Expected

• The second stop is a no-op; a re-submitted send maps to the same broadcast id rather than sending again.

Steps

1. As Admin, open /admin/broadcasts and a delivering broadcast's panel.

Expected

• /admin/broadcasts shows the SA-only message; the history panel shows no Stop control for Admin.

Steps

1. Open /admin/wizbit/kb.
2. Cycle the views (All / Due for review); read where-tags.

Expected

• Every answer is listed including drafts; review state chips read "Never reviewed" / due honestly.
• Where-tags read "Anywhere" or name the places an answer serves.

Steps

1. Use the find/try-a-question field; ask something a published answer covers, then something it doesn't.

Expected

• The result shows what a learner would be told now — and the test counts for nothing (no analytics, no evaluation-set change).

Steps

1. Open an answer; read every field and the preview.
2. Walk the lifecycle: Save draft → Publish (or Submit for approval under the publishing switch) → Archive → Return to Draft → Delete where offered.

Expected

• Fields: question, answer, synonyms, tags, and the "way to learners".
• The learner preview shows what they'd see; lifecycle actions use the product words — Return to Draft (an action, not a state), Archive, Delete — each with its own dialog and consequences.
• Archived/deleted answers stop being served as promised (re-try the question to prove it).

Preconditions

Two staff sessions on the same answer (mark N/A if a second staff session can't be staged).

Steps

1. Session A edits and saves; session B, which opened earlier, saves different text.

Expected

• B's save is refused as a conflict — nothing is merged or overwritten; the note offers A's saved version for comparison.

Steps

1. Open /admin/wizbit/responses.
2. Read the message set for several moments in Companion and Plain previews.

Expected

• Each moment's approved set is shown in both the companion's voice and the plain voice — side by side as learners would meet them.
• A draft starts from the suggested or published set or an earlier one; places whose set differs from today's moments are named as problems to fix.

Steps

1. Draft a change to a moment; publish (Admin under an On switch) or submit (switch Off / SA path as applicable).

Expected

• Publishing/submitting passes the protected gate; under "Allow Admins to publish: Off" an Admin's button reads Submit for approval instead of Publish.

Steps

1. Open /admin/wizbit/kb-administration.
2. Try an out-of-range threshold; preview against test questions; save thresholds + test questions together with a reason.

Expected

• Thresholds are decimals bounded to hundredths; an out-of-range value is refused.
• The preview runs against staff's own private test questions only — never learners' real questions; outcomes read in words (Answers / Offers topics / No clear answer).
• Thresholds and the evaluation set save together with a reason through the main-site check; test questions are saved as a whole set.
• Private test questions never appear as learner content.

Steps

1. Open /admin/wizbit/identity.
2. Read artwork sizes and expressions; change the accent; save.

Expected

• Only approved artwork is offered (four sizes + expressions); no uploader, no name editor.
• Accent offers the theme's own or the five tints (Ember, Jade, Orchid, Glacier, Azure), contrast-checked; an invalid/unavailable asset is refused rather than half-applied.
• Saving goes through the main-site check.

Steps

1. Open /admin/wizbit/nudges.
2. Read every control; save a change with a reason.

Expected

• The controls only reduce: once-a-day vs off, lengthening the wait for the same suggestion — nothing raises the ceiling, shortens the quiet hour, or adds a new kind.
• There is no per-learner intervention or permission system here.
• Saving requires a reason through the main-site check and lands in the audit.

Steps

1. As Admin, open /admin/wizbit/kb-administration, /admin/wizbit/identity, /admin/wizbit/nudges; then /admin/wizbit/kb and /admin/wizbit/responses.

Expected

• The three SA pages read "Only a Super Admin can open this page."; the staff pages work normally.
• With generated assistance off, none of these screens vanish — they read honestly instead of 404ing.

Steps

1. Open /admin/analytics/reporting; cycle Participation / Content review / WizBit use.
2. Change the period; reload; check the address.

Expected

• The tab lives in the address; the period (7/30/90 days) is shared across tabs and survives a reload.
• Everything is aggregate and anonymous: staff activity and tools are excluded; no learner is ever named or ranked.

Steps

1. Read the Participation tab for each period.

Expected

• Each area shows learners and minutes over the period, "Any area" last; a genuinely quiet area reads 0 rather than being hidden.
• First-time vs returning are defined where used; the computed-read time is stated.
• No activity, insufficient data and a failed calculation are three different readings — never the same empty table.

Steps

1. Read the Content review tab; open a flagged item.

Expected

• Flags are reason words — No primary skill / Few solve it / Almost everyone solves it / Many submissions per solve / Most learners open a hint — with the population and threshold stated.
• An item opens its owner's admin page; a flag is presented as a prompt to look, never a verdict.

Steps

1. Download a report; open the CSV; check the audit as Super Admin.

Expected

• The export is recorded first (audit report-exported, Super-Admin-readable); the filename carries the view, the period and the IST time (e.g. participation-30-days-…-IST.csv).
• The first line states coverage and when it was worked out; no personal detail anywhere; cell content is formula-safe.

Steps

1. Open /admin/analytics/home-suggestion; read the current card.
2. As Super Admin, pick a new published destination, add an optional line ≤140 + reason; confirm through the check.
3. Try an unpublished or unopenable item.

Expected

• The current suggestion is shown as learners see it, or honestly "Nothing is suggested", with who chose it and when.
• An unopenable destination warns "Home shows nothing in its place" rather than letting a dead card go live.
• The change is audited; Admin reads the page without the change controls.

Steps

1. Open /admin/analytics/next-action-mappings; read the table.
2. Change one cell's destination via the chooser + reason + check.
3. Try a destination that doesn't exist / isn't openable.

Expected

• The table maps skill stages to destinations (Learn → course/lesson, Practise → challenge/track, Assess → Mock paper, Applied work → template).
• An unopenable destination is refused — no mapping may point at something learners can't open.
• Every change needs a reason and is audited with previous → new mapping.

Steps

1. Open /admin/analytics/skill-evidence-reset; find a learner (User-role list).
2. Choose "Reset skill evidence…".

Expected

• It lands on /admin/people/<identity>/reset?scope=skills with the Skills scope chosen — the identical preview, confirm, run and audit as any person reset. No separate, weaker policy lives here.
• Admin gets the SA-only message on this page.

Steps

1. Open /admin/language-registry; read several languages' rows.

Expected

• Each language shows name + version, availability (Available / interactive-only / Coming soon / Off), and a per-service lane reading Running / Not running / Not yet / Could not be asked / Not offered.
• Nothing is editable — the registry is committed with the platform; the page says so.

Steps

1. Read a coming-soon language and any lane whose service can't be reached.

Expected

• A coming-soon language's lane reads "Not yet" — a neutral future, not a fault.
• An unanswerable lane reads "Could not be asked" — an unknown is never downgraded or upgraded into "Not running".

Steps

1. Open /admin/maintenance-windows; start declaring.
2. Try a past start, an end before the start, an end >7 days out, an explanation >300 chars.
3. Complete validly; read the live banner preview; declare through the check.

Expected

• Fields: start now/later, expected end (≤7 days after start), affected capabilities (grading / interactive programs / file storage), learner explanation ≤300 chars.
• Field problems are called out as chosen and refuse again at the server — Declare stays back until valid.
• The learner banner preview updates beside the form; declaring passes the main-site check and is audited.

Steps

1. Declare a window; double-press Declare; read the list.

Expected

• One window appears (the same id folds double-clicks), reading Scheduled with its details.
• States move through Scheduled → In progress → Ending → Overrunning → Ended, or Cancelled — honestly, when the worker measures them.

Steps

1. With a scheduled window starting within a day, and again while one is in progress, view the app as a learner.
2. Cancel the scheduled window and watch the banner leave.

Expected

• The banner shows for active windows and ones starting within ~24h: affects, times and the explanation, with "taking longer than expected" while Overrunning.
• An Ending window reads the same as In progress — nothing new appears; after cancellation or Ended the banner leaves within about a minute.

Steps

1. Look for a "Force healthy" / "End now" control on an in-progress window.
2. Watch a window cross its expected end.

Expected

• There is no manual End or Force-healthy control anywhere.
• When the expected end passes the window reads Ending — "waiting for the first check after its expected end" — and becomes Ended only once the affected capabilities measure healthy; otherwise Overrunning.

Steps

1. Cancel a Scheduled window through its confirm + main-site check.
2. Look for cancel on an In-progress window.

Expected

• Cancellation is offered only before start, behind a confirm and a fresh main-site check; in-progress windows cannot be cancelled.
• The window reads "Cancelled" and drops off the banner; the act is audited.

Steps

1. While a window is in progress / overrunning, read the hub's Maintenance signal.

Expected

• Maintenance reads Degraded while a window is in progress, ending or overrunning, and names the next planned window otherwise — not a fabricated Healthy during a window.

Steps

1. Open /admin/identity-delivery.
2. Read the waiting list and the verified list (Load more if offered).

Expected

• Waiting, oldest first: person link, the change kind in words (signed out / password changed / account deleted / role, membership or identity changed), sent time, due-since, tries, last failure in words.
• Verified: 100 a page with Load more and a "how many it shows" line — not a fabricated total; the window is bounded (~180 days).
• Change kinds stay distinct — signed-out, password, account-deleted and role/membership/identity changes never collapse into one generic "change"; each row's verification state is visible.

Steps

1. On a could-not-be-verified row, use "Ask the main site again" through the check.
2. Look for the control on a verified row.

Expected

• The re-ask exists only where verification failed; it is audited ("Asked the main site again about a change").
• Asking on a non-failed row changes nothing; the retry is idempotent.

Steps

1. Scan the page for any edit, create or delete control.
2. Open the address as Admin.

Expected

• The page is a record plus one retry — no control edits, invents or discards a main-site change, and no role is ever assigned here.
• Admin gets the SA-only message; the hub still shows them the row's count with "A Super Admin follows these up."

Steps

1. Open /admin/audit as Super Admin.
2. Read the rows and group headers; Load more.

Expected

• Grouped by IST day, newest first; each row reads "Action: item · time · who" with the who being a staff name + role or "The platform, automatically".
• Stable paging — Load more appends without reordering or repeating rows.

Steps

1. Open the audit as Admin; open the Show/action filter.
2. Compare with Super Admin's filter.

Expected

• Admin's Show filter offers only content-kind actions (publications, approvals, skills/topics changes…); settings, people and platform actions are absent — and the page lead says the Admin sees a subset.
• Super Admin's filter lists the full ~80 action types.

Steps

1. Set an action filter; type in Who; type in Item (watch the ~350 ms debounce); set From and To.
2. Reload; remove a chip.

Expected

• Item and Who search debounce (~350 ms) rather than firing per keystroke.
• All filters show as removable chips and persist in the address — a reload reproduces them.

Steps

1. Set From later than To (with other filters applied); read the page.

Expected

• The page says exactly: "From is after To, so the dates were not used."
• The other filters still apply; the dates are ignored rather than quietly swapped or blanking the list.

Steps

1. Click an entry; read the ?entry= panel.
2. Deep-link an entry not in the loaded pages.
3. As Admin, open a Super-Admin-kind entry's deep link.

Expected

• The panel shows item, kind, who, when, the change (from → to where it applies) and the reason where one exists.
• A deep-linked entry reads on its own even when it isn't in the loaded page.
• Admin opening an SA-kind entry gets a privacy-safe not-found — not the detail, not an error.

Steps

1. Look for any edit or delete affordance on entries or the list.
2. Compare "no entries", "no matches", and a failed read where catchable.

Expected

• No edit or delete exists anywhere; attribution never rewrites history (a suspended admin's past actions still carry their name).
• Empty vs no-matches vs failed-read are three different messages; totals are never manufactured.
• Private learner body content and report notes are never copied into a generic audit row.

Steps

1. Open /admin/settings/publishing; read the switch and the last-changed stamp.
2. Toggle it; read the confirm dialog.

Expected

• The page shows the switch ("Allow Admins to publish"), what On and Off each mean, and when it last changed + by whom.
• Confirming shows "Allow Admins to publish?" / "Stop Admins publishing?" with the explanatory text — and it warns there is no undo (you change it back by changing it again, recorded).
• The confirm passes the main-site check; the audit records the change old → new.

Preconditions

A failed save to stage (offline at confirm, or a refused check; mark N/A if not stageable).

Steps

1. Attempt the toggle while the save cannot succeed.

Expected

• "Not saved: … The switch is still on/off." — the control snaps back to what the api last confirmed; nothing pretends to have flipped.

Preconditions

Coordinate — flipping this changes Admin publish behaviour globally; restore it afterwards.

Steps

1. With the switch Off, open a studio as Admin and read the publish control.
2. Turn it On; re-check; read the Operations hub header as SA.
3. Restore the previous state.

Expected

• Off: Admin content flows through Submit for approval (queued drafts are unaffected); On: Admin can Publish directly per the domain's own rules.
• The hub's "Admins publish: On|Off" matches; the setting grants authored-content publication only — it is not a role assignment or a permission editor.

Steps

1. As Admin, open /admin/settings/publishing.

Expected

• "Only a Super Admin can open this page." — no switch, no current value leaked.

Preconditions

A completed Mock/Company test with events (run one with strictness on first if needed).

Steps

1. Open /admin/tests/<the test>/recorded-events.
2. Read the facts header and the event list.

Expected

• Header: learner, started, ended with the ending in words, state (+ Archived / a grading-since warning where it applies), strictness and the counted-event ceiling.
• Events list oldest-first in "what happened" words, each with a counted / not-counted chip, and a summary "N counted of M recorded".

Steps

1. Open recorded-events for a strictness-off test, and for a test that recorded nothing.

Expected

• Strictness off: "Nothing was recorded … That is the setting, not missing information." — distinct from a genuine "Nothing was recorded during this test."

Steps

1. Read the whole events page looking for recordings, clipboard/source content, hidden cases or inferred motives.

Expected

• Facts only — event names, counts, times. No recording playback, no clipboard or typed source, no hidden-test content, no "cheating" verdict.

Steps

1. On an ended, not-yet-invalidated test, open /admin/tests/<test>/invalidate.
2. Read the reason choices; pick one; write the staff note (≤500); confirm through the check.

Expected

• The link/control exists only for Super Admin, on an ended test, not already invalidated; Admin reads the page without it.
• Steps: reason (the four neutral choices, each previewing what the learner is told) → staff note (required, ≤500, SA-only) → confirm listing consequences → done; the confirm passes the main-site check.

Steps

1. After invalidating, read the test's row in history, the learner's results/readiness/skills, and the learner's notice.

Expected

• The history row is kept, marked Invalidated with the neutral reason — never deleted.
• The result, marks, readiness and skill evidence it fed are removed as invalidated; fresh-test eligibility is restored unless the test was archived.
• Any Mock rewards it paid are reversed exactly once — the amounts become re-earnable, with no double reversal.
• The learner's notice gives the neutral reason without the staff note; the invalidation is audited and idempotent.

Steps

1. Open …/invalidate on the test invalidated above, and on a still-running test.

Expected

• Already invalidated: "Already invalidated" plus the Invalidation section (reason, the SA-only note, by whom).
• Still running: "Not yet" — "Only a test that has ended can be invalidated."

Preconditions

An ended test belonging to an account mid-erasure.

Steps

1. Open its invalidate address.

Expected

• Refused with the same "being erased" sentence as every other person action — no form.

Steps

1. With a stale main-site check, attempt one protected write in each of three different areas (e.g. suspend, broadcast send, economy save).

Expected

• Each one routes through "Confirm on the main site" and returns to the same dialog/page with everything typed held — the handoff pattern is uniform, not bespoke per screen.

Preconditions

Coordinate: an account's role changed on the main site while a staff session is open (or simulate by sign-out/sign-in).

Steps

1. With a staff session open, remove its staff role on the main site; continue working in the console.

Expected

• Privileged actions stop being granted once the role no longer holds — a stale main-site check or a cached page never confers authority; the next protected write asks and fails honestly.

Steps

1. Revisit each area: the hub's signals and rows, people headlines, economy figures, registry lanes, broadcast estimate, audit list.

Expected

• Everywhere an "unavailable/unknown/could-not-be-read" state appeared during your run, it was named as itself — never silently rendered as 0, an empty list, Healthy or Not running.

Steps

1. Wherever a section failed during the run (a headline figure, a panel section), check the surrounding sections.

Expected

• A failed part degrades alone — the rest of the panel/page keeps showing what it could read, each with its own freshness.

Steps

1. Re-read every screen visited in this doc (or use a text search across them).

Expected

• People-facing copy says Wizly Learning — never "Labs".
• Actions say Suspend / Ban / typed-name confirm / Return to Draft (action, not state); credits speak of a relief grant, holds of reserved / captured / released; "try" and "test" where the product does — no "attempt", "unpublish" (for Return to Draft), "retention hold", "gift".
• Times and dates are labelled IST; numbers use Indian grouping.

Steps

1. After a testing session, open /admin/audit as Super Admin and find each write you performed (suspension, reset, hold, certificate action, correction, broadcast, mapping change, publishing toggle, invalidation).

Expected

• Every one is present with your name, the item and the reason where required; nothing wrote silently. Platform-side transitions (a suspension reaching its end, a scheduled window starting) are attributed to "The platform, automatically", never to a staff member.

Steps

1. Walk the main staff pages at 390, 768, 1280 and 1440 px in light and dark.

Expected

• Tables scroll or reflow without losing columns' meaning; the console dock and panels behave as on the hub; dialogs stay inside the viewport; nothing is unreadable in dark.

Steps

1. Operate a moderation dialog, a side panel and a table with keyboard alone; repeat with reduced motion on.

Expected

• Dialogs trap and release focus correctly; every confirm and field is reachable by keyboard; focus is visible; reduced motion calms transitions without breaking them.