[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-79930":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":8,"htmlUrl":8,"language":9,"languages":8,"totalLinesOfCode":8,"stars":10,"forks":11,"watchers":12,"openIssues":13,"contributorsCount":13,"subscribersCount":13,"size":13,"stars1d":12,"stars7d":14,"stars30d":15,"stars90d":13,"forks30d":13,"starsTrendScore":16,"compositeScore":17,"rankGlobal":8,"rankLanguage":8,"license":8,"archived":18,"fork":18,"defaultBranch":19,"hasWiki":18,"hasPages":18,"topics":20,"createdAt":8,"pushedAt":8,"updatedAt":21,"readmeContent":22,"aiSummary":23,"trendingCount":13,"starSnapshotCount":13,"syncStatus":12,"lastSyncTime":24,"discoverSource":25},79930,"harness-sdd","betta-tech\u002Fharness-sdd","betta-tech",null,"Python",165,64,2,0,48,79,14,71.34,false,"main",[],"2026-06-12 04:01:25","# ejemplo-harness — Notes CLI\n\nProyecto de ejemplo que demuestra los principios de **Harness Engineering**\naplicados a un CLI minimalista de notas en Python.\n\n> El código de la aplicación es deliberadamente simple. Lo importante de\n> este repo no es **qué** hace, sino **cómo** está estructurado para que un\n> agente de IA pueda trabajar sobre él de forma autónoma y verificable.\n\n## Cómo está organizado el arnés\n\n| Pilar                                  | Manifestación en este repo                                                       |\n|----------------------------------------|----------------------------------------------------------------------------------|\n| **1. El repositorio ES el sistema**    | `AGENTS.md`, `init.sh`, `feature_list.json`, `specs\u002F`, `progress\u002F`, `docs\u002F`      |\n| **2. Orquestación multi-agente**       | `.claude\u002Fagents\u002Fleader.md`, `spec_author.md`, `implementer.md`, `reviewer.md`    |\n| **3. Spec Driven Development**         | `docs\u002Fspecs.md`, EARS notation, puerta de aprobación humana en `spec_ready`      |\n| **4. Supervisión y mejora**            | `CHECKPOINTS.md`, hooks en `.claude\u002Fsettings.json`, `tests\u002F`                     |\n\n## Para empezar\n\n```bash\n.\u002Finit.sh\n```\n\nSi todo está verde, abre `AGENTS.md` y sigue desde ahí.\n\n## Para usar la app (humanos)\n\n```bash\npython3 -m src.cli add \"comprar pan\" --body \"y leche\"\npython3 -m src.cli list\n```\n\n## Probarlo tú mismo con Claude Code\n\nSi te descargas el repo y abres Claude Code en la raíz, ya estás dentro del\narnés: `CLAUDE.md` fuerza al modelo a actuar como `leader` (orquesta, no\nedita código) y `docs\u002Fspecs.md` impone el flujo Spec Driven Development.\n\nReceta rápida:\n\n1. `.\u002Finit.sh` — debe terminar verde.\n2. Abre `feature_list.json` y deja al menos una feature con\n   `status: \"pending\"` y `\"sdd\": true`. La #7 `cli_recent` ya está así.\n3. Lanza Claude Code en la raíz del repo: `claude`.\n4. Pídele: **«implementa la siguiente feature pendiente»**.\n\nLo que ocurre, en dos fases:\n\n**Fase 1 — Spec.** El `leader` lanza un `spec_author` que escribe\n`specs\u002F\u003Cfeature>\u002F{requirements.md, design.md, tasks.md}` y deja la feature\nen `spec_ready`. Luego **para y te pide aprobación**.\n\nTú lees los tres archivos en tu editor:\n\n- `requirements.md` — qué debe hacer la feature, en EARS estricto.\n- `design.md` — decisiones técnicas antes de escribir código.\n- `tasks.md` — checklist de pasos discretos a ejecutar.\n\nCuando estés conforme, dices al chat «aprobado» (o pides cambios).\n\n**Fase 2 — Código.** El `leader` transiciona la feature a `in_progress` y\nlanza `implementer` (sigue las tasks una a una marcándolas `[x]`) y\ndespués `reviewer` (verifica trazabilidad `R\u003Cn>` ↔ test y todas las tasks\ncompletas).\n\nDónde queda la traza de cada subagente:\n\n| Archivo                                  | Quién lo escribe   | Qué contiene                                                  |\n|------------------------------------------|--------------------|---------------------------------------------------------------|\n| `specs\u002F\u003Cfeature>\u002Frequirements.md`        | spec_author        | EARS requirements numeradas `R1`, `R2`, ...                  |\n| `specs\u002F\u003Cfeature>\u002Fdesign.md`              | spec_author        | Decisiones técnicas + alternativa descartada                  |\n| `specs\u002F\u003Cfeature>\u002Ftasks.md`               | spec_author        | Checklist; el implementer la va marcando `[x]`                |\n| `progress\u002Fcurrent.md`                    | leader             | Plan vivo de la sesión                                        |\n| `progress\u002Fimpl_\u003Cfeature>.md`             | implementer        | Archivos tocados + mapa `R\u003Cn> → test` + output de los tests   |\n| `progress\u002Freview_\u003Cfeature>.md`           | reviewer           | Checklist contra `docs\u002F`, `specs\u002F\u003Cfeature>\u002F` y `CHECKPOINTS.md` |\n| `feature_list.json`                      | leader\u002Fimplementer | `pending` → `spec_ready` → `in_progress` → `done`             |\n| `progress\u002Fhistory.md`                    | leader             | Resumen append-only al cerrar la sesión                       |\n\nAbre `specs\u002F` y `progress\u002F` en tu editor mientras Claude trabaja: cada\ninforme aparece en cuanto el subagente termina. Esa es la regla\nanti-teléfono-descompuesto en acción — el contenido no circula por chat,\nvive en disco y queda versionado.\n\n## Estructura\n\n```\n.\n├── AGENTS.md              # Mapa para agentes (divulgación progresiva)\n├── CHECKPOINTS.md         # Criterios de \"estado final correcto\"\n├── feature_list.json      # Alcance: una feature a la vez\n├── init.sh                # Verificación e inicialización\n├── specs\u002F\u003Cfeature>\u002F       # Spec por feature (Kiro-style)\n│   ├── requirements.md    # EARS notation\n│   ├── design.md          # Decisiones técnicas\n│   └── tasks.md           # Checklist de implementación\n├── progress\u002F\n│   ├── current.md         # Sesión activa (estado vivo)\n│   └── history.md         # Bitácora append-only\n├── docs\u002F\n│   ├── architecture.md    # Qué significa \"buen trabajo\"\n│   ├── conventions.md     # Estilo, nombres, errores\n│   ├── specs.md           # Proceso SDD: EARS, 3 archivos, aprobación humana\n│   └── verification.md    # Cómo demostrar que funciona\n├── .claude\u002F\n│   ├── agents\u002F            # leader, spec_author, implementer, reviewer\n│   └── settings.json      # Hooks que automatizan la verificación\n├── src\u002F\n│   ├── storage.py         # Persistencia atómica (JSON)\n│   ├── notes.py           # Modelo de dominio\n│   └── cli.py             # Interfaz argparse\n└── tests\u002F\n    ├── test_storage.py\n    ├── test_notes.py\n    └── test_cli.py\n```\n\n## Aprendizajes que ilustra este proyecto\n\n- **Divulgación progresiva** en `AGENTS.md`: el agente no recibe todas las\n  reglas de golpe, recibe un mapa para buscarlas bajo demanda.\n- **Una feature a la vez** validado por `init.sh` (rechaza más de un\n  `in_progress` en `feature_list.json`).\n- **Spec Driven Development** estilo Kiro: requirements (EARS) → design →\n  tasks → code, con una puerta de aprobación humana antes de tocar código.\n- **Estado en disco**, no en chat: `specs\u002F`, `progress\u002Fcurrent.md` y\n  `history.md` sobreviven a reinicios y context windows reventadas.\n- **Verificación ejecutable**: `init.sh` corre los tests reales y valida\n  la presencia de specs para toda feature SDD.\n- **Trazabilidad obligatoria**: cada `R\u003Cn>` se mapea a un test concreto;\n  el reviewer rechaza si falta.\n- **Patrón Leader-Spec-Implementer-Reviewer**: el leader no implementa,\n  el spec_author no codifica, el implementer no se autoaprueba, el\n  reviewer no edita código.\n- **Anti teléfono-descompuesto**: los subagentes escriben sus resultados\n  en archivos y solo devuelven una referencia ligera.\n","betta-tech\u002Fharness-sdd 是一个示例项目，展示了如何将Harness Engineering原则应用于一个简洁的Python笔记命令行工具。其核心功能包括多代理编排、规范驱动开发（Spec Driven Development, SDD）以及持续监督和改进机制，这些都通过特定的文件结构如`AGENTS.md`, `init.sh`, 和`feature_list.json`等来实现。该项目特别适合于探索如何构建能够支持AI自主且可验证地进行工作的软件系统架构。用户可以通过运行简单的初始化脚本开始使用，并利用Claude Code环境体验整个SDD流程从需求定义到代码实现再到审查的自动化过程。","2026-06-11 03:58:34","CREATED_QUERY"]