zhaoqqiu299/portfolio-3d-interactivo

Portafolio 3D interactivo

Ayuda a una persona a construir un portafolio que la gente explore como una habitación: una pizarra para "Acerca de", un portátil para "Proyectos", una estantería para "Habilidades", un buzón para "Contacto". La persona normalmente no sabe programar. Tú construyes; ellos miran, juzgan y redirigen. La mayor parte de la calidad proviene de muchas rondas cortas de su retroalimentación, así que haz cada ronda rápida y visible.

El proceso tiene 13 etapas en 4 fases. Hazlas en orden la primera vez; las solicitudes posteriores suelen caer en una etapa (casi siempre la Etapa 8).

Fase	Etapas	Leer
Planificar y construir	1 Planificar · 2 Primer prompt · 3 Imagen de referencia · 4 Construcción 3D · 5 Interacciones prestadas	references/build-patterns.md
Llenar	6 Contenido y notas de diseño · 7 Archivos de Google	references/content-and-docs.md
Pulir	8 Iterar · 9 Probar	este archivo, luego scripts/screenshot_site.js
Lanzar y proteger	10 Desplegar · 11 Dominio · 12 Actualizar automáticamente GitHub · 13 Proteger	references/launch-and-protect.md

Trabajar con la persona

• Espera solicitudes en lenguaje sencillo, en cualquier idioma. "Los libros planos parecen tablones largos" es una indicación completa. Tradúcela al cambio tú mismo. Responde en el idioma de la persona; mantén el texto del sitio en el idioma del sitio.
• Maneja las solicitudes numeradas una por una e informa con los mismos números, para que nada se omita silenciosamente.
• Muestra, no describas. Después de un cambio visual, toma una captura de pantalla y mírala antes de decir que está hecho. Envía a la persona la captura de pantalla cuando el cambio sea sobre diseño o apariencia. El WebGL de software es lento, así que da a las capturas de pantalla tiempos de espera generosos (ver Etapa 9).
• Explica las compensaciones brevemente y recomienda una opción cuando haya una elección real ("Testimonios" vs "Testimonio": recomienda la primera y explica por qué en una oración). No hagas preguntas que puedas responder desde el contexto.
• Cuando la persona no sepa qué significa una palabra (DNS, commit, repositorio), explícala en una línea y luego continúa.

Honestidad y cuidado

Un portafolio es leído por personas que deciden si contratar a alguien, así que debe ser verdadero.

• No añadas habilidades, herramientas, resultados, pruebas o colaboradores que la persona no haya confirmado. Si te piden que incluyas herramientas que no usaron ("finge que sé Blender"), di claramente que un entrevistador podría preguntar al respecto, ofrece el marco verdadero y a menudo más sólido (por ejemplo, "cada objeto modelado en código"), y sugiere listar habilidades reales en una sección de Habilidades.
• Cuando escribas justificaciones de diseño, fundamenta cada afirmación en lo que el artefacto realmente hace. El uso planificado va bajo un encabezado como "Cómo lo usaría en clase", nunca como algo que sucedió.
• Señala cualquier oración que hayas inferido en lugar de que te hayan dicho, y pide a la persona que la verifique.
• Protege a los estudiantes: elimina nombres, identificaciones, calificaciones y comentarios privados; difumina los rostros (incluidas las personas de fondo) antes de publicar fotos; mantén los datos de investigación y el código privados a menos que un supervisor lo apruebe. Ver Etapa 13.

Etapa 1 · Planificar antes de dar el prompt

Acuerda tres cosas antes de construir: la audiencia y su objetivo (por ejemplo, "equipos de contratación para pasantías de diseño de aprendizaje, de 3 a 5 minutos por candidato"), la lista de secciones, y un mapa de la sala donde la función cotidiana de cada objeto coincida con su sección. Si un objeto y su significado no coinciden, cambia el objeto (una maleta sugiere irse; un buzón sugiere escribir). Cada sección también debe ser accesible desde un menú simple.

Etapas 2 a 5 · Construir la sala

Lee references/build-patterns.md antes de escribir la escena. Arquitectura predeterminada:

• Un index.html con Three.js cargado desde una versión CDN fija mediante un mapa de importación, cada objeto modelado en código a partir de primitivas (sin archivos de modelo), texturas generadas con canvas, y un menú en la parte superior izquierda.
• El contenido que cambia a menudo (carpetas de proyectos, elementos de la galería) vive en pequeños archivos JSON junto a index.html, para que la persona pueda agregar un proyecto o foto sin tocar el código 3D.
• Si la persona trae una imagen de referencia (Etapa 3), primero iguala su diseño, paleta y luz; los detalles de estilo vienen después. Si traen una interacción de ejemplo (React Bits, Codrops), construye una versión original con el estilo del sitio y no copies código con licencia.

Lista de verificación de la primera construcción: cada sección tiene un objeto que brilla al pasar el cursor con una etiqueta; un clic mueve la cámara allí y abre la sección; el menú funciona sin la sala 3D; carga en unos 5 segundos; funciona en ancho de teléfono.

Etapa 6 y 7 · Llenar con trabajo real

Lee references/content-and-docs.md. En resumen: pide material real (CV, texto de LinkedIn, archivos de proyectos), redacta a partir de eso, y deja que la persona lo corrija. Pon los artefactos reales primero y el razonamiento a su lado como notas de diseño numeradas que nombren la decisión y la teoría de aprendizaje detrás de ella. Elimina fechas obsoletas a menos que importen. Para enlaces de Google, verifica que el uso compartido sea "Cualquiera con el enlace, Lector"; si un archivo necesita inicio de sesión universitario, alójalo en el sitio en su lugar.

Etapa 8 · Iterar

Aquí es donde ocurre la mayor parte del trabajo. Reglas aprendidas de rondas reales:

• Una única señal para "cliqueable". Todo lo cliqueable brilla al pasar el cursor; nada decorativo brilla o parece cliqueable. Elimina señales falsas (papeles brillantes, fórmulas flotantes, notas adhesivas sueltas).
• Señaliza interacciones ocultas. Si los visitantes pueden dibujar en una pizarra, convierte el puntero en tiza sobre ella, coloca las herramientas justo debajo y déjalas brillar hasta el primer uso. Si una galería se desplaza, muestra una pequeña leyenda (teclas de flecha, rueda, deslizamiento con dos dedos, arrastre en táctil). Cuando una sección esté abierta, haz que el siguiente elemento cliqueable brille suavemente (un contorno pulsante) para que la gente lo note.
• Mantén los objetos interactivos cerca de donde la gente mira. Cuando un panel se abre a la derecha, coloca los objetos con los que se puede interactuar en el lado derecho de la escena.
• Proporciones reales. Los libros, tazas y muebles a escala real se ven bien; las formas estiradas se ven mal de inmediato.
• Sonido solo después de un clic (los navegadores bloquean la reproducción automática): un botón "Entrar" que inicie la música, más una opción silenciosa.
• Ordena el contenido según la historia. En los testimonios, las palabras (cartas, notas, mensajes) antes que las fotos; el elemento más personal primero.
• Nombra las secciones de manera simple. Una etiqueta de menú debe decir lo que hay dentro ("Investigación", no "Siguiente capítulo").
• Verifica qué bloquea los clics. Los objetos Line y LineSegments de Three.js atrapan rayos desde aproximadamente un metro por defecto; establece obj.raycast = () => {} en las mallas decorativas, o los clics cerca de ellas irán al objeto equivocado.

Después de cada ronda, captura las vistas cambiadas, corrige lo que esté visiblemente mal una vez, e informa qué cambió en palabras simples.

Etapa 9 · Probar

Ejecuta scripts/screenshot_site.js <directorio_del_sitio> <directorio_de_salida> acerca proyectos contacto (los ids de las secciones son los valores data-go de los botones del menú) para capturar vistas de escritorio y teléfono e imprimir errores de página. Luego guía a la persona a través de las comprobaciones manuales: cada objeto y elemento del menú se abre, cada enlace funciona en una ventana privada, el formulario de contacto llega (FormSubmit necesita un correo de activación único), el sonido apagado sigue funcionando, la navegación solo con teclado funciona, y un amigo visita sin ayuda.

Etapas 10 a 13 · Lanzar y proteger

Lee references/launch-and-protect.md. Cubre el despliegue con GitHub más Vercel (la página principal debe ser index.html en el nivel superior; el sitio web de GitHub sube un máximo de 100 archivos a la vez), dominios personalizados, envío de cambios a través de la Claude GitHub App, y protección: un repositorio privado, assets/robots.txt y assets/vercel.json para rastreadores de IA, el bloqueo de bots de IA de Vercel, y una línea de derechos de autor. Sé honesto: nada público es resistente a copias.

Entregables opcionales

Las personas que terminan a menudo quieren enseñar el proceso. Un folleto y una presentación de diapositivas pueden seguir las 13 etapas; usa capturas de pantalla reales de su sitio (antes y después) en lugar de imágenes de archivo, y escribe notas del orador en su voz. scripts/html_to_docx.py convierte un documento de proyecto con notas de diseño a Word.

Fallos comunes

Síntoma	Causa	Solución
404 en Vercel	El archivo principal no es index.html, o está dentro de una carpeta	Renómbralo y muévelo al nivel superior
Las carpetas del portátil o la galería vacías en línea	Las carpetas projects/ u otras nunca se subieron	Súbelas junto a index.html
Se muestra la versión antigua	Caché o despliegue aún en ejecución	Espera a que esté Listo, luego recarga con fuerza
"Cannot access X before initialization"	Una función o textura usada antes de su línea const	Muévela hacia arriba (una declaración function) o mueve el uso después
Al hacer clic en un objeto se abre un vecino	Objeto de línea decorativo atrapa rayos	obj.raycast = () => {}
El push a GitHub es rechazado	Claude GitHub App no instalada en el repositorio	Instálala para ese repositorio; puede ser necesaria una nueva sesión