Bonnes pratiques DeepSeek Harness : deux corrections vérifiables

Ce qui a réellement été vérifié

Définir la limite avant l’instruction

1. 01

   Partir d’une version connue

   Suivez le démarrage de 0.1.3-alpha.1 et son commit fixé. Choisissez le modèle dans Settings → Models. Les identifiants appartiennent à la configuration du fournisseur, pas aux instructions ni aux exemples.

2. 02

   Séparer projet et environnement d’exécution

   Placez l’exercice dans son propre répertoire, sélectionné dans l’interface. N’installez pas le runtime officiel dans ce site ou sous un projet dont les répertoires parents contiennent des node_modules incompatibles.

3. 03

   Garder une première tâche limitée

   Vérifiez isolation et approbations effectives. Restez dans l’espace jetable et dans le travail demandé ; trois fichiers ne nécessitent pas de nouveaux plugins ou paquets.

Créer un petit projet avec une erreur observable

Préparez Node.js 24 et un terminal Bash dans un nouveau répertoire jetable : Bash sous macOS/Linux, Git Bash ou WSL sous Windows. harness-lab ne doit pas encore exister. L’exemple ne nécessite ni dépendances npm, ni compte, ni données privées, ni fichiers de production. Son CSV simple ne contient pas de virgules entre guillemets ; il ne s’agit pas d’un analyseur CSV général.

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

Le premier lancement doit produire deux assertions en échec et une réussie. Le code compte les 700 centimes remboursés, soit 2700 au lieu de 2000. La règle est précise : seules les lignes paid comptent ; refunded et pending apportent zéro. Les montants sont des centimes entiers.

Demander d’abord un diagnostic reproductible

Inspecte seulement orders.csv, report.mjs et report.test.mjs, sans les modifier. Énonce la règle des tests, identifie la ligne remboursée et lance node --test report.test.mjs. Explique pourquoi le filtre donne 2700 au lieu de 2000. Si la commande est inexécutable, rapporte le problème réel d’environnement sans inventer de sortie.

Un diagnostic utile cite la ligne B, status !== 'pending' et les deux assertions échouées. « Cela devrait passer après correction » n’est pas un résultat. Si une nouvelle bibliothèque CSV ou une vaste refonte est proposée, revenez à l’exemple et aux critères.

Autoriser le correctif ciblé, puis le vérifier séparément

Dans ce projet jetable, corrige report.mjs pour que totalPaid compte uniquement les lignes paid. Lis d’abord orders.csv et report.test.mjs, exécute node --test report.test.mjs et rapporte l’échec initial. Ne modifie ni orders.csv, ni report.test.mjs, ni report.original.mjs ; n’installe aucun paquet et n’accède pas aux autres répertoires. Fais la modification minimale, relance les trois assertions et calcule le total d’orders.csv. Fournis le fichier modifié, les résultats observés, le total et les limites. Distingue un problème d’environnement d’une assertion échouée.

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

Attendez trois tests réussis et, séparément, le total 2000. Le diff remplace normalement le filtre par status === 'paid'. Une autre solution convient si elle respecte la règle et les tests. diff renvoie 1 lorsque les fichiers diffèrent : c’est attendu ici, pas un échec de test. L’absence de Node ou un accès refusé relève de l’environnement.

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

La correction exécutée localement ne change que le filtre, sans toucher aux entrées ni aux tests. Gardez la sortie des tests et le total calculé ensemble. Une capture de terminal verte sans commande et sans diff ne suffit pas.

Deuxième tâche : le réglage change, le cache conserve l’ancien objet

Créez ces deux fichiers supplémentaires dans le même projet. account reste demo et mode passe de light à dark. Le cache ne compare qu’account et renvoie l’ancien objet. Cet exemple distingue une configuration modifiée de l’invalidation d’une instance déjà construite.

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

Inspecte cache.mjs et cache.test.mjs et reproduis l’échec. Corrige le cache : une modification d’account OU de mode doit créer une instance ; des valeurs identiques doivent la réutiliser. Garde le test initial, ajoute si utile un contrôle séparé pour account. N’ajoute ni dépendance, ni minuterie, ni purge globale. Lance node --test cache.test.mjs et explique les entrées qui déterminent l’identité.

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

Lancez node --test cache.test.mjs. La correction vérifiée passe : changer mode crée un objet différent portant dark ; l’appel identique suivant le réutilise. L’exemple n’a qu’account et mode. Dans un vrai service, recensez toutes les entrées, préservez le comportement d’échec de lecture et testez la rotation sans révéler les secrets. Ce n’est pas une certification de cache ou de fournisseur de paiement de production.

Pourquoi effectuer ces vérifications

Anthropic traite la recherche ciblée et les notes structurées dans son article sur le contexte, et distingue conversation et résultat dans celui sur l’évaluation. Notre application est concrète : partir des fichiers nommés, relire les modifications enregistrées et garder sorties de tests et total avec le diff. HANDOFF.md conserve chemins, commandes exécutées et travail restant pour qu’une session reprise vérifie les fichiers actuels. On relie ainsi contexte, preuves et passation sans prendre la longueur d’un prompt ou d’un journal pour une preuve de qualité.

Faciliter la reprise d’une tâche suspendue

Gardez report.original.mjs et cache.original.mjs intacts. Avant de changer de session, demandez une note avec fichiers actuels, dernières commandes et travail restant. À la reprise, relisez les fichiers et relancez les tests : le résumé peut décrire un ancien état. Une session DSH est un historique, pas une sauvegarde ni un contrôle de versions.

Écris HANDOFF.md pour l’exercice : objectif, fichiers modifiés, échecs initiaux, commandes exactes réellement exécutées et résultats, problème restant et prochain contrôle. N’inclus aucun identifiant et ne prétends pas avoir exécuté les contrôles en attente. Une nouvelle session doit pouvoir continuer avec cette note et les fichiers actuels.

Restaurer selon la panne observée

1. 01

   Une commande ne démarre pas

   Vérifiez version de Node, répertoire courant et espace sélectionné. Réparez l’environnement avant de changer le code pour masquer un exécutable absent ou un accès refusé.

2. 02

   L’agent modifie des tests ou d’autres fichiers

   Arrêtez, préservez la tentative et lisez le diff. Restaurez seulement les fichiers concernés depuis leurs originaux, puis rappelez les critères.

3. 03

   Le modèle ou fournisseur est indisponible

   Gardez fichiers et note, corrigez la configuration hors de l’instruction, puis reprenez ou ouvrez une autre session avec les mêmes critères. Une erreur API n’est pas une réussite des tests du code.

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

Les deux échecs initiaux doivent réapparaître : c’est une vérification volontaire de la restauration. Conservez report.attempt.mjs pour comparer. Dans un vrai dépôt, utilisez une branche ou un arbre de travail propre et une restauration ciblée après revue ; n’écrasez pas d’autres travaux avec ces commandes.

Transformer une routine utile en petit Skill

Après l’exercice, consignez inspection, reproduction, modification, tests et reprise. DSH découvre les Skills locaux notamment dans .dsh/skills et .agents/skills ; noms et priorités comptent. Un Skill décrit un workflow sans accorder de nouveaux droits système. Relisez-le avant sa découverte, limitez les commandes et ne chargez pas une extension inconnue pour sa seule promesse d’automatisation.