Saltar a contenido

Prompt T-3(b) — Conformidad EN de lo ya emitido (Digital Link · PDF/A-3 · API)

Arte Taxco / ICEDE-USC · 1 Ago 2026 · prompt acotado para el chat de código. Paridad con PROMPT-T0-PERFIL-TEXTIL.md, PROMPT-T1-ESQUELETO-TEXTIL.md, PROMPT-T3-FIRMA-DIDWEB.md.

Alcance de este chat. Endurecer a NORMA lo que el DPP ya emite, SIN cambiar su semántica: identificador EN 18219 (GS1 Digital Link), archivo EN 18221 (PDF/A-3 estricto), e interfaces EN 18216/18222 (API especificada). La firma did:web (EN 18246) ya se hizo en T-3(a). Es "endurecer lo emitido", no construir capacidad nueva. Cada paso es independiente y shippable por separado: si el chat se alarga, corta por paso.

⚠️ Regla de oro de este chat (anti-sobreafirmación): una afirmación de conformidad se VALIDA con una herramienta de conformidad real, no se asevera. PDF/A-3 → veraPDF en verde; Digital Link → validador GS1 / resolución real; API → un linter OpenAPI. Sin validador que lo respalde, se documenta como "compatible con", no "conforme a". Misma disciplina que "EPCIS serializable≠emisor" y "joyería≠textil".

Eres el asistente técnico del proyecto Arte Taxco. Antes de tocar nada, LEE en este orden: - docs/SYSTEM-PROMPT.md, docs/FIXES.md (reglas; español; aditivo; NUNCA prisma migrate dev) - docs/RUTA-DEMOSTRADOR-TEXTIL.md (la ruta; §1 Anexo A.1 mapea cada capa a su norma EN; T-3 "Conformidad EN") - docs/PROMPT-T3-FIRMA-DIDWEB.md (T-3a ya hecho: qué quedó dentro y qué se dejó a T-3b) - docs/MAPA-ECOSISTEMA-DPP.md y docs/DECISIONES-INTEROPERABILIDAD-DPP.md (dos ejes; gates) - apps/web/lib/dpp/export.ts (emisor XML/EPCIS/PDF/VC; construirDppPdf es ZUGFeRD-style, hoy SIN XMP/OutputIntent — el delta PDF/A-3) - apps/web/app/api/dpp/[folio]/route.ts y apps/web/app/api/verify/[folio]/route.ts (las dos superficies HTTP a especificar contra norma) - apps/web/lib/thermal-receipt.ts (QR actual: CERT_BASE_URL/{folio}, vía api.qrserver.com) - apps/web/public/dpp/dpp-1.0.xsd (por si algún paso lo extiende, aditivo)

CONTEXTO: T-0..T-2/T-3a dejaron el DPP textil FUNCIONAL: perfil, cadena de atestación, export XML/EPCIS/PDF/VC y firma did:web. Lo que falta de T-3 es conformidad formal a las normas EN 1821x de lo YA emitido — que un tercero (auditor, evaluador, otra plataforma) valide la interoperabilidad con herramientas estándar, no de palabra. No se añade dato nuevo al pasaporte; se endurece su envoltura.

DECISIÓN GATING A RESOLVER ANTES DEL PASO 0 (no asumir): GS1 Digital Link exige claves GS1 (GTIN + serie por AI 21), que requieren membresía GS1 (prefijo de compañía). Arte Taxco hoy NO tiene prefijo GS1. Dos caminos honestos: (a) construir un resolver Digital Link conforme que PARSEA/RESUELVE URIs GS1 Digital Link y sirve el DPP — sin emitir GTINs propios (se documenta que emitir claves conformes es institucional/gated a membresía GS1); o (b) esperar a tener prefijo GS1 y emitir identificadores plenamente conformes. Recomendado para el demostrador: (a) — el nodo "solo resuelve" (RUTA §1). El prompt asume (a); si el dueño consigue prefijo GS1, se sube a (b) sin reescribir el resolver.

TAREA T-3(b) — en pasos, cada uno con su commit (independientes; ordenar por valor):

0) IDENTIFICADOR GS1 DIGITAL LINK (EN 18219). - Resolver conforme: una ruta que acepte una URI GS1 Digital Link (p. ej. /01/{gtin}/21/{serie} o el esquema admitido) y redirija/resuelva al DPP del folio correspondiente (mapeo folio↔Digital Link en una columna aditiva o derivado). - El QR de la carta (thermal-receipt.ts) pasa a portar la URI Digital Link (no el folio suelto), manteniendo retrocompat con el link actual. - VALIDAR con el resolver/validador GS1 Digital Link (o la sintaxis oficial). Documentar que la EMISIÓN de GTINs conformes requiere membresía GS1 (gated) — el nodo resuelve.

1) PDF/A-3 ESTRICTO (EN 18221). - Endurecer construirDppPdf: añadir XMP (metadatos + marca PDF/A-3B) y OutputIntent (perfil ICC), manteniendo el XML embebido (AFRelationship=Data). - pdf-lib no hace PDF/A-3 nativo: inyectar XMP + OutputIntent + object structure requerida (evaluar pdf-lib + parche manual, o una lib que lo soporte). Aditivo: el f=pdf sigue sirviendo, ahora conforme. - VALIDAR con veraPDF (PDF/A-3B) en verde. Sin veraPDF verde, NO declarar "PDF/A-3"; dejar el comentario anti-sobreafirmación vigente hasta que pase.

2) API ESPECIFICADA CONTRA NORMA (EN 18216 / EN 18222). - OpenAPI 3.1 de las dos superficies (GET /api/dpp/{folio}?f=…, GET /api/verify/{folio}): esquemas de respuesta, content-negotiation, códigos, y el /.well-known/did.json. Servir el spec (p. ej. /api/openapi.json). - Alinear headers/negociación con la norma (tipos de contenido correctos ya presentes: application/ld+json EPCIS, application/xml, application/pdf, VC-JWT JSON). - VALIDAR el spec con un linter OpenAPI (p. ej. redocly lint / spectral). Mapear en un comentario cada endpoint a la cláusula EN 18216/18222 que cumple.

3) PORTADOR DE DATOS (EN 18220) — REVISIÓN, sin desarrollo. - Revisar el QR/Data Matrix actual contra EN 18220 (tamaño, corrección de errores, contenido = Digital Link del paso 0). Documentar conformidad/gap en FIXES.md; NO construir salvo un ajuste trivial del generador si la revisión lo exige.

RESTRICCIONES DURAS: - 100% aditivo. Cambios de schema (si el mapeo Digital Link necesita columna): npx prisma db push, NUNCA migrate dev. (Gotcha 5432: aplicar desde hotspot con URL directa.) - No cambies la SEMÁNTICA del DPP (atributos, estatus, nivelExigido, firmas): esto endurece la ENVOLTURA, no el contenido. No toques joyería ni el flujo de recertificación. - Conformidad = validada, no aseverada (veraPDF / validador GS1 / linter OpenAPI). Si un paso no pasa su validador, se documenta como pendiente, no como hecho. - Añadir dependencias solo si son puras JS (sin binarios nativos frágiles en Vercel); veraPDF puede correrse como paso de verificación local/CI, no en runtime. - Español en código, comentarios y commits. Documenta en docs/FIXES.md (sugerido FEAT-DPP-TEXTIL-T3B-001) y actualiza la tabla del Anexo A.1 en RUTA-DEMOSTRADOR-TEXTIL.md (marca qué capas pasan a "conforme validado").

CRITERIO DE ACEPTACIÓN: - npx tsc --noEmit → 0 errores. - PDF/A-3: f=pdf de una pieza pasa veraPDF (PDF/A-3B) en verde; el XML sigue embebido y extraíble. - Digital Link: una URI GS1 Digital Link resuelve al DPP correcto; el QR de la carta la porta; documentado el gate de emisión de GTIN (membresía GS1). - API: el OpenAPI valida con el linter y describe fielmente ambas superficies; servido en un endpoint. - Joyería y recertificación intactas; el DPP existente (XML/EPCIS/VC) no cambia de forma. - MUÉSTRAME EL DIFF ANTES DE HACER PUSH. Dame el comando de commit explícito, en español.

FUERA DE ALCANCE (otras fases — NO los hagas aquí): - Emitir GTINs GS1 conformes (requiere membresía GS1 — institucional). - DIDs por-actor, W3C Data Integrity (siguen en la cola de firmas post-T3a). - Verificación con laboratorio (T-2), endpoint de la planta de clasificación (T-4). - eIDAS/EUDI wallet, revocación de credenciales, timestamping cualificado. - Rediseño de la superficie pública /certificado/{folio} (es UI, no conformidad).

Decisiones (resueltas para este chat)

  • Digital Link → resolver conforme sin emitir GTINs (camino (a)); emitir claves GS1 es institucional (membresía). El nodo resuelve; se sube a plena conformidad al tener prefijo.
  • PDF/A-3B (no 3A/3U): nivel Basic es suficiente para "archivo + adjunto"; subir a 3U (Unicode) si un evaluador lo pide.
  • Conformidad validada con herramienta (veraPDF, validador GS1, linter OpenAPI) como condición de "hecho" — nunca autoafirmada.
  • Pasos independientes: si el chat se alarga, cada paso (Digital Link / PDF/A-3 / API) es su propio entregable y su propio commit; se pueden repartir en chats distintos.

Arte Taxco / ICEDE-USC · Prompt T-3(b) conformidad EN · 1 Ago 2026 · alcance, no implementación. Complementa T-3(a) (did:web) y cierra la fila "Conformidad EN" de la ruta.