Capture
La puerta de entrada del conocimiento hacia DARXI, y el único contexto delimitado que hoy se puede ejecutar de extremo a extremo.
Capture es la puerta de entrada del conocimiento hacia DARXI. Su responsabilidad es única: transformar entradas externas en objetos de conocimiento y publicar eventos. No decide, no razona, no planifica y no ejecuta.
Da igual qué se comparta —un vídeo, un hilo, un documento, una idea suelta escrita de madrugada—. No existen «vídeos» ni «artículos»: todo termina siendo el mismo tipo de cosa.
Lo que lo separa de un resumidor es la segunda pregunta. Un resumidor responde de qué habla esto. Capture responde también por qué llegó esto aquí: analiza el contenido y además el mensaje que lo acompañaba, el proyecto al que apunta y lo que ya existe sobre eso. Esa frase de acompañamiento es lo primero que cualquier sistema convencional tira a la basura.
Seis etapas, en este orden. Cada una guarda su salida como artefacto con idioma y productor declarados, así que la siguiente ejecución puede reutilizarla en vez de volver a pagarla.
- metadataSe resuelve la URL y se lee lo que la plataforma declara del contenido.
- captionsSe buscan subtítulos humanos antes que nada. Son mejores que cualquier transcripción automática, y gratis.
- transcriptSi no hay subtítulos utilizables, se transcribe el audio. Es la etapa más cara del recorrido.
- transcript_esSi el texto no está en el idioma del usuario, se traduce. Se decide por el idioma declarado, no por adivinanza.
- knowledgeEl texto pasa a resumen, ideas y etiquetas, siempre a través del Router. Ninguna parte del código nombra un modelo.
- dashboardLa tarjeta aparece en el Inbox desde el primer estado y se enriquece a la vista.
Capture es la forma de entrada; el producto que el usuario usa es el Inbox. La tarjeta aparece al instante, vacía, y se llena sola: empieza a contar valor desde el primer segundo en vez de esperar a estar completa.
El estado no es una etiqueta técnica: es la promesa en curso. «Transcribiendo» significa «estoy escuchando el vídeo por ti», y el Inbox lo cuenta en esos términos.
Cada etapa guarda su salida como artefacto con su idioma y su productor declarados. La siguiente ejecución los reutiliza en vez de volver a pagarlos — pero sólo si siguen sirviendo.
La comprobación importa más de lo que parece. Un transcript guardado en árabe no es reutilizable para un vídeo que declara estar en inglés, y sin esa comprobación el sistema traducía un texto equivocado y lo guardaba como si fuera correcto. El defecto existió, se reprodujo y se cerró.
La jerarquía es por calidad, no por comodidad: primero subtítulos humanos, luego automáticos de la plataforma, y sólo al final transcripción por audio. Cada elección queda registrada con la puntuación que la produjo, así que se puede discutir después.
La transcripción por audio corre en local. Es la etapa más lenta y la única que escala con la duración del vídeo, y por eso el alcance de esta versión se acota a piezas cortas y se mide en vez de suponerse.
El sprint sale del registro de git, no de una constante escrita aquí: esta página no puede quedarse anunciando uno que el árbol ya dejó atrás.
- Sprint fusionado
- S4.2
- medido el · hoy
- Servicios
- 3
- medido el · hoy
- Migraciones
- 5
- medido el · hoy
- Commits
- 21
- medido el · hoy
Dicho antes de que lo pregunten. Un producto que enseña solo lo que funciona no informa: obliga a descubrir el resto por sorpresa.
- Dos semanas de uso real sin escribir código. Es la única fase que responde la pregunta del MVP, y no se ha hecho.
- El último sprint de traducción y jerarquía no está fusionado. Tres rondas de revisión independiente lo declararon no fusionable, cada una cerrando lo que se le pidió y rompiendo algo nuevo.
- Los ADR de Capture siguen propuestos, sin firma. Bajo ellos, esta versión es un instrumento de validación de producto, no el contexto delimitado: su código es desechable por diseño y si funciona, el producto se reescribe sobre la arquitectura de DARXI.
- Todo el conocimiento depende del Router, cuya postura de autorización cambia sola. Se comprueba el endpoint que se va a usar antes de cada arranque, nunca el de salud.