Production Certification Checklist

Use This Reference Carefully

Use this guide when a safety, accountability, or follow-up record needs careful handling. In this guide, Production Certification Checklist narrows that work to checklist for proving the dashboard report system works across routes, roles, workflows, records, and cleanup. Because this is a reference page, read it as part of the Report System learning path rather than as an isolated checklist.

A report is a written memory of something important. The goal is to protect people, keep facts clear, and leave enough context for future reviewers. Read the page for the decision it helps a person make, then use the steps and checks as a steady path from context to action to proof.

What This Reference Collects

This page is for checking details. Use it to confirm names, routes, records, fields, or certification points before relying on memory. The intended readers are Support leads and Release certifiers. If the guide names a dashboard route, service area, export, or record type, treat that name as a pointer to real operational responsibility.

• Primary surface or service: /reports, /reports/all, /reports/new, /reports/detail?id=:incidentId, and /reports/manage?id=:incidentId.
• Records or contracts involved: Certification evidence, Test records, and Cleanup runs.
• Main care point: Watch for incomplete facts, unfair wording, privacy exposure, or a decision that another reviewer cannot understand later.
• Proof worth keeping: report ID, saved status, revision history, person profile, evidence note, reminder, reviewer decision, and handoff owner.

How To Find The Right Entry

1. Search for the exact name or route: Begin by naming the Report System situation, the owner, and the exact item involved in Production Certification Checklist.
2. Read the surrounding note, not only the matching line: Use /reports, /reports/all, /reports/new, /reports/detail?id=:incidentId, and /reports/manage?id=:incidentId to connect the words on the page to the screen, file, service route, or record that people actually use.
3. Compare the reference with the live screen, file, or service evidence: Keep Certification evidence, Test records, and Cleanup runs in view so the work stays tied to the records or contracts it can affect.
4. Save the evidence that proves the entry was checked: Before handing off, save proof such as report ID, saved status, revision history, person profile, evidence note, reminder, reviewer decision, and handoff owner so another reviewer can understand the facts without relying on memory.

Confirm The Reference Still Matches Reality

You are ready to use the rest of this page when the purpose, owner, affected information, and proof are all clear enough for a second person to review.

1. Scope is named: The work is tied to the correct page, event, report, route, file, person, or record.
2. Impact is understood: The operator can explain the effect on people, privacy, fairness, evidence, and the trustworthiness of the record.
3. Proof is findable: The handoff points to evidence that another reviewer can understand the facts without relying on memory.

End-to-end operator runbook

Use this numbered runbook when you need to operate this area without getting stuck. Read the purpose of each step, do the action in order, and use the final sentence as the checkpoint before continuing.

1. Step 1 - Choose the right path. Use this reference when you need to confirm a route, role, record, or certification expectation before acting. This anchors the work to the correct scope before any record changes.
2. Step 2 - Confirm scope and records. Find the dashboard surface or record type involved in the current task. Pause here and confirm the note is factual, fair, and reviewable.
3. Step 3 - Do the operating action. Compare what you see in /reports, /reports/all, /reports/new, /reports/detail?id=:incidentId, /reports/manage?id=:incidentId with the expected access, state, and records described here. This keeps the report useful to the next reviewer instead of only to the person writing it.
4. Step 4 - Verify the result. If something does not match, stop the workflow and capture the route, event/report ID, user role, and visible error state. The next action should still protect privacy, evidence, and due process.
5. Step 5 - Hand off remaining work. Return to the related operating guide after the reference question is answered. This leaves a handoff trail another operator can understand.

Route certification

Verify every report route by direct load, refresh, SPA navigation where applicable, desktop, and mobile:

• /reports
• /reports/all
• /reports/my-reports
• /reports/mine
• /reports/new
• /reports/detail?id=:incidentId
• /reports/manage?id=:incidentId
• /reports/bans
• /reports/ban-appeals
• /reports/cross-bans
• /reports/network-ban-appeal?entryId=:watchlistEntryId
• /reports/profiles
• /reports/watchlists

Workflow certification

Certify:

• Create report.
• Open detail page.
• Open manage page.
• Edit report.
• Upload or reference markdown evidence.
• Change status.
• Add local ban/watchlist action.
• View bans list.
• View watchlists list.
• Create and decide cross-ban request.
• Submit, edit/resubmit, deny, and approve network ban appeal.
• Create, link, unlink, update, and delete person profile.

Role certification

Use separate actors for:

• Admin / partner_admin
• Trust and Safety / event_staff
• ConOps / partner_operator
• Marketing / viewer
• FPH administrator / fph_admin

Prove both allowed and denied behavior. A denied mutation is a passing result when the role should not have access.

Evidence to capture

• Command output.
• Desktop and mobile route evidence.
• Created test record IDs.
• Mutation result summary.
• Role denial summary.
• Cleanup result with zero residue.
• Known non-blocking warnings, if any.

Suggested validation commands

Use the partner dashboard’s current package scripts as source of truth. At minimum, a release pass should include dashboard type/build checks, route checks, workflow certification, role matrix certification, API type checks where relevant, and cleanup verification.

For this docs app, run:

pnpm check
pnpm build