Buenas prácticas de DeepSeek Harness: dos reparaciones verificables

Qué se ha comprobado realmente

Define el límite antes de enviar una indicación

1. 01

   Parte de una versión conocida

   Sigue el inicio rápido de 0.1.3-alpha.1 y su commit fijado. Selecciona el modelo en Settings → Models. Guarda credenciales en la configuración del proveedor, nunca en indicaciones o ejemplos.

2. 02

   Separa proyecto y entorno de ejecución

   Usa un directorio propio para el ejercicio y selecciónalo en la interfaz web. No coloques el entorno del código oficial dentro de este sitio o de otro proyecto con node_modules incompatibles en sus directorios superiores.

3. 03

   Mantén pequeña la primera tarea

   Revisa el aislamiento y las aprobaciones efectivos. Limita el trabajo al proyecto desechable; estos tres archivos no necesitan plugins ni dependencias nuevas.

Crea un proyecto pequeño con un fallo visible

Necesitas Node.js 24 y una terminal compatible con Bash en un directorio nuevo y desechable. Usa Bash en macOS/Linux o Git Bash/WSL en Windows. harness-lab todavía no debe existir. No hay dependencias npm, cuentas, datos personales ni archivos de producción. El CSV simplificado no contiene comas entre comillas: no estamos construyendo un analizador CSV general.

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

La primera ejecución debe fallar en dos comprobaciones y superar una. El código incluye los 700 céntimos del pedido reembolsado: devuelve 2700 en lugar de 2000. La regla es contar únicamente filas con status paid; refunded y pending no aportan nada. Los importes son céntimos enteros.

Pide primero un diagnóstico reproducible

Inspecciona solo orders.csv, report.mjs y report.test.mjs, sin modificarlos aún. Explica la regla de las pruebas, identifica la fila reembolsada y ejecuta node --test report.test.mjs. Explica por qué el filtro devuelve 2700 en lugar de 2000. Si no puedes ejecutar el comando, describe el problema real del entorno sin inventar resultados.

Un diagnóstico útil identifica la fila B, status !== 'pending' y las dos comprobaciones fallidas. «Debería pasar después» no es un resultado. Si se propone otra biblioteca CSV o una refactorización amplia, vuelve al ejemplo y a sus criterios.

Autoriza el cambio acotado y compruébalo aparte

En este proyecto desechable, corrige report.mjs para que totalPaid cuente únicamente filas paid. Lee primero orders.csv y report.test.mjs, ejecuta node --test report.test.mjs y describe el fallo inicial. No cambies orders.csv, report.test.mjs ni report.original.mjs; no instales paquetes ni accedas a otros directorios. Haz el cambio mínimo, repite las tres comprobaciones y calcula el total de orders.csv. Devuelve el archivo modificado, el resultado observado, el total y las limitaciones. Distingue un problema del entorno de una comprobación fallida.

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

Deben pasar tres pruebas y aparecer por separado el total 2000. Normalmente el diff cambia el filtro a status === 'paid'. Otra implementación es válida si cumple la regla y conserva las pruebas. diff devuelve 1 cuando encuentra diferencias: aquí es normal, no un fallo de prueba. Un Node ausente o un permiso denegado son problemas del entorno.

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

La solución ejecutada localmente cambia solo el filtro, conservando datos y pruebas. Guarda juntos la salida de las pruebas y el total calculado. Una captura verde de terminal sin comando ni diff no basta.

Segunda tarea: cambia una opción, pero la caché conserva el objeto anterior

Crea dos archivos más en el mismo proyecto. account sigue siendo demo y mode cambia de light a dark. La caché compara solo account y devuelve el objeto anterior. El ejemplo distingue cambiar la configuración de invalidar una instancia ya construida.

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

Inspecciona cache.mjs y cache.test.mjs y reproduce el fallo. Corrige la caché: cambiar account O mode debe construir una nueva instancia; valores iguales deben reutilizarla. Mantén la prueba original y añade otra para account si hace falta. No introduzcas dependencias, temporizadores ni un vaciado global. Ejecuta node --test cache.test.mjs y explica qué entradas determinan la identidad.

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

Ejecuta node --test cache.test.mjs. La solución comprobada pasa: cambiar mode produce otro objeto con dark; la siguiente llamada idéntica lo reutiliza. Aquí solo existen account y mode. En un servicio real enumera todas las entradas, conserva el comportamiento ante lecturas fallidas y prueba la rotación sin revelar secretos. No es una certificación de una caché o proveedor de pagos de producción.

Por qué hacemos estas comprobaciones

Anthropic trata la búsqueda dirigida y las notas estructuradas en su artículo sobre contexto, y distingue conversación y resultado en el de evaluación. Nuestra aplicación es concreta: empezar por los archivos indicados, releer los cambios guardados y conservar las salidas reales de tests y el total junto al diff. HANDOFF.md guarda rutas, comandos ejecutados y tareas pendientes para que una sesión retomada vuelva a comprobar los archivos actuales. Así unimos contexto, evidencia y relevo sin confundir un prompt o registro largo con una prueba de calidad.

Facilita retomar una tarea pausada

Conserva report.original.mjs y cache.original.mjs. Antes de cambiar de sesión pide una nota con archivos actuales, últimos comandos y trabajo pendiente. Al retomar, lee los archivos y repite las pruebas: el resumen puede describir un estado anterior. La sesión de DSH es historial, no una copia de seguridad ni control de versiones.

Escribe HANDOFF.md para el ejercicio: objetivo, archivos cambiados, fallos originales, comandos exactos realmente ejecutados y resultados, problemas pendientes y siguiente comprobación. No incluyas credenciales ni afirmes haber ejecutado pruebas pendientes. Otra sesión debe poder continuar leyendo la nota y los archivos actuales.

Recupera según el fallo observado

1. 01

   No se ejecuta un comando

   Comprueba versión de Node, directorio actual y espacio seleccionado. Corrige el entorno antes de modificar código para disimular un ejecutable ausente o un permiso denegado.

2. 02

   El agente cambió pruebas o archivos ajenos

   Detén la tarea, conserva los cambios y lee el diff. Restaura únicamente los archivos afectados del ejemplo desde sus originales y reafirma los criterios.

3. 03

   El modelo o proveedor no está disponible

   Conserva archivos y nota; corrige la configuración fuera de la indicación. Continúa o abre otra sesión con los mismos criterios. Un fallo de API no significa que las pruebas del código hayan pasado.

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

Deben reaparecer los dos fallos iniciales: es una prueba deliberada de recuperación. Guarda report.attempt.mjs para comparar. En un repositorio real utiliza una rama o árbol de trabajo limpio y una restauración por archivo revisada; no apliques estas sobrescrituras a trabajo ajeno al ejemplo.

Convierte una rutina útil en un Skill pequeño

Después de terminar, documenta inspección, reproducción, cambio, pruebas y entrega. DSH descubre Skills locales en .dsh/skills y .agents/skills; importan nombres y precedencia. Un Skill describe un flujo, no concede permisos del sistema. Revísalo antes de habilitar su descubrimiento, acota los comandos y no cargues extensiones desconocidas por una promesa de automatización.