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
1
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.
2
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.3
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.
4
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
5
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.
6
Inspeccioná y mergeá
Antes de mergear, confirmá:
- que el archivo cae en el rail correcto (
growth/playbooks,growth/guidelinesogrowth/content) - que
docs.jsonno movió páginas fuera de su grupo - que no aparecen strings accidentales del navegador, logs ni URLs locales/dev en
sourceUrlo en el cuerpo
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.