docs: rename Tanemaki → Tane in design docs and notes

Product-name mentions → Tane; backup-file extension .tanemaki → .tane;
website tanemaki.app → tane.comunes.org. Etymology-bearing docs
(README, VISION, PLAN, CLAUDE, intros) handled separately.

CHANGELOG.md

@@ -1,6 +1,6 @@
 # Changelog
 
-All notable changes to Tanemaki are recorded here. Human-readable, newest
+All notable changes to Tane are recorded here. Human-readable, newest
 first. Dates are ISO (YYYY-MM-DD).
 
 ## [Unreleased] — Block 1 beta prep

docs/design/backup-and-recovery.md

@@ -1,16 +1,16 @@
-# Tanemaki — Copias de seguridad y recuperación
+# Tane — 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.
+"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 Tane **no tiene servidor central** (por sostenibilidad y por privacidad), la copia no puede vivir "en la nube de Tane": 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.
+- **Sin infraestructura de Tane.** 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.
@@ -18,7 +18,7 @@ Qué debe entrar en una copia completa: los datos del inventario (variedades, lo
 ## 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).
+Un botón: **"Guardar una copia de mi banco"** → un único archivo `.tane` (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)*

docs/design/chat-storage.md

@@ -30,7 +30,7 @@ keystore), so "no plaintext at rest" holds.
 ### Why a *separate* database, not a new table in `AppDatabase`
 
 Chat is **not inventory**. It is an ephemeral, per-device cache of what the
-relays delivered; it never enters an inventory snapshot, a `.tanemaki` backup,
+relays delivered; it never enters an inventory snapshot, a `.tane` backup,
 or the device-to-device sync. Keeping it out of `AppDatabase` means:
 
 - It carries **no CRDT metadata** (no HLC `updatedAt`, tombstones, `lastAuthor`,

docs/design/core-domain-boundary.md

@@ -1,8 +1,8 @@
-# Tanemaki — Frontera `commons_core` ↔ dominio semillas
+# Tane — Frontera `commons_core` ↔ dominio semillas
 
 *Nota de diseño (discusión). Desarrolla la Parte B de [usability-and-architecture.md](usability-and-architecture.md) y reparte las entidades de [data-model.md](data-model.md) entre el motor genérico y el dominio de semillas.*
 
-Aquí decidimos **qué vive en el motor común y qué en la app de semillas**, y con qué mecanismo se enchufan. Es la decisión que más amarra el resto, porque fija la costura que permitirá añadir mañana la "biblioteca de cosas" sin tocar Tanemaki.
+Aquí decidimos **qué vive en el motor común y qué en la app de semillas**, y con qué mecanismo se enchufan. Es la decisión que más amarra el resto, porque fija la costura que permitirá añadir mañana la "biblioteca de cosas" sin tocar Tane.
 
 ---
 
@@ -78,7 +78,7 @@ tane/                         (repo, hogar: ~/dev/tane)
     commons_ui/  (opcional)   ← kit de widgets accesibles (targets grandes, foto-first,
                                 icono+palabra) reutilizable por futuras apps.
   apps/
-    app_seeds/                ← Tanemaki: Species, SeedItem/SeedHolding, germinación,
+    app_seeds/                ← Tane: Species, SeedItem/SeedHolding, germinación,
                                 cosecha, unidades por familia, UI e i18n de semillas.
 ```
 
@@ -88,7 +88,7 @@ Drift: tablas del core en `commons_core`, tablas de extensión en `app_seeds`, m
 
 ## 7. Pragmatismo: no sobre-diseñar el motor ahora
 
-- **Construye Tanemaki concreto primero.** Mete en `commons_core` solo lo *ya conocido-compartido* (identidad, Party, Offer, Pledge, trust, sync, discovery). Para `Item/Holding`, empieza con tabla base del core + tabla de extensión de semillas; si al llegar la app de cosas resulta incómodo, **refactorizar dentro del monorepo es barato** (todo el código está junto y se mueve de un tirón).
+- **Construye Tane concreto primero.** Mete en `commons_core` solo lo *ya conocido-compartido* (identidad, Party, Offer, Pledge, trust, sync, discovery). Para `Item/Holding`, empieza con tabla base del core + tabla de extensión de semillas; si al llegar la app de cosas resulta incómodo, **refactorizar dentro del monorepo es barato** (todo el código está junto y se mueve de un tirón).
 - No inventes interfaces genéricas "por si acaso" para partes cuya forma real solo conocerás cuando exista la segunda app. La regla del §1 ("en la duda, al dominio") protege de la abstracción prematura.
 
 ---
@@ -110,7 +110,7 @@ tane/
                                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,
+    app_seeds/               ← Tane: Variety, Lot, Movement, Species, germinación,
                                cosecha, unidades por familia, UI e i18n, commons_ui embebido.
 ```
 

docs/design/data-model.md

@@ -1,4 +1,4 @@
-# Tanemaki — Data model (v0 draft)
+# Tane — Data model (v0 draft)
 
 *Technical spec feeding the Flutter/Drift implementation. Written in English (project convention). Implements the concepts discussed in [data-notes.md](data-notes.md) and PLAN §3 / §5-bis.*
 
@@ -172,7 +172,7 @@ The *shop window*: a signed statement published to the network so others can dis
 | `author_key` | TEXT | Publishing public key. |
 | *(+ common columns)* | | |
 
-A closed deal may produce a `Movement` (`given`) and, if it is an exchange with a return promise, a `Plantare`. The app never processes payments, takes commissions, or holds funds (keeps Tanemaki neutral infrastructure, not a central market operator).
+A closed deal may produce a `Movement` (`given`) and, if it is an exchange with a return promise, a `Plantare`. The app never processes payments, takes commissions, or holds funds (keeps Tane neutral infrastructure, not a central market operator).
 
 ## 3. Entity map
 
@@ -229,7 +229,7 @@ Together: Drift handles the *local database* migration; the compatibility rules
 
 ## 7. Interchange export/import (Phase 1) — decided & implemented
 
-The user-triggered **interchange export** (Settings → Backup). Distinct from the future encrypted full backup (`.tanemaki`, [backup-and-recovery.md](backup-and-recovery.md) mechanism 1): the interchange files are the *only* plaintext the app ever writes, and only because the user explicitly asks for them. Import reads the picked file straight into memory — no temp copies.
+The user-triggered **interchange export** (Settings → Backup). Distinct from the future encrypted full backup (`.tane`, [backup-and-recovery.md](backup-and-recovery.md) mechanism 1): the interchange files are the *only* plaintext the app ever writes, and only because the user explicitly asks for them. Import reads the picked file straight into memory — no temp copies.
 
 Two formats, one canonical:
 

docs/design/data-notes.md

@@ -1,4 +1,4 @@
-# Tanemaki — Notas de diseño: nombres, ciencia, notas y registro de banco
+# Tane — Notas de diseño: nombres, ciencia, notas y registro de banco
 
 *Documento de reflexión previo al modelo de datos formal. Lengua: español (el código irá en inglés).*
 *Refina y expande la Capa 1 del [PLAN.md](../../PLAN.md) §3.*
@@ -73,7 +73,7 @@ Con eso, el **catálogo empaquetado se licencia CC-BY** (Wikidata CC0 + GBIF CC-
 
 ### Consecuencia de diseño: los nombres de variedad los pone la comunidad
 
-El **banco de nombres de especie** (capa 4 de §2) viene de Wikidata/GBIF. Pero la **variedad/cultivar** (capa 3, la que más importa a quien guarda semillas) **la teclea la gente**, no una autoridad. Con el tiempo, los nombres de variedad compartidos entre usuarios de Tanemaki (de forma agregada/opcional) van formando **el propio banco folclórico de nombres de Tanemaki** — descentralizado, vivo, y que ninguna base oficial puede darte. Es coherente con todo el proyecto: la ciencia formal se toma prestada (CC0/CC-BY), pero el conocimiento de las variedades tradicionales es de la red, no de un registro.
+El **banco de nombres de especie** (capa 4 de §2) viene de Wikidata/GBIF. Pero la **variedad/cultivar** (capa 3, la que más importa a quien guarda semillas) **la teclea la gente**, no una autoridad. Con el tiempo, los nombres de variedad compartidos entre usuarios de Tane (de forma agregada/opcional) van formando **el propio banco folclórico de nombres de Tane** — descentralizado, vivo, y que ninguna base oficial puede darte. Es coherente con todo el proyecto: la ciencia formal se toma prestada (CC0/CC-BY), pero el conocimiento de las variedades tradicionales es de la red, no de un registro.
 
 Nota (posible puente futuro, no ahora): como anclamos a GBIF/Wikidata, ese banco folclórico —taxonomía de variedades y nombres vernáculos— es justo lo que los portales abiertos de biodiversidad (GBIF, atlas ALA) tienen más flojo. Deja la puerta a un export *opt-in* estilo Darwin Core, con guardas estrictas de privacidad. No es fase ni modelo; detalle e intención en [open-decisions.md](open-decisions.md) §C.
 
@@ -95,7 +95,7 @@ Principios (coherentes con todo lo demás):
 - **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.
+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 Tane de una libreta: reduce a un toque lo que en papel era investigar y copiar a mano.
 
 ### ¿Es viable la "varilla mágica" con datos abiertos? Sí
 

docs/design/first-sprint.md

@@ -1,4 +1,4 @@
-# Tanemaki — Primer sprint (Fase 1: inventario)
+# Tane — Primer sprint (Fase 1: inventario)
 
 *Guía de arranque para desarrollar en **Claude Code** (en la máquina, donde Flutter corre y git funciona). Objetivo: un **inventario usable, offline y cifrado**. Nada de capa social todavía. Convenciones y decisiones en [`../../CLAUDE.md`](../../CLAUDE.md) y [`open-decisions.md`](open-decisions.md).*
 

docs/design/g1-integration.md

@@ -1,4 +1,4 @@
-# Tanemaki — Integración opcional de Ğ1 (moneda libre)
+# Tane — 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.*
 
@@ -6,13 +6,13 @@
 
 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.
+1. **Misma red de confianza.** Tane 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**.
+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 Tane—, 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):
+Tane 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)**
 
@@ -20,7 +20,7 @@ Tanemaki no elige "regalo vs. dinero": ofrece un **abanico**, del más procomún
 
 ## Ğ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**:
+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 Tane 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.
@@ -31,9 +31,9 @@ Estrategia sugerida: **primer piloto dentro de los grupos de semillas de Ğ1**,
 ## 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.
+- **Sin custodia ni rieles de pago en la app** (coherente con sharing-model §4.3). Tane **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.
+- **Inclusión intacta.** Usar Tane **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.
+- **Acoplamiento con cuidado.** Reusar la WoT/identidad de Ğ1 es potente, pero no debe volver a Tane dependiente de Duniter para funcionar. Ğ1 informa/enriquece; no manda.
 
 ## Niveles de integración (de menos a más)
 
@@ -41,19 +41,19 @@ Estrategia sugerida: **primer piloto dentro de los grupos de semillas de Ğ1**,
 
 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.
+3. **Identidad y confianza compartidas (la sinergia profunda).** Como la WoT de Duniter v2 está en cadena e indexada (duniter-squid, GraphQL), Tane 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 Tane. 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).
+4. **Pago dentro de la app (descartado).** Firmar transferencias Ğ1 desde Tane 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.
+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 Tane, 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.
+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 Tane 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.
+2. **Mismo modelo de certificación.** Modelar la WoT de Tane 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.
+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 Tane: un miembro Ğ1 llega **pre-avalado**. Tane **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**.

docs/design/network-trust.md

@@ -1,4 +1,4 @@
-# Tanemaki — Red, confianza y mensajería (capa social descentralizada)
+# Tane — 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).*
 

docs/design/open-decisions.md

@@ -1,4 +1,4 @@
-# Tanemaki — Decisiones abiertas y "qué chirría"
+# Tane — 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.*
 
@@ -46,7 +46,7 @@ Estas fijan `schemaVersion = 1` y el arranque técnico:
 
 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.
+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 Tane 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.
 

docs/design/security-privacy.md

@@ -1,4 +1,4 @@
-# Tanemaki — Seguridad y privacidad (modelo de amenaza)
+# Tane — 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.*
 

docs/design/sharing-model.md

@@ -1,4 +1,4 @@
-# Tanemaki — Modelo de compartición y mercado (nota de diseño)
+# Tane — Modelo de compartición y mercado (nota de diseño)
 
 *Documento de reflexión. Lengua: español (discusión). Desarrolla la Capa 3 del [PLAN.md](../../PLAN.md) §3–§4 y §6, y conecta con el modelo de datos ([data-model.md](data-model.md)).*
 
@@ -56,13 +56,13 @@ Permitir vender es legítimo y realista —hay quien produce semilla artesanal,
 ### 4.2 Legal: vender reengancha justo el problema Kokopelli
 Esto es lo delicado. La **venta** de variedades tradicionales no registradas es exactamente lo que multó a Kokopelli; el regalo/trueque entre aficionados o agricultores está mucho más protegido (PLAN §6). Al añadir "venta" aumentas la exposición legal *de tus usuarios*. Mitigaciones de diseño:
 
-- **Tanemaki no es un mercado, es infraestructura neutral.** La app no opera el mercado, no publica un catálogo central, no pone en venta nada: son las personas, entre iguales (como flohmarkt). Esta neutralidad es la mejor defensa (replica por qué Kokopelli fue vulnerable —venta + operador central identificable— y evita ambas).
+- **Tane no es un mercado, es infraestructura neutral.** La app no opera el mercado, no publica un catálogo central, no pone en venta nada: son las personas, entre iguales (como flohmarkt). Esta neutralidad es la mejor defensa (replica por qué Kokopelli fue vulnerable —venta + operador central identificable— y evita ambas).
 - **Aviso contextual por región, no policía.** Al marcar una Offer como "venta", la app puede mostrar una nota suave y dependiente del país ("vender semilla de variedades no registradas puede estar restringido en tu país"). Informar, no bloquear, no vigilar.
 - **La venta prioriza el marco de conservación/compartición** en el discurso y el diseño; el dinero es una opción, no la portada.
 
 ### 4.3 Nada de rieles de pago (esto es innegociable)
 - **La app NO procesa pagos, NO cobra comisión, NO retiene dinero, NO muestra publicidad.** El pago se acuerda **directamente entre las personas** (efectivo, su propia transferencia, lo que sea), *fuera* de la app.
-- Meter pagos dentro convertiría a Tanemaki en operador central: obligaciones KYC/AML, custodia de fondos, y reintroduce justo la centralización que se quiere evitar. Además mataría la sostenibilidad (§7: financiación por subvenciones/donaciones, no por comisiones).
+- Meter pagos dentro convertiría a Tane en operador central: obligaciones KYC/AML, custodia de fondos, y reintroduce justo la centralización que se quiere evitar. Además mataría la sostenibilidad (§7: financiación por subvenciones/donaciones, no por comisiones).
 - Resultado: es el "efecto Wallapop sin Wallapop" también para la venta — anuncia y conecta; el dinero cambia de manos entre personas.
 
 ### 4.4 Representación del precio

docs/design/testing.md

@@ -1,4 +1,4 @@
-# Tanemaki — Estrategia de pruebas (casi-TDD, sin depender de pruebas manuales)
+# Tane — Estrategia de pruebas (casi-TDD, sin depender de pruebas manuales)
 
 *Convención del proyecto. Objetivo: **cada comportamiento cubierto por una prueba automática**; las pruebas manuales son la excepción, no la red de seguridad.*
 

docs/design/usability-and-architecture.md

@@ -1,4 +1,4 @@
-# Tanemaki — Usabilidad y generalización (nota de diseño)
+# Tane — Usabilidad y generalización (nota de diseño)
 
 *Documento de reflexión. Lengua: español (discusión). Afecta a la estructura del primer commit de código, por eso conviene decidirlo ahora.*
 
@@ -56,17 +56,17 @@ Prior art que lo confirma: el software de "Library of Things" (Lend Engine, myTu
 
 ### La reconciliación: generaliza el MOTOR, no el PRODUCTO
 
-Usabilidad y reutilización apuntan **a la misma respuesta**. Tanemaki (semillas) y la futura app de cosas son **productos separados, simples, monotema**, cada uno con su nombre y su cara; por debajo comparten un **motor común** que resuelve una sola vez la fontanería P2P/confianza/préstamo. Generalizas donde nadie lo ve (el engine), no donde todo el mundo lo sufre (el producto).
+Usabilidad y reutilización apuntan **a la misma respuesta**. Tane (semillas) y la futura app de cosas son **productos separados, simples, monotema**, cada uno con su nombre y su cara; por debajo comparten un **motor común** que resuelve una sola vez la fontanería P2P/confianza/préstamo. Generalizas donde nadie lo ve (el engine), no donde todo el mundo lo sufre (el producto).
 
 ### ¿Ahora o después? "Diseña para generalizar, implementa uno"
 
-- **Construye solo Tanemaki ahora.** No hagas la plataforma genérica de forma especulativa (riesgo de abstracción prematura: te sale la abstracción equivocada).
+- **Construye solo Tane ahora.** No hagas la plataforma genérica de forma especulativa (riesgo de abstracción prematura: te sale la abstracción equivocada).
 - **Pero estructura el repo desde el primer commit como workspace** con un paquete `core/` + `app_seeds/`, respetando una **costura de dominio limpia**. Extraer más adelante la app de cosas es barato si la costura se respeta; retrofitear un motor genérico dentro de un monolito es caro.
 - **En `core` va solo lo obviamente compartido** (identidad, sync, `Offer`, `Party`, confianza, `Pledge`/registro de préstamo). Lo específico de semillas (`Species`, germinación, cosecha) se queda en el dominio de semillas. Se sube más a `core` solo cuando la segunda app revele la forma real compartida (regla del tres — pero el núcleo P2P/confianza/pagaré es conocido-compartido de antemano, así que extraerlo ya está justificado).
 
 ### Cómo generalizan las entidades (mapa)
 
-| Genérico (`core`) | Semillas (Tanemaki) | Cosas (futura) |
+| Genérico (`core`) | Semillas (Tane) | Cosas (futura) |
 |---|---|---|
 | `Item` / holding | `Variety` + `Lot` | herramienta / objeto |
 | `Offer` (+ tipo **`lend`**: devolver *el mismo* objeto) | gift/exchange/sale/wanted | lend/gift/sale/wanted |
@@ -78,7 +78,7 @@ Nota: el `Plantare` es el caso semillas de un concepto genérico **`Pledge`** (p
 
 ### Nombres
 
-- **Tanemaki** = el producto de semillas.
+- **Tane** = el producto de semillas.
 - El **núcleo** conviene que tenga nombre neutro. Tu organización **Comunes** encaja de libro ("motor del procomún"): p.ej. paquete `commons_core` o similar. La app de cosas tendrá su propio nombre cuando llegue.
 
 ### Consecuencia técnica inmediata (por eso se decide ahora)
@@ -86,14 +86,14 @@ Nota: el `Plantare` es el caso semillas de un concepto genérico **`Pledge`** (p
 El **primer commit de código** no es "una app Flutter", sino un **workspace** (pub workspaces / melos) con:
 
 ```
-tanemaki/            (repo)
+tane/            (repo)
   packages/
     commons_core/    ← identidad, sync, Offer, Party, Pledge, confianza, discovery
   apps/
-    app_seeds/       ← Tanemaki: Species, germinación, cosecha, UI de semillas, i18n
+    app_seeds/       ← Tane: Species, germinación, cosecha, UI de semillas, i18n
 ```
 
-Drift: tablas de `core` + tablas de dominio de semillas, con las migraciones versionadas (§5 del modelo) por paquete. Así, el día que exista `app_things`, reusa `commons_core` sin tocar Tanemaki.
+Drift: tablas de `core` + tablas de dominio de semillas, con las migraciones versionadas (§5 del modelo) por paquete. Así, el día que exista `app_things`, reusa `commons_core` sin tocar Tane.
 
 ---
 

docs/i18n.md

@@ -1,6 +1,6 @@
-# Translating Tanemaki
+# Translating Tane
 
-Tanemaki is multilingual **by design** — international, not any-country-first
+Tane is multilingual **by design** — international, not any-country-first
 (see the golden rules in [`../CLAUDE.md`](../CLAUDE.md)). Translations live as
 one JSON file per locale, a format Weblate (and any translation platform that
 speaks nested JSON) handles natively.

docs/release.md

@@ -1,4 +1,4 @@
-# Releasing Tanemaki (manual, no CI yet)
+# Releasing Tane (manual, no CI yet)
 
 Block 1 ships as a self-contained Android app (desktop builds also work). There
 is no release pipeline yet — this page is the by-hand checklist.