NeoImage2Pattern

De una foto de falda sencilla a un patrón 2D auditado y un PDF imprimible. Aplicación local y de código abierto (MIT). Funciona sin IA (modo manual), con un modelo local vía Ollama o con una API compatible con OpenAI.

Patrón generado por software. Requiere comprobar la escala de impresión y confeccionar una toile/prototipo antes de utilizar tejido definitivo.

• El estado máximo que emite el programa es TOILE_CANDIDATE_UNVERIFIED: un candidato a prueba de confección.
• Ningún patrón se ha cortado ni cosido para validar este software. «Auditado digitalmente» no significa «probado físicamente».

Qué hace (y qué no)

Hace:

• Dos faldas de cintura elástica con jareta, en tejido plano estable:
  • Recta (skirt_elastic_straight_v1): el núcleo obligatorio de v1.
  • Evasé (skirt_elastic_aline_v1): bajo escuadrado a 90° con el costado y dobladillo estrecho. Solo se activa si la batería de evidencia make verify-aline pasó para el código instalado.
• Separa la IA de la geometría:
  • La IA, si la usas, solo clasifica la foto con un JSON validado y sin ningún número: rasgos visibles, inferidos (deducidos, para que los corrijas) y desconocidos. Una sola llamada por foto (más una reparación como máximo), con tokens, duración y coste estimado a la vista.
  • Tú confirmas las medidas en cm y el diseño. Si eliges otra variante que la propuesta, prevalece tu elección y queda registrado.
  • Un motor determinista genera el patrón, su propio compositor comprueba cada contorno y un auditor independiente lo audita antes de exportar. Cada regla dice qué entradas lee, de dónde sale su evidencia y con qué hashes.
• Exporta un ZIP con:
  • pattern-a4.pdf: mosaico A4 con hoja de calibración;
  • pattern-fullsize.pdf, pattern.svg y pattern.json;
  • pattern-generic-r2010.dxf: DXF genérico R2010 en mm para CAD (no es AAMA/ASTM; verificado con un lector propio);
  • audit.json, audit.html e instructions.md;
  • manifest.json con los hashes.
• Si el patrón no pasa la auditoría, no hay ZIP, pero sí un informe de rechazo descargable.
• Guarda la historia: revisiones inmutables, historial del proyecto y migración explícita de revisiones hechas con una versión anterior del motor o de las reglas.

No hace:

• No deduce medidas de la foto.
• No ajusta la prenda al cuerpo, no simula en 3D ni manda nada a fabricar.
• No admite cierres, pinzas, punto ni faldas complejas. Una foto así devuelve UNSUPPORTED_DESIGN, y solo se reinterpreta como falda básica si lo aceptas expresamente.

Puesta en marcha

Opción A: Docker (sin clave API ni GPU)

cp .env.example .env
docker compose up --build
# web: http://localhost:5173 · API: http://127.0.0.1:8000/health

Los puertos se publican solo en 127.0.0.1.

• Ollama dentro de Compose (opcional): OLLAMA_BASE_URL=http://ollama:11434 docker compose --profile ollama up
• Imagen de QA con las herramientas independientes, como Poppler: docker compose --profile qa run --rm qa

Opción B: desarrollo local

Requisitos:

• Python 3.11 y uv.
• Node 22 con npm.
• Para la suite de exportación: Poppler (pdftocairo). Por ejemplo, sudo apt install poppler-utils o micromamba install -c conda-forge poppler.

make install-locked      # uv sync --locked + npm ci (solo desde lockfiles)
make dev                 # backend en 127.0.0.1:8000 y Vite en 127.0.0.1:5173

Uso

Abre la web y sigue las cuatro secciones:

1. A · Referencia. Sube una foto (opcional), elige Manual, Ollama o API, pulsa «Comprobar conexión» (no envía la foto) y analízala: es una sola llamada, cacheada. Verás lo visible, lo inferido y lo desconocido, los tokens y el coste estimado. Corrige lo que proponga el modelo.
2. B · Medidas y diseño. Introduce cintura, cadera máxima, profundidad de cadera y largo en cm, y confírmalas. Elige recta o evasé, el tejido, la holgura, el vuelo y el elástico.
3. C · Patrón. Previsualización técnica 2D, que es la misma geometría que el PDF. Puedes iterar con «más/menos vuelo», «más larga/corta» o «Aproximar diseño» hacia un vuelo objetivo que tú indicas (sin IA), comparar revisiones, restaurar cualquiera y ver el historial del proyecto.
4. D · Auditoría y descarga. Revisa la tabla de reglas, los bloqueos (cada uno enlaza a su parámetro) y las tres dimensiones del estado. Si no hay bloqueos, descarga el ZIP.

Para imprimir:

1. Imprime solo la hoja 1 al 100 %, sin ajustar.
2. Mide el cuadrado: tiene que medir 100 × 100 mm.
3. Imprime el resto y une las hojas casando las cruces de registro.
4. Haz primero una toile con tela de prueba.

Capturas

Capturas reales de la aplicación: el backend sirve la SPA y se usa el proveedor simulado. Se hicieron con frontend/scripts/capture-screenshots.mjs.

Inicio, modos de IA y «Comprobar conexión»	Análisis: visible, inferido, desconocido, tokens y coste

Foto no soportada: reinterpretación explícita	Historial del proyecto

Patrón, cifras clave e «Aproximar diseño»	Auditoría con la evidencia de cada regla

Modos de IA

Modo	Configuración (.env del backend)	Estado verificado
Manual (por defecto)	AI_PROVIDER=none	Funciona sin red; cubierto por las pruebas automáticas
Ollama (local)	OLLAMA_BASE_URL y OLLAMA_MODEL=qwen3-vl:4b-instruct (antes, ollama pull qwen3-vl:4b-instruct)	Adaptador probado en vivo (Ollama 0.40.6, qwen3-vl 4B y 2B «instruct», CPU): JSON válido a la primera y tokens registrados. La clasificación no es fiable con esos modelos: ningún caso salió ANALYZED y todo pasó a confirmación manual (docs/LIVE_AI_RESULTS.md)
API compatible OpenAI (remota)	AI_API_BASE_URL, AI_MODEL y AI_API_KEY	Adaptador probado en vivo contra un servidor compatible (la API /v1 de Ollama), no contra la API de OpenAI. La clave nunca llega al navegador; se pide consentimiento en cada envío

• No hay paso automático de local a remoto.
• «Probado en vivo» queda ligado al hash del código que se probó (backend/app/providers/live_evidence.json); si el adaptador cambia, vuelve a «sin probar». Tu instalación concreta se comprueba con «Comprobar conexión».
• Coste: solo se estima si defines AI_PRICE_INPUT_PER_1M y AI_PRICE_OUTPUT_PER_1M; Ollama no cobra por token.
• Pruebas reales opt-in, excluidas de CI: cd backend && LIVE_OLLAMA=1 uv run --locked pytest -m live. Para la API usa LIVE_OPENAI=1 en lugar de LIVE_OLLAMA=1; LIVE_WRITE_EVIDENCE=1 registra la evidencia.

Calidad y evidencia

make lint            # ruff + tsc
make typecheck       # mypy --strict + tsc
make test            # suites core, export, workflow y mutation + vitest
make e2e             # Playwright contra el backend real (proveedor simulado)
make smoke           # F01 por HTTP real: proyecto → auditoría → exportación → hashes y PDFs
make verify-export   # oráculos independientes (Poppler + PDFium) sobre ZIPs F01/F02
make verify-aline    # evidencia A1–A5 y puerta de activación de la evasé
make license-check   # inventario de licencias + SBOM
make audit-deps      # vulnerabilidades conocidas (pip-audit + npm audit)
make system-check    # sistema, arquitectura, memoria, disco y permisos
make golden-check    # golden files versionados (cambios: scripts/update_golden.py --reason "…")
make preflight       # todo lo anterior → PRE_FLIGHT_REPORT.{json,md} y TEST_RESULTS.md
make ci-clean        # clona el commit en limpio, instala desde locks y ejecuta preflight

Resultados reales de la última ejecución:

• TEST_RESULTS.md: resultados por suite, criterios AC01–AC23 y matriz de mutaciones.
• PRE_FLIGHT_REPORT.md: comandos ejecutados, códigos de salida y estados M0–M9 / A1–A5.

Lo que aparece como NOT_RUN o UNTESTED_LIVE no se ejecutó en ese entorno. Por ejemplo, Docker no estaba instalado en la máquina de desarrollo y se verifica en CI.

Estructura

backend/   FastAPI + motor (app/geometry), motores tras PatternEngine (app/engines), auditor
           independiente (app/audits), exportación y verificación (app/export), proveedores de IA,
           SQLite (app/db), MCP opcional (app/mcp_tools.py, app/mcp_server.py)
frontend/  React + Vite + TypeScript (4 secciones), Vitest y Playwright
scripts/   smoke, preflight, verify_exports, verify_aline, verify_garmentcode, license_check, audit_deps,
           system_check, update_golden, gen_docs, create_demo_fixture, setup_garmentcode
docs/      ARCHITECTURE, API, AUDIT_RULES, AUDIT_TOLERANCES, PATTERN_CONVENTIONS,
           MANUFACTURING_LIMITATIONS, ALINE_CONSTRUCTION_REVIEW, SECURITY, RESEARCH, GARMENTCODE,
           LIVE_AI_RESULTS, TROUBLESHOOTING, CHANGELOG, OSS_LICENSES
qa/        imagen Docker con las herramientas de QA (Poppler)

Limitaciones conocidas y pendientes

• Validación física: ninguna (NOT_TESTED). Sigue el protocolo de docs/MANUFACTURING_LIMITATIONS.md.
• Elástico: la longitud 0,90 × cintura + solape es una propuesta. Sin la extensión útil medida, el resultado es solo una toile (ELASTIC_STRETCH_UNVERIFIED).
• Evasé: el embebido del vuelto curvo se cuantifica con un umbral heurístico. El modelo de plegado no se ha validado con un patronista (NO_EXTERNAL_PATTERN_ORACLE).
• IA: los modelos locales pequeños probados (qwen3-vl 2B/4B) repiten elementos y confunden los dibujos de prueba; el sistema lo detecta y pide confirmación, pero la tasa de acierto no está medida (requiere un dataset etiquetado).
• Extras opcionales, con alcance limitado:
  • motor GarmentCode experimental (desactivado por defecto): solo la falda recta; su evasé no escuadra el bajo y se rechaza (docs/GARMENTCODE.md);
  • DXF genérico R2010: no es AAMA/ASTM y no se ha probado en un CAD comercial;
  • servidor MCP (make mcp): envoltorio de la API local, no un segundo motor.
• No implementado: adaptador FreeSewing, segundo LLM para texto libre y autenticación para uso en LAN.

Licencia

Código propio bajo licencia MIT (LICENSE). Las dependencias y sus licencias están en docs/OSS_LICENSES.md y sbom.json. Poppler (GPL) se usa solo como herramienta de QA y no se distribuye.