Requisitos a Especificaciones Técnicas
Las solicitudes de producto llegan como "los usuarios deberían poder hacer staking y ganar rendimiento". Ingeniería entrega diseños de cuentas, gráficos de CPI y flujos de billetera. Una buena especificación cierra la brecha con criterios de aceptación comprobables antes de que alguien escriba manejadores de Anchor.
Receta
Tarjeta de receta de referencia rápida - lista para copiar y pegar.
## Característica: Hacer staking de SOL por participaciones en el pool
### Historia de usuario
Como titular, deposito SOL para recibir tokens del pool que representan mi participación.
### En cadena
- Cuentas: PDA de PoolConfig, PDA de UserPosition, cuenta SOL de bóveda
- Instrucciones: depositar, retirar
- CPIs: Solo transferencia del Programa del Sistema
### Aceptación
- [ ] LiteSVM: depositar 1 SOL -> emitir 1e9 unidades de participación
- [ ] La simulación falla si el pool está pausado
- [ ] El cliente muestra confirmado antes del toast de éxitoCuándo usar esto:
- Planificación de sprints para una nueva característica del protocolo
- El producto propone un cambio en la utilidad del token
- El auditor necesita un documento de alcance de la característica
- Traducir una propuesta de gobernanza comunitaria a ingeniería
Ejemplo de Trabajo
## Especificación: Reclamación de recompensas SPL (v1)
**Incluido**
- Reclamar recompensas acumuladas a la ATA del usuario
- Vista previa de solo lectura a través de simulación RPC
**Excluido**
- Autocompound (RFC v2)
- Voto de gobernanza para cambiar la tasa de emisión
**Seguridad**
- Solo el propietario de la posición puede reclamar
- La bóveda de recompensas PDA firma la transferencia a través de semillas
**UX**
- La billetera firma una transacción; mostrar estimación de CU
- Mapa de errores: Pausado, NadaQueReclamar, RentaInsuficienteLo que esto demuestra:
- La exclusión explícita de elementos previene sorpresas a mitad de sprint
- Las viñetas de seguridad se convierten en una lista de verificación de revisión
- El mapeo de errores de UX vincula el
ErrorCodedel programa con el texto
Análisis Profundo
Capas de la Especificación
| Capa | Audiencia | Contenido |
|---|---|---|
| PRD | Producto | Resultados del usuario, métricas |
| Especificación Técnica | Eng | Cuentas, ix, CPI |
| RFC | Inter-equipos | Modelo de amenaza, alternativas |
| Tickets | Implementadores | Tareas + pruebas |
Trampas Comunes
- "Soportar NFTs" vago - cNFT vs Metaplex vs Core difieren 10x en esfuerzo. Solución: Nombrar el estándar y la escala.
- Sin casos de fallo - Solo camino feliz de aceptación. Solución: Atacante y casos extremos por instrucción.
- Tokenomics poco claras - "La comunidad decide" sin autoridad. Solución: Multisig vs programa de gobernanza detallado.
- Especificación sin impacto RPC - Una característica pesada en GPA derrite la infraestructura. Solución: Ruta de lectura e indexador anotados.
- Cambiar especificación sin aumento de versión - Desfase entre cliente y programa. Solución: Versión de la especificación en el título del ticket.
Alternativas
| Alternativa | Usar Cuando | No Usar Cuando |
|---|---|---|
| Historias de trabajo | Usuarios avanzados de DeFi | Empresas reguladas que necesitan trazabilidad |
| BDD Gherkin | Flujos con mucho cliente | Diseño de cuentas de bajo nivel |
| Solo FigJam | Fase de lluvia de ideas | Lógica de tenencia de fondos |
Preguntas Frecuentes
¿Quién escribe la especificación técnica?
El ingeniero propone; el producto revisa los resultados del usuario; ambos firman antes del compromiso del sprint.
¿Qué tan detallado antes de RFC?
Suficiente para que la revisión de seguridad liste las cuentas y los firmantes.
¿Solicitudes de características de la comunidad?
Clasificar en especificación con apéndice de tokenomics y seguridad.
¿Plantilla de especificación?
docs/specs/TEMPLATE.md junto a la plantilla RFC.
¿Estimación a partir de la especificación?
T-shirt por instrucción + clase CPI; refinar después del spike.
¿Entrada del auditor?
Compartir la especificación antes de la implementación para acordar el alcance.
¿MWA móvil?
Añadir sección de flujo de billetera a la especificación para rutas de Solana Mobile.
¿Romper IDL?
Marcar en la especificación; coordinar el tren de lanzamiento en el mismo documento.
¿Especificación vs ADR?
La especificación tiene un alcance de característica y puede expirar; ADR es un registro arquitectónico.
¿Especificación abandonada?
Marcar como retirada; enlazar la razón para evitar un nuevo debate.
Relacionado
- Realización de Revisiones de Diseño - de especificación a RFC
- Estimación y Riesgo - dimensionamiento a partir de la especificación
- Comunicación con Stakeholders - compartir progreso
Versiones de Stack: Esta página fue escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0, y LiteSVM 0.6.x.