La metodología es un sistema vivo.

[0.4.0-beta] — 2026-09-03

Entrega por hitos

Documento nuevo Hitos para los proyectos que se entregan en más de un bloque contratado por separado —lo que el cliente llama “la fase 2”—. El caso estaba resuelto pero repartido entre la fase 6, el paso F3.5 y brownfield; ahora tiene un lugar propio, como brownfield y equipos. Las siete fases y sus pasos no cambian.

• hito, término nuevo del vocabulario: un bloque de alcance que se define, se construye, se entrega y —casi siempre— se cobra aparte, con identificador estable (H-1, H-2). Se distingue de fase (los 7 tramos del proceso) y de etapa (los pasos del ciclo de OpenSpec), que ya estaban tomadas.
• La regla: el alcance se parte en hitos, el proceso no. La fundación (fase 0), el entendimiento (fase 1) y la maquinaria de la fase 4 se corren una vez para todo el proyecto; la definición detallada y la construcción son del hito en curso —profundidad desigual—.
• El mapa de hitos nace en el Documento de Entendimiento (F1.2) y pasa al PRD de negocio (F3.4), donde es contrato. Cada requisito declara su hito (RF-4 · H-1) y cada ítem del backlog el suyo: el backlog sigue siendo una sola cola, el hito es un atributo del ítem.
• Encadenados o con corte real: lo decide si el hito llega a manos de sus usuarios antes de que empiece el siguiente. Encadenados, el ciclo de la fase 5 continúa; con corte, el producto entra en evolución continua y el hito siguiente re-entra por el triaje de la fase 6, por el carril que le corresponda por tamaño.
• Cierre de hito ✋ con siete puntos —deuda aplazada capturada, release trazable, PRD al día, design system canónico, prototipo apagado, métricas cortadas y auditoría corrida— y el gate correspondiente: el hito siguiente no se abre con el anterior sin cerrar.
• Plantillas: el mapa de hitos entra en entendimiento.md.template y prd-business.md.template, la columna Hito en prd-v1.md.template y la convención de hito por ítem en backlog.md.template. Todas marcadas como opcionales: un proyecto de un solo hito las borra.

[0.3.1-beta] — 2026-09-03

Revisión de lenguaje: los documentos se escriben en español, y el vocabulario se corrige donde había términos sin traducir o traducidos a medias. No cambia ningún mecanismo — mismos pasos, mismas fases, mismos entregables.

Vocabulario

• grooming → refinamiento. En español, grooming nombra el acoso a menores en línea; es además el término que la propia comunidad ágil reemplazó por refinement. La sección de operations.md pasa a llamarse Refinamiento del backlog.
• intake → recepción. El paso de la fase 6 que captura el trabajo nuevo antes de triarlo. Intake no es palabra de uso corriente en español; recepción dice lo mismo y encaja con el triaje que viene después.
• triage → triaje, que es la forma en español y la que corresponde al verbo triar que los documentos ya usaban.
• artifact → artefacto en la prosa. Convivían las dos formas para el mismo concepto (el artefacto de QA). Se conservan en inglés el nombre de archivo qa-artifact.md.template y la palabra artifacts cuando nombra la clave del schema de OpenSpec.
• soporta → admite donde traducía supports: en español soportar es aguantar, no admitir.
• tracking → seguimiento.
• item → ítem (101 veces): en español lleva tilde. Se conservan sin tocar los identificadores dentro de código.

[0.3.0-beta] — 2026-09-03

Revisión de privacidad: qué material del proyecto es confidencial y qué mecanismo lo mantiene fuera del historial y de la vista pública. Las siete fases y los principios no cambian; la fase 0 gana un paso.

Confidencialidad del material del proyecto

• F0.3 nuevo — .gitignore de partida: la fase 0 pone el .gitignore antes de que llegue el primer archivo confidencial. initial-references/ estaba declarada como ignorada en cuatro documentos pero ninguna plantilla la ignoraba: era una regla que dependía de acordarse. Plantilla nueva (aislamiento/gitignore.template) con el material de stakeholders, settings.local.json, los .env y los volcados de base de datos. El aislamiento acota lo que el asistente lee; el .gitignore, lo que el repositorio publica.
• Dónde vive el prototipo (prototype.md): el archivo lleva el producto del cliente antes de existir, así que es confidencial del mismo grado que initial-references/ — nunca en un repositorio público; si se publica para que un stakeholder lo abra, en URL no adivinable, con noindex y apagado al cerrar la fase; datos de ejemplo inventados.
• El envío de feedback a un tercero lo decide el cliente: el formulario por correo (Formspree) es la única pieza del andamiaje que sale del navegador, y lo que manda son comentarios sobre el producto del cliente. Se cablea con su aprobación; el canal por defecto es el export local.

[0.2.0-beta] — 2026-09-02

Primera ronda de refinamiento sobre la beta, salida de la práctica. Las siete fases (0–6) y los principios se mantienen; cambian el reparto de la definición entre las fases 2 y 3, la forma del prototipo y el detalle del ciclo iterativo.

El proceso

• Toda fase declara su entregable al inicio: mientras el artefacto no exista, la fase no cerró. La fase 6 es la excepción declarada —es un lazo, y cada vuelta entrega lo mismo que la fase 5—.
• Documento de Entendimiento (F1.2 ✋): la fase 1 cierra con la síntesis del problema, no de la solución. Las rutas de exploración e investigación convergen en él. Plantilla nueva.
• Un solo PRD antes del prototipo. La fase 2 pasa a llamarse PRD inicial; la partición en PRD de negocio y técnico se mueve a F3.4, con el prototipo ya aprobado y antes de la preparación técnica. Plantilla nueva.
• Trazabilidad por ID estable (RF-2, MET-1) en vez de número de sección: el ID viaja con el requisito cuando cambia de documento.
• El prototipo es un solo archivo HTML con switch de modo: encendido muestra insignias, notas y comentario por bloque; apagado se ve como producción; la vista limpia (?limpio) quita el marco para demos y capturas. Rol, fase y escenario se declaran en el prototipo y el marco pinta los selectores.
• Paso opcional F3.5 · Refinamiento del prototipo ✋: convierte el prototipo aprobado en especificación visual ejecutable —pasos intermedios, estados de vacío/carga/error, validaciones y textos reales, permisos por rol—, con umbral explícito de “completo”. Es parcial por diseño y su entregable es el acuerdo escrito: un change de OpenSpec pendiente por flujo. Plantilla nueva: inventario de flujos.
• La fase 3 sin interfaz valida la superficie observable contra su consumidor: contrato navegable y sus convenciones en una API, comandos y salidas en una CLI, esquemas en un pipeline. Se aprueba cuando el consumidor puede escribir su cliente contra el mock sin preguntar nada.
• Las capas de la definición (workflow.md): qué vive en el PRD de negocio, el PRD técnico, el prototipo + design system y las specs, con regla de decisión, referencia por ID en vez de repetición y precedencia cuando dos capas se contradicen.
• F4.8 · Personalizar el ciclo de OpenSpec (nuevo): F0.2 fija la versión y forkea el schema; F4.8 lo llena con el stage qa, los criterios de verify, la orquestación por agente y la validación end-to-end.
• Protocolo de QA en tres pasos, secuencial y bloqueante: verificar los datos en la base → correr lo automatizable y registrarlo → entregar los bloques manuales. Un bloque es un rol × un flujo, autocontenido; las credenciales se referencian al seed y nunca se escriben en el artifact.
• Code review y security review, nombrados en el ciclo: el code review es el pase de juicio de verify; el security review entra como tercer pase condicional, disparado por un gate de superficie sensible, y un hallazgo bloquea el archive salvo disposición explícita.
• El paso archive entrega índice y regla aprendida: un índice append-only de changes archivados —dónde está la historia de cada capability— y la regla, que se escribe donde se aplica y deja solo el puntero en el índice. Plantillas nuevas.

Estándares

• §11 nueva — Higiene de dependencias: audit que falla el build con severidad ≥ alta, en cada PR y programado sobre la rama principal; excepciones con motivo y fecha de caducidad; bot de actualizaciones recomendado; lockfile versionado y versiones fijadas.
• §9 dice ahora cómo se configuran los logs, no solo dónde se leen: salida estándar, JSON en producción, niveles con debug por variable de entorno, identificador de correlación, enmascarado de datos sensibles y retención declarada.
• Cuarto foco en la auditoría periódica — seguridad del producto—, centrado en el estado de los mecanismos automáticos: excepciones vencidas, PRs del bot sin merge, dependencias sin mantenimiento y deriva de majors.

CLAUDE.md y aislamiento

• El CLAUDE.md no lleva historia: si una línea empieza con una fecha, va a uno de los logs que ya existen. Se actualiza reemplazando, no anexando, con un tope de 200 líneas verificado en CI.
• El proyecto no usa la memoria del asistente: los hechos del proyecto viven en archivos versionados; las preferencias personales del desarrollador pueden quedarse en su herramienta.
• La versión fijada de OpenSpec se declara en el CLAUDE.md, junto a la de Argui. No duplica el lockfile —instalado contra validado—, y se actualiza al re-validar el ciclo, no al instalar.
• Aislamiento en dos archivos: línea base de seguridad versionada (settings.json) más lo específico de cada máquina (settings.local.json), con la base corregida contra la configuración probada.
• Lo que vive fuera del repositorio se lee, no se recorre con comandos: el aislamiento tiene dos capas que no cubren lo mismo, y una carpeta externa queda al alcance de las herramientas de archivo pero no del shell.

Plantillas

• Nuevas: Documento de Entendimiento, PRD inicial, inventario de flujos, índice de changes archivados y los instruction de orquestación de OpenSpec.
• Los PRD suman la declaración de datos sensibles, el gate de IA dentro del producto y la nota de frontera con las specs; el stage qa que se distribuye lleva el protocolo nuevo; la plantilla de auditoría suma las métricas de equipo.
• El prefijo de los IDs de backlog en los ejemplos pasa a PRJ-, declarado como marcador de posición del proyecto.
• Auditoría de consistencia previa al versionado sobre los 35 archivos de la metodología: corregidos los entregables de fase, las referencias a estándares y rutas gobernadas, y los acrónimos sin definir en su primer uso.

[0.1.0-beta] — 2026-06-29

Primera versión pública de Argui — el método que le da claridad a tu desarrollo con IA.

Argui es un método para construir productos digitales con IA de forma estructurada y predecible: define qué hacer antes de escribir código, organiza agentes de IA por especialidad, valida cada avance y asegura un producto final sólido y entregable.

Estado: beta. La estructura es estable; los detalles se refinan con cada ronda de proyectos reales. Validada con OpenSpec v1.4.1.

El proceso

• Siete fases (0–6): fundación → entendimiento → PRDs → prototipo → preparación → ciclo iterativo → evolución continua, con puntos de aprobación humana.
• IDs de paso estables F{fase}.{paso}: insertar o quitar un paso solo renumera su fase, no las demás.
• Prototipo trazable al PRD antes de construir; el design system se consolida del prototipo aprobado.
• Ciclo iterativo sobre OpenSpec personalizado (apply → verify → qa → archive), con la separación implementador/revisor.
• Soporte brownfield: aplicar el método a un producto que ya existe (onboarding + entrada por la fase 6).
• Trabajo en equipo: el paralelismo es propiedad de las fases 5/6; la preparación (0–4) es secuencial por diseño.

Estándares

• Accesibilidad en capas, seguridad y aislamiento del entorno de IA, monitoreo en producción, versionado y rollback del despliegue, descubribilidad (SEO/GEO) condicional, y evals/guardrails para productos con IA. Métricas de entrega y auditorías periódicas, con el principio “lo verificable se verifica como código”.

El repositorio

• Guías de metodología, arquetipos de agente, plantillas (CLAUDE.md, PRDs, backlog, QA, decisiones, aislamiento, equipos) y catálogo de comandos y skills.