{
  "id": "cadastros-pendentes-de-supervisor-e-concedente",
  "title": "Cadastros pendentes de supervisor e concedente",
  "description": "Contrato de dados e análise dos cadastros solicitados durante a abertura de estágio.",
  "type": "domain-contract",
  "status": "planned",
  "visibility": "public",
  "tags": [
    "sge/estagio",
    "sge/cadastro",
    "sge/pendencias"
  ],
  "related": [
    "migration-12a-supervisor-registration-requests",
    "migration-12b-granting-party-registration-requests",
    "backlog-e-decisoes",
    "migration-12-granting-parties",
    "migration-19-internship-requests"
  ],
  "sourceRefs": [
    "https://github.com/sge-suite/sge/blob/master/database/migrations/2026_09_23_162229_create_supervisor_registration_requests_table.php",
    "https://github.com/sge-suite/sge/blob/master/database/migrations/2026_09_23_190320_create_granting_party_registration_requests_table.php",
    "https://github.com/sge-suite/sge/blob/master/database/migrations/2026_09_24_152252_create_internship_requests_table.php",
    "https://github.com/sge-suite/sge/blob/master/app/Models/SupervisorRegistrationRequest.php",
    "https://github.com/sge-suite/sge/blob/master/app/Models/GrantingPartyRegistrationRequest.php",
    "https://github.com/sge-suite/sge/blob/master/app/Models/InternshipRequest.php",
    "https://github.com/sge-suite/sge/blob/master/tests/Feature/SupervisorRegistrationRequestTest.php",
    "https://github.com/sge-suite/sge/blob/master/tests/Feature/GrantingPartyRegistrationRequestTest.php",
    "https://github.com/sge-suite/sge/blob/master/tests/Feature/InternshipRequestTest.php"
  ],
  "authors": [],
  "updated": null,
  "diagram": null,
  "body": "> [!info] Implementação\n> As Migrations 12A (`supervisor_registration_requests`) e 12B (`granting_party_registration_requests`) estão implementadas. O pedido de concedente e a concedente resultante pertencem ao mesmo campus; o vínculo é obrigatório e imutável nos Models, e o uso em solicitações/estágios valida esse escopo. Os fluxos de envio, análise e aprovação continuam planejados.\n\n## Regras comuns\n\n| Campo | Regra |\n| --- | --- |\n| `id` | bigint, chave primária. |\n| `status` | `draft`, `submitted`, `under_review`, `approved`, `rejected` ou `cancelled`; enum existente `RegistrationRequestStatus`. |\n| `reviewed_at` | nullable até a análise; registra o instante da revisão. |\n| `decision_reason` | obrigatório em recusa ou cancelamento; opcional em aprovação. |\n| timestamps | auditoria técnica; alterações e decisões relevantes também entram no `activity_log`. |\n\nEm `draft`, campos de negócio podem ser nulos. Em todos os demais estados, as colunas obrigatórias do respectivo cadastro devem ser válidas. Na Migration 19, a solicitação de estágio identifica o vínculo discente responsável pelo envio. As Migrations 12A e 12B não duplicam FKs de autoria ou revisão nem guardam `submission_snapshot`; quando seus Models forem alterados por Eloquent, o Activity Log registra eventos e o contexto de autoria disponível. As Actions e Policies dos fluxos de análise ainda estão pendentes. Aprovação não cria automaticamente conta ou concedente sem uma ação de análise explícita do Setor.\n\n## `supervisor_registration_requests`\n\n| Campo | Regra |\n| --- | --- |\n| `name` | obrigatório fora de rascunho. |\n| `cpf` | informado pelo discente, válido e normalizado; obrigatório fora de rascunho. |\n| `phone` / `email` | obrigatórios fora de rascunho e normalizados. |\n| `job_role` | obrigatório fora de rascunho. |\n| `qualification` | obrigatório fora de rascunho. |\n| `training` | nullable; formação declarada. |\n| `professional_experience` | texto nullable; experiência profissional declarada. |\n| `supervisor_affiliation_id` | FK nullable para o vínculo criado ou selecionado na aprovação; obrigatório quando `status = approved`. |\n\nEste pedido registra a proposta do discente e a análise do Setor. Os dados profissionais atuais ficam em `user_personal_data`, compartilhados pelos vínculos da mesma conta. Se já houver um vínculo de supervisor selecionável, a solicitação de estágio pode referenciá-lo diretamente e não precisa criar este pedido. Quando houver pendência, o registro mantém os dados profissionais enviados; após aprovação, associa um vínculo de supervisor existente ou criado em transação. No aceite, os dados necessários são copiados para `internships.supervisor_snapshot`.\n\nA Migration 12A guarda o CPF informado pelo discente em coluna própria, validado e normalizado pelo `CpfCast`; `users.cpf` continua único na conta. A associação a uma conta existente ou a criação da conta e do vínculo será feita no futuro fluxo de aprovação. Cargo, qualificação, formação e experiência atuais ficam em `user_personal_data`. O supervisor preenche ou confirma esses dados no futuro formulário, e cada estágio conserva seu próprio snapshot histórico.\n\n## `granting_party_registration_requests`\n\n| Campo | Regra |\n| --- | --- |\n| `campus_id` | FK obrigatória para o campus de origem, com exclusão restrita; não pode ser alterada após a criação. |\n| `document_type` / `document_number` | tipo CPF/CNPJ e número normalizado; obrigatórios fora de rascunho. |\n| `name` | nome ou razão social, obrigatório fora de rascunho. |\n| `street`, `number`, `neighborhood`, `city`, `uf`, `zip_code` | endereço proposto, obrigatório fora de rascunho. |\n| `representative_name` / `representative_role` | obrigatórios fora de rascunho. |\n| `phone` / `email` | nullable e normalizados. |\n| `field_of_activity` | obrigatório fora de rascunho. |\n| `professional_council` / `council_registration_number` | nullable. |\n| `credentialing_process_number` | nullable. |\n| `granting_party_id` | FK nullable para o cadastro criado ou selecionado; obrigatório quando `status = approved`. |\n\nNa aprovação, o Setor cria ou seleciona uma `granting_parties` do mesmo campus de origem do pedido. A regra de campus está validada no Model. Uma concedente nova recebe uma linha própria em `addresses`, mesmo que outro cadastro tenha endereço idêntico; o pedido preserva o endereço proposto em suas colunas. O CNPJ da matriz pode aparecer em registros distintos para filiais ou escolas, e CPF/CNPJ não devem provocar compartilhamento automático entre campi. A solicitação pendente mantém o envio original, a decisão e o vínculo resultante, enquanto a tabela de concedentes guarda somente o cadastro atual. Tanto a concedente quanto a solicitação de concedente persistem `campus_id`, que não pode ser alterado após a criação.\n\n## Integridade e interface\n\n- A solicitação de estágio referencia uma concedente **ou** uma solicitação pendente, e um supervisor **ou** uma solicitação pendente; cada par é exclusivo.\n- O discente pode continuar preenchendo o formulário principal enquanto o cadastro estiver em análise, mas não pode enviar a abertura para aceite até as duas referências exigidas estarem aprovadas.\n- Só o Setor visualiza e decide as solicitações pendentes; elas não são logs expostos ao discente ou ao supervisor.\n- Recusar ou cancelar não apaga o registro. O discente pode escolher um cadastro existente ou criar nova solicitação, preservando o histórico da anterior.\n\n## Referências\n\n- [Backlog e decisões](doc:backlog-e-decisoes#d-011-solicitacoes-pendentes-sao-registros-proprios)\n- [Migration 12 — granting_parties](doc:migration-12-granting-parties)\n- [Migration 19 — internship_requests](doc:migration-19-internship-requests)",
  "sections": [
    {
      "id": "regras-comuns",
      "level": 2,
      "title": "Regras comuns",
      "text": "| Campo | Regra | | --- | --- | | `id` | bigint, chave primária. | | `status` | `draft`, `submitted`, `under_review`, `approved`, `rejected` ou `cancelled`; enum existente `RegistrationRequestStatus`. | | `reviewed_at` | nullable até a análise; registra o instante da revisão. | | `decision_reason` | obrigatório em recusa ou cancelamento; opcional em aprovação. | | timestamps | auditoria técnica; alterações e decisões relevantes também entram no `activity_log`. |  Em `draft`, campos de negócio podem ser nulos. Em todos os demais estados, as colunas obrigatórias do respectivo cadastro devem ser válidas. Na Migration 19, a solicitação de estágio identifica o vínculo discente responsável pelo envio. As Migrations 12A e 12B não duplicam FKs de autoria ou revisão nem guardam `submission_snapshot`; quando seus Models forem alterados por Eloquent, o Activity Log registra eventos e o contexto de autoria disponível. As Actions e Policies dos fluxos de análise ainda estão pendentes. Aprovação não cria automaticamente conta ou concedente sem uma ação de análise explícita do Setor.",
      "line": 4
    },
    {
      "id": "supervisor-registration-requests",
      "level": 2,
      "title": "supervisor_registration_requests",
      "text": "| Campo | Regra | | --- | --- | | `name` | obrigatório fora de rascunho. | | `cpf` | informado pelo discente, válido e normalizado; obrigatório fora de rascunho. | | `phone` / `email` | obrigatórios fora de rascunho e normalizados. | | `job_role` | obrigatório fora de rascunho. | | `qualification` | obrigatório fora de rascunho. | | `training` | nullable; formação declarada. | | `professional_experience` | texto nullable; experiência profissional declarada. | | `supervisor_affiliation_id` | FK nullable para o vínculo criado ou selecionado na aprovação; obrigatório quando `status = approved`. |  Este pedido registra a proposta do discente e a análise do Setor. Os dados profissionais atuais ficam em `user_personal_data`, compartilhados pelos vínculos da mesma conta. Se já houver um vínculo de supervisor selecionável, a solicitação de estágio pode referenciá-lo diretamente e não precisa criar este pedido. Quando houver pendência, o registro mantém os dados profissionais enviados; após aprovação, associa um vínculo de supervisor existente ou criado em transação. No aceite, os dados necessários são copiados para `internships.supervisor_snapshot`.  A Migration 12A guarda o CPF informado pelo discente em coluna própria, validado e normalizado pelo `CpfCast`; `users.cpf` continua único na conta. A associação a uma conta existente ou a criação da conta e do vínculo será feita no futuro fluxo de aprovação. Cargo, qualificação, formação e experiência atuais ficam em `user_personal_data`. O supervisor preenche ou confirma esses dados no futuro formulário, e cada estágio conserva seu próprio snapshot histórico.",
      "line": 16
    },
    {
      "id": "granting-party-registration-requests",
      "level": 2,
      "title": "granting_party_registration_requests",
      "text": "| Campo | Regra | | --- | --- | | `campus_id` | FK obrigatória para o campus de origem, com exclusão restrita; não pode ser alterada após a criação. | | `document_type` / `document_number` | tipo CPF/CNPJ e número normalizado; obrigatórios fora de rascunho. | | `name` | nome ou razão social, obrigatório fora de rascunho. | | `street`, `number`, `neighborhood`, `city`, `uf`, `zip_code` | endereço proposto, obrigatório fora de rascunho. | | `representative_name` / `representative_role` | obrigatórios fora de rascunho. | | `phone` / `email` | nullable e normalizados. | | `field_of_activity` | obrigatório fora de rascunho. | | `professional_council` / `council_registration_number` | nullable. | | `credentialing_process_number` | nullable. | | `granting_party_id` | FK nullable para o cadastro criado ou selecionado; obrigatório quando `status = approved`. |  Na aprovação, o Setor cria ou seleciona uma `granting_parties` do mesmo campus de origem do pedido. A regra de campus está validada no Model. Uma concedente nova recebe uma linha própria em `addresses`, mesmo que outro cadastro tenha endereço idêntico; o pedido preserva o endereço proposto em suas colunas. O CNPJ da matriz pode aparecer em registros distintos para filiais ou escolas, e CPF/CNPJ não devem provocar compartilhamento automático entre campi. A solicitação pendente mantém o envio original, a decisão e o vínculo resultante, enquanto a tabela de concedentes guarda somente o cadastro atual. Tanto a concedente quanto a solicitação de concedente persistem `campus_id`, que não pode ser alterado após a criação.",
      "line": 33
    },
    {
      "id": "integridade-e-interface",
      "level": 2,
      "title": "Integridade e interface",
      "text": "- A solicitação de estágio referencia uma concedente **ou** uma solicitação pendente, e um supervisor **ou** uma solicitação pendente; cada par é exclusivo. - O discente pode continuar preenchendo o formulário principal enquanto o cadastro estiver em análise, mas não pode enviar a abertura para aceite até as duas referências exigidas estarem aprovadas. - Só o Setor visualiza e decide as solicitações pendentes; elas não são logs expostos ao discente ou ao supervisor. - Recusar ou cancelar não apaga o registro. O discente pode escolher um cadastro existente ou criar nova solicitação, preservando o histórico da anterior.",
      "line": 50
    },
    {
      "id": "referencias",
      "level": 2,
      "title": "Referências",
      "text": "- [Backlog e decisões](doc:backlog-e-decisoes#d-011-solicitacoes-pendentes-sao-registros-proprios) - [Migration 12 — granting_parties](doc:migration-12-granting-parties) - [Migration 19 — internship_requests](doc:migration-19-internship-requests)",
      "line": 57
    }
  ],
  "sourcePath": "content/cadastros-pendentes-de-supervisor-e-concedente.md",
  "visuals": [],
  "apiVersion": 1
}