Objetivo
El operador tiene que poder convertir recordings en assets publicables sin empujar commits ciegos amain. El flujo correcto es siempre: draft, edición, validación, review branch, merge.
Flujo recomendado
Seleccioná moments que realmente sostengan una pieza
El draft no corrige falta de evidencia. Si los moments no explican el tema con claridad, volvé al workspace y curá mejor la base.
Generá el draft en la app
Elegí si la pieza es
playbook, guideline o content. Completá la metadata mínima (title, description, icon, assetType, sourceUrl) y usá el draft generado como punto de partida, no como versión final.Editá el MDX hasta cumplir el contrato
Revisá frontmatter, headings obligatorias, tono y precisión factual. La source of truth es el MDX final que vas a validar, no los campos auxiliares del formulario.
Corré “Validar draft”
El preflight verifica cuatro cosas:
- metadata obligatoria (
title,description,icon,assetType,sourceUrl) - headings requeridas por tipo
- ausencia de placeholders o URLs locales/dev en body y frontmatter
- path final y mutación esperada de
docs.json
Abrí la branch de review
La app crea una branch dedicada y devuelve el compare de GitHub. Ese compare es el review surface obligatorio antes del merge. Si no hay diff para inspeccionar, no hay publish seguro.
No hacer
Qué queda fuera de este flujo
- Auth del operador: se resuelve en
DAN-7. - Sincronización automática del merge de vuelta a la app: hoy el operador mergea en GitHub y la app guarda la URL pública planeada desde que existe la branch de review.