main/adm.php?_action=report renders a single form (JournalReport::admReportForm) with a report_type dropdown that dispatches to a materially different query/table per value — Submission Count (1), Submission Details (2), Published Articles Count (3), Published Articles Details (4), and Editorial Board (6) all appear as <option>s; report_type=5 (admArticleTrackingReport, per-article view/download tracking) is coded and reachable by setting the query param directly but is never rendered as a dropdown option or linked from anywhere in the app — kept as its own row since it renders a distinct screen, flagged here as hidden/undocumented. Cross-checked against apps/legacy/spec/superadmin/submission-details-report.md and published-articles-details-report.md, which independently confirm report types 2 and 4 as distinct features; the Excel-export variant of each (e.g. submission-details-report-excel.md) is a download of the same filtered result set, not a separate screen, so it isn't a separate row. This report action and its report_type switch are also present verbatim in mainm/adm.php (mainm/adm.php:404-410) and mainn/adm.php (mainn/adm.php:403-409) — reachable identically from all three dispatch files (and included in mainm/adm.php's "report-only" account whitelist, see the note below) — unlike py_report/arst_report/act_report/revTrack, which differ across dispatch files as documented in the rows and notes on this page.

arst_report and act_report have no case at all in main/adm.php's _action switch, but both are wired up with journalCode = 0 (platform-wide, matching the scoping pattern of every other row on this page) in mainm/adm.php and (for act_report) mainn/adm.php as well — the same "sourced from the sibling dashboard because main/adm.php's switch lacks the case" situation already documented on this segment's Subject Management and Content Management pages. act_report itself renders two materially different screens switched by its rtp GET param, printed as two visible tabs in CnActionReport::cnActionReportForm(): rtp=2 ("Users Action", the default whenever rtp is omitted) queries ju_contact_actions joined to ju_contacts with its own search fields/columns, while rtp=1 ("Submission History") queries ju_manu_tracking — hence the two separate rows above. rtp=1 is the code behind apps/legacy/spec/superadmin/submission-history-report.md ("User Activity Report — Submission History"), confirmed by the exact match between the spec's search/sort fields (ju_manu_tracking, "Search in" options, sort-by list) and class/cn.action.report.class.php; that same spec's "Inconsistency states" section independently corroborates the rtp=2/"Users Action" tab's existence and default status via its documented broken-email-link bug ("the report defaults to the other tab (Users Action)").

mainm/adm.php short-circuits to exit() before its _action switch whenever $_SESSION['juAdmUser__'] == 3, unless the action is one of "", "report", "arst_report", "act_report", "pass" — i.e. this restricted account's entire surface is the default dashboard, three of this module's reports, and its own password screen. Its dashboard menu still prints a revTrack link unconditionally alongside the whitelisted ones, but revTrack is not in the whitelist, so that link is a dead end (silent exit()) for this account — a genuine bug, not modeled as a separate page. main/adm.php and mainn/adm.php have no equivalent restricted-account gate.

JUPaymentReport::paymentReportResult varies its joined columns by a py_source filter (manuscript fees / reviewer honoraria / article purchases — see apps/legacy/spec/payment/payment-roles-and-flows.md), but this is one continuous filtered ledger view submitted from one form, not separately linked screens, and no per-source spec exists — unlike the report_type dropdown above, kept as a single row.

"Editorial Board Report" is a read-only, cross-journal listing of board members (name, role, speciality, contact info) for platform oversight — distinct from the CRUD screens that manage a journal's own board membership, which live in the Journal Admin and Publishing Workflow segments (see those segments' editorial-board pages).

mainm/adm.php's revTrack case (mainm/adm.php:390-403) calls EditorManager::reviewersAssignments(), then, whenever the request carries search or excel_rv — the exact parameter names on the report's own "Go"/"Excel" submit buttons rendered inside reviewersAssignments()'s own view (view/editor.view.php:2304-2305 for the Classic theme, :2671-2672 for Modern) — additionally instantiates JournalReport and calls $repp->getReviewersReport($_PARAMS) (mainm/adm.php:399-401). JournalReport::getReviewersReport does not exist anywhere in class/report.class.php or anywhere else in apps/legacy/js (a full-tree search finds only the one call site at mainm/adm.php:401 and zero definitions) — the real handler for this data is EditorManager::getReviewersAssignments, already invoked internally by reviewersAssignments() itself when search is set (class/editor.class.php:4764-4773), on the pre-existing $rep (EditorManager) object, not the newly-created $repp (JournalReport) object. So submitting the report's own Search or Excel button on mainm/adm.php throws a PHP fatal "Call to undefined method JournalReport::getReviewersReport()" and crashes the request after partial output. main/adm.php's revTrack case (main/adm.php:275-286) has no equivalent second call and is unaffected; mainn/adm.php has no revTrack case at all. Flagged here as a genuine dead-code/fatal-error bug, not a separate screen.

overview-reports is an unwired placeholder (filter form + Export are no-ops, hidden from the sidebar) with no legacy predecessor in the Reports module. Recorded as a New row for claim-exactly-once accounting; Phase C/D should decide whether to wire or drop it.