Cyrus-terra/qilin-fit

Desenvolvimento de Compatibilidade Front-end Kirin / Qianxin

Princípios de Uso

Trate a compatibilidade como uma restrição desta implementação, não como uma correção de cor após a página estar pronta. Este Skill se aplica a novos desenvolvimentos, correções de bugs, atualizações de dependências e revisões; não exige um framework específico. Apenas trate os riscos envolvidos na tarefa, não reescreva incondicionalmente todo o projeto.

Não é possível garantir a cobertura de todas as versões do Qianxin. O número do produto, canal de distribuição e versão do kernel Chromium podem ser diferentes; o mesmo kernel pode se comportar de forma diferente em diferentes CPUs, drivers e políticas corporativas. Informações desconhecidas devem ser marcadas como "a confirmar", e registros de verificação não podem ser falsificados.

1. Determine o Contrato de Suporte Primeiro

1. Leia as diretivas existentes do projeto, arquivos de bloqueio, configuração de build, testes de compatibilidade e escopo de suporte, preservando as alterações do usuário.
2. Colete do usuário, da página "Sobre" do navegador e de assets/browser-probe.html: nome completo do produto, versão completa do produto, canal, versão completa do Chromium, versão/SP do Kirin, arquitetura da CPU, DPR/zoom, fontes/GPU, políticas corporativas críticas. O User-Agent serve apenas como pista, não pode provar o kernel real.
3. Crie ou atualize a matriz de suporte existente do projeto; quando não houver arquivo pronto, use assets/support-matrix.example.json. Preencha as funcionalidades essenciais do negócio, o kernel real mínimo, os critérios de aceitação em dispositivo real e de degradação. Não registre dados do dispositivo de negócios no diretório do Skill instalado.
4. Quando a linha de base for desconhecida, pergunte primeiro, não considere automaticamente como Chromium 102. Se o usuário solicitar desenvolvimento antes, uma linha de base conservadora pode ser definida provisoriamente, mas deve ser registrada como provisional / não verificado, e não se pode escrever "já compatível com todas as versões".
5. Leia a Matriz de Navegadores. Diferentes canais e arquiteturas devem ser validados separadamente; a linha de base mínima e versões superiores devem ser cobertas, não se pode testar apenas o Chrome mais recente para representar o Qianxin.

2. Auditoria Somente Leitura, Determine a Mínima Alteração

• Leia o código-fonte real e a configuração de build de produção para confirmar ferramentas CSS, bibliotecas de UI, pontos de entrada do navegador/servidor, pacotes de terceiros e método de implantação.
• Selecione as referências a serem lidas com base na alteração, não é necessário carregar todos os arquivos a cada vez:

Tarefa	Obrigatório Ler
Estilos, Tailwind, layout, tema, popups	CSS e Layout
JS/TS, compilação de sintaxe, dependências, Web APIs	JavaScript e Build
Fontes/IME, arquivos, PDF, permissões, rede, CPU/GPU	Plataforma Kirin e Entrega
Testes, screenshots, aceitação de release, limites de dados	Verificação e Aceitação
Verificar suporte de funcionalidades ou base de versão	Fontes e Níveis de Evidência

• Execute o verificador a partir do caminho real de instalação do Skill; <skill-dir> representa o diretório onde o SKILL.md atual está localizado. Substitua pelo caminho real confirmado, não copie o placeholder:

python3 "<skill-dir>/scripts/compat_audit.py" ./src --min-chromium 102

Use o 102 do exemplo somente quando o contrato de suporte já determinou que é 102; quando não determinado, omita --min-chromium, a saída marcará como unknown. Substitua o caminho pelo projeto real. O verificador é somente leitura, zero dependências de terceiros, não modifica código; é uma detecção de candidatos léxica, não um compilador AST, CSS ou certificação de compatibilidade.

3. Regras de Implementação

CSS

• Para caminhos estáveis, use preferencialmente hex/rgb/hsl convencionais, transform tradicional, layout com fallback; use recursos modernos apenas quando o alvo suportar ou for demonstrado aprimoramento progressivo.
• Para 102: verifique principalmente :has(), container queries, novas unidades de viewport, transformações independentes, cores modernas, aninhamento nativo, Popover e código gerado pelo Tailwind. Consulte a referência CSS para limites de suporte e alternativas.
• Tailwind v4 tem Chrome 111 como mínimo oficial; 102 não está na faixa de suporte. Não se pode afirmar que patches de paleta, Autoprefixer ou definição de JS target resolvem toda a compatibilidade v4. Proponha soluções suportadas ou transformação de artefatos validada; migração/downgrade de dependências deve ser confirmado primeiro, não execute por conta própria.
• O fallback de var() não equivale a fallback de qualquer cor moderna; CSS.supports() não equivale a pixel correto real. Verifique parsing, valor computado e resultado visual separadamente.
• Ao modificar o posicionamento de popups, preserve a composição de transform para animação e arrasto; verifique máscara, foco, scroll, teclado, Portal e contexto de empilhamento, não apenas a centralização do screenshot.

JS / Dependências

• Distinga entre transpilação de sintaxe, polyfill de objetos internos e Web APIs que exigem permissão/suporte de plataforma nativa. target do TypeScript, lib e target do build não podem se substituir mutuamente.
• Configure o kernel real mínimo na cadeia de entrega para navegadores, verifique dependências, chunks dinâmicos, workers, scripts de terceiros e artefatos CSS; APIs do lado do servidor Node não podem ser usadas como APIs de navegador.
• Para novas APIs, faça detecção de capacidade no ponto de entrada, com degradação aceitável para o negócio; falha de parsing de sintaxe ocorre antes da detecção, não se pode usar if para envolver nova sintaxe em vez de transpilar.
• Não desabilite blanketamente capacidades já suportadas como optional chaining, nem polyfill tudo por padrão. Não desative CSP, verificação de certificado, sandbox ou outras medidas de segurança por motivo de compatibilidade.

Plataforma / Dados

• Cubra falta de fontes, eventos de composição de IME chinês, diferenças de arquitetura, GPU, download/impressão, nomes de arquivo, proxy/certificados, implantação offline e políticas de permissão corporativas.
• Ao envolver dados externos/de IA, valide na fronteira de acordo com o schema real e exiba estado claro de falha/ausência; não preencha silenciosamente pontuações desconhecidas como válidas, nem force a introdução de uma biblioteca de validação específica. Alterações de negócio não relacionadas ao navegador não devem ter o escopo ampliado.

4. Ordem de Verificação

1. Varredura de riscos do código-fonte, testes unitários existentes e lint; confirme diretórios não varridos, falsos positivos e justificativas de isenção manual.
2. Build de produção; varra o CSS/JS realmente publicado (use --include-build, confirme que o caminho não é mapeamento de código-fonte ou pacote do lado do servidor Node). Registre a saída real da transformação/degradation, não deduza eficácia pela configuração.
3. Abra o probe offline no navegador alvo, verifique manualmente a área visual, depois acesse os fluxos críticos do projeto real. O probe não substitui o teste do projeto, não coleta credenciais ou entrada de negócios.
4. Compare com a linha de base mínima, versões existentes e o terminal Kirin real da versão atual, execute a aceitação de funcionalidade/screenshot/teclado/IME/zoom/impressão dos documentos de referência. Chrome comum, Chromium recente do Playwright ou User-Agent falsificado não podem substituir o dispositivo real alvo.
5. Sem dispositivo real, sem permissão de instalação de dependências ou falha de build, escreva claramente os bloqueios e itens não verificados, não gere screenshots/conclusões falsas de sucesso.

# Apenas exemplo: substitua pelo diretório real de artefatos do navegador do projeto
python3 "<skill-dir>/scripts/compat_audit.py" ./dist --include-build --min-chromium 102 --format json
# Opcionalmente, defina um gate de CI para todos os riscos candidatos; primeiro trate falsos positivos e aprimoramento progressivo com evidência
python3 "<skill-dir>/scripts/compat_audit.py" ./src --min-chromium 102 --fail-on warning

5. Formato de Entrega

Saída resumida:

• Contrato de Suporte: versão/arquitetura real, kernel mínimo; unknown/provisional deve ser anotado.
• Alterações e Justificativas: problema, local, método de degradação/transformação; ao citar código, use path:line.
• Resultados da Verificação: código-fonte, artefatos, navegador comum, dispositivo real Kirin registrados separadamente como pass/fail/not-run, não misturados em um único "aprovado".
• Riscos Residuais: versões não verificáveis, limitações de política/hardware e trade-offs que precisam de confirmação do usuário.

A descrição do Skill é usada para correspondência automática; se deve ser acionado a cada vez, isso deve ser explicitamente solicitado pela diretiva do Agent do projeto de uso, exigindo o carregamento deste Skill antes do desenvolvimento relacionado. O Skill em si não pode substituir o mecanismo de descoberta do host, nem contornar permissões ou forçar a chamada do modelo.