La fabricación es una transacción, no una segunda economía

699. Identidad de la lección

Módulo

2.5 — Inventario, equipamiento y fabricación

Lección

La fabricación es una transacción, no una segunda economía

Tipo académico

Integración

Tipo de esquema

Práctica

Orden

Lección 3

Tiempo estimado

35–45 minutos

700. Objetivo de aprendizaje

Después de esta lección, podrás especificar una transacción de fabricación clasificando los datos de la receta, las entradas del inventario, los costes no basados en objetos que pertenecen a economía, los resultados, las precondiciones de progresión, la confirmación atómica, la reversión y las evidencias de fallo.

701. Por qué importa

La fabricación conecta inventario, economía, progresión y presentación sin sustituir ninguno de estos sistemas. Una transacción que consume objetos pero olvida un coste controlado por economía, acepta una receta inválida o falla a mitad del proceso puede dejar el estado del juego incoherente. La validación previa y la confirmación atómica establecen un límite fiable para la implementación. También proporcionan una especificación concreta con la que puedes revisar diseños o código generados por IA.

702. Conocimientos previos

El inventario controla la posesión y las cantidades de objetos. El equipamiento controla la selección activa de ranuras y modifica las capacidades mediante un contrato explícito. La fabricación debe recurrir a esas autoridades, no copiar su estado. Usa el modelo de esta etapa, entrada → regla → presentación → respuesta visible, para explicar cómo se hace observable una solicitud de fabricación.

703. Concepto central

La fabricación es una transacción delimitada que opera sobre autoridades existentes. Una receta declara entradas de objetos, costes no basados en objetos que pertenecen a economía, resultados y precondiciones. La operación valida la declaración completa y todos los requisitos del jugador antes de modificar cualquier estado autoritativo.

• El inventario controla las cantidades de objetos.
• Economía controla los saldos no basados en objetos, como la moneda.
• Progresión controla la disponibilidad de las recetas.
• Equipamiento controla la selección activa de ranuras.
• Fabricación coordina la validación, la confirmación, la reversión y la clasificación del resultado.
• Presentación representa el resultado devuelto sin decidir si la fabricación tuvo éxito.

Un resultado autoritativo de fabricación puede proporcionarse después como evidencia para una misión, pero el sistema de misiones conserva la autoridad sobre los predicados que determinan si esa evidencia satisface una condición.

Un flujo seguro es:

solicitud de fabricación + receta
→ validar los datos y todas las precondiciones
→ preparar el conjunto completo de cambios de inventario y economía
→ confirmar todos los cambios juntos
→ devolver un único resultado autoritativo

Los datos de receta inválidos y los recursos insuficientes son fallos de validación. No deben producir ninguna mutación. Si no se puede garantizar que todas las mutaciones tengan éxito juntas, usa un único comando atómico en el límite con autoridad, o reservas/comprobaciones de versión y un protocolo de confirmación definido. Restaurar una instantánea más tarde no equivale a una confirmación atómica. La compensación puede restaurar las mutaciones de esta transacción, pero no debe sobrescribir una escritura concurrente legítima.

704. Mapa de autoridad

Una receta es inválida cuando su declaración no puede describir una operación segura. Algunos ejemplos son la ausencia de un ID de receta, una cantidad no positiva, un objeto o una clave económica desconocidos, entradas duplicadas en conflicto o una cantidad de salida ausente. Los datos inválidos no equivalen a una falta de recursos del jugador. Ambos casos fallan antes de mutar, pero requieren resultados distintos.

705. Modelo mental

Usa DECLARAR → VALIDAR → PREPARAR → CONFIRMAR → INFORMAR:

706. Ejemplo hipotético de especificación

Considera esta receta ilustrativa:

Receta: field_repair_kit
Entradas:
  scrap: 3
  fiber: 1
Coste no basado en objetos:
  credits: 10
Resultado:
  repair_kit: 1
Precondición:
  la receta está desbloqueada

Supón que el inventario contiene 5 unidades de scrap, 1 de fiber y espacio para el resultado; economía contiene 25 credits; y progresión indica que la receta está desbloqueada. El conjunto preparado es:

inventario: scrap -3, fiber -1, repair_kit +1
economía: credits -10
resultado: SUCCESS

El estado final esperado es 2 unidades de scrap, 0 de fiber, 1 repair_kit y 15 credits. Fabricación coordina los cambios, pero no crea otro saldo de créditos.

Si solo hay 2 unidades de scrap, la validación devuelve INSUFFICIENT_ITEM antes de mutar. Si solo hay 7 credits, devuelve INSUFFICIENT_ECONOMY_COST; inventario y economía permanecen intactos. Un coste negativo, un objeto desconocido o una cantidad de salida ausente produce INVALID_RECIPE_DATA y no cambia el estado del jugador.

Si se retiran las entradas y después falla la mutación económica, la transacción debe restaurar las cantidades y dejar ausente el resultado. Si el resultado ya se había concedido, la reversión también debe retirarlo. Compensa las mutaciones de esta transacción salvo que el almacenamiento sea realmente atómico; no sobrescribas una escritura concurrente legítima. La coincidencia exacta con el estado previo solo se exige en un límite realmente atómico y sin una escritura concurrente legítima.

707. Flujo de trabajo nativo de IA

Usa la IA para hacer visible y comprobar el límite transaccional, no para que elija autoridades ocultas.

1. Escribe la receta, el mapa de autoridad, las invariantes y los códigos de resultado antes de pedir una implementación.
2. Pide a la IA que clasifique cada lectura y mutación como trabajo de receta, inventario, economía, progresión, fabricación, equipamiento, presentación o misiones.
3. Exige que valide los datos, las cantidades, los costes no basados en objetos, el desbloqueo y la capacidad antes de mutar.
4. Exige un conjunto de cambios preparado o un diseño transaccional que confirme juntos los cambios de inventario y economía.
5. Exige una ruta de reversión que restaure todas las entradas, costes y resultados ya aplicados.
6. Solicita pruebas de éxito, objetos insuficientes, coste económico insuficiente, datos inválidos, receta bloqueada, falta de capacidad, solicitudes repetidas y fallo forzado durante la confirmación.
7. Revisa si aparecen saldos duplicados, consumo parcial, resultados concedidos antes del coste, cambios de equipamiento sin una regla explícita o lógica de presentación que decida el éxito por su cuenta.

Un prompt útil es:

Especifica una transacción de fabricación para field_repair_kit. Consume 3 scrap, 1 fiber y 10 credits controlados por economía, requiere que la receta esté desbloqueada y produce 1 repair_kit. Valida los datos, los recursos, el desbloqueo y la capacidad antes de mutar. Confirma los cambios de inventario y economía con un comando atómico, o con reservas/comprobaciones de versión y un protocolo de confirmación. Si falla cualquier paso, compensa las mutaciones de esta transacción salvo atomicidad real; no sobrescribas una escritura concurrente legítima. Devuelve resultados distintos para datos inválidos, objetos insuficientes, créditos insuficientes, receta bloqueada, falta de capacidad, confirmación revertida y éxito. Muestra el mapa de autoridad, el conjunto de cambios y las pruebas de invariantes antes de implementar.

708. Error común

Un error frecuente es tratar la validación como una secuencia de mutaciones: retirar una entrada, descubrir después que falta otro objeto o la moneda y devolver un fallo con el estado ya dañado. Otro error consiste en validar solo el inventario y permitir que el coste económico falle más tarde. También se pueden confundir los datos inválidos con una escasez del jugador, lo que oculta un defecto de configuración.

Valida primero la receta y todas las precondiciones. Prepara el conjunto completo de cambios. Confirma juntos los cambios de objetos y economía. Si no puede completarse la confirmación, compensar las mutaciones de esta transacción con un protocolo seguro ante conflictos, que puede fallar y no debe sobrescribir una escritura concurrente legítima, salvo que el almacenamiento sea realmente atómico.

709. Práctica guiada

Completa la evaluación práctica adjunta mediante una especificación de transacción y una matriz de pruebas.

Paso 1: Declara y clasifica la receta

Registra:

• ID de receta;
• IDs y cantidades positivas de las entradas;
• cualquier coste no basado en objetos, su autoridad y su cantidad;
• IDs y cantidades de los resultados;
• precondición de progresión;
• política de capacidad de salida.

Añade al menos dos casos de datos inválidos. No introduzcas una moneda exclusiva de fabricación ni dupliques una cantidad del inventario.

Paso 2: Escribe el mapa de autoridad y las invariantes

Identifica la autoridad de los datos de receta, las cantidades de objetos, los saldos no basados en objetos, la disponibilidad de progresión, la selección de equipamiento, la coordinación de la transacción, la presentación y cualquier predicado de misión posterior. Incluye estas invariantes:

• los datos inválidos no cambian el estado del jugador;
• la falta de objetos o de costes no basados en objetos no cambia el inventario ni la economía;
• una receta bloqueada no puede fabricarse solo porque haya recursos suficientes;
• el éxito consume y concede exactamente las cantidades declaradas;
• inventario y economía confirman juntos de forma atómica, o siguen un protocolo de reserva/versión/confirmación cuya compensación no sobrescribe escrituras concurrentes legítimas;
• equipamiento solo cambia mediante una regla independiente y explícita;
• presentación muestra el resultado en vez de recalcularlo;
• la lógica de misión puede recibir el resultado como evidencia, pero controla sus propios predicados.

Paso 3: Define el contrato de resultado

Especifica resultados distintos para SUCCESS, INVALID_RECIPE_DATA, INSUFFICIENT_ITEM, INSUFFICIENT_ECONOMY_COST, RECIPE_LOCKED, OUTPUT_CAPACITY_FAILURE y COMMIT_ROLLED_BACK, o equivalentes precisos. Para cada resultado, indica el estado final esperado del inventario y la economía.

Paso 4: Construye la matriz de pruebas

Incluye:

1. todos los requisitos satisfechos;
2. falta de un objeto requerido;
3. falta del coste no basado en objetos;
4. datos de receta inválidos;
5. recursos suficientes, pero receta bloqueada;
6. falta de capacidad de salida;
7. fallo forzado después de aplicar una mutación;
8. solicitud repetida después de un éxito;
9. un cambio concurrente o intermedio después de la validación previa y antes del commit, que debe producir un conflicto o un reintento y no debe perder la actualización intermedia.

En cada fila registra el estado inicial, la acción, el resultado esperado, el estado final esperado y la evidencia observable. La fila de fallo forzado debe demostrar compensación de las mutaciones de esta transacción salvo atomicidad real, y no puede afirmar una restauración exacta después de una escritura concurrente legítima.

Paso 5: Toma una decisión de implementación

Elige un único comando atómico en el límite con autoridad, o reservas/comprobaciones de versión y un protocolo de confirmación definido. Una API transaccional genérica solo vale si aporta esa atomicidad; restaurar una instantánea más tarde no equivale. No trates una instantánea restaurada a posteriori como equivalente a una confirmación atómica. Restaurar una instantánea puede sobrescribir cambios legítimos concurrentes; la propia reversión puede fallar; y la capacidad o el saldo comprobados en la validación previa pueden quedar obsoletos antes del commit. Si inventario y economía siguen siendo autoridades separadas, exige reserva o control de versión y un protocolo de confirmación definido. Describe la restauración tras un fallo como compensación, salvo que el almacenamiento sí ofrezca atomicidad. Incluye una prueba en la que el estado cambie entre la validación y el commit: el resultado debe ser un conflicto o un reintento, sin actualizaciones perdidas. Explica cómo el diseño coordina inventario y economía sin duplicar sus autoridades. Indica dónde se aplica la capacidad de salida y cómo la política evita perder entradas o duplicar resultados.

710. Validación y evidencias

711. Puntos clave

• Fabricación coordina autoridades existentes; no crea una segunda economía.
• Valida los datos, los recursos, la progresión y la capacidad antes de mutar.
• Los cambios de inventario y economía deben confirmarse juntos de forma atómica, o compensarse las mutaciones de esta transacción con un protocolo seguro ante conflictos que puede fallar y no debe sobrescribir una escritura concurrente legítima.
• Los datos inválidos, los recursos insuficientes y los fallos de confirmación requieren resultados y evidencias distintos.
• Presentación muestra el resultado autoritativo sin recalcularlo.
• Una misión puede consumir ese resultado como evidencia, pero el sistema de misiones controla sus predicados.

712. Próxima lección

Continúa con 2.7 — Misiones.

713. Comprobación