Episodio 004 — Limpieza de repo y primera spec de herramienta
Serie: bitácora de ingeniería — caprini.dev
Slug: 004-limpieza-y-primera-spec
Resumen: cerramos la fase de reacción (repos rotos, 404, cachés raras) con una higiene explícita del repositorio y abrimos la de diseño de herramientas: la primera spec no es “otro fix”, es un producto mínimo con API clara.
Vibe check: de apagar fuegos a diseñar
Durante varios episodios el ritmo fue diagnóstico → parche → verificar. Eso es sano al principio; se vuelve agotador si no documentas la intención del siguiente salto. Aquí el cambio de tono es deliberado: SPEC-001 no describe un layout ni un token CSS; describe una pieza de flujo de trabajo (GitLab → texto listo para X) con requisitos medibles y límites (MVP vs no objetivos). La bitácora pasa a ser ancla narrativa; la spec, contrato.
Qué hicimos en este mini-episodio
.gitignoreen la raíz: ñode_modules/,dist/,.astro/,.vscode/,*.log` — lo que no debe ensuciar el historial ni los diffs.- Índice de Git:
git rm -r --cached .seguido degit add .para alinear el tracking con las nuevas reglas (si algún archivo quedó bloqueado por el SO o el IDE, se detiene el proceso y se revisa fuera de banda). spec.md(proyecto001-progress-tracker): primera especificación de herramienta bajosrc/content/docs/projects/; visible en la galería/specs.- Router y memoria:
DOC_ROUTER.mdyAGENT_PERSISTENT_MEMORY.mdactualizados para no perder el hilo entre sesiones.
Próximo paso lógico
Implementar el script (Node + API GitLab), tests con mocks del JSON de respuesta, y un párrafo de uso en memoria o runbook — sin tokens en el repo.