Skip to content

Baton 0.4.1: flujo de inicio, módulos iterables y correcciones del piloto - #6

Open
Zartaroth wants to merge 12 commits into
mainfrom
flujo-inicio
Open

Zartaroth wants to merge 12 commits into
mainfrom
flujo-inicio

Conversation

@Zartaroth

Copy link
Copy Markdown
Owner

Resumen

Reúne los cambios de las versiones 0.4.0 y 0.4.1, que salieron de tres intentos de prueba piloto con un proyecto real pequeño (la CLI gastos). El detalle está en CHANGELOG.md, y cada defecto (D1 a D23), con su corrección, en pruebas/BITACORA-piloto.md.

0.4.0: flujo de inicio

  • Entender antes de decidir: baton-start detecta si el proyecto es nuevo o existente, escribe la visión y la confirma con el humano antes de configurar.
  • Escala y stack: el stack se recomienda según la escala y queda en ADR-0001, con condiciones para revisarlo.
  • Mapa de módulos iterable, con ciclo de vida propio (baton-module).
  • Tipo de backlog principal más auxiliares.
  • /baton como punto de entrada único.
  • baton-item une el refinamiento y el plan en una sola confirmación.

0.4.1: correcciones del piloto

  • El humano solo aprueba lo que tiene en pantalla: los criterios y los slices se muestran antes de pedir la aprobación, y los tests se presentan junto a cada criterio.
  • Abrir un módulo tiene una sola confirmación.
  • Preguntas interactivas para las decisiones con opciones.
  • Cada skill trae sus reglas: el agente ya no lee el código de baton.py.
  • El primer congelado de tests ya no exige un commit intermedio. El driver sigue bloqueado.
  • Bugs de baton.py: reinstalar el hook, el verificador sin entidad, los .pyc en el lock y el recorte de texto.

Pruebas

  • pruebas/e2e.sh: 31 comprobaciones, todas ok, incluidos los ataques al lock.
  • Frontmatter YAML válido en las 8 skills.

Siguiente

Validar Baton construyendo un SaaS real. Las skills baton-verify y baton-review siguen pendientes.

🤖 Generated with Claude Code

Zartaroth and others added 12 commits November 3, 2026 14:55
La rama piloto ya no hereda los archivos de la metodología, para que los
agentes no los usen para suplir lo que falte en una skill. pytest se instala
en un .venv para no necesitar sudo.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Retroalimentación de la primera prueba piloto:

- baton-start (antes baton-setup): detecta si el proyecto es nuevo o
  existente, entiende qué se construye y lo confirma con el humano,
  recomienda el stack según la escala (ADR-0001 con "revisar si"),
  configura con ese contexto y arma el mapa de módulos.
- baton-module (antes baton-kickoff): mapa de módulos iterable (agregar,
  dividir, fusionar, descartar) y apertura de un módulo: entender,
  configurar y definir sus ítems.
- baton-item: une refine y plan, con una sola confirmación.
- baton (antes baton-next): router y único punto de entrada.
- Tipo de backlog principal (historia, requerimiento o ticket) más
  auxiliares (bug, técnico), con una plantilla por tipo.
- baton.py: comando detectar, estados de módulo, Definition of Ready
  según el tipo, la visión y los ADR en el sync, y el mapa de módulos
  en BACKLOG.md.
- CI valida el frontmatter de las skills.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Guía coherente con el flujo nuevo: inicio (entender, escala y stack),
  cambios al mapa, módulos en Delegado y en Pair, iterar (bug en un
  módulo cerrado, actualizar la visión) y ataques. Sin IDs fijos.
- Corrige la preparación, que no enlazaba el router baton.
- pruebas/reiniciar-piloto.sh deja el piloto como un proyecto recién
  creado, respalda el baton/ anterior y vuelve a enlazar las 8 skills.
  Solo actúa en la rama piloto.
- Bitácora: el intento 1 queda archivado y hay tablas nuevas para el
  intento 2.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
"continúa" no tiene sentido en un proyecto vacío y depende de que el
agente interprete la frase. /baton invoca siempre el router: en un
proyecto vacío lanza baton-start, y a mitad del trabajo sigue con lo
que toque. La descripción del router incluye también frases de inicio
("empecemos", "start"). /baton-start sigue disponible.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Las decisiones con opciones (elegir, aceptar o descartar, confirmar un
resumen) usan la herramienta de preguntas interactivas del entorno, si
la tiene, con la recomendación primero. Las preguntas abiertas van en
texto. Si no hay herramienta interactiva, se usa una lista numerada.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- baton-start: la configuración se pregunta en dos tandas interactivas;
  la ronda 2 separa lo abierto de lo que tiene opciones; el cierre muestra
  tablas (configuración, mapa de módulos, next); hay una sección de reglas
  para que el agente no lea el código de baton.py; el verificador siempre
  tiene entidad.
- baton.py: init reconoce su propio hook y funciona también desde la copia
  instalada (antes fallaba al copiarse sobre sí mismo); validar avisa si
  el verificador no tiene entidad.
- e2e: 27 comprobaciones, con la reinstalación del hook y el aviso.
- Guía y bitácora con los resultados de la fase 1.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ente

- Guía y bitácora con los resultados de la fase 2 (D12–D15).
- baton-module, sección A: propuestas de módulos con una pregunta
  interactiva de selección múltiple, motivo de fondo en cada cambio,
  regla de división que permite conservar el original, y la visión
  actualizada cuando el mapa cambia el alcance.
- El piloto pasa a ser un repositorio independiente: un worktree comparte
  la memoria de Claude Code y el remoto del repo de la metodología (D14).
  El script de reinicio avisa si detecta un worktree.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
El piloto ya no es un worktree: ahora es un repositorio propio, con su
memoria de Claude Code y sin remoto. La guía vuelve a tener las
casillas en blanco, y los resultados del intento 2 quedan archivados en
la bitácora, verificación por verificación.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- baton-start: el nombre del proyecto sale del producto y se confirma en el resumen
- proyecto-nuevo: la escala ofrece las 4 opciones más cercanas
- baton-start: sin tabla previa a las tandas de configuración; commit con pregunta interactiva
- baton.py: el objetivo del mapa se corta por palabra (90 caracteres)
- Guía: fase 2 adaptada a los módulos cuentas y liquidacion; nota del error sembrado

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…recciones (D18–D23)

- baton-item: decisiones, luego criterios y slices visibles, luego la aprobación
- baton-approve: tabla criterio-test obligatoria antes de preguntar
- baton-module y baton-item: reglas que necesitan, sin leer baton.py
- baton: anuncio siempre; baton-module se activa ante '¿qué módulos faltan?'
- baton.py: archivos_tests ignora __pycache__ y .pyc (e2e)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ue duda y apertura de módulo

- baton.py: el primer congelado no exige un commit intermedio en TestsEnRevision (D22);
  Pendiente → Candidato permitido. e2e: 31 comprobaciones
- baton-module B: preguntas abiertas, propuesta completa a la vista y una sola aprobación
- baton-tests: implementación desechable solo si duda, fuera del repositorio
- FORMATOS §6.3, METODOLOGIA §4.3 y diagrama de estados actualizados

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant