Contrato assinado, aluno matriculado

O problema

Uma pessoa compra um curso. Assina o contrato e paga. A partir desse fato, alguém precisa transformá-lo em acesso: criar o login do aluno no ambiente virtual e colocá-lo na turma certa. Feito à mão, isso falha de quatro formas silenciosas — e nenhuma delas aparece como erro no sistema:

• a pessoa fica sem acesso e liga para o suporte: a instituição perdeu a primeira impressão e ganhou um chamado;
• a matrícula é feita duas vezes, porque o mesmo aviso chegou de novo ou duas pessoas processaram o mesmo caso;
• a pessoa entra na turma errada, porque o contrato não dizia com clareza para qual curso;
• seis meses depois, ninguém sabe o que aconteceu, quem autorizou, com base em qual documento.

O dia da aula chega, e o problema só existe quando alguém reclama. É esse intervalo — entre o contrato assinado e o aluno matriculado — que este fluxo fecha.

O que o fluxo faz

Liga o provedor de assinatura (ClickSign) ao ambiente virtual de aprendizagem (Moodle). Quando um contrato é concluído, o sistema não confia no aviso sozinho: confere no próprio provedor se o contrato está de fato fechado, e só então cria o usuário e faz a matrícula — uma vez e só uma vez, com registro de por que aquilo aconteceu e com caminho de recuperação quando algo falha.

O padrão não morre no Moodle: o mesmo contrato entre sistemas vale para outros destinos (Canvas, por exemplo) e outros gatilhos (pagamento aprovado, matrícula confirmada). Primeiro se define o contrato de dados entre os sistemas; o conector vem depois.

O que já está provado

Nada aqui é promessa sobre código — é medição, com data e fonte:

• o fluxo completo de execução levou 1m35s e terminou sem erros (código de saída 0) na corrida registrada em 2026-10-22 (um estágio de checagem declara a perna offline por design) — 141 testes unitários, 66 de integração, 6 cenários ponta a ponta sobre Moodle 4.5 real e 83 checagens de conformidade;
• a reprodutibilidade foi confirmada por outra pessoa: três cópias limpas do repositório em 2026-10-22, cada uma com o fluxo completo de execução sem erros (código de saída 0);
• a documentação do provedor de assinatura foi executada, não lida: nas medições de 2026-10-22, os avisos reais conferiram com a máquina 19/19 vezes e com a fórmula publicada pela documentação 0/19 (gatilho de upload, seis corridas); o gatilho de cancelamento somou mais 4 no mesmo dia — 23/23 com a máquina, 0/23 com a fórmula publicada. O catálogo do fluxo seguiu a máquina, e a divergência ficou registrada com data;
• o ambiente de prova é de verdade: Moodle real, ambiente de testes do provedor com envelope criado por script e defeitos históricos plantados de propósito para demonstrar que a checagem automática os detecta antes da entrega.

Como verificamos, em detalhe, está escrito em Onde mora a disciplina. A prova específica deste fluxo viaja junto com o repositório público do laboratório.

Como está disponível hoje

A contratação é de consultoria e desenvolvimento, nos dois formatos:

• customizar este fluxo para a sua operação — as suas tabelas, os seus cursos, as suas regras de matrícula;
• compor este fluxo numa arquitetura maior — matrícula, pagamento, documentos e relatórios fechando o circuito de uma vez.

O fluxo sai pré-construído: o trabalho do projeto é a customização e o encaixe no resto da casa, não a construção do zero. Em ambos os formatos, começa pelo diagnóstico — descreva a dor em uma frase, com o nome dos sistemas envolvidos.

O que ainda não prova

As fronteiras estão declaradas, não escondidas:

• o passo decisivo roda no laboratório, mas com um assinante sintético: um navegador abre o link do e-mail, confirma os dados e finaliza; o envelope fecha sozinho (closed) e os avisos reais de sign, auto_close e document_closed chegam com HMAC conferido. Uma pessoa real, com CPF e e-mail reais, ainda não passou pelo fluxo — é isso que separa o laboratório da operação;
• eventos de recusa e de prazo (refusal, deadline) não foram disparados; o caminho do código de 6 dígitos do componente também não foi exercitado (o link do e-mail já chega autenticado);
• não há integração contínua (CI): o fluxo de execução roda localmente, com data e árvore registradas;
• a recuperação de falha de rede no meio do fluxo ainda é manual, e ainda não é ferramenta;
• o vídeo do fluxo existe como ativo de publicação, mas ainda não foi publicado — quem lê o caso hoje não o assiste sem pedir o arquivo.

Nada nesta página vai ao ar sem que essas linhas sejam as mesmas do README do laboratório — quando uma delas mudar, esta página muda junto.

Notas de método

Números do README de labs/clicksign-moodle-provisioning (Instituto People-T), corrida de 2026-10-22, cada um na árvore que o imprimiu (89 s em 7e81be8; 1m36s com a perna ao vivo em dec7380; 1m35s na árvore pós-review que publica o README atual). As medições do aviso da ClickSign estão em medicoes/aviso-clicksign-2026-10-22.md (19 entregas, seis corridas) e medicoes/aviso-cancelamento-2026-10-22.md (+4, total do dia 23/23); a divergência com a fórmula publicada é o ADR-009 do laboratório. O problema do cliente vem de operação real do passado; o laboratório o reconstruiu como fluxo verificável. Apuração: 2026-10-22.