CASE DE EVIDÊNCIA
Migração dos detalhes de projeto para ISR runtime com um fluxo de engenharia delimitado
Um gate real de performance do Portfolio 2025 usou o pack completo de Engineering Workflow para planejar, fatiar, revisar, verificar e entregar o handoff de uma transição para ISR runtime com ownership no servidor sem ampliar o escopo para rotas legitimamente dinâmicas.
01
Problema
Mover os detalhes de projeto em PT e EN do carregamento request-time controlado pelo cliente para ISR runtime com ownership no servidor, preservando URLs, localização, UI editorial, semântica de metadata, segurança de cache e rotas públicas intencionalmente dinâmicas.
02
Métodos aplicados
- 01Planejamento de Trabalho de EngenhariaTorna explícito o próximo passo de engenharia preservando restrições, riscos, dependências, suposições e as evidências exigidas para conclusão.
- 02Gestão de Slices de ImplementaçãoReduz expansão de escopo e risco de integração preservando uma cadeia clara de dependências entre slices de implementação.
- 03Revisão de Pull RequestsProduz achados de revisão priorizados e acionáveis sem confundir preferência de estilo com correção nem tratar o estado do CI como suposição.
- 04Redação de Handoffs Técnicos EficazesPreserva continuidade entre pessoas, agentes e sessões sem obrigar o próximo responsável a reconstruir o projeto a partir do histórico da conversa ou de suposições.
Registro de decisões
- 01
Planejar comportamento e verificação antes da implementação
Definir contratos RED, ownership no servidor, ISR, invalidação de cache, assertions de rota, QA e non-goals explícitos antes de alterar código de produção.
- 02
Manter a iniciativa de performance em slices dependentes
Tratar ownership de project detail como Gate C após o trabalho de locale roots e manter font delivery, upgrades, migrations e rotas legitimamente dinâmicas fora da slice.
- 03
Revisar risco em vez de polir o diff
Revisar ownership, localização, reutilização de metadata/JSON-LD, invalidação após mutações, classificação de rotas, CI atual e limites de escopo antes de aceitar o candidato.
- 04
Entregar um ponto exato de retomada
Preservar SHA do candidato, IDs dos runs, decisões de rota, QA, restrições e a próxima ação explícita de não fazer merge sem autorização na descrição final da PR.
03
Verificação
Trate este relatório como evidência dos métodos e da verificação mostrados aqui. A sobreposição com um pack, sozinha, não prova que o pack foi usado ou validado por completo.
04
Resultado
- 01
Os padrões PT/EN de detalhes de projeto saíram de renderização dinâmica por request para ISR runtime preservando a interface editorial.
- 02
O candidato final passou contratos de static rendering, performance, SEO, validação, integrações, typecheck, lint, build de produção, assertion de rotas e QA localhost.
- 03
O merge subsequente na main passou o workflow canônico Validate.
- 04
Os quatro métodos de Engineering Workflow contribuíram para planejamento, limites de slice, revisão ou handoff técnico.