04 · Admin — Content & Studios

Preconditions

Signed in as Admin (tester-staff-1) on a computer-width viewport.

Steps

1. Open /admin.
2. Read the navigation and the header, then open the Content space.

Expected

• Seven spaces, always expanded, in this order: Operations, Content, People, WizBit, Messages, Insights, System.
• Operations holds: Operations, Submissions, Content reports. Content is one plain list in the order learners meet the areas: Courses, Video courses, Daily Challenges, Challenges, Tracks, Debug cases, Aptitude, Typing Quest, Mock Tests, Company Tests, Workspace templates, Skills and topics, Content sources.
• Content gaps sits under Insights (not Content); Home suggestion under Insights; Runtimes, Maintenance, Main-site changes, Audit history under System; Broadcasts under Messages.
• The header carries the health light and the account menu; the Operations hub is the landing page.

Also try

• Open a page from another space — the shell persists; only the page body changes.

Preconditions

Signed in as Admin; at least one challenge exists to open.

Steps

1. Open /admin/challenges, then one challenge's studio.
2. Read the breadcrumb. Resize to 390 px and read it again.

Expected

• Breadcrumb names real pages only — the space as plain text, the page matched by its pattern (e.g. Content · Challenges · the challenge).
• On a phone width it folds to one link, to the nearest page above; where the page's own header has a way back, the breadcrumb steps aside — one way back, never two.

Preconditions

Signed in as Admin; browser at ~390 px (or a phone).

Steps

1. Open /admin.
2. Look at the bottom of the screen; open More.

Expected

• A bottom dock holds Operations, Content, People and More.
• More opens the other four spaces (WizBit, Messages, Insights, System). There is no drawer.

Preconditions

Signed in as a learner (tester-learner-1).

Steps

1. Open /admin.
2. Open /admin/submissions, then a nonsense address such as /admin/banana and /no-such-page.

Expected

• Every one renders the same plain not-found page — no console navigation, no staff page titles, no hint that the page exists but is forbidden.
• The learner's own shell is unchanged; this is privacy-safe not-found, not an error.

Preconditions

Signed in as Admin.

Steps

1. Open /admin/settings/publishing.
2. Open /admin/vocabulary.
3. Open a submission's review address /admin/submissions/<id> if one exists.

Expected

• Each renders "Only a Super Admin can open this page." inside the shell — not a crash, not the page's own content, and never a partial render of protected controls.
• The same result from a direct address as from any link.

Also try

• /admin/tests/:test/invalidate on a real test id — same message for an Admin.

Preconditions

Two browsers or two sessions available: one Admin, one Super Admin. 🖥🖥

Steps

1. As Admin, read the full console navigation.
2. As Super Admin, read it again.

Expected

• Destinations appear only when the role permits them: the Admin does not see Skills and topics, Publishing (under System/settings), WizBit matching, WizBit look, WizBit nudges, Maintenance, Main-site changes, Send a broadcast, name corrections, economy settings/corrections.
• The Super Admin sees them all.
• A shared staff destination (Submissions, Content reports, Challenges) renders for both.

Preconditions

Signed in as Super Admin.

Steps

1. Type /admin/submissions into the address bar directly (not via nav).
2. Type /admin/definitely-not-a-page.

Expected

• A direct address receives the same access decision as its navigation link — the submissions queue opens.
• An unknown /admin/* address renders a not-found inside the console shell (Coming soon is only for listed-but-unbuilt pages like /admin/aptitude).

Preconditions

Signed in as Admin.

Steps

1. From the account menu or address bar, open a learner page: /challenges, then a published challenge.
2. Run and Submit a solution as the staff account.

Expected

• Every learner page opens for staff; where spec'd, staff extras appear (e.g. the way to the item's editor).
• Staff activity earns no XP and stays out of learner-facing counts (solve rates, participation figures) — the staff solve is not counted in the challenge's public Solve rate.

Preconditions

The same staff account signed in from two browsers. 🖥🖥

Steps

1. Sign in as tester-staff-1 in browser A.
2. Sign in as the same account in browser B.
3. Return to browser A and navigate or act.

Expected

• Browser A is told the account was opened on another browser or device — the "opened on another browser or device" notice — and is not silently signed back in.
• Work already typed in browser A's page stays on screen under the notice; nothing is silently discarded.

Preconditions

Signed in as staff.

Steps

1. Find the health light in the console header on /admin.
2. Press it.
3. Watch it over a couple of minutes with the tab visible, then hidden.

Expected

• It shows one word from the hub: Healthy, Degraded, Down or Unknown — never a colour alone (Unknown is a hollow dot, never one that reads as fine).
• Pressing it opens /admin (the Operations hub — its detail is doc 05).
• It reads about once a minute while the tab shows, and not while hidden. On a phone a healthy light collapses to its dot; other states keep their word.

Also try

• Block /api/v1/admin/operations/health in dev tools → the light reads Unknown, never Healthy.

Preconditions

Signed in as staff.

Steps

1. Open /admin/aptitude.

Expected

• "This page is coming soon." renders inside the console shell with same-domain links — never a blank page or an error.
• It is the only unbuilt staff page; every other console address in this doc renders its real screen.

Preconditions

Signed in as Super Admin; note the current state first and tell the team you are changing it.

Steps

1. Open /admin/settings/publishing.
2. Read the current state, then flip Allow Admins to publish.
3. Confirm — the main-site check must be fresh — then reload the page.

Expected

• One global on/off for all Admins — no per-person switches, no permission matrix.
• Changing it asks for explicit confirmation and a fresh main-site check; the change and its old/new values are audited together.
• The persisted value survives reload and reads the same in a second browser.
• Put it back when done and note the restored state in the case notes.

Preconditions

Signed in as Super Admin; dev tools open.

Steps

1. Block the write request (devtools network blocking or offline).
2. Try to flip the switch and confirm.
3. Unblock and reload.

Expected

• The change fails honestly — no optimistic flip that silently reverts.
• After reload the switch shows the old persisted value; nothing half-applied.

Preconditions

Switch ON. Signed in as Admin; a checked challenge draft ready ("QA-VK 15 Nov — publish me").

Steps

1. In the challenge studio, press Check and publish.
2. Confirm through the main-site check if asked.

Expected

• The lit button offers Publish/Update — not Submit.
• The challenge goes live at once on /challenges for learners; nothing waits in Submissions.
• Validation, protection and domain rules still apply — the switch grants publication only, not approval powers, Unpublish, Archive or protected settings.

Preconditions

Switch OFF. Signed in as Admin; a checked draft ready.

Steps

1. Press Check and submit for approval.
2. Where the studio offers a reviewer note (course builder, typing studio), write one up to 500 characters; submit.

Expected

• The item enters Submissions as Waiting; the studio shows who submitted it and when.
• The Admin retains preparation rights — drafts still save — but cannot publish, approve, Unpublish or Archive.
• The note is readable by the reviewer in the submission's review.

Preconditions

🖥🖥 Admin has a studio open; Super Admin in a second browser.

Steps

1. With the switch ON, the Admin leaves a checked draft open.
2. Super Admin turns the switch OFF.
3. The Admin presses Check and publish.

Expected

• The publish is refused and the refusal is said; the item is read again without a reload.
• Publish becomes Submit for approval with the draft kept — a press of Publish is never carried out as a submission, nor Submit as a publication.
• Turning the switch off does not withdraw published content, and turning it on does not publish queued drafts.

Preconditions

Any published item you can edit (a draft copy of a challenge is safest).

Steps

1. Publish the item; open it as a learner in a second tab.
2. Edit its statement and let the save land.
3. Look at the item's status in the studio and the staff list; refresh the learner tab.

Expected

• The item is marked as having changes not live until republished.
• The learner still reads the last published revision — a failed or unfinished update never replaces valid live content.
• A draft saved back to the live version (change made then removed) reads Live again, with no false "changes not live".

Preconditions

Switch OFF; at least two Admin submissions exist (create them if needed).

Steps

1. Open /admin/submissions.
2. Read the Waiting view; switch to Decided.

Expected

• Waiting lists oldest first — nothing waits longest out of sight. Each row: title, its kind label, the submitter, and the submitted time.
• Decided lists newest first, each with its state chip: Approved and published, Sent back, or Superseded — with who decided, when, and the reason where given.
• Empty states are honest: "Nothing is waiting" / "When an Admin submits content for approval, it appears here." and "Nothing decided yet" / "Approved, sent-back and superseded submissions appear here."

Preconditions

Switch OFF; at least one waiting submission exists. Signed in as Admin.

Steps

1. Open /admin/submissions.
2. Open a waiting row.

Expected

• The Admin reads the queue — each row leads to the item's own studio, never to a review pane.
• No Approve or Send back control is offered anywhere; the review address itself (/admin/submissions/:id) is the SA-only page from TC-CON-005.

Preconditions

Switch OFF; a waiting submission exists. Signed in as Super Admin.

Steps

1. Open /admin/submissions, then the waiting submission.
2. Read the review pane.

Expected

• The pane reads "Loading the submission…" until the review arrives — it is fetched apart from the queue.
• It shows the item, its kind, the submitter, the submitter's note (where left, above what was submitted), the check result, what the change replaces, and the source record in force with where it differs.
• Kinds with a learner preview (challenges, Debug cases, Dailies, lessons) offer "Preview it as learners will see it"; kinds without one show the submitted content itself under "As submitted", part by part (a typing text's passage, a paper's sections/questions, a template's files/checklist…); a part over 12 lines or 1,200 characters folds until asked for.

Preconditions

Switch OFF; a waiting submission; Super Admin; note what the submitted revision contains.

Steps

1. Open the submission's review.
2. Approve and publish, confirming through the main-site check.
3. Check the queue, the item's learner page, and the submitter's inbox (submit as Admin first if needed). 🖥🖥 helps.

Expected

• Approval is publication in one action — the exact reviewed revision goes live; a changed-then-approved draft cannot slip extra edits in.
• The row reads "Approved and published" in Decided; the next waiting submission opens for decision (with none, the decided one stays open saying what became of it).
• The submitter gets one inbox notice naming who approved what (title and kind) and that it is live now, opening the item's studio — a course decided with its lessons is told once, naming the course.

Preconditions

Switch OFF; a waiting submission; Super Admin.

Steps

1. Open the review and press Send back… with no reason.
2. Type a reason under 3 or over 300 characters and try again.
3. Send back with a proper reason (3–300 characters).

Expected

• An absent or out-of-range reason performs nothing.
• With a reason: the submission reads Sent back, the draft is returned to its author unchanged, and nothing is published.
• The submitter's inbox notice says who sent it back, carries their note, and asks for changes and a new submission.

Preconditions

🖥🖥 Switch OFF; Admin submits an item; Super Admin has the review open.

Steps

1. Admin submits the item.
2. Admin edits the same draft again and saves.
3. Super Admin opens/reads the submission.

Expected

• The submission reads Superseded — it cannot be approved; the review says it needs submitting again.
• Nothing is published by the stale review; only the draft is kept, so once it has moved on nothing is shown "as submitted".
• Editing a submitted draft takes only that item out of the queue.

Preconditions

A waiting submission; Super Admin.

Steps

1. Open the review; double-click Approve and publish fast.
2. Re-open the same submission's address and try to decide again.
3. Check /admin/audit.

Expected

• One publication, one audit entry — repeating the confirmed decision returns its existing result instead of duplicating it.
• A decided submission offers no second decision; inaction never approves.
• The audit entry records who acted, the item and kind, the time and the change.

Preconditions

Super Admin whose last main-site check is over 15 minutes old (wait, or sign in elsewhere earlier); a waiting submission.

Steps

1. Open the review and press Send back…; type a reason.
2. Confirm — the button should read "Confirm on the main site".
3. Take the trip and return.

Expected

• The confirming button reads "Confirm on the main site" once the check has lapsed.
• You come straight back to the same address; the typed reason was held in the tab and is restored — the same change is confirmed once.
• A typed name confirmation (e.g. a delete) is typed again after the trip — that is the one input not held.

Preconditions

Signed in as staff.

Steps

1. Open /admin/courses/approvals.
2. Open /admin/submissions.

Expected

• /admin/courses/approvals opens the Courses list on its Waiting for approval view.
• The full cross-area queue still lives on Submissions — the course view is a shortcut, not a second queue that could disagree.

Preconditions

Switch OFF; Admin has a course with details and at least one lesson changed; Super Admin for the decision.

Steps

1. Admin: submit the course's choice together from the one Publish dialog with a reviewer note.
2. Super Admin: review from the builder ("Review {n} waiting…") — each item's check, changes, preview and source record.
3. Approve together, then repeat with a send-back on another submission.

Expected

• A waiting item opens read-only until "Edit it"; editing takes only that item out of the queue.
• Approve publishes the chosen items together; send back returns them together with one reason (3–300 characters) the author sees on the course and on each item.
• The submitter is told once, naming the course, however many items were sent.

Preconditions

Signed in as staff; showcase challenges exist plus one archived (create+archive one if needed).

Steps

1. Open /admin/challenges.
2. Type a title search; switch views: All, Waiting for approval, Archived.
3. Change the order: Saved, newest first vs Title, A to Z.

Expected

• Each view says how many it holds for the search as typed; the search, view and order live in the address (?search=…&view=waiting|archived&sort=title).
• A value the list does not know is refused — never quietly dropped.
• Counts and rows agree; a search with no match differs from a failed read.

Preconditions

Signed in as Admin.

Steps

1. From Challenges, create a draft titled "QA-VK 15 Nov — studio check".
2. Fill only the title and part of the statement; stop typing.
3. Watch the save bar; then leave and re-open the draft.

Expected

• The studio is one page with its sections listed beside it: Details, Statement, Languages & Code, Test cases, Hints, Editorials, Limits.
• About two seconds after typing stops the bar reads saving then Saved — an incomplete draft saves fine; incompleteness blocks publish, not saving.
• Reopened, the draft holds what was typed.

Preconditions

A draft open; dev tools for going offline.

Steps

1. Go offline (devtools), type a change; wait.
2. Try the bar's retry; come back online; wait again.

Expected

• Offline, the bar never reads Saved — it reads not saved, tap to retry (or keeps "Unsaved changes" where the studio saves by hand), and backs off after a failed save.
• On reconnection it saves at once and then reads Saved — only ever one of: saving · saved · not saved, tap to retry · saved locally.
• Leaving with unsaved changes asks first; the check never runs on an autosave.

Preconditions

A draft open; a way to paste more than a field's limit.

Steps

1. Paste over-limit text into a bounded field (e.g. a hint or the statement).
2. Wait for the autosave; press Check and publish; try to leave the page.

Expected

• The text stays in the field — never silently cut — but the bar never says Saved while it is there: "Not saved: a field is over its limit. Shorten it to save it."
• Check and publish stops on it; leaving or reloading asks first.
• Shorten it and the save resumes normally.

Preconditions

🖥🖥 The same draft open by Admin in browser A and Super Admin (or another staff account) in browser B.

Steps

1. A edits the title and lets it save.
2. B — whose page read the older version — edits the statement and waits for its save.

Expected

• B's save stops on the conflict and offers Keep mine or Load theirs — the typed work is never silently overwritten or merged.
• Keep mine saves B's text over A's newer version at once (the bar says Saved only once it has); Load theirs brings A's saved content in.
• An item deleted while typed work is unsaved is left at once, without a leave-without-saving prompt.

Preconditions

A draft with at least one hint and one test case.

Steps

1. Remove a hint. Wait, watching the toast.
2. Remove a test case; press Undo within six seconds.

Expected

• The removal applies at once; the toast offers Undo for six seconds and then settles.
• Undo restores the entry — a test case comes back with its values.

Preconditions

A draft missing several required parts (no reference solution, no hidden case, no classification).

Steps

1. Press Check and publish.
2. Fix the named problems; run it again.

Expected

• The check runs on the saved revision — unsaved typing is saved first — and stops at the first failure.
• Each blocking issue is explained at its item/field and leads to the right section; a check that cannot run reads "Not yet verifiable", never Passed.
• Publishing requires: complete title/statement, difficulty and classification, a stated comparison rule, ≥1 visible and ≥1 hidden test case, valid starters and reference solutions — each reference passing every test case, no starter already solving the task.

Preconditions

A draft with a reference solution written and a hidden test case with input but no expected output.

Steps

1. Use the fill-from-reference control on the hidden case.
2. Review each offered value: Accept, Discard, or Accept all.

Expected

• Each produced value is shown for acceptance — marked "From the {Python} reference" until edited by hand, and checked against a second reference where there is one.
• Nothing silently fills expected output; unaccepted values stay empty.

Preconditions

A console challenge draft; where SQL showcase content exists, a SQL item too.

Steps

1. Inspect the comparison settings on the console challenge.
2. On a SQL item, inspect the row-order choice and the schema/datasets it asks for.
3. Find where a numeric tolerance is declared.

Expected

• Console comparison normalizes line endings and ignores one final newline — not all whitespace.
• SQL authoring asks whether row order matters and requires schema and datasets; it validates them in the check.
• Any numerical tolerance is stated explicitly in the learner's comparison rules — never implied.

Preconditions

A draft you can bulk-edit; a way to generate large content.

Steps

1. Try to add a 101st test case and an 11th hint.
2. Try to save a whole document past its 12 MB cap (a challenge/Daily/Debug case/template caps at 12 MB; a lesson or paper at 4 MB).

Expected

• 100 test cases and 10 ordered hints are the ceilings — the controls refuse more honestly.
• A document over its cap is refused with a sentence naming the cap, and nothing is saved — no silent truncation of a collection to what fits.
• Shortening a collection explains which cases, languages or hints will be removed.

Preconditions

A draft with hints and hidden test cases.

Steps

1. Press Preview — it opens in a side sheet.
2. Read it as a learner would; then check the item's learner-facing stats.

Expected

• The preview draws the learner presentation — statement, examples, visible cases — without hidden test cases, reference solutions, internal notes or unrevealed hint bodies.
• It creates no solve count, progress, XP or evidence; it is not an unrestricted run environment.

Preconditions

A published challenge (or a draft meant for publish).

Steps

1. Open the Editorial section / /admin/challenges/:id/editorial.
2. Write an editorial per language; run the check.

Expected

• The editorial is written in its own studio at its own address; it is separately authored learner-facing explanation, never the private reference answer.
• It is validated — its example must pass — and unlocks for learners only after their first accepted solve.

Preconditions

A fully checked draft; a learner signed in elsewhere (or a second browser). 🖥🖥 helps.

Steps

1. Publish the challenge.
2. Immediately refresh the learner's /challenges catalogue and open the item.

Expected

• The new/changed challenge appears to learners at once — publication moves the published-content cache in the same transaction.
• Only the checked revision went live; no partial publish.

Preconditions

A challenge with hints, cases and an editorial — ideally one with learner solves.

Steps

1. From the studio's More menu (or the row's menu in the list), Duplicate.
2. Open the copy.

Expected

• The copy is a new draft with its own address holding the authored material — no learner submissions, rewards, statistics or completion carried over.
• It is independent from then on: edits to either never touch the other.

Preconditions

Super Admin A published challenge with at least one learner solve (use a tagged QA challenge a learner solved if possible).

Steps

1. Super Admin: Unpublish / Return to Draft from the studio.
2. As a learner, look for it in the catalogue and in My Solutions.
3. Republish it.

Expected

• It leaves learner discovery and new activity; the same item returns to draft editable — not a new identity, not Archive, not Delete.
• Earned solves, XP, drafts and retained Solutions survive; the learner's solution still reads its record.
• Republishing needs the ordinary checks and never re-arms first-solve rewards or resets history; the Admin never gets the Unpublish control.

Preconditions

Super Admin A tagged published challenge ready to retire.

Steps

1. Archive it; look at the staff list's Archived view and the learner catalogue.
2. As Admin, confirm no Archive control is offered.

Expected

• Archive removes it from new discovery and solving while preserving earned learner records — a retirement, not a hidden soft-delete; archived items do not silently reactivate.
• Admin has no Archive control at all.

Preconditions

One never-touched tagged draft; one published challenge with learner work.

Steps

1. Delete the untouched draft — it names the item and asks for the typed title.
2. Try Delete on the one with learner work.

Expected

• Deleting an eligible draft: confirmation names it and requires its title typed; mistyped performs nothing; there is no Trash to restore from.
• Where learner work exists, delete refuses or explains the consequence — earned solves/XP/retained solutions are never destroyed; the refusal offers Archive.
• A deleted challenge leaves no broken selectable link anywhere.

Preconditions

Signed in as staff; showcase challenges have learner activity.

Steps

1. Open /admin/challenges-review.
2. Sort lowest solve rate first; filter by review reason if offered.
3. Compare a challenge's rate with what learners see on its page.

Expected

• Staff and learners read the same Solve rate definition on the same population; rates count distinct eligible learners, never repeated tries.
• Small samples read "Not enough data"; a never-submitted item reads as unknown, never a zero-success failure; missing figures say unavailable with no invented denominator.
• Review signals prompt inspection — nothing declares content defective automatically; staff never see learner source here.

Preconditions

Super Admin with a stale main-site check (>15 min); a published tagged challenge.

Steps

1. Try to Archive or Delete with the stale check.

Expected

• The save bar's lit button reads "Confirm on the main site" beside the bar's words saying so — no separate note far up the page asks for it.
• A refused archive/delete is said in the api's words, never as "Not saved", and offers no Try again.

Preconditions

Create near-identical tagged exercises in Challenges and in a track (or note existing ones).

Steps

1. Edit one meaningfully; save and publish.
2. Check the other.

Expected

• Identical exercises in different areas stay independent: no synchronization, no shared lifecycle, no cross-domain completion.
• A track cannot add a live reference to a standalone Challenge; optional companion links are navigation only.

Preconditions

Signed in as staff.

Steps

1. Create a track "QA-VK 15 Nov — track", choosing Python.
2. Add a challenge inside it; look for a language control afterwards.

Expected

• The language is offered at creation from the runtimes the grading service runs.
• Once the track holds a challenge the language is fixed — a different language means a separately authored track, never reinterpreted source.

Preconditions

A tagged track exists.

Steps

1. Create a challenge inside the track.
2. Check its studio's language section and its place in the track's order.
3. Duplicate it; delete the copy.

Expected

• The studio opens fixed to the track's one language; content belongs to this track problem only — never a reference to a standalone Challenge.
• A new or duplicated challenge lands last in the track's order; a deleted one leaves the order, draft and live alike.

Preconditions

A track with at least two challenges.

Steps

1. Move a challenge up and down with the order controls.
2. Publish the track; check the learner-facing order.

Expected

• Order is changed with up/down controls in the track studio and goes live with the track — one deliberate change, never a series of partially applied moves.
• The learner reads the published order.

Preconditions

A tagged track whose challenges are all drafts.

Steps

1. Publish the track itself.
2. Open it as a learner.

Expected

• The track must have published problems before learners can start it — an empty published track offers nothing to begin, honestly.
• Each child publishes on its own; the track's studio shows its challenges' Solve rates.

Preconditions

Super Admin A published track with published challenges and learner progress (use a tagged one if staging).

Steps

1. Super Admin: Unpublish the track.
2. As a learner, try to open the track and one of its challenges through it.
3. Republish.

Expected

• The track and its challenges become unavailable through that track — children are not deleted, reassigned or unpublished themselves.
• Earned track completion, challenge solves, rewards, drafts and retained solutions survive; republishing re-checks and never re-pays them.

Preconditions

Super Admin One untouched tagged track; one with learner work.

Steps

1. Look for Delete on each.
2. Delete the untouched one — confirm its children are named.

Expected

• Delete is offered only while nobody has worked on the track or its challenges; after that the action is Archive.
• Deleting a track identifies its own child problems — it cannot reach standalone Challenges or another track's problems.

Preconditions

Signed in as staff.

Steps

1. Open /admin/daily-challenges; create "QA-VK 15 Nov — daily".
2. Read its sections and the Daily-specific fields.

Expected

• The list reads like the other practice lists — search, views All/Waiting/Archived with counts, orders in the address.
• The open Daily is a state of the page (?item=); the shared sections are present plus the Daily's own part: date and bonus (0–200 XP; a new Daily starts at Economy's default, then is its own).
• An incomplete draft saves.

Preconditions

A checked tagged draft; a free future date (check the schedule).

Steps

1. Press Check and schedule.
2. Choose the free future date; confirm (main-site check).

Expected

• Only a draft whose saved revision passed its check can take a date; scheduling needs a free permitted date and a valid bonus.
• The schedule now shows the challenge on that date — one challenge per date.
• Choosing or moving a date needs no new content check: the date lives apart from the draft.

Preconditions

Two checked tagged drafts; a date already taken.

Steps

1. Try to schedule the second draft onto the taken date.

Expected

• The conflict names the occupying challenge and the date; nothing changes — no overwrite, no queue, no vague error.

Preconditions

Super Admin for freeing; a tagged Daily scheduled on a future date no learner has touched.

Steps

1. Move it to another free future date.
2. Then "Free the date" on it.

Expected

• Moving asks for a confirmation naming both dates (or explaining the date is freed) and lands on the new date.
• "Free the date" returns the challenge to draft unscheduled — freeing a not-yet-begun date is a Super Admin's, like Unpublish.
• Nothing reaches a begun date this way — those are governed by locks and Void.

Preconditions

Switch OFF; Admin; a checked draft.

Steps

1. As Admin, schedule the draft onto a free future date.
2. Check /admin/submissions; then have the date's 09:00 pass before approval if stagable.

Expected

• With the switch OFF the Admin's schedule waits in Submissions for a Super Admin — scheduling is publishing.
• A date whose 09:00 passes before approval stays neutral — no late first publish ever lands.

Preconditions

Signed in as staff; a mix of checked and unchecked drafts.

Steps

1. Open /admin/daily-challenges/schedule.
2. Open the fill offer for a free date.

Expected

• The schedule shows six weeks from today.
• Filling a date offers each draft on no date whose saved revision passed its check — unchecked or already-dated drafts are not offered.

Preconditions

A Daily whose product date has begun (today's, after 09:00 IST).

Steps

1. Open it in the studio; try to edit the date, difficulty, bonus, classification, offered languages, test cases, reference solutions and comparison rule.
2. Edit statement wording instead and save.

Expected

• The grading fields are locked: date, difficulty, bonus, classification, languages, test cases and fixtures, reference solutions, comparison rule.
• Cosmetic corrections are still editable — they do not change grading.
• No generic Unpublish bypass is offered for a begun date.

Preconditions

A begun date with nothing scheduled (or a past empty date to inspect).

Steps

1. Try to schedule a checked draft onto the begun date.
2. Check the learner's calendar for that date.

Expected

• The begun date refuses scheduling — a date that began with no Daily remains neutral that day.
• The learner's calendar reads the date as Neutral (it neither builds nor breaks streaks), never as a missed day.

Preconditions

Super Admin A tagged Daily on a begun date — ideally with a learner solve already recorded.

Steps

1. From the studio's More menu choose Void Daily.
2. Confirm the date and give the reason learners will read; complete the main-site check.
3. Check: the learner page for the date, a solver's record and streak, and try a new submission as a learner.

Expected

• Only a Super Admin voids, with a recent main-site verification; it cannot be undone and there is no Void on a future date (that is Free/unschedule).
• New submissions stop; the date is neutral for everyone — no streak built or broken by it.
• Existing valid solves and awards survive; the challenge still opens for Runs and hints and is not described as missing.
• A submission already received is still graded.

Preconditions

🖥🖥 A learner's Daily page open; a tagged checked draft ready.

Steps

1. Schedule the draft onto a free future date.
2. On the learner side, open that date's future cell / past list where visible.

Expected

• Putting a Daily on a date, moving it, taking it off, archiving, deleting and voiding each move the published view in their own transaction — learners never read a stale schedule.
• Future dates never disclose the challenge's title, difficulty or other hidden content to learners — only that a date is claimed.

Preconditions

Signed in as staff.

Steps

1. Open /admin/daily-challenges/schedule-health.
2. Read each of the next seven dates.

Expected

• Each date reads scheduled, empty or blocked — an empty tomorrow is highlighted.
• A date whose checks cannot run reads an unknown state — never guessed as scheduled or fine.

Preconditions

Signed in as staff; showcase Dailies have history.

Steps

1. Open /admin/daily-challenges/review.
2. Download the CSV and read its first line.

Expected

• It lists the most recent 120 dates, newest first: solve rate, solves on the day vs catch-up, graded submissions, hint use, and the median time from a learner's first graded submission to their solve.
• The CSV's first line states what it covers; figures never include staff or invented denominators.

Preconditions

Super Admin A tagged draft Daily (untouched) and a begun/past Daily.

Steps

1. Delete the untouched draft.
2. On the begun one, look for Delete/Archive and weigh what is offered.

Expected

• Draft deletion follows the ordinary safe rules — names the item, typed title.
• A begun day's grading conditions cannot be casually removed: Archive/Delete cannot silently replace Void Daily — voiding is the explicit operation, preserving solves and making the date neutral.

Preconditions

🖥🖥 A learner able to submit near the boundary (or review records around a past 09:00).

Steps

1. As a learner, submit a correct solution shortly before 09:00 IST on a Daily's date.
2. Let grading finish after 09:00; check the date's standing and the streak.

Expected

• The submission keeps its receipt: received during its date, it counts for that date however late grading finishes — the date reads awaiting its result meanwhile, never a false break.
• A submission first received on a later date is catch-up: full award, but it does not repair a missed on-time date.

Preconditions

Signed in as staff; create a tagged draft case.

Steps

1. Open "The bug" part of the studio.
2. Set planted bugs and bug types; add a "This is the bug" text.

Expected

• Planted bugs accepts 1–10; bug types 1–3 from the curated list (its seeded entries include off-by-one, boundary, state, logic, resource, typo).
• "This is the bug" is one optional text per case; a new draft's Planted bugs says nothing until a number is typed, and the checks' items about them lead to The bug, not Details.

Preconditions

A tagged case draft offered in two languages; only one debrief written.

Steps

1. Run the check.
2. Complete the missing debrief; run it again.

Expected

• The check runs each written language on the grading service: the fix must pass every test case and the broken code must fail at least one.
• Every offered language requires a validated debrief — covering root cause, why the starter failed, the repair approach, an important edge case and corrected learner-facing code — before publish.
• A case offered only in languages the author wrote broken code for — not every graded language.

Preconditions

A tagged case draft.

Steps

1. Set the broken starter equal to the reference fix; run the check.
2. Then make the broken starter pass every test case; run it again.

Expected

• Both are blockers, named at their source: broken and fixed source cannot be identical, and the broken starter must fail at least one case in every offered language.
• Publish also requires ≥1 visible and ≥1 hidden test case with well-formed expected results.

Preconditions

Two tagged case drafts.

Steps

1. Title one normally and let its address generate.
2. Give the second the same address by hand; try an invalid address too.

Expected

• With none supplied, a readable address is generated from the title and shown; a supplied one is normalised as entered and validated against the shared rules.
• An invalid or already-used address is rejected with a clear reason while the draft is preserved; one address resolves to exactly one case.
• Changing a title alone does not silently regenerate an established address.

Preconditions

A tagged case draft.

Steps

1. Set the case to Timed then practice.
2. Try durations outside 5–120 minutes and windows outside 1–10.

Expected

• A new case is Practice only; Timed then practice starts at 30 minutes and three windows.
• Out-of-range numbers are kept as typed and say their range — never snapped silently or saved out of bounds.
• Timed settings are part of what a material change protects (next cases).

Preconditions

🖥🖥 A published tagged case; a learner with a timed window open on it (or stage one if possible).

Steps

1. Change test cases (or offered languages, limits, comparison, minutes/windows) on the live case.
2. Publish the change.
3. Check the learner's window and allowance.

Expected

• Publishing a material change asks first and names the number of windows open as the page read it; a window started after that ends the same way.
• Affected windows end as platform-caused, their allowances are restored and acknowledged code stays recoverable — the learner is never blamed.
• If the impact count cannot be read, the destructive confirmation is blocked — never confirmed against an estimate.

Preconditions

🖥🖥 A published case with a timed window open.

Steps

1. Edit only statement/hint text on the live case and publish.
2. Check the open window.

Expected

• Text-only changes leave open windows as they are — no impact prompt, no ended window, no restored allowance needed.

Preconditions

Super Admin A published case — ideally with an open timed window.

Steps

1. Super Admin: Unpublish / Return to Draft the case.
2. Read the impact shown; confirm; check the learner side.
3. Republish afterwards.

Expected

• The action shows the exact affected windows; they end as platform-caused with allowances restored and acknowledged code preserved; if protection cannot be established it does not pretend to complete safely.
• Earned fixes, rewards, drafts and retained solutions remain; republish needs the ordinary checks and renews no first-fix rewards; archived is not restored by this.

Preconditions

Super Admin A tagged live case to retire.

Steps

1. Archive it (or Delete a safe one).
2. Check learner records that referenced it.

Expected

• The same active-window protection applies; new starts stop; earned records stay readable.
• No invented in-app notification — the persistent affected-window message explains what happened; a deletion that cannot protect history refuses and offers Archive.

Preconditions

Both roles available. 🖥🖥 helps.

Steps

1. As Admin: open /admin/debug-detective-bug-types — read the list, look for an add/correct control.
2. As Super Admin: add a bug type "QA-VK-test"; correct its label. Look for a delete.

Expected

• Every staff member reads the list; adding an entry or correcting a label is a Super Admin's, behind the main-site check.
• Entries are never deleted — no delete control exists; a relabelled type keeps its meaning and its history on cases.

Preconditions

Signed in as staff; published cases have learner activity.

Steps

1. Open /admin/debug-detective-review.
2. Read the columns; export the CSV if offered.

Expected

• Every case ever published, lowest Fix rate first: learners, fixes, validations, failures, hint use, median time to fix — timed figures in their own columns, never averaged with practice.
• Staff practice is left out; small samples read "Not enough data".
• The export states what it covers and says when older cases were left out.

Preconditions

Signed in as staff; showcase written subjects exist.

Steps

1. Open /admin/courses and /admin/video-courses.
2. Use search, views (All, the format's, Waiting for approval, Archived) and orders; press New on each.

Expected

• Each list counts and shows only its own format; search, view and order live in the address.
• Each card has Edit; New asks only for a title and makes a course of that list's format.
• The builder's back link leads to the course's own list.

Preconditions

Signed in as staff; a showcase subject ("Python Fundamentals") to read.

Steps

1. Open /admin/courses/:content for a subject.
2. Open a chapter, then a lesson, from the outline.
3. Check the older addresses resolve: /settings, /order-preview, /publish, /retirement, /review.

Expected

• The outline — chapters and their lessons, each with where it stands — sits beside whatever is open: the course's details, a chapter, or a lesson, each with its own checklist and side panels.
• Every earlier address is a view of this one page: details, settings (How it runs), chapter, lesson, revisions, learner order, the one Publish, retirement, How it's going.
• Chapters and lessons are added in the outline; no chapter inside a chapter, no lesson outside one.

Preconditions

A tagged never-published course; a showcase live course.

Steps

1. On the never-published course, move a lesson by dragging, by its menu, and with Alt+↑/↓.
2. On the live course, move two lessons; read what the outline says before applying.

Expected

• A course never published saves each move at once.
• A live one holds its moves under "Order changed" until "Apply for learners" — several moves make one change record and one notice; a stale outline is never applied over someone else's moves (held moves are let go and the author told when the order moves on beneath them).

Preconditions

A live course with held order moves; test both: Super Admin, and Admin with the switch OFF.

Steps

1. As Admin (switch OFF): open the live course and try to apply.
2. As Super Admin: Apply for learners; then check the learner-facing order and the change record.

Expected

• An Admin while the switch is off is told to ask a Super Admin — applying a new order, renaming a chapter and toggling required/optional each need a fresh main-site check and the right to publish.
• Applied, the order lands for learners as one recorded change; a video lesson made required must have its captions and transcript first.

Preconditions

A tagged draft course; create lessons.

Steps

1. Create a reading lesson: add headings, text, a callout, a display-only code block, an image block and a runnable example.
2. Create a quiz lesson and an assigned-project lesson; note the integration reference kind.

Expected

• Reading, assigned project and integration reference lessons use the block editor: headings, formatted text, note/tip/warning callouts, display code, images, executable examples.
• A runnable example offers only the runtimes it can run in (plus HTML/CSS/browser-JavaScript where supported); a program may take input; a CSS/browser-JS example may take the page it is shown inside.
• An assigned-project lesson selects an available workspace template and required/optional — no invented grader or completion override.

Preconditions

A draft lesson with content; another empty draft lesson.

Steps

1. Change the written lesson's kind; read the warning.
2. Change the empty one's kind.

Expected

• The change names the source and destination kinds and exactly what would be discarded; with nothing to lose it says nothing.
• Existing learner completions are untouched either way — a kind change is never a hidden progress reset; a kind is fixed once the lesson is live.

Preconditions

A draft reading lesson.

Steps

1. Paste a formatted-text section over 50,000 characters; a code block over 64 KiB; an outcome over 240 characters.
2. Try a picture over its limit.

Expected

• Each exceeded limit is rejected clearly at its field — subject outcomes 1–8, published lesson outcomes 1–5 (each ≤240 chars), heading/callout titles 120, formatted text 50,000 chars, code sections 64 KiB.
• A picture over the limit is refused before it is read; a larger one is said to be too large rather than unreadable.

Preconditions

A draft quiz lesson.

Steps

1. Add questions of each type; set whole marks, an optional numerical tolerance, a timer, shuffle and a pass threshold.
2. Add review-lesson links; remove a question's options and a prerequisite with Undo.

Expected

• The four question types work with answer keys and whole marks; multi-select is all-or-nothing (never Assessment partial marking).
• Removed items undo cleanly; review links to lessons inside the same course resolve; a link to a lesson outside it is cleared on import.

Preconditions

A video-subject draft; a video upload to stage (or an existing Processing/Failed one).

Steps

1. Watch the upload's state; try to publish the lesson while the video is Processing/Failed or while a required video lacks captions/transcript.

Expected

• Staff read Processing, Ready or Failed honestly — a long preparation stays Processing (the operator is told after 30 minutes), never labelled successful.
• Publish refuses an unready video or a required video without captions/transcript; a failed upload can be replaced.
• Captions added to a video a live lesson already plays reach learners at once — and ask what a publication asks: fresh check + publish right.

Preconditions

A tagged draft course missing pieces (e.g. a chapter holding lessons none of which is going live).

Steps

1. Open the one Publish (/publish).
2. Read the blockers; fix them; publish.

Expected

• What stands in the way is listed with a way to each item — blockers only, apart from what is ready: a chapter holding no published lesson is the classic blocker on first publication; a chapter with no lessons at all never holds a course back.
• Everything chosen goes live in one request or nothing does, naming each item that would not; a live subject gains a lesson the moment that lesson goes live, without the subject being republished.
• Also checked: usable unique addresses, outcomes valid, required lessons reachable, parents available before children, no prerequisite circle (names the course that closes it), image sections holding a kept picture.

Preconditions

A live course; edit two lessons and the details; leave a third untouched.

Steps

1. Open Publish.
2. Read what it offers; untick one and publish; then reopen.

Expected

• The dialog offers the course details when changed and every lesson with something new — each ticked; what still has something to fix is listed apart with a way to it.
• With nothing chosen its button reads Publish (or Submit for approval), never "Publish 0 lessons"; a draft saved back to the live version reads Live, not "changes not live", and is not offered.
• First publication or update asks for a reason in the author's words on update — kept for staff, never shown to learners.

Preconditions

A draft lesson open; dev tools for going offline.

Steps

1. Go offline; edit the lesson; wait for the autosave.
2. Leave and reopen the item at the same version.

Expected

• The failed save keeps what it held in this browser and the bar says Saved locally — never implied to be a platform save.
• Reopened at the same version it offers "Put back what you typed"; a copy taken from an older version is let go.
• Only Saved, Not saved and Saved locally are announced — never each pause in typing.

Preconditions

A lesson with several saved edits.

Steps

1. Open the lesson's /revisions.
2. Read an entry's name; Put this back on one.

Expected

• The newest ten of the last ninety days are offered — a save keeps what the lesson said before it, one author's saves within ten minutes keeping one; the version learners see, a put-back and a kind change are always kept.
• Each is named by the save that replaced it: "Before the save of 10 Nov 2026, 01:58 IST by Asha".
• Put this back fills the draft and never touches what learners see — it must then pass the current checks to go live; after someone else's newer save it is refused as a save is.

Preconditions

A course with required/optional lessons and sequential navigation.

Steps

1. Open the lesson preview and the learner order (/order-preview).
2. Check for created progress.

Expected

• Preview uses the learner presentation and course order — required/optional work and the sequential frontier visible — and creates no enrollment, progress, reward or certificate; executable content does not run.
• A failed preview is explained and does not by itself block saving or an otherwise valid publish.

Preconditions

A draft lesson; a second signed-in account for the recipient view. 🖥🖥

Steps

1. From the lesson editor, make the read-only preview link; open it as the other person (/course-previews/:previewId).
2. Revoke it; open the link again.

Expected

• The link lets any signed-in person read that draft for 24 hours — no editing, no running an example (examples say as much where Run would be), no quiz, no enrolment, no completion.
• A withdrawn or expired link says it is no longer active — it never falls through to the live content; a lesson holds at most ten live draft links.

Preconditions

A tagged video course and a written one.

Steps

1. Open /settings: set navigation, prerequisites, classification and tags.
2. On the video subject find the certificate switch; on the written one confirm its absence.

Expected

• Video subjects offer open/sequential navigation and required/optional lessons — chapter progress derives from required lessons only; written subjects keep their own completion rules.
• Prerequisites list each required completion explicitly — never inferred from XP, scores or levels; a configuration that dead-ends a required journey cannot publish.
• The certificate switch is on for a new video subject, read at first completion; turning it on later does not back-issue, and off does not remove issued ones; written subjects never award a certificate.
• Tags: up to ten of forty letters each — the catalogue filters by them.

Preconditions

Super Admin A showcase (or tagged) published subject with enrolled learners; a tagged never-published subject.

Steps

1. Open /retirement on each and read the consequence preview.
2. Archive the published one; delete the never-published one (typed title).

Expected

• The dialog explains what each action affects before confirmation — affected chapters/lessons, live references, learner-facing consequences.
• Archive removes new discovery and new starts; existing learners keep readable access and their Course Workspaces; it never resets progress or revokes certificates — and an unfinished required assignment without a workspace is called out.
• Delete is offered only for a subject never published — title typed to confirm; a published subject is archived, never deleted, by either role.

Preconditions

Signed in as staff; a subject to export; a deliberately broken file to import.

Steps

1. Export a subject from its page.
2. Import it back at /admin/courses/transfer; then import a corrupted/edited file and an oversized one (>10 MiB or >500 lessons).

Expected

• The export file carries the subject, chapters and every lesson's content — no learner progress, no video (it stays with its service), no completions.
• Import reads and describes the file before writing, naming problems by place ("chapter 3, lesson 2"); one fault refuses the whole file — nothing is written; a file with many problems names its first twenty and how many more.
• What arrives is a draft under the file's own name ("(copy)" on a name clash), with its own addresses — importing never publishes; a foreign file reads "not a course file this platform wrote".

Preconditions

A showcase subject with learner activity.

Steps

1. Open /admin/courses/:content/review.
2. Read the per-lesson figures.

Expected

• It says how many learners started and completed the subject and finished each published lesson — with the moment the figures were worked out.
• Staff are not counted and nobody is named; figures that cannot be worked out say so rather than reading as zero.
• A change learners were told about (the change record) is readable on the subject — Added/Updated/Moved/Removed, when, by whom, and the author's reason.

Preconditions

Signed in as staff; showcase texts exist.

Steps

1. Open /admin/typing-quest.
2. Filter by kind (English, Code, Template, Lesson), then level, language and state.

Expected

• Filters work together; with none chosen they read Any level, Any language and Any state.
• A text opens in its editor as a state of the same page (?text=<id>) — the domain keeps its one staff route.
• Each text's figures (rounds, average speed and accuracy) are visible — the signals for spotting too-hard texts.

Preconditions

A new text draft open.

Steps

1. Paste a body with a curly quote (é, —), a tab, a trailing space and an unbalanced bracket in a code text.
2. Read the check list; fix them; watch the list clear.

Expected

• The checks are listed under the body as it is typed; they refuse: any character but the 95 a US keyboard types (naming each once, in order: "These characters are not on a US keyboard: é, —."), a space at a line's end, a blank start or end, and an unbalanced bracket in code.
• Length bounds per kind: common words 20–1,000 words ≤24 letters; simple 100–1,500 chars; complex 150–2,500; level check 600–6,000 chars with its 1–5 minutes; code 40–3,000 chars ≤100 lines ≤100 chars; title ≤120; source note ≤300.
• A text with any problem cannot be published or submitted.

Preconditions

A draft text.

Steps

1. Set it to English — read the level field; to code — the language; to template — language + target time; to lesson — order + steps.
2. Convert a filled English draft to code and back.

Expected

• English asks its level, code its language, a template its language and target time, a lesson its place and steps; choosing code clears the level and time, choosing English clears the language.
• Conversion keeps only what the new kind needs — nothing stale lingers invisibly in the draft.

Preconditions

A valid tagged text; try under the current switch state and note which path ran.

Steps

1. Type a last change; without waiting, press Publish (or Submit for approval with the switch OFF).
2. Complete the main-site check.

Expected

• One press saves what is unsaved first, then publishes or submits the saved revision — through the content engine, obeying Allow Admins to publish.
• With the switch OFF, Submit offers an optional reviewer note up to 500 characters that the Super Admin reads in Submissions.
• Return to Draft and Archive are a Super Admin's; there is no Delete for a text.

Preconditions

A draft template.

Steps

1. Write a template outside 80–2,000 characters or over 60 lines/100-per-line; leave the target time empty; try to publish.
2. Fix and publish.

Expected

• Code's checks plus its own: indentation by spaces, none at a line's end, balanced brackets, 80–2,000 characters, up to 60 lines of up to 100.
• A template without its target time cannot be published — the blocker is named.

Preconditions

A draft lesson; a published lesson already holding order place 1.

Steps

1. Give the draft the same place; run the check.
2. Break a step's bounds (<10 or >400 chars, >8 lines, tabs, new keys with spaces).

Expected

• A place already held is refused at the check, naming the lesson holding it — publishing waits until another is chosen; the editor knows the places other published lessons hold as the place is typed.
• Step bounds named per step: 10–400 characters, up to 8 lines of up to 100, US-keyboard characters, no tab, no line-end space, no blank start/end; new keys without spaces.

Preconditions

A published simple/complex English passage or code snippet; a common-words list and a level-check passage.

Steps

1. Toggle "In the Typing Daily pool" on the poolable text.
2. Look for the switch on the other two kinds.

Expected

• The switch sits under "On the way to learners" for a simple/complex English passage or a code snippet — any staff member's, applying at once with no approval (the text itself was already published through approval).
• A common-words list or a level-check passage is refused — not poolable; archived or returned-to-draft texts leave the pool.

Preconditions

Signed in as staff; texts in the pool.

Steps

1. Open the studio's Typing Daily (?daily).
2. Replace a future date's English slot; confirm; try a begun date.

Expected

• It lists the next 14 dates, today first, each with its text in English and in each code language — or "Nothing in the pool" for an empty slot.
• Replace asks once, naming the slot and its date, the text offered now and the one it would offer instead (titles cut to 40 chars); a toast names the date, text and slot; a choice whose text left the pool gives way to the draw.
• A begun date reads Begun — its texts are locked and replacement is refused.

Preconditions

Published showcase content: a reading lesson with a code example, a challenge with a hand-written starter.

Steps

1. Press "Add from our content" beside New text.
2. Pick a language; search; inspect what is offered; copy one into a new draft.

Expected

• The dialog offers lesson code examples and runnable blocks from published subjects, then challenge starters — up to 25 of each — each with title, file and first four lines.
• Never offered: a reference solution, an editorial, a hidden test case, or any other part; code that is empty or too long is not offered; no match says so with Clear filters; a failed read says so with Try again.
• The copy lands as an independent draft titled "lesson or challenge: file" with its source note under Copied from — the source changing later never changes it.

Preconditions

Signed in as staff; showcase papers exist.

Steps

1. Open /admin/mock-tests and /admin/company-tests.
2. Open /admin/papers; use the status views, search and orders.

Expected

• Cards with status views and counts: drafts, waiting for approval, published, changes not live, archived — with a title search, two orders, and "Live tests at once" at the foot.
• /admin/papers opens Mock Tests, or Company Tests for company papers (?type=company opens the company cards).
• Company Tests shows companies as cards: their roles, papers by state (archived left out; a live paper with a waiting change counts as published and waiting) and the learners who started one of its tests this calendar month — staff left out.

Preconditions

Signed in as staff.

Steps

1. Create a Mock paper "QA-VK 15 Nov — paper".
2. Read its defaults: strictness, review settings, duration, passing percentage, grace.
3. Try to publish without category/difficulty.

Expected

• Defaults: strictness Standard with every review setting on; duration 60 (5–240); submission grace 60 s (0–300); passing 50% (1–100%); Strict event ceiling 3 (1–10); fullscreen/observation categories optional.
• A Mock paper needs a category (free text; the field suggests categories already in use, one per spelling whatever its capitals) and a difficulty — publish blocks without them.
• A category typed in other capitals than a published paper's saves in that paper's spelling, shown back as soon as the save answers.

Preconditions

Both roles. 🖥🖥 helps.

Steps

1. As Admin, open /admin/company-tests/:company (e.g. Northvale Systems) — read details, roles, papers.
2. As Super Admin, change a company detail or role (main-site check), then look for Delete/Deactivate.
3. Try a javascript: address as the company's website.

Expected

• Staff read the company's details, roles and its papers by role and state; every change is a Super Admin's through the main-site check, recorded in audit old and new.
• A role name must be unique within the company; "New test" makes a draft already in that company with its role chosen from the company's roles.
• A company with papers cannot be deleted — it is deactivated instead (removed from browsing, records kept); Delete is for a company without papers, naming what goes.
• The website accepts empty or https:///http:// only — anything else is said under the field as typed, holds Save back, and the server refuses it.

Preconditions

A tagged draft paper.

Steps

1. Add, name, order and remove sections; give one a suggested duration and a visible-case run allowance; exclude one from the paper.

Expected

• Each section carries its subject and an introductory briefing, an optional suggested duration (pacing help — never an enforced sectional limit) and an optional visible-case run allowance (none = unlimited; a configured one is shown to learners).
• Included/excluded sections are explicit; changes to a published paper apply only to future starts.

Preconditions

A tagged draft paper with a section.

Steps

1. Add a question of each kind: single-choice, multiple-choice, numerical, true/false, coding.
2. Give one a penalty above its marks; try to change a written question's kind.

Expected

• Each kind asks its own fields: options + one right answer / the right set / the number + tolerance / the boolean / prompt + languages + starter/reference/cases + limits; every question also has marks, optional fixed penalty, difficulty and skill/topic classification; explanation and target time optional.
• A wrong answer loses at most the question's own marks — "At most its marks, 2, so it is not saved." under the field, and the api refuses it naming the question.
• A question's kind is fixed once written — changing it goes through add/remove, not a kind switch.

Preconditions

A draft paper; a coding question part-written (reference missing or failing).

Steps

1. Finish the coding question: languages, starter, reference, visible + hidden cases, limits.
2. Run the checklist.

Expected

• The question is open in every graded language like a challenge; each written reference must pass every test case and no starter may already pass them all.
• References are checked on the grading service before the paper can go live; a check that could not run reads Not yet verifiable — and one the full service turns away waits for it (the paper reads as being checked), reading Not yet verifiable only if still turned away a day on.
• A change to any coding question — or to which are included — needs the check again; an untouched-questions save (details, other questions) leaves a passed check standing.

Preconditions

🖥🖥 The same paper open by two staff members.

Steps

1. A edits details and lets the part save.
2. B, on the older revision, edits questions and waits for its save.

Expected

• Each part saves itself two seconds after typing stops; what is waiting is saved before another part opens.
• A save against a stale revision is refused — B keeps theirs (saved over the newer version) or loads the other; never a silent merge; typed input is preserved either way.

Preconditions

A draft paper; the CSV template downloaded; a batch with deliberate bad rows.

Steps

1. Open /admin/papers/:paper/import; get the template.
2. Paste rows: one with a bad kind, one a coding row, one naming a new section, one valid; Check.
3. Fix and import; then try a batch over 200 questions.

Expected

• Check reads every row and names each problem by row and column; nothing is added until every row passes — then it says how many questions go into which section, new ones marked.
• A coding row is refused with a pointer to the studio (its cases/references are checked there); a section title not in the paper makes a new section at the end, within limits; blank marks/penalty take the company's then the platform's defaults.
• An over-limit batch (>200 questions, or one taking the paper past its 4 MB cap) is refused whole with the bound named — never only the rows that fit.
• Imported questions land in the draft even of a live paper; learners see them at next publish.

Preconditions

Signed in as staff.

Steps

1. From the paper studio, follow "Import questions".
2. Open /admin/import/assessment-paper/:paper directly; then /admin/import/<some-other-kind>/:id.

Expected

• The studio's import goes through /admin/import/:kind/:id to the owning area's importer — a Mock or Company paper is the one kind with an importer today.
• Any other kind is told there is nothing to import into there — no generic importer, no central bank.

Preconditions

A draft paper with several problems (no included section, no questions, missing key).

Steps

1. Open /checklist.
2. Fix the named failures; re-check.

Expected

• Every failure is listed together — never stopping at the first — each pointing at the view that fixes it.
• Checked: usable title, positive duration, an availability window that opens before it closes, ≥1 included section and question, positive total marks, valid classifications, well-formed keys, Mock's passing percentage, Company's owning company + matching role, coding references validated.
• An Actual paper needs a dated source and documented permission to reproduce; a Pattern paper must not claim to be an employer's actual released paper.

Preconditions

🖥🖥 helps. A published paper with a test in progress or completed; edits staged.

Steps

1. Edit a question and a setting; publish through the main-site check.
2. Compare a test taken before with a new one started after.

Expected

• Publishing keeps a frozen copy of exactly that revision — a test already running or finished keeps the questions, keys, marks, section order, strictness and timing it started with; its result and review never substitute the new content.
• The update reaches only tests started after; the same checks apply to updates as to first publish.
• "Why, for the record" is not asked at publish (it was never kept); Archive/Delete/Publish/Update confirm through the main-site check.

Preconditions

A published paper.

Steps

1. Open /admin/papers/:paper/published.
2. Read its questions, options and keys.

Expected

• Each question and option is drawn as learners read them — Markdown drawn, code as code, never its backticks; the right option is marked Right.
• It is the frozen live copy with its keys — read-only here, the staff view of exactly what tests begin on.

Preconditions

Super Admin A published paper whose settings are changed.

Steps

1. As Admin, change a live paper's setting and submit (switch OFF) — or try to publish it (switch ON means direct publish is for content; live timing/scoring settings stay SA's — note which).
2. As Super Admin, publish the settings change: read each old → new value, the optional notice and its recipient count; confirm.

Expected

• A change to a live paper's settings is published by a Super Admin; an Admin's is submitted for approval — and a submission approved later tells nobody.
• The confirmation lists each old and new setting, the eligible recipient count, and that a sent notice cannot be recalled; if the count cannot be calculated there is no confirmation against an invented audience.
• "After a test" says a result keeps the settings its test began with — the change reaches only tests started after it and open practice as it now stands.

Preconditions

Super Admin A live paper with finalized learner results; a settings change ready to publish.

Steps

1. Publish with the notice on and the relief grant chosen.
2. Check who was told and who got the grant; try to grant without the notice.

Expected

• The grant is offered only with the notice: learners who had finalized on that paper get one more recorded test; learners not yet tested or still in progress get none; grants do not stack — a holder of an unused grant keeps just that one.
• The learner's notice says what changes after their next test in a sentence; a grant's notice survives the learner's Delete/Clear.
• The change and grants are kept on the publication's transaction; notices go out afterwards a page at a time, retried until raised, never undoing the change; learners being erased are skipped as each page is told.
• Audit keeps the settings as from → to and "Gave relief grants" with how many.

Preconditions

Super Admin A Company paper whose live copy is Actual (or stage one).

Steps

1. Super Admin: More → Downgrade to Pattern, give a reason, main-site check.
2. Read the draft, the live copy, a frozen copy's result and the audit trail.
3. Look for a way to make a Pattern paper Actual.

Expected

• The label becomes Pattern on its draft, its live copy and every frozen copy — results already taken read Pattern; nothing else changes; it is audited with the reason.
• A later Actual is only ever a new publication: results keep the label of the copy they began on; a finished Pattern test is never relabelled Actual.

Preconditions

Both roles; a learner who has signed in (tester-learner-1); a published paper.

Steps

1. As Admin, open /admin/papers/:paper/accommodations.
2. As Super Admin, find the learner by name and give 1.5×; then remove it.

Expected

• Both staff roles read who has extra time; the page tells an Admin giving/removing is a Super Admin's and offers them neither.
• Learners are found by name from two letters, twenty at a time; multipliers 1.25, 1.5 or 2.0 — or the usual time set on purpose (1.0 is never silently reported as an accommodation).
• It cannot be given or removed while that learner's test on the paper is in progress or while their account is being erased; it applies to the next Start — the learner's paper page and clock show the lengthened time and that it includes agreed extra time.
• Each change is audited with its old and new value.

Preconditions

Super Admin A paper with learner tests (showcase papers have some).

Steps

1. Open /admin/papers/:paper/tests.
2. As Super Admin, choose two ended tests and invalidate together — one reason, one note, one main-site check.
3. As Admin, read the same list.

Expected

• Newest first: the learner's name, when it started, where it stands, how it ended and its counted events — never a score or an answer; a test still grading an hour on is marked and reads that it keeps trying, not a technical reason.
• Bulk invalidation gives each test's outcome — invalidated, already invalidated, or refused with why — each under the single test's rules; only an ended test (being graded or final) can be invalidated; none of someone being erased.
• The note is a Super Admin's to read — an Admin never sees it; the learner reads only the reason's sentence.

Preconditions

A paper with tests at different strictness levels (Off included if possible).

Steps

1. Open /admin/tests/:test/recorded-events for a Standard/Strict test, then an Off one.

Expected

• The facts of the test and its events oldest first, each marked counted or not — read-only; no screen/audio/video capture, clipboard contents or inferred misconduct.
• Under Off it says nothing was recorded because of the setting — a recorded Off is never presented as missing monitoring data.

Preconditions

Super Admin An ended learner test (ideally a relief-grant test and a replaced result somewhere to observe consequences).

Steps

1. Open /admin/tests/:test/invalidate; choose a reason, write a note, confirm through the main-site check.
2. Check the learner's history, XP and Skills; try invalidating again.

Expected

• The flow is reason → note → confirm → done, offered only once the test has ended; the reasons are a fault on our side, faulty content, account security and a staff decision.
• The test keeps its place in the learner's history as Invalidated with the reason's sentence — the private staff note never reaches the learner; the paper can be taken again; Mock XP is reversed through Economy (paid instead to another valid Mock test of theirs where there is one, and the confirm says so); skill evidence is set aside; achievements stay earned.
• Invalidating a relief-grant test gives the grant back and the replaced result stands again; invalidating an already-replaced result leaves the newer one and gives no new test; repeating invalidation has no duplicate effect.

Preconditions

Super Admin A tagged live paper — ideally one holding unused relief grants.

Steps

1. Archive the paper; read the confirmation first.
2. Check the catalogue, a running test, and a grant holder's paper page.

Expected

• Archive retires the paper from catalogues and stops new starts — final, never a republish loop; existing tests finish under their original rules and history stays readable.
• Its confirm says how many unused relief grants it ends before it is pressed; a grant holder's paper page tells them it can no longer be used; no notice is sent.
• No score is invalidated and no earned history removed by archiving.

Preconditions

Super Admin A tagged paper with tests taken; a Company paper.

Steps

1. Delete the paper — read what the confirm says.
2. On a Company paper, More → Duplicate to… another active company; try it on a Mock paper.

Expected

• Delete says how many tests were taken on it and how many are still running; the frozen copies keep those tests gradeable and reviewable — the staff list of a deleted paper's tests still answers; deleting never cascades into learner results.
• Duplicate to… puts an independent draft in another active company — no role chosen yet, no Actual label and no source (the copy re-declares Actual/Pattern with its own permission); the server refuses an inactive company and refuses Duplicate-to for a Mock paper.
• Results from the two papers are never merged.

Preconditions

Papers and a company with learner tests.

Steps

1. Open /admin/papers/:paper/analytics on a Mock and a Company paper.
2. Open /admin/companies/:company/analytics; read the question review prompts.

Expected

• Each reads learners' recorded tests only — says so and when it was worked out: learners, tests started, share of ended tests submitted, average score (a tenth, rounded down), accuracy, middle result's time, results by score, section averages, tests per day for thirty days, and per-question results/accuracy/skips/partly-right with its prompts.
• Pass rate appears for Mock only — Company figures have no pass/fail measure; a company's figures list its papers lowest completion first.
• The six neutral prompts (accuracy <25% or >95%, skipping >35%, slow answering, partial credit ≥40%, grading failures) are advisory — never a verdict on a question or a learner; staff tests are left out; the questions export is CSV.

Preconditions

Signed in as staff; the showcase template set exists.

Steps

1. Open /admin/workspace/templates.
2. Use the status views, search and orders; load more.

Expected

• Status views with counts for the search as typed: All, Draft, Submitted, Published, Archived; orders Recently saved / Name — all in the address; 25 more per load.
• Each card names the language by its runtime-registry name ("Python 3.14", "React", "SQL in the browser"), its status and whether changes are live, when and by whom saved, its files, its tasks, and how many projects were made from it — a count, never who; the one action is Edit.

Preconditions

Signed in as staff.

Steps

1. Create "QA-VK 15 Nov — template": name, description, technology, topic, language, two files, a start file, three checklist tasks.
2. Paste over-limit text into a bounded field and try to save.

Expected

• Details, Files and Checklist sit beside their index with the checks beside them; a template is classified by one topic whose skill becomes its primary skill.
• Text past a field's limit stays in the field and is not saved — the bar keeps "Unsaved changes" while it is there; a server refusal names the part and its limit in the studio's words ("A task (number 3) is over the most it can hold, 120 characters.").
• Removing a file or task acts at once with an Undo toast — Undo puts a file back with its start file and the tasks about it.

Preconditions

Drafts of a terminal starter (e.g. Python) and a web starter; a deliberately broken one.

Steps

1. Run the check on the good starter and on the broken one.
2. Read the failure output.

Expected

• A name, a description, a topic, a language and at least one file are needed before a check; technology and checklist optional.
• A terminal starter passes on exit code 0 or still running after its watch (waiting for input counts); otherwise it fails showing the first 2,000 characters it printed; compiled languages are watched for their build time too.
• A web starter passes when its start page and every file it names are present; a SQL starter's statements run on a fresh database; a Flask app's checks prove files and compilation — and say they do not prove the app runs.
• The result belongs to the revision checked — a later save needs a new check before publish.

Preconditions

A checked tagged template; try under the current switch state.

Steps

1. Publish as the role you're on; where the switch is OFF and you are Admin, submit instead.
2. Check the learner's New project picker.

Expected

• Only a revision that passed its check goes live — directly for a Super Admin or an Admin while the switch is on, through the approval queue otherwise.
• The published template is what learners create independent projects from — the studio's web preview matches the learner's preview.

Preconditions

Super Admin A published template learners have created projects from (a showcase one); a never-published tagged draft.

Steps

1. Read the projects-made count on the published one, then Return to Draft it — or Archive it.
2. Delete the never-published draft; try Delete on a published template as Admin.
3. Check a project made earlier still opens.

Expected

• Return to Draft and Archive are a Super Admin's; each says how many projects were made from the template — and none is touched: existing learner projects and course-assignment starters stay independent.
• Delete is any staff member's for a template never published, a Super Admin's for any — projects made from it are copies, so no learner's work goes with it; the confirm explains the effect without ever exposing learner project names or files.
• An archived template leaves the picker and new selection; a course assignment keeps the starter it captured.

Preconditions

A template — published or draft.

Steps

1. Duplicate it from the More menu; open the copy.

Expected

• A new draft named "Copy of" the original, with its draft files and checklist and nothing else — no learner projects, completions, rewards or activity.

Preconditions

A learner project exists (a tagged template instantiated by tester-learner-1).

Steps

1. As either staff role, hunt for any way to open that project's files — the template's page, the learner's support view, any link.

Expected

• None exists: no open-as-learner, file-inspection, grade-project, completion-override or promote-learner-project-to-template action — staff manage templates, not learners' project content; project limits are not adjustable from this studio.

Preconditions

Super Admin Signed in.

Steps

1. Open /admin/vocabulary; choose a skill (?skill=).
2. Read the allowance meter.

Expected

• Skills beside the chosen one's topics; the lifetime allowance reads as a meter — the ceiling is 2,000 entries counting active, archived and merged-source alike; it warns above 1,800.
• The difficulty scale and language catalogue are read-only here.

Preconditions

Signed in as Admin.

Steps

1. Open /admin/vocabulary directly.
2. Look for the destination in the Content space.

Expected

• "Only a Super Admin can open this page." — the page is a Super Admin's to open as well as to use.
• The destination does not appear in an Admin's navigation.

Preconditions

Super Admin

Steps

1. Add a skill "QA-VK Skill" and a topic "QA-VK Topic" under it.
2. Try a 1-character and a 61-character label; try "qa-vk skill" again; go stale on the check once.

Expected

• A label is 2–60 characters, compared ignoring case and extra spaces — the duplicate is refused.
• Each add goes through the main-site check at confirm; a stale check sends you to the main site and back with what was typed held.
• New entries are offered in the studios' pickers at once.

Preconditions

Super Admin The "QA-VK Topic" from the previous case, attached to a tagged item if possible.

Steps

1. Correct the label to "QA-VK Topic renamed" with a reason (3–300 characters).
2. Check the item still carries it, the audit entry, and a historical record that showed the old label.

Expected

• The rename preserves the classification's identity, links and historical evidence — it is not a new skill; the item's tag follows at once.
• The reason is required (3–300) and kept with old/new labels in the audit history; a mistyped or absent reason performs nothing.
• Historical records keep their original label where they preserve one — the wording change is never presented as a new outcome.

Preconditions

Super Admin A topic attached to tagged items across a couple of areas (tag a challenge and a course first).

Steps

1. Archive the topic from its row.
2. Read the affected-content dialog; confirm with a reason through the main-site check.

Expected

• First the dialog reads what carries the topic: every authored item tagged with it, whatever its state, counted by area (challenges, track challenges, Debug cases, Dailies, courses, Workspace templates, papers) — each area opening to its items by title, linked to its editor.
• While that cannot be read, Archive waits — never confirmed against a guess; the reason (3–300) is kept in audit; however often asked, it happens and is recorded once, and is never undone.
• Afterwards: the pickers omit it for new choices; items already carrying it show "(archived)" and can take it off; learner topic filters omit it; a paper's question import refuses it; what carries it keeps it readable, checks still accept it, it still counts against the lifetime ceiling and its label stays taken.

Preconditions

Super Admin Just added/renamed a topic.

Steps

1. Open a challenge studio's topic picker and a course's classification.
2. Confirm the new label reads the same in both at once.

Expected

• One shared skill-to-topic picker serves every area — a change is readable in all of them at once through the published cache.
• A failed vocabulary read offers no invented free-text fallback and cannot pass publication checks.

Preconditions

Signed in as staff.

Steps

1. Open /admin/provenance.
2. Open an item; unfold an area's defaults.

Expected

• Items whose own values differ from their area's defaults list first, newest change first, twenty a page — each opening its source record; an item differs too where the area sets no default and the item sets one.
• Each area's defaults fold behind its name.

Preconditions

Super Admin

Steps

1. Unfold an area's defaults; change one in place (main-site check).
2. As Admin, confirm the same change is not offered.
3. Check the audit entry.

Expected

• A Super Admin changes an area's defaults in place, recently checked with the main site and recorded in the audit history — a provenance-downgrading change is audited.
• Either staff role prepares an item's own values; only the Super Admin changes defaults.

Preconditions

An item with its own values (or a submission review linking to one).

Steps

1. Open /admin/provenance/:kind/:id.
2. Edit one own value from the bar at the foot; read the history.

Expected

• Each field shows the record in force — marked when it is the area's default or differs from it — the item's own values, the record kept with its latest publication, and every change.
• Each publication in the history names the staff member who made it go live (directly or by approving); the cited-as-of date reads as a day ("27 Oct 2026").

Preconditions

Super Admin An item published under today's defaults.

Steps

1. Publish the item; change its area's defaults.
2. Re-open its source record's history.

Expected

• The record kept with the publication still shows what it stood on — the changed default does not reach back; a submission's review shows the record in force and where it differs before approval.

Preconditions

A Company paper draft labelled Actual without source/permission.

Steps

1. Try to publish it as Actual.
2. Change to Pattern and publish.

Expected

• Actual refuses with precisely what is missing: the dated source, the documented reproduction permission, or both.
• Pattern publishes without them but must not imply employer endorsement or possession of the original.

Preconditions

Signed in as staff.

Steps

1. Open /admin/import/assessment-paper/<a paper id>.
2. Open /admin/import/<any other kind>/<id>.

Expected

• The paper's own importer opens (same screen as §9.2).
• Other kinds are told there is nothing to import into there — the page stays inside the console, honest, not an error.

Preconditions

Reports exist on a few items (file some as learners first if the queue is empty).

Steps

1. Open /admin/reports.
2. Filter by area and by state; compare counts to rows; page through.

Expected

• One row per reported item — its reasons and how many of each, how many reports, the oldest and its most pressing state; open items first, longest waiting first; 20 to a page.
• An area filter narrows rows and the status counts; a status filter narrows rows, not the cross-status breakdown — every state and area says how many reports it holds, and zero counts are real.

Preconditions

An item with several reports (one with a renamed title if possible).

Steps

1. Open the item beside the queue at its own address.
2. Read each report's note, state and moves.

Expected

• Each report shows the item as learners open it now, with "Reported as …" when its title changed since; the reason and note, its outcome or dismissal, every move with who made it and when — fifty reports at a time.
• The way to the item's editor is offered only while learners can open it — it does not pretend the editor shows the historical screen.
• Staff never see who sent a report; the note stays staff-readable.

Preconditions

An open report.

Steps

1. Mark it Investigating, then back to Open.
2. Resolve it — try each outcome (Corrected / No action / Escalated / Duplicate) with and without the optional note.
3. Dismiss another without a reason, then with one.

Expected

• Open and Investigating move between each other or to closed; moving a report to where it already is changes nothing; repeated moves create no duplicate actions.
• Resolve records the outcome with an optional note named by it — the correcting change, why nothing needs changing, where it went and why, or which report it repeats; a note past 200 characters is kept whole and said to be too long while Resolve waits.
• Dismiss requires a reason; the history reads Back to open, Reopened, Resolved with its outcome.

Preconditions

A resolved and a dismissed report.

Steps

1. Try to resolve a resolved report again — then reopen it without a reason, then with one.
2. Give it a different outcome.

Expected

• A closed report must be reopened with a reason before another outcome — reopen clears the former closure marker without losing history.
• Reopen is refused only while the reporter has a newer still-open report of the same item.

Preconditions

Several items selected.

Steps

1. Choose several items; mark investigating / resolve / dismiss together.
2. Read the result message.

Expected

• One request moves each item's reports the move may take — at most the 500 oldest — each still on its own: one refusal undoes nothing, and the page says how many moved and why any did not, saying when more are left for the same move again.

Preconditions

A report exists on a tagged item; then archive/delete that item (or use one learners can no longer open).

Steps

1. Remove the content learners-side.
2. Re-open the report row.

Expected

• Removed content does not remove the report: the row says learners can no longer open it, under the title it was last reported as — never passing the old title off as current.
• An item its area could not be asked about just now says that too; the editor link is offered only while learners can open it.

Preconditions

A learner account; a published challenge and a lesson.

Steps

1. As the learner, "Report a problem" on a challenge and a lesson — each reason, Other with and without a note (≤500).
2. Report the same item again while the first is open; look for Report on a Daily and during a live test.

Expected

• Report sits beside the page's own request control; Spam/Incorrect/Inappropriate take an optional note, Other requires one (≤500 chars).
• A second report of an item while the first is open repeats nothing; a Daily and a live test do not offer Report.
• Five reports a minute is the learner's ceiling — past that they are asked to try again shortly.

Preconditions

Just moved some reports.

Steps

1. Open /admin/audit and look for the report moves.
2. Re-open a report and read its own history.

Expected

• Report review is not recorded in the audit history (it keeps protected actions only); each report's own history records every move with who and when.

Preconditions

Signed in as staff; topic requests exist (file one as a learner if needed).

Steps

1. Open /admin/content-gaps.
2. Read both panels.

Expected

• "Asked for" (topic requests) beside "Searched for and not found" (WizBit search misses) — each its own counts, never added together.
• Neither panel exposes requester identity or raw queries; a failed lookup is not a content gap.

Preconditions

Dev tools to block one panel's read.

Steps

1. Block the requests/WizBit search-miss read in dev tools; reload.

Expected

• The blocked panel says it cannot be read; the other still renders — no invented zeros, no blank page.

Preconditions

Signed in as staff.

Steps

1. Find Content gaps in the console navigation.

Expected

• It sits in Insights beside Participation, Home suggestion and Next actions — it is a report, not an authoring surface.

Preconditions

A session whose check is over 15 minutes old (idle past it, or re-verify only at sign-in).

Steps

1. Try each protected write with the stale check: publish, archive, delete, a submission decision, a vocabulary add, a company change, an invalidation.
2. Type a reason/note first, then take the trip and return.

Expected

• Every confirming button reads "Confirm on the main site" once the check has lapsed — the session itself says until when it is fresh.
• You come straight back to the same address; what you typed (reasons, notes, labels, a change's own id) is held in the tab and restored — the same change confirms once. A typed name confirmation is typed again.
• The api still refuses a write sent with a stale check regardless of the button — the trip is convenience, not the guard.

Preconditions

Any protected action ready to confirm.

Steps

1. Double-click the confirming button; retry the request from a duplicated tab; re-open the address and repeat.

Expected

• Repeating a confirmed operation returns its existing result instead of duplicating it — one publish, one archive, one decision, one audit entry.
• Duplicated tabs do not double-apply; a refreshed confirmation names what already happened.

Preconditions

🖥🖥 Two staff sessions; the same item open in several studios across the day (practice studio, paper, template, lesson, company details).

Steps

1. In each, let one author save, then have the other save over the stale read.

Expected

• Every studio stops on the conflict and offers Keep mine or Load theirs — the company form and the paper studio too; never a silent overwrite or merge.
• What was typed survives whichever is chosen.

Preconditions

Both roles; some writes from today's session exist (publishes, vocabulary changes, an invalidation, an accommodation). 🖥🖥 helps.

Steps

1. As Admin, open /admin/audit; filter by action, who, item and day.
2. As Super Admin, read the same trail; open an action-on-people entry (e.g. an invalidation) and then try it as Admin.

Expected

• The trail groups entries by IST day — action, item, time and who (by role name, or "The platform, automatically"); an entry opens beside the list at its own address.
• Admin reads the content entries — publications, approvals, skills and topics — and is offered only the actions an Admin can read; an action-on-people or settings entry reads to an Admin as not found.
• Super Admin reads the whole trail; no role can edit or delete entries; a content change shows as from → to where it carries one.

Preconditions

Dev tools to fail selected reads.

Steps

1. Block one read at a time on: a staff list's counts, a review page's figures, schedule health, the submissions queue, content reports.
2. Reload and read each failed panel beside the working ones.

Expected

• A failed read says so — never rendered as 0, an empty list, or a falsely healthy state; usable panels keep their information when another fails.
• Lists show actual counted totals only — a failed count does not erase readable rows; an unavailable exact impact count blocks the irreversible action relying on it (never confirmed on an estimate).
• Nothing authored, no matches, unauthorized, unavailable and a genuine zero are five different states.

Preconditions

Any bounded field in any studio.

Steps

1. Paste text past a field's limit; paste a CSV row past a bound; drop an oversized file on an upload.

Expected

• The text stays typed and the save state stays honest — "Not saved: a field is over its limit…" or "Unsaved changes" — until shortened; nothing is silently truncated or partly saved.
• A document over its cap is refused with the cap named (lesson/paper 4 MB; challenge/Daily/Debug/template 12 MB; subject import 10 MB) and nothing is saved.

Preconditions

Any session.

Steps

1. Walk today's screens reading the words: headings, empty states, refusals, confirm dialogs.

Expected

• No "Labs", no internal state names, no specification sentences, no raw errors or secrets in any message — a calculated figure may say when it was worked out in plain words.
• Times and dates are labelled IST where a learner or colleague could misread them; numbers use Indian grouping.

Preconditions

Browser at 390 and 768 px.

Steps

1. Walk the queue, a practice studio, the paper studio's index, the course builder's outline and the reports queue at both widths.

Expected

• Nothing overflows or traps; the console's bottom dock serves navigation; a practice studio's checks sit behind a Checks button on a narrower screen; confirm dialogs remain reachable and readable.
• Authoring stays a computer-shaped job but never breaks or lies at a small width.

Preconditions

Unplug the mouse for a pass.

Steps

1. Tab through the console nav, a staff list's filters, a studio's sections and a confirm dialog.

Expected

• Navigation is usable with a keyboard; focus is visible; dialogs trap and return focus to their opener; destructive confirms still need their typed text — no accidental confirms.