Importación, origen y distribución

Importación: lo que se escribe, lo que nunca se escribe

Importar un match, una posición u otra base añade lo que falta; no reemplaza lo que ya está ahí.

Una posición nunca se duplica. Es su identidad — fichas, cubo, dados, marcador — la que la reconoce, nunca el archivo del que proviene: la misma posición encontrada en dos partidas sigue siendo una sola fila.
Importar una base relee todo lo que escribe una exportación. Las posiciones, con sus análisis y comentarios, pero también las partidas (juegos y jugadas incluidos), los torneos con su Dirección y su Encuentro, los borradores de transcripción, los alias, las colecciones, las lecciones y los mazos Anki: véase Fusionar una base de datos. No se sobrescribe nada: una partida ya presente no se vuelve a copiar, un torneo del mismo nombre recibe las partidas sin cambiar la fecha del evento (su fecha de última modificación avanza, puesto que recibe partidas nuevas), un torneo que ya tiene su Dirección la conserva y queda fuera del Encuentro importado, una partida ya archivada en otro torneo o en otro lugar del cuadro se queda allí, y lo que la base ya decidía sigue decidido por ella. Los torneos, Direcciones, Encuentros, borradores de transcripción y alias creados por la importación conservan sus fechas de origen; las colecciones, lecciones y mazos Anki creados no las conservan.
Un análisis por motor. eXtreme Gammon, GNUbg, BGBlitz y el evaluador integrado conviven en una misma posición, y el panel Análisis indica el origen de cada uno. Importar uno no borra el otro.
Un análisis importado nunca se recalcula. blunderDB lo guarda tal cual, con su etiqueta de nivel (« 3-ply », « XG Roller++ », « Book »), sus equities, sus errores, sus probabilidades y la suerte de la tirada. La regla es « una evaluación solo rellena un hueco »: el análisis automático tras la importación solo visita las posiciones sin ningún análisis, y el reanálisis de los análisis gammonNet obsoletos deja intacta toda posición que lleve un análisis importado (véase Configuración).
Reimportar un partido ya presente solo aporta lo más profundo. El partido se reconoce por su juego (jugadores, longitud, dados, jugadas, cubo), no por su análisis: no se reescribe ningún partido, partida ni jugada. Se añaden las marcas puestas en el programa de origen, y un análisis más profundo que el guardado lo sustituye, posición por posición — una versión Roller++ del mismo partido sustituye a la versión 3-ply, sea cual sea el orden de importación; a profundidad igual o menor, el análisis guardado permanece. Reimportar el mismo archivo no reescribe, por tanto, nada. El informe de importación distingue los duplicados que no aportaban nada de los que han profundizado análisis. En línea de comandos, --skip-duplicates omite un duplicado sin tomar de él nada más que las marcas. Un partido truncado y luego completado (más partidas) no es el mismo partido: se importa como un segundo partido.
Un análisis ilegible no impide importar la partida. Una decisión cuyo análisis contiene un valor que no es un número finito (NaN o infinito, que llevan algunos archivos XG) se importa sin ese análisis; el resto de la partida entra con normalidad, y el informe de importación cuenta las decisiones afectadas.
Un partido ya presente con otros nombres se señala, nunca se fusiona. Las dos huellas de partido incluyen los nombres de los jugadores: «Martin A.» y «Alice Martin» hacen dos partidos. La importación también compara los dados (longitud, marcador inicial, dados de cada partida) y señala, bajo la línea del archivo y en el informe, el partido ya presente en la base con otros nombres cuyos dados tiene. blunderdb repair --duplicates lista estos pares en una base existente, así como los partidos truncados y su versión más larga.
Un nombre conocido con otra grafía se registra con su nombre canónico. Un alias dice que «Martin A.» es otra grafía de «Alice Martin» (o que un nombre de evento es otra de otro). Al importar, los nombres de los jugadores y del evento se sustituyen por su nombre canónico, y la partida se guarda en el torneo del evento canónico. Las huellas de la partida conservan los nombres del archivo: un archivo importado antes de que exista su alias se reconoce, pues, siempre. Una partida cuyos dados son los de una partida de la base, y cuyos nombres solo difieren por alias conocidos, no es una segunda partida: sus análisis enriquecen la que está guardada.

Los alias se gestionan en la pestaña Corpus de los ajustes: elegir Jugadores o Eventos, introducir el alias y el nombre canónico, o quitar un alias de la lista. Proponer enumera los nombres que solo difieren en mayúsculas, acentos, puntuación u orden de las palabras; no se aplica nada sin hacer clic en Aplicar. La misma pestaña incluye la casilla Omitir duplicados al importar (el equivalente de --skip-duplicates, para la sesión) y la búsqueda de los duplicados probables de una base existente, la de blunderdb repair --duplicates: cada pareja se da por sus números de partida, no se fusiona nada. Bajo una pareja con los mismos dados, Crear estos alias registra con un clic los alias de jugador que harían que los dos partidos nombraran a los mismos jugadores, pasando la grafía del partido más reciente a ser el alias: una sola propuesta cuando un nombre es común a ambos, si no dos — asiento por asiento, luego cruzada — entre las que se elige la que dice quién es quién. En línea de comandos: blunderdb players alias y blunderdb events alias.

Una carpeta se importa en paralelo. Los archivos se leen en varios núcleos a la vez y se escriben por grupos, siempre en el orden de la carpeta: los números de partida no dependen de la máquina. Un archivo idéntico, byte a byte, a un archivo ya leído de la misma carpeta no se vuelve a leer: cuenta como duplicado. Cancelar detiene la importación en el grupo en curso; lo que ya estaba escrito se queda.
El progreso se lee en posiciones por segundo. La ventana de importación muestra el porcentaje leído, el ritmo, el tiempo restante estimado y los recuentos en curso (importados, duplicados, con error). Minimizar la guarda en la barra de estado, desde donde una pastilla la vuelve a abrir: la importación continúa mientras usted trabaja, y la ventana vuelve sola con el informe al final. Se listan los cien primeros errores; los siguientes se cuentan, y el registro de la aplicación los nombra todos. En la línea de comandos, blunderdb import --type batch muestra el mismo progreso en la salida de error, y --format json lo devuelve en el objeto final (progress).
Cada archivo de una importación queda registrado, y una importación interrumpida se puede reanudar. Para cada archivo, el registro del lote guarda la ruta, el tamaño, la fecha de modificación, la huella SHA-256 y el resultado: partida nueva (con su número), duplicado (con la partida que lo cubre), partida enriquecida o error (con el mensaje). Una importación cancelada o cortada se continúa sin repetir lo ya decidido: un archivo con la misma ruta, tamaño y fecha se omite sin leerse; un archivo con el mismo contenido se lee pero no se analiza; un archivo con error se reintenta. En la aplicación, la ventana de fin de importación lista el registro (un archivo por línea, con su resultado y el mensaje de un error; un archivo reintentado muestra su último resultado), y una línea que dio una partida la abre. Una importación cancelada deja la ventana abierta con el botón Reanudar. En la línea de comandos, blunderdb import --type batch --dir <carpeta> --resume <lote> reanuda el lote cuyo número se mostró al inicio de la importación, y --format json devuelve el registro en el objeto final (journal). El servidor acepta resume en la petición de imports.batch y devuelve el registro mediante imports.files. El registro es un dato de la importación: abrir o leer una base no escribe nada en él.
Una importación cortada por la parada de la aplicación se reanuda desde la ventana. El comando :resume lista las importaciones que nada ha terminado; se elige la que continuar y se indica de nuevo la carpeta o los archivos, como --dir en la línea de comandos. El diario del lote decide qué no se vuelve a leer.
Una carpeta grande se importa en modo masivo. A partir de 200 archivos, blunderDB escribe con una caché mayor y menos puntos de control. Si la base aún no contiene ninguna posición, va más lejos: los índices de búsqueda solo se reconstruyen al final y las escrituras ya no se sincronizan con el disco. Un corte de corriente durante una importación así puede entonces dañar la base: hay que recrearla y relanzar la importación. Un cierre brusco del programa, en cambio, solo deja índices ausentes, que la siguiente apertura reconstruye (el registro lo indica).
Lo que blunderDB nunca escribe: una suerte recalculada — se lee del archivo de origen o queda desconocida — y un rollout que no ha lanzado él mismo: los datos de rollout de un archivo .xg no se abren. Solo se almacenan los rollouts que produce blunderDB (Rollouts), junto al análisis.

Panel de Metadatos

El panel Metadatos (CTRL-M) muestra la información general de la base de datos actual: Usuario, fecha de creación (Creado), Versión del esquema y Descripción. El usuario, la fecha y la descripción se modifican en el sitio y se guardan al salir del campo; la versión es de solo lectura. También accesible mediante el comando meta.

También muestra, cuando existe, el origen de la base de datos — véase Distribuir una base de datos: origen y contraseña. Una base de datos corriente no muestra esa sección.

Distribuir una base de datos: origen y contraseña

Un profesor que distribuye una base de posiciones dispone de dos mecanismos, independientes entre sí, ambos opcionales y elegidos en el momento de la exportación: marcar el archivo con su origen y protegerlo con una contraseña.

Nota

Ninguno de los dos hace seguimiento de lo que ocurre con el archivo. blunderDB no registra nada del lado de quien recibe la base: abrir una base marcada es exactamente igual que abrir cualquier otra, y en ningún sitio queda constancia de quién la abrió, cuándo, ni de dónde procede su contenido.

Marcar una base de datos con su origen

La ventana de exportación cabe en una sola pantalla: una banda de cabecera —el número de posiciones exportadas, Cancelar y Exportar…— y después una cuadrícula, con una fila por familia y su recuento. Estos recuentos son exactos: se leen del servidor en cada cambio de casilla, sobre la misma selección que la exportación, y son lo que contendrá el archivo. El archivo se elige al final, tras Exportar…; cerrar esa elección sin nombre devuelve a la cuadrícula. Después se superpone una barra de progreso mientras dura la escritura, la ventana se cierra sola y el resultado aparece en la barra de estado.

Nueve puntos merecen atención:

El alcance: desde una lista —una búsqueda, una colección—, la fila Alcance elige entre la Lista actual y Toda la biblioteca. La lista actual exporta sus posiciones, y la fila Partidas solo propone aquellas en las que se jugaron esas posiciones; cada partida marcada sale con todas sus posiciones. Desde la biblioteca, el alcance es la biblioteca.
Toda la biblioteca es la exportación del servidor y de export --type database: todas las familias están marcadas de entrada, los mazos Anki con su historial de repaso, y las transcripciones en curso salen con el resto.
La sincronización: con Toda la biblioteca, la fila Sincronización ofrece Solo lo nuevo desde la última exportación a esta carpeta y el botón Elegir la carpeta…. Entonces ya no se pide el archivo: se escribe en esa carpeta con un nombre nuevo, y los recuentos son los de lo nuevo (véase Sincronizar dos máquinas).
Una partida sale con su borrador de transcripción, bajo la casilla Transcripciones de la fila Partidas, marcada de entrada; las partidas que un torneo también lleva. Un borrador que aún no ha producido una partida solo sale con la biblioteca entera. Una partida o una transcripción vinculadas a un vídeo local solo llevan el nombre del archivo, sin su carpeta, que el destinatario reubica en su propia copia; un enlace web sale tal cual. El archivo desde el que se importó una partida tampoco sale más que por su nombre.
Una partida sale con los alias de sus jugadores y de su evento: la casilla Alias, marcada de entrada, hace que la fusión de jugadores la acompañe, y el destinatario lee un jugador fusionado como uno solo. Un alias que no nombra a nadie de las partidas exportadas se queda con usted.
Una colección cuyas posiciones no están todas en la lista llega truncada. La lista de colecciones muestra, para cada una, la parte cubierta («12/40») y la señala en rojo cuando es parcial. La casilla + sus posiciones se lleva las posiciones de las colecciones marcadas: las de una lista hecha a mano, las que selecciona la consulta de una colección viva. Una colección viva cuya consulta nombra filas que el archivo no contiene sale congelada: llega como la lista que su consulta selecciona hoy, y la lista la marca en rojo como «congelada» con una nota; marcar + sus posiciones la deja viva.
Un torneo sale siempre con sus partidas: sin ellas, el vínculo torneo–partida no existe y el torneo llegaría vacío. Marcar un torneo se lleva sus partidas, aunque la casilla de las partidas esté desmarcada o limitada a otras. También sale con su Dirección — diario, parejas, mesas y vinculación de las partidas exportadas — y su Encuentro sale en cuanto sale uno de sus torneos; la carpeta de salida de la Dirección se queda en su equipo. La Dirección se recupera abriendo el archivo, o importándolo en otra base.
Un mazo Anki sale con sus posiciones, como copia de estudio nueva. La casilla con mi historial se lleva además el estado de cada tarjeta y el registro de sus repasos: una copia de seguridad, o sus mazos pasados a otra máquina. Está desmarcada para una lista y marcada para la biblioteca.
Los filtros guardados no exportan contenido sino sus propias búsquedas, sin utilidad en la base de otra persona; la casilla está desmarcada para una lista. Un filtro que designa una posición, una partida o un torneo por su número se renumera para el archivo; si designa uno que no sale, se queda con usted.

Las colecciones, lecciones, transcripciones, mazos Anki, alias y torneos salen con las fechas de creación y de adición que tienen en su equipo, no con la fecha de la exportación.

Los campos Usuario, Descripción y Fecha de creación describen el archivo producido; vienen rellenados de antemano a partir de la base de origen.

Al marcar Marca de agua aparecen dos campos:

Origen — qué es este archivo y de dónde viene, con sus propias palabras: «Curso de Jean Dupont — 12 de marzo de 2026». Este campo es obligatorio: mientras esté vacío, aparece bordeado de rojo y el botón de exportación permanece inactivo.
Nota, opcional — condiciones de uso, dirección de contacto, una petición de no redistribuir.

La marca se firma con tu identidad de emisor. Es por tanto inalterable e infalsificable: nadie puede modificarla ni fabricar una en tu nombre. En cambio, no es imborrable: el archivo distribuido es una base SQLite corriente y blunderDB es software libre. No impide nada: dice de dónde viene el archivo.

Los comentarios que usted ha escrito se firman con la misma identidad: el destinatario ve que vienen de usted y si han sido alterados por el camino (véase Panel de Comentarios). Un comentario que ya lleva la firma de otro emisor la conserva. La barra de estado indica, al final de la exportación, cuántos de sus comentarios se han firmado; una exportación sin marca no firma ninguno.

Identidad del emisor

Las marcas se firman con tu identidad de emisor, creada por sí sola la primera vez que marcas un archivo; no hay nada que configurar. Pertenece a una persona y no a una base de datos: todos tus archivos llevan la misma huella pública, con la forma A3F1-9C24-7B05-E1D8.

Puedes comunicar esa huella a tus destinatarios para que comprueben que un archivo procede realmente de ti. La identidad se traslada de un equipo a otro en un único archivo (extensión .bdbid), protegido si se desea por una frase de contraseña. Ese archivo permite firmar en tu nombre: no lo compartas.

En los ajustes (icono de rueda dentada de la barra de herramientas), la pestaña Identidad del emisor muestra tu nombre y tu huella, y ofrece Guardar identidad…, Cargar identidad… y Regenerar….

Advertencia

Regenerar no revoca nada. Una marca lleva incorporada la clave pública que la firmó: se verifica por sí sola para siempre. Si tu archivo de identidad se ha filtrado, quien lo posea podrá seguir firmando con tu huella antigua, y esas marcas seguirán siendo válidas.

Lo que te protege tras una filtración no es el software: es publicar tu nueva huella y desautorizar la antigua ante tus destinatarios.

La regeneración sobrescribe la clave actual; blunderDB ofrece guardarla antes de reemplazarla.

Proteger una base de datos con una contraseña

La contraseña se escribe oculta, tanto aquí como al abrir un archivo protegido; el icono con forma de ojo la muestra mientras se mantiene pulsado y vuelve a ocultarla al soltarlo.

Al marcar Contraseña se produce un archivo con extensión .dbx, incluso si el nombre elegido en la ventana de guardado termina en .db. Para abrirlo, use la apertura de base habitual: la ventana de selección acepta tanto .db como .dbx. blunderDB pide entonces la contraseña e instala una base ordinaria al lado; después ya no se pide nada.

La ventana ofrece eliminar el archivo protegido una vez abierto: de lo contrario conservas el mismo contenido con dos nombres. La casilla no está marcada por omisión —el archivo protegido sigue siendo tuyo si piensas transmitirlo— y la eliminación solo se produce tras una apertura correcta.

Advertencia

La contraseña protege el transporte del archivo, no la base. Impide que un tercero abra un archivo olvidado en una carpeta de descargas o un adjunto reenviado por error. No protege frente a aquel a quien has dado la contraseña.

La contraseña se comprueba en cada apertura, incluso si el archivo ya se había abierto antes en ese equipo.

Técnicamente, la base se cifra con AES-256 en modo GCM, con una clave derivada de la contraseña mediante Argon2id (64 MiB de memoria, 3 pasadas, 4 hilos) y una sal aleatoria propia de cada archivo. El modo GCM autentica el conjunto: una contraseña errónea se detecta como tal, y también cualquier alteración del archivo cifrado; nunca se obtiene en silencio una base corrupta.

La cabecera del archivo protegido permanece en claro: su origen sigue siendo legible sin la contraseña.

Leer el origen de un archivo

En la aplicación, abre el archivo y muestra el panel Metadatos (comando meta). Aparece una sección Origen en la parte superior del panel, de solo lectura, que indica lo que se inscribió, por quién, cuándo, y el estado de la firma:

«✓ marcada por usted»: el archivo lleva su marca, intacta;
«✓ firma verificada»: la marca está intacta y procede de otra clave; compara su huella con la que te haya comunicado el autor;
«⚠ firma no válida»: el documento ha sido modificado o falsificado.

Esta sección no aparece en una base de datos corriente.

En línea de comandos, blunderdb info --db archivo.db muestra el origen y el estado de la firma, sin escribir nunca en el archivo. El comando funciona también con un archivo protegido, sin la contraseña. Consulta CLI_USAGE.md para las opciones --watermark y --password de export, así como para identity y open.

Publicar una base para otros

Una base marcada se distribuye como cualquier archivo — correo, sitio personal, memoria USB. blunderDB no ofrece ningún servicio: ni repositorio, ni catálogo alojado, ni cuenta. Es consecuencia directa de su diseño: nunca se registra nada del lado de quien recibe un archivo, así que no habría nada que comunicar a un servicio, aunque existiera.

Lo que hace utilizable por otro una base publicada se reduce a cuatro campos, todos ya presentes:

Usuario — quién la constituyó, con el nombre que quiere ver citado.
Descripción — qué contiene la base, en una frase que quepa en una lista: «240 decisiones de cubo al marcador, comentadas, nivel intermedio».
Origen (de la marca de agua) — qué es este archivo y para quién se produjo. Es lo primero que el destinatario lee en el panel Metadatos.
Huella del emisor — publíquela junto al archivo, no dentro: comparándola el destinatario comprueba que el archivo viene de usted y no de alguien que ha tomado su nombre.

Una base publicada sin marca de agua sigue siendo perfectamente utilizable; simplemente es anónima, y el panel Metadatos no muestra entonces ninguna sección Origen.

Para dar a conocer una base, la categoría Show and tell de las discusiones del repositorio sirve de directorio: es una lista mantenida por quienes publican, no un servicio prestado por blunderDB. Anunciar una allí requiere el enlace, los cuatro campos anteriores y la huella.