Skip to main content

PRD-013: Case Detail Shell — Tab Structure & Design-System Parity

Author: Product Management | Date: 2026-09-11 | Status: Draft | Version: v0.1.1

Revision History​

VersionDateAuthorDescription of Change
v0.1.02026-09-11Product ManagementInitial draft, compiled from a design-parity audit of the live /c/:companyId/cases/:caseId screen against approved mockups.
v0.1.12026-09-11Product ManagementResolved the CaseTeamPanel placement open question: moved to Aprovações (SYS-REQ-402), not Visão Geral. Re-tested the observed diligências load error — could not reproduce; not treated as a confirmed bug.

1. Context & Business Rationale​

/c/:companyId/cases/:caseId (the case detail screen) is the day-to-day workspace for every actor in the disciplinary-process workflow — HR admin, case manager, instructor, revisor jurídico. Each of the eight phase PRDs (PRD-004 through PRD-010, plus the cross-phase PRD-011 Dossier) defines the backend behaviour for its phase, but none of them own the shell the phase screens sit inside — the header, the tab bar, the overview/checklist split. That shell was built once, early, as a single scrolling page (case-detail.tsx + phase-workspace.tsx), and has grown a panel per phase feature as each backend slice shipped, without ever being restructured to match how the product was actually designed to look.

Design has since produced mockups for this screen showing an 8-tab shell (Visão Geral, Checklist, Prazos, Anexos, Aprovações, Portal, Audit Log, Dossiê Final) built on the cream/deep-green, serif-heading visual language that packages/design-system already ships (tokens.css, landed under PR #351, feat/design-system-warm-theme/tokens-foundation). The live screen has none of that structure: three nav entries (one of them dead text), everything else stacked on one page in plain unstyled blocks. This PRD is the frontend restructuring needed to close that gap, reusing what already exists rather than inventing new concepts — most of the eight tabs already have real, working panels; they've just never been given a tab to live in.

2. Problem Statement​

Today's case-detail "shell" is two layers: case-detail.tsx renders the header, an 8-phase horizontal Stepper, CaseTeamPanel, and CasePhaseHistoryPanel unconditionally — above a 3-item nav (Visão Geral, a dead "Portal (em breve)" label, Auditoria) — so the team panel and phase history currently show on every tab, including Auditoria. Its index route (today's "Visão Geral") then renders phase-workspace.tsx in full: a single, fully-editable 12-panel workspace (CaducidadePanel, CaseDeadlinesPanel, CaseRemindersPanel, CaseAdvancePanel, ChargesReviewGatePanel, ChargesDeliveryPanel, ChecklistPanel, DiligenciasPanel, InstructorProposalPanel, CaseResponsePanel, DeliverablesPanel, PreventiveSuspensionPanel), with no read-only summary anywhere and none of the Card/serif-heading/vertical-Stepper visual language the design system already provides. A user working a case today has to scroll past unrelated panels to find the one they need, and "Visão Geral" is, despite its name, the most editable screen in the app.

3. Goals, Non-Goals, and Success Metrics​

3.1 Goals​

  • Restructure the case detail screen into a tab shell — header (with back navigation) plus an 8-tab bar — mirroring the existing empresa-shell.tsx layout-route pattern (a thin shell + <Outlet />; see SYS-REQ-101 on how tab gating differs from empresa-shell.tsx's).
  • Give Visão Geral a real, read-only summary screen (process summary, phase history, deadlines in progress, recent activity) — today's index route is the entire editable PhaseWorkspace, not a summary.
  • Retire phase-workspace.tsx as a single mounted unit, and redistribute its 12 panels across Checklist/Prazos/Aprovações (see §6.3–6.4's full mapping) — every phase keeps reusing the same tab set, exactly as PhaseWorkspace itself is reused across phases today; only the container changes, not the "one component set for every phase" property.
  • Give Checklist its own tab, restyled to the mockup's two-column layout: a vertical phase-progress rail plus Card-sectioned content, showing whichever of the phase-scoped panels apply to the case's current phase (Abertura's mockup shows 3 sections; a later phase may show others — see SYS-REQ-304), ending in an advance-when-ready call to action.
  • Apply the design system's existing visual language consistently on this screen: Card sections, serif section headings, monospace identifiers/counts, vertical Stepper.
  • Extract the already-working phase panels — Prazos (deadlines + reminders + the caducidade clock), Aprovações (the charges-review gate, PRD-006 #58), Audit Log (already a working route) — into their own tabs.
  • Land Anexos and Dossiê Final as tabs backed by their real data: Dossiê Final surfaces PRD-011's dossier export; Anexos needs a contracts pass to define a case-wide evidence rollup (today's evidence is scoped per-diligência).

3.2 Non-Goals​

  • No new backend workflow behaviour — every CaseStatus/gate/deliverable rule stays exactly as specified in PRD-004 through PRD-011. This PRD only changes how existing (and PRD-011's already-specified but unbuilt) data is arranged and styled on screen.
  • No change to the left primary sidebar (Painel/Definições stay absent — see Open Questions).
  • No change to CaseTeamPanel's underlying team-assignment behaviour — only where it's placed moves (to Aprovações, SYS-REQ-402), and it stops rendering unconditionally on every tab (today's actual behaviour — see §2).
  • A load error was observed on case-diligencias-panel.tsx once during the audit ("Não foi possível carregar as diligências"), on one specific archived case. Re-tested against the same case afterward and could not reproduce it — the endpoint correctly returned 403 NotTheAssignedInstructor, and the panel correctly rendered its "Visível apenas para o instrutor nomeado" copy, not the generic error. Not treated as a confirmed bug; no fix applied here. If it recurs, it needs its own repro before a ticket is filed.
  • Portal tab: stays a disabled/"em breve" tab entry, unchanged — its real screen is Portal epic #226 (sub-issues #108/#107), out of scope here.

3.3 Success Metrics​

Metric TypeMetric DefinitionBaselineTarget
PrimaryCase-detail tabs that route to a real, single-purpose screen (of 8)2 (Visão Geral index, Auditoria)8 (Portal remains an intentional stub)
SecondaryDesign-system primitives (Card, serif headings, vertical Stepper) adopted on this screen0 sectionsAll restructured sections
Guard RailExisting panel functionality (team, deadlines, checklist, deliverables, gates, suspension)100% working todayNo regression — same reads/writes, new layout only

4. User Personas & Actors​

4.1 HR Admin / Case Manager (Primary)​

  • Role: opens a case daily to check status, work the checklist, and produce/validate deliverables.
  • Frustrations: today, doing any one of those means scrolling past eight unrelated panels; there's no quick, read-only "where does this case stand" view to check before diving in.

4.2 Instrutor (Primary)​

  • Role: runs diligências, produces phase deliverables, records the preventive-suspension decision — all currently panels stacked on the same long page.

4.3 Revisor Jurídico (Secondary)​

  • Role: approves or rejects the Nota de Culpa at the charges-review gate (charges-review-gate-panel.tsx, PRD-006 story #58). Today this gate is just another panel in the middle of the scroll; a reviewer has no dedicated place to find "what's waiting on my approval."

5. User Stories​

  • As an HR admin, I want a read-only Visão Geral tab summarising the case's status, phase history, active deadlines, and recent activity, so I can check where a case stands without scrolling through every working panel.
  • As an HR admin or instructor, I want a dedicated Checklist tab laid out as a phase-progress rail plus sectioned base-info/deliverables/checklist cards, so the phase's required work is legible at a glance instead of buried in a flat scroll.
  • As any case-team member, I want Prazos (deadlines + reminders) on its own tab, so I don't have to scan past checklist/deliverable content to find an upcoming deadline.
  • As a revisor jurídico, I want an Aprovações tab that surfaces gates awaiting my decision (starting with the charges-review gate), so approval work isn't mixed in with drafting work.
  • As any case-team member, I want a Dossiê Final tab that surfaces the case's compiled dossier (PRD-011) once it exists, so the exportable record has an obvious home instead of no UI at all.
  • As any case-team member, I want an Anexos tab listing the case's evidence/attachments across all phases, so I don't have to open every diligência individually to find a given file.
  • As any user on this screen, I want a back control in the header, so I can return to the Processos list without using the browser back button.

6. System Requirements​

6.1 Shell & navigation​

  • SYS-REQ-101: The case detail screen shall render as a shell (header + 8-tab nav + routed content), following the same layout-route pattern as empresa-shell.tsx: a thin parent component with <Outlet />, each tab a real child route registered in routes.tsx. Gating differs from empresa-shell.tsx's, though: that shell gates tabs on company-role permissions via useAuthorization(), but a case-scoped action like the Aprovações gate is already gated on the server-computed, per-case caseDetail.data.permissions list (see charges-review-gate-panel.tsx's existing check), not a company role — consistent with frontend-frontoffice/CLAUDE.md's note that case-scoped capacity must come from the server per case, never be derived from CompanyRole. Any tab whose visibility (not just its controls) should depend on the caller's case-level standing needs this same per-case check, not useAuthorization().
  • SYS-REQ-102: The header shall render a back control (PageHeader's existing onBack prop) returning to the case list.
  • SYS-REQ-103: Each tab shall be independently reachable by URL (a distinct route per tab, not client-side-only tab state), consistent with this app's existing routing conventions (frontend-frontoffice/CLAUDE.md, "Navigation & the route registry").
  • SYS-REQ-104: The Portal tab shall remain a disabled/"em breve" entry — not a route — exactly as it is today, until Portal epic #226 ships a real screen.

6.2 Visão Geral (read-only overview)​

  • SYS-REQ-201: Visão Geral shall render a process-summary card (arguido, current phase, instructor, active flags), a phase-history card (reusing case-phase-history-panel.tsx), a "Prazos em curso" card summarising the same reads the Prazos tab uses in full — deadlines, reminders, and the caducidade clock (today's CaducidadePanel, reassigned to Prazos per SYS-REQ-401) — and a recent-activity card.
  • SYS-REQ-202: Visão Geral shall present no editing affordance — every control on this tab is read-only. CaseTeamPanel (assigning revisor jurídico/decisor) lives on the Aprovações tab instead (SYS-REQ-402), resolving what was this section's open question.
  • SYS-REQ-203: Visão Geral shall end with a call to action that navigates to the Checklist tab.

6.3 Checklist​

  • SYS-REQ-301: The Checklist tab shall render a two-column layout: a left phase-progress rail (the design system's Stepper in orientation="vertical") and a right column of Card-sectioned content.
  • SYS-REQ-302: Each card section (base info, formal deliverables, checklist items) shall show a completion count (e.g. "7/7 preenchidos") derived from existing read data — no new backend field.
  • SYS-REQ-303: The tab shall end with an advance-readiness call to action, enabled only when every section is complete, reusing the existing advance command (case-advance-panel.tsx).
  • SYS-REQ-304: The Checklist tab shall be phase-aware, not Abertura-specific: it shall render whichever of today's phase-scoped PhaseWorkspace panels apply to the case's current phase, each restyled as one of the tab's Card sections. This is every panel not already reassigned to Prazos/Aprovações/Audit-Log/Dossiê-Final/Anexos — concretely, today's ChecklistPanel, DeliverablesPanel, DiligenciasPanel, InstructorProposalPanel, CaseResponsePanel, ChargesDeliveryPanel, and PreventiveSuspensionPanel. Abertura's own Checklist tab (the provided mockup) only needs base-info/deliverables/checklist because Abertura is the only phase that doesn't use the others — a later phase's Checklist tab surfaces whichever sections its own phase populates, with no shell change required.

6.4 Prazos, Aprovações, Audit Log (extract existing panels)​

  • SYS-REQ-401: Prazos shall be its own tab/route, rendering case-deadlines-panel.tsx, case-reminders-panel.tsx, and today's CaducidadePanel (currently inside phase-workspace.tsx), unchanged in behaviour.
  • SYS-REQ-402: Aprovações shall be its own tab/route, rendering the existing gate panel(s) — starting with charges-review-gate-panel.tsx (PRD-006 #58) — built on the reusable gate-decision-panel.tsx, so later gates (any future phase's decision gate) land in the same tab with no shell change. Gated per SYS-REQ-101's per-case caseDetail.data.permissions check, matching charges-review-gate-panel.tsx's existing behaviour — not useAuthorization(). Also renders case-team-panel.tsx (assigning revisor jurídico/decisor) — resolves the §8 open question on its placement, since those two roles are exactly who this tab's gates are for.
  • SYS-REQ-403: Audit Log shall be added to the tab bar, routing to the existing case-audit.tsx screen — no new screen, tab-bar wiring only.

6.5 Dossiê Final​

  • SYS-REQ-501: Dossiê Final shall be its own tab, rendering the dossier export defined by PRD-011 once that backend work lands. If PRD-011's export is not yet built when this shell ships, the tab shall render a real "not yet available" state rather than being omitted from the bar (consistent with how Portal is handled today).

6.6 Anexos​

  • SYS-REQ-601: Anexos shall be its own tab, listing the case's evidence across every diligência/phase — a rollup, not per-diligência-only as evidence-section.tsx is today. The read this needs does not exist yet — see Open Questions; scope/shape to be settled before a contracts pass.

7. Workflows & Usage Scenarios​

Processos (case list)
      │  open a case
      ▼
Case Detail Shell (header + 8-tab bar)
      │
      ├─ Visão Geral (index, read-only)  ── "Abrir Checklist da fase" ──►  Checklist
      ├─ Checklist   (progress rail + card sections + advance CTA)
      ├─ Prazos      (deadlines + reminders)
      ├─ Anexos      (evidence rollup — needs contracts)
      ├─ Aprovações  (gate decisions, e.g. charges-review)
      ├─ Portal      (disabled — em breve, unchanged)
      ├─ Audit Log   (existing screen, added to the bar)
      └─ Dossiê Final (PRD-011 export, or "not yet available")

7.1 Usage Scenario 1: HR admin checks a case before a meeting​

  1. The HR admin opens Processos and selects a case.
  2. Visão Geral loads by default: they see the current phase, the last three activity entries, and that the caducidade clock has 13 days remaining — no editing controls, nothing to accidentally change.
  3. They click "Abrir Checklist da fase" and land on Checklist, where the base-info and deliverables cards both show 100%, and one checklist item is still "Por rever."

7.2 Usage Scenario 2: Revisor jurídico works their approval queue​

  1. The revisor jurídico opens a case flagged for their review and goes straight to the Aprovações tab (rather than scrolling past checklist/deliverable panels to find the gate, as today).
  2. They review the Nota de Culpa deliverable inline and approve it via the existing GateDecisionPanel control — no behaviour change, only relocated.

8. Open Questions​

  • CaseTeamPanel placement. Resolved: it moved to Aprovações (SYS-REQ-402) — revisor jurídico/decisor are approval-adjacent roles, and Visão Geral now has no editing affordance at all.
  • Anexos' exact shape (SYS-REQ-601). Is a case-wide evidence rollup a new read endpoint over existing diligência-scoped evidence, or does it also need its own case-level upload path (e.g. correspondence, non-diligência documents)? This needs a contracts pass before to-issues can size it.
  • Dossiê Final sequencing. PRD-011 (Dossier Export) is itself still Status: Draft with its format spike (PDF vs ZIP) unresolved. Does this shell's Dossiê Final tab ship as a placeholder until PRD-011 lands, or does PRD-011 need to move first?
  • Left sidebar (Painel, Definições). The mockups show them; this codebase's own convention (nav-items.ts) is to never add a nav item pointing at a screen that doesn't exist. Confirming: out of scope here, revisited only when those screens are actually planned.
  • Baseline/target figures in 3.3 beyond the tab count are qualitative (no dashboard tracks this screen's usage today) — flagging rather than inventing a number.