v2 Gap Analysis — Admin & System

Admin & System — V2 Review Gap Analysis

Source: BACKEND-RAMBLINGS.md lines 371-388
Spec: docs/admin-spec/10-admin-system.md
Implementation: src/pages/admin-system/

Screens covered

• Admins
• Issue Queue

(Stakeholder does not mention Settings, Notifications, Support Links — these remain per spec; not analyzed here.)

Admins

Matches

• Name, Email, Role, Status, Last Login columns: All present in both spec and implementation.
• Two-tier permission model: "Full or view-only" exactly matches spec's Admin (user_type=1) vs. View-Only (user_type=5).
• Create/Edit/Delete actions: All three capabilities implemented and functional.
• Role dropdown on edit: Allows switching between Admin and View-Only roles.

Expands

• Sortable columns: Implementation adds sorting to Name, Email, Role, Status, Last Login — spec doesn't explicitly mention sorting.
• Empty state messaging: Implementation includes "Create an admin to grant backend access" — stakeholder did not request this.

Deviates

None identified. Implementation faithfully follows spec.

Adds

None beyond empty state messaging (benign).

Ambiguous

None. Admins screen is clear and fully specified.

Issue Queue

Stakeholder explicitly says: "This needs a little bit more discussion."

Implementation covers most spec requirements, but stakeholder left three action types unresolved.

Matches

• Data columns: Student Name, Type, Subject, Date Reported, Status, Priority — all present.
• Sortable columns: Implementation allows sorting (spec marks as "Yes").
• Status values: Open, In Progress, Resolved, Closed — matches spec exactly.
• Priority values: High, Medium, Low — matches spec exactly.
• Issue Type values: Bug, Content, Account, Other — matches spec exactly.
• View Issue detail: Row click opens detail view with description + student info (spec requirement).
• View Student: Student name click navigates to Student Detail Page (spec requirement).

Expands

• Search functionality: Implementation adds search by student name or subject; spec only mentions list + filter bar (not search).
• Filter bar with multi-select: Implementation includes Status, Priority, Type filters; spec mentions "Filter bar" but doesn't detail filter types/options.

Deviates

• Status transitions: Implementation shows Resolve/Close buttons with conditional display (not shown if already Resolved/Closed). Spec shows both "Resolve" and "Close" as available actions but doesn't specify conditional logic.

Adds

• Close button behavior: Implementation adds "Close" as a separate action from Resolve (visually distinct). Stakeholder said "close it or resolve it" + "handle it" but didn't clearly define three distinct action types or their logic.

Ambiguous

These are the core discussion points stakeholder flagged:

1. "Handle it" action: Spec shows Resolve, Close, but no "Handle" action. Stakeholder says "be able to... handle it" as a separate verb from resolve/close. Is "Handle" a state update, a workflow step, or synonym for one of the existing actions?

2. Delete action: Spec does NOT include delete capability in Issue Queue actions (section 6.5 shows: View, Update Status, Assign Priority, View Student, Resolve, Close — no delete). Stakeholder says "delete it" as a required action. Implementation also lacks delete button on issues.

3. Resolve vs. Close semantics: Is Resolved a terminal state? Can an issue move from Resolved → Closed? Can it move backward? Stakeholder didn't define the state machine.

4. Update Status dropdown: Spec shows "Update Status" as an action. Implementation shows Resolve/Close buttons on detail view but no explicit status dropdown. Should admin be able to set status to any of the four values (Open, In Progress, Resolved, Closed), or are Resolve/Close the only workflows?

Summary

Admins coverage: Fully matches spec. All required columns, two-tier permissions, and CRUD operations present. No gaps.

Issue Queue open questions:

• Define "Handle it" — is it a state, action, or alias?
• Confirm whether delete is in scope (spec excludes it; stakeholder requests it).
• Document state machine: Can issues transition backward? Is Resolved terminal?
• Clarify whether admin can manually set status to any value or only via Resolve/Close buttons.

Biggest ambiguities: Issue Queue action semantics (Resolve vs. Close vs. Handle) and delete scope remain undefined per stakeholder's note that this "needs more discussion."