Skip to main content

Two deliverable subsystems

Investigative actions (diligências, inquiry_actions) have two parallel editor subsystems that share a state contract but duplicate the logic:

1. Witness path (legacy, special-cased)​

WITNESS_HEARING actions open InquiryActionDrawer → deliverable HearingMinutesDrawer (the Ata da Inquirição). Steps and sections are hardcoded: 5 steps (preparation, identification, warning, questions, closing) and 7 minutes sections. A comment calls it "the legacy drawer".

2. Generic path (config-driven)​

All other action types open GenericActionDrawer → deliverable ActionDeliverableDrawer, both driven by ActionTypeConfig from src/lib/inquiry-action-types.ts (~900 lines): substeps, fields, suggested questions, deliverable sections, and generators are all data.

InquiryActionsList routes between them on action.action_type and filters by a caller-supplied phase string (it is otherwise phase-agnostic).

Shared contract​

Both persist into inquiry_actions.step_data JSONB (legal state in JSONB): _validated flags per step, a deliverable _status (draft/completed/approved), _formal_document, _upload_mode (text/file). Two status vocabularies (action-level vs deliverable-level).

Gotchas​

  • Latent stale-form bug: the step forms in InquiryActionDrawer and GenericActionDrawer seed local state on mount but lack the prevActionId reset that the deliverable drawers have — switching actions without remount can retain stale data.
  • Reopen dialogs carry legal warnings ("if already shared with the arguido…") but reopening is not actually blocked by any check on portal-sharing status — advisory only.
  • company_template creation mode reuses the plain upload path — no distinct template logic; an aspirational/dead branch.
  • InquiryReportDrawer touches the DB directly (deliverables, audit, storage) while the other drawers go through the useInquiryActions hook — inconsistent data-access layering.

Rebuild implication​

Unify into one config-driven deliverable subsystem; make witness hearings just another configured action type; enforce reopen/lock rules in data, not warning text; fix the form-reset pattern.