[DigitByte]

Summary

Admins and lead verifiers can now manage subjects from the dashboard.

The Subjects page lists each subject's name, summary and creation date, with the same filtering and sorting as the other dashboard tables. You can edit one subject's name and summary, or select several on the current page to merge.

Before merging, you see the selected subjects, choose which one to keep, and can edit its name and summary.

The API doesn't rely on hidden buttons. It checks the caller's role, and the database checks again before making changes. A merge runs as one transaction: guide and objective tags, including drafts and past revisions, move to the subject you're keeping, overlapping tags become one, and the duplicates are removed. Guides and objectives stay intact. If any selected subject is already gone, nothing changes.

The kept subject keeps its ID, URL, publication status and creation date. If the selection includes a published subject, you have to keep a published one. Removed subject URLs won't redirect, and the confirmation says so.

Navigation already mentioned lead-verifier, but the database enum and API role schemas didn't define it. This adds the role without assigning it to anyone. Mobile dashboard tabs now use the same role checks as the desktop sidebar.

After an edit or merge, the API starts the existing best-effort background search sync for affected guide search cards.

Refs #521

Type of change

• Feature

Verification

• App, API and shared schema typechecks pass
• App production build and API build pass
• Formatting and lint pass, with one existing app lint warning
• Manually verified in a browser
• Followed app layout conventions
• No new dependencies

Everything CI runs passes locally against upstream deec6044, on Node 22 and pnpm 10.33.1: 345 app tests across 42 files, plus the API deploy dry run.

I added 12 UI tests and 15 API integration tests covering picking subjects, editing, changing which subject to keep, cancellation, validation, retries, pending requests, permissions, filtering, pagination, stale selections, keeping guide and objective tags, and updating search-card tags. One test starts two merges sharing a source subject and checks that one succeeds while the other is rejected without losing the guide's tag.

All 65 tests in the five related API files pass against local Supabase, including the existing dashboard, identity, subject and objective-subject tests. The search-card test mocks Typesense rather than using a live search server.

For the October 24 browser pass, I signed in with a local lead-verifier account, filtered the table, edited a subject, and reloaded to confirm the edit stuck. I cancelled a merge with both Cancel and Escape, then merged three test subjects and reloaded. The duplicates stayed gone, and database checks confirmed the guide and objective drafts remained with one tag pointing to the kept subject. I also checked the layout at a narrow viewport.

The November 1 recheck brought the branch up to date and reran the automated tests. It wasn't a new browser pass.

An earlier run on d54ae5d3 failed the existing Markdown-import round-trip test because the returned Markdown had different italic markers and trailing whitespace. It passed alone and in the next full run. Upstream has since changed the editor and test, and the full run on deec6044 passes. This branch doesn't add editor changes, and I haven't pinned down the earlier intermittent failure.

The existing prefer-for-of warning in objectiveGraphLayout.ts still shows up. That file isn't touched here.

What I didn't do: the full API integration suite, a fresh database reset, a live Typesense check, or testing on physical mobile devices or other browser engines.

Database and rollout

20261023115900_lead_verifier_role.sql needs to run before 20261023120000_manage_dashboard_subjects.sql, and both need to be applied before the API and frontend go out. Both applied cleanly to the existing local test database. I checked the new function and role types against the generated database types.

The merge function checks the caller's role before using elevated database permissions to move tags on revisions they might not otherwise see. It doesn't grant direct subject deletion permissions.

Merges can't be undone through the UI. Removed subject URLs won't redirect, and an already-open editor tab or browser-only draft can still hold an old subject ID; this doesn't rewrite those local copies. Search updates are best-effort, so a failed update needs a later resync.

This touches RLS policies, the database schema and roles, so per CONTRIBUTING it needs two maintainer approvals rather than one.