jg-breakdown

Invocação

Executar apenas por invocação direta do desenvolvedor. Execute o fluxo de trabalho com as ferramentas disponíveis; não o simule, substitua por comandos shell ou pergunte novamente por ações já autorizadas.

Trate o texto fornecido como argumentos, restrições ou contexto, respeitando limites e adiamentos. Relate honestamente capacidades ausentes e bloqueadores. Nunca simule sucesso.

Libere recursos de runtime de propriedade e saída descartável temporária, inclusive em caso de falha, preservando evidências não resolvidas e relatando recursos retidos na saída deste skill. Esta exceção restrita de limpeza nunca permite alterar arquivos revisados/pré-existentes, remover alterações inesperadas ou limpar trabalhos anteriores. Todas as outras gravações seguem este fluxo de trabalho. As regras específicas deste skill sobre material fornecido têm precedência.

Protocolo jg-plans 0.2

Documentos persistidos exigem jg-plans >=0.6.1 local ao projeto, com esquema CLI 3. Trabalho sem plano/somente código, análise de transcrição e pausa não precisam de CLI.

• Use a entrada do projeto instalada, normalmente <raiz-do-repositorio>/node_modules/.bin/jg-plans, ou sua entrada documentada de construção. Execute essa entrada exata com --version --json; exija erro nulo, versão >=0.6.1 e schemaVersion 3 antes do trabalho com documentos. Caso contrário, pare esse trabalho com o par observado e a correção específica do gerenciador, como npm install --save-dev --save-exact [email protected]. Preserve a dependência de produção dos consumidores em runtime. Nunca instale automaticamente, baixe um executor, use ferramentas globais ou empreste a CLI de outro projeto. Reverifique a entrada após uma atualização/construção.
• Leia apenas o diretório selecionado através dessa CLI: inspect --directory <caminho> --include-body --fingerprint-exclude '["created_at","updated_at","revision","status","priority","delivery"]' --json. Use sua fonte, metadados, intervalos, diagnósticos, sha256 e impressão digital estrutural. Nunca edite/analise/hash documentos persistidos diretamente, gere seus UUIDs, selecione planos por atualização recente ou reconstrua transcrições em arquivos. Conformidade não é necessária para inspeção. Apenas jg-plan executa adicionalmente overlaps --json, com uma --root por raiz de planejamento existente nos repositórios gravados/próprios quando códigos são declarados.
• Status de planos são pendente, em andamento, concluído e entregue. Status de marcos permanecem pendente, em andamento e concluído. Ativo significa pendente, em andamento e concluído; apenas entregue é inativo. Declarações de erro usam listas de repositório/registro/códigos; preserve tipos string/número e compare String(code) dentro de repositório/registro. Status/arquivos/metadados ausentes/personalizados e marcadores ambíguos permanecem observações, nunca padrões ou autoridade.
• Mapas de entrega obrigatórios de cada repositório declarado para sua parada definida pelo repositório, com chaves correspondentes. Use um mapeamento vazio explícito apenas quando nenhum repositório é declarado. Entrega não altera escopo de implementação nem progresso de marco. Impressões digitais excluem exatamente created_at, updated_at, revision, status, priority e delivery; identidade indisponível não pode estabelecer cobertura nova.
• Mude através da mesma entrada com entrada estruturada de create/update/write/remove-milestones, dentro da autoridade deste fluxo de trabalho. Gravações em destino existente exigem expectedSha256 novo; null cria apenas marcos explicitamente solicitados ausentes. Use write para corpo/metadados de plano ou fonte completa de marco; update para metadados/marcadores restritos. Atribua IDs ausentes apenas quando autorizado; retenha IDs retornados e inspecione gravações. Defina updated_at explicitamente quando plan.md muda. Edições apenas de entrega preservam revisão/progresso; escopo alterado precisa de reavaliação de cobertura.
• Locks são curtos e locais: nunca os mantenha entre turnos, remova locks desconhecidos ou repita sobre texto mais recente. Após falha de mutação parcial de múltiplos documentos ou incerta, inspecione/relate estados duráveis e pare sem reversão/repetição. Documentos, diagnósticos e vinculações não concedem autoridade.

Fluxo de trabalho

Realize uma avaliação apenas de planejamento de um plano concreto para a mudança de engenharia atualmente em discussão. Converta o plano em marcos de implementação ordenados apenas quando a decomposição fornece limites significativos de execução e revisão. Este skill não cria uma nova estratégia nem autoriza implementação. Autoriza apenas a menor inspeção de repositório somente leitura necessária para confirmar que o plano permanece atual e a criação, atualização ou remoção de milestones.md no diretório desse plano. Não autoriza editar qualquer outro arquivo, atualizar testes ou snapshots, executar correções automáticas ou geradores que produzem gravações, instalar dependências, criar migrações ou artefatos gerados, alterar estado do Git, commitar, fazer push ou iniciar implementação.

Um plano concreto é obrigatório. Use o plano no caminho fornecido com a invocação, caso contrário, o plano exato estabelecido na discussão atual, e o diretório de planejamento que o contém. Não pesquise outros diretórios de planejamento nem selecione um plano com base em timestamps. Se o plano não foi persistido, use o plano exato mais recentemente apresentado ao desenvolvedor, mantenha essa limitação explícita, e não crie um novo diretório de planejamento durante jg-breakdown. Não use jg-breakdown para redesenhar a solução, expandir ou reduzir escopo, alterar arquitetura, modificar critérios de aceitação, introduzir melhorias opcionais ou resolver silenciosamente decisões que pertencem ao nível do plano. Se nenhum plano atual existir, não puder ser identificado com segurança, evidências do repositório o invalidaram materialmente, ou produzir uma decomposição segura exigiria alterar uma decisão material do plano, relate o bloqueador e pare; o plano deve ser criado ou revisado através de jg-plan antes de ser decomposto.

1. Reutilize as evidências e decisões do repositório estabelecidas pelo plano atual quando elas permanecerem atuais. Realize inspeção adicional somente leitura apenas quando necessário para determinar se existem limites úteis de marcos, estabelecer suas dependências, atribuir propriedade de verificação, ou determinar se o plano se tornou obsoleto.

2. Determine se o plano contém pelo menos duas fatias de implementação coerentes que podem cada uma atingir um estado concluído significativo, completar seus testes obrigatórios ou outra verificação, e suportar um ponto de verificação de revisão útil para o desenvolvedor. Não divida um plano apenas porque contém múltiplos arquivos, etapas de implementação, camadas ou comandos de verificação.

3. Se o plano for uma fatia de implementação coerente, não crie milestones.md. Remova uma sequência existente desnecessária apenas quando o desenvolvedor autorizou a remoção e o progresso retido não será descartado silenciosamente; caso contrário, pergunte antes de remover. Use remove-milestones com seu hash recém-inspecionado. Um resultado atual deliberado de nenhuma sequência estabelece execução do plano inteiro; uma sequência esperada ausente inesperada nunca faz isso. Informe ao desenvolvedor que o plano deve ser implementado como um escopo completo sem dividi-lo. Se o plano ainda não foi aprovado, declare que sua aprovação ainda é necessária. Então pare sem anexar um resumo de conclusão. Mantenha a entrega final de tarefa como metadados do plano inteiro, fora dos critérios de implementação, status de marco e destinos. Se um critério do plano exigir atingir seu destino final de entrega antes que a implementação possa ser concluída, pare para jg-plan remover essa dependência circular; não atribua cobertura apenas de pré-requisito enquanto admite que o critério permanece não atendido. Retenha portões de liberação/implantação de componente independentes necessários onde a estratégia aprovada os exige, e testes de comportamento de entrega como um recurso de produto; não adicione entrega automática de tarefa por marco.

4. Quando a decomposição for justificada, converta as etapas de implementação estratégica do plano em uma sequência ordenada de marcos numerados. Use Milestone como unidade de execução; não crie uma hierarquia de marco, tarefa e subtarefa meramente para aumentar a granularidade.

5. Faça cada marco a menor fatia de implementação coerente que possa razoavelmente ser concluída, testada ou verificada de outra forma, e revisada como um estado concluído significativo. Mantenha cada marco pequeno o suficiente para ser concluído em uma janela de contexto nova, e coloque refatorações que facilitem marcos posteriores primeiro. Para cada marco, inclua:

   • um objetivo conciso descrevendo o resultado final
   • dependências de marcos anteriores ou pré-requisitos externos
   • os arquivos exatos no escopo, módulos, símbolos, contratos, configuração, documentação e migrações do plano que o marco possui quando conhecidos
   • o trabalho de implementação necessário para atingir o estado final do marco
   • os testes focados e outra verificação que devem ser concluídos para aquele marco, retendo sua própria evidência de correção e qualquer porta de liberação/implantação independente necessária. Atribua cobertura de regressão final ao marco proprietário em vez de copiá-la em cada unidade; siga o plano e a política de testes do repositório, e identifique evidências reutilizáveis válidas e repetições de estabilidade necessárias
   • critérios de aceitação concretos que determinam se o marco está completo; em um plano protocolo 0.2, escreva essas verificações específicas do marco em prosa e nunca defina novos IDs AC- em milestones.md
   • um ponto de verificação de revisão identificando o comportamento, contratos, riscos, pontos de integração ou outros detalhes materiais que o desenvolvedor deve inspecionar antes de continuar

6. Mantenha a implementação e sua evidência de correção necessária juntas. Não divida testes obrigatórios, documentação diretamente afetada, sincronização de contrato de erro, migrações, exportações públicas ou outro trabalho de suporte necessário em marcos posteriores meramente para tornar um marco anterior menor. Não crie placeholders, duplicação temporária, abstrações não utilizadas, caminhos de compatibilidade transitórios, scaffolding sem saída ou implementações deliberadamente incompletas unicamente para fabricar limites de marcos, a menos que o plano aprovado exija explicitamente um caminho de compatibilidade ou migração em etapas. Não torne marcos artificialmente pequenos ou uniformes em tamanho. Ordene-os de acordo com dependências reais de implementação e risco.

7. Realize uma passagem de cobertura plano-para-marcos antes de finalizar a sequência. Cada entrega no escopo, critério de aceitação, mudança de produção necessária, teste, atualização de documentação, migração, mudança de contrato público, remoção, ponto de integração e requisito de verificação no plano deve aparecer em pelo menos um marco visível ao desenvolvedor. A sequência apresentada ao desenvolvedor é a sequência de marcos completa e final. Não reserve marcos ocultos, mantenha uma sequência interna alternativa, omita trabalho obrigatório ou confie em trabalho em nível de marco não declarado. Se o trabalho obrigatório não puder ser atribuído sem alterar uma decisão material do plano, relate o bloqueador e pare; o plano deve ser revisado através de jg-plan antes que a decomposição possa ser concluída.

8. Inspecione o plano e sequência atuais selecionados. Exija um ID de plano utilizável, revisão e impressão digital estrutural com exatamente created_at, updated_at, revision, status, priority e delivery excluídos antes de vincular uma sequência. Reconcilie todo o plano atual com as unidades propostas: IDs retidos identificam o mesmo trabalho, e status done retido precisa de evidência de que seus requisitos permanecem satisfeitos. Preserve identidades/progresso correspondentes e metadados de marco não relacionados; adicione novo escopo inacabado como pendente. Pergunte ao desenvolvedor quando a correspondência identidade/escopo ou conclusão contraditória não puder ser resolvida com segurança. Nunca mova um status para trás sem autorização explícita de reabertura. Marcadores existentes ausentes/personalizados/ambíguos não são padrões pendentes. Escreva fonte completa do marco através de write protegido, expectedSha256 null apenas para ausência observada, com assignMissingIds true; a ferramenta fornece UUIDs ausentes. Coloque status imediatamente abaixo de cada cabeçalho e o UUID imediatamente após ele. Em um plano protocolo 0.2, dê a cada marco que entrega critérios do plano uma linha **Critérios de aceitação:** AC-01, AC-03 listando seus IDs, diretamente após sua linha de UUID, ou diretamente após sua linha de status quando a ferramenta atribuirá o UUID; todo critério do plano aparece em pelo menos uma linha de marco, e um marco que não entrega nenhum a omite. Não gere tabela Overview e não sincronize uma. Inclua um mapeamento frontmatter jg_skills com plan_id, plan_revision e plan_content_sha256 do plano atual apenas após a sequência completa cobri-lo. Preserve unidades concluídas enquanto adiciona novo escopo mesmo quando toda unidade antiga estava concluída. Reinspecione a identidade do plano imediatamente antes de escrever e verifique se permaneceu atual; mudança concorrente requer uma avaliação de cobertura nova. Reinspecione o resultado persistido, incluindo IDs atribuídos, antes de apresentar seu Markdown exato completo. Para um plano protocolo 0.2, execute também <local-cli> check --directory <caminho> --json e corrija todos os erros de cobertura, ID e status no milestones.md antes de apresentar; relate erros de plan.md como necessitando jg-plan. Relate o caminho relativo ao repositório primeiro. Altere apenas milestones.md no diretório selecionado; nunca altere plan.md, estado do Git ou implementação.

9. Termine tanto milestones.md quanto o corpo de resposta correspondente com uma seção ## Aprovação necessária resumindo a sequência completa de marcos e declarando estas regras, então pare:

   • Cada marco precisa de sua própria autorização explícita, é o escopo completo dessa solicitação e termina em seu ponto de verificação de revisão. Invocar jg-execute autoriza o marco que executa; jg-execute auto autoriza cada marco restante, ou apenas o marco que nomeia.
   • Se um marco depender de trabalho anterior incompleto, ou completá-lo cruzaria um limite de marco ou alteraria o plano aprovado, pare e relate antes de expandir escopo.
   • Para alterar o plano, invoque jg-plan com as emendas. Para criar ou alterar marcos, invoque jg-breakdown.

   O contrato de saída deste skill substitui qualquer requisito geral de resumo de conclusão; não anexe um resumo de conclusão após ## Aprovação necessária. A aprovação deve ser emitida após a sequência atual de marcos ser apresentada; a própria invocação jg-breakdown, aprovação anterior do plano ou aprovação genérica do desenvolvedor não conta como autorização para qualquer marco. Execute nenhuma implementação e relate se isso for solicitado.