DeepSeek-Harness-Praxis: zwei überprüfbare Reparaturen

Was tatsächlich geprüft wurde

Vor dem Prompt die Grenze festlegen

1. 01

   Mit einer bekannten Laufzeit beginnen

   Den Schnellstart für 0.1.3-alpha.1 und den fixierten Commit nutzen. Modell unter Settings → Models wählen. Zugangsdaten gehören in die Anbieter-Konfiguration, nicht in Prompts oder Testbeispiele.

2. 02

   Projekt und Laufzeit trennen

   Ein eigenes Übungsverzeichnis anlegen und in der Web UI auswählen. Die offizielle Quelllaufzeit nicht in dieser Website oder unter einem Projekt mit inkompatiblen node_modules in übergeordneten Verzeichnissen installieren.

3. 03

   Die erste Aufgabe klein halten

   Wirksame Sandbox und Freigaben prüfen. Im Wegwerfprojekt nur den nötigen Auftrag ausführen; für drei Dateien keine Plugins oder Abhängigkeiten hinzufügen.

Ein kleines Projekt mit sichtbarem Fehler anlegen

Verwenden Sie Node.js 24 und ein Bash-Terminal in einem neuen Wegwerfverzeichnis: Bash unter macOS/Linux, Git Bash oder WSL unter Windows. harness-lab darf noch nicht existieren. Das Beispiel benötigt keine npm-Abhängigkeiten, Konten, privaten Daten oder Produktionsdateien. Das vereinfachte CSV enthält keine Kommas in Anführungszeichen; es ist keine Übung für einen allgemeinen CSV-Parser.

create_harness_lab() {
mkdir harness-lab || return
cd harness-lab || return
cat > orders.csv <<'CSV'
id,status,cents
A,paid,1200
B,refunded,700
C,paid,800
D,pending,400
CSV
cat > report.mjs <<'JS'
export function totalPaid(csv) {
  const rows = csv.trim().split(/\r?\n/).slice(1);
  return rows.map(row => row.split(','))
    .filter(([, status]) => status !== 'pending')
    .reduce((sum, [, , cents]) => sum + Number(cents), 0);
}
JS
cat > report.test.mjs <<'JS'
const { default: assert } = await import('node:assert/strict');
const { readFileSync } = await import('node:fs');
const { default: test } = await import('node:test');
const { totalPaid } = await import('./report.mjs');
const csv = readFileSync(new URL('./orders.csv', import.meta.url), 'utf8');
test('only paid orders count', () => assert.equal(totalPaid(csv), 2000));
test('refunds alone count as zero', () => assert.equal(totalPaid('id,status,cents\nB,refunded,700\n'), 0));
test('an empty ledger counts as zero', () => assert.equal(totalPaid('id,status,cents\n'), 0));
JS
cp report.mjs report.original.mjs
node --test report.test.mjs
}
create_harness_lab

Beim ersten Lauf müssen zwei Prüfungen scheitern und eine bestehen. Der Fehler zählt die 700 Cent einer erstatteten Bestellung mit: 2700 statt 2000. Die Regel lautet: Nur Zeilen mit Status paid zählen; refunded und pending tragen null bei. Alle Beträge sind ganze Cent.

Zuerst eine reproduzierbare Diagnose verlangen

Untersuche ausschließlich orders.csv, report.mjs und report.test.mjs, ohne Dateien zu ändern. Erkläre die Testregel, benenne die erstattete Zeile und führe node --test report.test.mjs aus. Warum liefert der Filter 2700 statt 2000? Wenn der Befehl nicht ausführbar ist, melde das echte Umgebungsproblem und erfinde keine Ausgabe.

Eine hilfreiche Diagnose nennt Zeile B, status !== 'pending' und zwei fehlgeschlagene Assertions. „Danach sollte es funktionieren“ ist kein Testergebnis. Bei Vorschlägen für neue CSV-Bibliotheken oder große Umbauten auf vorhandenes Beispiel und Kriterien zurückführen.

Gezielte Reparatur erlauben und unabhängig prüfen

Behebe in diesem Wegwerfprojekt report.mjs, sodass totalPaid nur paid-Zeilen zählt. Lies zuerst orders.csv und report.test.mjs, führe node --test report.test.mjs aus und beschreibe den ursprünglichen Fehler. Verändere weder orders.csv noch report.test.mjs oder report.original.mjs. Installiere keine Pakete und greife nicht auf andere Verzeichnisse zu. Ändere die Implementierung minimal, wiederhole alle drei Prüfungen und berechne die Summe aus orders.csv. Nenne geänderte Datei, beobachtetes Testergebnis, Summe und Grenzen. Unterscheide einen Umgebungsfehler von einer fehlgeschlagenen Assertion.

node --test report.test.mjs
node --input-type=module -e "import {readFileSync} from 'node:fs'; import {totalPaid} from './report.mjs'; console.log(totalPaid(readFileSync('orders.csv','utf8')))"
diff -u report.original.mjs report.mjs

Erwartet werden drei bestandene Tests und separat die Summe 2000. Der Diff ersetzt üblicherweise den Filter durch status === 'paid'. Eine andere Lösung ist zulässig, wenn Regel und Tests erhalten bleiben. diff beendet sich bei Unterschieden mit Code 1: Hier ist das erwartet, kein Testfehler. Fehlendes Node oder verweigerte Rechte sind Umgebungsprobleme.

.filter(([, status]) => status === 'paid')

Die lokal ausgeführte Referenz ändert nur den Filter; Daten und Tests bleiben gleich. Testausgabe und separat berechnete Summe gemeinsam aufbewahren. Ein grüner Terminal-Screenshot ohne Befehl und Diff genügt nicht.

Zweite Aufgabe: geänderte Einstellung, altes Cache-Objekt

Die zwei zusätzlichen Dateien im selben Projekt anlegen. account bleibt demo, mode wechselt von light zu dark. Der Cache vergleicht nur account und liefert fälschlich das alte Objekt. Konfiguration ändern und eine konstruierte Instanz ungültig machen sind unterschiedliche Schritte.

create_cache_lab() {
test ! -e cache.mjs && test ! -e cache.test.mjs && test ! -e cache.original.mjs || return
cat > cache.mjs <<'JS'
let cached;
export function getSettings(config) {
  if (!cached || cached.account !== config.account) cached = { ...config };
  return cached;
}
JS
cat > cache.test.mjs <<'JS'
const { default: assert } = await import('node:assert/strict');
const { default: test } = await import('node:test');
const { getSettings } = await import('./cache.mjs');
test('a changed setting refreshes the instance', () => {
  const first = getSettings({ account: 'demo', mode: 'light' });
  const second = getSettings({ account: 'demo', mode: 'dark' });
  assert.notEqual(second, first);
  assert.equal(second.mode, 'dark');
  assert.equal(getSettings({ account: 'demo', mode: 'dark' }), second);
});
JS
cp cache.mjs cache.original.mjs
node --test cache.test.mjs
}
create_cache_lab

Untersuche cache.mjs und cache.test.mjs und reproduziere den Fehler. Ändere den Cache: Eine Änderung an account ODER mode muss eine neue Instanz erzeugen; gleiche Werte müssen dieselbe Instanz wiederverwenden. Originaltest beibehalten, bei Bedarf eine separate Prüfung für account ergänzen. Keine Abhängigkeiten, Timer oder globale Cache-Löschung. Führe node --test cache.test.mjs aus und erkläre die identitätsbestimmenden Eingaben.

if (!cached || cached.account !== config.account || cached.mode !== config.mode) cached = { ...config };

node --test cache.test.mjs ausführen. Die geprüfte Referenz besteht: Geändertes mode liefert ein anderes Objekt mit dark; der nächste gleiche Aufruf verwendet es wieder. Hier gibt es nur account und mode. Im echten Dienst alle Konstruktionseingaben erfassen, Lesefehler weiterhin korrekt behandeln und Rotation ohne Ausgabe geheimer Werte prüfen. Das zertifiziert keinen Produktionscache oder Zahlungsanbieter.

Warum diese Prüfungen zur Übung gehören

Anthropics Kontextbeitrag behandelt gezieltes Nachladen und strukturierte Notizen; der Evaluationsbeitrag trennt Gesprächsprotokoll und Ergebnis. Unsere Anwendung: mit den benannten Dateien beginnen, gespeicherte Änderungen erneut lesen und echte Testausgaben samt Summe neben dem Diff aufbewahren. HANDOFF.md hält Pfade, ausgeführte Befehle und offene Aufgaben fest, damit eine fortgesetzte Sitzung die aktuellen Dateien erneut prüft. So werden Kontext, Nachweis und Übergabe verbunden, ohne lange Prompts oder Protokolle als Qualitätsbeweis zu behandeln.

Eine pausierte Aufgabe leicht fortsetzbar machen

report.original.mjs und cache.original.mjs unverändert lassen. Vor einer neuen Sitzung eine Notiz mit aktuellen Dateien, letzten Befehlen und offenen Punkten verlangen. Beim Fortsetzen Dateien lesen und Tests wiederholen: Eine Zusammenfassung kann veraltet sein. Eine DSH-Sitzung ist Verlauf, kein Ersatz für Versionsverwaltung oder Sicherung.

Schreibe HANDOFF.md für diese Übung: Ziel, geänderte Dateien, ursprüngliche Fehler, exakt ausgeführte Befehle und Ergebnisse, offene Probleme und nächste Prüfung. Keine Zugangsdaten und keine Behauptung nicht ausgeführter Tests. Eine neue Sitzung muss anhand der Notiz und aktuellen Dateien fortfahren können.

Je nach beobachtetem Fehler wiederherstellen

1. 01

   Ein Befehl startet nicht

   Node-Version, Arbeitsverzeichnis und ausgewählten Arbeitsbereich prüfen. Erst die Umgebung reparieren, statt fehlende Programme oder Rechte durch Codeänderungen zu kaschieren.

2. 02

   Tests oder fremde Dateien wurden geändert

   Stoppen, Versuch sichern und Diff lesen. Nur betroffene Übungsdateien aus ihren bekannten Originalen wiederherstellen und Kriterien erneut festlegen.

3. 03

   Modell oder Anbieter nicht verfügbar

   Dateien und Übergabe behalten, Anbieter außerhalb des Prompts konfigurieren und dieselbe oder eine neue Sitzung mit gleichen Kriterien nutzen. Ein API-Fehler ist kein erfolgreicher Codetest.

cp report.mjs report.attempt.mjs
cp report.original.mjs report.mjs
node --test report.test.mjs

Danach müssen die ursprünglichen zwei Fehler wieder auftreten: Das ist der beabsichtigte Wiederherstellungstest. report.attempt.mjs bleibt zum Vergleich erhalten. Im echten Repository eine saubere Branch oder einen Worktree und eine geprüfte dateispezifische Wiederherstellung nutzen; diese Überschreibbefehle nicht auf andere Arbeit anwenden.

Eine bewährte Routine als kleinen Skill festhalten

Nach der Übung Untersuchen, Reproduzieren, Ändern, Testen und Übergeben dokumentieren. DSH findet lokale Skills unter anderem in .dsh/skills und .agents/skills; Namen und Rangfolge sind relevant. Ein Skill beschreibt Abläufe und verleiht keine Systemrechte. Vor der Erkennung prüfen, Befehle begrenzen und keine unbekannte Erweiterung nur wegen eines Automatisierungsversprechens laden.