Skip to content

English · Español

Fase 0 — Quizzes

Espejo legible de data/quizzes/phase-00-foundations.yaml. Las respuestas viven detrás de bloques <details> para que puedas autoevaluarte sin spoilers.

Fuente de verdad: data/quizzes/phase-00-foundations.yaml. El portal renderiza los mismos ítems; esta página es para leer sin conexión.

q-00-01 — ¿Por qué un lockfile no es simplemente un requirements.txt con versiones fijadas?

Ves dos archivos en el repo de un compañero: requirements.txt con numpy>=2,<3 y uv.lock con numpy==2.0.1 (sha256=...). ¿Qué afirmación captura con mayor precisión por qué el lockfile es necesario aunque el archivo de requisitos ya restrinja la versión?

  1. El lockfile es legible por humanos mientras que requirements.txt no.
  2. La restricción se satisface con versiones exactas distintas en días distintos; el lock fija una versión + el hash del artefacto, así la instalación falla si el upstream ha sido manipulado.
  3. El lockfile registra el orden de instalación, cosa que requirements.txt no puede.
  4. Solo el lockfile lo recoge CI; requirements.txt se ignora.
Respuesta **Opción 2.** Las restricciones describen un conjunto; los lockfiles registran una resolución + hash del contenido. El hash es lo que hace detectable la manipulación.

q-00-02 — ¿Qué fuentes de RNG NO hace deterministas seed_everything?

Selecciona cada fuente de no-determinismo que seed_everything(seed) no doma del todo por sí solo.

  1. Orden de reducción de BLAS multihilo
  2. El módulo random de la stdlib de Python
  3. TF32 vs FP32 en GPUs Ampere
  4. RNG legacy global de NumPy (np.random.seed)
  5. Hash randomization de cadenas entre procesos arrancados antes de que seed_everything se ejecutara
Respuesta **Opciones 1, 3, 5.** `seed_everything` siembra el estado del RNG. No puede reordenar una reducción multihilo, no puede desactivar TF32 (es un flag aparte) y no puede re-semillar `hash(str)` retroactivamente en un intérprete ya corriendo.

q-00-03 — Esenciales del manifiesto (libre)

En una o dos frases, nombra las tres piezas de información que un manifiesto de experimento debe contener para que un extraño, seis meses después, pueda reejecutar tu script y diagnosticar cualquier deriva numérica.

Respuesta Mínimo: la **semilla**, el **git sha** y las **versiones resueltas** de cada librería numéricamente relevante. Hardware y wall time son extras recomendados.

q-00-04 — Por qué git_dirty importa en un manifiesto

Un manifiesto contiene git_sha: a1b2c3 y git_dirty: true. ¿Por qué el subagente phase-gatekeeper lo rechaza como artefacto de DoD?

  1. Porque los working trees sucios confunden la resolución de uv.lock.
  2. Porque el sha registrado ya no identifica el árbol de fuentes que produjo los números; la ejecución no es reproducible solo desde el sha.
  3. Porque pytest salta los working trees sucios por defecto.
  4. Porque bandit no puede escanear un working tree sucio.
Respuesta **Opción 2.** Un working tree sucio significa que el código real que se ejecutó difiere de cualquier snapshot commiteado — el sha ya no identifica qué se ejecutó en realidad.

q-00-05 — Curva de coste de pre-commit (libre)

Ordena el coste típico de arreglar un defecto de más barato a más caro entre estas cinco fases: detectado-en-editor, detectado-por-CI, detectado-por-pre-commit, detectado-en-review, detectado-en-producción. Nombra el más barato y el más caro y explica en una frase por qué pre-commit se sitúa entre editor y CI.

Respuesta **Más barato:** editor (segundos). **Más caro:** producción (horas a días). **Pre-commit** se sitúa entre editor y CI porque corre antes del push pero después del bucle LSP/typecheck — más barato que esperar minutos a CI, más caro que el feedback continuo del editor.