diff --git a/RAG/docs/HISTORIAL_SESIONES.md b/RAG/docs/HISTORIAL_SESIONES.md
index 8395dc1..36c234e 100644
--- a/RAG/docs/HISTORIAL_SESIONES.md
+++ b/RAG/docs/HISTORIAL_SESIONES.md
@@ -50,3 +50,5 @@ Dar continuidad al RAG en `RAG/` a partir del estado actual documentado.
 - Comparacion de auditorias del modelo (pre y post cleanup) documentada en `RAG/docs/TEMP_AUDITORIA_MODELO_PRE_CLEANUP.md`, confirmando una ganancia clara en nitidez y precision del RAG al evaluar el codigo.
 - Implementacion de ingesta directa de carpetas locales desde el playground: el navegador empaqueta la carpeta en un `.zip` en memoria (filtrando `node_modules`, `dist`, `.git`, etc. con logica nativa) y el backend usa `adm-zip` para extraerla de forma segura en un directorio temporal antes de la ingesta.
 - Correccion en `IngestService` (`resolveInputFiles` y `normalizeDocumentKey`) para escanear archivos desde la ruta temporal extraída (`readPath`) en lugar del identificador lógico al subir carpetas completas, evitando error de `ENOENT`.
+- Revision inicial del corpus `/_imports/gstreamer-rag-text` como futura base documental especializada para GStreamer.
+- Creacion de `RAG/docs/TASK_INGESTA_GSTREAMER.md` con el plan operativo para ingerirlo bajo un scope unico, validar retrieval y prepararlo para uso posterior con modelo local.
diff --git a/RAG/docs/TASK_INGESTA_GSTREAMER.md b/RAG/docs/TASK_INGESTA_GSTREAMER.md
new file mode 100644
index 0000000..4321f4a
--- /dev/null
+++ b/RAG/docs/TASK_INGESTA_GSTREAMER.md
@@ -0,0 +1,199 @@
+# Task: Ingesta controlada de corpus GStreamer
+
+**Proyecto:** Workspace de tools IA para empresas  
+**Modulo:** RAG  
+**Ultima actualizacion:** 2026-04-09  
+**Ultima modificacion por:** Agente RAG 2  
+**Estado:** Planificado
+
+---
+
+## Proposito
+
+Preparar una ingesta controlada y verificable de la documentacion oficial de GStreamer para usarla como corpus documental especializado dentro del RAG.
+
+El objetivo final no es solo "cargar docs", sino dejar el corpus listo para:
+
+- hacer `bootstrap` global del dominio GStreamer
+- recuperar documentacion oficial de forma fiable
+- apoyar a un modelo local en revision y correccion de codigo que use GStreamer
+
+---
+
+## Fuente elegida
+
+Fuente principal confirmada:
+
+```text
+/home/pancho/Documentos/Empresa/Desarrollo/IA/_imports/gstreamer-rag-text
+```
+
+Motivos:
+
+- la documentacion ya esta normalizada a `.txt`
+- la estructura en carpetas y ficheros es mejor que un monolito para retrieval
+- permite recuperar mejor por tema, plugin, elemento o manual
+- evita mezclar demasiadas secciones distintas en el mismo chunk
+
+---
+
+## Objetivo de modelado del corpus
+
+Todo el corpus debe quedar agrupado bajo un unico scope logico dedicado a GStreamer.
+
+Eso permitira que en el playground aparezca como un scope identificable y seleccionable, en lugar de quedar repartido en multiples scopes pequenos.
+
+### Scope recomendado
+
+- `sourceRef`: `gstreamer-official`
+- `sourceId`: `corpus:gstreamer:official:v1`
+- `mode`: `mechanical`
+- `chunk mode esperado`: `documental`
+
+### Tags recomendados
+
+- `gstreamer`
+- `official-docs`
+- `multimedia`
+- `documental`
+
+---
+
+## Resultado esperado tras la ingesta
+
+Al consultar `GET /sources`, deberiamos ver un scope similar a:
+
+```text
+gstreamer-official [documental]
+```
+
+Y ese scope deberia servir para:
+
+1. hacer `bootstrap` general del dominio GStreamer
+2. recuperar docs sobre plugins, pads, states, negotiation, bus, pipelines, caps, etc.
+3. mantenerlo aislado de `docs`, `RAG/docs` y `RAG/src`
+
+---
+
+## Riesgos identificados
+
+### 1. Volumen alto
+
+La fuente contiene miles de ficheros.
+
+Riesgos:
+
+- tardanza alta en la vectorizacion
+- errores parciales en una carga masiva
+- fallos del playground en una subida tan grande
+
+### 2. Ruido documental
+
+Los ficheros incluyen restos de navegacion tipo:
+
+- `Toggle navigation`
+- `Edit on GitLab`
+- breadcrumbs y subpages
+
+Esto no impide la ingesta, pero puede introducir ruido semantico.
+
+### 3. Recuperacion dispersa
+
+Aunque todo quede en un mismo scope, el corpus cubre muchas capas:
+
+- core
+- libraries
+- plugins
+- tutorials
+- app manual
+- plugin development
+
+Esto obliga a validar retrieval antes de usarlo para tareas reales de depuracion.
+
+---
+
+## Estrategia de ejecucion recomendada
+
+### Fase 1. Validacion tecnica de la ingesta
+
+Objetivo:
+- confirmar que el flujo de ingesta soporta este volumen y formato sin romper
+
+Pasos:
+
+1. revisar y corregir el error actual de ingesta (`Cannot read properties of undefined (reading 'map')`) si sigue reproduciendose
+2. elegir el metodo de ingesta mas fiable para esta carga
+3. ejecutar una ingesta controlada con el corpus completo bajo el scope acordado
+
+### Fase 2. Verificacion del scope
+
+Objetivo:
+- confirmar que el corpus quedo agrupado correctamente
+
+Pasos:
+
+1. comprobar `GET /sources`
+2. verificar que aparece un unico scope de GStreamer
+3. comprobar tags y `sourceId`
+
+### Fase 3. Validacion funcional del retrieval
+
+Objetivo:
+- asegurar que el RAG devuelve documentacion oficial util, no solo chunks ruidosos
+
+Consultas de prueba sugeridas:
+
+1. "explica la diferencia entre pads static y request pads en GStreamer"
+2. "como funciona caps negotiation en GStreamer"
+3. "que estados principales tiene un pipeline y como se gestionan"
+4. "como enlazar elementos dinamicos y manejar pads-added"
+5. "que dice la documentacion oficial sobre bus messages y manejo de errores"
+
+### Fase 4. Validacion del bootstrap
+
+Objetivo:
+- comprobar que el corpus sirve como mapa inicial del dominio completo
+
+Consulta sugerida:
+
+```text
+dame un mapa inicial de la documentacion oficial de GStreamer, sus bloques principales, conceptos nucleares, areas tecnicas y que partes son mas utiles para depurar aplicaciones grandes
+```
+
+### Fase 5. Preparacion del flujo con modelo local
+
+Objetivo:
+- usar el corpus ya validado como base documental para revisar codigo real
+
+Enfoque recomendado:
+
+1. no pedir al modelo local que revise toda una aplicacion enorme de golpe
+2. pasarle modulos o archivos concretos
+3. acompañar siempre con:
+   - logs de error
+   - mensajes de GStreamer
+   - sintomas observados
+4. usar el RAG como fuente documental oficial, no como sustituto del contexto tecnico del fallo
+
+---
+
+## Criterio de exito
+
+La task se considerara bien cerrada cuando se cumplan estas condiciones:
+
+1. la documentacion de GStreamer este ingerida bajo un unico scope reconocible
+2. el playground permita seleccionarlo facilmente
+3. el `bootstrap` global funcione sobre todo el corpus
+4. el retrieval devuelva documentacion oficial util en consultas de prueba
+5. el corpus quede listo para usarse con un modelo local en tareas de revision de codigo
+
+---
+
+## Siguiente ejecucion prevista
+
+Si el usuario valida este plan, la siguiente fase sera:
+
+1. diagnosticar y corregir definitivamente el fallo actual de ingesta
+2. ejecutar la ingesta real del corpus GStreamer
+3. validar retrieval y bootstrap
+4. dejar preparado el terreno para la integracion con el modelo local