lade-factory

Golden path automation: un solo workflow (scaffold.yml) que clona un template de lade-templates, lo inicializa, crea el repo en lade-group, bootstrapea su backend de Terraform y configura environments + branch protection. Se puede disparar desde la UI de GitHub Actions o desde lade-admin-panel (sección Golden Paths).

Requisitos (org lade-group)

Secret/variable	Tipo	Para qué	Estado
FACTORY_GH_TOKEN	Org secret, visibilidad selected → solo lade-factory	gh repo create en la org + push de .github/workflows/*.yml (el GITHUB_TOKEN por defecto no puede crear repos)	✅ configurado
AWS_ROLE_ARN_DEV	Org variable	OIDC para bootstrapear el bucket S3 de state de cada repo nuevo	✅ ya existe (shared-aws-bootstrap)
CLOUDFLARE_ACCOUNT_ID / CLOUDFLARE_ZONE_ID	Org variables	Pasados a init.sh cuando el template es astro-cloudflare-template	✅ ya existen

Crear FACTORY_GH_TOKEN

1. GitHub → Settings → Developer settings → Personal access tokens (classic).
2. Scopes: repo (completo) + admin:org (crear repos en lade-group y gestionar environments/variables) + workflow (obligatorio: sin este scope, git push rechaza cualquier archivo .github/workflows/*.yml — y todos los templates traen workflows — con el error refusing to allow a Personal Access Token to create or update workflow ... without workflow scope). Los 3 scopes se pueden marcar en el mismo token o agregarse después editándolo (el valor del token no cambia al editar scopes).
3. Expiración: la que prefieras (recomendado 90 días + rotar).
4. gh secret set FACTORY_GH_TOKEN --org lade-group --visibility selected --repos lade-factory --body <token>

Es un PAT personal — deuda técnica conocida y aceptada para el MVP. Ver la historia F7.4 en Notion (Lade HQ) para el reemplazo por una GitHub App.

Uso manual (sin el panel)

GitHub → Actions → Scaffold → Run workflow. Completá template, project_name, flavor (solo aplica a astro-cloudflare-template) y ticket_prefix. Dejá run_key vacío (es para la correlación desde el panel) y reconfigure_only en false.

Qué hace exactamente

1. scripts/scaffold.sh (job scaffold, corre con environment: dev para tener OIDC de AWS): clona el template, corre su init.sh con los flags correspondientes (astro-cloudflare-template recibe además --cloudflare-account-id/--cloudflare-zone-id), corre create-app.sh si el template lo soporta de forma no interactiva (solo astro-cloudflare-template — vite-cloudfront-template tiene un create-app.sh interactivo, npm create vite@latest, que no se automatiza a propósito: elegir framework es una decisión humana), crea el repo en lade-group con gh repo create --private --push, y bootstrapea el backend de Terraform (make tf-bootstrap-apply + gh variable set TF_STATE_BUCKET).
2. scripts/configure-repo.sh (job configure, siempre corre después —también solo si reconfigure_only=true, sin repetir el clone/push): setea TICKET_PREFIX, crea los 3 GitHub Environments (dev sin restricciones; qa/prod con el actor que disparó el run como reviewer obligatorio y branch policy restringida a tags v*.*.*), y aplica branch protection básica en main (1 review, sin force-push). Todo con gh api — idempotente, se puede re-correr.
3. Resumen en $GITHUB_STEP_SUMMARY con la URL del repo y los próximos pasos manuales.

Limitaciones conocidas (MVP)

• No se automatiza “Require status checks to pass” en branch protection (los nombres de checks solo existen después del primer PR real).
• vite-cloudfront-template necesita create-app.sh a mano después del scaffold (es interactivo por diseño).
• Auth vía PAT personal, no GitHub App (F7.4 en el backlog).