{
  "id": "arquitetura-atual",
  "title": "Arquitetura atual",
  "description": "Fotografia da arquitetura, dependências e infraestrutura atualmente presentes na aplicação.",
  "type": "architecture",
  "status": "observed",
  "visibility": "public",
  "tags": [
    "sge/arquitetura",
    "sge/implementacao"
  ],
  "related": [
    "visao-geral",
    "pessoas-e-responsabilidades",
    "fluxos-principais",
    "dominio-e-modelo-de-dados"
  ],
  "sourceRefs": [
    "https://github.com/sge-suite/sge/blob/master/composer.json",
    "https://github.com/sge-suite/sge/blob/master/compose.yaml",
    "https://github.com/sge-suite/sge/blob/master/app/Providers/AppServiceProvider.php",
    "https://github.com/sge-suite/sge/blob/master/app/Providers/FortifyServiceProvider.php",
    "https://github.com/sge-suite/sge/blob/master/app/Models/User.php"
  ],
  "authors": [],
  "updated": null,
  "diagram": "arquitetura-atual-diagrama",
  "body": "## Leitura em linguagem simples\n\nEsta página mostra como o SGE é montado por dentro. Quem usa o sistema não precisa conhecer estas tecnologias para solicitar, acompanhar ou avaliar um estágio. Em termos simples: há uma tela para as pessoas, regras que conferem cada ação, um banco que guarda as informações e serviços que executam tarefas como calcular datas ou preparar documentos.\n\nUse esta página para saber o que já existe e o que ainda está sendo planejado. Para entender o processo de estágio sem detalhes técnicos, comece por [Visão geral](doc:visao-geral), [Pessoas e responsabilidades](doc:pessoas-e-responsabilidades) e [Fluxos principais](doc:fluxos-principais).\n\n## Stack\n\nA implementação atual utiliza:\n\n- Laravel 13.\n- PHP `^8.3 (o ambiente de desenvolvimento atual usa PHP 8.5).\n- Livewire 4 e Flux UI.\n- Tailwind CSS e Vite.\n- PostgreSQL.\n- Laravel Fortify.\n- Spatie Activitylog.\n- Spatie Medialibrary.\n- Laravel Scout e Meilisearch.\n\n## Dependências do domínio\n\n- O `composer.json` atual não declara PhpOffice/PhpWord, usado apenas quando a geração DOCX for implementada;\n- o helper de valores por extenso importa Brick Math, mas o pacote não está declarado diretamente no `composer.json`.\n\n## Organização do código\n\n{{diagram:arquitetura-atual-diagrama}}\n\n## Componentes observados\n\n| Área                    | Situação    | Evidência                                                                            |\n| ----------------------- | ----------- | ------------------------------------------------------------------------------------ |\n| Autenticação            | ✅          | Fortify, páginas Livewire e rotas protegidas                                         |\n| Usuários                | Parcial     | Administração de contas e vínculos de Administrador do Sistema/Campus pela interface; busca, políticas e ciclo de vida implementados. A listagem mostra contas com vínculos administrativos; fluxos de domínio e perfil pessoal seguem parciais. |\n| Autorização             | Parcial     | `UserPolicy`, `AffiliationPolicy` e `CampusPolicy` exigem o vínculo ativo selecionado nos escopos administrativos implementados; políticas e interfaces das jornadas de estágio ainda faltam. |\n| Auditoria               | ✅          | Spatie Activitylog, autoria pelo vínculo ativo e campos pessoais/profissionais auditados                  |\n| Infraestrutura de mídia | Parcial     | Spatie Medialibrary disponível; Models e schema de templates/versões existem, mas upload e geração DOCX seguem pendentes |\n| Estágios                | Parcial     | Models, migrations, validações e auditoria existem; faltam Actions, Policies completas e jornadas da aplicação |\n| Administração de campi   | Parcial     | Páginas Livewire para Administrador do Sistema e backend para operações locais permitidas ao Administrador do Campus; a interface local continua pendente. |\n| Relatórios              | Planejado   | Devem consumir o domínio e respeitar o escopo do vínculo ativo                       |\n\n## Regras de arquitetura\n\n> [!warning] Limite desta nota\n> A arquitetura descrita aqui é a base da aplicação. Para o domínio e os fluxos, consulte [Domínio e modelo de dados](doc:dominio-e-modelo-de-dados) e [Fluxos principais](doc:fluxos-principais).\n\n- Regras de negócio importantes devem ficar em Services, Actions ou objetos de domínio, evitando controllers grandes.\n- Autorização deve ser centralizada em Gates e Policies.\n- A autorização é derivada do vínculo ativo, `AffiliationType`, campus/curso e estado do registro; a decisão fica no código e nos testes.\n- Alterações persistentes devem ser feitas por migrations.\n- Integrações externas devem ser encapsuladas em Services e testadas isoladamente.\n- Cálculos determinísticos ficam em Services puros; autorização, transação e efeitos colaterais ficam em Actions/Policies.\n- Decisões que alterem o domínio devem manter os modelos e fluxos correspondentes sincronizados.",
  "sections": [
    {
      "id": "leitura-em-linguagem-simples",
      "level": 2,
      "title": "Leitura em linguagem simples",
      "text": "Esta página mostra como o SGE é montado por dentro. Quem usa o sistema não precisa conhecer estas tecnologias para solicitar, acompanhar ou avaliar um estágio. Em termos simples: há uma tela para as pessoas, regras que conferem cada ação, um banco que guarda as informações e serviços que executam tarefas como calcular datas ou preparar documentos.  Use esta página para saber o que já existe e o que ainda está sendo planejado. Para entender o processo de estágio sem detalhes técnicos, comece por [Visão geral](doc:visao-geral), [Pessoas e responsabilidades](doc:pessoas-e-responsabilidades) e [Fluxos principais](doc:fluxos-principais).",
      "line": 1
    },
    {
      "id": "stack",
      "level": 2,
      "title": "Stack",
      "text": "A implementação atual utiliza:  - Laravel 13. - PHP `^8.3 (o ambiente de desenvolvimento atual usa PHP 8.5). - Livewire 4 e Flux UI. - Tailwind CSS e Vite. - PostgreSQL. - Laravel Fortify. - Spatie Activitylog. - Spatie Medialibrary. - Laravel Scout e Meilisearch.",
      "line": 7
    },
    {
      "id": "dependencias-do-dominio",
      "level": 2,
      "title": "Dependências do domínio",
      "text": "- O `composer.json` atual não declara PhpOffice/PhpWord, usado apenas quando a geração DOCX for implementada; - o helper de valores por extenso importa Brick Math, mas o pacote não está declarado diretamente no `composer.json`.",
      "line": 21
    },
    {
      "id": "organizacao-do-codigo",
      "level": 2,
      "title": "Organização do código",
      "text": "",
      "line": 26
    },
    {
      "id": "componentes-observados",
      "level": 2,
      "title": "Componentes observados",
      "text": "| Área                    | Situação    | Evidência                                                                            | | ----------------------- | ----------- | ------------------------------------------------------------------------------------ | | Autenticação            | ✅          | Fortify, páginas Livewire e rotas protegidas                                         | | Usuários                | Parcial     | Administração de contas e vínculos de Administrador do Sistema/Campus pela interface; busca, políticas e ciclo de vida implementados. A listagem mostra contas com vínculos administrativos; fluxos de domínio e perfil pessoal seguem parciais. | | Autorização             | Parcial     | `UserPolicy`, `AffiliationPolicy` e `CampusPolicy` exigem o vínculo ativo selecionado nos escopos administrativos implementados; políticas e interfaces das jornadas de estágio ainda faltam. | | Auditoria               | ✅          | Spatie Activitylog, autoria pelo vínculo ativo e campos pessoais/profissionais auditados                  | | Infraestrutura de mídia | Parcial     | Spatie Medialibrary disponível; Models e schema de templates/versões existem, mas upload e geração DOCX seguem pendentes | | Estágios                | Parcial     | Models, migrations, validações e auditoria existem; faltam Actions, Policies completas e jornadas da aplicação | | Administração de campi   | Parcial     | Páginas Livewire para Administrador do Sistema e backend para operações locais permitidas ao Administrador do Campus; a interface local continua pendente. | | Relatórios              | Planejado   | Devem consumir o domínio e respeitar o escopo do vínculo ativo                       |",
      "line": 30
    },
    {
      "id": "regras-de-arquitetura",
      "level": 2,
      "title": "Regras de arquitetura",
      "text": "> [!warning] Limite desta nota > A arquitetura descrita aqui é a base da aplicação. Para o domínio e os fluxos, consulte [Domínio e modelo de dados](doc:dominio-e-modelo-de-dados) e [Fluxos principais](doc:fluxos-principais).  - Regras de negócio importantes devem ficar em Services, Actions ou objetos de domínio, evitando controllers grandes. - Autorização deve ser centralizada em Gates e Policies. - A autorização é derivada do vínculo ativo, `AffiliationType`, campus/curso e estado do registro; a decisão fica no código e nos testes. - Alterações persistentes devem ser feitas por migrations. - Integrações externas devem ser encapsuladas em Services e testadas isoladamente. - Cálculos determinísticos ficam em Services puros; autorização, transação e efeitos colaterais ficam em Actions/Policies. - Decisões que alterem o domínio devem manter os modelos e fluxos correspondentes sincronizados.",
      "line": 43
    }
  ],
  "sourcePath": "content/arquitetura-atual.md",
  "visuals": [
    {
      "id": "arquitetura-atual-diagrama",
      "kind": "architecture",
      "title": "Arquitetura atual da aplicação",
      "description": "Camadas e dependências observadas na aplicação Laravel do SGE.",
      "summary": "Rotas e configurações chegam a Controllers e Livewire, que usam Services, Actions, Models, Gates e Policies; a aplicação persiste no PostgreSQL e entrega a interface por Blade, Flux UI, Vite e Tailwind.",
      "renderMode": "mermaid",
      "api": "api/diagrams/arquitetura-atual-diagrama.json",
      "human": "diagrams/arquitetura-atual-diagrama.html"
    }
  ],
  "apiVersion": 1
}