Release de corrección. Dos bugs de path-matching, uno de empaquetado y otro de configuración — ninguno afecta el core determinista del pipeline.

Corregido #

• .pubignore excluía código fuente real. El patrón docs/ (línea 3) estaba sin / inicial, por lo que en sintaxis gitignore se anclaba a cualquier profundidad — excluía también lib/src/core/docs/ y test/core/docs/, que son código Dart, no documentación del proyecto. Anclado a la raíz (/docs/).
• architecture.layers.*.paths no soportaba glob patterns, aunque ship-complete-config.md los recomienda para proyectos feature-first (ej. lib/src/feature/*/domain/). Directory() no expande * — el patrón se trataba como nombre literal, nunca existía, y el layer quedaba vacío en silencio. Afectaba 8 puntos del analyzer suite: analyze_command, wiring_cohesion, widget_inventory e inventory_command no encontraban ningún archivo; layer_integrity, security, testing y package_boundary reimplementaban su propio matching por prefijo literal, que tampoco entendía *. Nuevo lib/src/core/paths/glob_match.dart (globMatch + expandLayerPaths) replica la semántica de glob que dart_source_graph ya usa para ship graph (* un segmento, ** cualquier profundidad, / final = prefijo de directorio), y los 8 puntos ahora la comparten. Schema: paths retipado de list<relative_path> a list<glob>.

Tercer release. El foco fue documentación intent-first: convertir la documentación del pipeline en artefactos deterministas y verificables, e introducir una fase de intención que se aprueba antes del diseño. El núcleo determinista sigue siendo 100% sin IA.

Añadido #

• Artefactos de documentación deterministas (lib/src/core/docs/): esquema de docs verificable por máquina (doc_schema), generador de esqueleto markdown (doc_skeleton), validador estructural (doc_validator) y parser de outline (markdown_outline). Doc kinds intent/design/tasks con perfiles por tipo de ticket. Nuevos comandos ship doc-skeleton y ship validate-doc.
• Fase intent-first + Intent Gate en el flujo de feature. Nuevo comando /ship-capture-intent: captura problema, valor, alcance y criterios de aceptación por función en un intent.md validado, con sidecar de aprobación intent_approved.json que espeja el Gate 0 de spec. Se cablea en /ship-pipeline como Phase 1.5 y aplica a tickets feature/arch/design (no bugfix).
• Comando ship docs-path: resuelve la ruta tracked de un documento del pipeline.
• Tipos de ticket arch y design: enum de clasificación extendido a feature|bugfix|arch|design, decidido por label y palabras clave.
• Detalle por función forzado por código: el validador exige ≥1 bloque ### FNN cuando el perfil lo requiere, y ship doc-skeleton siembra esos bloques desde new_components.screens del analysis.json.

Cambiado #

• El driver del pipeline exige aprobación de intención antes del diseño en tickets feature/arch/design.
• El gate de análisis se evalúa antes de intención/spec: un analysis.json inválido bloquea aunque ya exista spec.json (no avanzar sobre datos sin verificar).
• Los command strings emitidos por el driver se normalizan al prefijo ship- (/ship-analyze-ticket, /ship-design-feature, /ship-implement-*), en línea con los archivos de comando reales.
• Etiquetas del reporte del pipeline generalizadas para arch/design; el Intent Gate aparece en el reporte final.
• Ampliadas las palabras clave de clasificación bugfix para reducir el ruteo incorrecto de defectos como features.

Segundo release. El foco fue cerrar el lazo de fidelidad de diseño: extraer diseño de Figma de forma determinista, exigir que el código generado trace 1:1 contra el NDS, y volver el esquema NDS verificable por máquina. El núcleo determinista sigue siendo 100% sin IA.

Añadido #

• Subsistema Figma — extracción REST headless (lib/src/figma/). Nuevo comando ship figma-extract: lee un diseño de Figma vía REST y produce un NDS determinista, sin plugin ni MCP. Incluye parser de URL de Figma (figma_url.dart), cliente REST (figma_api.dart) y mapeo Figma→NDS (figma_mapper.dart).
• ship nds-diff — compara dos NDS (o un NDS contra su realización) para medir desviación de fidelidad de diseño.
• Regla visual_fidelity/hallucinated_element — todo widget interactivo generado debe trazar a un elemento real del NDS mediante una anotación // nds:<id>. UI sin anotación se reporta como posible alucinación o elemento obsoleto. Cierra el bug donde el code-gen inventaba UI ausente del NDS.
• Regla unknown_font_weight en el analizador visual_fidelity (font_weight.dart).
• Adaptador de design source markup — adapter.md documentado como fuente de diseño de primera clase junto a Figma e imagen.
• Canon de imports (core/paths/import_canon.dart) para normalizar rutas de importación al validar capas.

Cambiado #

• BREAKING (pre-1.0): /ship-qa-handoff se renombra a /ship-handoff y el artefacto qa_handoff.md a handoff.md. El pipeline es agnóstico a la fuente y el consumidor puede no tener equipo de QA; el documento sirve a cualquier verificador humano (QA o reviewer).
• Contrato de diseño 1:1 con el NDS. El code-gen realiza exactamente los elementos declarados en el NDS — ni de más (alucinación) ni de menos — y ahora permite diferir las capas data y presentation cuando el ticket no las requiere todavía.
• nds.schema.yaml reescrito a forma verificable por máquina. Antes estaba en un YAML descriptivo que el validador no podía recorrer; ahora ship validate-artifact --schema nds lo aplica de verdad. El wrapper canónico es nds.document.elements.
• Esquemas de contrato actualizados (analysis, code_review, final_report, spec, validation_report, project-config).
• Prompts del pipeline (core/commands/*) y adaptadores de code-gen / design source afinados.

Corregido #

• El code-gen alucinaba UI ausente del NDS (ahora bloqueado por hallucinated_element + contrato 1:1).
• El esquema NDS no era recorrible por el validador, por lo que validate-artifact no lo aplicaba realmente.

Lanzamiento inicial público de shipflow: un paquete de Dart + CLI que lleva cualquier proyecto Flutter desde un ticket hasta un merge request mediante un pipeline determinista y configurable. El núcleo (analyzers, matching, scaffolding) es 100% determinista; el pipeline ticket→MR está en vista previa (ver README.md → Madurez).

CLI (ship) #

Subcomandos compilables a un binario nativo (tool/compile.sh):

• ship --version / -v — imprime la versión.
• ship init — genera el skeleton de un proyecto o un .ship.yaml. --template config lo deriva de un proyecto Flutter existente leyendo pubspec.yaml y escaneando capas; cada campo lleva un comentario trazable (# inferred from …, # detected at …, # default, # PLACEHOLDER) y lo no detectado se emite como PLACEHOLDER explícito en vez de adivinarse (ADR-0012). Idempotente con --dry-run y --force. Agrega .pipeline/ al .gitignore del consumidor.
• ship analyze — ejecuta los analyzers de un gate y emite el reporte en formato legible, JSON o HTML navegable (--format html → ship-reports/, triage-first: los hallazgos bloqueantes antes que los informativos, con agrupación, filtros y búsqueda; ADR-0013). Resuelve el Dart SDK desde --dart-sdk, DART_SDK, o dart/flutter en PATH.
• ship match — resuelve color / tipografía / espaciado contra el catálogo de tokens de diseño del consumer.
• ship scaffold — genera el scaffold de un feature vía el adapter de code-gen.
• ship inventory — escanea clases de widgets y emite un inventario JSON.
• ship journal / ship context — inspeccionan el journal JSONL y construyen el context packet de una corrida.
• ship install-commands — instala de forma determinista los prompts /ship-* en tu agente (claude / gemini / codex / cursor; ADR-0021).
• Subcomandos de soporte del pipeline: redact, check-files-changed, validate-artifact, metrics, run, graph, graph-query, commands-path.

Analyzers #

Conjunto de analyzers de arquitectura, diseño y calidad: layer_integrity, package_boundary, visual_fidelity, code_complexity, build_method_complexity, flutter_antipatterns, widget_purity, widget_inventory, wiring_cohesion, state_mgmt, testing, security, performance, project_conventions, dry_detection, design_principles. Cada uno emite AnalysisIssue estructurado (severidad minor / major / critical / blocker, ruleId y suggestedFix). Validados contra un proyecto Flutter de producción para minimizar falsos positivos; varias severidades son configurables (p. ej. missing_test y missing_image_fit son informativos por defecto, y missing_test reconoce el layout espejo lib/ → test/).

Pipeline ticket → MR (vista previa) #

Prompts en markdown bajo core/commands/ orquestados por tu CLI de IA; el paquete no llama a ninguna API de IA. El pipeline lee el ticket, genera un spec, implementa cada capa, corre las compuertas por capa, revisa y crea el MR; los artefactos quedan en .pipeline/runs/<ticket_id>/. Las fases consultan un grafo de conocimiento del código provisto por dart_source_graph (ADR-0019). Un gate de reconciliación verifica que los archivos modificados coincidan con los declarados por cada fase, comparando contra el estado previo a la corrida e ignorando el estado interno del pipeline (.pipeline/).

Adapters #

Ticket sources (asana, file), design sources (figma, image, markup), code generators (riverpod_manual, bloc) y token catalog (dart_source, json). Agregar soporte = una carpeta bajo adapters/<family>/<name>/ que implemente el contrato de la familia, sin tocar el core.

Arquitectura #

• Hexagonal (Ports & Adapters): el core depende de contracts/, nunca de un adapter concreto; la selección ocurre por búsqueda de nombre en .ship.yaml en runtime. Autovalidada: PackageBoundaryAnalyzer corre sobre el propio árbol de shipflow en CI (tool/check_shipflow_boundaries.dart).
• Biblioteca de matching pura (lib/matching.dart): ΔE CIE2000, Jaccard, puntuación difusa, snap a pasos — sin I/O.
• Generación de código idempotente con rollback (ScaffoldExecutor).
• Soporte para monorepos (ADR-0011): ship init --template feature arma un paquete cuyo token catalog apunta a un design_system/ hermano.

Dependencias #

dart_source_graph: ^0.1.2, analyzer: ^13.0.0, args: ^2.7.0, crypto: ^3.0.7, path: ^1.9.1, yaml: ^3.1.3.

Configuración y documentación #

Schema de config del consumer (contracts/schemas/project-config.schema.yaml), ejemplo comentado (config/examples/sample_app.yaml), Architectural Decision Records bajo docs/adr/, recorrido visual (docs/PROJECT_WALKTHROUGH.md) y guía de adopción (docs/CONSUMER_INTEGRATION.md).

Pruebas #

645 pruebas en verde a lo largo de analyzers, adapters, resolvers, scaffolding, inventory, schema, driver y el CLI runner; invariantes de frontera de paquete autovalidados (0 violaciones).