DLM Load 7 Portable

O que DLM Load 7 Portable faz?

Propósito

Bloqueie um repositório e carregue seu próprio contrato, restrições, tarefa ativa, arquivos de manifesto e âncoras de código fonte. Este skill pessoal define o método de carregamento; o estado do repositório permanece inteiramente de propriedade do repositório.

Portão de governança de resultado

Aplique a Governança de Resultado DLM compartilhada. Leia-a antes de load-and-continue, antes de tratar uma lacuna de contexto como bloqueante, ou sempre que o carregamento alimentar uma revisão formal, delegação, lançamento ou outra decisão de estado externo.

• Trate o carregamento como uma verificação combinada de identidade/escopo seguida dos fatos mínimos necessários para a próxima decisão material.
• Não repita a Inicialização de Sessão, recongele a autoridade ou gere artefatos do plano de controle quando a identidade do repositório/tarefa já estiver estável.
• load-and-continue não ignora a governança: antes da primeira escrita substantiva, delegação com capacidade de execução, ação externa ou mutação de estado/recurso, confirme que a Linha de Base de Aceitação aplicável está Congelada por seu proprietário ou que uma autorização de sessão explícita equivalente fornece o mesmo alvo, critérios, Escopo Autorizado, evidências e linha de parada.
• Uma lacuna de contexto bloqueia apenas quando um contrato aplicável a marca como necessária e sua ausência impede materialmente a reivindicação atual ou ação segura. A obsolescência administrativa não relacionada é relatada para encerramento orientado pelo consumidor, não é permitida atrasar o trabalho alvo.
• Documentação, código fonte, evidências de tempo de execução e estado de coordenação permanecem separados; carregue a camada que se ajusta à decisão em vez de usar uma como proxy para outra.

Resolução de repositório

1. Prefira uma raiz de repositório explicitamente fornecida pelo usuário.
2. Caso contrário, use a raiz Git mais próxima que contenha o doc_llm relevante.
3. Em um monorepo ou ambiguidade de checkout aninhado, inspecione as identidades candidatas doc_llm/dlm.json e pergunte apenas se o alvo ainda não puder ser determinado com segurança.
4. Leia o AGENTS.md, doc_llm/dlm.json e doc_llm/README.md aplicáveis antes de interpretar caminhos ou status.
5. Nunca carregue o DLM de um projeto vizinho porque é familiar da memória ou de uma conversa anterior.

Se o projeto tiver um contrato, o repository_root, doc_llm_root, project_id, status e regras de compatibilidade declarados são autoritativos. Caminhos de skill pessoal nunca são arquivos de contexto do projeto.

Modos de intenção

• load-only: o usuário pediu apenas para inspecionar, resumir ou avaliar contexto. Permaneça somente leitura e pare após o relatório de contexto.
• load-and-continue: o usuário já solicitou planejamento, implementação, revisão ou diagnóstico. Carregue primeiro, depois continue a tarefa autorizada sem pedir uma confirmação redundante.

Carregar é uma fase de fluxo de trabalho, não um modo de plataforma e não autoridade de mutação.

Inicialização de sessão

Na primeira entrada, leia o contrato/README e as restrições BRIEF/L0 aplicáveis; reutilize-os enquanto a identidade do repositório e as restrições relevantes permanecerem estáveis. Para uma tarefa nomeada ou já bloqueada, vá diretamente para sua Epic/Subtarefa e entradas de manifesto necessárias. Leia o backlog/índice apenas para descobrir propriedade, resolver dependências ou escolher trabalho dentro de uma fila já autorizada. Um diagnóstico ou pergunta ad hoc não autoriza seleção ou execução de um item de backlog não relacionado.

Quando a seleção de tarefa fizer parte da solicitação do usuário ou de uma fila já autorizada, selecione deterministicamente:

1. Epic/Subtarefa especificada pelo usuário;
2. tarefa já bloqueada na conversa atual e ainda ativa;
3. tarefa em andamento ordenada pelas regras de backlog/prioridade/ID do repositório;
4. tarefa planejada pronta para dependência usando a mesma ordem;
5. tarefas bloqueadas são relatadas com sua condição de liberação, não tratadas como executáveis.

Se os candidatos permanecerem empatados após aplicar as regras do repositório, mostre o menor conjunto útil de candidatos em vez de adivinhar por carimbos de data/hora de arquivo ou ler cada tarefa histórica.

Identidade atual e retomada

• Quando o projeto fornecido pelo usuário não tiver metadados Git, bloqueie seu diretório explícito mais seu próprio contrato DLM. Relate o estado Git como indisponível; nunca adote um repositório pai ou vizinho para fabricar uma identidade.
• Use Epic/Subtarefa como a identidade canônica da tarefa. Resolva uma dependência curta antiga dentro de sua Epic proprietária primeiro, depois apenas se globalmente única. Um ID simples compartilhado por várias Epics precisa de desambiguação; não deve escolher silenciosamente a primeira correspondência.
• A tabela Meta principal atual (ou seção ## Meta explícita) é autoritativa. Logs históricos, planos arquivados e uma entrada Congelada antiga não substituem o status atual ou a aceitação. Leia evidências históricas apenas quando a próxima decisão precisar delas.
• Prefira um comando next / context existente de propriedade do repositório quando ele fornecer identidade, dependências, bloqueadores e ordem de leitura. Não instale um novo comando meramente para carregar contexto ou tratar sua saída como autoridade de mutação.

Mergulho profundo em tarefa

1. Leia a tarefa e localize <context_manifest>.
2. Para esquema 2, exija project correspondente, caminhos / relativos ao repositório e um arquivo concreto por entrada.
3. Cada <file> tem path, intent e required; section e defer são opcionais.
4. Rejeite caminhos absolutos, .., diretórios, repositórios irmãos, raízes de skill pessoal e arquivos de fluxo de trabalho .agents/skills como contexto de tarefa.
5. Arquivos ausentes exigidos pelo contrato de tarefa atual bloqueiam o mergulho/análise profunda afetado. Arquivos opcionais ausentes, ou registros administrativos não relacionados sem consumidor atual, tornam-se avisos.
6. defer="true" é válido apenas com required="false"; carregue-o apenas quando a decisão atual precisar dele.
7. Leia arquivos independentes em paralelo quando útil. Honre section carregando a seção relevante precisamente.

Para manifestos legados, siga a regra de compatibilidade do repositório e relate a lacuna. Não migre silenciosamente durante o carregamento.

Contexto focado em decisão e retomada

Após as entradas necessárias, organize a leitura adicional em torno da próxima questão material: restrições aplicáveis, evidências e contraevidências, fatos ausentes e a próxima entrada de código fonte. Relevância por si só não estabelece suficiência. Em uma retomada real, preserve a última evidência aplicável e rotas com falha excluídas; atualize dependências alteradas em vez de repetir a Inicialização de Sessão.

Para reutilização de evidências, mudança de conhecimento L2 ou falha repetida, leia a seção relevante de Evidências e decisões. Para um conjunto útil de mudanças explicitamente identificadas, scripts/dlm_impact.py --repo-root <repo> --changed-file <arquivo-relativo-ao-repo> --json pode retornar candidatos de revisão L2 somente leitura, incluindo propagação opcional de depends_on. Ele não certifica validade do conhecimento nem substitui entradas de manifesto necessárias. Não execute para cada leitura de rotina.

Ancoragem de código fonte

• Use rg, navegação de símbolos, arquivos de projeto, testes, logs e evidências geradas para localizar a verdade da implementação.
• Comece com leituras estreitas de código fonte. Leia arquivos completos quando ciclo de vida, serialização, máquina de estados ou comportamento entre membros tornar excertos locais inseguros.
• Distinga afirmações de documentação, fatos de código fonte, evidências de tempo de execução e inferência não resolvida.
• Se DLM e código fonte discordarem, relate a incompatibilidade e continue do código fonte/evidência atual a menos que a tarefa seja explicitamente focada em documentação.

Carregamento ad-hoc

Durante a execução, encaminhe através do L1 global / L1 de domínio para o menor L2 relevante e âncoras de código fonte. Não repita toda a Inicialização de Sessão quando apenas uma decisão de domínio precisar de mais contexto.

Validação e saída

Execute a verificação de saúde do repositório quando a integridade do contrato/manifesto for importante para a próxima decisão ou o usuário solicitou validação DLM. Use o médico genérico como evidência de contrato de suporte, não como um ritual:

python -B -X utf8 <skill-dir>/scripts/dlm_doctor.py --repo-root <repo> --require-contract

Classifique falhas contra o alvo e contrato atuais. Uma falha relevante de contrato/caminho pode bloquear a ação DLM afetada; um aviso administrativo não relacionado ou pré-existente não pode invalidar um contexto de engenharia de outra forma suficiente.

Relate identidade do repositório/projeto, tarefa selecionada e base de seleção, restrições carregadas e âncoras de código fonte, contexto ausente ou desatualizado, o impacto material de qualquer lacuna bloqueante e se a tarefa original continuará agora. Uma vez que a próxima decisão tenha contexto suficiente, pare de carregar e retorne o esforço para esse trabalho.

Brief opcional do Ledger v2 (scripts/dlm.py brief)

Ao carregar uma Epic que usa ledger.json, execute python -X utf8 <skill-dir>/scripts/dlm.py brief <E> <S> (ou dlm.py status) para renderizar o resumo da tarefa, obrigações ativas, hipóteses não resolvidas e estado de checkpoint anterior junto com dlm_impact.py.