Add design docs; update README/PLAN

docs/design/data-notes.md

@@ -0,0 +1,124 @@
+# Tanemaki — 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.*
+
+El objetivo de estas notas es cuadrar una tensión concreta: que la app permita guardar datos ricos (nombre científico, enlaces a Wikipedia, germinación, notas personales, historial de banco) **sin volverse pesada ni difícil de usar**. La respuesta corta es un principio + una distinción de modelado.
+
+---
+
+## 1. Principio rector: simple por defecto, profundidad a demanda
+
+**No construir dos apps (un "modo simple" y un "modo avanzado" como mundos separados).** Los modos globales confunden (¿en cuál estoy?, ¿dónde quedó ese campo?) y parten la comunidad de usuarios. En su lugar, **una sola app que parece simple para todo el mundo y revela profundidad cuando se pide** (progressive disclosure).
+
+Cómo se traduce:
+
+- **El alta en 20 segundos.** Añadir una semilla pide lo mínimo: una **etiqueta** (el nombre que tú usas) y, si quieres, una **foto** y una **cantidad**. Nada más es obligatorio. Alguien puede inventariar su cajón entero a base de nombres y fotos, y ya tiene una app útil.
+- **"Añadir más…"** despliega, por secciones plegadas, todo lo demás: identificación científica, germinación, procedencia, ubicación de almacén, notas largas, enlaces. Quien no lo toca, no lo ve.
+- **Preferencia global "mostrar campos avanzados"** (opcional): solo cambia *qué secciones vienen desplegadas por defecto*, nunca esconde funciones ni obliga a nada. Una persona novata nunca ve ruido; quien gestiona un banco lo activa una vez y se acuerda.
+
+Regla de oro: **cualquier campo más allá de la etiqueta es opcional y, a poder ser, autorrellenable.** El trabajo lo hace la app, no la persona.
+
+---
+
+## 2. Los nombres (modelo realista, en capas)
+
+Cómo nombra la gente de verdad una semilla, de lo más personal a lo más formal:
+
+1. **Etiqueta propia** *(lo único obligatorio)* — texto libre, en tu idioma: "el tomate de la abuela", "judía del huerto de arriba 2024". Es lo que tecleas y lo que ves en la lista.
+2. **Nombres comunes / vernáculos** *(opcional, lista)* — "tomate de colgar", "tomàquet de penjar", con idioma/región. Pueden venir del catálogo (§3) o añadirlos tú. Son los que la gente busca.
+3. **Variedad / cultivar** *(opcional)* — 'Marmande', 'Cherokee Purple'. **Ojo: para quien guarda semillas, esto suele ser la identidad que más importa**, y NO es el nombre científico. Merece su propio campo.
+4. **Nombre científico (especie)** *(opcional)* — *Solanum lycopersicum*. **Nunca se teclea en frío**: autocompletado desde un catálogo ligero empaquetado (§3). Es una etiqueta que la app te ofrece, no un deber.
+
+La clave: solo la capa 1 es obligatoria. Las capas 2–4 son opcionales y, en su mayoría, se rellenan solas al vincular con el catálogo.
+
+---
+
+## 3. La "parte científica" y los enlaces, sin peso
+
+El truco para tener conocimiento botánico sin embeber una base de datos enorme: **anclar cada especie a un identificador estable y derivar el resto bajo demanda.**
+
+- El catálogo ligero empaquetado guarda, por especie, un **Wikidata QID** (p.ej. `Q23501` para el tomate). Con ese único identificador, **cuando hay red**, la app deriva gratis: el enlace a la **Wikipedia en tu idioma**, una foto, el taxón en **GBIF**, sinónimos. **Sin red**, sigues teniendo el nombre común y el científico guardados localmente. La "parte científica" es, por tanto, un dato minúsculo (un QID) que abre todo el conocimiento de la web solo si te interesa mirarlo.
+- **Notas personales:** un campo de texto libre (markdown) + una **lista de enlaces** (pega cualquier URL: Wikipedia, un hilo de foro, tu blog) + **adjuntos** (fotos, un PDF). Simple y abierto. Aquí caben lo científico, lo enciclopédico y lo personal como añadidos opcionales.
+- Encaja con los mockups: la ficha de ítem (`07_inventory_item`) ya tiene pestañas **DOCS** y **COMMENTS** → notas, enlaces y adjuntos.
+
+Así, "datos científicos / Wikipedia / notas propias" son todo capas opcionales colgadas de un ancla mínima, no un formulario que agobia.
+
+---
+
+## 3-bis. Fuentes de nombres y datos: qué va offline, qué online, con qué licencia
+
+La pregunta clave: *¿qué banco de nombres es realista usar, qué se empaqueta (offline) y qué se consulta bajo demanda (online), y qué licencia lo permite?* Porque empaquetar datos ajenos en la app es redistribuirlos, y ahí manda la licencia.
+
+### Lo que SÍ es realista
+
+**Empaquetar offline (núcleo, tiene que ser ligero):** un catálogo **curado** de las especies hortícolas relevantes en tu contexto (península / Mediterráneo primero, ampliable), NO una taxonomía entera. Por especie: nombre científico + unos pocos nombres comunes por idioma + **Wikidata QID** + clave GBIF. Son del orden de cientos a pocos miles de especies → caben en pocos MB. Se construye extrayendo de:
+
+- **Wikidata** — licencia **CC0** (dominio público): *la mejor base para empaquetar*, porque redistribuir es libre y sin ataduras. Tiene ítems de taxón, nombres vernáculos en muchos idiomas y enlaces a Wikipedia. Cobertura de nombres comunes irregular, pero suficiente para un catálogo curado. **Es nuestro ancla.**
+- **GBIF Backbone Taxonomy** — licencia **CC-BY 4.0** (solo pide atribución). Nombres científicos y sinónimos autoritativos, con nombres vernáculos, y **dumps descargables** (Darwin Core Archive). Se usa para validar/completar el científico. Atribución en el "Acerca de".
+
+Con eso, el **catálogo empaquetado se licencia CC-BY** (Wikidata CC0 + GBIF CC-BY), limpio y redistribuible.
+
+**Consultar online (opcional, derivado del QID/clave, siempre cacheado):**
+- **Wikipedia** en tu idioma (resumen + enlace) y **Wikimedia Commons** (foto) — del QID, gratis.
+- **GBIF** — ficha del taxón, sinónimos, distribución/mapa.
+- **Permapeople** — base comunitaria de cultivo (cómo sembrar, asociaciones…), **CC-BY-SA 4.0**, con API (requiere alta y pedir acceso). Útil como *referencia online enlazada*, no para empaquetar (ver abajo).
+
+### Lo que NO es realista (o hay que evitar)
+
+- **Empaquetar la taxonomía completa** (GBIF backbone entero = millones de nombres; Wikidata entero): pesado e innecesario. Curar, no volcar.
+- **PFAF (Plants For A Future):** datos valiosos de plantas útiles, pero **licencia restrictiva** → no empaquetar.
+- **Dejar que la licencia CC-BY-SA "contamine" el catálogo:** si mezclas datos **share-alike** (Permapeople, Practical Plants) *dentro* del bundle, el catálogo entero queda obligado a CC-BY-SA. No es malo (encaja con el ethos copyleft), pero para mantener el núcleo simple y CC-BY, **trata lo SA como consulta online enlazada**, no como dato embebido. Decisión deliberada, no accidental.
+- **Esperar que cualquier base autoritativa conozca tus variedades tradicionales / cultivares.** No las tiene, por definición: las landraces no están en catálogos oficiales (y ahí está justo el sentido político, §6 del PLAN). Los catálogos oficiales (registro UE/España, CPVO) son *las variedades registradas* — lo contrario de lo que cuidas.
+
+### 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.
+
+### Regla transversal: online siempre opcional
+
+Nada del núcleo depende de la red. Offline tienes inventario completo, nombres del catálogo empaquetado, notas y registro de banco. Online solo *enriquece* (Wikipedia, fotos, GBIF, cultivo Permapeople, y más adelante los mapas de la Capa 3) y todo **degrada con elegancia**: si no hay red, simplemente no aparece esa capa extra, sin errores ni bloqueos.
+
+---
+
+## 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:
+
+- **Variedad (accession)** — la *identidad*: nombres, especie, cultivar, notas, enlaces. Permanente. Es lo que ves en el inventario.
+- **Lote (lot / batch)** — una *hornada concreta* que tienes de esa variedad: **año de cosecha**, cantidad, ubicación de almacén, resultado de germinación. Puedes tener **varios lotes de la misma variedad** (el de 2023 y el de 2024) y no mezclarlos. El año vive aquí, que es donde importa (la germinación decae con la edad del lote).
+- **Movimiento (event)** — el *diario* de un lote: **recibido de** X (fecha), **entregado a** Y (fecha) = *un Plantare*, **sembrado** (fecha), **test de germinación** (fecha, %). Entradas y salidas son, simplemente, tipos de movimiento.
+
+Qué te da esta separación, "gratis":
+
+- **Entrada/salida, fecha, año, germinación** dejan de ser campos ambiguos: cada uno pertenece a su nivel (año→lote, fechas de intercambio→movimiento, identidad→variedad).
+- Conecta con la pestaña **HISTORY** del mockup: es la lista de movimientos del ítem.
+- Conecta con §5-bis: **cada movimiento de salida ES un Plantare**, y la cadena de movimientos entre personas es el **DAG de procedencia** de la variedad.
+- Habilita el **banco colectivo**: se sabe quién aportó qué lote y cuándo, sin ensuciar la identidad de la variedad.
+
+**Germinación como evento** (opcional, avanzado): fecha, tamaño de muestra, nº germinadas, % (calculado), notas. Con el año del lote, permite avisos amables tipo "este lote es de 2019; su germinación puede haber bajado, ¿lo pruebas?".
+
+---
+
+## 5. Qué se ve en "simple" vs. qué revela "avanzado"
+
+| Nivel | Campos | Cuándo aparece |
+|---|---|---|
+| **Simple (siempre)** | etiqueta, foto, cantidad cualitativa, categoría, ¿se comparte? | alta básica, 20 s |
+| **Un toque más** (habitual en banco) | año del lote, procedencia (de quién), fecha de entrada | un despliegue |
+| **Avanzado (a demanda)** | nombre científico + Wikidata/Wikipedia, cultivar, nombres vernáculos múltiples, varios lotes, germinación, ubicación de almacén, notas largas, enlaces, historial completo | secciones plegadas / preferencia |
+
+---
+
+## 6. Riesgo a vigilar (banco colectivo)
+
+En un banco colectivo la tentación es **exigir muchos datos** por cada aporte, y eso mata la participación. El diseño debe garantizar que **un aporte mínimo sea siempre válido** (nombre + año + quién lo aporta), y que el resto se rellene *con el tiempo* o *entre varias personas* (colaborativo: alguien añade el nombre científico, otra persona sube una foto, otra registra una germinación). La app acompaña; nunca hace de aduana.
+
+---
+
+## 7. Qué falta decidir antes del modelo formal
+
+- ¿El catálogo ligero empaquetado se centra primero en hortícolas de la península (para que el autocompletado sea realista en tu contexto) y se amplía luego? Probablemente sí.
+- ¿"Cantidad" a nivel de lote con unidades cualitativas por defecto (§3) y precisión opcional? Sí, coherente con lo acordado.
+- ¿Ubicación de almacén como texto libre o como lista reutilizable ("nevera", "trastero", "banco del pueblo")? Empezar por texto libre con sugerencias.
+- ¿Un lote puede pertenecer a un banco colectivo *y* a tu inventario personal a la vez? Afecta al modelo de permisos/compartición; decidir al abordar la Capa 2–3.