O que Project Steward faz?

Papel e Roteamento

O Project Steward mantém métodos de governança reutilizáveis entre projetos. As decisões de produto, fatos de arquitetura e restrições de longo prazo de cada projeto permanecem em suas fontes únicas de verdade existentes; fatos variáveis de ferramentas (usuário e máquina) permanecem em arquivos de ambiente fora do projeto e do Skill.

Primeiro, selecione o caminho principal com base no resultado que o usuário deseja obter; resultados independentes dentro da mesma solicitação devem ser contabilizados separadamente:

Diálogo histórico, correção, processo completo de implementação ou limite funcional do Skill alvo: Aprendizado por Conversa e Auto Evolução.
Antes de iniciar funcionalidades, refatorações, migrações ou mudanças entre camadas para eliminar retrabalho: Prevenção de Mudanças.
Defeitos, migrações parciais, reparos repetitivos, falhas em cadeias reais ou verificações de coesão, acoplamento, duplicação e módulos god: Remediação de Causa Raiz.
Verificar, integrar ou reparar a compatibilidade do projeto com CLIs, ferramentas de execução ou protocolos externos: Compatibilidade com Ferramentas Externas.
Compreender o propósito, arquitetura e capacidades de um repositório, diretório ou pacote de código-fonte, ou pesquisar projetos de referência: Pesquisa e Explicação de Projeto.
Auditar ou organizar diretórios do projeto, julgando limites de uso real, estado de geração, ignorar, mover, arquivar e excluir: Governança de Diretório do Projeto.
Estabelecer, adotar, atualizar ou verificar modelos de projeto: Linha de Base e Modelos do Projeto.
Escrever padrões estáveis em modelos: Evolução de Modelos.
Definir, revisar, reconstruir ou implementar a experiência e interface do produto: Governança de Experiência e Interface do Produto.
Auditar, reescrever README ou criar visuais para a página inicial do GitHub: README e Página Inicial.
Governar logs do projeto, registros de LLM, memória de longo prazo, TTS ou resultados de visualização de logs: Logs Humanizados.
Inicializar Git, criar repositórios, commit, push, alterar visibilidade ou verificar remoto: Criação e Publicação de Repositório.
Selecionar, aplicar ou governar licenças e autorizações de terceiros em lote: Governança de Licenças.
Estabelecer ou consumir perfis de ambiente do usuário, verificar ferramentas, cache, SDKs, terminais ou tarefas longas: Perfil de Ambiente do Usuário e Ambiente de Execução.
Verificar a conclusão item por item de acordo com um plano de implementação, ou realizar uma verificação abrangente, julgar a saúde do projeto e classificar riscos em nível de projeto: Auditoria Abrangente do Projeto.

Quando apenas este Skill é mencionado, selecione o caminho mais adequado com base no material existente; se o material for insuficiente, forneça um exemplo de solicitação direta próximo ao contexto e pare.

Após selecionar o caminho principal, antes de qualquer gravação ou implementação especializada no projeto, estabeleça um livro-razão de roteamento: resultado final do usuário, caminho principal, métodos obrigatórios fixos, especialidades condicionais e suas evidências de acionamento, limites de ação, consumidores formais, critérios de aceitação e pontos de parada. Métodos obrigatórios fixos não podem ser ignorados porque uma modificação local parece óbvia; especialidades condicionais só são sobrepostas se as evidências de aplicabilidade forem obtidas. Se itens de aceitação forem adicionados posteriormente na mesma solicitação, atualize o livro-razão original; não substitua escopos ainda válidos pelos sintomas mais recentes.

Limites Comuns

Funcionalidades de negócio comuns continuam sendo responsabilidade da tarefa de desenvolvimento atual; se o usuário apenas pedir explicação de um único erro, função ou comportamento local, responda a esse resultado e pare, sem escalar para uma reforma em nível de projeto. Somente quando a solicitação em si exigir prevenção, remediação, migração, auto evolução ou resultados em nível de projeto, o caminho correspondente deve ser seguido.
Congele imediatamente o escopo, permissões de gravação e ponto de parada após selecionar o caminho. Verificações, auditorias, diagnósticos, avaliações, análises, revisões e relatórios são somente leitura por padrão; permissões de gravação correspondentes só são obtidas na mesma solicitação se a reparação, governança, implementação, modificação, atualização ou auto evolução for explicitamente solicitada.
Quando o usuário fornece um arquivo de código-fonte e solicita entender, auditar ou pesquisar o projeto, ou apenas menciona este Skill e anexa o arquivo, a descompactação é uma preparação de material necessária para pesquisa somente leitura, não uma gravação formal do projeto. Siga diretamente "Pesquisa e Explicação de Projeto" para determinar a raiz alvo, execute scripts existentes para descompactar em um diretório independente com nome evitando duplicatas, leia a raiz do projeto retornada pelo script e continue a pesquisa somente leitura, sem necessidade de confirmação adicional de descompactação. Esta ação autoriza apenas a criação de uma cópia de pesquisa e a leitura de seu conteúdo; executar o projeto, instalar dependências ou ferramentas de descompactação, modificar o projeto, mover ou excluir arquivos originais, fazer commit e publicar ainda requerem autorização separada.
Conectar à internet, baixar, instalar, executar, gerar, gravar, mover, arquivar, excluir, fazer commit, push e publicar são autorizados separadamente; apenas o contrato de conclusão padrão explicitamente listado nesta seção pode mesclar autorizações de gravação, commit, push e verificação remota dentro do mesmo resultado do usuário. Executar ou gerar não equivale a obter permissão de gravação no projeto; fora do contrato de conclusão padrão, commit, push ou publicação autorizam apenas o processamento de alterações existentes e verificadas com precisão, não autorizam retroativação de gravações anteriores e não incluem alterações na árvore de trabalho não relacionadas.
Quando o usuário menciona explicitamente o Project Steward (incluindo chamar $project-steward) e solicita explicitamente modificação, reparo, governança, atualização ou otimização de um projeto Git existente, se o branch atual tiver um upstream configurado e o usuário não tiver solicitado apenas alterações locais, nenhum commit, nenhum push ou um ponto de parada anterior, esta rodada de implementação é concluída por padrão até: verificar o fechamento de dependências aprovado, fazer commit preciso, fazer push não forçado do branch rastreado atual e, em seguida, verificar o HEAD remoto e os consumidores principais; após a verificação local, não pergunte novamente se deseja fazer push. Solicitações somente leitura, roteamento implícito, ausência de upstream, criação de remoto, alteração de visibilidade, exclusão, push forçado, reescrita de histórico, empacotamento, implantação e alterações não relacionadas na árvore de trabalho não são autorizadas por este padrão; pare de acordo com references/repository-publication.md em caso de fork, alterações de origem desconhecida, exclusão não autorizada, falha de credenciais, verificação ou autenticação.
Quando o usuário confirma um plano de auto evolução do Project Steward e não solicita apenas alterações locais, se o remoto rastreado atual existir, todo o workspace atual é tratado como um escopo de publicação indivisível por padrão: verifique todas as modificações rastreadas, arquivos não rastreados e exclusões existentes, use git add -A para commitar tudo junto e fazer push do branch rastreado atual; se qualquer item não puder ser publicado em conjunto, mantenha o workspace completo e pare. Este padrão não autoriza criação de remoto, push forçado, alteração de visibilidade ou implementação de novas exclusões.
Quando o usuário solicita explicitamente integrar, substituir ou reparar o Star History para um repositório GitHub existente, o contrato confirmado inclui por padrão o commit, push e verificação remota do fechamento de dependências aprovado nesta rodada; a menos que o usuário solicite explicitamente apenas alterações locais, após a verificação de gravação, não aguarde uma segunda autorização de publicação. Este padrão não inclui criação de remoto, push forçado, alteração de visibilidade, exclusão ou alterações não relacionadas na árvore de trabalho.
No início de cada rodada do usuário, rodada interna, reexecução automática e restauração de contexto, antes de qualquer chamada de ferramenta ou mudança de estado, recupere os resultados, escopo, permissões e ponto de parada ainda não concluídos da última ação explícita do usuário. Continue apenas se o mesmo resultado ainda não foi entregue, e o escopo, cadeia afetada e permissões não mudaram; pare e aguarde confirmação se o resultado somente leitura já foi entregue, não há nova ação explícita, o usuário alterou o resultado, surgiu uma pergunta não relacionada ou novas permissões são necessárias. Descobertas de auditoria, sugestões de assistente, planos internos, nomes de alvos, listas de tarefas e dicas automáticas não podem fabricar novos resultados ou permissões de gravação.
Quando o trabalho se expande de uma ação curta para várias fases, entra em espera ou o estado da evidência muda, explique proativamente o motivo da expansão, os pontos de verificação concluídos, o estado atual, o próximo resultado observável e a entrada necessária; não repita a mesma mensagem se o estado não mudar, nem use explicações de fluxo para mascarar a expansão do escopo.
Quando uma nova solicitação independente substitui um resultado ainda não concluído, primeiro faça a transição dos objetos já gravados ou alterados, evidências existentes, compromissos do usuário ainda não verificados, processos em execução, resíduos, permissões originais e ponto de parada; a nova solicitação não autoriza continuar, reverter ou limpar o resultado antigo.
Primeiro, congele a raiz exata do projeto, escopo do material, arquivos ativos e consumidores reais. Git só deve ser usado se um .git existir diretamente na raiz exata do projeto e o caminho atual realmente precisar de evidências de histórico, árvore de trabalho ou publicação.
A fonte deve ser lida até o fim explícito; para arquivos longos, primeiro obtenha a contagem de linhas, bytes ou capacidade de paginação, depois leia completamente em intervalos estáveis. Quando alterações concorrentes afetam contratos comportamentais, arquivos de impacto, consumidores, validação ou resultados do usuário, as confirmações antigas perdem a validade; replaneje e confirme novamente.
Múltiplas sondagens independentes só devem ser paralelizadas se o orquestrador puder manter a saída, erro e status de saída de cada item individualmente; se qualquer item fizer com que todo o lote termine prematuramente, execute-os independentemente. Após a falha de um lote, preserve as evidências de sucesso ainda frescas e execute novamente apenas os itens mascarados, não executados ou com status desconhecido.
Fatos do projeto devem ser gravados de volta na única fonte de verdade existente do projeto; fatos do ambiente devem ser gravados em um perfil de usuário independente; métodos de governança transferíveis só devem entrar neste Skill; modelos só devem receber padrões estáveis que devem ser executados a cada vez para um determinado tipo de projeto.
Ao julgar se uma capacidade em material histórico ou externo já existe, primeiro conclua a divisão de resultados independentes e a ordenação causal necessária, depois cubra a fonte e verifique se o alvo pode reconhecer a mesma condição, reter os mesmos detalhes constitutivos e tomar o mesmo tratamento específico; apenas o framework de governança de nível superior conta como parcialmente possuído. Somente após a comparação item por item, destile o mecanismo comum e as dimensões especiais.
A validação deve selecionar o nível com base no risco da alteração: primeiro execute verificações alvo que cubram diretamente esta alteração e as alegações de aceitação; para alterações apenas em documentação, licenças, agradecimentos ou metadados puros, pare após passar na entrada de manutenção correspondente, sem iniciar navegadores ou cadeias ponta a ponta desnecessários; apenas quando contratos públicos, runtime principal, limites entre repositórios, publicação ou verificações alvo expuserem impacto sistêmico, atualize para regressão completa e cadeia de usuário real.
Após uma mudança de estado, releia diretamente a autoridade alvo. A conclusão da validação deve percorrer produtores formais, limites de transporte ou armazenamento, consumidores e resultados observáveis pelo usuário; não permita que o lado do consumidor insira dados falsos ou simule a cadeia principal que está sendo validada.
Antes de usar resultados de teste para fechar um compromisso ou declarar conclusão, as identidades esperadas dos testes principais devem ser consistentes com as identidades exclusivas realmente coletadas pelo framework de teste; identidades ausentes ou não exclusivas só podem ser marcadas como não cobertas.
Ao ler configurações de diagnóstico, relatórios de execução, artefatos estruturados ou logs, projete primeiro os campos permitidos necessários para o julgamento atual de acordo com references/log-audit-standard.md; estruturas desconhecidas não devem ser recursivamente geradas por completo, e credenciais devem ser desinfectadas antes de entrar na saída da ferramenta, diálogo ou exportação de diagnóstico.

Aprendizado por Conversa e Auto Evolução

Primeiro, leia completamente references/conversation-learning-and-self-evolution.md.

Quando qualquer resultado do usuário contiver falha, correção, interceptação de proteção, desvio temporário ou resíduo, leia também references/root-cause-remediation.md. A ordem de leitura é fixa: recupere o processo completo do resultado ao longo da cadeia causal para determinar o principal tópico de aprendizado e resultados secundários independentes, depois recupere os detalhes específicos que mudarão a governança futura e compare as capacidades alvo item por item de acordo com os limites comuns; somente então destile o mecanismo comum e as dimensões especiais, julgue a transferibilidade, o limite funcional e o proprietário formal e, finalmente, julgue a responsabilidade histórica. Desvios e resíduos não podem substituir causas raiz controláveis mais antigas com evidências estabelecidas; se correções posteriores alterarem a causa principal, os planos e confirmações existentes perdem a validade imediatamente. Somente quando o resultado for bem-sucedido e esses sinais não estiverem presentes, o método de causa raiz não deve ser carregado.

A comparação de capacidades deve primeiro distinguir entre "falta de método" e "método existente não foi roteado, executado ou aceito". O primeiro só fortalece o único proprietário do método in situ; o último só repara a rota principal, limites de ação, consumidores formais ou validação que falhou primeiro, sem adicionar regras sinônimas em outros arquivos. Os planos devem ser organizados por proprietário e cadeia de consumo, não empilhando patches na ordem de aparecimento no diálogo.

Quando o usuário solicita apenas análise, permaneça somente leitura. Quando absorção, auto evolução, atualização, otimização ou iteração do Project Steward são explicitamente solicitadas, primeiro entregue o comportamento futuro, limite funcional, saída representativa, arquivos impactados e método de validação e pare; modifique o Skill ativo somente após o usuário confirmar esse plano. Se o plano confirmado não declarar apenas alterações locais, leia também references/repository-publication.md; se o remoto rastreado atual existir, verifique todo o workspace de acordo com o impacto real, use git add -A para commitar modificações rastreadas, arquivos não rastreados e exclusões existentes juntos e faça push do branch rastreado atual, verifique se não há omissões entre o HEAD remoto e o workspace antes de concluir. Em caso de falha de remoto, autenticação, proteção de branch, fork, verificação ou qualquer item não publicável em conjunto, mantenha o workspace completo e pare no limite exato, sem reverter para commits seletivos.

Durante a auto evolução do Project Steward, as restrições do arquivo principal devem ser executadas:

Antes de gravar, registre o número de linhas, caracteres e a coleção de referências diretas de SKILL.md, e atribua um proprietário ativo exclusivo para cada nova regra adicionada.
SKILL.md possui apenas roteamento, condições de acionamento, ordem de leitura, permissões, saída e pontos de parada; métodos completos, tabelas, listas de verificação e exceções são de propriedade exclusiva da referência correspondente, com o arquivo principal mantendo apenas links diretos.
Após a gravação, SKILL.md não deve exceder 220 linhas ou 14.000 caracteres e deve manter todas as capacidades ativas diretamente acessíveis. Se novos roteamentos excederem o orçamento, detalhes antigos devem ser migrados ou mesclados na mesma alteração.
Se não for possível manter as capacidades existentes, consumidores formais e validação dentro do orçamento, pare a gravação, replaneje e não declare conclusão.

Prevenção de Mudanças

Primeiro, leia references/change-prevention.md, que é responsável pelo comportamento alvo, fonte única de verdade, gráfico de impacto, interface final, saída de caminho antigo e aceitação da cadeia de usuário real. Sobreponha de acordo com o problema:

Operações duráveis, lotes limitados e drenagem de backlogs em filas ou agendadores, recuperação, reinicialização, artefatos em grupo, ou concorrência de admissão, liberação e fechamento de sessões e recursos compartilhados em serviços stateful residentes: references/durable-operation-governance.md
Status de tarefa, progresso ou reexecução automática: references/task-progress-governance.md
Resultados de alto custo que exigem demonstração por fases, confirmação, execução automática contínua ou invalidação por alterações upstream: references/staged-result-governance.md
O mesmo resultado expresso por múltiplas especificações, planos, tarefas ou artefatos de pesquisa, com necessidade de decidir relações evolutivas, ou envolvendo artefatos derivados, cache semântico, divisão de unidades de trabalho, utilização de pool de recursos ou orquestração repetitiva de agentes: references/derived-artifact-governance.md
Plano de validação de CI em nível de projeto, cache de ambiente de execução, hierarquização de recursos de teste, fragmentação demorada, falha rápida e reexecução precisa: references/ci-execution-governance.md
Configuração em tempo de execução que recria serviços compartilhados, providers, raízes de armazenamento ou grafos de composição: references/runtime-generation-governance.md
Dificuldade de reprodução, problemas de temporização, concorrência, contrapressão ou cadeias completas caras: references/hard-to-reproduce-diagnostics.md
JSON externos, persistidos, de modelo, rede ou processo que possuem múltiplas análises, capacidade, fragmentação atômica, cursores de reprodução ou ambiguidade de contrato: references/structured-data-boundary.md
Modelo envolvido em julgamento de tarefa, expressão de estado, eventos de tempo de execução ou respostas estruturadas, exigindo verificação de fonte de mensagem, papel, roteamento, solicitação de linha e responsabilidade de apresentação: references/model-mediated-operation-governance.md
Código-fonte externo como ponto de partida único para estabelecer um produto independente, ou absorção seletiva de seu ecossistema de extensão: references/source-fork-and-ecosystem-adoption.md; ao copiar código, leia também references/license-governance.md
Experiência e interface do produto: references/product-experience-governance.md; quando métodos de design ou interação forem necessários, leia também references/ux-design.md

Modifique o projeto apenas quando o usuário autorizar explicitamente a implementação; se apenas um plano for solicitado, pare no gráfico de impacto, limites alvo, ordem de migração e contrato de aceitação.

Remediação de Causa Raiz

Primeiro, leia references/root-cause-remediation.md. O diagnóstico para em evidências, escopo de impacto e método de reparo final; a implementação migra todos os produtores, limites e consumidores de uma só vez e sai da arquitetura antiga. Sobreponha de acordo com o problema:

Se o reparo assumir uma auditoria abrangente anterior desta tarefa, ou o usuário solicitar explicitamente reparar todos os problemas dessa auditoria, o livro-razão de transição da auditoria original continua como contrato de fechamento; antes de gravar, leia references/change-prevention.md fixamente e, após a última modificação relevante, retorne a references/project-audit.md para regenerar a cobertura e o livro-razão de descobertas do escopo original e do contrato atualmente aceito. Um único defeito não se expande para esta cadeia apenas porque um histórico contém uma auditoria não relacionada.

Operações duráveis, lotes limitados e drenagem de backlogs em filas ou agendadores, recuperação, ou concorrência de admissão e liberação de sessões em serviços stateful residentes: references/durable-operation-governance.md
Progresso de tarefa ou estado contínuo: references/task-progress-governance.md
Retrabalho devido à falta de confirmação por fases, desvio do objeto de confirmação ou disseminação incorreta de alterações: references/staged-result-governance.md
Retrabalho devido a relações incertas entre múltiplos artefatos, perda de justificativa na regeneração, recálculo completo, invalidação incorreta de cache, divisão perigosa, julgamento incorreto de recursos ou idas e vindas de orquestração: references/derived-artifact-governance.md
CI em nível de projeto com testes lentos repetitivos, desperdício de preparação de ambiente, desequilíbrio de fragmentação, pré-verificação entre plataformas muito tardia ou reexecução indiferenciada após falha: references/ci-execution-governance.md
Operações de tempo de execução que abrangem gerações de serviço, transações de configuração a quente ou alternância de raiz física: references/runtime-generation-governance.md
Problemas difíceis de reproduzir ou de baixa observabilidade: references/hard-to-reproduce-diagnostics.md
Codificação, orçamento de recursos, capacidade lógica de mensagem, fragmentação atômica, cursores de reprodução, valores numéricos, schema ou bifurcação semântica de erros em JSON estruturados: references/structured-data-boundary.md
Respostas do modelo, estado de tarefa ou apresentação de resultado inconsistente com o runtime real, ou necessidade de localizar a solicitação real enviada ao modelo: references/model-mediated-operation-governance.md
Propriedade de hierarquia visual, transformação ou animação: references/interaction-motion.md; quando a aceitação da tela real de execução for necessária, leia também references/implementation-review.md
Ferramentas, aliases de caminho, ambiente de execução ou tarefas longas: references/user-environment-governance.md
Eventos, versões, histórico ou cache que confundem o escopo de impacto planejado com fatos reais de alteração: contrato "Separação de escopo planejado e fatos reais de alteração" de references/change-prevention.md
Atualizações de estado local, heartbeat ou telemetria que sobrescrevem ou limpam campos não declarados, ou consumidores incapazes de distinguir entre snapshot completo e patch parcial: contrato de atualização de projeção ativa de references/change-prevention.md
Código-fonte, README, scripts, testes ou configurações com valores hardcoded da máquina local e fatos de implantação: limite de configuração de execução do projeto de references/change-prevention.md; para fatos da máquina do usuário, leia também references/user-environment-governance.md
Coesão, acoplamento, duplicação semântica ou módulos god: references/architecture-cohesion-governance.md

Compatibilidade com Ferramentas Externas

Leia references/external-tool-compatibility.md. Quando as relações de compatibilidade envolvem contratos públicos entre raízes de projeto, snapshots derivados ou pacotes de entrega compostos, leia também os limites de contrato público, fechamento de adoção de contrato e entrega entre raízes de references/change-prevention.md. A verificação de compatibilidade permanece somente leitura e relata, por adaptador explícito em cada camada, artefatos executáveis, contratos de capacidade, chamada e isolamento, entrada temporária, protocolo de linha upstream, resultado estruturado, verificação independente do host e cadeia do usuário; modifique a raiz do projeto aprovado apenas quando a reparação ou integração for explicitamente autorizada.

Pesquisa e Explicação de Projeto

Primeiro, leia references/project-research.md. Leia apenas a superfície do projeto necessária para responder à pergunta atual; expanda a cobertura apenas quando o usuário solicitar explicitamente uma pesquisa completa ou adoção de capacidade e, ao mesmo tempo, leia references/source-fork-and-ecosystem-adoption.md, primeiro rastreie o upstream original e distinga entre reutilização direta e aprendizado de método; quando confirmar que código ou recursos serão reutilizados diretamente, leia também references/license-governance.md e escreva recursos de terceiros e agradecimentos no README do projeto alvo. Quando for necessário medir eficácia, amostras de falha e confiança, leia references/project-effectiveness-review.md; quando for necessário salvar um relatório verificável, leia references/project-research-report.md. Para arquivos de código-fonte, primeiro use scripts/extract_project_archive.ps1 com -DestinationRoot <raiz_alvo> para descompactar em um diretório independente; se nenhuma raiz alvo for especificada, use E:\Work\BaiduSyncdisk\Code\Example. Após o script retornar a raiz do projeto, leia imediatamente references/archive-safety-screening.md e execute scripts/inspect_extracted_project_safety.py; somente se este método confirmar um risco significativo, a saída é fornecida ao usuário; caso contrário, continue silenciosamente a pesquisa original.

Governança de Diretório do Projeto

Leia references/repository-directory-governance.md. Primeiro, use scripts/inspect_project_tree.py para obter evidências físicas e Git somente leitura e, em seguida, verifique o produtor formal, fonte de verdade do caminho, consumidor e ciclo de vida de cada diretório candidato; pare a verificação, explicação e planejamento no livro-razão de evidências; altere o caminho exato apenas quando a organização, movimentação ou arquivamento for explicitamente autorizado; a exclusão continua exigindo autorização separada. Quando a movimentação afetar código-fonte ativo, modelos, dados, materiais, entradas de construção ou execução, leia também references/change-prevention.md; quando caminhos antigos, leitura dupla, cópias síncronas ou migrações parciais já existirem, leia também references/root-cause-remediation.md, migrando consumidores de uma só vez e saindo da entrada antiga.

Linha de Base e Modelos do Projeto

Leia references/project-template-system.md. Solicitações somente leitura param em inspect, plan ou verify; adopt, upgrade ou gravação de configuração de projeto exigem autorização explícita e verificação dos consumidores formais.

Evolução de Modelos

Leia references/template-evolution.md. Primeiro, prove que o candidato é um padrão estável, não um método que ainda requer julgamento situacional, e então sincronize a versão do modelo, registro, hash, documentação e testes do consumidor.

Governança de Experiência e Interface do Produto

Primeiro, leia references/product-experience-governance.md e, em seguida, execute de acordo com as seguintes entradas fixas e especialidades condicionais:

Diagnóstico, avaliação, otimização ou reconstrução de interface: leitura fixa de references/ux-design.md, references/interface-experience-quality.md, references/interface-problem-patterns.md, references/implementation-review.md. Antes de modificar, congele todas as janelas, páginas, painéis, sobreposições, estados principais e jornadas do usuário relacionadas; não trate o problema local mais proeminente em uma captura de tela como escopo completo de revisão.
Design do zero ou mudança de direção visual: references/design-method.md, references/visual-direction.md, references/surface-registers.md
Layout, design system, interação e animação: references/layout-responsive.md, references/design-system-alignment.md, references/interface-guidelines.md, references/interaction-motion.md
Reconstrução fiel de interface de referência: references/reference-interface-reconstruction.md
Quando confirmado como aplicativo desktop, Tauri/Vue ou workspace de arquivo local, leia respectivamente references/desktop-app-governance.md, references/tauri-vue-governance.md, references/local-file-workspace-governance.md; quando a forma do projeto já estiver estabelecida, não omita o shell da plataforma apenas porque o feedback atual menciona apenas cor, espaçamento ou texto.
Status de tarefa ou progresso: references/task-progress-governance.md

Ao depender de posicionamento ou design system existente, execute scripts/context.mjs no máximo uma vez por tarefa; ao reconstruir fielmente uma interface de referência, assets/reference-reconstruction/component-spec.md assume a especificação do componente.

Criação e Publicação de Repositório

Leia references/repository-publication.md. Distinga entre inicialização, commit, criação de remoto, push, visibilidade, verificação e implantação; cada passo executa apenas o ponto de parada autorizado e verifica a identidade exata do repositório, índice, branch, remoto e alterações concorrentes antes e depois da mudança de estado.

README e Página Inicial

Primeiro, leia references/readme-delivery.md, usando um livro-razão de entrega para verificar limites do Git, README, corpo, visuais, multilíngue, licença, Star History, GitHub Topics, metadados do repositório, validação e ponto de parada; solicitações somente leitura param no mesmo livro-razão; implemente apenas quando otimização, reescrita ou tratamento completo forem explicitamente solicitados. Em seguida, leia references/content-architecture.md; para otimização completa ou envolvendo logo/hero, leia references/visual-direction.md, primeiro realize uma investigação da fonte formal de identidade com código prioritário e, em seguida, leia references/project-native-hero.md e references/github-readme-canvas.md conforme necessário. Quando multilíngue, entrada pessoal ou área de status do repositório for necessária, leia assets/readme-profile/profile.json, consumido por scripts/readme_header.py com arquivos reais, identidade do repositório, licença e navegação do projeto explicitamente analisada. Para otimização completa do README de um repositório público GitHub existente, inclua Star History e Topics como itens de entrega padrão: para Star History, leia references/github-star-history.md e references/repository-publication.md; para Topics, escreva e releia através de scripts/github_topics.py; a menos que o usuário opte explicitamente por sair ou o alvo objetivamente não se aplique, um resultado bem-sucedido sem nenhum consumidor real não pode concluir toda a entrega. Selecione conforme necessário:

SVG e visuais híbridos: references/svg-production.md, references/hybrid-svg-production.md
Animação: references/motion-production.md
Limites de plataforma: references/platform-guidelines.md
Diagnóstico ou integração especializada de Star History auto-hospedado: references/github-star-history.md; mantenha somente leitura ao perguntar apenas sobre causa de falha ou status atual; ao implementar, faça commit preciso e push das alterações no repositório de chamada, execute manualmente o workflow e, em seguida, verifique a cadeia real por API, gerador, branch de saída, raw SVG e consumidor README

O README não serve como segunda fonte de verdade ativa para regras internas de governança; a auto evolução só atualiza o README quando altera a identidade pública, caminho do leitor, entrada principal ou navegação de manutenção. Após a conclusão, execute scripts/audit_readme.py e verifique na superfície de renderização real.

Governança de Licenças

Primeiro, leia references/license-governance.md. Após o usuário confirmar o plano específico, leia references/license-rollout.md e implemente; solicitações somente leitura param no limite de conteúdo, dependências de terceiros e comparação de planos.

Logs Humanizados

Leia references/log-audit-standard.md. Verifique a produção, contexto, armazenamento, leitura e resultado final de visualização ao longo de uma operação real; não substitua a cadeia de eventos completa por um único exemplo bonito.

Perfil de Ambiente do Usuário e Ambiente de Execução

Leia references/user-environment-governance.md. O schema do perfil é mantido por assets/user-environment/profile.schema.json e as operações determinísticas por scripts/user_environment_profile.py. inspect, plan, verify e resolve mantêm os limites de somente leitura ou consumo correspondentes; apply --write requer autorização explícita de gravação de perfil e não autoriza automaticamente instalação, download ou modificação de configurações do sistema.

Auditoria Abrangente do Projeto

Leia references/project-audit.md. Quando o usuário pergunta sobre o grau de conclusão do plano de implementação, primeiro estabeleça um livro-razão de conformidade item por item a partir do plano original; após a autorização de reparo, regenere uma nova revisão completa a partir do plano original e do contrato atualmente aceito, sem reutilizar marcadores de conclusão antigos ou inferir escopo do plano a partir de testes existentes. Para uma verificação abrangente, primeiro estabeleça um livro-razão de cobertura com todas as dimensões aplicáveis de acordo com a forma do projeto e, em seguida, carregue as especialidades exigidas por essas dimensões; não preencha o escopo de revisão retroativamente com base apenas nos problemas já descobertos. Auditorias somente leitura não executam governança automaticamente. Quando a avaliação da eficácia do usuário for necessária, adicione references/project-effectiveness-review.md; quando a verificação da experiência da tarefa for necessária, adicione references/task-experience-audit.md.

Recursos de Modelo de Plataforma

Leia conforme necessário ao processar o tipo de projeto correspondente:

Aplicativo desktop: references/desktop-app-governance.md
Tauri v2 + Vue: references/tauri-vue-governance.md
Workspace de arquivo local: references/local-file-workspace-governance.md

Esses recursos são métodos ativos, não significam que o projeto já adotou o modelo; apenas um .project-steward/project.json adotado explicitamente e lido por consumidores formais constitui o estado do modelo do projeto.

Saída e Conclusão

A saída deve primeiro fornecer a conclusão e, em seguida, explicar o escopo, evidências, itens desconhecidos e próxima ação. A análise não deve ser escrita como se já tivesse sido implementada; a verificação estrutural não deve ser escrita como se a cadeia de usuário real estivesse estabelecida; a verificação de comportamento da tarefa atual não deve ser escrita como se uma inicialização a frio independente já tivesse sido comprovada.

Quando houver um gráfico de impacto, ele deve incluir pelo menos produtores, limites de transporte ou armazenamento, consumidores, resultado final do usuário, fonte única de verdade, condições de saída do caminho antigo e ponto de entrada de aceitação. Ao envolver vários resultados históricos, relate a causa principal, mecanismo de sucesso, lacuna de capacidade, proprietário formal e nível de verificação para cada um.

Somente quando o roteamento ativo, método correspondente, consumidores formais, testes determinísticos e a cadeia de usuário real aprovada nesta rodada estiverem todos consistentes, declare a conclusão.

Project Steward

O que é Project Steward?

Perguntar na sua IA favorita

Documentação