rajput-hemant/website

Verificar el sitio web del portafolio

Estado: lanzamiento, diagnóstico, limpieza y un primer conjunto de flujos están probados en producción (2026-10-02, probado 82ec737, chrome-devtools-axi, WebGL2 real en Apple M3 Pro). La cobertura es parcial: cada archivo features/*.md tiene una línea Última prueba en vivo: que indica exactamente qué se ejecutó y qué no; una característica cuya línea dice ninguno nunca se condujo. Nada de esto está "verificado" porque este archivo lo describe.

Solo activación manual (regla de usuario, 2026-10-02): esta habilidad y PStack se ejecutan solo cuando el usuario solicita explícitamente la verificación. Un commit, push, PR o habilitar un modo no la inicia, y nada de esto puede estar conectado a un gancho de git, script de ciclo de vida de paquete, trabajo de CI o programación. El frontmatter establece disable-model-invocation: true, por lo que el agente nunca lo recoge por sí solo. Inícielo manualmente: Claude Code /verify; Codex $verify cuando Codex descubre .agents/skills/verify; cualquier otro agente: lea este archivo y ejecute los pasos a continuación explícitamente. Auditoría de activaciones automáticas el 2026-10-02, ninguna ejecuta un navegador: .husky/pre-commit (lint-staged, configuración .lintstagedrc: eslint y prettier en archivos preparados), .husky/commit-msg (commitlint), package.json prepare (husky), .github/workflows/ci.yml (type-check, lint, fmt:check, vitest, build, budget). test:e2e y visual-baseline son solo scripts manuales. El core.hooksPath de este checkout apunta a un directorio de hooks de firstmate fuera del repositorio, no a .husky.

El uso del navegador está autorizado solo para una ejecución de verificación explícita (la ejecución del 2026-10-02 fue autorizada por el capitán, reemplazando la retención anterior del navegador). Las recetas de Drive están escritas como acciones de usuario y resultados observables para que se ejecuten con chrome-devtools-axi o cualquier otra habilidad de navegador.

Cada problema abierto, hipótesis y brecha de prueba en vivo reside en un solo libro de contabilidad: docs/verification/verification-issues.md. Los archivos de características enlazan a él y no lo repiten. Lea features/README.md para el mapa antes de conducir cualquier cosa.

Cuál es la superficie

Una aplicación Next.js 16 (App Router, proxy.ts, prerenderizado estático, React Compiler). Once ediciones en vivo comparten un modelo de contenido y un conjunto de rutas; la edición del visitante decide la apariencia. El proxy reescribe /<path> a /f/<edition>/<path>; / muestra el selector (/flavors) hasta que la cookie hr_flavor contenga un ID de edición en vivo. NEXT_PUBLIC_FLAVOR=<id> fija una compilación a una edición. La lista de ediciones es flavors/registry.ts. La lista de rutas por edición es content/site.ts pages más /owner, /projects/<slug>, /lab/<slug>, /ask/<slug>, /ask/page/<n>, /md/* mirrors, /llms.txt, /sitemap.xml, /robots.txt.

Esto es Next.js con cambios importantes. Antes de tocar el código de la aplicación, lea la guía correspondiente en node_modules/next/dist/docs/ (el AGENTS.md del repositorio lo dice).

Arneses existentes (reutilizar, no duplicar)

playwright.config.ts y e2e/*.spec.ts ya cubren la mayor parte del comportamiento del shell. Una ejecución de verificación conduce el sitio en vivo para lo que no prueban y los cita para lo que prueban. Nunca copie una aserción de e2e en un archivo de características como un segundo conjunto de pruebas.

Cobertura existente	Dónde	Qué prueba
La salida de compilación está prerenderizada	e2e/static-routes.spec.ts (proyecto build)	ninguna ruta pública se renderiza por solicitud, sin revalidación basada en tiempo
Conjunto mínimo personalizado	home, navigation, ask, lab, motion, preferences, print, disclosure, command-menu, link-preview, markdown specs, proyectos desktop y mobile	Solo mínimo (cookie hr_flavor=minimal)
Conjunto personalizado Drawing Set	e2e/drawing-set.spec.ts, proyectos desktop-drawing-set, mobile-drawing-set	índice de hojas, menú de comandos, persistencia de Personalizar, registro /now, sin desbordamiento a 768
Shell compartido para las otras nueve	editions.spec.ts, a11y.spec.ts, command-dialog.spec.ts, proyectos desktop-<id> y mobile-<id>	cada ruta 200 con un h1, edición 404, menú de comandos, tema Personalizar, alternancia de tema en el encabezado, axe en claro y oscuro con movimiento reducido, contratos de rueda de diálogo de comandos y teclado

Esos conjuntos se ejecutan con bun run test:e2e e inician su propio bun run build && bun run start -p 3020 (reuseExistingServer: true fuera de CI, por lo que cualquier proceso ya en 3020 se reutiliza silenciosamente). Son automatización de navegador: ejecútelos solo a pedido, un worker, con 3020 confirmado libre. No se ejecutaron el 2026-10-02. Su aprobación o falla no es una prueba de nada que este mapa marque como una brecha (consulte el libro de contabilidad).

Compuertas que no son de navegador que existen: bun run lint, bun run type-check, bun run test (vitest), bun run fmt:check, bun run check:identity, bun run budget (después de una compilación). Ejecutarlos está permitido y no dice nada sobre el comportamiento de la UI.

Lanzamiento

Un servidor por tarea, en un puerto específico de la tarea, iniciado desde una compilación de producción porque eso es lo que asumen la configuración de e2e y static-routes.spec.ts (next dev no es parte de este plan).

.agents/skills/verify/scripts/doctor.sh                    # higiene de entorno y árbol, no necesita servidor
.agents/skills/verify/scripts/serve.sh start 3071          # compilar, iniciar, esperar disponibilidad, escribir archivo PID
.agents/skills/verify/scripts/doctor.sh 3071               # ahora también sondea la instancia en ejecución

serve.sh start hace exactamente esto: rechaza si el puerto está ocupado, ejecuta bun run build y bun run start -p <port> con todas las variables de Sanity, consulta y sabor sin establecer (para que el sitio renderice el contenido de respaldo empaquetado y no haga llamadas a CMS), registra el PID del servidor en $RUN_DIR/server.pid, y espera hasta que GET /flavors responda 200. Los puertos 3000 y 3020 son rechazados (3020 pertenece a la configuración de Playwright). Una compilación sobrescribe .next; no inicie dos ejecuciones en un mismo checkout.

Listo significa todo lo siguiente: serve.sh imprimió ready, GET /flavors es 200, y GET / con la cookie hr_flavor=minimal es 200 y contiene un <h1>. No conduzca nada que no haya cumplido los tres.

Cierre: .agents/skills/verify/scripts/serve.sh stop 3071 (consulte Limpieza).

Diagnóstico (Doctor)

.agents/skills/verify/scripts/doctor.sh [port] es de solo lectura. Responde "¿vale la pena conducir esta instancia y es segura?". Falla (código de salida 1) cuando se cumple alguna de estas condiciones:

• Un archivo .env, .env.local, .env.development*, .env.production* existe en la raíz del repositorio (Next cargaría secretos de Sanity o de consulta y la conducción podría escribir en un conjunto de datos real).
• Cualquiera de NEXT_PUBLIC_SANITY_PROJECT_ID, SANITY_API_READ_TOKEN, SANITY_API_WRITE_TOKEN, SANITY_REVALIDATE_SECRET, ASK_COOKIE_SECRET, ASK_OWNER_PASSPHRASE, NEXT_PUBLIC_FLAVOR está establecido en el shell de llamada.
• HEAD no es el commit que la ejecución afirma, o el árbol está sucio (imprime ambos).
• Con un puerto: el puerto no es propiedad del PID en $RUN_DIR/server.pid, /flavors no es 200, /api/visits no es 503 (debe ser 503: así es como la compilación de respaldo prueba que el contador de visitas no puede escribir en un CMS), o / con hr_flavor=minimal no tiene <h1>.

Ejecútelo primero cada vez que algo parezca fuera de lo común.

Requisitos previos que una ejecución debe declarar

• Contenido: respaldo empaquetado (content/fallback/), el predeterminado. Una ejecución contra un proyecto de Sanity configurado es una ejecución diferente con aprobación del propietario, un conjunto de datos desechable y un token de solo lectura; consulte features/cms-prerequisites.md. Ninguna ejecución puede escribir en un CMS, cambiar el contenido del propietario, implementar o tocar credenciales.
• Viewports: escritorio 1440x900 y teléfono (perfil "Pixel 7" de Playwright: táctil, puntero grueso, sin hover). Claro y oscuro. Movimiento activado y prefers-reduced-motion: reduce.
• Almacenamiento: inicie cada conducción de sabor desde un perfil vacío con solo la cookie hr_flavor=<id> (lo que hace el storageState de e2e). Nunca use una sesión de navegador autenticada compartida.
• Nivel de escena: el nivel de escena sigue a WebGL2, Save-Data, prefers-reduced-data, deviceMemory y puntero (lib/scene/tier.ts). Registre las señales de nivel del navegador con cada prueba de escena. Un navegador sin cabeza sin GPU prueba T0 y el póster, no el 3D.

Conducción (Drive)

Navegador: chrome-devtools-axi con su propia sesión, puerto y perfil aislado; nunca se conecte automáticamente al Chrome del usuario. Configuración probada (2026-10-02):

export CHROME_DEVTOOLS_AXI_SESSION=<unique-task-name> CHROME_DEVTOOLS_AXI_PORT=<free port> CHROME_DEVTOOLS_AXI_AUTO_CONNECT=0
export CHROME_DEVTOOLS_AXI_MCP_PATH="$(npm prefix -g)/lib/node_modules/chrome-devtools-mcp/build/src/bin/chrome-devtools-mcp.js"   # evita el arranque de npx
export CHROME_DEVTOOLS_AXI_HEADED=1 CHROME_DEVTOOLS_AXI_CHROME_ARGS="--enable-gpu --ignore-gpu-blocklist"   # WebGL2 real; headless prueba solo el póster
chrome-devtools-axi emulate --viewport "1440x900x2"              # escritorio; "412x915x2.625,mobile,touch" para el perfil Pixel 7
chrome-devtools-axi emulate --color-scheme dark|light
# movimiento reducido: reinicie el puente (`chrome-devtools-axi stop`) con --force-prefers-reduced-motion añadido a CHROME_ARGS
chrome-devtools-axi run <<'EOF' ... EOF                              # barridos con script; detenga el puente al final

Notas de herramientas de la ejecución: en scripts run, page.wait(ms) lanza "fn is not a function", así que duerma con await new Promise(r=>setTimeout(r,ms)); process.env no está disponible allí, sustituya valores en el texto del script; hr_flavor no se puede borrar desde document.cookie, así que elija una edición abriendo /?flavor=<id>; emulate no tiene un indicador de movimiento reducido; un clic de puntero en el Paper visualmente oculto de Press agotó el tiempo de espera (la tecla de flecha derecha funcionó, WEB-H8); el hook zshz de este shell devuelve distinto de cero en cd, así que use rutas absolutas. Cada archivo de características bajo features/ enumera las acciones, los identificadores estables y el estado final observable. Identificadores en orden de preferencia: rol ARIA y nombre accesible, ruta de ruta, html[data-theme], html[data-motion], html[data-scene], [data-scene-poster], la clave hr.*.prefs de localStorage por edición (e2e/support/site.ts prefsKeyFor). Sin coordenadas.

Estándares de prueba:

• Ejercite la ruta y el control reales, no un establecedor de almacenamiento. Prefiera el control visible sobre las ediciones de localStorage; use el almacenamiento solo para establecer un estado inicial que el archivo de características nombre.
• Capture la acción y el estado después de ella: una instantánea ARIA y una captura de pantalla para la UI, el estado de respuesta y los encabezados para las comprobaciones HTTP, el registro de la consola y las solicitudes fallidas para cada conducción.
• Una prueba unitaria o especificación e2e aprobada no es prueba de un flujo no ejercitado. Marque la característica Última prueba en vivo: solo después de que el flujo real se haya ejecutado, con fecha, commit y ruta de evidencia.
• Informe una ruta inalcanzable con el paso intentado y la condición previa no cumplida. No informe un punto de entrada omitido como verificado a través de otro.

Evidencia

Directorio: $EVIDENCE_DIR, por defecto $HOME/.verify-evidence/website/<run-id>/ donde <run-id> es <marca de tiempo UTC>-<HEAD corto>. Diseño: doctor.txt, server.log (copiado de $RUN_DIR), luego <feature-id>/<step>.aria.txt, <step>.png, console.txt, network.txt. Después de una conducción, agregue una línea a la línea Última prueba en vivo: del archivo de características (fecha, commit, ruta de evidencia) y una fila al libro de contabilidad. Copie $RUN_DIR/server.log en el directorio de evidencia antes de stop, porque stop elimina $RUN_DIR. La evidencia sobrevive a la limpieza y nunca es eliminada por esta habilidad.

Limpieza (Cleanup)

.agents/skills/verify/scripts/serve.sh stop <port> mata solo el PID en $RUN_DIR/server.pid (y los hijos que inició), luego elimina $RUN_DIR. Nunca mata por nombre de proceso y nunca toca un proceso que no inició. Deja .next (un artefacto de compilación que el checkout ya ignora) y $EVIDENCE_DIR intactos. Si el archivo PID falta, lo informa y no mata nada. Después de una ejecución fallida, ejecútelo antes de reintentar para que ningún puerto permanezca ocupado.

$RUN_DIR es ${TMPDIR:-/tmp}/website-verify-<port>; contiene solo el archivo PID y el registro del servidor.

Ayudantes (Helpers)

• scripts/doctor.sh [port]: la comprobación de solo lectura anterior. Salida 0 saludable, 1 no vale la pena conducir.
• scripts/serve.sh start <port> y scripts/serve.sh stop <port>: lanzamiento y cierre anteriores.

Ambos son ejecutables y usan solo bash, curl, lsof, git y bun.