Lujker/road-map-journal

Roadmap e diário de trabalho

Mantenha um plano atual útil e um registro rastreável de decisões sem impor uma nova estrutura. Siga as instruções do usuário e as convenções do projeto. Preserve nomes, identificadores, idioma, links, alterações não confirmadas e conteúdo não relacionado existentes. Para um novo plano, use o idioma que o usuário especificar ou indicar razoavelmente; pergunte se não estiver claro. Não imponha um idioma.

Quando usar

Use para solicitações sobre roadmap, plano de desenvolvimento, fila, diário de trabalho, status de item ou continuação do trabalho planejado. Exemplos incluem "what is next on the roadmap?", "continue the agreed item", «дорожная карта», «план разработки», «дневник разработки», «что дальше по плану?» e «продолжай разработку по плану». Determine o escopo solicitado a partir do contexto; uma pergunta de status é somente leitura.

Descubra primeiro

Identifique a raiz do projeto e leia suas instruções. Localize roadmaps, filas, anotações de itens e documentos de handoff existentes; nomes e locais variam. Leia o item relevante, seus critérios de aceitação, fila atual e notas vinculadas. Verifique a implementação relevante, o estado de controle de versão se disponível e as evidências quando a solicitação precisar de uma avaliação do estado atual. Não presuma Git, um layout de diretório específico ou um vocabulário de status específico. Para múltiplos repositórios, siga os links existentes; pergunte por uma localização autoritativa inacessível em vez de inventar uma substituição.

Selecione o modo implícito pela solicitação:

• Somente leitura: Responda a partir dos documentos e evidências relevantes. Distinga alegações registradas de fatos verificados de forma independente; não faça edições.
• Inicialização: Se nenhum plano existir, discuta a forma de trabalho desejada pelo proprietário e proponha uma estrutura, local, escopo, itens iniciais e ordenação adequados; inclua tracks, funções de agente e cartões iniciais quando relevante. Para exploração mais profunda, use grill-me se disponível e apropriado; se ausente, ofereça-se para instalá-lo, mas não instale sem permissão ou bloqueie o fluxo de trabalho. Caso contrário, facilite você mesmo uma discussão estruturada concisa, com recomendações para escolhas não resolvidas. Obtenha consentimento informado do usuário antes de criar arquivos; não invente prioridades ou compromissos.
• Adoção: Se o material de planejamento já existir, use-o no local. Quando o proprietário solicitar uma revisão substancial, use a mesma discussão estruturada opcional da inicialização, adaptada ao que não está resolvido. Explique qualquer novo arquivo, migração ou reescrita substancial proposta e obtenha consentimento informado primeiro. Não crie silenciosamente uma fonte paralela de verdade.
• Retomada: Leia a diretiva mais recente, fila ativa, anotações de itens e estado atual relevante. Resolva instruções contraditórias ou desatualizadas com base em evidências atuais e na decisão mais recente do usuário; pergunte se um conflito relevante persistir. Se o item ainda não estiver selecionado ou delegado, concorde em um antes da implementação. Um plano salvo ou aprovação para documentar não é autorização para iniciar o trabalho.
• Atualização: Faça as alterações solicitadas e com escopo definido nos registros existentes. Mantenha o status do item, o trabalho restante e as entradas de fila afetadas consistentes; preserve o histórico e a ordenação não relacionada. Para um novo arquivo ou reescrita substancial, explique a alteração proposta e obtenha consentimento informado primeiro. Uma solicitação limitada a um item não autoriza implementar ou reescrever o restante do plano.

Registrar e reconciliar

Use o arranjo estabelecido do projeto. Normalmente, um roadmap resume itens e sua ordem atual; um diário contém decisões, descobertas, evidências e histórico. Vincule em vez de duplicar detalhes longos. Mantenha identificadores estáveis. Não exclua silenciosamente decisões ou trabalho cancelado: marque-os como substituídos ou cancelados com o motivo quando relevante.

Quando uma decisão, pausa ou ordem mudar, atualize os sumários atuais afetados e as instruções de próximo passo dentro do escopo autorizado; rotule instruções anteriores como históricas. Um plano pausado ou adiado não deve parecer uma instrução ativa para continuar. Não repriorize trabalho não relacionado apenas porque uma nota foi adicionada. Se uma correção necessária estiver fora do escopo autorizado, sinalize-a ao usuário em vez de expandir a edição.

A menos que o proprietário tenha autorizado um escopo mais amplo, trabalhe em um item de cada vez e não comece automaticamente o próximo. Uma subetapa concluída não completa o item pai; registre o restante. Mantenha o modo de trabalho separado de permissões e orçamentos: autorização para continuar não é permissão geral para ações de produção ou gravações externas. Mantenha a conclusão registrada, aceitação pendente do usuário e trabalho totalmente aceito distintos. Mantenha pontos de verificação concisos em handoffs, decisões, resultados verificados e bloqueadores, incluindo o que resta e como retomar; verifique ações em andamento incertas antes de repeti-las. Antes de uma atualização de vários arquivos em um checkout compartilhado, verifique o estado de controle de versão e os caminhos sujos imediatamente antes de escrever, aplique edições estreitas em conteúdo lido recentemente, preserve trabalho não relacionado e verifique as alterações no escopo sem confirmar ou publicar, a menos que autorizado.

Para trabalho que abrange vários itens, agentes ou sessões, tem um orçamento, ou onde o proprietário autoriza uma track ou modo contínuo, leia Trabalho de longa duração primeiro.

Status e evidências

Use o vocabulário de status do projeto. Se nenhum existir, sugira ABERTO, EM ANDAMENTO, BLOQUEADO, PARCIAL e CONCLUÍDO, com significados acordados para o projeto. Registre o status de acordo com os critérios de aceitação e evidências reais, não intenção ou alegação não fundamentada de um delegado. Para PARCIAL, nomeie o que resta e qualquer bloqueador. Mantenha as referências de status afetadas consistentes.

Registre as verificações realmente realizadas, seus resultados e escopo, e quem as executou quando relevante. As evidências podem ser históricas ou de outro executor; rotule sua fonte e aplicabilidade, e não implique que foram reexecutadas. Se alterações posteriores invalidarem uma verificação, identifique ou realize a verificação apropriada. Nunca invente comandos, resultados, contagens de teste, aprovações ou aceitação do usuário. Testes automatizados, código lançado e operação ao vivo são alegações diferentes: nunca infira aceitação ao vivo a partir de implementação ou testes. Se a aceitação necessária não ocorreu, mantenha PARCIAL ou o equivalente do projeto e declare o ambiente ou aprovação ausente.

Após uma edição autorizada, verifique o status afetado, a fila, os links e a consistência com as evidências e o escopo. Relate alterações, verificações realmente feitas e itens não resolvidos. Não reivindique verificação que não foi realizada.

Referências

• Templates genéricos — pontos de partida opcionais, adaptados ao projeto.
• Cenários — exemplos concisos de escolhas de modo e escopo.
• Trabalho de longa duração — tracks, pontos de verificação, pausa e parada, aceitação, orçamentos, checkouts compartilhados.
• Reconciliação multi-repositório — preserve o trabalho e distinga o estado registrado, Git e ativo entre checkouts.