Phase steps & inputs

The case lifecycle note describes the PoC's eight phases as a state machine. This section is the level below that: for each phase, what the operator is actually asked to fill in, step by step, and where each answer lands.

Everything here was read off _poc/extracted/src/components/workflow/ — one *PhaseView.tsx per phase plus its field drawers. Field labels are quoted verbatim in Portuguese, because they are the vocabulary the client's team uses and the rebuild should preserve it.

The anatomy of a phase workspace

Seven of the eight phase views are built from the same three blocks:

1. Informação base necessária — a list of named fields, each opening a drawer with the real form. Each row shows Preenchido / Por preencher, and the header counts n/total.
2. Deliverables formais — the phase's formal documents, each Pendente → Rascunho → Em revisão → Validado → Fechado.
3. Checklist da fase — a one-line summary of the older case_checklist_items engine, which still owns the transition gate. See checklist auto-approve.

Below those sits a gate panel: either "Ainda existem elementos por completar nesta fase" with the count of what's missing, or "Próxima fase disponível" with the advance button.

Pareceres is the exception — no field block, no deliverable block, just three numbered steps.

The phases at a glance

#	Phase	CaseStatus	Base fields	Formal deliverables	Diligências
1	Abertura	INTAKE	7	3	—
2	Inquérito Prévio	PRELIMINARY_INQUIRY	5	1	yes
3	Nota de Culpa	CHARGES_ISSUED	7	1	—
4	Consulta do Processo	CONSULTATION_PORTAL	4	—	—
5	Resposta do Arguido	RESPONSE_WINDOW	5	—	—
6	Fase de Prova	EVIDENCE_PHASE	5	1	yes
7	Pareceres	BODIES_OPINION	—	2 (as records)	—
8	Relatório Final e Decisão	FINAL_REPORT	6 + 5	2	—

The diligências catalogue is shared by phases 2 and 6: eight action types, each with its own four-to-five-step mini-workflow and its own deliverable.

Three shared mechanisms

The deliverable drawer. Every formal document uses the same drawer, with three creation modes — auto (fill a hardcoded Portuguese template from case data), company_template (upload the company's Word template) and upload (attach a finished PDF/Word). Content is then editable as text, and Validar stamps validated_by + validated_at.

The emission drawer. Used twice — for the Nota de Culpa and for the final decision — with identical inputs: Método de envio* (Email · Carta simples · Carta registada · Carta registada c/ AR · Entrega em mão · Outro), Data de envio*, Comprovativo(s) de envio (files), Estado da receção (Não aplicável · Enviado, sem confirmação de receção · Recebido / confirmado · Devolvido / falhado), Data de confirmação de receção, Comprovativo de receção (file), Observações.

The field drawer. One per phase, holding the actual form controls. Inquérito Prévio has none of its own — it reuses AperturaFieldDrawer, which is why its fields write to the same columns Abertura does.

Three storage regimes, one UI

The uniform-looking field rows hide three very different persistence stories:

Where	Which phases	Schema?
cases columns	Abertura, Inquérito Prévio	Yes — real typed columns
case_response_data	Resposta do Arguido, read by Fase de Prova	Yes — created by a migration
case_phase_deliverables.metadata (jsonb)	Nota de Culpa, Consulta, Fase de Prova, Pareceres, Relatório Final	No — the table is never created by any migration

That last row is the phantom deliverables table: five of eight phases store their entire legal content in a jsonb blob on a table that does not exist in the migration history. See also legal state in untyped JSONB.

What "required" means here

Only the diligências catalogue has a declarative notion of required inputs — SubstepFieldDef.required and SubstepDef.requiredFields. Elsewhere there are exactly two hand-rolled guards: the dismissal justification in Nota de Culpa, and método + data de envio in the emission drawer.

Everywhere else, Preenchido is a plain truthy check in the browser (!!caseData.description), so a single space satisfies it — and nothing on the server cares either way. Pair this with client-side integrity.

Rebuild implication

Treat this section as the input specification for the rebuild, not as a description of enforcement. The vocabulary, the step order and the field sets are the hard-won domain knowledge worth preserving; the storage and the validation both need replacing. Where a field here is free text but the workflow later needs to reason over it — testemunhas, diligências requeridas, intervenientes — that is a place the rebuild should introduce a real structure. See preserve and fix.