Real Pilot Client QA Runbook.
Answer one question: can a real paying client use Rendorax end-to-end? Run Scenarios A–G in a real browser against the environment you will pilot. Do not start First International Onboarding until this sprint passes.
Current maturity (reference)
- Business Layer ~95%
- Workflow Layer ~95%
- Platform Foundation ~90%
- Pilot Readiness ~80% — blocked on real browser QA, production env, user behavior
How to run
- Use production-like env (or staging that mirrors prod Auth, R2, Redis).
- One dedicated pilot org first; Scenario G needs a second org.
- Mark each check Pass / Fail. Any Fail in A–E or G = sprint Fail.
- Record email provider, browser, and date on the scorecard below.
Scenario A — Admin — Request to Project
Prove commercial intake becomes a production Agency Project.
Actors: Admin + Primary Client (or Approver for proposal)
[ ]Admin creates Client (email + temporary password)
Expect: Client can sign in at /access → /dashboard
[ ]Admin creates Editor with specialization
Expect: Editor signs in → sees Dashboard (not Admin HQ)
[ ]Client submits Project Request
Expect: Appears in Admin Request Inbox as Submitted
[ ]Admin reviews → creates Proposal → Send
Expect: Request status Quoted; Client sees Proposal
[ ]Client/Approver Approves Proposal
Expect: Request status Approved (Admin cannot fake Approve)
[ ]Admin Convert To Project
Expect: Status Project Created; AgencyProject at Awaiting Assets
[ ]Retry Convert on same request
Expect: 409 Already converted — no second project
[ ]Client opens Dashboard project list
Expect: Converted project visible without Admin creating it again
Pass rule: Pass only if convert + visibility work and duplicate convert fails.
Scenario B — Reviewer — Invite and limits
Reviewer joins org and can comment, but cannot approve or download Master.
Actors: Primary Contact (invite) + Reviewer invitee
[ ]Primary invites Reviewer (email or copy link)
Expect: Pending invite; role Reviewer
[ ]Reviewer opens /access/invite → sets password → Accept
Expect: Auth role client; lands on Client Dashboard
[ ]Reviewer opens org project / request
Expect: Can view request and review assets
[ ]Reviewer posts a timed comment
Expect: Comment appears; author shows Reviewer identity
[ ]Reviewer tries Approve Proposal (if any sent) / Approve Version
Expect: UI hidden or API 403 — cannot approve
[ ]Reviewer opens Master Delivery → Download
Expect: Download blocked (UI and/or API 403)
Pass rule: Pass only if comment works and approve + download are denied.
Scenario C — Approver — Decisions and delivery
Approver can approve review and download Master.
Actors: Primary Contact (invite) + Approver + Editor (delivery ready)
[ ]Invite Approver → Accept + password
Expect: Dashboard access as org Approver
[ ]With sent Proposal on Quoted request — Approve Proposal
Expect: Request → Approved (or use Scenario A Approver for this)
[ ]On Review Version — Approve Version
Expect: Review decision recorded as approved
[ ]With active Master Delivery — Download Master
Expect: Download succeeds; Access Granted recorded
Pass rule: Pass only if approve review + master download both succeed.
Scenario D — Editor — Production path
Editor completes assigned production work on the converted project.
Actors: Admin (assign) + Editor
[ ]Admin assigns Task on converted project to Editor
Expect: Task appears on Editor Dashboard
[ ]Editor uploads Review Version to project (03_REVIEW)
Expect: Asset linked to project; Client can preview
[ ]Editor (or Client) sets Picture Lock when ready
Expect: Lock event visible; rules match product policy
[ ]Editor uploads/registers Master Delivery (05_MASTER_DELIVERY)
Expect: Delivery current; Approver/Primary can download
Pass rule: Pass only if task → review → lock → master chain works on one project.
Scenario E — Password Recovery
Paying client can recover access without Admin console.
Actors: Any provisioned client user
[ ]/access → Forgot Password? → enter email → Send Reset Link
Expect: Success message; email arrives (Supabase Auth email)
[ ]Open reset link → /auth/callback → /reset-password
Expect: Session valid; New Password + Confirm form
[ ]Update Password → Go To Login → sign in
Expect: Login with new password succeeds
[ ]Expired / reused link
Expect: Clear error; can request a new link
Pass rule: Pass only if email delivery works in the environment under test (Redirect URLs configured).
Scenario F — Archive / Restore
Finished work leaves active surfaces; Restore brings it back.
Actors: Admin + Client + Editor
[ ]Admin Archives the pilot project
Expect: Removed from active Admin/Client/Editor lists and Operations Queue
[ ]Client/Editor attempt active workspace actions on archived project
Expect: API 409 / blocked — not editable as live work
[ ]Admin Restores project
Expect: Visible again in active lists; workflow usable
Pass rule: Pass only if archive hides from active ops and restore recovers.
Scenario G — Organization Isolation
Org A must not see Org B data (especially comments).
Actors: Two separate Client Organizations (A and B)
[ ]Create Org A project with comments; Org B separate project
Expect: Each org only sees own projects/requests
[ ]Org A user opens review; query/browse comments
Expect: Cannot read Org B comments (RLS / UI)
[ ]Org B member tries Org A project id / request id
Expect: 403 / empty — no cross-org leak
Pass rule: Fail the sprint if any cross-org comment or project leak is found.
Sprint scorecard
| Scenario | Result | Notes |
|---|---|---|
| A — Admin — Request to Project | Pass / Fail | — |
| B — Reviewer — Invite and limits | Pass / Fail | — |
| C — Approver — Decisions and delivery | Pass / Fail | — |
| D — Editor — Production path | Pass / Fail | — |
| E — Password Recovery | Pass / Fail | — |
| F — Archive / Restore | Pass / Fail | — |
| G — Organization Isolation | Pass / Fail | — |