Soluções · Instituições & administração
As secções que a decisão do governo exige, escritas em código e atualizadas pelo funcionário — não adicionadas no fim, como anexo.
Uma câmara municipal ou uma instituição tem uma lista fixa de secções obrigatórias, uma obrigação de transparência decisória e um funcionário que tem de publicar um anúncio sem chamar um programador. Construímos exatamente isso, com registo de auditoria que se apaga sozinho no prazo e com limite às tentativas de autenticação.
Já construídoDuas plataformas próprias, públicas e verificáveis hoje. A primeira é o site oficial de uma câmara municipal: Laravel 12 em PHP 8.2 com MySQL 8, 40 modelos, 32 rotas, 10 migrações, com o conteúdo editorial que muda raramente mantido num único ficheiro de configuração de 1.613 linhas e o que muda frequentemente na base de dados, editável a partir do painel; a autenticação no painel é limitada a 5 pedidos por minuto, e o registo de auditoria é apagado diariamente após 12 meses, com referência explícita à base legal. Os cabeçalhos de segurança podem ser lidos do exterior neste momento. A segunda é uma plataforma cívica em produção, com 65 rotas de interface de programação, mais de 50 migrações, 103 ficheiros de teste no lado do servidor e 59 cenários end-to-end, com verificação de acessibilidade nos testes. O que não colocamos como «entregue»: a interoperabilidade com os serviços do Estado — o código de autenticação federada e de assinatura eletrónica está escrito e testado, mas parado, porque faltam o contrato com a autoridade e o certificado de sistema.
Um site de instituição pública não se julga pela aparência, mas por uma lista. A Decisão do Governo 728/2023 estabelece que secções têm de existir: transparência decisória, projetos e decisões, anúncios, documentos, contactos, orçamento. São obrigatórias, são verificadas e não são negociáveis. Por isso, construímo-las desde o início, como estrutura, e não as adicionamos no final — adicionadas no fim saem formais e inúteis, e isso vê-se imediatamente.
A segunda condição é mais prática: a instituição tem de poder publicar sozinha. Um anúncio de concurso, um projeto de decisão colocado em consulta, uma fotografia de um evento — se tudo passa por um programador, a informação de interesse público fica no papel ou num grupo de rede social, e o site torna-se uma montra morta. Separamos de propósito dois tipos de conteúdo: o editorial que muda raramente — geografia, histórico, instituições, contactos, orçamento — fica num único ficheiro de configuração lido diretamente pelos modelos; o que muda frequentemente fica na base de dados e é editado a partir do painel.
A terceira condição é aquela sobre a qual ninguém pergunta no caderno de encargos: o que acontece aos dados. Um painel de administração pública precisa de um limite às tentativas de autenticação — ao sexto pedido num minuto a partir do mesmo endereço, a resposta é 429, e isso é coberto por um teste automático, não presumido. O diário de auditoria contém endereços IP, portanto é um dado pessoal: uma tarefa programada limpa-o diariamente de tudo o que tem mais de doze meses, com a base legal escrita no comentário do código, não num documento separado que ninguém abre.
E, por fim, a parte sobre a qual preferimos falar antes do concurso: a interoperabilidade com os serviços governamentais. A autenticação federada e a assinatura eletrónica estão escritas e testadas por nós, mas desligadas por um comutador, porque faltam o contrato com a autoridade e o certificado de sistema — falta o papel, não o código. Para a plataforma de pagamentos do Estado, a via de interoperabilidade e o gabinete do cidadão, não temos nenhum código, em nenhum repositório, e escrevemos isso como tal.