[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-2363":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":14,"stars7d":15,"stars30d":16,"stars90d":13,"forks30d":13,"starsTrendScore":17,"compositeScore":18,"rankGlobal":8,"rankLanguage":8,"license":8,"archived":19,"fork":19,"defaultBranch":20,"hasWiki":19,"hasPages":19,"topics":21,"createdAt":8,"pushedAt":8,"updatedAt":22,"readmeContent":23,"aiSummary":24,"trendingCount":13,"starSnapshotCount":13,"syncStatus":12,"lastSyncTime":25,"discoverSource":26},2363,"ejemplo-harness-subagentes","betta-tech\u002Fejemplo-harness-subagentes","betta-tech",null,"Python",245,113,2,0,12,24,120,36,82.17,false,"main",[],"2026-06-12 04:00:14","# 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`, `progress\u002F`, `docs\u002F` |\n| **2. Orquestación multi-agente**    | `.claude\u002Fagents\u002Fleader.md`, `implementer.md`, `reviewer.md` |\n| **3. 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).\n\nReceta rápida:\n\n1. `.\u002Finit.sh` — debe terminar verde.\n2. Abre `feature_list.json` y deja al menos una feature con `status: \"pending\"`.\n   Si todas están en `done`, añade una nueva al final del array o cambia el\n   estado de una existente para reabrirla.\n3. Lanza Claude Code en la raíz del repo: `claude`.\n4. Pídele literalmente: **«implementa la siguiente feature pendiente»**.\n\nLo que verás en chat:\n\n- El **leader** anuncia el plan, lanza un `implementer` y luego un `reviewer`.\n- Por chat **no pasa código** — solo referencias del tipo\n  `done -> progress\u002Fimpl_\u003Cfeature>.md`. Esa es la regla anti-teléfono-descompuesto.\n\nDónde queda la traza de cada subagente (esto es la \"visualización\" persistente):\n\n| Archivo                          | Quién lo escribe | Qué contiene                                        |\n|----------------------------------|------------------|-----------------------------------------------------|\n| `progress\u002Fcurrent.md`            | leader           | Plan vivo de la sesión                              |\n| `progress\u002Fimpl_\u003Cfeature>.md`     | implementer      | Archivos tocados + output de los tests              |\n| `progress\u002Freview_\u003Cfeature>.md`   | reviewer         | Checklist contra `docs\u002F` y `CHECKPOINTS.md`         |\n| `feature_list.json`              | implementer      | `pending` → `in_progress` → `done`                  |\n| `progress\u002Fhistory.md`            | leader           | Resumen append-only al cerrar la sesión             |\n\nAbre `progress\u002F` en tu editor mientras Claude trabaja: cada informe aparece\nen cuanto el subagente termina. Así puedes auditar paso a paso quién decidió\nqué — el contenido no circula por chat, vive 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├── 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│   └── verification.md    # Cómo demostrar que funciona\n├── .claude\u002F\n│   ├── agents\u002F            # Definiciones de líder, implementador, revisor\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- **Estado en disco**, no en chat: `progress\u002Fcurrent.md` y `history.md`\n  sobreviven a reinicios y context windows reventadas.\n- **Verificación ejecutable**: `init.sh` corre los tests reales, no se fía\n  de lo que diga el agente.\n- **Patrón Líder-Trabajador-Revisor**: el líder no implementa, el\n  implementador no se autoaprueba, el revisor no edita código.\n- **Anti teléfono-descompuesto**: los subagentes escriben sus resultados\n  en archivos y solo devuelven una referencia ligera.\n","该项目是一个展示如何应用Harness Engineering原则于Python构建的简约笔记命令行界面(CLI)示例。核心功能包括通过结构化的方式使AI代理能够自主且可验证地对项目进行操作，采用了多代理协作、持续监督改进等机制，并强调了代码库即系统的思想。特别设计用于演示如何让Claude Code这样的AI模型参与到软件开发流程中，如特征实现与代码审查，适合想要探索或实践基于AI辅助开发工作流的开发者使用。","2026-06-11 02:49:39","CREATED_QUERY"]