Irnist/website-pipeline

Website pipeline

Ejecutas un sitio web de cliente desde la entrada en bruto hasta una vista previa desplegada con la menor intervención posible del usuario. Primero, cada ejecución (nueva, reanudada o una fase única): Lee <pipeline>/RULES.md, las reglas del sitio web, a menos que esta sesión ya lo haya hecho. Se aplican a cada paso. Las herramientas en tools/ aplican la mayoría de ellas mecánicamente, así que ejecútalas en lugar de volver a verificar manualmente.

Espacio de trabajo

Todo vive en un espacio de trabajo, C:\Users\Administrator\Desktop\Claude Workspace (<workspace>). Las rutas a continuación son relativas a él; en los scripts, derívalas de la ubicación del propio script (Path(__file__)), nunca una ruta fija del Escritorio.

Qué	Dónde
Pipeline (<pipeline>)	Workflow and Pipeline/website-pipeline/ (~/.claude/skills/website es un enlace simbólico a él)
Herramientas compartidas	<pipeline>/tools/: la única copia de qa.py, browser_qa.mjs, deploy.py… El tools/ de cada sitio tiene stubs que lo ejecutan en ese sitio (L-052), por lo que una corrección o nueva verificación llega a todos los sitios a la vez. Los scripts específicos del sitio se sitúan junto a los stubs.
Sitios de muestra	Concept Websites/<Nombre> Website/
Portafolio del propietario	Portfolio Site/
Capturas de pantalla del portafolio	Portfolio Screenshots/: solo capturas de sitios terminados, nada más
Archivos temporales (scripts de prueba, capturas de prueba, copias de seguridad, defectos plantados)	_temp/, nunca la carpeta temporal del sistema, un proyecto o la plantilla

0. ¿Dónde estoy?

Decide el punto de entrada según el estado de la carpeta y los argumentos:

Estado	Acción
Sin _src/build.py en el directorio actual	Andamiaje: powershell -NoProfile -ExecutionPolicy Bypass -File "<pipeline>/scaffold.ps1" -Target "<cwd>" -NoLaunch, luego ve a Recepción. Si el directorio actual contiene archivos no relacionados, detente y pregunta (esta es una pregunta crítica).
PROJECT.md tiene todas las fases marcadas (un sitio terminado reabierto con el mismo nombre) y los argumentos están vacíos o son de recepción de nuevo sitio, no un argumento de fase o una solicitud de cambio	Pregunta primero, antes de ejecutar o cambiar algo (el usuario, 2026-10-10, L-057). Usa una AskUserQuestion: " ya está terminado (vista previa ). ¿Rediseñarlo?" con No, déjalo y Sí, rediseñarlo. No: detente y no hagas nada, ni siquiera una sincronización de herramientas, QA o despliegue. Sí: comienza exactamente como un sitio nuevo; nunca rediseñes por tu cuenta desde el brief anterior (L-058). (1) Confirma cualquier cambio suelto y etiqueta la versión anterior: git tag previous-<fecha>. Luego mueve todo excepto client-assets/ y .git/ a <workspace>/_temp/<Nombre>-previous-<fecha>/ (un archivo, nunca una eliminación), incluyendo el antiguo BRIEF.md. La etiqueta mantiene el sitio anterior restaurable después de limpiar _temp. (2) Vuelve a andamiar, copia el BRIEF.md en blanco de la plantilla y establece su línea Business name:. (3) Abre el formulario de brief, python "<pipeline>/brief-form/brief_form.py" "<project>", como comando en segundo plano, dile al usuario que la ventana está abierta y espera. No hagas trabajo de dirección, aprendizaje de bibliotecas, búsqueda de existencias o diseño mientras tanto. (4) Salida 0 ("Comenzar a construir"): ejecuta el proceso normal de nuevo sitio desde Recepción en el nuevo brief. Salida 3 (cerrado): detente y di que el brief está guardado. En la entrega, reemplaza la entrada de la biblioteca de diseño del sitio en lugar de agregar una segunda.
PROJECT.md tiene fases sin marcar	Reanuda en la primera fase sin marcar. Di una línea sobre dónde estás reanudando.
Reanudando o cambiando cualquier proyecto existente	Las herramientas no necesitan sincronización: tools/ tiene stubs para las herramientas compartidas. Si el sitio no tiene .git/, ejecuta git init -b main, git config core.autocrlf false, copia el .gitignore de la plantilla y confirma una línea base primero. Si qa.py advierte sobre copias completas de herramientas compartidas (un sitio anterior al 2026-10-13), ejecuta python "<pipeline>/dev/use_shared_tools.py" "<project>" y confirma. También incorpora las características de la plantilla que la solicitud necesita (por ejemplo, GSAP: h_gsap en build.py, {{fn:gsap}}, tools/vendor/, motion.js).
Argumento status	Imprime la lista de verificación de fases más los placeholders abiertos. No hagas nada más.
Argumento learn	Aprende las imágenes de diseño y los archivos DESIGN.md colocados en <pipeline>/design-library/inspiration/: sigue design-library/LEARN.md, luego informa una línea por referencia. No hagas nada más.
Argumento qa / deploy / handoff	Ejecuta solo esa fase.

Los argumentos de texto libre son material de recepción (nombre comercial, teléfono, enlaces, notas). Trátalos igual que BRIEF.md.

Modo: muestra o cliente

BRIEF.md › Project type establece el modo. Por defecto es muestra, lo que significa una pieza de portafolio. Una instrucción explícita en los argumentos prevalece.

	muestra (portafolio)	cliente (negocio real)
Datos faltantes	Cuando el brief es escaso, inventa un negocio ficticio plausible y consistente: nombre, historia, servicios, horarios. Usa números de teléfono 555-01xx y correos electrónicos example.com para que nada llegue a una persona real.	Nunca inventes. Usa placeholders y data-todo.
Reseñas, estadísticas, credenciales	Está bien para un negocio ficticio; enuméralos como ficticios en la entrega. Si la muestra usa un negocio real, usa solo hechos públicos reales: sin reseñas, afirmaciones o precios inventados sobre personas o empresas reales.	Solo lo que el cliente proporciona.
Preguntas	Casi ninguna: solo eliminar archivos, gastar dinero, contactar el mundo real (bandejas de entrada reales, números de teléfono reales), y críticas de diseño críticas (#5).	La política completa de preguntas a continuación.
Formularios	El modo demo está bien.	Se necesita un endpoint real; pregunta si falta.
Despliegue	Vista previa no indexada	Vista previa no indexada; producción solo bajo solicitud
Entrega adicional	Captura de pantalla del portafolio (ver Entrega)	Lista de placeholders escrita para el cliente

Reglas operativas

• Piloto automático. Avanza de fase a fase sin preguntar "¿debo continuar?". Después de cada fase, márcala en PROJECT.md › Estado. Eso hace que la ejecución sea reanudable después de la compactación o una nueva sesión.
• Git (cada sitio y el pipeline son repositorios). Confirma en el sitio después de cada fase marcada (<Fase>: <lo que se hizo>) y después de cada ronda de cambios solicitados, para que cualquier estado pueda compararse o restaurarse. Confirma los cambios del pipeline (herramientas compartidas, plantilla, SKILL.md, LESSONS.md, biblioteca de diseño) en el repositorio del pipeline, con el ID de la lección en el mensaje cuando la haya. dist/, qa/ y los cachés están en gitignore. Nunca reescribas el historial, fuerces nada o subas; no hay remoto.
• Las preguntas siguen la política a continuación. Todo lo demás es una decisión: tómala, agrega una línea a PROJECT.md › Decisiones (qué + por qué) y sigue adelante.
• Modo cliente: nunca fabriques datos del cliente. Esto cubre testimonios, recuentos de reseñas, años en el negocio, licencias, certificaciones, precios, garantías, premios y nombres de equipo. Si el material no está en las entradas, escribe la copia para que no necesite el dato. Si es realmente necesario, marca el elemento con data-todo="lo que se necesita" para que QA lo enumere para la entrega. El modo muestra sigue la tabla de Modo.
• Registra cada error en el momento en que ocurre en PROJECT.md › Errores. No esperes a la entrega; el contexto puede compactarse antes. Un error es cualquier cosa que el usuario corrige, cualquier error de primer borrador que QA, una crítica o el revisor señala (registra una entrada por tipo, no por instancia), y cualquier suposición incorrecta o herramienta mal utilizada. Cada entrada registra qué pasó, quién lo detectó, la causa raíz, la corrección y cómo prevenirlo.
• Fuente de la verdad: edita _src/ (páginas, parciales, site_config.py) y assets/, luego ejecuta python _src/build.py. Nunca edites dist/.
• Ediciones con script (L-027): los cambios individuales usan Editar. Varias sustituciones a la vez van en un script Python escrito con Escribir (en <workspace>/_temp), nunca un heredoc de shell. El script termina a menos que cada recuento de coincidencias sea exactamente 1, y verifica cada archivo antes de escribir cualquiera de ellos. Después, py_compile cualquier .py editado y reconstruye.
• Higiene del contexto: ejecuta herramientas y lee sus informes (qa/*.md), no la salida sin procesar. Consulta informes largos, registros y listados a través del modo de contexto (ctx_execute_file / ctx_batch_execute con una pregunta como "solo errores y advertencias") en lugar de leerlos completos. Mira las capturas de pantalla con la herramienta Leer. Nunca vuelques archivos HTML completos en la conversación.

Política de preguntas (solo asuntos críticos)

Pregunta solo cuando uno de estos sea verdadero. Esto es en modo cliente; en modo muestra solo se aplican #2 y #5, y una vista previa no indexada nunca necesita preguntar.

1. Identidad incognoscible. No puedes determinar a partir de ninguna entrada o fuente pública qué hace el negocio, dónde está o a quién sirve. Una suposición incorrecta significaría reescribir el sitio.
2. Hacia afuera o irreversible. Despliegues de producción, dominios personalizados, conectar un formulario a una bandeja de entrada real, cualquier cosa que gaste dinero, eliminar archivos de usuario. Un despliegue de vista previa no indexada está preautorizado cuando BRIEF.md dice Deploy preview: yes.
3. Afirmaciones legales o fácticas que el sitio haría y que solo el cliente puede confirmar (licencias, precios, garantías). Por defecto, déjalas fuera. Pregunta solo si el brief las hace centrales.
4. Instrucciones conflictivas entre el brief, los mensajes del usuario, RULES.md y CLAUDE.md, donde ambas lecturas sean plausibles.
5. Crítica de diseño crítica. Una crítica impecable o el revisor final informa un problema P0 (Bloqueante) o P1 (Mayor). Sigue la puerta de críticas a continuación. Esta es la única pregunta permitida durante la construcción.

Cómo preguntar:

• Un lote, al final de la Recepción. Usa una sola AskUserQuestion con 1 a 4 preguntas. Pon la respuesta recomendada primero, marcada "(Recomendado)". Nunca preguntes durante la construcción, excepto en la puerta de críticas (#5). Si surge un bloqueador más tarde, usa un placeholder claramente marcado, regístralo bajo Preguntas diferidas y sácalo en la entrega.
• Nunca preguntes sobre: paleta, fuentes, diseño, tono de la copia, lista de páginas, qué fotos de stock, orden de secciones, pila tecnológica, nombres de archivos, o si arreglar un hallazgo de QA. Decide esas cosas. La única excepción es un hallazgo de crítica P0/P1 (#5).
• Si nada es crítico, no preguntes nada. Di "Sin preguntas bloqueantes; procediendo" y continúa.

Puerta de críticas (hallazgos impeccables)

Usa la escala de gravedad de impeccable (P0 Bloqueante, P1 Mayor, P2 Menor, P3 Retoque). Clasifica cada elemento del revisor de hallazgos en la misma escala.

• P2/P3 (menor): no los arregles; continúa. Registra una línea por hallazgo en PROJECT.md › Decisiones: "omitido: menor (P2/P3), ".
• P0/P1 (crítico): detente y pregunta antes de cambiar cualquier cosa. Usa un lote de AskUserQuestion con hasta 4 preguntas. Escribe una pregunta por hallazgo, o agrupa por clase si hay más de 4. Cada pregunta dice qué está mal y dónde (página, sección, archivo de captura de pantalla). Ofrece 2-3 opciones de corrección concretas, con la recomendada primero y marcada "(Recomendado)", más "Dejar como está". Luego aplica la elección del usuario a toda la clase en todo el sitio (L-016), reconstruye y registra la elección en Decisiones.
• Revisión: vuelve a ejecutar la misma crítica una vez después de aplicar las elecciones. Cualquier nuevo P0/P1 pasa nuevamente por la puerta; los hallazgos menores se omiten como arriba.
• No forma parte de la puerta: violaciones objetivas de reglas que qa.py, browser_qa.mjs, LESSONS.md o RULES.md ya prohíben, como contraste por debajo de 4.5:1, desbordamiento, una foto repetida, un resplandor que reduce el contraste del texto sobre él por debajo del nivel (los resplandores están permitidos), un sujeto recortado o un select prellenado con un valor predeterminado. Arregla esos automáticamente, cualquiera que sea la gravedad que la crítica les dé, porque son defectos, no decisiones de diseño. Los indicadores de impeccable detect cuentan como menores a menos que cumplan una de estas reglas. Anota los falsos positivos conocidos (L-000) como antes.

Fases

1 · Recepción

0. Lee <pipeline>/LESSONS-INDEX.md (una línea por lección, generada a partir de LESSONS.md). Cada lección se aplica desde el primer borrador. Abre la entrada completa de LESSONS.md para cada una que sea relevante para este proyecto y enumera sus IDs, cada una con unas pocas palabras, en PROJECT.md › Errores › "Vigilar". Enumera IDs, nunca texto de lección copiado: las copias se vuelven obsoletas cuando una lección es reemplazada (Trevor Travis y Gadget Zone mantuvieron "sin resplandores" después de que los resplandores fueran permitidos).
1. Lee BRIEF.md, los argumentos y todo en client-assets/. Abre cada foto con Leer y cataloga en PROJECT.md › Activos. Registra el sujeto, su calidad, cualquier problema (platos, logotipos, desorden, recorte) y el mejor lugar para ella (hero/característica/galería/saltar). Las marcas de terceros en una imagen (tableros, señalización, renders) se leen como respaldos: márcala como "recortar antes de usar" o saltar (L-028). Nota qué fotos provienen de la misma sesión o muestran la misma vista (L-029).
2. Si se dieron enlaces (sitio existente, Perfil de Negocio de Google, Facebook), recupéralos y extrae datos: servicios, área de servicio, horarios, historia, propietario, años, proyectos reales. Cita la fuente junto a cada dato en PROJECT.md › Datos.
   • Guarda los pies de foto, reseñas y citas del propietario textualmente en un archivo de fuentes (por ejemplo, client-assets/sources.md). Copia las citas desde él; nunca reescribas ni parafrasees una de memoria (L-007).
   • Registra la línea de crédito de cada proyecto (diseñado por / construido por / año) en Datos. Un proyecto que el negocio solo construyó nunca es "diseñado por" él.
3. Optimiza las fotos del cliente: python tools/optimize_images.py (client-assets → assets/img/client/, rotadas EXIF, máximo 2000px).
4. Llena _src/site_config.py: BIZ, HOURS, SERVICES, PRIMARY_CTA, PAGES, FORM_ENDPOINT, SEO. Los valores de contacto desconocidos permanecen como "". La construcción los deja como placeholders visibles {{TOKEN}} y QA los informa.
   • Formulario de contacto. Copia Form endpoint: del brief en FORM_ENDPOINT: en blanco = modo demo; netlify = Formularios de Netlify (solo con Deploy host: netlify; qa.py da error de lo contrario); web3forms:<clave de acceso> = Web3Forms en cualquier host (el propietario de la bandeja de entrada crea la clave en web3forms.com); o una URL estilo Formspree. {{fn:form_fields}} agrega los campos ocultos correspondientes y la trampa de spam. Nunca elijas o conectes una bandeja de entrada real tú mismo: un brief en blanco se queda en modo demo y va a la lista de entrega. En modo cliente, qué bandeja de entrada recibe los mensajes es una pregunta. Copia Online booking link: en BOOKING_URL; {{fn:booking}} lo muestra en la página de contacto junto al botón de llamada.
   • Animación GSAP. Opcional, desactivada por defecto. Solo cuando el brief dice GSAP motion: yes. Si se establece en yes, pon GSAP: enable en site_config.py, activa h_gsap en build.py, y usa {{fn:gsap}}, tools/vendor/gsap.min.js y motion.js de la plantilla.
   • Mapas. {{fn:map}} inserta un mapa; la dirección real puede ser un placeholder.
   • Blog. Solo cuando el brief lo especifica; usa PAGES: [..., {..., 'blog': true}].
5. Si hay un archivo _src/site_config.py de una ejecución anterior, compáralo con los activos y el brief actuales y actualiza cualquier cosa que haya cambiado.
6. En modo muestra sin activos del cliente, genera un activo de marca: python tools/generate_brand_asset.py "/<nombre-de-la-muestra>" (ejecútalo en el directorio del proyecto) y pon la imagen generada como fondo, tarjeta o elemento hero.
7. Crea PROJECT.md si no existe: copia de...

(Omitido por brevedad; la traducción continúa con la misma estructura y reglas.)