Que s’espera que faci un producer d’OSIRIS JSON
Els producers d’OSIRIS JSON son el punt on l’estandard es torna real.
Les directrius per a producers i la documentacio de l’SDK per a producers ho fan explicit. Un producer no es nomes un parser que casualment emet JSON. Es el limit on inventaris propietaris es tradueixen a un snapshot d’OSIRIS determinista, portable i segur del qual altres eines puguin refiar-se.
Un producer es un traductor de nomes lectura
El primer punt important de la guia per a producers es allo que un producer no es.
No aprovisiona infraestructura. No modifica dispositius. No inventa dades que falten. No reinterpreta l’especificacio. La feina d’un producer es mes estreta i mes estricta: descobrir allo que existeix, normalitzar-ho a OSIRIS, eliminar dades insegures o irrellevants i emetre un snapshot que pugui ser validat per la toolchain canonica d’OSIRIS.
Sona obvi, pero es la linia correcta. En el moment en que els producers comencen a comportar-se com a plans de control, o comencen a incrustar idees personalitzades del que significa OSIRIS, la interoperabilitat es trenca.
El flux de treball del producer es deliberat
La documentacio descriu el cicle de vida del producer en quatre passos: discovery, normalization, redaction i emission.
Aquesta sequencia importa perque cada etapa te una responsabilitat diferent:
- discovery recull dades del vendor o de la plataforma
- normalization les mapeja a estructures estandard d’OSIRIS
- redaction elimina secrets, PII i soroll inutil
- emission serialitza el document i el valida abans de publicar-lo
La guia tambe deixa espai per a la realitat. Els inventaris parcials son acceptables. Les fallades individuals de discovery normalment s’haurien de registrar i ometre en lloc de fer fallar tota l’exportacio. Pero aquesta flexibilitat s’atura al limit de seguretat: si es detecten secrets, s’espera que el producer falli de manera segura.
El determinisme es una funcionalitat, no un acabat
Un dels temes mes forts en tots dos documents es el determinisme.
S’espera que els ID de recursos, connexions i grups siguin estables entre execucions. La documentacio per a producers insisteix molt a evitar aleatorietat, ordenacions inestables i noms ad hoc. La rao es directa: si el mateix entorn produeix una sortida diferent cada vegada, els diff, la correlacio i l’automatitzacio aigues avall deixen de ser fiables.
L’SDK reforca aixo amb ajudes concretes:
- generacio determinista d’ID a partir de claus canoniques
- gestio de collisions en dues fases mitjancant un
IDRegistry - un
DocumentBuilderque gestiona$schema,version, les metadades del generator i una sortida topologica ordenada - helpers de prova que comproven el determinisme byte a byte i la consistencia dels golden files
Aquesta es una de les senyals mes clares que OSIRIS s’esta dissenyant per a tooling de llarga durada, no per a exportacions puntuals.
La seguretat es responsabilitat del producer
Les directrius per a producers son igual de fermes respecte de la redaccio.
Els documents OSIRIS no han de contenir credencials, tokens, claus privades ni cadenes de connexio amb secrets incrustats. S’espera que els producers analitzin patrons comuns abans de l’emissio, descomponguin els valors insegurs en lloc de copiar-los sencers i triin un mode de fallada explicit.
El valor predeterminat recomanat es fail-closed. Existeix un mode log-and-redact d’activacio explicita, pero fins i tot aqui les regles continuen sent estrictes: no registrar mai el valor secret en si, marcar sempre el document com a redactat i no permetre mai que la redaccio passi en silenci.
Aquesta es la postura correcta. Els producers son el punt mes proper als sistemes font en brut, i aixo els converteix en el lloc mes perillos on actuar amb negligencia.
L’SDK hi es per eliminar la deriva
L’SDK de producers en Go no es presenta com a infraestructura magica. Es presenta com una manera d’aturar la deriva dels producers.
Estandarditza el contracte Collect(ctx), proporciona context d’execucio compartit, factories de recursos i relacions, helpers de normalitzacio, builders deterministes i un harness de proves. Igual d’important, es nega a convertir-se en un segon validador. L’SDK no es propietari dels diagnostics V-* i no importa @osirisjson/core com a biblioteca. Els producers validen la sortida cridant la CLI canonica com a pas extern.
Aquesta separacio es arquitectonicament solida. Manté la logica de mapatge als producers i la logica de validacio al motor compartit d’OSIRIS.
La confianca ve de les proves
El missatge final de la documentacio per a producers es que la sortida d’un producer ha de ser reproduible i revisable.
Els golden files es tracten com la defensa principal contra regressions. El flux de treball esperat es simple: simular l’entrada del vendor, generar el document OSIRIS, comparar-lo amb el golden file i despres validar aquell artefacte amb la CLI canonica sota el perfil strict. El harness de proves de l’SDK afegeix helpers per a aquest flux i per a reexecucions deterministes amb rellotges i fixtures fixos.
Aixo importa perque la qualitat d’un producer no consisteix nomes en si l’exportacio “funciona una vegada”. Consisteix en si la mateixa entrada continua produint una sortida fiable a mesura que evoluciona l’ecosistema.
Llegir la documentacio de producers
La guia per a producers esta disponible a la seccio d’arquitectura de la documentacio: