zfxaction26_2/docs/design.md

Reactor Maintenance Design

Concept

The player controls a maintenance robot inside a failing reactor facility. The game is a deterministic, turn-based systems puzzle about reading a visible machine, forecasting failure, and choosing between local stabilization and longer-term network control.

The simulation core is built from:

• static floor and wall terrain,
• underground fuel, coolant, and electricity networks,
• surface props for sources, isolation valves, controls, terminals, supplies, doors, and reactor activation,
• consumers that consume whichever underground services exist under their cell,
• reachable leaks and sprinkler valves that project hazards or suppression water onto floor cells,
• transport network structural integrity,
• deterministic fixed simulation rules and forecasts.

The game should feel logical, tactical, readable, and systemic. It should avoid randomness, action pressure, and hidden information while the player is using an active and powered AllSeeingEyeTerminal.

Terminology

Design and campaign documents use these PascalCase keywords when referencing shared mechanics:

• Fuel, Coolant, and Electricity: underground carrier networks.
• Heat, LeakedFuel, SprinklerWater, and LeakedElectricity: surface values stored on floor cells.
• Unsafe: derived floor-cell movement state caused by dangerous surface values or value combinations.
• Step: one low-level deterministic simulation iteration.
• Pulse: the player-facing environment response after one accepted lengthy action.
• QuickAction: a player action that does not mutate the environment and does not trigger a Pulse.
• LengthyAction: a player action that mutates the environment and triggers one Pulse.
• MoveRobot: the quick action that moves the robot to an adjacent floor cell.
• InteractProp, InteractLeak, ApplyHeatShield, and ActivateReactor: player commands that can be accepted or refused by fixed rules.
• FlowProp, IsolationValveProp, ConsumerProp, JunctionProp, DoorProp, AllSeeingEyeTerminal, RemedySupplyProp, SprinklerControlProp, CoolantSprinklerValve, and ReactorControlProp: authored surface prop categories.
• PoweredProp: a prop that requires positive local Electricity flow before its interaction can take effect.
• Enabled, Disabled, Open, Closed, Supplied, Starved, and Producing: prop or service states.
• Forecast: a systemic warning generated by deterministic simulation over copied state.
• ReactorReadiness: the derived condition that allows ActivateReactor.
• Stable, Caution, Critical, Ready, Lost, and Won: derived level states.
• UnsafeEntryLoss: terminal loss caused when MoveRobot enters an Unsafe destination cell.

Action Economy

There is no action budget. Player choices are either quick or lengthy.

QuickAction commands do not mutate the environment and do not trigger a Pulse:

• MoveRobot: move the robot to an adjacent floor cell, reduce heat immunity movement steps if applicable, reject movement into walls or out of bounds, and apply UnsafeEntryLoss if the destination floor cell is Unsafe,
• selection and inspection: change only UI selection state,
• AllSeeingEyeTerminal viewing: when the robot is at an active and powered terminal, allow the player to view every surface and underground layer.

LengthyAction commands commit an intervention and immediately trigger one Pulse:

• InteractProp: toggle FlowProp state, toggle IsolationValveProp state, toggle ConsumerProp state, cycle JunctionProp ratios, open or close powered DoorProp instances, pick up RemedySupplyProp instances, toggle SprinklerControlProp state, or activate powered AllSeeingEyeTerminal access from a terminal,
• InteractLeak: repair a reachable leak or apply a matching elemental remedy,
• ApplyHeatShield: spend one heat shield and set heat immunity movement steps,
• ActivateReactor: activate a ready reactor at the current reactor control prop.

Invalid actions report refusal and do not mutate gameplay state.

DoorProp and AllSeeingEyeTerminal are PoweredProp instances. If the robot uses InteractProp on an unpowered PoweredProp, the action is accepted as a LengthyAction, changes no prop state, provides no terminal view, and still triggers one Pulse. This makes power loss an authored puzzle consequence rather than a UI refusal. Other invalid interactions remain refused and do not trigger a Pulse.

Pulses And Steps

A step is the low-level deterministic simulation iteration. One step injects leaks, resolves same-cell reactions, resolves adjacent surface flow, accumulates deltas, and clamps visible surface values.

A pulse is the player-facing environment response after an accepted lengthy action. One pulse contains a fixed balance-defined number of steps and is animated as a short cascade. The pulse length is the same for every lengthy action and must not vary by action type, forecast outcome, or current danger level.

Movement, inspection, and layer viewing do not trigger pulses. The campaign loop should not rely on a player-facing wait or fast-forward command; the puzzle is to solve cascading failures and activate the reactor as soon as a pulse leaves its needs fulfilled. Editor, debug, and automated-test tools may still advance isolated steps or pulses when needed.

Goal And Failure

Each reactor starts offline. ReactorReadiness is true and the level enters Ready when:

• every underground network present beneath the ReactorControlProp cell has positive amount and positive pressure or voltage,
• the level has the required number of Enabled and Producing Fuel consumers,
• the level has the required number of Enabled and Producing Coolant consumers,
• the level has the required number of Enabled and Producing Electricity consumers,
• Heat is below the terminal condition.

The required consumer counts are level properties. The reactor is not explicitly bound to any consumer positions.

When ReactorReadiness is true, the level shows REACTOR READY. The player wins by using ActivateReactor at the ReactorControlProp, changing the level from Ready to Won.

The level is lost when:

• Heat reaches the terminal threshold,
• MoveRobot enters an Unsafe destination floor cell without applicable protection, causing UnsafeEntryLoss,
• fixed simulation rules mark terminal failure.

Missing ReactorReadiness, including missing ReactorControlProp feed or missing required ConsumerProp production, blocks Ready but does not directly cause Lost.

Campaign Progression

The campaign grows by teaching one intervention grammar at a time. A guided tutorial may use a one-action setup to teach pulse playback, but campaign levels should not rely on a single obvious lengthy action. Every non-tutorial campaign level should present at least two plausible first interventions whose pulses create different readable consequences.

Early levels can still use one carrier, but they need a real systems choice:

• feed the service now and risk worsening a pressure-fed fault,
• isolate the damaged branch and temporarily disable a required feed or required ConsumerProp production,
• repair the leak while the root pressure remains unresolved,
• reroute or rebalance the network before restoring service.

Campaign authoring should answer two questions for each level:

• What are the plausible first lengthy actions?
• What does each resulting pulse visibly improve, worsen, or reveal?

Recommended progression:

1. Tutorial: one safe guided action may teach that lengthy actions trigger pulses.
2. Group 1: Fuel source, pressure-fed leak, IsolationValveProp, repair site, and direct ReactorReadiness.
3. Group 2: Coolant ConsumerProp production, wall-mounted CoolantSprinklerValve, pressure recovery, SprinklerWater, and Evaporation.
4. Group 3: Electricity wall leaks, powered DoorProp, and first AllSeeingEyeTerminal.
5. Group 4: Fuel + Electricity interactions where Ignite creates recurring Heat.
6. Group 5: Coolant + Electricity interactions where wet cells can Conduct.
7. Group 6: full three-network startup with fire, suppression, wet conduction, and terminal-local Forecast.

Information

The player can always inspect:

• surface terrain,
• surface props and visible prop state,
• visible leaks and repair faces,
• visible surface values and Unsafe movement cells,
• door state,
• remedy inventory and supply props,
• consumer state: disabled, starved, supplied, producing, or unknown,
• level state,
• Forecast warnings only while the robot is at an active and powered AllSeeingEyeTerminal.

Underground topology and numeric network values are available only while the robot is at an active and powered AllSeeingEyeTerminal. There is no persistent lock or unlock state in the level data.

The editor always sees and authors every layer.

Safe, caution, and critical labels are display and forecast bands derived from balance thresholds. Numeric simulation values remain authoritative.

Grid And State

Each map coordinate contains:

• one static surface terrain cell: Floor or Wall,
• zero or one underground fuel cell,
• zero or one underground coolant cell,
• zero or one underground electricity cell,
• zero or one surface prop,
• visible surface values on floor cells,
• optionally the robot, only on a floor cell.

Terrain is authored and does not change during play. Wall cells are not walkable and do not store surface hazards.

Underground cells use one structural state:

• Absent,
• Intact,
• Leaking.

Underground cells store carrier amount, pressure or voltage intensity, and structural integrity on a 0-10 scale. Max structural integrity supports the highest pressure. Non-max integrity under high pressure worsens proportionally to excess pressure. Low integrity with positive pressure creates a leak. Repairing a leak restores integrity to max.

Structural integrity is persistent authored and runtime state:

• absent cells have no meaningful structural integrity,
• newly authored present cells start at max structural integrity,
• network propagation updates amount and intensity but does not reset integrity,
• structural integrity cannot exceed max and cannot fall below zero,
• existing leaks keep their current integrity until repaired.

Same-carrier underground cells connect by inferred cardinal adjacency.

Surface floor cells store:

• leaked fuel,
• sprinkler water from coolant discharge,
• leaked electricity,
• heat,
• active elemental remedy blocks.

Simulation values use C# float. Runtime values are clamped and retain full float precision. UI shows visible values rounded to one decimal plus the safe/caution/critical band.

Level State

The derived level states are:

• Stable: no terminal path is near and required systems are not deteriorating.
• Caution: required service is missing, a consumer is starved or disabled, a hazard is growing, or reactor heat is concerning.
• Critical: forecast predicts loss without near-term intervention, or reactor heat is close to terminal.
• Ready: a reactor can be activated.
• Lost: terminal failure has occurred.
• Won: a reactor has been activated successfully.

Props

Surface prop categories:

• flow prop,
• isolation valve prop,
• consumer prop,
• junction prop,
• door prop,
• AllSeeingEyeTerminal prop,
• remedy supply prop,
• sprinkler control prop,
• coolant sprinkler valve prop,
• reactor control prop.

Props exist on floor cells. Props do not directly participate in the surface hazard pair table.

Flow Props

A flow prop is bound to fuel, coolant, or electricity. It can be Enabled or Disabled.

During network flow, an enabled flow prop injects source carrier amount and pressure or voltage into its connected underground network cell. A disabled flow prop injects nothing. Flow props are source feeders; use isolation valves for branch shutoffs so startup, shutdown, and damaged-branch isolation stay readable as separate player decisions.

Isolation Valve Props

An isolation valve prop is bound to fuel, coolant, or electricity and sits on a floor cell whose coordinate has exactly one matching underground carrier. It can be Open or Closed.

During network flow, an open isolation valve allows carrier propagation through the underground branch normally. A closed isolation valve blocks intentional network propagation across that underground cell's connected branch boundary. Closing a valve can stop pressure or voltage from reaching a damaged segment, but it can also prevent downstream ConsumerProp production, CoolantSprinklerValve discharge, or ReactorControlProp feed.

Toggling an isolation valve is a lengthy action and triggers one pulse. Inspection should make visible branch effects readable before the player commits. If the robot is at an active and powered AllSeeingEyeTerminal, systemic Forecast output should also warn about affected underground branches, isolated leaks, and downstream service loss.

Consumer Props

A consumer prop can be Enabled or Disabled.

An enabled consumer derives one service state per underground network present beneath it:

• Supplied: enough carrier and pressure or voltage reaches the underground cell.
• Starved: supply predicates fail.
• Producing: the consumer was supplied during the current pulse and emits service.

A disabled consumer consumes nothing, produces nothing, and cannot satisfy reactor readiness. A consumer on no underground layer is valid but produces no service and contributes no readiness requirement. A consumer on one underground layer consumes that service. A consumer on multiple underground layers consumes all present layers and can satisfy one requirement for each carrier that is producing.

The aggregate consumer prop still exposes a single switch state. Per-carrier service state is derived from the underground layers beneath the prop and is used by reactor readiness, forecasts, and inspection. If any consumed carrier is starved, the consumer contributes a warning for that carrier without blocking other carriers on the same prop from producing.

Reactor Control Props

A ReactorControlProp is the activation site for one reactor. ReactorReadiness is derived from level-level consumer count requirements and the networks beneath the ReactorControlProp cell.

The ReactorControlProp itself is not bound to any individual consumer. It has a local feed requirement for any underground network present beneath its cell:

• if no underground layer is present beneath the ReactorControlProp, the local ReactorControlProp feed requirement is satisfied,
• if one or more underground layers are present, every present layer must have positive amount and positive intensity after network propagation,
• a present but unfed reactor-under-network blocks ReactorReadiness but does not directly lose the level.

Level properties define RequiredFuelConsumers, RequiredCoolantConsumers, and RequiredElectricityConsumers. For each carrier, ReactorReadiness requires at least that many Enabled ConsumerProp instances whose per-carrier service state is Producing.

Junction Props

A junction prop must be on a floor cell whose coordinate has exactly one underground carrier. That carrier is the regulated network.

The engine infers incoming and outgoing branch directions from valid network topology and enabled source paths. A valid junction has one incoming branch and either two or three outgoing branches. Ambiguous junction flow is invalid. Ratio numbers are balance-defined weights that divide carrier amount and pressure or voltage. A zero-weight branch receives no intentional outflow.

Powered Props

A PoweredProp requires positive local Electricity amount and positive voltage before its authored interaction can take effect. For the approved campaign scope, only DoorProp and AllSeeingEyeTerminal are PoweredProp instances.

When the robot uses InteractProp on an unpowered PoweredProp:

• the action is accepted as a LengthyAction,
• the prop state does not change,
• an unpowered AllSeeingEyeTerminal does not reveal underground layers or Forecast output,
• one Pulse resolves normally.

The prop remains in its previous physical or active state when power is lost. This keeps power-routing consequences readable and allows levels to use wasted powered-prop interactions as deliberate risk.

Doors

A DoorProp is a PoweredProp on one floor cell. Its orientation is derived from opposing wall cells:

• north and south walls mean the door sits in an east-west corridor and blocks west/east propagation while closed,
• west and east walls mean the door sits in a north-south corridor and blocks north/south propagation while closed.

A DoorProp must have exactly one valid opposing wall pair and exactly one connected Electricity underground cell at its coordinate. The player can toggle a DoorProp only when that local Electricity feed has positive amount and positive voltage. If power is lost, the DoorProp keeps its last physical Open or Closed state. Interacting with an unpowered DoorProp changes nothing and triggers one Pulse.

Closed DoorProp instances block LeakedFuel, SprinklerWater, LeakedElectricity, and Heat propagation across the corridor cell. They do not block MoveRobot, underground network flow, source feeding, consumer supply, or hazards already present on either side.

Door blocking is evaluated by the door cell and its inferred corridor axis:

• east-west corridor DoorProp instances block surface interaction between the west neighbor, the door cell, and the east neighbor while Closed,
• north-south corridor DoorProp instances block surface interaction between the north neighbor, the door cell, and the south neighbor while Closed,
• Open DoorProp instances do not block surface interaction,
• DoorProp instances on invalid terrain, with ambiguous opposing walls, or without local Electricity are validation errors.

Sprinkler Controls And Coolant Sprinkler Valves

A SprinklerControlProp is an interactive floor prop linked to exactly one wall-mounted CoolantSprinklerValve. It can be Enabled or Disabled and does not require Electricity.

Toggling a SprinklerControlProp is a LengthyAction and triggers one Pulse. The linked CoolantSprinklerValve mirrors the control state for discharge purposes. CoolantSprinklerValve instances are not directly interactive by the robot.

A CoolantSprinklerValve is a wall-mounted surface prop that intentionally releases Coolant as SprinklerWater onto one adjacent authored floor outlet/access face. It exists to let the player trade local fire suppression for reduced Coolant service.

Valve behavior:

• the valve discharges only while its linked SprinklerControlProp is Enabled,
• an Enabled valve adds a balance-defined amount of SprinklerWater to its outlet floor cell during each Step,
• the valve must be authored on a wall cell with exactly one adjacent valid floor outlet/access face,
• the valve must be connected to a present Coolant network cell,
• the valve must be linked to exactly one SprinklerControlProp,
• discharge creates a local Coolant pressure drop and can prevent nearby or downstream ConsumerProp production or ReactorReadiness,
• disabling the linked SprinklerControlProp or closing an upstream IsolationValveProp can restore Coolant pressure on later pulses,
• discharge does not repair coolant pipe damage and does not permanently disable the Coolant network.

The local pressure drop is deterministic and spatial. It should be derived from the valve's connected Coolant network branch so that the player can understand why nearby consumers or ReactorReadiness become insufficient after sprinkler discharge.

Terminals And Supplies

An AllSeeingEyeTerminal is a PoweredProp that allows full underground inspection and Forecast viewing while the robot is at an active and powered terminal. Activating a powered terminal is a LengthyAction and triggers one Pulse; viewing is terminal-local and does not persist after the robot leaves.

Interacting with an unpowered AllSeeingEyeTerminal changes nothing, reveals no underground layers or Forecast output, and still triggers one Pulse.

Remedy supply props are single-use pickups:

• FuelRemedySupply,
• CoolantRemedySupply,
• ElectricityRemedySupply,
• HeatRemedySupply.

Each supply provides one matching inventory item and then becomes depleted.

Leaks, Sprinklers, And Remedies

Each leak stores carrier type, underground coordinate, accessible floor coordinate, and repair state.

Leaks are pressure-fed or voltage-fed faults. A leaking underground cell remains damaged until repaired, but fresh surface injection only occurs when the leaking cell currently receives positive amount and positive pressure or voltage from network propagation. Isolating a leak therefore stops new hazard growth without repairing the underlying fault. Repair removes the fault and restores structural integrity, but it does not clean hazards already on the surface.

Fuel leaks:

• occur under floor cells,
• use the same coordinate as their accessible floor coordinate,
• can be repaired or remediated by the robot standing on that floor cell.

Coolant pipe failures use the same reachable-access rules as fuel leaks for repair, but their surface output is treated as sprinkler water rather than as a generic damaging liquid. Authored puzzles should prefer coolant sprinkler valves for intentional player-triggered coolant release.

Electricity leaks:

• occur in wall cells,
• store exactly one adjacent floor cell as the emission face,
• can be repaired or remediated from that floor cell,
• emit only to that stored face.

All leaks must have valid floor access. Repair changes the underground cell from Leaking to Intact, restores structural integrity to max, and stops future injection. Repair does not clean existing surface hazards. If the repaired segment is immediately returned to excessive pressure or voltage, structural integrity rules may damage it again on later pulses.

The robot carries remedial consumables with balance-defined inventory capacity:

• FuelNeutralizer,
• CoolantNeutralizer,
• ElectricityNeutralizer,
• HeatShield.

Element neutralizers remove the matching surface element from a target floor cell or reachable leak face, then apply a temporary same-element re-entry block. They do not remove other elements, reduce heat, or repair leaks.

Heat shield gives the robot heat immunity for a balance-defined number of movement steps. It does not remove heat, block heat propagation, or protect against fuel, coolant, or electricity hazards.

Network Flow

Network flow runs independently for fuel, coolant, and electricity.

For each carrier:

1. Clear transient carrier amount and pressure or voltage.
2. Start from every enabled flow prop connected to that carrier.
3. Walk through connected intact and leaking underground cells.
4. Stop at absent cells, closed isolation valve boundaries, and disconnected topology.
5. Apply distance falloff.
6. Apply valid junction ratio weights and isolation valve branch blocking.
7. Assign each reached cell its best incoming carrier amount and best incoming pressure or voltage.
8. Clamp final values.

Multiple non-ambiguous source paths may reach the same non-junction cell; the cell uses the best carrier amount and best pressure or voltage. Junction ambiguity is a validation error.

A consumer is supplied when carrier amount, pressure or voltage, and connectivity predicates pass.

Surface Hazards

Leaking underground cells remain part of network propagation unless isolated by a closed valve.

During leak injection:

• fed fuel leaks add leaked fuel to the accessible floor cell,
• fed coolant pipe failures and CoolantSprinklerValve instances with enabled linked SprinklerControlProp instances add sprinkler water to valid floor outlet/access cells,
• fed electricity leaks add leaked electricity to the stored floor emission face,
• active matching remedy blocks prevent matching element entry.

Injection magnitude is balance data and may depend on local carrier amount, pressure, or voltage. If the target floor cell has an active matching remedy block, that matching element is not injected into the cell for that step. Remedy blocks do not block other elements or heat.

After injection and sprinkler discharge, the engine evaluates local interactions between leaked fuel, sprinkler water, leaked electricity, and heat on the same floor cell and across unblocked adjacent floor cells.

Surface interaction resolution is deterministic:

• coolant mitigation evaluates before ignition and electrical spread on each floor cell,
• same-cell interactions then evaluate every unordered quantity pair on each floor cell,
• adjacent interactions evaluate every unordered pair of adjacent floor cells once,
• same-carrier leaked fuel, sprinkler water, electricity, and heat equalize across adjacent floor cells using Flow(amount),
• wet floor cells spread electricity faster than dry floor cells,
• sprinkler water evaporates every step using ambient evaporation plus heat-driven evaporation,
• wall cells never store surface hazards and do not participate,
• closed doors and remedy blocks gate the interactions they explicitly block,
• deltas accumulate during an interaction pass and are applied together before clamping.

Unsafe Movement

Unsafe is a derived movement-safety state on floor cells. It is recalculated from current surface values after authored setup and after each Pulse.

A floor cell is Unsafe when any of these conditions are true:

• Heat is at or above the balance-defined unsafe heat threshold,
• LeakedElectricity is at or above the balance-defined unsafe electricity threshold,
• SprinklerWater and LeakedElectricity together meet the balance-defined wet-electric unsafe rule.

LeakedFuel alone is not Unsafe. It is dangerous because it can Ignite with Heat or LeakedElectricity. SprinklerWater alone is not Unsafe.

UnsafeEntryLoss occurs only when MoveRobot enters an Unsafe destination cell without applicable protection. A Pulse does not cause UnsafeEntryLoss for a robot that remains stationary on a cell that becomes Unsafe; the loss happens when the player next attempts to enter an Unsafe destination. HeatShield can protect only against Heat entry according to its configured duration. Element neutralizers can remove their matching surface element before movement, but they do not provide general immunity.

Hazard Bands And Pair Table

Balance thresholds project numeric values into safe, caution, and critical bands:

• FuelSafe, FuelCaution, FuelCritical,
• CoolantSafe, CoolantCaution, CoolantCritical,
• ElectricitySafe, ElectricityCaution, ElectricityCritical,
• HeatSafe, HeatCaution, HeatCritical.

The pair table maps projected bands to parameterized verbs:

• Hold: no direct change,
• Flow(amount): equalize a surface quantity by a balance-defined transfer amount,
• Dilute(amount): reduce fuel by a balance-defined amount,
• Warm(amount): increase heat by a balance-defined amount,
• Quench(amount): reduce heat by a balance-defined amount,
• Evaporate(amount, cooling): reduce sprinkler water and reduce heat by balance-defined amounts,
• Conduct(multiplier): spread electricity through wet floor cells faster than normal adjacent electrical flow,
• Ignite(heat, fuel): add heat and consume fuel by balance-defined amounts.

Row\Col	FuelSafe	FuelCaution	FuelCritical	CoolantSafe	CoolantCaution	CoolantCritical	ElectricitySafe	ElectricityCaution	ElectricityCritical	HeatSafe	HeatCaution	HeatCritical
FuelSafe	Hold	Flow	Flow	Hold	Dilute	Dilute	Hold	Warm	Ignite	Hold	Warm	Ignite
FuelCaution		Hold	Flow	Dilute	Dilute	Dilute	Warm	Ignite	Ignite	Warm	Ignite	Ignite
FuelCritical			Hold	Dilute	Dilute	Dilute	Ignite	Ignite	Ignite	Ignite	Ignite	Ignite
CoolantSafe				Hold	Flow	Flow	Hold	Conduct	Conduct	Hold	Quench	Quench
CoolantCaution					Hold	Flow	Conduct	Conduct	Conduct	Quench	Quench	Quench
CoolantCritical						Hold	Conduct	Conduct	Conduct	Quench	Quench	Quench
ElectricitySafe							Hold	Flow	Flow	Hold	Hold	Hold
ElectricityCaution								Hold	Flow	Hold	Hold	Hold
ElectricityCritical									Hold	Hold	Hold	Hold
HeatSafe										Hold	Flow	Flow
HeatCaution											Hold	Flow
HeatCritical												Hold

Blank lower-triangle entries mirror the corresponding upper-triangle entry.

Design rules:

• fuel becomes dangerous through electricity or heat,
• coolant is a sprinkler suppression system,
• coolant dilutes fuel before ignition is checked,
• coolant quenches heat and never directly increases heat,
• coolant becomes dangerous when electricity reaches wet cells,
• wet cells conduct electricity faster than dry cells,
• sprinkler water evaporates over time, with hot cells evaporating faster than cold cells,
• heat equalizes between neighboring floor cells,
• same-carrier leaked surface amounts equalize between neighboring floor cells,
• doors and remedy blocks gate local interactions.

Evaporation is value-based, not a fixed-duration wetness timer:

1. Every step computes evaporation from AmbientEvaporationPerStep + (surface heat * HeatEvaporationScale).
2. Evaporation is capped by the current sprinkler water amount on the cell.
3. Evaporated sprinkler water reduces heat by evaporated amount * EvaporationCoolingScale, clamped at zero heat.
4. Heat-driven evaporation can remove wetness quickly from hot cells, while ambient evaporation slowly clears cold wet cells.

Structural Integrity

Structural integrity is resolved after network propagation and before leak injection. It is deterministic and uses balancing values:

• MaxStructuralIntegrity: the maximum integrity value, 10 for the approved scale,
• StructuralIntegrityHighIntensityThreshold: the pressure or voltage threshold above which a weakened cell degrades,
• StructuralIntegrityDamageScale: difficulty-specific multiplier, initially 0.25 in Normal difficulty,
• StructuralIntegrityLeakThreshold: integrity at or below this value can become a leak when positive intensity exists.

For every present underground cell:

1. If the cell is already max integrity, high intensity does not weaken it during that pulse.
2. If integrity is below max and intensity is greater than the high threshold, integrity is reduced by (intensity - threshold) * StructuralIntegrityDamageScale.
3. Integrity is clamped to the 0-10 range.
4. If the final integrity is at or below the leak threshold and intensity is positive, the cell becomes Leaking and a LeakState is created if one does not already exist.

Automatic leak access follows the same rules as authored leaks:

• fuel leaks and coolant pipe failures use the underground cell as their floor access and can only auto-start under floor cells,
• electricity leaks require one adjacent floor access face; if multiple valid faces exist, the deterministic order is north, east, south, west,
• if no valid floor access exists, the weakened cell remains damaged but no reachable leak state is created.

Repairing a leak sets the underground cell to Intact, sets structural integrity to max, marks the leak repaired, and leaves existing surface hazards unchanged.

Fixed Rule Systems

Data-driven rule predicates and effects are not part of level data. Effects happen through fixed systems:

• player-issued lengthy interactions toggle props, cycle junctions, use inventory, open or close powered doors, repair leaks, activate terminals, and activate reactors,
• network propagation clears transient amount and intensity, then recomputes flow from enabled sources,
• consumer resolution derives per-carrier service states from present underground layers,
• structural integrity resolution weakens damaged high-pressure cells and creates leaks from low-integrity positive-pressure cells,
• leak injection and sprinkler discharge add carrier hazards or sprinkler water to valid floor access cells,
• surface interaction resolution spreads and reacts hazards according to the hazard pair table,
• robot safety resolves UnsafeEntryLoss when MoveRobot enters an Unsafe destination floor cell,
• reactor state derives readiness or terminal heat loss,
• duration advancement reduces remedy blocks and heat immunity counters,
• forecast refresh simulates copied state over the configured pulse horizon for active and powered AllSeeingEyeTerminal viewing.

Warnings are generated by fixed forecast and status systems when conditions can be proven.

Pulse And Step Order

One accepted lengthy interaction resolves one pulse in this order:

1. Apply the accepted player mutation.
2. Validate runtime state.
3. Propagate underground networks.
4. Resolve consumers and service production.
5. Resolve structural integrity and automatic leak creation.
6. Resolve the configured number of deterministic steps.
7. Derive reactor readiness and level state.
8. Preserve robot position; a Pulse does not cause UnsafeEntryLoss by itself.
9. Advance remedy blocks and heat immunity once for the pulse.
10. Refresh forecasts for active and powered AllSeeingEyeTerminal viewing.

Each step inside the pulse resolves in this order:

1. Inject leaks and sprinkler discharge fractionally for this step.
2. Resolve coolant mitigation against fuel and heat.
3. Resolve evaporation and latent cooling.
4. Evaluate same-cell surface interactions, including ignition and electrical conduction.
5. Evaluate adjacent floor interactions across unblocked door cells.
6. Accumulate and apply deltas in deterministic priority order.
7. Clamp values.

Forecasts

Forecast output is generated systemically by deterministic simulations over copied state. Forecasting does not mutate the actual level. Level data does not author bespoke forecast text.

Forecast output is visible only while the robot is at an active and powered AllSeeingEyeTerminal. Away from an active and powered terminal, the player relies on visible props, visible leaks, visible surface values, consumer state, and level state.

Forecast output includes:

• terminal loss forecasts,
• reactor ready forecasts,
• starved required consumer warnings,
• growing hazard warnings when values cross caution or critical bands,
• wet-electricity spread warnings,
• isolation valve warnings for branch shutoff, restored pressure, isolated leaks, and downstream service loss,
• coolant pressure-drop warnings from sprinkler valve use,
• structural integrity leak warnings when weakened cells are expected to leak.

Forecast timing is reported in pulses, for example Pulse +2. The forecast horizon is balance data.

Validation

The editor blocks run and save when validation errors exist. Warnings are visible and non-blocking.

Validation errors:

• invalid dimensions or cell counts,
• robot out of bounds or not on floor,
• wall cell with surface hazards,
• prop on invalid terrain,
• invalid required consumer counts,
• invalid door cell or door without local electricity,
• invalid leak access,
• invalid wall-mounted CoolantSprinklerValve outlet/access face or missing coolant network connection,
• invalid or missing SprinklerControlProp link for a CoolantSprinklerValve,
• isolation valve without exactly one matching underground carrier,
• junction without exactly one underground carrier,
• ambiguous junction flow,
• network loop or equal-source ambiguity at a junction,
• malformed required data.

Validation warnings:

• unreachable non-required consumer,
• underground cell with no source path,
• initially starved required consumer,
• initially unready reactor,
• isolation valve with no meaningful upstream/downstream distinction,
• unused remedy supply,
• sprinkler valve with no useful suppression target,
• visible hazard with no detectable nearby remedy or route.

Editor And Schema

The editor authors:

• surface terrain,
• underground fuel, coolant, and electricity cells,
• flow props,
• isolation valves,
• multi-service consumer props,
• required fuel, coolant, and electricity consumer counts,
• junction props and balance-defined ratio mode index,
• electric door props,
• wall-mounted coolant sprinkler valves and their authored outlet/access floor cells,
• sprinkler control props and their linked coolant sprinkler valves,
• AllSeeingEyeTerminal props,
• remedy supplies,
• floor leaks and electricity wall leaks with authored access faces,
• initial surface hazards, sprinkler water, and heat,
• robot start position.

The editor includes layer selection for Surface, Electricity, Fuel, and Coolant:

• Surface active: surface is full opacity, all underground layers are 25% opacity.
• Underground active: surface is 50% opacity, inactive underground layers are 25% opacity, active underground layer is full opacity.
• Coolant renders blue, fuel red, electricity yellow.
• Networks render as thick lines connecting adjacent cell centers; sources render as large centered dots.
• Tools are layer-aware. Cursor is always available. Surface terrain, props, consumers, hazards, doors, and heat tools are available only on Surface. Network painting and sources are available only on their matching underground layer.

Editor tool badges and drag previews use stable semantic image keys when assets are available. Assets may be added under Images/Badges or Images/Elements with filenames such as tool-door.png, prop-reactor.png, carrier-fuel-source.png, leak-electricity.png, or robot.png; missing assets fall back to compact procedural badges and text labels.

The serialized level schema stores level metadata, dimensions, terrain, underground layers including structural integrity, props and prop state, required reactor consumer counts, leaks, robot state, inventory, forecasts, and dynamic state when saving active play.

The loader accepts only schema-valid level data and returns clear errors for malformed data.

Balancing And Tests

Balancing defines source strengths, falloff, ratio math, isolation valve branch blocking, consumer predicates, leak magnitudes, sprinkler discharge, coolant pressure drops, evaporation, wet-electricity conduction, structural integrity thresholds and damage scale, interaction magnitudes, display thresholds, Unsafe thresholds, terminal heat thresholds, inventory capacity, remedy duration, heat immunity duration, and forecast horizon.

Tests assert behavior against configured balance values and bands. Coverage includes validation, inferred connectivity, isolation valve branch blocking, junction effects, multi-service consumer states, reactor readiness and activation, terminal loss, unsafe entry loss, heat immunity, structural integrity degradation and leak creation, pressure-fed leak injection, leak access, wall-mounted sprinkler valves, sprinkler control links, coolant pressure drops, coolant mitigation, evaporation, wet-electricity spread, remedies, powered door toggling and blocking, powered terminal access, unpowered PoweredProp no-op pulses, terminal-local forecasts, campaign authoring rules, and serialization round trips.