Saltar a contenido

DPP: Cadena de propiedad + ciclo de vida — Nota de DISEÑO

Arte Taxco · 27 Julio 2026 · DISEÑO (no construido) · feed para el chat de interoperabilidad

Estado: esto es diseño, no está construido. Decisión de Marco (27 jul): solo diseñar y documentar, no tocar código ni la carta todavía. Este doc captura el modelo para que (a) alimente el chat de interoperabilidad y (b) sea la base cuando se decida construir. El estado real de lo que HOY existe está en ARQUITECTURA-DPP-OFERTAS-ESTADO-REAL.md.

0. La idea

El DPP debe registrar el ciclo de vida completo de la pieza: quién la posee (cadena de propietarios) y qué le pasa (pulido, reparación, reventa). Hoy la propiedad es un campo único que se sobreescribe (ownerName/Email/Phone/ ownerRegisteredAt) y el registro es manual y por pieza. La visión requiere:

  1. Propietario #1 automático = el comprador (ya tenemos sus datos).
  2. Actualización de propiedad por el dueño vía el QR de la carta (caso regalo, corrección, transferencia) → propietario adicional, no reemplazo.
  3. Eventos de ciclo de vida que el comprador puede declarar (pulido, reparación, reventa), distinguiendo declarado vs verificado.
  4. Explicación del DPP + contexto ESPR para el comprador.

1. Dos ejes que NO hay que mezclar

Eje Qué modela Mecanismo hoy Cuándo cambia
Linaje del CERTIFICADO Re-emisión del certificado en una reventa verificada por AT Certificate.certAntecesorId (self-relation) + origenCircular Solo cuando AT recertifica (reventa por la plataforma)
Cadena de PROPIETARIOS Quién posee la pieza a lo largo del tiempo Campos owner* únicos (se sobreescriben) Regalo, corrección de nombre, transferencia — sin emitir certificado nuevo

Un regalo o una corrección de nombre no emiten certificado nuevo: solo agregan un propietario. Por eso la cadena de propietarios es un registro aparte, más ligero que el linaje de certificados.

2. Modelo propuesto — RegistroPropietario

Tabla nueva (aditiva; nunca migrate dev), un registro por evento de propiedad:

RegistroPropietario
  id
  certificadoId   → Certificate (FK)
  ownerName, ownerEmail, ownerPhone
  geo?            { lat, lng, etiqueta }   ← OPCIONAL y PRIVADO (ver §6)
  tipo:           COMPRADOR | PROPIETARIO | TRANSFERENCIA
  esActual:       Boolean
  registradoEn:   DateTime
  fuente:         SHOPIFY | MELI | MANUAL
  • COMPRADOR — creado automáticamente al pagarse (propietario #1).
  • PROPIETARIO — auto-registro por el dueño vía QR (regalo/corrección).
  • TRANSFERENCIA — cambio de dueño por reventa a través de AT (se sincroniza con la recertificación con linaje del flujo de ofertas).

esActual marca al propietario vigente (uno solo por certificado). El histórico se conserva completo (requisito DPP) pero redactado en público (§6).

Alternativa mínima (v1) sin tabla: reutilizar los campos owner* actuales + el AuditLog OWNER_REGISTERED que ya existe como historial. El propietario #1 se llena automático; "actualizar" reemplaza y el AuditLog guarda la traza. La carta ya sería verdadera. La cadena visible de propietarios se difiere a v2 (la tabla). Recomendación: decidir v1 vs v2 junto con el chat de interoperabilidad, porque el formato destino (Verifiable Credentials / JSON-LD, ver MAPA-ECOSISTEMA- DPP.md) favorece la tabla desde el inicio (cada registro = una claim firmable).

3. Propietario #1 automático

  • Origen de datos (ya lo capturamos): Shopify → buyerName, buyerPhone, shippingAddress (webhook orders/paid). MELI → nombre + dirección (enriquecerCertificadosDesdeOrdenMeli). Falta el email en MELI (revisar).
  • Cuándo: al crear el Certificate (webhook Shopify / enriquecimiento MELI).
  • Efecto: la carta puede afirmar con verdad "registrada a nombre de [comprador] como su primer propietario". Sin esto, la carta mentiría — es la dependencia que bloquea el cambio de copy.

4. Actualizar el registro (regalo / corrección / transferencia)

/registrar/{folio} evoluciona de "registrar" a "registrar / actualizar propietario":

  • Muestra el propietario actual (anonimizado) y "¿Eres tú el propietario? Actualiza el registro a tu nombre."
  • Al actualizar: agrega un RegistroPropietario (tipo PROPIETARIO), marca esActual, conserva el anterior.
  • Caso regalo: el comprador recibe la pieza para regalar; el destinatario escanea el QR y se registra → cadena: comprador → propietario real.
  • Ya existe la cascada por compra (registrar un folio registra las piezas hermanas del mismo shopifyOrderId — FEAT-ENVIOS-001). Mantener ese comportamiento para el auto-registro y para la actualización.

5. Eventos de ciclo de vida por el comprador — declarado vs verificado

El comprador podría declarar eventos ("llevé a pulir", "la reparé", "la revendí"). Regla dura del DPP (anti-sobreafirmación):

  • Lo que declara el dueño = estatus DECLARADO (sin prueba).
  • Lo que AT constata al tener la pieza = VERIFICADO/MEDIDO.
  • Nunca presentar un declarado como verificado.

Encaja con lo ya diseñado en MAPA-ECOSISTEMA-DPP.md (transversal "atributos con estatus epistémico": {clave, valor, estatus (declarado|verificado|medido), emisor(rol), fecha, víaEvento}). Base existente: EventoInventario (EPCIS 2.0), historial circular (lib/circular/historial.ts), tipos R (REPARADO, MANTENIMIENTO, REMANUFACTURADO, RECICLADO). Lo nuevo sería un write-path del comprador (hoy solo AT/actores escriben eventos), marcado como DECLARADO.

6. Privacidad — alertas fuertes (LFPDPPP + GDPR + doble-ciego académico)

  • Geolocalización del dueño = PII sensible. Requiere consentimiento explícito y finalidad limitada. Recomendación: opcional, privada, y en el DPP público mostrar como mucho una región (estado), nunca un pin exacto. Sugerencia: diferirla a la fase de interoperabilidad (otro chat), no en el primer corte.
  • Propietarios anteriores SIEMPRE redactados en público (ya lo dice el schema). El DPP público muestra: propietario actual anonimizado (iniciales) + "Nº de propietario" (p. ej. "2º propietario"), no la cadena con nombres.
  • Anonimato del equipo AT (POLITICA-ANONIMATO-001): ningún nombre personal del equipo en la carta ni en la página; todo firma "Arte Taxco".
  • El email del comprador MELI puede faltar → el registro debe tolerar ausencia de email (hoy crearOferta/portal usan ownerEmail || buyerEmail).

7. Impacto en la CARTA (copy propuesto — NO aplicado)

Reemplazaría la sección "REGISTRA TU COMPRA" por algo como:

TU PASAPORTE DIGITAL (DPP) Registramos tu compra a nombre de [comprador] como su primer propietario. Si el propietario real es otra persona (por ejemplo, un regalo), esa persona puede registrarla a su nombre escaneando el QR de cada pieza y actualizando el propietario. Cada vez que la lleves a pulir, la repares o la revendas, regístralo aquí también: así el pasaporte guarda toda la vida de tu joya. Este sistema responde a la nueva regulación europea de Pasaporte Digital de Producto (Reglamento UE 2024/1781, ESPR). certificados.artetaxco.mx/registrar/{folio}

Pendiente de aplicar (bloqueado por el auto-registro del propietario #1, §3).

8. Impacto en la RUTA DEL VISITANTE (NO aplicado)

  • /certificado/{folio} (DPP público): renderizar el propietario actual anonimizado + "Nº de propietario" (hoy NO se muestra — gap documentado en ARQUITECTURA-DPP-OFERTAS-ESTADO-REAL.md §1) + un explicador breve del DPP/ESPR.
  • /registrar/{folio}: pasar a "registrar / actualizar propietario" (§4), con el botón "Actualizar registro" y, si se decide, geo opcional (§6).

9. Fases sugeridas (para el chat de interoperabilidad)

  1. P1 — Propietario #1 automático (mínimo: reusar campos + AuditLog; o tabla). Desbloquea la carta.
  2. P2 — Actualizar registro (regalo/corrección) → propietario adicional.
  3. P3 — Mostrar propiedad + explicador DPP/ESPR en la página pública.
  4. P4 — Eventos de ciclo de vida declarados por el comprador (estatus epistémico).
  5. P5 — Geo opcional + export/portabilidad (Verifiable Credentials, Data Act) → converge con el frente de interoperabilidad y el acto delegado ESPR.

Cada fase es aditiva al schema. La decisión v1 (reusar campos) vs v2 (tabla RegistroPropietario) conviene tomarla junto con el diseño de interoperabilidad, porque el formato destino (VC/JSON-LD firmables) empuja a la tabla desde P1.

10. Preguntas abiertas (para decidir con el otro chat)

  • ¿v1 (campos) o v2 (tabla RegistroPropietario) desde el inicio?
  • ¿Se recolecta geolocalización? ¿Con qué finalidad declarada y qué se muestra?
  • ¿El comprador puede declarar eventos de ciclo de vida, o solo AT/actores los registran? (afecta la superficie de escritura y el modelo de confianza)
  • ¿La transferencia de propiedad por reventa-AT (TRANSFERENCIA) se auto-sincroniza con la recertificación con linaje del flujo de ofertas?

Arte Taxco · Nota de diseño (no construido) · 27 Jul 2026 · complementa ARQUITECTURA-DPP-OFERTAS-ESTADO-REAL.md y MAPA-ECOSISTEMA-DPP.md.