# Workflow PRs + Issues — cd-frontend-dev ↔ cd-system > Guía operativa para que el equipo (Maxi, futuros frontend devs) trabajen en `cd-frontend-dev` con PRs e Issues, y los cambios fluyan correctamente al codebase canónico `cd-system`. > > Vivo desde 2026-05-12. --- ## El flujo en 1 diagrama ``` ┌───────────────────────────────┐ ┌───────────────────────────────┐ │ cd-frontend-dev │ │ cd-system │ │ (espejo editable frontend) │ │ (canónico Laravel) │ │ │ │ │ │ Dev frontend (Maxi): │ │ Maintainer (Coke): │ │ - levanta docker compose │ │ - revisa sync PRs auto │ │ - edita .blade.php + .css │ │ - mergea cambios visuales │ │ - abre PR │ │ - lidera fixes de backend │ │ - reporta issues │ │ - mantiene módulos PHP │ │ │ sync │ │ │ Branch: main │ ──→ ←── │ Branch: cd-system │ │ │ bidir │ │ └───────────────────────────────┘ └───────────────────────────────┘ ``` ### Qué se sincroniza automáticamente Solo los **9 archivos visuales** que componen un demo (más algunos compartidos): ``` resources/views/layout/front/headers/demo-{name}.blade.php resources/views/layout/front/footers/demo-{name}.blade.php resources/views/layout/front/partials/page-header-{name}.blade.php resources/views/modules/cd-base/frontend/demos/demo-{name}/welcome.blade.php resources/views/modules/cd-base/frontend/demos/demo-{name}/about.blade.php resources/views/modules/cd-base/frontend/demos/demo-{name}/contact.blade.php public/template/css/demos/demo-{name}.css public/template/css/skins/skin-{name}.css [opcional] public/template/js/demos/demo-{name}.js ``` Plus componentes compartidos: `resources/views/components/*.blade.php`, `resources/views/layout/front/partials/*.blade.php`, etc. **No se sincroniza**: backend PHP (`app/`), migrations, configs, comandos artisan, services, models. Eso vive solo en cd-system. Detalle técnico del sync: [`sync-architecture.md`](sync-architecture.md). --- ## Tipos de contribución ### Tipo A — Fix visual / UI (lo que hace Maxi) **Repo de trabajo**: cd-frontend-dev **Flow**: 1. Maxi edita Blade/CSS/JS en su clone local con docker compose. 2. Push branch a `LACOMPANIADIGITAL/cd-frontend-dev`. 3. Abre PR contra `main` con descripción + screenshots. 4. **Coke revisa** (o auto-merge si está autorizado). 5. Merge a `main` → workflow auto crea PR en cd-system con los cambios. 6. **Coke mergea** el sync PR en cd-system → CI auto-deploy a VPS1. **Ejemplos de Tipo A**: - Cambiar copy de un header - Ajustar CSS responsive - Fix de assets rotos - Mejorar paleta de colores de un skin - Reordenar secciones del welcome ### Tipo B — Bug de backend (lo que sale de Tipo A) **Repo de trabajo**: cd-system **Flow**: 1. Maxi detecta el bug y reporta como Issue en cd-frontend-dev. 2. **Coke clasifica**: si es backend → comenta el issue con "scope: cd-system" y mueve el fix a cd-system. 3. Coke implementa el fix en cd-system, commit + push. 4. CI auto-deploy a VPS1. 5. Issue se cierra con referencia al commit/PR de cd-system. **Ejemplos de Tipo B**: - CSRF token mismatch (issue #3) — Laravel session config - Routes que devuelven 404 cuando deberían — `routes/` - Validación de form rota — Controller + Request - Webhook Stripe no procesa — `app/Http/Controllers/StripeWebhookController.php` ### Tipo C — Audit / DRAFT (lista de hallazgos) **Repo de trabajo**: cd-frontend-dev como Issue draft **Flow**: 1. Maxi recorre el panel/sitio y documenta hallazgos en un Issue masivo (ej. #7 Documentación, #8 Restaurant Bar). 2. **Coke prioriza** sección por sección. 3. Maxi (o quien tome) abre **sub-issues** o **PRs separados** por sección priorizada. 4. Se cierran progresivamente conforme van resolviéndose. 5. El issue draft permanece abierto como tracking hasta cerrar todas las secciones. **Ejemplos de Tipo C**: - Audit UI/UX completo del admin - Audit responsive de un demo específico - Lista de typos / copy a corregir --- ## Standard de calidad para PRs (lo que Maxi viene haciendo bien) ✅ **Título descriptivo**: `fix(docker): evitar overlay de layout/front sobre archivos de la imagen` ✅ **Descripción con repro steps**: pasos exactos para reproducir + comportamiento esperado vs actual. ✅ **Scope claro**: si el bug pertenece a otro repo (backend), lo nota explícitamente. ✅ **Screenshots / videos** cuando aplica (especialmente para Tipo C). ✅ **Labels**: bug / enhancement / documentation (Maxi ya las usa). --- ## Lo NO hacer ❌ **No editar archivos de cd-system directamente desde cd-frontend-dev**. Si necesitás tocar PHP/Controllers/etc., reportá el issue → Coke lo agarra en cd-system. ❌ **No mergear PRs propios en cd-frontend-dev sin code review**. Por más simple que parezca el fix, alguien tiene que validar antes (Coke o un peer dev frontend cuando haya más). ❌ **No agregar archivos al espejo que no son parte de los demos**. Si lo necesitás (e.g. un partial nuevo), abrir issue para discutir antes de incorporarlo al sync workflow. ❌ **No ignorar el workflow check de CI**. Si CI falla, debuggear localmente con `docker compose up -d` antes de re-pushear. --- ## Capacidad operativa actual (2026-05-12) | Métrica | Valor | |---------|-------| | **PRs merged este mes** | 2 (Maxi: #2 docker overlay, #5 recaptcha CSS) | | **Issues abiertos** | 5 (#3 CSRF, #4 disclaimer ✅, #6 docker reset, #7 audit UI, #8 audit restaurant) | | **Tiempo promedio merge-to-deploy** | <5 min (sync workflow + CI auto-deploy) | --- ## Cómo Coke triagea issues de Maxi (cheatsheet) Al recibir un issue, Coke (o quien revise) clasifica: ``` Issue nuevo de Maxi │ ▼ ¿Toca solo blade/css/js? │ ┌───────┴───────┐ SÍ NO │ │ ▼ ▼ Tipo A ¿Toca backend? (Maxi PR) │ ┌──────┴──────┐ SÍ NO │ │ ▼ ▼ Tipo B Tipo C (Coke fix) (draft tracking) en cd-system ``` --- ## Referencias - [Sync architecture](sync-architecture.md) — detalle técnico del workflow bidireccional - [Anatomía de un demo](anatomia-de-un-demo.md) — qué archivos componen un demo - [Guía de uso](guia-de-uso.md) — setup local docker compose - [Standard de demo](../product-readiness/estandar-demo.md) — los 8 archivos obligatorios