Entregables y evaluación
Cada semana el equipo abre un pull request en su repositorio con lo de las dos rutas. Vence el lunes a las 11:59 p. m. y se revisa en las office hours del martes. Todo lo técnico se verifica con un enlace público: un hash o un Contract ID en stellar.expert, o un PR en GitHub.
Pull requests de la Ruta
| PR | Fundamentos | Builders | Emprendimiento |
|---|---|---|---|
| #1 Lun 19 oct |
La define el equipo técnico al cierre de la sesión 1. Lectura común: Stellar Docs → Learn → Fundamentals. | Issue «Hipótesis de problema» y lista de 5 personas a entrevistar. | |
| #2 Lun 26 oct |
Emisión del activo documentada, diagrama de cuentas, trustlines y pagos, y explicación de qué es un activo. | hello_world con count en testnet, Contract ID en el README, pruebas en CI y declaración de IA. |
5 entrevistas en docs/entrevistas.md y lienzo del problema en docs/problema.md. |
| #3 Lun 2 nov |
App con wallet y pago en testnet, bocetos de las tres pantallas y README con el problema y las operaciones. | Diseño del contrato aprobado, lib.rs con las funciones firmadas y pruebas del comportamiento esperado. |
Propuesta de valor en docs/propuesta-de-valor.md, probada con 3 usuarios, y mapa de las tres pantallas. |
| #4 Lun 9 nov |
Proyecto desplegado en testnet de punta a punta. README final con problema, operaciones o contratos, Contract ID o cuentas, cómo correrlo y declaración de IA. Informe técnico en docs/informe.md. |
Modelo en docs/modelo.md, guion en docs/pitch.md y diapositivas en docs/pitch.pdf. | |
| Demo Day Vie 13 nov |
Pitch de 3 minutos, demo de 3 minutos en testnet (en vivo o en video) y 2 minutos de preguntas del panel. | ||
Además, cada semana debe haber commits en el repositorio: la meta es que el 80 % de los equipos tenga commits en 4 de las 5 semanas.
Cómo queda el repositorio del equipo
2026-II-<equipo>/
├── README.md equipo, roles, nivel, direcciones, Contract ID, cómo correrlo
├── DEBUG_LOG.md errores de la sesión 4 y cómo se resolvieron
├── docs/
│ ├── problema.md lienzo del problema (PR #2)
│ ├── entrevistas.md 5 entrevistas (PR #2)
│ ├── propuesta-de-valor.md (PR #3)
│ ├── modelo.md modelo en una página (PR #4)
│ ├── pitch.md y pitch.pdf (PR #4)
│ └── informe.md informe técnico (PR #4)
├── contracts/ Builders: contrato Soroban y pruebas
├── app/ frontend o app con wallet
└── .github/
├── PULL_REQUEST_TEMPLATE.md
└── workflows/ CI
El informe técnico sigue esta estructura: antecedentes; planteamiento del problema (justificación, objetivos, viabilidad y deficiencias en el conocimiento del problema); hipótesis; marco teórico; metodología y resultados.
Plantilla de pull request con declaración de IA
PULL_REQUEST_TEMPLATE.md
## Qué hace este PR
(2 a 4 líneas, en sus palabras)
## Ruta de emprendimiento
- [ ] Entregable de la semana en docs/ (enlace):
## Cómo lo probamos
- [ ] Pruebas automatizadas pasan (CI verde)
- [ ] Probado en testnet: hash / Contract ID: ____
## Declaración de uso de IA (obligatoria)
- [ ] No usamos IA en este PR
- [ ] Usamos IA para explicar conceptos o errores
- [ ] Usamos IA para generar código. Archivos/funciones: ____
Qué cambiamos después de leerlo: ____
Qué parte no entendimos del todo (sé honesto, no resta puntos): ____
- [ ] Usamos IA para generar pruebas. ¿Las leímos y entendimos qué verifican? Sí / No
## Integrante que puede explicar cada parte
| Archivo / función | Quién la explica |
|---|---|
| | |Convención de commits: feat:, fix:, docs:, test: seguidos de una descripción corta. La rama main está protegida: todo entra por PR con al menos una revisión.
Cómo se califica
Se evalúan tres cosas: que el equipo avance cada semana, que cada persona aprenda (y pueda explicar lo que construyó) y lo que presenta el equipo en el Demo Day. Las rúbricas se publican antes de calificar para que dos mentores califiquen igual.
Semáforo del PR semanal
| Verde | Entregado a tiempo, completo y con enlace verificable en las dos rutas. |
| Amarillo | Parcial, tarde o sin evidencia. Se completa antes del viernes. |
| Rojo | No entregó. El equipo va obligatoriamente a office hours esa semana. |
Insignias de nivel
Fundamentos
6 de las 7 habilidades del checklist, marcadas por un mentor cuando la ve ejecutada sin ayuda.
Builders
7 de las 9 habilidades del checklist. Además, nadie recibe la insignia sin pasar la prueba oral (nivel 2 o más) y sin un contrato con rúbrica de 2,0 o más.
El checklist completo está en la ruta técnica. Las insignias se publican en el repositorio del semillero y el panel del Demo Day las ve como contexto, no como puntaje.
Rúbricas técnicas
Calidad de contratos Soroban
| Criterio | 0 | 1 | 2 | 3 |
|---|---|---|---|---|
| Autorización | Funciones que cambian estado sin require_auth | require_auth en algunas, inconsistente | En todas las funciones que cambian estado | Además, roles o admin guardados en storage y verificados |
| Manejo de errores | Panics genéricos o sin validar entradas | Valida entradas pero con panic! | Errores tipados con contracterror y Result | Errores documentados y probados |
| Storage | Todo en un solo tipo sin criterio | Tipos elegidos sin justificar ni TTL | Tipo correcto por dato | Además, extiende TTL donde corresponde y lo explica |
| Pruebas | Sin pruebas | Una prueba del camino feliz | Tres o más, incluido un caso de fallo | Pruebas de autorización con mock_auths y de límites |
| Secretos y configuración | Llaves o seeds en el repositorio (crítico) | Configuración mezclada en el código | Variables de entorno y .gitignore correctos | Además, README con red, Contract ID y cómo reproducir el despliegue |
| Documentación | No se puede invocar sin preguntar | README incompleto | README con build, deploy e invoke de ejemplo | Además, diagrama del flujo y decisiones de diseño |
Hallazgo crítico: una llave privada o seed en el repositorio, o una función que mueve fondos o cambia el admin sin autorización. Anula el puntaje de la revisión hasta corregirlo.
Commits y pull requests
| Criterio | 0 | 1 | 2 | 3 |
|---|---|---|---|---|
| Mensajes | «update», «fix», «final» | Describen el qué | Describen qué y por qué | Siguen la convención tipo: descripción |
| Atomicidad | Un commit con todo el trabajo de la semana | Commits grandes mezclando temas | Un cambio por commit | Historial que cuenta la historia del trabajo |
| Descripción del PR | Vacía | Una línea | Qué cambia, cómo probarlo y declaración de IA | Además, capturas o hashes de la prueba en testnet |
| Revisión por par | Sin revisión | Aprobado sin comentarios | Al menos un comentario sustantivo | Cambios solicitados y atendidos antes de fusionar |
| Pruebas | No corren o fallan | Corren localmente según el autor | Pasan en el repositorio | CI configurada y en verde |
Comprensión del código
Prueba oral de cinco minutos en la sesión 4: el mentor elige dos funciones del código entregado y cualquier integrante las explica, sin pantalla ni asistentes.
| 0 | No reconoce el código o no sabe qué hace. |
| 1 | Describe qué hace, pero no por qué está así ni qué pasa si falla. |
| 2 | Explica qué hace, por qué se tomó esa decisión y qué pasa con una entrada inválida. |
| 3 | Además, propone una mejora o identifica un riesgo sin que se le pregunte. |
Rúbrica del Demo Day (100 puntos)
| Criterio | Puntos | Qué se evalúa |
|---|---|---|
| Problema y usuario | 20 | Dolor real validado con entrevistas; por qué blockchain y por qué Stellar. |
| Funcionamiento técnico | 30 | Corre en testnet de punta a punta, en vivo o en video, con evidencia verificable en el explorador; uso correcto de cuentas, activos o contratos; código legible. Se apoya en la rúbrica de contratos. |
| Propuesta de valor y producto | 20 | Flujo claro, onboarding y decisiones justificadas con usuarios. |
| Informe técnico | 20 | Estructura completa, metodología clara y resultados verificables. |
| Pitch | 10 | Tres minutos, demo sin improvisar y respuestas al panel. Cualquier integrante debe poder explicar cualquier parte. |
Un hallazgo crítico de seguridad resta 10 puntos. El puntaje final es el promedio del panel.
Quién compite y cómo se gana
Para competir por premios
- Al menos 3 de los 4 PR en verde o amarillo.
- Commits en 4 de las 5 semanas.
- Demo en testnet, en vivo o en video, con un hash o Contract ID verificable.
Premios
- Primer lugar: USDC 120.
- Segundo lugar: USDC 80.
- Los mejores proyectos quedan como candidatos a Instawards y al Stellar Community Fund.
- En caso de empate gana el equipo con más PR en verde.