Add VISION and design docs (backup/recovery, G1 integration, network trust, security/privacy, open decisions); update domain boundary and data notes

VISION.md

@@ -0,0 +1,106 @@
+# Tanemaki — Visión
+
+*Explicación para personas. Fuente de la que derivar el README, la web y las solicitudes de financiación. Lengua: español (se derivará versión en inglés para NLnet/comunidad internacional).*
+
+---
+
+## En una frase
+
+**Tanemaki es una app libre para cuidar y compartir semillas tradicionales, que funciona sin conexión y sin intermediarios: tu banco de semillas en el bolsillo, y una red vecinal para hacerlas circular.**
+
+## El problema
+
+Un puñado de empresas controla hoy buena parte de las semillas del mundo. Muchas son híbridas o están diseñadas para no reproducirse bien, de modo que hay que volver a comprarlas cada temporada. Mientras tanto, las variedades tradicionales —las que se han cultivado, adaptado y mejorado durante milenios— se pierden a un ritmo acelerado, y con ellas el conocimiento de cómo cultivarlas.
+
+Compartir semillas, que es la práctica más antigua y natural de la agricultura, se ha vuelto en algunos sitios sospechoso o incluso sancionable: en Francia, la asociación Kokopelli fue multada por distribuir variedades no inscritas en el catálogo oficial. La ley tiende a proteger lo registrado y privativo, y a arrinconar lo común.
+
+Quien quiere resistir esto —redes de semillas, colectivos agroecológicos, hortelanas y hortelanos— lo hace hoy con libretas, hojas de cálculo y mucha memoria. No hay una herramienta amena, libre y descentralizada que les acompañe.
+
+## La idea
+
+Tanemaki hace dos cosas, y las hace fáciles:
+
+**Gestionar.** Llevar, de forma sencilla y hasta agradable, el inventario de tu banco de semillas y tu plantel: qué tienes, de qué año, cuánto, de dónde vino, con el nombre que tú usas (no hace falta saber latín). Sirve igual para una persona con cuatro sobres en un cajón que para un banco comunitario con cientos de variedades.
+
+**Compartir.** Decir qué ofreces y qué no, y que alguien cerca lo encuentre y te contacte —para regalar, intercambiar, o vender si así lo quieres— **sin una empresa en medio** que controle, censure o se lleve una comisión. La app presenta; el trato lo cierran las personas.
+
+Detrás de todo late una idea: las semillas tradicionales son un bien común de la humanidad. Frente a su privatización, Tanemaki quiere ponértelo fácil para conservarlas, multiplicarlas y hacerlas circular.
+
+## Para quién
+
+Para todo el mundo, **de los 10 a los 80 años**. Para la persona mayor que guarda la semilla de toda la vida y apenas usa el móvil, y para quien coordina un banco comunitario y necesita potencia. La app es sencilla por fuera para quien empieza, y despliega profundidad para quien la necesita, sin convertirse en dos aplicaciones distintas. Hortelanas y hortelanos, redes de semillas, colectivos agroecológicos, ferias de intercambio, escuelas.
+
+## Cómo funciona (sin tecnicismos)
+
+Tanemaki está pensada por **capas**, y cada una es útil por sí sola:
+
+1. **Tu inventario.** Vive en tu teléfono. Funciona sin internet, sin crear ninguna cuenta. Añades una semilla con una foto y un nombre en veinte segundos; si quieres, le pones año, cantidad, procedencia, notas, o hasta su nombre científico (que la app te sugiere, no te obliga a teclear). Y una **"varilla"** puede ofrecerte rellenar el resto por ti —nombres, cuidados, cómo conservarla, años de viabilidad— a partir de lo poco que has escrito, como propuestas que confirmas o corriges.
+
+2. **Tu oferta.** Por cada cosa decides si es privada, si la compartes, si la cambias o si la vendes. Es tu escaparate, y solo enseña lo que tú elijas.
+
+3. **La red local.** Publicas lo que ofreces y aparece para quien está cerca (nunca tu dirección exacta, solo "a X km"). Quien lo quiera te contacta. No hay servidor central que mande: la identidad es tuya, y los anuncios viajan por una red abierta.
+
+4. **La confianza.** Con el tiempo se teje una red de confianza: quién intercambia, quién devuelve, quién es de fiar. Es la versión digital de algo antiguo.
+
+### El Plantare: una promesa de devolver
+
+Cuando das semillas, puedes acompañarlas de un **Plantare**: un compromiso —heredero de un pagaré de papel real de 2009— de devolver, cuando puedas, una cantidad parecida de semilla libre. No es una deuda con intereses: es una promesa de mantener la semilla viva y en movimiento. Y como para devolver semilla hay que cultivarla, y al cultivarla se multiplica, **cada préstamo hace crecer el común en lugar de agotarlo.** Es lo contrario de la semilla que no se reproduce.
+
+## Qué lo hace distinto
+
+No es "otro Wallapop" ni "otra app de huerto". La diferencia es de raíz:
+
+- **Sin centro.** No hay una empresa dueña que pueda apagar el servicio, censurar, vender tus datos o quedarse una comisión. Si mañana desaparece quien la mantiene, tu app sigue funcionando y tus semillas siguen circulando.
+- **Anti-monopolio por diseño.** El mecanismo del Plantare está pensado para multiplicar las variedades libres, no para lucrarse con ellas.
+- **Se propaga como una semilla.** Para dar semillas con la app, invitas a la otra persona: cada intercambio real hace crecer la red, sin marketing.
+- **Legal por diseño.** La app no es un vendedor ni un catálogo central: es una herramienta personal que además facilita el contacto. Prioriza el regalo y el intercambio (lo más protegido legalmente) y, cuando alguien vende, avisa con tacto según el país. El dinero, si lo hay, cambia de manos entre personas, fuera de la app.
+
+## Valores
+
+Software libre (copyleft). Funciona sin conexión y sin cuenta. Tus datos, en tu dispositivo. Multilingüe desde el primer día, traducida por voluntariado. Sin publicidad, sin comisiones, sin venta de datos. Privacidad por defecto (ubicación aproximada, identidad seudónima).
+
+## El nombre y su herencia
+
+**Tanemaki** (種まき) significa "sembrar, esparcir semillas" en japonés. Es un homenaje a las antiguas tradiciones japonesas de ayuda mutua en torno al arroz —el *yui*, el trabajo comunitario compartido, y el *tanomoshi*, los fondos vecinales de reciprocidad— que inspiraron el Plantare original. El apodo corto es **Tane** ("semilla"). Tanemaki continúa el camino del Plantare (BAH-Semillero, 2009), de la Red de Semillas "Resembrando e Intercambiando" y de la cultura libre. *Las semillas del conocimiento libre ya están plantadas.*
+
+## Sostenibilidad
+
+Tanemaki no tiene modelo de negocio, y es a propósito. Al ser local-first, sigue siendo útil aunque nadie la mantenga ni haya servidores encendidos: la utilidad no caduca. Al ser libre y con datos abiertos, cualquiera puede continuarla. Su desarrollo se sostiene con trabajo voluntario, comunidad (redes de semillas, colectivos) y financiación de bien común (fondos europeos de tecnología libre como NLnet/NGI Zero), nunca cobrando por uso ni extrayendo valor de quien la usa.
+
+## La visión mayor
+
+Bajo Tanemaki hay un motor común (`commons_core`) que resuelve lo difícil: identidad propia, red descentralizada, confianza, y el préstamo-con-devolución. Ese motor sirve para más que semillas. La misma idea —"qué tengo, qué comparto, con confianza y devolución"— vale para una **biblioteca vecinal de cosas y herramientas**. Tanemaki es la primera app sobre ese motor; otras podrán venir. Generalizamos el motor, no el producto: cada app sigue siendo simple y de un solo propósito.
+
+## Estado y camino
+
+En diseño temprano. El orden previsto: primero un **inventario usable** (útil desde el día uno, aunque no exista aún la parte de compartir); luego la **oferta y el Plantare digital**; después, como investigación, la **compartición local descentralizada**; y por último la **red de confianza**. Cada fase deja algo que ya merece la pena usar.
+
+## Cómo participar
+
+Tanemaki es un proyecto abierto. Se puede contribuir cultivando y probándolo en una red de semillas real, traduciéndolo, aportando conocimiento sobre variedades, o programando. El código y su documentación son públicos.
+
+---
+
+## Anexo — Chequeo de completitud (qué está atado y qué no)
+
+*Esta sección no va al README ni a la web; es nuestra red de seguridad. Al escribir la visión, esto es lo que veo sólido y lo que aún cojea.*
+
+**Sólido / atado:** el porqué (problema y valores), el qué (gestión + compartición por capas), el público (10–80), el modelo de datos (variedad/lote/movimiento), nombres y catálogo, la compartición y el mercado, el Plantare y su faceta vírica, la postura legal, la sostenibilidad, la frontera core/dominio y el stack.
+
+**Aún NO atado (huecos reales que conviene pensar):**
+
+1. **Recuperación de identidad y datos.** *Cada persona es su propio banco*, así que perder el móvil no puede ser perder el banco. **Con diseño ya** en [docs/design/backup-and-recovery.md](docs/design/backup-and-recovery.md): copias cifradas que tú controlas (archivo, tu propia nube/Seafile, segundo dispositivo, QR de identidad imprimible), sin servidor central. Pendiente de bajar a detalle (formato, cifrado vs. facilidad), pero deja de ser un hueco abierto y **condiciona ya la Fase 1**: el formato de exportación es de primera clase.
+
+La capa social (huecos 2–6) tiene ya enfoque en [docs/design/network-trust.md](docs/design/network-trust.md):
+
+2. **Arranque en frío.** Doble motor: la app es útil **en solitario** (inventario sin red), así que se adopta para uso personal y la red crece por debajo; y **siembra física** en ferias, mercados y colectivos (Red de Semillas), donde ya hay gente que comparte. Los encuentros presenciales arrancan a la vez la red y la confianza.
+
+3–4. **Confianza y moderación.** Red de confianza estilo **Duniter/Ğ1**: participas desde el minuto uno como "desconocido"; con ~5 certificaciones (parámetro) de miembros entras en "gente conocida". Las certificaciones se dan cara a cara (en la feria). El spam/estafa se queda en "desconocido" y se filtra solo, sin autoridad central.
+
+5. **Relays.** Sí, **la propia app puede hacer de relay** (oportunista), combinado con intercambio por **proximidad física** (feria: Bluetooth/QR, cero infraestructura) y algún **relay comunitario** barato (colectivos/Comunes, no una empresa).
+
+6. **Mensajería (hueco grande destapado).** Hace falta **mensajería 1:1 cifrada dentro de la app** (estilo Wallapop) para cerrar tratos sin dar el teléfono. Va sobre la misma identidad Nostr (NIP-17), es de `commons_core`, y el mockup `10_chat` ya la preveía. (La "autenticidad de variedad" se cubre con confianza + procedencia.)
+
+7. **Avisos legales.** Empezar por **unas pocas jurisdicciones de marco común (Europa)** y ampliar luego.
+
+Ninguno bloquea la Fase 1 (inventario), pero **la capa social es un salto grande e indivisible** (ofertas + mensajería + relays + confianza, todo junto). El detalle y las decisiones pendientes están en [docs/design/open-decisions.md](docs/design/open-decisions.md).

docs/design/backup-and-recovery.md

@@ -0,0 +1,92 @@
+# Tanemaki — Copias de seguridad y recuperación
+
+*Nota de diseño (discusión). Responde al hueco crítico nº 1 de [VISION.md](../../VISION.md): si cada persona es su propio banco, perder el móvil no puede significar perder el banco.*
+
+## El planteamiento
+
+"El banco eres tú." Tu inventario, tu identidad (tu clave) y tu historial viven en tu teléfono. Si el móvil se rompe, se pierde o se cambia, hace falta poder **recuperarlo todo** en otro. Y como Tanemaki **no tiene servidor central** (por sostenibilidad y por privacidad), la copia no puede vivir "en la nube de Tanemaki": tiene que ir a un sitio que **tú** elijas y controles.
+
+Qué debe entrar en una copia completa: los datos del inventario (variedades, lotes, movimientos, notas), las **fotos**, la **identidad (par de claves)** y la red de confianza/Plantares que tienes. Sin la clave, recuperarías los datos pero perderías tu identidad y tu reputación; por eso viajan juntos, cifrados.
+
+## Principios (coherentes con el proyecto)
+
+- **Sin infraestructura de Tanemaki.** El destino de la copia lo pone la persona: un archivo, su propia nube, otro dispositivo. Nada obligatorio en servidores nuestros.
+- **Privada por defecto.** La copia va cifrada (lleva tu clave privada y tus datos). Nadie más debería poder leerla.
+- **Para humanos de 10 a 80.** "Guarda una copia de tu banco", no "exporta la base de datos cifrada". Metáfora amable: guardar las semillas a buen recaudo. Recordatorios suaves ("hace 2 meses que no haces copia").
+- **Degrada con elegancia.** La copia más simple (un archivo) funciona sin red y sin cuentas. Las opciones más cómodas se añaden encima, nunca como requisito.
+
+## Mecanismos, en capas (de lo simple a lo potente)
+
+### 1. Exportar / importar un archivo *(base, Fase 1)*
+Un botón: **"Guardar una copia de mi banco"** → un único archivo `.tanemaki` (un zip con los datos + fotos + la clave, cifrado con una frase de paso). La persona lo guarda donde quiera: se lo manda a su propio correo, a un USB, a su nube, lo copia a otro móvil. **"Restaurar desde una copia"** en el móvil nuevo lo devuelve todo, identidad incluida. Sin infraestructura, sin cuentas, totalmente privado. Es la red de seguridad mínima y debe existir desde el inventario (Fase 1).
+*Contra:* es manual (la gente se olvida) y el archivo es sensible (por eso, cifrado).
+
+### 2. Copia a una carpeta que tú sincronizas *(muy alineado con tu ethos)*
+La app deja la copia (cifrada) en una **carpeta local que tu propia herramienta ya sincroniza**: Seafile, Nextcloud, Syncthing... (justo como trabajas tú). Set-and-forget, sin depender de Big Tech ni de nosotros. Para quien ya se autogestiona, es la opción ideal.
+
+### 3. Copia automática programada a un destino elegido *(Fase 1–2)*
+La app escribe la copia cada cierto tiempo en el sitio que elegiste una vez (una carpeta, tu nube). Resuelve el "se me olvidó". Con recordatorios amables si lleva mucho sin hacerse.
+
+### 4. Respaldo del sistema operativo *(red de seguridad automática)*
+Aprovechar el backup normal del móvil (Android Auto Backup / iCloud): los datos de la app entran en la copia que la persona ya hace de su teléfono. Cero esfuerzo, pero opaco, con límites de tamaño (las fotos), y atado a cuentas de Big Tech → **como red de seguridad adicional, no como único mecanismo**.
+
+### 5. Segundo dispositivo = copia viva *(Fase 3, cuando exista la sincronización)*
+Como el modelo es CRDT, **sincronizar con un segundo dispositivo** (una tablet, el ordenador de casa, el móvil de la pareja) hace que los datos vivan en dos sitios: el segundo dispositivo *es* una copia que se actualiza sola. La misma maquinaria de sincronización que construimos para el P2P sirve de backup. Elegante, pero necesita la sincronización hecha y un segundo aparato.
+
+### 6. Papel: recuperación de la identidad *(bonito y fiel al Plantare)*
+La **clave de identidad** cabe en una hoja imprimible / un QR (como una "frase de recuperación", pero explicada con cariño). Un QR guardado en un cajón permite recuperar tu identidad aunque lo pierdas todo. El inventario entero no cabe en papel, pero **imprimir un catálogo legible de tu banco** es además un artefacto humano precioso y muy en la línea del Plantare de papel.
+
+### 7. Respaldo social/distribuido *(investigación, más adelante)*
+Trozos cifrados de tu copia guardados entre **contactos de confianza** o en relays. "Tu banco, respaldado en tu red." Muy en el espíritu (descentralizado, resiliente), pero complejo → no para la v1.
+
+### 8. El banco colectivo como respaldo *(gratis, cuando exista)*
+Lo que compartes con un banco comunitario ya está replicado en el banco y en otras personas. Pertenecer a un banco es, en sí, una copia de lo compartido.
+
+## ¿Cifrar la copia? Pros, contras y recomendación
+
+Es la decisión delicada, y conviene separarla por partes, porque la copia contiene dos cosas muy distintas: **los datos** (semillas, notas, fotos) y **la clave de identidad**.
+
+**A favor de cifrar:**
+- Protege tu **clave privada** si el archivo cae en malas manos (con ella te podrían **suplantar**: publicar ofertas o firmar Plantares como si fueras tú, dañar tu reputación). Este es el argumento fuerte y real.
+- Protege el **grafo social** ("quién comparte qué con quién") en **contextos donde compartir está penado** (Francia/Kokopelli) — justo parte del público que al proyecto le importa.
+- Tranquilidad si la copia va a una nube de terceros.
+
+**En contra de cifrar (con contraseña):**
+- **Introduce un modo de fallo que va justo en contra del propósito de una copia:** contraseña olvidada = pérdida **total e irreversible**. En un backup —cuyo único fin es *no* perder— esto es especialmente perverso. Para el público de 10 a 80, olvidar la contraseña es *más probable* que sufrir un robo del archivo.
+- **Fricción** real: contraseñas, "no la apuntes pero no la olvides", gestión.
+- Los **datos en sí son de baja sensibilidad** para la mayoría (una lista de semillas y fotos de tomates). Cifrarlo todo es matar moscas a cañonazos.
+- **Redundante** si la copia ya vive en un sitio que tú proteges (tu cuenta de nube, tu cajón): el resto de tus ficheros ahí tampoco van cifrados uno a uno.
+
+**Recomendación (revisada por el peor caso legal — ver [security-privacy.md](security-privacy.md)):** el "peor caso" (país donde la variedad está prohibida) obliga a subir el listón: **se cifra siempre, también el inventario en reposo, y también la copia.** La clave está en cifrar **sin una contraseña que olvidar**:
+
+- **La llave es una clave aleatoria fuerte, no un secreto memorizado.** Uso diario: en el **almacén de claves del sistema** (se libera con la huella/PIN que ya usas). Recuperación/portabilidad: un **QR imprimible** que guardas físicamente ("como tu mejor semilla"), en dos copias.
+- Así se consiguen **las dos cosas a la vez**: confidencialidad total (nada en claro, ni datos ni copia) *y* durabilidad (no hay contraseña que olvidar; solo pierdes datos si pierdes el móvil **y** todas las copias del QR — un objeto físico, no un olvido).
+- **Contraseña adicional = opción avanzada** para quien quiera defensa en profundidad, con aviso honesto de pérdida irreversible.
+
+Esto **corrige** la idea provisional anterior de "datos de baja sensibilidad → sin cifrar": valía para tomates en España, no para el peor caso, que es nuestra brújula. El detalle completo (inventario en reposo, bloqueo de app, red) vive en [security-privacy.md](security-privacy.md); aquí basta con: **la copia va cifrada con la llave del QR.**
+
+## Recomendación por fases
+
+- **Fase 1 (inventario):** exportar/importar a un archivo cifrado (mecanismo 1) + "copia a una carpeta que tú sincronizas" (2). Es la caja fuerte mínima, sin infraestructura. **Esto obliga a que el formato de exportación sea abierto, estable y versionado** (encaja con las migraciones, §5 del data-model): una copia de hace un año debe poder restaurarse en una versión nueva de la app.
+- **Fase 1–2:** copia automática programada (3), recordatorios, QR de recuperación de identidad + catálogo imprimible (6).
+- **Fase 3+:** segundo dispositivo como copia viva (5) y respaldo por banco colectivo (8).
+- **Investigación:** respaldo social distribuido (7).
+
+## Consecuencias para el diseño (ya, desde la Fase 1)
+
+- El **formato de exportación** es de primera clase: abierto, documentado, estable, versionado, y que incluya datos + fotos + clave. No es un "extra al final".
+- La **identidad debe ser exportable/recuperable** por separado (QR) además de dentro de la copia completa.
+- Pensar el modelo para que **restaurar** sea idempotente y tolere versiones (una copia vieja restaurada en app nueva → se migra al abrir).
+
+## Decidido sobre cifrado (ver [security-privacy.md](security-privacy.md))
+
+- **Todo cifrado, siempre**: inventario en reposo *y* copia. Nada en claro en disco.
+- **Llave = clave aleatoria** en el almacén del sistema (uso diario con huella/PIN) + **QR imprimible** físico (recuperación/portabilidad, dos copias). **Sin contraseña memorizada como único secreto.**
+- Con eso: confidencialidad total *y* durabilidad (no hay contraseña que olvidar).
+- **Contraseña adicional = opción avanzada opt-in** (defensa en profundidad), con aviso de pérdida irreversible.
+
+## A decidir (pendiente)
+
+- **Formato del archivo de copia:** ¿zip con SQLite/estado CRDT + carpeta de fotos + clave (protegida aparte); o un único blob? Debe ser abierto, documentado y versionado.
+- ¿La copia "de datos" incluye la clave o la clave va **siempre** por el canal separado (QR)? (Tiende a: clave separada, para que una copia de datos filtrada no entregue la identidad.)
+- ¿Ofrecemos "copia a carpeta" (Seafile/Nextcloud/Syncthing) ya en la v1 como opción destacada, dado que es la más afín al proyecto? (Tiende a: sí.)

docs/design/core-domain-boundary.md

@@ -93,9 +93,25 @@ Drift: tablas del core en `commons_core`, tablas de extensión en `app_seeds`, m
 
 ---
 
-## 8. A decidir
+## 8. Decidido
 
-- **Nombre del paquete núcleo:** `commons_core` / `comunes_core` / otro. (Tu org es Comunes; `commons_core` en inglés encaja con la convención de código.)
-- ¿Hacemos ya `commons_ui` como tercer paquete, o el kit accesible empieza dentro de `app_seeds` y se extrae cuando llegue la segunda app? (Coherente con §7: probablemente empezar en `app_seeds` y extraer luego — salvo que quieras forzar la disciplina desde el día 1.)
-- ¿`Item` y `Holding` como tablas base en el core desde el inicio, o el core arranca sin ellas (solo Offer/Pledge/Party/trust/sync) y `Variety/Lot` viven enteras en el dominio hasta que la app de cosas revele la forma común? (Esto último es aún más conservador y quizá lo más sensato.)
-- ¿Herramienta de monorepo: `pub workspaces` (nativo, Dart 3.5+) o `melos`?
+- **Nombre del paquete núcleo:** **`commons_core`** (inglés, encaja con la convención de código y con la org Comunes).
+- **`commons_ui`:** nombre e idea fijados, pero **arranca dentro de `app_seeds`**; se extrae a paquete cuando llegue la segunda app (evita andamiaje prematuro, §7).
+- **`Item` / `Holding`:** arranque **conservador** — el core NO lleva tablas base `Item/Holding` todavía. `Variety/Lot` viven **enteras en el dominio de semillas**. El core arranca solo con lo seguro-compartido (`Offer`, `Pledge`, `Party`, `Group`, `TrustEdge`, `Identity`, transporte+CRDT+sync, discovery). Cuando exista la app de cosas y revele la forma común, se extrae `Item/Holding` al core (refactor barato dentro del monorepo).
+- **Monorepo:** **`pub workspaces`** (nativo de Dart, sin dependencias extra). Descartado `melos`.
+
+### Estructura de arranque resultante
+
+```
+tane/
+  pubspec.yaml               ← workspace raíz (pub workspaces)
+  packages/
+    commons_core/            ← Offer, Pledge, Party, Group, TrustEdge, Identity,
+                               transport (OfferTransport/Nostr), CRDT+sync, geohash.
+                               (Item/Holding se añadirán aquí al llegar la 2ª app.)
+  apps/
+    app_seeds/               ← Tanemaki: Variety, Lot, Movement, Species, germinación,
+                               cosecha, unidades por familia, UI e i18n, commons_ui embebido.
+```
+
+Dependencia: `app_seeds → commons_core`, nunca al revés. Migraciones Drift versionadas por paquete.

docs/design/data-notes.md

@@ -81,6 +81,24 @@ Nada del núcleo depende de la red. Offline tienes inventario completo, nombres
 
 ---
 
+## 3-ter. La "varilla": autocompletado asistido
+
+Idea clave para que la app sea *amena*: una **varilla** (un botón de "autocompletar / rellenar por mí") que, a partir de lo poco que la persona ha metido —un nombre, una especie vinculada o una foto—, **propone** rellenar el resto: nombres (comunes y científico), **cuidados** (siembra, riego, asociaciones), y **datos de conservación** (cómo secar, años de viabilidad de la semilla, condiciones de guardado). Convierte un formulario en un gesto.
+
+Principios (coherentes con todo lo demás):
+
+- **Propone, nunca impone.** La varilla rellena *borradores editables*; la persona confirma o corrige. Nunca sobrescribe en silencio ni presenta un dato como verdad absoluta (sobre todo los cuidados, que dependen del clima local).
+- **Un botón, no un muro.** Encaja con el *progressive disclosure*: es una acción opcional, no más campos que rellenar a mano.
+- **Degrada con elegancia.** *Offline*: rellena lo que da el catálogo empaquetado (nombres, familia y quizá valores de conservación por defecto por familia/especie). *Online*: enriquece con Wikipedia, GBIF, cultivo de Permapeople, etc. Sin red, la varilla hace menos, pero nunca falla.
+- **Fuentes y privacidad.** Prioriza datos abiertos (Wikidata/GBIF/Permapeople). Si en el futuro se usa reconocimiento de foto (sugerir especie a partir de una imagen de semilla/planta) o un servicio de IA para resumir cuidados, es **opcional, con consentimiento** (la foto/el nombre solo salen del dispositivo si la persona lo pide) y **sustituible** (nada atado a un proveedor cerrado).
+- **Datos de conservación** (viabilidad en años, secado, guardado) merecen una pequeña tabla curada por especie/familia, empaquetada y ampliable online — es justo el saber que se está perdiendo y que la app puede ayudar a preservar.
+
+Encaje con la arquitectura: la varilla es **de dominio** (`app_seeds`), porque "cuidados" y "conservación" son específicos de semillas; el motor genérico no sabe de eso. Es una de las piezas que más diferencian a Tanemaki de una libreta: reduce a un toque lo que en papel era investigar y copiar a mano.
+
+**A pensar más:** el conjunto mínimo de campos que la varilla intenta rellenar en la v1 (probablemente solo nombres + viabilidad + siembra), y si el reconocimiento por foto entra pronto o es fase posterior.
+
+---
+
 ## 4. El registro de banco: variedad / lote / movimiento
 
 Esta es la distinción de modelado que hace que **fecha, entrada/salida, año y germinación** —lo que subrayas como importante— caigan en su sitio sin campos sueltos y confusos. Tres niveles:

docs/design/g1-integration.md

@@ -0,0 +1,88 @@
+# Tanemaki — Integración opcional de Ğ1 (moneda libre)
+
+*Nota de diseño (discusión). Explora integrar opcionalmente la moneda libre Ğ1 (Duniter) para facilitar intercambios, sin excluir el regalo, el Plantare, el trueque ni otras monedas. Conecta con [sharing-model.md](sharing-model.md) §4 y con [network-trust.md](network-trust.md) §2.*
+
+## Por qué Ğ1 encaja como ninguna otra moneda
+
+No es un añadido oportunista: hay **tres coincidencias profundas**.
+
+1. **Misma red de confianza.** Tanemaki ya adopta una WoT **estilo Duniter** (network-trust §2). Ğ1 *es* esa WoT hecha moneda. Integrarla no es pegar un sistema ajeno: es la misma filosofía expresada como dinero.
+2. **Misma ética.** Ğ1 es libre, descentralizada, no especulativa (dividendo universal, no acumulativa). Casa con el proyecto donde el euro no llega, y resuena con el espíritu del Plantare ("mantener en circulación, no acaparar").
+3. **Mismo stack, y experiencia propia.** Duniter v2 (lanzado el 7 de marzo de 2026, sobre Substrate) trae **Ğecko**, cartera móvil en **Flutter** —igual que Tanemaki—, y **Ğ1nkgo**, del propio autor de este proyecto. Hay código Dart/Flutter y conocimiento directo que reutilizar: la integración **no parte de cero**.
+
+## El gradiente de reciprocidad
+
+Tanemaki no elige "regalo vs. dinero": ofrece un **abanico**, del más procomún al más convencional, y la interfaz lo presenta en ese orden (lo comunitario primero):
+
+**regalo → Plantare (devolver algo similar) → trueque → Ğ1 (moneda libre) → euro (moneda convencional)**
+
+Ğ1 se sitúa como la **opción de dinero afín a los valores** — la que uno *preferiría* mostrar frente al euro, sin prohibir ninguna. Todas conviven; ninguna es obligatoria.
+
+## Ğ1 como primer campo de prueba (y solución al arranque en frío)
+
+En la comunidad Ğ1 **ya hay grupos de semillas**, pero lo que falla es justo **la app y la red para intercambiar**. Es decir: existe una comunidad motivada, afín en valores, **ya en red y con confianza montada (la WoT) y con moneda (Ğ1)** — a la que solo le falta la herramienta que Tanemaki construye. Esto convierte a los grupos de semillas de Ğ1 en el **piloto perfecto**:
+
+- **Resuelve el arranque en frío (hueco 2 de VISION)** para ese subconjunto casi de un plumazo: no hay que crear la comunidad ni la confianza, ya existen; se les da la pieza que falta.
+- **Prueba las tres capas a la vez con gente real:** inventario, compartición y —único sitio donde podemos probarlo de verdad— la **integración Ğ1** (niveles 1–3) y la WoT compartida.
+- **Feedback de calidad:** son usuarios exigentes y alineados, buenos para pulir antes de abrir a un público más amplio (Red de Semillas, ferias, gente de 80 sin Ğ1).
+
+Estrategia sugerida: **primer piloto dentro de los grupos de semillas de Ğ1**, y desde ahí ampliar a la Red de Semillas y al público general (que no necesita Ğ1). No convertir a Ğ1 en el único público, pero sí en la **primera comunidad**.
+
+## Principios de la integración
+
+- **Opcional y plural.** Ğ1 es *una* opción más. Nunca obligatoria, nunca el defecto. El regalo y el Plantare siguen siendo de primera clase.
+- **Sin custodia ni rieles de pago en la app** (coherente con sharing-model §4.3). Tanemaki **no** mueve fondos: anuncia y conecta; el valor se transfiere en la **cartera del usuario** (Ğecko/Cesium²/Ğ1nkgo), fuera de la app. Así seguimos siendo infraestructura neutral, sin KYC/AML.
+- **Inclusión intacta.** Usar Tanemaki **no** exige ser miembro de Ğ1. La persona de 80 que solo cambia tomates no toca Ğ1 jamás. Ğ1 es una **capa opcional** para quien ya está en ese mundo.
+- **Acoplamiento con cuidado.** Reusar la WoT/identidad de Ğ1 es potente, pero no debe volver a Tanemaki dependiente de Duniter para funcionar. Ğ1 informa/enriquece; no manda.
+
+## Niveles de integración (de menos a más)
+
+1. **Precio en Ğ1 (ya cabe hoy).** `price_currency` admite Ğ1: una oferta puede valer "50 Ğ1". Sin pago en la app; la transferencia va aparte, como el efectivo. **Coste técnico casi nulo** — ya está en el modelo (sharing-model §4.4).
+
+2. **Enlace a la cartera (deep-link).** Botón "Pagar en Ğ1" que abre **Ğecko / Cesium² / Ğ1nkgo** con destinatario e importe ya rellenos (URI de pago). La app no toca fondos; solo entrega el testigo. Riesgo bajo, UX buena — y conoces esos esquemas de URI de primera mano.
+
+3. **Identidad y confianza compartidas (la sinergia profunda).** Como la WoT de Duniter v2 está en cadena e indexada (duniter-squid, GraphQL), Tanemaki podría **opcionalmente** vincular tu identidad Ğ1 e **importar tu pertenencia y certificaciones** como señal de confianza: un miembro Ğ1 llega **pre-avalado** a Tanemaki. Pero manteniendo la WoT propia y ligera para quien no es de Ğ1 (inclusión). Ğ1 como **fuente opcional de confianza que suma**, no como requisito.
+
+4. **Pago dentro de la app (descartado).** Firmar transferencias Ğ1 desde Tanemaki cruzaría la línea de "sin rieles de pago" y añadiría custodia/complejidad. Mejor el nivel 2 (delegar en la cartera).
+
+## La WoT: independiente pero compatible (respuesta a "¿podría ser compatible?")
+
+La disyuntiva no es "depender de Ğ1" (fácil, pero excluye a los no-Ğ1 y acopla) contra "independiente" (inclusivo, pero costoso de construir). Hay un **punto medio**, como el correo electrónico —tu propio servidor, pero compatible con SMTP—: **una WoT propia de Tanemaki, estructuralmente compatible con la de Duniter.** Y ser compatible **abarata** lo difícil, porque reutilizas diseño probado y tu propio código.
+
+Cómo se logra:
+
+1. **Mismo primitivo de identidad.** Usar el mismo tipo de clave que Duniter v2 (cuentas Substrate). Así una identidad Ğ1 es técnicamente comprensible por Tanemaki y **reutilizas la cripto de Ğ1nkgo/Ğecko**, sin depender de la red Ğ1.
+2. **Mismo modelo de certificación.** Modelar la WoT de Tanemaki como la de Duniter (certificaciones firmadas "A avala a B", regla de N certificaciones + distancia). Es una WoT estilo Duniter, pero **tu propia instancia/grafo**. Esto abarata el "hazlo independiente": reutilizas un diseño probado desde 2017, no inventas uno.
+3. **Importar la WoT de Ğ1 en un solo sentido.** Leer el grafo on-chain de Ğ1 (duniter-squid, GraphQL) para *informar* la confianza en Tanemaki: un miembro Ğ1 llega **pre-avalado**. Tanemaki **no escribe** en la cadena de Ğ1 (eso sí acoplaría). Import unidireccional = compatible **sin** dependencia.
+4. **Una sola clave para todo (como en Duniter).** Una única identidad —una clave Duniter-v2/Substrate— hace *todo*: perfil, ofertas, mensajes, certificaciones y, si te opt-in, pagos Ğ1 y pertenencia a la WoT. Nada de claves separadas por función. **Tener la clave ≠ ser miembro de Ğ1:** una persona no-Ğ1 (la abuela) tiene una clave que simplemente **no está certificada** en la WoT (= "desconocida", encaja con network-trust §2) y nunca toca la moneda. Un miembro Ğ1 **reusa su misma clave** y llega pre-avalado. Así, una sola clave *e* inclusión total.
+
+*Privacidad y peor caso legal:* usar la misma clave enlaza tu actividad de semillas con tu identidad Ğ1 pública. Para la mayoría (tomates en España) es indiferente. Para el caso sensible, la protección real es que **tener no es publicar**: las variedades delicadas viven **locales y cifradas**, y publicar una oferta es opt-in por ítem — así la clave nunca las expone en la red. Como escape adicional, quien *publique* algo sensible y no quiera ligarlo a su Ğ1 puede usar una **clave seudónima distinta** (opción avanzada), pero la norma es **una sola clave**.
+
+**Resultado: instancia independiente, estándar compartido, una sola clave.** Funciona sin Ğ1 (incluye a la abuela), interopera con Ğ1 (miembros y certificaciones cuentan) y reutiliza tu código. Lo "difícil" se vuelve asequible por ser compatible.
+
+## Recomendación
+
+Empezar por los niveles **1 y 2** (precio en Ğ1 + enlace a la cartera): casi gratis, sin custodia, y ya dan una experiencia real "vendo/cambio por Ğ1, pago en mi cartera". El nivel **3** (reusar la WoT de Ğ1 como fuente de confianza) es la joya, pero es diseño de la capa social (Fase 3) y decisión mayor — se aborda en la ronda social, no ahora.
+
+## Notas técnicas
+
+- **Duniter v2 = Substrate/Rust.** Identidades = cuentas Substrate; WoT y certificaciones **en cadena**, consultables vía **duniter-squid (GraphQL)**.
+- **Cliente Dart/Flutter** ya existente en el ecosistema (Ğecko, Ğ1nkgo) → reutilizable en `commons_core` como módulo opcional de "moneda/confianza Ğ1".
+- **Deep-links de pago** hacia las carteras v2 (a confirmar los esquemas URI actuales de Ğecko/Cesium²).
+- Encaje arquitectónico: el soporte de Ğ1 vive en `commons_core` (identidad/pago/confianza son genéricos), tras una interfaz, para no acoplar el núcleo a un único sistema.
+
+## Decidido
+
+- **Reutilizar el código de Ğ1nkgo/Ğecko** (Dart/Flutter) para la parte Ğ1 (cripto, identidad, WoT). Sí.
+- **Ğ1 por delante del euro** en la interfaz (orden por valores). Sí.
+- **WoT propia pero compatible con Duniter** (no dependiente, no independiente-desde-cero): mismo primitivo de identidad + mismo modelo de certificación + import unidireccional de la WoT de Ğ1.
+- **Una sola clave para todo**, tipo Duniter-v2/Substrate (perfil, ofertas, mensajes, certificaciones, Ğ1). Sin claves por función. Clave seudónima distinta = solo opción avanzada para publicar algo sensible.
+
+**Consecuencia honesta (a mirar):** una sola clave Duniter/Substrate **debilita el encaje de Nostr** como transporte — la identidad de Nostr *es* su clave secp256k1, y no es la nuestra. O bien Nostr queda como transporte "tonto" con nuestro propio sobre firmado (perdiendo el ecosistema NIP), o bien conviene **apoyar ofertas/mensajería en el ecosistema Duniter** (datapods/indexadores firmados con la misma clave) o en un transporte **agnóstico a la clave**. Se replantea en la ronda social (no bloquea la Fase 1). → [open-decisions.md](open-decisions.md) D7.
+
+## A decidir (pendiente)
+
+- **Transporte de la capa social** dado "una sola clave Duniter": ¿datapod/indexador estilo Duniter, transporte agnóstico, o Nostr como mero relay? (Revisar; sustituye la inclinación previa "Nostr primero".)
+- ¿Nivel 3 (import de la WoT de Ğ1) entra en la primera ronda de la capa social o en una posterior?
+- ¿`sr25519` o `ed25519` (lo que use Duniter v2) para la clave única?
+- Formato de certificación propio, mapeable al modelo Duniter.

docs/design/network-trust.md

@@ -0,0 +1,51 @@
+# Tanemaki — Red, confianza y mensajería (capa social descentralizada)
+
+*Nota de diseño (discusión). Resuelve los huecos 2–6 del anexo de [VISION.md](../../VISION.md): cómo arranca la red, cómo se teje la confianza, quién sostiene el descubrimiento y cómo se comunican las personas. Se apoya en la Capa 3–4 del [PLAN.md](../../PLAN.md) y en [sharing-model.md](sharing-model.md).*
+
+## 1. Arranque en frío: sembrar en lo físico (hueco 2)
+
+Una app de compartición local no sirve si eres la única persona en 50 km. Dos motores lo resuelven:
+
+- **Utilidad en solitario.** El inventario vale **sin red**: la gente adopta la app para su uso personal (su banco en el bolsillo), y la red social crece *por debajo*. No hace falta masa crítica para empezar a usarla. Esto amortigua el arranque en frío mejor que ninguna campaña.
+- **Siembra física.** Ferias de intercambio, **mercados**, colectivos agroecológicos, Red de Semillas: ahí se junta gente que **ya** comparte semillas. Llevar la app a esos espacios crea comunidades locales de golpe. El plan de adopción es presencial, no digital.
+
+**Sinergia clave:** los encuentros físicos arrancan a la vez la **red** y la **confianza** (§2) — te certificas cara a cara, en la feria.
+
+**Primer campo de prueba: los grupos de semillas de Ğ1.** En la comunidad Ğ1 ya hay grupos de semillas, pero les falla la app y la red para intercambiar. Son el **piloto ideal**: comunidad motivada, afín, **ya en red y con confianza (WoT) y moneda (Ğ1) montadas** — solo les falta la herramienta. Para ese subconjunto, el arranque en frío está casi resuelto. Detalle en [g1-integration.md](g1-integration.md).
+
+## 2. Red de confianza estilo Duniter (huecos 3 y 4)
+
+Modelo inspirado en **Duniter / Ğ1**: cualquiera participa desde el minuto uno, pero empieza como **"desconocido"**. Cuando **N personas** que ya son miembros te **certifican** (una firma: "doy fe de esta persona"), entras en el área de **"gente conocida"** (miembro de la red de confianza). Duniter usa ~5 certificaciones + una regla de distancia; el umbral es un **parámetro ajustable**.
+
+- **Certificar = acto presencial y consciente** ("te conocí, respondo por ti"). Encaja con §1: las ferias generan certificaciones.
+- **Resuelve el arranque de confianza (hueco 3):** al recién llegado no se le bloquea, solo se le marca como desconocido hasta acumular avales.
+- **Resuelve la moderación (hueco 4):** spammers y estafadores se quedan en "desconocido" y se filtran o despriorizan solos; la red de confianza pone en cuarentena **sin autoridad central**. Encima se suma la **reputación** (valoraciones tras un trato cerrado).
+- **UI para 10–80:** mostrar "conocido / desconocido" con lenguaje humano ("aún nadie de tu confianza responde por esta persona"), nunca jerga de grafos.
+
+*A decidir:* umbral de certificaciones (¿5?), regla de distancia, caducidad de certificaciones, y si un banco/colectivo puede certificar como entidad.
+
+## 3. Relays y descubrimiento: ¿la app como relay? (hueco 5)
+
+El problema: encontrar ofertas sin índice central depende de nodos (relays), que cuestan. Respuesta en tres piezas, de menos a más infraestructura:
+
+1. **Proximidad física primero.** En una feria o mercado, dos móviles intercambian **directamente** (red local, Bluetooth, QR) sin ningún relay. Para el cara a cara, **cero infraestructura**.
+2. **La app como peer que propaga.** Cada instancia, cuando está online, puede reenviar y almacenar temporalmente eventos de su entorno: un **relay ligero oportunista**. Reduce la dependencia de servidores. (Los móviles solos no bastan —offline a ratos, tras NAT, batería—, pero ayudan.)
+3. **Relays comunitarios de respaldo.** Unos pocos nodos siempre encendidos, **baratos**, hospedados por colectivos, redes de semillas o Comunes —nunca una empresa—. Dan fiabilidad. Coste **distribuido** y afín al ethos.
+
+Respuesta a tu pregunta: **sí, la app puede ser relay** (parcial/oportunista), combinado con proximidad física y algún relay comunitario. No es cero-infraestructura, pero sí distribuida, barata y opcional.
+
+## 4. Mensajería en la app (hueco 6, reformulado — y es grande)
+
+Para cerrar tratos hace falta **mensajería dentro de la app** (como Wallapop u otros). Sin ella, la gente tendría que intercambiar teléfonos —fuga de datos personales— y se rompe el seudonimato. Es un **hueco importante** que hay que asumir.
+
+- **Ya estaba entrevisto:** el mockup `10_chat.png` tiene pantalla de chat.
+- **Diseño:** mensajería **1:1 cifrada**, sobre la **misma identidad y transporte** (mensajes directos cifrados de Nostr, NIP-17). **No es un sistema aparte**: reusa claves y relays. Mantiene el seudonimato (no das el teléfono).
+- **Es de core** (`commons_core`): una biblioteca de cosas también necesita mensajería. Va al motor común.
+- **Alcance v1:** 1:1 atado a una oferta/contacto. Grupos (banco colectivo) más tarde.
+- **Es una funcionalidad grande** (entrega, offline, cifrado, spam). Apoyarse en NIP-17 reduce el trabajo, pero hay que dimensionarla. La red de confianza (§2) filtra también el spam de mensajes.
+
+*Nota sobre "autenticidad de la variedad"* (el hueco 6 original): se resuelve por **confianza + procedencia** (ya cubierto), no por prueba técnica. El hueco real que destapaste es la **mensajería**.
+
+## 5. Consecuencia importante para el plan
+
+Esta capa social —ofertas + **mensajería** + relays + red de confianza— es **indivisible y grande**: no se puede "compartir un poco". Todo va junto y es interdependiente. Esto tiene peso para las fases (ver [open-decisions.md](open-decisions.md), "qué chirría"): la Fase 1 (inventario) es entregable sola y sólida; la parte social es un **salto grande**, no un incremento pequeño. Conviene reflejarlo en el plan y en la solicitud de financiación.

docs/design/open-decisions.md

@@ -0,0 +1,56 @@
+# Tanemaki — Decisiones abiertas y "qué chirría"
+
+*Revisión de conjunto antes de seguir construyendo. Reúne los cabos sueltos repartidos por los docs de diseño, ordenados por cuándo hay que decidirlos, y nombra las tensiones del plan que conviene mirar de frente.*
+
+## A) Decidir antes de escribir código de la Fase 1 (inventario)
+
+Estas fijan `schemaVersion = 1` y el arranque técnico:
+
+- **Formato de exportación/copia:** abierto, documentado, versionado (datos + fotos + clave). Bloqueante para el backup. → [backup-and-recovery.md](backup-and-recovery.md)
+- **Cifrado en reposo (el "cómo" técnico):** SQLCipher + llave aleatoria en el almacén del sistema + QR de recuperación. Conceptualmente decidido; falta bajar el mecanismo. → [security-privacy.md](security-privacy.md)
+- **Claves separadas** para identidad (firmar) y para cifrado. (Tiende a: sí.)
+- **Detalles de modelo que fijan el esquema:** ¿`Quantity` como tipo compartido reutilizado en Lot y Movement? ¿`offer_status` solo en Lot? ¿`category` libre o ligada a `Species.family`? → [data-model.md](data-model.md) §6
+- **Licencia** del código (AGPL vs GPLv3): conviene fijarla al abrir el repo público.
+- **Alcance de la "varilla" v1** y **fuente de los datos de conservación** (viabilidad, secado): ¿quién los cura/empaqueta? → [data-notes.md](data-notes.md) §3-ter
+- **Estructura del workspace** (`commons_core` + `app_seeds`, pub workspaces) — decidido; falta materializarlo.
+
+## B) Decidir antes de la capa de compartir (Fase 3) — muy interdependientes
+
+- **Transporte de la capa social — REPLANTEAR** (ya no "Nostr primero"): la decisión de "una sola clave Duniter/Substrate" (D7) descarta la identidad Nostr. Opciones: datapod/indexador del ecosistema Duniter (misma clave), transporte agnóstico a la clave, o Nostr como mero relay con sobre propio. → [g1-integration.md](g1-integration.md) D7
+- **Estrategia de relays:** app-as-relay oportunista + proximidad física + relays comunitarios. → network-trust §3
+- **Parámetros de la red de confianza:** umbral de certificaciones (¿5, estilo Duniter?), distancia, caducidad, certificación por colectivo. → network-trust §2
+- **Mensajería:** alcance v1 (1:1 atada a oferta), apoyo en NIP-17. → network-trust §4
+- **Reputación** atada a un trato/oferta cerrada (evitar reseñas falsas). → sharing-model §6
+- **Precio:** ¿monedas comunitarias / de tiempo además de dinero? → sharing-model §6
+- **Integración Ğ1 (moneda libre):** niveles 1–2 (precio en Ğ1 + enlace a cartera Ğecko/Cesium²/Ğ1nkgo) en la capa social; nivel 3 (reusar la WoT de Ğ1 como fuente de confianza) como estudio aparte. → [g1-integration.md](g1-integration.md)
+- **Ofertas de banco colectivo** (publica la entidad, no la persona). → sharing-model §6
+- **Caducidad/revocación** de ofertas ya replicadas en relays. → sharing-model §6
+
+## C) Puede esperar (no bloquea nada ahora)
+
+- Negación plausible / bóveda señuelo; modo discreto. → security-privacy
+- Reconocimiento por foto en la varilla.
+- Respaldo social distribuido entre contactos.
+- Ampliar avisos legales más allá de Europa (empezar por jurisdicción común europea). → PLAN §6
+- Segundo producto (biblioteca de cosas) y extracción de `Item/Holding` al core. → core-domain-boundary
+- Bloqueo de app: ¿activado por defecto o sugerido? → security-privacy
+
+## D) Qué chirría (tensiones a mirar de frente)
+
+1. **La capa social es indivisible y grande.** "MVP = inventario + compartición local" subestima que "compartir" de verdad = **ofertas + mensajería + relays + red de confianza**, todo junto e interdependiente. Propuesta: replantear las fases como **(1) inventario** —entregable, sólido, en solitario— y **(2) el salto social** —un bloque grande, no un incremento—. Ser honestos con esto en el plan y en la financiación.
+
+2. **Casi toda la dificultad vive en `commons_core`.** Identidad, sync CRDT, ofertas, pledge, red de confianza, **mensajería**, relays… `app_seeds` es, en comparación, ligero. En el fondo Tanemaki es **infraestructura de procomún** con las semillas como primera aplicación. Es buena noticia para NLnet/NGI Zero (financian infraestructura), pero hay que asumir que lo "sencillo" (semillas) es la punta del iceberg y comunicar el proyecto en consecuencia.
+
+3. **Apuesta fuerte por Nostr.** Ofertas, mensajes y confianza dependerían de NIPs en evolución (99 / 17 / 85). La abstracción `OfferTransport` amortigua las ofertas, pero mensajería y confianza también se apoyan en Nostr → más acoplamiento del que sugería el plan. Revisar si un solo protocolo lo cubre bien o si conviene aislar también mensajería y confianza tras interfaces.
+
+4. **Cifrado en reposo + sync CRDT + multidispositivo.** Hay que asegurar que la sincronización **no filtra la llave ni datos en claro**, y que la llave (QR) llega bien al segundo dispositivo. Encaja, pero es un punto técnico fino que conviene prototipar pronto.
+
+5. **La "varilla" y los datos de conservación** necesitan una fuente y una curación que **aún no tenemos**. Puede ser más trabajo del que parece (y es, a la vez, de lo que más valor humano aporta).
+
+6. **Alcance vs. sostenibilidad de un mantenedor.** El conjunto (inventario + cripto + P2P + confianza + mensajería + relays, en varias plataformas) es **mucho** para "proyecto personal + IA". Refuerza la necesidad de: fases honestas, comunidad temprana, y financiación (NLnet) para la parte social. La Fase 1 sí es abordable en solitario.
+
+7. **Primitivo de identidad — RESUELTO: una sola clave.** Decidido: **una única clave Duniter-v2/Substrate para todo** (perfil, ofertas, mensajes, certificaciones, Ğ1), como en Duniter. Nada de claves por función. **Consecuencia abierta:** esto **debilita Nostr** como transporte (su identidad es su clave secp256k1) → hay que **replantear el transporte de la capa social** hacia el ecosistema Duniter (datapods) o algo agnóstico a la clave, en vez de "Nostr primero". No bloquea la Fase 1. → [g1-integration.md](g1-integration.md)
+
+## Recomendación de orden
+
+Cerrar el bloque **(A)** — son pocas decisiones y desbloquean construir el inventario, que es valioso por sí solo y de bajo riesgo. Dejar **(B)** para una ronda de diseño específica de la capa social (con su propia financiación si llega). Y asumir explícitamente el punto **(D.1)**: replantear las fases para que "lo social" sea un hito grande y no una coletilla del MVP.

docs/design/security-privacy.md

@@ -0,0 +1,64 @@
+# Tanemaki — Seguridad y privacidad (modelo de amenaza)
+
+*Nota de diseño (discusión). Nace del "peor caso legal": una persona en un país donde una variedad (p.ej. cannabis) está prohibida debe poder usar la app **sin dejar datos en claro**. Extiende y matiza [backup-and-recovery.md](backup-and-recovery.md) y la postura legal del [PLAN.md](../../PLAN.md) §6.*
+
+## El peor caso, como brújula
+
+Si diseñamos para la persona más expuesta —alguien cuyo inventario podría ser *prueba* en su contra si le requisan o le hacen desbloquear el móvil—, protegemos a todo el mundo de paso. Esto **corrige** la conclusión provisional anterior ("los datos son de baja sensibilidad, no cifrar"): eso valía para tomates en España, no para este caso. La regla pasa a ser más fuerte:
+
+> **Nunca hay datos en claro en reposo. Ni el inventario, ni el backup, ni ficheros temporales o logs.**
+
+## Tres superficies distintas (cada una su respuesta)
+
+### A) Datos en reposo en el dispositivo (el inventario) — **cifrado siempre**
+La base de datos local va **cifrada** (SQLCipher, que Drift/Flutter soportan). No se escribe nada en claro en disco: ni la BD, ni caché de fotos, ni logs. Así, un móvil apagado o bloqueado que se requisa **no revela nada**.
+
+### B) Bloqueo de la app — **opcional, recomendado**
+Para el caso "móvil desbloqueado en la mano" (o te obligan a desbloquear en una frontera), un **bloqueo propio de la app** (biométrico/PIN, aparte del desbloqueo del teléfono) evita que abrir el móvil muestre el inventario. Rápido con huella, y protege cuando el teléfono está desbloqueado pero la app cerrada (como hacen las apps de banca o Signal).
+
+### C) La copia de seguridad — **cifrada también**
+Coherente con A: el backup **también va cifrado** (el usuario lo pedía). Un archivo de copia filtrado o requisado tampoco debe estar en claro.
+
+### D) La red / las ofertas — **acto deliberado, privado por defecto**
+Publicar es lo más arriesgado. Por eso cada cosa es **privada por defecto**; ofrecer es un acto consciente por ítem. Quien tiene una variedad sensible simplemente **no la ofrece**: la tiene, cifrada, en su inventario, y punto. Cuando sí se ofrece: identidad seudónima (clave), **ubicación aproximada**, sin catálogo central. Gestionar el inventario nunca toca la red.
+
+## La clave del asunto: cifrar **sin** contraseña que olvidar
+
+El problema del cifrado en algo que debe durar (§ de backup) era: contraseña olvidada = pérdida total. Se resuelve **no usando una contraseña memorizada como llave.** En su lugar:
+
+- **Llave = una clave aleatoria fuerte**, no algo que la persona recuerde.
+- **Uso diario:** esa llave vive en el **almacén de claves del sistema** (Android Keystore / iOS Keychain / Secure Enclave), y se libera con el desbloqueo que la persona *ya hace* (huella/PIN del móvil). Cifrado invisible: no hay contraseña nueva que aprender.
+- **Recuperación / cambio de móvil:** la misma llave se guarda en un **QR imprimible** — *"tu llave; guárdala como tu mejor semilla"*. Un objeto físico, no un secreto que memorizar. Se anima a tener **dos copias** en sitios distintos (como se hace con papeles importantes).
+- **Restaurar en un móvil nuevo:** escaneas el QR → la llave → descifra la copia → todo vuelve.
+
+Con esto conseguimos las dos cosas a la vez, que parecían enfrentadas:
+- **Confidencialidad total:** nada en claro, ni en el móvil ni en la copia. Sirve para el peor caso legal.
+- **Durabilidad:** no hay contraseña que olvidar. Solo pierdes datos si pierdes **a la vez** el móvil y **todas** las copias del QR. La pérdida es un objeto físico extraviable (intuitivo), no un olvido.
+
+Y encaja con el público de 10 a 80: **no se le pide ninguna contraseña nueva**; usa su huella de siempre, y guarda un papel. El cifrado es invisible por defecto.
+
+## Lo que la protege además, "gratis"
+
+- **Es una app de semillas, genérica e inocua.** No es "una app de cannabis": es un inventario de semillas. Lo que importa —el contenido— va cifrado. La app en sí no delata.
+- **Nada en la red por gestionar.** Tener no es publicar. El inventario vive local y cifrado.
+
+## Avanzado / futuro (nombrarlo, no hacerlo ya)
+
+- **Negación plausible / bóveda señuelo:** un inventario "de fachada" y otro oculto, para el caso de desbloqueo forzado. Potente pero delicado (puede volverse en contra) → función posterior, con cuidado.
+- **Modo discreto:** icono/nombre camuflado. A valorar; suele ser más humo que protección real.
+- No prometer lo que no se puede cumplir: si a alguien le **obligan** a desbloquear y abrir la app, el cifrado en reposo no basta; ahí ayudan el bloqueo de app y, en su caso, la negación plausible. Ser honestos sobre los límites.
+
+## Decidido
+
+- **Inventario cifrado en reposo, siempre** (SQLCipher). Sin datos en claro en disco.
+- **Copia cifrada, siempre.**
+- **Llave = clave aleatoria en el almacén del sistema + QR imprimible.** **Nunca** una contraseña memorizada como único secreto (default). El QR es el mecanismo de recuperación y de portabilidad.
+- **Bloqueo de app (biométrico/PIN): opcional, recomendado** para variedades sensibles.
+- **Privado por defecto** en la red; ofrecer es opt-in por ítem.
+
+## A decidir
+
+- ¿Bloqueo de app **activado por defecto**, o sugerido la primera vez que marcas algo como sensible?
+- ¿Se permite una contraseña *además* del QR para quien la quiera (defensa en profundidad), asumiendo su riesgo?
+- ¿La negación plausible entra en el radar de la v1 o se aparca claramente para después?
+- Identidad: **una sola clave para todo** (perfil, ofertas, mensajes, certificaciones, Ğ1), tipo Duniter — decidido (ver [g1-integration.md](g1-integration.md)). Matiz: la **clave simétrica que cifra la BD en reposo** es un **detalle interno distinto** (no es una "identidad"), así que no contradice el "una sola identidad"; el cifrado de mensajes E2E sí deriva de la clave de identidad (ECDH), como en Cesium/Duniter.