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 éxito

Cuá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, RentaInsuficiente

Lo 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 ErrorCode del programa con el texto

Análisis Profundo

Capas de la Especificación

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

Preguntas Frecuentes

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.