DLM Load 7 Portable

Was macht DLM Load 7 Portable?

Zweck

Ein Repository sperren und seine eigenen Verträge, Einschränkungen, aktiven Aufgaben, Manifestdateien und Quellcodeanker laden. Diese persönliche Skill definiert die Lademethode; der Repository-Zustand bleibt vollständig dem Repository gehörig.

Ergebnis-Governance-Gate

Wende die gemeinsame DLM Outcome Governance an. Lies sie vor load-and-continue, bevor eine Kontextlücke als blockierend behandelt wird, oder wann immer das Laden eine formelle Überprüfung, Delegation, Freigabe oder eine andere externe Zustandsentscheidung speist.

• Behandle das Laden als eine kombinierte Identitäts-/Bereichssicherheitsprüfung, gefolgt von den minimalen Fakten, die für die nächste materielle Entscheidung benötigt werden.
• Wiederhole keine Sitzungsinitialisierung, friere keine Autorität neu ein und erzeuge keine Steuerungsebene-Artefakte, wenn die Repository-/Aufgabenidentität bereits stabil ist.
• load-and-continue umgeht nicht die Governance: Vor dem ersten substantiellen Schreibvorgang, der ausführungsfähigen Delegation, externen Aktion oder Zustands-/Ressourcenänderung bestätige, dass die anwendbare Akzeptanz-Baseline von ihrem Eigentümer eingefroren ist oder dass eine gleichwertige explizite Sitzungsautorisierung dasselbe Ziel, dieselben Kriterien, denselben autorisierten Bereich, dieselben Beweise und dieselbe Stopplinie liefert.
• Eine Kontextlücke blockiert nur, wenn ein anwendbarer Vertrag sie als erforderlich kennzeichnet und ihr Fehlen den aktuellen Anspruch oder die sichere Aktion materiell verhindert. Nicht zusammenhängende administrative Veraltung wird für die verbrauchergesteuerte Abschlussmeldung gemeldet, darf aber die Zielarbeit nicht verzögern.
• Dokumentation, Quellcode, Laufzeitbeweise und Koordinationszustand bleiben getrennt; lade die Ebene, die zur Entscheidung passt, anstatt eine als Proxy für eine andere zu verwenden.

Repository-Auflösung

1. Bevorzuge einen vom Benutzer explizit angegebenen Repository-Stamm.
2. Verwende andernfalls den nächsten Git-Stamm, der das relevante doc_llm enthält.
3. Bei Mehrfach-Repository- oder verschachtelten Checkout-Mehrdeutigkeiten überprüfe die Kandidaten-doc_llm/dlm.json-Identitäten und frage nur nach, wenn das Ziel immer noch nicht sicher bestimmt werden kann.
4. Lese die anwendbaren AGENTS.md, doc_llm/dlm.json und doc_llm/README.md, bevor Pfade oder Status interpretiert werden.
5. Lade niemals das DLM eines benachbarten Projekts, weil es aus dem Gedächtnis oder einem früheren Gespräch bekannt ist.

Wenn das Projekt einen Vertrag hat, sind die deklarierten repository_root, doc_llm_root, project_id, Status und Kompatibilitätsregeln maßgeblich. Persönliche Skill-Pfade sind niemals Projektkontextdateien.

Intent-Modi

• load-only: Der Benutzer bat nur darum, Kontext zu inspizieren, zusammenzufassen oder zu bewerten. Bleibe schreibgeschützt und stoppe nach dem Kontextbericht.
• load-and-continue: Der Benutzer hat bereits Planung, Implementierung, Review oder Diagnose angefordert. Lade zuerst, fahre dann mit der autorisierten Aufgabe fort, ohne nach einer redundanten Bestätigung zu fragen.

Laden ist eine Workflow-Phase, kein Plattform-Modus und keine Mutationsberechtigung.

Sitzungsinitialisierung

Beim ersten Eintritt lese den Vertrag/die README und die anwendbaren BRIEF/L0-Einschränkungen; verwende sie wieder, während Repository-Identität und relevante Einschränkungen stabil bleiben. Gehe bei einer benannten oder bereits gesperrten Aufgabe direkt zu ihrem Epic/Subtask und den erforderlichen Manifesteinträgen. Lese das Backlog/Index nur, um Eigentümerschaft zu entdecken, Abhängigkeiten aufzulösen oder Arbeit innerhalb einer bereits autorisierten Warteschlange auszuwählen. Eine Ad-hoc-Diagnose oder -Frage autorisiert nicht die Auswahl oder Ausführung eines nicht zusammenhängenden Backlog-Elements.

Wenn die Aufgabenauswahl Teil der Benutzeranfrage oder einer bereits autorisierten Warteschlange ist, wähle deterministisch:

1. benutzerspezifiziertes Epic/Subtask;
2. Aufgabe, die bereits im aktuellen Gespräch gesperrt und noch aktiv ist;
3. laufende Aufgabe, geordnet nach den Backlog-/Prioritäts-/ID-Regeln des Repositorys;
4. abhängigkeitsbereite geplante Aufgabe mit derselben Reihenfolge;
5. blockierte Aufgaben werden mit ihrer Freigabebedingung gemeldet, nicht als ausführbar behandelt.

Wenn Kandidaten nach Anwendung der Repository-Regeln gleichauf bleiben, zeige den kleinsten nützlichen Kandidatensatz an, anstatt nach Dateizeitstempeln zu raten oder jede historische Aufgabe zu lesen.

Aktuelle Identität und Wiederaufnahme

• Wenn das vom Benutzer bereitgestellte Projekt keine Git-Metadaten hat, sperre sein explizites Verzeichnis plus seinen eigenen DLM-Vertrag. Melde den Git-Status als nicht verfügbar; übernimm niemals ein übergeordnetes oder benachbartes Repository, um eine Identität zu fabrizieren.
• Verwende Epic/Subtask als kanonische Aufgabenidentität. Löse zuerst eine alte kurze Abhängigkeit innerhalb ihres besitzenden Epics auf, dann nur, wenn global eindeutig. Eine bloße ID, die von mehreren Epics gemeinsam genutzt wird, benötigt Disambiguierung; sie darf nicht stillschweigend den ersten Treffer auswählen.
• Die aktuelle führende Meta-Tabelle (oder ein expliziter Abschnitt ## Meta) ist maßgeblich. Historische Logs, archivierte Pläne und ein alter eingefrorener Eintrag überschreiben nicht den aktuellen Status oder die Akzeptanz. Lese historische Beweise nur, wenn die nächste Entscheidung sie benötigt.
• Bevorzuge einen vorhandenen repository-eigenen next/context-Befehl, wenn er Identität, Abhängigkeiten, Blocker und Lesereihenfolge bereitstellt. Installiere keinen neuen Befehl nur, um Kontext zu laden, und behandle seine Ausgabe nicht als Mutationsberechtigung.

Aufgaben-Tiefgang

1. Lese die Aufgabe und lokalisiere <context_manifest>.
2. Für Schema 2 erfordere passende project, repository-relative /-Pfade und eine konkrete Datei pro Eintrag.
3. Jede <file> hat path, intent und required; section und defer sind optional.
4. Lehne absolute Pfade, .., Verzeichnisse, benachbarte Repositorys, persönliche Skill-Wurzeln und .agents/skills-Workflow-Dateien als Aufgabenkontext ab.
5. Fehlende Dateien, die vom aktuellen Aufgabenvertrag als erforderlich gekennzeichnet sind, blockieren den betroffenen Tiefgang/Anspruch. Fehlende optionale Dateien oder nicht zusammenhängende administrative Aufzeichnungen ohne aktuellen Verbraucher werden zu Warnungen.
6. defer="true" ist nur mit required="false"" gültig; lade es nur, wenn die aktuelle Entscheidung es benötigt.
7. Lese unabhängige Dateien parallel, wo nützlich. Beachte section, indem du den relevanten Abschnitt präzise lädst.

Bei Legacy-Manifesten folge der Kompatibilitätsregel des Repositorys und melde die Lücke. Migriere nicht stillschweigend während des Ladens.

Entscheidungsfokussierter Kontext und Wiederaufnahme

Nach erforderlichen Eingaben organisiere das weitere Lesen um die nächste materielle Frage: anwendbare Einschränkungen, Beweise und Gegenbeweise, fehlende Fakten und der nächste Quelleneintrag. Relevanz allein begründet nicht die Ausreichendheit. Bei einer echten Wiederaufnahme behalte den letzten anwendbaren Beweis und ausgeschlossene fehlgeschlagene Wege bei; aktualisiere geänderte Abhängigkeiten, anstatt die Sitzungsinitialisierung zu wiederholen.

Bei Beweiswiederverwendung, sich änderndem L2-Wissen oder wiederholtem Fehlschlag lese den relevanten Abschnitt von Evidence and decisions. Für einen nützlichen Satz explizit identifizierter Änderungen kann scripts/dlm_impact.py --repo-root <repo> --changed-file <repo-relative-file> --json schreibgeschützte L2-Review-Kandidaten zurückgeben, einschließlich optionaler depends_on-Propagation. Es zertifiziert nicht die Gültigkeit von Wissen und ersetzt keine erforderlichen Manifesteingaben. Führe es nicht für jede routine Lektüre aus.

Quellcode-Ankerung

• Verwende rg, Symbolnavigation, Projektdateien, Tests, Logs und generierte Beweise, um die Implementierungswahrheit zu lokalisieren.
• Beginne mit schmalen Quellcode-Lektüren. Lese vollständige Dateien, wenn Lebenszyklus-, Serialisierungs-, Zustandsmaschinen- oder übergreifendes Mitgliederverhalten lokale Auszüge unsicher macht.
• Unterscheide zwischen Dokumentationsbehauptungen, Quellcode-Fakten, Laufzeitbeweisen und nicht aufgelösten Schlussfolgerungen.
• Wenn DLM und Quellcode uneins sind, melde die Diskrepanz und fahre mit dem aktuellen Quellcode/Beweis fort, es sei denn, die Aufgabe ist explizit dokumentationsorientiert.

Ad-hoc-Laden

Während der Ausführung leite durch globales L1/Domain-L1 zum kleinsten relevanten L2 und den Quellcode-Ankern. Wiederhole nicht die gesamte Sitzungsinitialisierung, wenn nur eine Domain-Entscheidung mehr Kontext benötigt.

Validierung und Ausgabe

Führe die Repository-Gesundheitsprüfung durch, wenn die Vertrags-/Manifestintegrität für die nächste Entscheidung wichtig ist oder der Benutzer eine DLM-Validierung angefordert hat. Verwende den generischen Doctor als unterstützenden Vertragsbeweis, nicht als Ritual:

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

Klassifiziere Fehler in Bezug auf das aktuelle Ziel und den Vertrag. Ein relevanter Vertrags-/Pfadfehler kann die betroffene DLM-Aktion blockieren; eine nicht zusammenhängende bestehende oder administrative Warnung kann einen ansonsten ausreichenden technischen Kontext nicht ungültig machen.

Melde Repository-/Projektidentität, ausgewählte Aufgabe und Auswahlbasis, geladene Einschränkungen und Quellcode-Anker, fehlenden oder veralteten Kontext, die materielle Auswirkungen einer blockierenden Lücke und ob die ursprüngliche Aufgabe nun fortgesetzt wird. Sobald die nächste Entscheidung ausreichenden Kontext hat, stoppe das Laden und gib die Bemühungen an diese Arbeit zurück.

Optionaler v2 Ledger Brief (scripts/dlm.py brief)

Wenn ein Epic geladen wird, das ledger.json verwendet, führe python -X utf8 <skill-dir>/scripts/dlm.py brief <E> <S> (oder dlm.py status) aus, um den Aufgabenbrief, aktive Verpflichtungen, ungelöste Hypothesen und vorherigen Checkpoint-Zustand zusammen mit dlm_impact.py darzustellen.