La unidad de diseño es la tarea

Un workflow no empieza con una plataforma. Empieza observando trabajo real: recibir un brief, comprobar permisos, nombrar archivos, escuchar, decidir, exportar, revisar y entregar. Cada verbo tiene entradas, salidas, errores y costes diferentes. Agruparlos bajo «hacer el proyecto» impide saber qué puede delegarse de forma segura.

Clasifica las tareas como mecánicas, creativas o mixtas. Una mecánica aplica una regla comprobable, por ejemplo verificar que un nombre contiene un identificador. Una creativa decide intención o aceptación sonora. Una mixta prepara información automáticamente y termina en juicio humano. La clasificación no es permanente: cambia con el riesgo y la claridad del caso.

Mide la línea base antes de mejorarla: tiempo activo, espera, número de fallos, repeticiones y coste de recuperación. Una automatización que ahorra dos minutos pero crea una posibilidad de sobrescribir una fuente no es mejora. Reversibilidad y error cost pesan tanto como velocidad.

El árbol de decisión tiene cuatro salidas. Automatiza cuando regla, input y verificación son claros. Asiste cuando una herramienta puede proponer candidatos que una persona revisa. Crea plantilla cuando la variación es baja pero la ejecución sigue siendo humana. Mantén manual cuando el criterio creativo, la privacidad o el riesgo dominan.

Four Pillars puede aportar contexto creativo, pero no gobierna la operación. Ritmo, Textura, Intención y Narrativa pueden viajar dentro de un brief; la automatización no los aprueba. No publicar automáticamente, no enviar automáticamente y no sobrescribir automáticamente son fronteras del sistema. Toda acción material requiere aprobación humana, registro y rollback.

Protocolo común de ensayo supervisado

Antes de aceptar el diseño, recórrelo con el fixture desde la entrada hasta la salida simulada. Lee cada dato en voz alta, confirma de dónde procede y señala qué transformación se propone. En cada rama pregunta qué ocurre si el dato falta, si aparece dos veces, si llega tarde o si contradice el brief. El objetivo no es hacer el mapa más complejo, sino demostrar que falla de forma visible.

Registra estado inicial, acción preparada, resultado observado y responsable de decidir. La aprobación humana ocurre inmediatamente antes de cualquier efecto material. Si nadie responde, el estado permanece pendiente: el silencio no concede permiso. Si el coste estimado o la privacidad cambian, vuelve al gate correspondiente. Conserva siempre una ruta manual que permita terminar el ejercicio sin plataforma.

Ensaya también la recuperación. Introduce una excepción, aplica rollback y comprueba que la fuente y el registro siguen disponibles. Repite el mismo evento para verificar que no duplica trabajo. Al cerrar, distingue claramente simulado, preparado, aprobado y realizado. Este vocabulario evita declarar una implementación que solo existe como diagrama y convierte la evidencia en una base honesta para la siguiente iteración.

No rellenar lo que el cliente no dijo

Un intake seguro separa hechos entregados de inferencias. Objetivo, entregables, formatos, nombres, plazo, propietario y permiso deben provenir de una fuente autorizada. Si falta un dato, se marca pendiente; no se completa porque parezca habitual. Un workflow consistente puede producir errores consistentes cuando el input inventa hechos.

La estructura facilita preguntar solo lo necesario. Cada campo tiene tipo, obligatoriedad, ejemplo y condición de validez. «Fecha» no significa una fecha adivinada; significa que el proyecto no avanza a la fase que depende de ella. La privacidad exige recoger el mínimo: no guardes contacto, identidad o material si el ejercicio funciona con un identificador ficticio.

Los permisos también son datos. Distingue permiso para escuchar, procesar, compartir internamente, entregar y publicar. Una autorización técnica para acceder a un archivo no cubre todas las acciones. No enviar automáticamente y no publicar automáticamente deben aparecer en restricciones, incluso si una futura plataforma dispone de conectores.

Las condiciones de parada convierten un formulario en control. Archivo corrupto, permiso ausente, formato no definido, identidad vocal no autorizada o coste superior al techo detienen el flujo. Una negativa clara protege al proyecto y produce una pregunta concreta para la persona responsable.

El fixture `brief.json` contiene hechos inventados y una información faltante. Su propósito es practicar validación sin datos reales. El campo `deadline` declara que no es una fecha real. El estado ilustrativo impide presentarlo como encargo o evidencia de cliente.

Protocolo común de ensayo supervisado

Antes de aceptar el diseño, recórrelo con el fixture desde la entrada hasta la salida simulada. Lee cada dato en voz alta, confirma de dónde procede y señala qué transformación se propone. En cada rama pregunta qué ocurre si el dato falta, si aparece dos veces, si llega tarde o si contradice el brief. El objetivo no es hacer el mapa más complejo, sino demostrar que falla de forma visible.

Registra estado inicial, acción preparada, resultado observado y responsable de decidir. La aprobación humana ocurre inmediatamente antes de cualquier efecto material. Si nadie responde, el estado permanece pendiente: el silencio no concede permiso. Si el coste estimado o la privacidad cambian, vuelve al gate correspondiente. Conserva siempre una ruta manual que permita terminar el ejercicio sin plataforma.

Ensaya también la recuperación. Introduce una excepción, aplica rollback y comprueba que la fuente y el registro siguen disponibles. Repite el mismo evento para verificar que no duplica trabajo. Al cerrar, distingue claramente simulado, preparado, aprobado y realizado. Este vocabulario evita declarar una implementación que solo existe como diagrama y convierte la evidencia en una base honesta para la siguiente iteración.

Una referencia no es solo un enlace

Una fuente útil conserva URL, título, propietario o institución, fecha de acceso, permiso conocido, contenido usado y límite entre cita, paráfrasis e inferencia. Sin esa información, una futura revisión no puede distinguir qué cambió ni qué estaba autorizado.

La fecha de acceso importa en documentación sensible a versión. Interfaces, cuotas, formatos y condiciones pueden cambiar. Una captura demuestra una vista en un momento; no promete disponibilidad futura. Registra el alcance exacto de lo que la fuente sostiene y excluye afirmaciones más amplias.

La privacidad empieza antes de cargar. Revisa nombres, voces identificables, contactos, conversaciones, proyectos no publicados, metadatos y rutas de archivo. Pregunta si la capacidad necesita realmente ese dato. Si no, redáctalo, sustitúyelo por un identificador o mantén la tarea local.

Propiedad y permiso son diferentes. Tener una copia no autoriza transferirla. Una referencia pública puede consultarse, pero copiar grandes fragmentos puede exceder el uso necesario. Prefiere síntesis original y cita breve cuando corresponda. No inventes citas a partir de un resumen automático.

El registro también conserva exclusiones. «No inspeccionado», «privado» o «sin permiso» explica por qué una fuente no entró. Omitirla sin nota puede provocar que otra persona la vuelva a cargar. Un workflow seguro convierte la exclusión en dato visible.

Protocolo común de ensayo supervisado

Antes de aceptar el diseño, recórrelo con el fixture desde la entrada hasta la salida simulada. Lee cada dato en voz alta, confirma de dónde procede y señala qué transformación se propone. En cada rama pregunta qué ocurre si el dato falta, si aparece dos veces, si llega tarde o si contradice el brief. El objetivo no es hacer el mapa más complejo, sino demostrar que falla de forma visible.

Registra estado inicial, acción preparada, resultado observado y responsable de decidir. La aprobación humana ocurre inmediatamente antes de cualquier efecto material. Si nadie responde, el estado permanece pendiente: el silencio no concede permiso. Si el coste estimado o la privacidad cambian, vuelve al gate correspondiente. Conserva siempre una ruta manual que permita terminar el ejercicio sin plataforma.

Ensaya también la recuperación. Introduce una excepción, aplica rollback y comprueba que la fuente y el registro siguen disponibles. Repite el mismo evento para verificar que no duplica trabajo. Al cerrar, distingue claramente simulado, preparado, aprobado y realizado. Este vocabulario evita declarar una implementación que solo existe como diagrama y convierte la evidencia en una base honesta para la siguiente iteración.

El texto es una capa de acceso, no la fuente

Una transcripción facilita buscar y segmentar, pero el audio sigue siendo la fuente. Los sistemas pueden omitir palabras, confundir nombres, desplazar timestamps o asignar hablantes de forma incorrecta. Una frase fluida no es evidencia de exactitud.

Trabaja con niveles de confianza y categorías de error: palabra, puntuación, speaker, tiempo, omisión, adición e incertidumbre. Escucha alrededor del segmento, no solo la palabra. Cuando no puedas resolverlo, marca inaudible o dudoso; no completes por sentido.

Resumen y cita son objetos distintos. El resumen condensa con tus palabras; una cita reproduce contenido verificado. Nunca uses una paráfrasis automática entre comillas. Conserva enlace entre texto corregido, timestamp y fuente para que otra persona pueda comprobarlo.

Los marcadores convierten segmentos en navegación. Define identificador, inicio, final, etiqueta, confianza y propósito. Antes de importar al DAW, revisa que el formato temporal coincida y que el orden sea determinista. Un marcador útil indica función, no solo «parte buena».

La privacidad de voz importa. El fixture contiene narración original sin datos personales. En un proyecto real, confirma permiso antes de enviar audio a un servicio y revisa coste o límites de duración. La ruta manual permite completar el módulo sin cargar nada.

Protocolo común de ensayo supervisado

Antes de aceptar el diseño, recórrelo con el fixture desde la entrada hasta la salida simulada. Lee cada dato en voz alta, confirma de dónde procede y señala qué transformación se propone. En cada rama pregunta qué ocurre si el dato falta, si aparece dos veces, si llega tarde o si contradice el brief. El objetivo no es hacer el mapa más complejo, sino demostrar que falla de forma visible.

Registra estado inicial, acción preparada, resultado observado y responsable de decidir. La aprobación humana ocurre inmediatamente antes de cualquier efecto material. Si nadie responde, el estado permanece pendiente: el silencio no concede permiso. Si el coste estimado o la privacidad cambian, vuelve al gate correspondiente. Conserva siempre una ruta manual que permita terminar el ejercicio sin plataforma.

Ensaya también la recuperación. Introduce una excepción, aplica rollback y comprueba que la fuente y el registro siguen disponibles. Repite el mismo evento para verificar que no duplica trabajo. Al cerrar, distingue claramente simulado, preparado, aprobado y realizado. Este vocabulario evita declarar una implementación que solo existe como diagrama y convierte la evidencia en una base honesta para la siguiente iteración.

Un archivo legible dentro de seis meses

La organización empieza con un identificador estable, no con una carpeta bonita. Proyecto, rol, versión y estado forman nombres que pueden ordenarse y validarse. El nombre no debe incluir datos privados innecesarios. Un manifiesto relaciona identidad lógica, archivo, checksum, procedencia y estado.

El checksum verifica bytes, no calidad ni autoría. Dos archivos con el mismo hash son idénticos; dos hashes distintos solo indican diferencia. Usa esta evidencia para detectar duplicados y corrupción sin presentarla como aprobación sonora.

Distingue copiar de mover. Copiar crea otra instancia y exige saber cuál es canónica. Mover cambia ubicación y puede romper rutas. Archivar conserva con estado y política de recuperación; eliminar destruye acceso. Este curso no borra ni sobrescribe fuentes.

Versionar significa que v002 deriva de v001 con una razón registrada. «Final» no sustituye número ni estado. Usa draft, review, approved o archived solo cuando la persona autorizada lo confirma. Un agente no aprueba su propio resultado.

La recuperación se prueba antes de confiar. El fixture contiene una versión v000 ilustrativa. Copia el inventario a un espacio temporal, simula que v001 falla y recupera v000 sin tocar el registro original. Registra el procedimiento y el tiempo.

Protocolo común de ensayo supervisado

Antes de aceptar el diseño, recórrelo con el fixture desde la entrada hasta la salida simulada. Lee cada dato en voz alta, confirma de dónde procede y señala qué transformación se propone. En cada rama pregunta qué ocurre si el dato falta, si aparece dos veces, si llega tarde o si contradice el brief. El objetivo no es hacer el mapa más complejo, sino demostrar que falla de forma visible.

Registra estado inicial, acción preparada, resultado observado y responsable de decidir. La aprobación humana ocurre inmediatamente antes de cualquier efecto material. Si nadie responde, el estado permanece pendiente: el silencio no concede permiso. Si el coste estimado o la privacidad cambian, vuelve al gate correspondiente. Conserva siempre una ruta manual que permita terminar el ejercicio sin plataforma.

Ensaya también la recuperación. Introduce una excepción, aplica rollback y comprueba que la fuente y el registro siguen disponibles. Repite el mismo evento para verificar que no duplica trabajo. Al cerrar, distingue claramente simulado, preparado, aprobado y realizado. Este vocabulario evita declarar una implementación que solo existe como diagrama y convierte la evidencia en una base honesta para la siguiente iteración.

Primero simular, después decidir

Un batch amplifica una regla. Si la regla es incorrecta, amplifica el daño. Define alcance exacto, entrada, salida, orden y condición de éxito antes de preparar acciones. No uses globs ambiguos ni rutas amplias en un proceso real; el laboratorio trabaja solo con nombres ficticios.

El dry run produce un informe de lo que ocurriría sin modificar archivos. Incluye cada input, salida propuesta, conflicto, excepción y coste estimado. Una persona revisa una muestra y el total antes de aprobar. El estado inicial permanece intacto.

La idempotencia evita duplicación. Si el mismo evento se procesa dos veces, el resultado debe reconocer el identificador y no crear otra copia. Define qué hace el flujo ante una salida existente: detener, comparar o versionar; nunca sobrescribir automáticamente.

Los fallos parciales requieren estado por elemento. Algunos archivos pueden validar y otros fallar. No declares éxito global si falta una excepción. El log registra orden, resultado y motivo, sin credenciales ni contenido privado.

Rollback puede borrar solo salidas simuladas o mover copias temporales a cuarentena, pero preserva fuentes. En un sistema vivo cualquier limpieza material necesitaría autorización específica. Aquí se ensaya con tarjetas y fixtures.

Protocolo común de ensayo supervisado

Antes de aceptar el diseño, recórrelo con el fixture desde la entrada hasta la salida simulada. Lee cada dato en voz alta, confirma de dónde procede y señala qué transformación se propone. En cada rama pregunta qué ocurre si el dato falta, si aparece dos veces, si llega tarde o si contradice el brief. El objetivo no es hacer el mapa más complejo, sino demostrar que falla de forma visible.

Registra estado inicial, acción preparada, resultado observado y responsable de decidir. La aprobación humana ocurre inmediatamente antes de cualquier efecto material. Si nadie responde, el estado permanece pendiente: el silencio no concede permiso. Si el coste estimado o la privacidad cambian, vuelve al gate correspondiente. Conserva siempre una ruta manual que permita terminar el ejercicio sin plataforma.

Ensaya también la recuperación. Introduce una excepción, aplica rollback y comprueba que la fuente y el registro siguen disponibles. Repite el mismo evento para verificar que no duplica trabajo. Al cerrar, distingue claramente simulado, preparado, aprobado y realizado. Este vocabulario evita declarar una implementación que solo existe como diagrama y convierte la evidencia en una base honesta para la siguiente iteración.

Un detector produce candidatos

Una alerta no es un veredicto. Contiene candidato, tiempo, severidad, confianza y evidencia disponible. La persona escucha en contexto, consulta el brief y decide aceptar, rechazar o mantener incierto. Procesar automáticamente puede destruir un evento deliberado.

Severidad describe consecuencia, no certeza. Un posible archivo equivocado tiene alta severidad aunque el detector dude. Confianza describe soporte de la hipótesis. Mantener ambas dimensiones evita priorizar por una única puntuación.

El false positive ocurre cuando el sistema señala algo que no incumple el contrato. El true positive se confirma con evidencia. Lo incierto necesita otra fuente o revisión. El fixture contiene los tres resultados esperados para practicar sin audio privado.

La revisión manual usa una checklist estable: archivo, versión, inicio, final, silencios, clicks, picos, canales, formato, nombres y continuidad. La asistencia puede priorizar, pero la muestra manual revela fallos que el detector no busca.

El sign-off es humano. El agente o detector prepara un informe; no aprueba su resultado. No enviar automáticamente, no publicar automáticamente y no sobrescribir automáticamente siguen vigentes después del QC.

Protocolo común de ensayo supervisado

Antes de aceptar el diseño, recórrelo con el fixture desde la entrada hasta la salida simulada. Lee cada dato en voz alta, confirma de dónde procede y señala qué transformación se propone. En cada rama pregunta qué ocurre si el dato falta, si aparece dos veces, si llega tarde o si contradice el brief. El objetivo no es hacer el mapa más complejo, sino demostrar que falla de forma visible.

Registra estado inicial, acción preparada, resultado observado y responsable de decidir. La aprobación humana ocurre inmediatamente antes de cualquier efecto material. Si nadie responde, el estado permanece pendiente: el silencio no concede permiso. Si el coste estimado o la privacidad cambian, vuelve al gate correspondiente. Conserva siempre una ruta manual que permita terminar el ejercicio sin plataforma.

Ensaya también la recuperación. Introduce una excepción, aplica rollback y comprueba que la fuente y el registro siguen disponibles. Repite el mismo evento para verificar que no duplica trabajo. Al cerrar, distingue claramente simulado, preparado, aprobado y realizado. Este vocabulario evita declarar una implementación que solo existe como diagrama y convierte la evidencia en una base honesta para la siguiente iteración.

El diagrama es el sistema antes del sistema

Un trigger inicia el flujo; un filtro decide si el evento entra; una acción prepara una salida; una rama trata diferencias; retry gestiona fallos temporales; timeout evita espera infinita; el gate humano autoriza; el registro observa; rollback recupera.

La tarjeta debe poder leerse sin la interfaz de un proveedor. Usa nombres de capacidad y datos del fixture. n8n, Make o Zapier son ejemplos sensibles a versión; no hacen falta para completar el curso y sus pantallas no se convierten en contenido principal.

El trigger necesita idempotencia. Un mismo project ID no crea dos tarjetas. El filtro rechaza permiso ausente o estado no válido. La acción solo prepara un paquete local. El envío se sustituye por recibo simulado.

Retry se limita por número y causa. Repetir una validación que falla por dato ausente no ayuda; debe detenerse. Timeout devuelve estado pendiente y conserva contexto. Ninguna rama inventa aprobación por silencio.

La privacidad y el coste se revisan antes de conectar. Un nodo puede enviar más datos de los visibles. El ejercicio no usa conectores, claves ni paid actions. No publicar automáticamente es parte del diagrama.

Protocolo común de ensayo supervisado

Antes de aceptar el diseño, recórrelo con el fixture desde la entrada hasta la salida simulada. Lee cada dato en voz alta, confirma de dónde procede y señala qué transformación se propone. En cada rama pregunta qué ocurre si el dato falta, si aparece dos veces, si llega tarde o si contradice el brief. El objetivo no es hacer el mapa más complejo, sino demostrar que falla de forma visible.

Registra estado inicial, acción preparada, resultado observado y responsable de decidir. La aprobación humana ocurre inmediatamente antes de cualquier efecto material. Si nadie responde, el estado permanece pendiente: el silencio no concede permiso. Si el coste estimado o la privacidad cambian, vuelve al gate correspondiente. Conserva siempre una ruta manual que permita terminar el ejercicio sin plataforma.

Ensaya también la recuperación. Introduce una excepción, aplica rollback y comprueba que la fuente y el registro siguen disponibles. Repite el mismo evento para verificar que no duplica trabajo. Al cerrar, distingue claramente simulado, preparado, aprobado y realizado. Este vocabulario evita declarar una implementación que solo existe como diagrama y convierte la evidencia en una base honesta para la siguiente iteración.

Capacidad delimitada, no autonomía ilimitada

Un agente necesita objetivo concreto, contexto mínimo, tool allowlist, política de parada, coste máximo y evidencia de salida. Least privilege significa que solo puede leer o preparar lo necesario. No obtiene permiso para enviar, publicar, borrar, mover o aprobar por saber hacerlo.

El contexto puede quedar obsoleto. Cada dato importante lleva fuente y fecha. Antes de actuar, el agente verifica estado barato de comprobar. Si no puede, etiqueta incertidumbre y pide aprobación o se detiene. No presenta una inferencia como estado vivo.

Observabilidad responde qué intentó, qué herramienta usó, qué recibió, qué produjo y por qué paró. Una frase «hecho» sin recibo, archivo o estado verificable es hallucinated completion. El sistema falla cerrado: no inventa un ID ni repite silenciosamente una acción material.

Timeout no equivale a fracaso ni éxito. Conserva estado pendiente y permite reanudar sin duplicar. Permiso denegado confirma que el límite funciona. Datos obsoletos obligan a refrescar o detener. Cada condición tiene recovery definido.

El agente puede redactar, clasificar o preparar. La aprobación humana decide la acción material. Privacidad y coste forman parte de la entrada; si excede el techo, se detiene. No enviar automáticamente y no sobrescribir automáticamente son guardas mutacionadas en la suite.

Protocolo común de ensayo supervisado

Antes de aceptar el diseño, recórrelo con el fixture desde la entrada hasta la salida simulada. Lee cada dato en voz alta, confirma de dónde procede y señala qué transformación se propone. En cada rama pregunta qué ocurre si el dato falta, si aparece dos veces, si llega tarde o si contradice el brief. El objetivo no es hacer el mapa más complejo, sino demostrar que falla de forma visible.

Registra estado inicial, acción preparada, resultado observado y responsable de decidir. La aprobación humana ocurre inmediatamente antes de cualquier efecto material. Si nadie responde, el estado permanece pendiente: el silencio no concede permiso. Si el coste estimado o la privacidad cambian, vuelve al gate correspondiente. Conserva siempre una ruta manual que permita terminar el ejercicio sin plataforma.

Ensaya también la recuperación. Introduce una excepción, aplica rollback y comprueba que la fuente y el registro siguen disponibles. Repite el mismo evento para verificar que no duplica trabajo. Al cerrar, distingue claramente simulado, preparado, aprobado y realizado. Este vocabulario evita declarar una implementación que solo existe como diagrama y convierte la evidencia en una base honesta para la siguiente iteración.

La automatización debe ganarse su lugar

El proyecto final parte de una línea base: tiempo, espera, fallos y coste de recuperación. Elige un proceso acotado, repetitivo y de bajo riesgo. No uses entrega real, cliente privado ni material no autorizado. Reproduce la estructura con fixtures.

El mapa identifica tareas mecánicas, creativas y mixtas. Selecciona un paso asistido y una decisión deliberadamente manual. Por ejemplo, preparar un informe puede asistirse; aprobar el audio permanece humano. Explica por qué esa frontera protege intención.

Diseña gates de privacidad, coste, permiso y calidad. Añade input, output, excepción, log, idempotencia y rollback. No publicar automáticamente, no enviar automáticamente y no sobrescribir automáticamente deben aparecer textualmente.

El dry run precede cualquier materialización. Revisa muestra, conflictos y excepciones. Simula timeout, dato ausente y salida existente. Demuestra que el sistema vuelve a estado seguro y que una segunda ejecución no duplica.

Después del ensayo repite la medición. No cuentes el tiempo de desarrollo como cero ni conviertas una prueba en promesa. Decide conservar, simplificar o descartar. Un sistema que no ahorra tiempo pero mejora trazabilidad puede valer; uno que añade vigilancia constante puede no merecerse.

Protocolo común de ensayo supervisado

Antes de aceptar el diseño, recórrelo con el fixture desde la entrada hasta la salida simulada. Lee cada dato en voz alta, confirma de dónde procede y señala qué transformación se propone. En cada rama pregunta qué ocurre si el dato falta, si aparece dos veces, si llega tarde o si contradice el brief. El objetivo no es hacer el mapa más complejo, sino demostrar que falla de forma visible.

Registra estado inicial, acción preparada, resultado observado y responsable de decidir. La aprobación humana ocurre inmediatamente antes de cualquier efecto material. Si nadie responde, el estado permanece pendiente: el silencio no concede permiso. Si el coste estimado o la privacidad cambian, vuelve al gate correspondiente. Conserva siempre una ruta manual que permita terminar el ejercicio sin plataforma.

Ensaya también la recuperación. Introduce una excepción, aplica rollback y comprueba que la fuente y el registro siguen disponibles. Repite el mismo evento para verificar que no duplica trabajo. Al cerrar, distingue claramente simulado, preparado, aprobado y realizado. Este vocabulario evita declarar una implementación que solo existe como diagrama y convierte la evidencia en una base honesta para la siguiente iteración.