Diego Volpatto

Diego Volpatto – site acadêmico

Site pessoal estático em português e inglês, construído com SciAstro e Astro, usando o LNCC Theme e conteúdo editável em YAML e BibTeX. O endereço principal é https://www.lncc.br/~volpatto/. O GitHub mantém o código e a integração contínua; a publicação no GitHub Pages está desativada no repositório, com um modelo preservado para reativação futura.

As páginas são definidas em sciastro.yaml e conteudo/paginas/. O SciAstro fornece os componentes, estilos e interações; este repositório mantém a configuração, o conteúdo, os arquivos públicos e os testes do site, além de uma extensão visual para a genealogia acadêmica. O JavaScript local se limita às configurações, à proteção do HTML gerado, à hospedagem Apache, à automação de publicação, à genealogia e aos testes. A geração opcional do currículo usa Python, separadamente do build do site.

Os dados bibliográficos ficam em conteudo/publicacoes.bib; cada card seleciona uma chave e uma categoria em conteudo/paginas/publicacoes.yaml. As orientações usam conteudo/alunos.yaml, com suporte a fotos circulares e símbolos das instituições como alternativa. O build lê esses arquivos localmente, sem consultar DOIs ou serviços externos.

A foto de apresentação usa o recorte circular nativo do SciAstro. Os links entre páginas usam identificadores estáveis, como page:research, que resolvem o idioma e o endereço de publicação. O logo do LNCC também fornece a imagem padrão para compartilhamento de links; essa configuração é independente das fotos dos alunos.

A apresentação combina o LNCC Theme com superfícies neutras, acentos em violeta e um gradiente discreto azul/roxo nos títulos principais. O menu permanece lateral no desktop e recolhível no celular. Ícones de sol/lua indicam a ação do controle de tema; os movimentos sutis respeitam a preferência por movimento reduzido. Essas escolhas ficam em layout e appearance de sciastro.yaml; veja como ajustar a aparência.

O SciAstro é instalado diretamente do npm, com versão fixa em package.json e dependências registradas em pnpm-lock.yaml. O subdiretório /~volpatto/ tem suporte nativo desde o SciAstro 1.1.1. Não é preciso clonar nem compilar o repositório do framework. A documentação do SciAstro descreve os componentes, as opções de configuração e a API disponíveis.

As páginas abrangem apresentação, pesquisa, publicações, software, ensino, orientações, grupos de pesquisa, parcerias e projetos, currículo, curiosidades e contato. A genealogia acadêmica é uma subseção de Curiosidades; licenciamento é acessível pelo rodapé. Inclui experiência profissional, práticas de engenharia de software, resumos de ementas e logos dos grupos e instituições. Os modos claro e escuro respeitam a preferência do sistema na primeira visita; o botão no cabeçalho salva a escolha localmente. As fontes e imagens são servidas pelo próprio site. Não há analytics, formulário, banco de dados nem chamadas ao GitHub durante a navegação.

Guia rápido

Com Git e Pixi instalados:

git clone https://github.com/volpatto/volpatto.github.io.git
cd volpatto.github.io
pixi run --locked dev

Abra http://127.0.0.1:4321/~volpatto/. Edite os arquivos de conteudo/ e salve para ver as alterações. Antes de publicar, execute pixi run --locked verify-all. O resultado pronto para hospedagem fica em dist/.

• Instalar o Pixi e preparar o ambiente
• Editar o conteúdo
• Atualizar o SciAstro
• Gerar o site para domínio próprio ou subdiretório
• Publicar em servidor web
• Atualizar e restaurar uma versão anterior
• Integração contínua no GitHub
• Resolver problemas de ambiente e hospedagem
• Gerar novamente o currículo

Licenciamento

O escopo das licenças distingue textos editoriais autorais sob CC BY 4.0 e código e documentação técnica originais sob MIT. Textos editoriais em YAML ou dentro de arquivos .astro ou .ts continuam sujeitos à licença de conteúdo; isso não torna todas as partes desses arquivos intercambiavelmente MIT ou CC BY.

Logos, foto, figuras científicas, currículo em PDF, fontes e materiais de terceiros estão fora dessas concessões gerais. Os créditos e as condições de cada ativo estão em THIRD_PARTY_NOTICES.md. A figura de Kyas et al. tem sua própria licença CC BY 4.0, com atribuição aos autores originais. Os textos integrais das licenças e avisos distribuídos com o site estão em public/licenses/.

O rodapé de todas as páginas acadêmicas liga para /licenciamento/ ou /en/licensing/, respeitando o subdiretório configurado. Ao adicionar imagens ou documentos, atualize os avisos de direitos e a página de licenciamento.

Ambiente e uso local com Pixi

Requisitos

Na máquina que vai editar ou gerar o site, tenha:

• Git, para obter o repositório e suas atualizações (download e instalação);
• Pixi 0.72.2 ou superior; a integração contínua usa exatamente 0.72.2;
• acesso à internet para baixar as ferramentas e dependências na primeira instalação;
• permissão de escrita na pasta do projeto e no diretório pessoal do usuário.

O projeto fornece Node.js 24 e pnpm 11.19.0 dentro do ambiente Pixi. Não é necessário instalá-los globalmente nem ativar um ambiente manualmente. Pixi prepara as ferramentas; pnpm instala Astro e as bibliotecas do site. Python só é necessário para gerar novamente o PDF do currículo, em um procedimento separado ao final deste documento.

O ambiente está registrado para macOS Apple Silicon, macOS Intel, Linux x86-64 e Windows x86-64. O build foi executado em macOS Apple Silicon; as demais plataformas têm dependências resolvidas no lockfile, sem execução equivalente conferida. Linux ARM e distribuições baseadas em musl, como Alpine, não fazem parte desse ambiente. Essa restrição se aplica à máquina de build; os arquivos estáticos gerados podem ser servidos em outras plataformas.

Instalar o Pixi

Links oficiais:

• Site do Pixi: apresentação da ferramenta e documentação;
• Download do Pixi: versões, instaladores e executáveis; abra Assets na versão desejada;
• Instruções oficiais de instalação: Linux, macOS, Windows e alternativas como Homebrew, Winget e instalação manual.

O passo a passo abaixo já contém os comandos necessários. Os instaladores identificam o sistema e baixam o executável correspondente; não é preciso escolher um arquivo manualmente. Escolha um dos métodos para o seu sistema.

Linux ou macOS, em Bash ou Zsh:

curl -fsSL https://pixi.sh/install.sh | sh

Para instalar especificamente a mesma versão usada no GitHub Actions, use este comando no lugar do anterior:

curl -fsSL https://pixi.sh/install.sh | PIXI_VERSION=v0.72.2 bash

Windows, no PowerShell:

powershell -ExecutionPolicy Bypass -c "irm -useb https://pixi.sh/install.ps1 | iex"

Feche e abra o terminal após a instalação. Confira:

git --version
pixi --version

O instalador coloca o Pixi em ~/.pixi/bin no Linux/macOS e em %USERPROFILE%\.pixi\bin no Windows. Se o terminal não encontrar pixi, verifique se essa pasta está no PATH. Em sessões Bash/Zsh não interativas, como scripts de build, pode ser necessário acrescentá-la explicitamente:

export PATH="$HOME/.pixi/bin:$PATH"

Instale e execute o ambiente como usuário comum. As permissões administrativas do servidor web são independentes da instalação das dependências do projeto.

Obter o projeto e instalar as dependências

git clone https://github.com/volpatto/volpatto.github.io.git
cd volpatto.github.io
pixi install --locked
pixi run --locked setup

Se já tiver o repositório, apenas entre na pasta que contém pixi.toml e package.json; não precisa cloná-lo novamente. pixi install --locked prepara Node.js e pnpm em .pixi/; setup instala as bibliotecas em node_modules/. Os dois diretórios são locais e não devem ser copiados entre máquinas.

Para conferir as ferramentas efetivamente usadas pelo projeto:

pixi run --locked node --version
pixi run --locked pnpm --version

Use sempre pixi run … nos comandos do projeto, mesmo que exista outra instalação de Node.js no sistema. No VS Code, abra a pasta do repositório e use Terminal → Novo terminal.

Editar e visualizar localmente

Na raiz do repositório:

pixi run --locked dev

Abra http://127.0.0.1:4321/~volpatto/ ou o endereço informado pelo terminal, caso a porta esteja ocupada. As alterações salvas nos YAMLs aparecem na prévia. As tarefas também preparam as dependências automaticamente: é possível começar diretamente por dev ou verify, sem executar install e setup separadamente.

Comandos disponíveis

Comando	Resultado
pixi run --locked dev	Prévia com atualização automática ao salvar os arquivos
pixi run --locked verify	Valida conteúdo, gera o site, executa Tests estáticos e inspeciona HTML/SVG/CSS
pixi run --locked build	Gera o site estático em dist/
pixi run --locked build-lncc	Valida e gera o site em dist/ para https://www.lncc.br/~volpatto/
pixi run --locked deploy-lncc	Executa build-lncc, cria um backup e publica automaticamente em ../htdocs/
pixi run --locked preview	Gera o site e serve a versão de publicação localmente
pixi run --locked check-content	Confere os YAMLs e os arquivos referenciados
pixi run --locked check	Valida configuração, conteúdo e arquivos com SciAstro
pixi run --locked test-browser	Gera o site e executa Browser Tests; instale Chromium primeiro
pixi run --locked verify-all	Validação completa, incluindo auditoria de dependências e Browser Tests
pixi run --locked audit-dependencies	Consulta vulnerabilidades conhecidas das dependências, incluindo as de build
pixi run --locked security-build	Gera o site e inspeciona os arquivos conforme a política de segurança
pixi run --locked test-security-browser	Gera o site e testa CSP e comportamentos inesperados no Chromium
pixi run --locked security	Gera o site e executa as três camadas de checks de segurança
pixi run --locked test	Gera o site e executa os testes
pixi run --locked setup	Instala somente as bibliotecas do site
pixi run --locked format	Formata o código, preservando a formatação dos YAMLs editoriais
pixi run --locked dev-stop	Encerra a prévia de desenvolvimento
pixi run --locked preview-stop	Encerra a prévia estática

--locked exige que pixi.toml e pixi.lock estejam consistentes e impede alterar o lockfile durante a execução. A instalação das bibliotecas também usa pnpm install --frozen-lockfile, que aplica a mesma exigência a package.json e pnpm-lock.yaml. Instalações posteriores reutilizam os pacotes disponíveis localmente; atualizar dependências pode exigir novos downloads.

Em um terminal comum, os servidores normalmente permanecem ligados ao terminal; use Ctrl+C para encerrar. Quando o Astro inicia em segundo plano, como pode ocorrer em ferramentas de desenvolvimento automatizadas, fechar o terminal não os encerra. Nesse caso, use as tarefas dev-stop ou preview-stop. Os servidores de desenvolvimento e prévia atendem somente em 127.0.0.1 por padrão.

Mensagem “Another astro dev server is already running”

Essa mensagem significa que já existe uma prévia deste projeto em execução. O Astro mostra seu endereço e PID e encerra a nova tentativa com código 1; isso não indica falha na instalação do Pixi ou das dependências. A prévia existente continua disponível no endereço informado.

Para continuar editando, basta abrir esse endereço. Para reiniciar o servidor, execute, na pasta do projeto:

pixi run --locked dev-stop
pixi run --locked dev

Ao terminar o trabalho, use pixi run --locked dev-stop. Para a prévia do build, os comandos equivalentes são pixi run --locked preview-stop e pixi run --locked preview.

Versões e arquivos do ambiente

• pixi.toml: ferramentas e tarefas disponíveis;
• pixi.lock: versões e arquivos exatos do Node.js, pnpm e bibliotecas do ambiente;
• package.json: dependências e comandos do site;
• pnpm-lock.yaml: versões exatas das dependências do site;
• pnpm-workspace.yaml: política de instalação das dependências;
• .pixi/ e node_modules/: instalações locais, ignoradas pelo Git.

Inclua os dois lockfiles nos commits. Eles permitem reconstruir o ambiente com as mesmas versões das dependências. O GitHub Actions usa esse mesmo ambiente e o comando pixi run --locked verify.

Para atualizar intencionalmente uma ferramenta, edite pixi.toml e execute pixi update, revisando o novo pixi.lock. Ao atualizar pnpm, mantenha a mesma versão em packageManager no package.json. Para atualizar bibliotecas do site, use pnpm dentro do ambiente, por exemplo pixi run pnpm update, revise pnpm-lock.yaml e rode pixi run --locked verify. Essas atualizações são tarefas de manutenção; não fazem parte da publicação habitual de conteúdo.

Os scripts pnpm continuam disponíveis dentro do ambiente (pixi run pnpm … ou pixi shell). Para o uso habitual, prefira as tarefas da tabela.

O site funciona sem JavaScript para leitura, navegação entre páginas, menu móvel e download do CV. As orientações em andamento e concluídas aparecem em seções próprias, com os cards sempre visíveis. O seletor de tema e a adaptação automática do estado do menu usam JavaScript. A mudança de idioma preserva a página atual; a escolha de tema persiste entre páginas. Links antigos como /#teaching são encaminhados à página correspondente quando JavaScript está disponível.

Onde atualizar o conteúdo

Nota mais para eu mesmo, já que JS não é meu forte.

Comece pelo guia de edição em conteudo/README.md. Os textos, links, imagens e listas estão em YAML. As publicações usam BibTeX, e os alunos têm um cadastro compartilhado em alunos.yaml. Para acrescentar um registro, siga os exemplos do guia; não é preciso alterar os componentes nem atualizar contagens nos testes.

Arquivo	O que editar
sciastro.yaml	Identidade, tema, idiomas, menu, rodapé, metadados e imagem de compartilhamento (social)
conteudo/paginas/sobre.yaml	Apresentação, foto, recorte circular (image.shape) e formação resumida
conteudo/paginas/pesquisa.yaml	Linhas de pesquisa, figuras e fontes
conteudo/publicacoes.bib	Autoria, títulos, anos, periódicos e DOIs
conteudo/paginas/publicacoes.yaml	Chaves BibTeX, categorias e ordem das publicações
conteudo/paginas/software.yaml	Softwares, práticas, documentação e pacotes
conteudo/paginas/ensino.yaml	Disciplinas e materiais
conteudo/alunos.yaml	Alunos, temas, situação, nível, fotos e símbolos institucionais
conteudo/paginas/orientacoes.yaml	Introdução e composição da página de orientações
conteudo/paginas/grupos.yaml	Grupos de pesquisa
conteudo/paginas/parcerias.yaml	Parcerias acadêmicas, projetos e indústria
conteudo/paginas/curriculo.yaml	Experiência, formação e download do CV
conteudo/paginas/contato.yaml	Sala e endereço
conteudo/paginas/licenciamento.yaml	Créditos e condições dos materiais
public/images/	Imagens, logos e bandeiras
public/files/cv-diego-volpatto-2026.pdf	PDF do currículo já revisado
cv/	Configuração para gerar novamente o PDF

Os campos traduzidos têm pt e en. Não há importação automática do Lattes; as atualizações continuam editoriais e devem ser conferidas antes de publicar. O guia inclui exemplos de parágrafos, links, publicações e alunos.

Para ligar páginas nos textos e campos links, use o id da página de destino: [Pesquisa](page:research) ou url: page:research#sciml. O mesmo destino serve para os dois idiomas, e o build confere a página e a âncora. No rodapé e nos caminhos de imagens e arquivos, mantenha os endereços explícitos começando por /. Veja textos e links.

O retrato circular é configurado em conteudo/paginas/sobre.yaml, sem CSS adicional. Em sciastro.yaml, social.fallback: logo reutiliza o PNG completo do LNCC, sem aplicar o recorte do cabeçalho. Para escolher outra imagem de compartilhamento, configure social.image com um PNG/JPEG em public/; veja os exemplos de foto de apresentação e compartilhamento. As prévias em aplicativos dependem da publicação e do cache de cada serviço.

As legendas de figuras e tabelas ficam centralizadas pela configuração appearance.captions de sciastro.yaml. Para alterar o padrão ou alinhar apenas uma legenda, veja imagens e créditos; não é necessário acrescentar CSS.

Para mudanças de estrutura, edite sections nos YAMLs. Para cores, fontes, largura e legendas, use appearance em sciastro.yaml. O LNCC Theme, os componentes e os comportamentos de navegação pertencem ao pacote SciAstro. Veja o mapa do repositório.

Ícones e bandeiras são locais. Os desenhos acompanham rótulos textuais e são decorativos para leitores de tela. As bandeiras do Brasil e do Reino Unido acompanham PT e EN; os nomes acessíveis são Português e English. Os créditos continuam na página de licenciamento e em THIRD_PARTY_NOTICES.md.

Estrutura do repositório

Este repositório contém o conteúdo e a configuração do site. O SciAstro fornece as páginas, os componentes, o LNCC Theme, a navegação e a validação dos YAMLs. O único componente local, em src/components/, apresenta a genealogia acadêmica. As edições de nomes, relações, fontes e traduções continuam em YAML.

Caminho	Responsabilidade
sciastro.yaml	Identidade, tema, idiomas, menu, rodapé e destino de publicação
conteudo/	Textos e composição das páginas; inclui o guia de edição
styles/site.css	Fundo dos símbolos institucionais e alinhamento do rodapé
conteudo/genealogia.yaml	Pessoas, relações e fontes da genealogia; distâncias calculadas automaticamente
src/components/AcademicGenealogy.astro e styles/genealogy.css	Diagrama resumido, visualizador e lista acessível de relações
build/genealogy.mjs	Valida o grafo e gera os diagramas SVG e dados JSON em PT/EN
public/	Imagens, currículo e licenças distribuídos com o site
astro.config.mjs	Ativa o SciAstro; normalmente não precisa ser editado
build/security.mjs	Completa e posiciona a política de segurança no HTML gerado
build/apache.mjs	Gera .htaccess com UTF-8, tipos MIME, índice e erro 404 para o destino do build
build/site-verification.mjs	Inclui a tag do Google Search Console no HTML da página inicial
security-policy.yaml	Origens adicionais permitidas e regras da auditoria de dependências
scripts/	Checks de dependências e dos arquivos gerados, com relatórios em JSON
scripts/deploy-lncc.mjs	Confere o destino LNCC, cria um backup e sincroniza dist/ com ../htdocs/
cv/	Script e configurações para gerar novamente o currículo
tests/ e playwright.config.mjs	Tests do conteúdo publicado e da navegação
.github/workflows/pages.yml	CI com build para o LNCC, testes e auditorias; sem publicação
deployment/github-pages.yml	Modelo inativo para reativar a publicação manual no GitHub Pages
package.json, pnpm-workspace.yaml e pnpm-lock.yaml	Dependências do site e política de instalação
pixi.toml e pixi.lock	Ferramentas e tarefas reproduzíveis

Os testes próprios continuam úteis para conferir o conteúdo publicado, os links, o currículo, as imagens e os idiomas deste site. O compilador TypeScript e os testes dos componentes ficam no desenvolvimento do SciAstro. A prévia dos Browser Tests usa o servidor oficial do Astro, sem um servidor HTTP próprio no repositório. A verificação automática não confirma afirmações científicas nem links externos. Os testes da genealogia verificam os caminhos, as distâncias, a distinção entre ascendência e ramos colaterais e a correspondência entre dados e downloads.

A seção Curiosidades, antes de Contato, contém a genealogia acadêmica. O guia de edição explica seus campos e ressalvas históricas. Graphviz, por meio de @viz-js/viz, gera os SVGs durante o build; não é carregado no navegador. Os downloads em public/files/genealogy/ são regenerados do YAML e ignorados pelo Git.

As pastas dist/, .astro/, .test-output/ e .cv-build/ são saídas locais, ignoradas pelo Git. Podem ser removidas quando seus processos estiverem parados; serão recriadas pelo build, pelos testes ou pela geração do currículo. Guarde à parte relatórios de conversão do CV que queira conservar. .pixi/ e node_modules/ são o ambiente de trabalho: removê-las exige instalar as dependências novamente.

Atualizar o SciAstro

O site usa o pacote publicado no npm. A versão instalada aparece no campo dependencies.sciastro de package.json; ela é fixa, sem ^ ou ~. Instalações e builds usam o lockfile e não adotam novas releases automaticamente. Editar textos, imagens ou o currículo não exige atualizar o framework.

O SciAstro 1.1.1 aceita nativamente ~ no caminho base, usado pelo LNCC em /~volpatto/, nas validações de configuração e de downloads. O site usa essa implementação sem patches locais. A configuração do Apache e das fontes continua em build/apache.mjs e astro.config.mjs, conforme a hospedagem do LNCC. Não edite node_modules/ manualmente: essas alterações se perderiam na próxima instalação.

Para atualizar intencionalmente:

1. Leia as notas da release e escolha uma versão publicada no npm; confira eventuais instruções de migração.

2. Na pasta deste site, substitua VERSAO pelo número escolhido e execute:

   pixi run --locked pnpm add sciastro@VERSAO --save-exact
   pixi run --locked browser-install
   pixi run --locked verify-all
   

   browser-install prepara o Chromium para os testes. Pode ser omitido quando a versão de navegador exigida pelo Playwright já estiver instalada.

   Se o pnpm bloquear uma release recém-publicada com ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION, aguarde a janela indicada ou, após conferir essa release, acrescente apenas sciastro@VERSAO à lista minimumReleaseAgeExclude em pnpm-workspace.yaml. Mantenha a exceção da versão anterior até concluir a atualização: o pnpm também verifica o lockfile existente. Depois, remova a exceção antiga e rode pixi run --locked setup.

3. Execute pixi run --locked preview e confira as páginas em português e inglês, os temas claro/escuro e a apresentação em uma tela pequena.
4. Execute também pixi run --locked build-lncc para conferir o suporte ao subdiretório Apache. Revise e registre package.json, pnpm-lock.yaml e pnpm-workspace.yaml juntos. Envie um PR para main; o CI executa os testes, e a publicação no LNCC é feita com pixi run --locked deploy-lncc.

Não é necessário copiar arquivos .tgz, manter uma pasta vendor/ ou gerar uma release do site no npm. O projeto do site é privado para fins de publicação de pacotes (private: true); seu resultado é o conteúdo estático de dist/. Uma release do SciAstro só chega a este site quando sua dependência é atualizada.

GitHub Actions e GitHub Pages

O workflow pages.yml permanece ativo em pushes para main, pull requests e execuções manuais. Ele usa Pixi, valida o conteúdo, gera o build para https://www.lncc.br/~volpatto/, executa testes estáticos e de navegador, audita dependências e inspeciona os arquivos gerados. Os relatórios continuam disponíveis no artefato website-tests-and-security.

Esse workflow não configura nem publica no Pages, não envia artefatos de publicação e não recebe permissões de Pages. Ele também não publica no LNCC: essa etapa continua sendo pixi run --locked deploy-lncc, na máquina que contém ../htdocs/. A badge abaixo do título acompanha o CI na branch main. O job Build and Tests foi preservado para manter as regras de proteção da branch.

O modelo de publicação manual foi preservado em deployment/github-pages.yml, fora de .github/workflows/. Ele está inativo e disponível para uma eventual reativação.

Gerar o site para publicação

Definir o endereço público

O endereço final é configurado antes do build, pelas variáveis abaixo. Todos os domínios example.org desta seção são exemplos a substituir pelo endereço público real.

Variável	Significado	Padrão do projeto
SITE_URL	Protocolo e domínio público, sem o subdiretório	https://www.lncc.br
BASE_PATH	Caminho público, começando e terminando em /	/~volpatto/

Sem variáveis de ambiente, build, verify, dev e preview usam esses padrões LNCC definidos em sciastro.yaml. Para a publicação habitual, use pixi run --locked deploy-lncc; os exemplos abaixo são para outros destinos.

Para https://pesquisa.example.org/, em Bash/Zsh:

export SITE_URL="https://pesquisa.example.org"
export BASE_PATH="/"
pixi run --locked verify

Para https://www.example.org/pesquisadores/diego/, em Bash/Zsh:

export SITE_URL="https://www.example.org"
export BASE_PATH="/pesquisadores/diego/"
pixi run --locked verify

No PowerShell, o segundo exemplo é:

$env:SITE_URL = "https://www.example.org"
$env:BASE_PATH = "/pesquisadores/diego/"
pixi run --locked verify

Defina as duas variáveis na mesma sessão em que executa o comando. Em um serviço de integração contínua, configure-as no ambiente da etapa de build. Este projeto lê essas opções de process.env pela integração SciAstro; colocar os valores apenas em um arquivo .env não substitui essas instruções.

verify instala as dependências, valida o conteúdo, gera o site e confere os testes, links internos e regras de segurança dos arquivos gerados. Para incluir a consulta de vulnerabilidades e os testes de navegador, instale Chromium com pixi run --locked browser-install e execute pixi run --locked verify-all. Publique somente depois dessa validação completa, com código de saída zero. Os testes locais não conferem a configuração do servidor de destino nem a disponibilidade de links externos.

Conferir o resultado

dist/ contém tudo o que precisa ser publicado:

dist/
  .htaccess                  Configuração Apache: UTF-8, tipos MIME, índice e erro 404
  index.html                 Página inicial em português
  pesquisa/index.html        Exemplo de página interna
  en/index.html              Página inicial em inglês
  en/research/index.html     Exemplo de página interna em inglês
  404.html                   Página de endereço inexistente
  _astro/                    CSS, JavaScript e fontes compilados
  images/                    Foto, logos, bandeiras e figuras
  files/                     Currículo em PDF
  licenses/                  Licenças e avisos distribuídos com o site
  ...                        Demais páginas e arquivos públicos

Para abrir essa versão localmente, mantenha as mesmas variáveis e execute:

pixi run --locked preview

A tarefa gera dist/ novamente antes de iniciar a prévia. Abra o endereço informado no terminal, incluindo /~volpatto/ no padrão LNCC ou o subdiretório que tiver escolhido. Confira a navegação nos dois idiomas, tema claro/escuro, imagens e download do currículo. Para encerrar, use pixi run --locked preview-stop.

Os caminhos dos arquivos em dist/ são os mesmos com qualquer BASE_PATH. O que muda são os URLs gravados no HTML, CSS e scripts. Não é criada uma pasta dist/pesquisadores/diego/: o servidor deve disponibilizar o conteúdo de dist/ nesse caminho público.

Ao mudar de domínio ou subdiretório, gere e publique novamente o site inteiro. Copiar um build antigo para outro endereço não atualiza seus links e metadados. Para voltar aos padrões LNCC em Bash/Zsh, use unset SITE_URL BASE_PATH; no PowerShell, abra uma nova sessão. Também é possível mudar os valores padrão nos campos url e base de sciastro.yaml para tornar permanente o novo destino.

Publicar em servidor web

O projeto usa output: "static": o build produz HTML, CSS, JavaScript e arquivos públicos, conforme o modelo de publicação do Astro. O ambiente de publicação precisa apenas de um servidor de arquivos estáticos, como Nginx ou Apache, com o domínio e o HTTPS configurados.

Etapa	O que precisa estar instalado
Editar, validar e gerar o site	Git, Pixi e as dependências instaladas pelas tarefas
Servir o site já gerado	Servidor web com suporte a arquivos estáticos
Gerar um novo PDF do currículo	Ambiente Python separado, descrito ao final

Node.js, pnpm, Pixi e Python não são necessários no servidor que apenas recebe dist/. Não é preciso manter um processo Astro, serviço de aplicação, container ou banco de dados em execução. dev e preview são ferramentas de conferência local; a publicação usa o servidor web.

Publicar no LNCC em ../htdocs

Na máquina do LNCC, com rsync instalado e este repositório ao lado de htdocs, execute na raiz do repositório:

pixi run --locked deploy-lncc

Essa tarefa executa todo o processo:

1. Executa build-lncc: define SITE_URL=https://www.lncc.br e BASE_PATH=/~volpatto/, valida o conteúdo, gera dist/ e executa os testes estáticos e a inspeção de segurança.
2. Confere o diretório de publicação, a URL canônica e a configuração Apache do build, incluindo UTF-8 e a página 404.
3. Copia o conteúdo atual de ../htdocs/ para um backup irmão com nome único, no formato ../htdocs.backup-DATA-HORA-SUFIXO/.
4. Sincroniza o conteúdo completo de dist/, incluindo .htaccess, para ../htdocs/, remove arquivos obsoletos e aplica permissões 755 aos diretórios e 644 aos arquivos.

O destino ../htdocs precisa existir como um diretório real e conter exclusivamente o site. Os caminhos são resolvidos a partir do repositório. A publicação só começa após o build, as verificações e o backup terminarem sem erros. O terminal informa o caminho do backup; se a sincronização falhar, use essa cópia para recuperar a versão anterior. Os backups ficam fora da pasta pública e não são removidos automaticamente; remova os antigos quando não precisar mais deles.

O rsync usa --delay-updates para transferir arquivos temporariamente antes de substituí-los e --delete-delay para remover arquivos antigos ao final da transferência. Isso evita servir arquivos parcialmente escritos, mas a troca do site inteiro não é atômica.

Para gerar e validar apenas dist/, sem publicar nem criar backup, execute pixi run --locked build-lncc. Você pode então transferir seu conteúdo manualmente, preservando os arquivos ocultos: não use dist/*, pois esse padrão omite .htaccess. Os valores padrão de sciastro.yaml também apontam para o LNCC; as tarefas específicas garantem esse destino mesmo se houver variáveis de ambiente definidas para outra hospedagem.

Abra a página do LNCC, uma página interna e a versão em inglês. Confira também os cabeçalhos e a resposta para uma página inexistente:

curl -I https://www.lncc.br/~volpatto/
curl -I https://www.lncc.br/~volpatto/pesquisa/
curl -I https://www.lncc.br/~volpatto/en/research/
curl -I https://www.lncc.br/~volpatto/pagina-inexistente/

O HTML deve informar Content-Type: text/html; charset=UTF-8. As três primeiras respostas devem ter status 200; a última deve ter status 404 e exibir a página de erro do site. Ao regenerar para o LNCC, use deploy-lncc para publicar ou build-lncc para apenas preparar os arquivos.

Transferir os arquivos

Copie o conteúdo de dist/, preservando todos os arquivos e subdiretórios, para uma pasta exclusiva desta versão do site. A página inicial deve ficar diretamente na raiz pública configurada, e não em uma pasta extra chamada dist.

Para transportar o build como um único arquivo, em Linux/macOS:

COPYFILE_DISABLE=1 tar -czf ../site-publicacao.tar.gz -C dist .
tar -tzf ../site-publicacao.tar.gz

COPYFILE_DISABLE=1 evita incluir arquivos auxiliares de metadados do macOS; o mesmo comando também funciona no Linux. O pacote é salvo fora do repositório. Antes de reutilizar esse nome em uma atualização, guarde o pacote anterior com um nome que identifique sua versão. Transfira o pacote por SSH/SFTP ou pelo mecanismo disponível na hospedagem. No servidor, um exemplo de extração é:

mkdir -p /srv/www/diego/releases/2026-09-20-01
tar -xzf /caminho/recebido/site-publicacao.tar.gz -C /srv/www/diego/releases/2026-09-20-01

Substitua os caminhos e o identificador 2026-09-20-01 pelos da instalação. A pasta da versão deve estar vazia antes da extração. O usuário responsável pela publicação precisa poder gravar nela; o usuário do servidor web precisa poder ler os arquivos e acessar os diretórios.

Publique somente o resultado do build. O repositório, node_modules/, .pixi/, arquivos de configuração e exportações XML do Lattes ficam fora da raiz pública. O pacote de transferência também fica fora dela.

Configurar os caminhos e a página 404

O servidor deve resolver diretórios para index.html. Exemplos:

URL público	Arquivo dentro da pasta publicada
/~volpatto/	index.html
/~volpatto/pesquisa/	pesquisa/index.html
/~volpatto/en/research/	en/research/index.html
/~volpatto/files/cv-diego-volpatto-2026.pdf	files/cv-diego-volpatto-2026.pdf

Com BASE_PATH=/pesquisadores/diego/, substitua /~volpatto/ nos URLs da tabela. Por exemplo, /pesquisadores/diego/pesquisa/ deve resolver para o mesmo arquivo pesquisa/index.html da versão publicada.

Sirva arquivos inexistentes com status HTTP 404, usando 404.html como corpo da resposta. Não redirecione todos os caminhos desconhecidos para a página inicial: cada página deste site já possui seu próprio HTML. Preserve também os tipos MIME usuais de CSS, JavaScript, SVG, fontes WOFF2 e PDF.

Exemplo com Nginx

Para um domínio dedicado, este trecho fica dentro do bloco server existente, cujo domínio, certificado e HTTPS já devem estar configurados:

root /srv/www/diego/current;
index index.html;

location / {
    try_files $uri $uri/ =404;
}

error_page 404 /404.html;

Nesse exemplo, current é um link simbólico para a pasta da versão publicada. A criação e a troca desse link estão descritas em Atualizar e restaurar uma versão anterior. A configuração http do Nginx deve carregar o arquivo mime.types fornecido pela instalação. Confira a referência de root, try_files e tipos MIME.

Para um subdiretório em um domínio compartilhado, uma alternativa é fazer /srv/www/pesquisadores/diego apontar para a pasta da versão e acrescentar somente este bloco ao server do domínio:

location = /pesquisadores/diego {
    return 301 /pesquisadores/diego/;
}

location /pesquisadores/diego/ {
    root /srv/www;
    index index.html;
    try_files $uri $uri/ =404;
    error_page 404 /pesquisadores/diego/404.html;
}

Aqui o root é /srv/www, pois o Nginx acrescenta a URI completa ao caminho. Assim, /pesquisadores/diego/pesquisa/ corresponde a /srv/www/pesquisadores/diego/pesquisa/index.html. Preserve as configurações dos outros sites do mesmo domínio. Antes de recarregar o serviço, valide a configuração com nginx -t, usando as permissões adequadas à instalação.

Configuração Apache incluída no build

build/apache.mjs gera .htaccess automaticamente em dist/, usando o BASE_PATH do build para o caminho da página 404. O arquivo configura index.html como índice, UTF-8 para os textos e tipos MIME dos recursos estáticos. Copie esse arquivo junto com as páginas. Em outras hospedagens, como GitHub Pages ou Nginx, ele não é interpretado.

O Apache do LNCC enviava charset=ISO-8859-1 para HTML em UTF-8. O cabeçalho HTTP prevalece sobre a tag de charset no HTML; por isso, acrescentar outra tag não corrige a exibição. A diretiva AddDefaultCharset UTF-8 e as associações de charset no .htaccess corrigem a configuração do diretório. O servidor precisa permitir essas diretivas em .htaccess por meio de AllowOverride. Se o arquivo for ignorado ou causar erro 500, a configuração correspondente precisa ser revista pela administração da hospedagem.

Não há regras de reescrita para a página inicial: cada URL possui seu próprio HTML. O ErrorDocument mantém o status 404 para endereços inexistentes. Não é necessário proxy para uma porta Node.js. A prévia do Astro não interpreta .htaccess; os cabeçalhos e a página de erro precisam ser conferidos no Apache.

Conferir após a publicação

Abra a página inicial, uma página interna diretamente pelo URL, a versão em inglês e o currículo. Confirme que imagens, fontes, estilos e scripts carregam do domínio e subdiretório escolhidos. Uma URL inexistente deve exibir a página de erro mantendo o status 404.

Exemplo de conferência dos status, para publicação na raiz:

curl -I https://pesquisa.example.org/
curl -I https://pesquisa.example.org/pesquisa/
curl -I https://pesquisa.example.org/en/research/
curl -I https://pesquisa.example.org/files/cv-diego-volpatto-2026.pdf
curl -I https://pesquisa.example.org/pagina-inexistente/

Os quatro primeiros devem terminar em HTTP 200; o último, em HTTP 404. Se a hospedagem estiver em subdiretório, inclua-o em cada URL.

Política de segurança e avisos do navegador

O site inclui a tag google-site-verification no <head> da página inicial gerada. Os códigos ficam em astro.config.mjs, na chamada googleSiteVerification, associados ao endereço público completo. O build seleciona o código do LNCC ou do GitHub Pages conforme SITE_URL e BASE_PATH; outros destinos não recebem tag.

No Search Console, adicione uma propriedade do tipo Prefixo do URL com o endereço exato https://www.lncc.br/~volpatto/ e escolha Tag HTML. Publique com pixi run --locked deploy-lncc, volte ao Search Console e clique em Verificar. O código anterior do GitHub Pages permanece na configuração para uma eventual reativação; somente um build com o endereço GitHub o inclui. Mantenha a tag após a confirmação, pois o Google verifica sua presença novamente. Consulte as instruções oficiais de verificação por tag HTML. Essa tag não altera a aparência nem instala Google Analytics; a medição de visitas exige uma configuração separada.

O build inclui uma Content Security Policy (CSP) em todas as páginas, inclusive na página 404. A configuração está em astro.config.mjs. A política permite recursos do próprio site e os scripts inline autorizados por hashes; bloqueia scripts de terceiros, atributos HTML de eventos, formulários, frames, objetos, workers e conexões em segundo plano. Links normais para artigos, parceiros e outros sites continuam funcionando.

build/security.mjs completa os hashes dos scripts e estilos inline do SciAstro e posiciona a política antes dos recursos da página. Os hashes são calculados automaticamente a cada build, sem mudanças no conteúdo ou na aparência. Esse ajuste é necessário porque a CSP nativa do Astro não cobre todos os blocos inline do layout atual. A proteção usa uma meta no HTML e funciona também no GitHub Pages, sem configurar cabeçalhos no servidor. Ela considera a saída do build confiável: não é um antivírus nem uma verificação das dependências.

Atributos de estilo continuam permitidos para o posicionamento das figuras. O build publica as fontes como arquivos locais separados, com vite.build.assetsInlineLimit: 0. A CSP HTTP do LNCC permite fontes do próprio domínio, mas bloqueia fontes incorporadas em URLs data:. As políticas do cabeçalho e da meta são aplicadas em conjunto: a permissão na meta não remove a restrição do cabeçalho. Servir as fontes por URLs locais permite manter a política da hospedagem.

Se adicionar analytics, vídeos incorporados ou recursos carregados de outro domínio, revise as diretivas correspondentes e os testes; não libere origens indiscriminadamente. A política é aplicada ao build de produção. Para conferir seu comportamento, execute pixi run --locked verify-all ou use a prévia do build; dev não é uma verificação da CSP de produção.

Um aviso vermelho de “site perigoso” é uma avaliação independente do navegador; adicionar CSP não remove essa classificação automaticamente. Se aparecer:

1. Consulte o relatório público do Safe Browsing.
2. No Google Search Console, selecione a propriedade do site e abra Segurança e ações manuais → Problemas de segurança. Esse relatório pode mostrar a descrição do problema e exemplos de URLs, mesmo quando o aviso não é reproduzido em outro navegador.
3. Investigue os exemplos e compare o HTML e os recursos publicados com um build local do commit implantado. Corrija o que o relatório identificar e, após validar, solicite uma revisão pelo próprio relatório. Consulte as instruções do Google.
4. Se a investigação indicar uma classificação incorreta, use o formulário oficial de falso positivo, informando a URL exata e os resultados verificados.

Não desative a Navegação segura para resolver o aviso. Os testes locais validam a proteção do site; não consultam nem garantem a classificação do Google.

Checks automatizados de segurança

Para executar a validação completa, na raiz do repositório:

pixi run --locked browser-install
pixi run --locked verify-all

Para executar somente as três camadas de segurança, use pixi run --locked security. As tarefas geram o build antes de inspecioná-lo. Nenhuma delas publica o site, aplica correções automáticas às dependências ou altera o conteúdo. O CI executa as mesmas verificações em PRs e pushes para main, independentemente de qualquer publicação. No modelo opcional do GitHub Pages, uma falha também impede o job de publicação. Para impedir o merge com falhas, configure Build and Tests como check obrigatório nas regras da branch no GitHub.

Camada	Ferramentas e critérios	Relatório
Dependências	pnpm audit --json, incluindo dependências diretas, transitivas e de desenvolvimento/build; bloqueia vulnerabilidades high e critical sem exceção revisada	.test-output/security/dependencies.json
Arquivos gerados	Node.js, htmlparser2, CSS Tree e parser de srcset; inspeciona todos os HTML, SVG e CSS do build	.test-output/security/build.json
Navegador	Playwright/Chromium em desktop e celular; observa requisições, navegações, pop-ups, downloads, workers e WebSockets	.test-output/report/index.html, com registros JSON anexados aos testes

A auditoria de dependências precisa de internet e envia ao registro npm nomes e versões dos pacotes para consultar os avisos conhecidos. Falhas de conexão, respostas incompletas ou inválidas são erros da auditoria, não um resultado sem vulnerabilidades. Os scripts de auditoria e inspeção retornam 0 quando as regras passam, 1 quando há achados que bloqueiam e 2 quando não conseguem concluir a verificação. Avisos de menor gravidade também ficam no relatório. Consulte a documentação do pnpm audit.

A inspeção dos arquivos verifica origens de recursos carregados automaticamente, referências em CSS e srcset, recursos locais ausentes, SVGs com elementos ativos, atributos de eventos, esquemas de URL inseguros, formulários, incorporações e redirecionamentos por meta refresh. Downloads explícitos são limitados a PDFs locais, como o currículo. Links normais para artigos e parceiros são inventariados separadamente e não precisam de uma lista de domínios permitidos. A inspeção não acessa esses sites nem usa seu status HTTP como diagnóstico de segurança.

As regras editáveis ficam em security-policy.yaml. resources.allowedOrigins começa vazio: recursos do domínio do próprio site já são permitidos. Se um novo recurso externo for necessário, revise-o antes de adicionar a origem HTTPS exata, sem caminho ou curinga. Essa lista não muda a CSP: a política em astro.config.mjs também precisa ser revisada, e os Browser Tests devem passar. Não adicione um domínio só para silenciar um teste que falhou.

Para uma vulnerabilidade, prefira atualizar a dependência afetada e testar o site novamente. Uma exceção deve ser rara, temporária e fundamentada. O formato é:

dependencies:
  failOn: [high, critical]
  exceptions:
    - id: GHSA-xxxx-xxxx-xxxx # Substitua pelo identificador real do relatório.
      reason: "Descreva a análise que justifica a exceção e a correção planejada."
      expires: "YYYY-MM-DD" # Substitua por uma data real de vencimento em UTC.

Esse exemplo é ilustrativo; a configuração inicial não tem exceções. Exceções vencidas ou inválidas fazem o check falhar. Mantenha as exceções apenas nesse arquivo, sem filtros audit.ignore ou equivalentes no pnpm, para que o relatório preserve os avisos encontrados. Não use --ignore-registry-errors para aprovar uma auditoria que não conseguiu consultar o registro.

Os testes incluem exemplos simulados que devem ser detectados: a própria verificação também é testada. No navegador, tentativas externas inesperadas são bloqueadas pelo observador dos testes; isso não adiciona um bloqueador novo ao site publicado. A proteção do visitante continua sendo a CSP. O download intencional do currículo é exercitado e permitido.

Esses controles não detectam toda forma de código malicioso: a auditoria cobre avisos conhecidos, a inspeção verifica regras estruturais e os testes de navegador cobrem o carregamento e as ações exercitadas. Código permitido da própria origem e comportamentos não exercitados continuam exigindo revisão. Não há comparação automática com a versão publicada nem consulta à classificação do Google nesta etapa. Os relatórios ficam disponíveis no artefato website-tests-and-security do GitHub Actions, inclusive quando um check falha.

Atualizar e restaurar uma versão anterior

Para atualizar o site em servidor próprio:

1. Na cópia de trabalho, revise as alterações locais com git status. Com a cópia sem alterações pendentes, obtenha a nova versão com git pull --ff-only.
2. Defina SITE_URL e BASE_PATH para o destino e execute pixi run --locked verify-all. Os mesmos comandos servem para mudanças de texto, imagens e código.
3. Registre a revisão (git rev-parse HEAD) e os dois valores de configuração junto ao pacote de publicação. Gere o pacote a partir de uma revisão salva no Git, para que esse registro identifique todo o conteúdo publicado.
4. Transfira o novo build para uma nova pasta de versão, mantendo a anterior. Aponte a raiz pública ou o link simbólico para a nova pasta depois da cópia completa. Isso evita misturar arquivos de duas compilações.
5. Confira os URLs e os arquivos públicos conforme a seção anterior. Se houver cache intermediário, atualize-o para que o HTML e os arquivos substituídos, como o PDF e as imagens, correspondam à versão publicada.

No exemplo de domínio dedicado, criar ou trocar o link simbólico pode ser feito em Linux, no servidor, com:

ln -sfn /srv/www/diego/releases/2026-09-20-01 /srv/www/diego/current

Use esse comando somente quando current estiver ausente ou já for um link simbólico; uma instalação que use diretório real deve ajustar o caminho no servidor web. Para o exemplo em subdiretório, o link público equivalente é /srv/www/pesquisadores/diego.

Para restaurar a versão anterior, aponte o link ou a raiz pública de volta para a pasta anterior e confira o site. Não é necessário reconstruir o ambiente. O build restaurado precisa ter sido gerado para o mesmo domínio e BASE_PATH. Se houver alteração na configuração do servidor, valide-a e recarregue o serviço; trocar apenas o destino do link normalmente dispensa essa recarga.

Problemas frequentes

Sintoma	O que verificar
pixi: command not found	Reabra o terminal e confira o diretório de instalação no PATH.
Versão errada de Node.js ou pnpm	Execute as tarefas por pixi run --locked …, dentro do repositório.
Pixi informa lockfile desatualizado	Confira se pixi.toml e pixi.lock vieram da mesma revisão. Gere um novo lockfile somente ao atualizar intencionalmente o ambiente.
pnpm informa lockfile desatualizado	Confira package.json e pnpm-lock.yaml. Em uma alteração intencional de dependências, rode pixi run pnpm install, revise e salve o lockfile atualizado.
Falha ao baixar pacotes	Confira o acesso a GitHub, conda-forge e ao registro pnpm/npm, além da configuração de proxy da rede.
Página abre sem estilos ou imagens	Confira BASE_PATH, a cópia completa de _astro/ e images/, os tipos MIME e eventuais caches. Refaça o build com o endereço correto.
Página inicial funciona, mas abrir /pesquisa/ diretamente falha	Confira o mapeamento de diretórios para index.html no servidor.
Links ainda apontam para o domínio anterior	Refaça o build com SITE_URL e BASE_PATH corretos e substitua toda a versão publicada.
Another astro dev server is already running, seguido de código 1	A prévia anterior continua ativa. Abra o endereço informado ou execute pixi run --locked dev-stop e depois pixi run --locked dev. Não é preciso reinstalar o ambiente.
Build aponta erro em um YAML	Confira o arquivo e campo indicados, a indentação e as traduções pt/en. Veja o guia de edição.

A configuração de hospedagem e a preservação do CI estão descritas em GitHub Actions e GitHub Pages.

Conferência de conteúdo

O Lattes tem atualização em 23/08/2026, confirmada também no XML fornecido em 18/09/2026. Disciplinas, vínculos, projetos e orientações refletem esse registro; não representam confirmação independente de oferta ou situação em cada semestre. Temas provisórios estão identificados, e temas não definidos foram omitidos. Os esclarecimentos sobre o ThermoPhase e a coorientação com o LEF desde 2024 foram fornecidos diretamente pelo autor.

O símbolo do LNCC é exibido por uma janela de recorte sobre a imagem institucional original. O arquivo completo permanece preservado. No modo escuro, o símbolo é apresentado em branco. O logotipo ThermoPhase foi fornecido pelo autor.

A redação mantém a experiência prévia na indústria de software em termos gerais. A ESSS aparece apenas no histórico do currículo; as demais páginas não atribuem à empresa as práticas ou os softwares de pesquisa.

Gerar novamente o currículo

O PDF disponível no site foi gerado com lattes2pdf 0.3.0 e RenderCV 2.8 a partir do ZIP/XML exportado pelo autor. O tema classic foi ajustado às cores do site. A versão acadêmica inclui formação, experiência, pesquisa, artigos, projetos, ensino, orientações, trabalhos em eventos, software listado no Lattes, bancas, prêmio e idiomas. A seleção não é uma transcrição integral do Lattes: por exemplo, cursos de formação complementar e apresentações foram omitidos. O registro integral continua acessível pelo link do Lattes.

Com Python 3.12 ou superior, na raiz do projeto, em Linux/macOS:

python3 -m venv .venv-cv
.venv-cv/bin/python -m pip install -r cv/requirements.txt
.venv-cv/bin/python cv/generate.py /caminho/para/CV_3999178670179183.zip --output .cv-build/revisao.pdf

A primeira geração precisa de acesso à internet para os pacotes Typst. A exportação de entrada permanece fora do repositório. .cv-build/ recebe o PDF, o YAML editável, o relatório de conversão e as somas de verificação. O cabeçalho usa somente os contatos públicos de cv/header.yaml; não se publicam XML, telefone, endereço residencial ou campos pessoais da exportação.

Revise o PDF, incluindo todas as páginas, antes de copiar .cv-build/revisao.pdf para public/files/cv-diego-volpatto-2026.pdf. Sem --output, o script substitui diretamente esse PDF do site. Atualize a data indicada em conteudo/paginas/curriculo.yaml quando o registro Lattes mudar. O build do site usa o PDF já revisado e não depende de Python ou de acesso ao Lattes.

As figuras de pesquisa são artefatos existentes, com referências, alterações e condições de uso descritas em THIRD_PARTY_NOTICES.md. Ao trocar uma figura, confira também legenda, texto alternativo e dimensões em conteudo/paginas/pesquisa.yaml, além dos créditos na página de licenciamento.

Browser Tests

Além dos Tests das páginas estáticas, há testes em Chromium para os dois idiomas, modos claro/escuro e larguras de desktop/celular. Eles verificam navegação, persistência do tema, figuras, logos, PDF e ausência de transbordamento horizontal. Os testes de segurança também verificam a ordem da CSP, a renderização de todas as páginas sem bloqueios indevidos e o bloqueio de código e conexões não autorizados. As tentativas de teste usam respostas simuladas, sem acessar servidores externos. Uma suíte adicional observa atividade automática em todas as páginas e testa interações de menu, idioma e tema, além do download intencional do currículo. Esses testes fazem parte do CI em PRs e pushes para main.

pixi run --locked browser-install
pixi run --locked verify-all

No Linux, use pixi run --locked pnpm exec playwright install --with-deps chromium se as bibliotecas do navegador estiverem ausentes. O CI instala essas dependências e roda os Browser Tests mesmo com o GitHub Pages desativado. Relatórios, capturas e evidências de falhas ficam em .test-output/; no CI são preservados como artefato. Os testes utilizam uma instância temporária na porta 4370, sem encerrar a prévia na 4321.

This site is open source. Improve this page.