Restore complete design system documentation

TASKS.md

@@ -1,9 +1,27 @@
 # Reactor Maintenance Rewrite Tasks
 
 ## Current State
+- Approved design iteration targets the simulation model, rule removal, action economy, reactor requirements, and editor layer workflow.
+- Work is proceeding on branch `design-iteration-structural-editor` in methodical commits: docs/tasks, simulation rework, editor rework, cleanup.
+- Design documentation must preserve every existing system-level rule unless a change explicitly supersedes it. Superseded sections must document the replacement behavior with equal detail.
 
 ## Completed Work
+- Created the approved implementation plan for:
+  - single multi-service consumers,
+  - count-based reactor requirements,
+  - cell-derived doors,
+  - 0-10 structural integrity,
+  - fixed automatic rule systems,
+  - quick/lengthy action economy,
+  - all-seeing-eye viewing without persistent unlocking,
+  - layer-aware editor visualization and tools.
 
 ## Current Work
+- Repair design documentation gaps before simulation implementation.
+- Rework simulation state, validation, serialization, forecasts, and tests.
+- Rework Win2D editor layer selection, rendering, tool filtering, drag behavior, and removed panels.
 
 ## Future Work
+- Add authored sample levels once the new schema stabilizes.
+- Tune structural integrity balancing after playtesting.
+- Extend UI affordances for inspecting per-carrier consumer service state.

docs/design.md

@@ -4,44 +4,57 @@
 
 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 uses a small formal core:
+The simulation core is built from:
 
-- static floor and wall terrain
-- underground fuel, coolant, and electricity networks
-- surface props for controls, terminals, supplies, doors, and reactor activation
-- reachable leaks that project hazards onto floor cells
-- explicit reactor requirements bound to consumer props
-- deterministic rule events and forecasts
+- static floor and wall terrain,
+- underground fuel, coolant, and electricity networks,
+- surface props for controls, terminals, supplies, doors, and reactor activation,
+- consumers that consume whichever underground services exist under their cell,
+- reachable leaks that project hazards 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 after the player earns the relevant diagnostic access.
+The game should feel logical, tactical, readable, and systemic. It should avoid randomness, action pressure, and hidden information once the player reaches an all-seeing-eye terminal.
 
-## Turn Structure
+## Action Economy
 
-Each turn has three phases:
+There is no per-turn action budget. Player choices are either quick or lengthy.
 
-1. Player phase: the player spends the level action budget.
-2. Simulation phase: networks, consumers, leaks, hazards, doors, robot safety, and level state resolve.
-3. Event phase: rule events, remedy block durations, and heat immunity duration advance.
+Quick actions do not mutate the level state and do not advance the simulation:
 
-The simulation advances once after the player spends or ends the turn action budget. Individual player actions do not tick the simulation.
+- `MoveRobot`: move the robot to an adjacent floor cell, reduce heat immunity movement steps if applicable, and reject movement into walls or out of bounds,
+- selection and inspection: change only UI selection state,
+- all-seeing-eye viewing: when the robot is at an all-seeing-eye terminal, allow the player to view every surface and underground layer.
+
+Lengthy actions mutate level state and immediately advance one simulation step:
+
+- `InteractProp`: toggle flow props, toggle consumers, cycle junction ratios, open or close doors, pick up remedy supplies, or activate all-seeing-eye viewing 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,
+- `Wait`: advance one simulation step without applying another player mutation.
+
+Invalid actions report refusal and do not mutate gameplay state.
 
 ## Goal And Failure
 
 Each reactor starts offline. A reactor becomes ready when:
 
-- its bound fuel consumer is enabled, supplied, and producing
-- its bound coolant consumer is enabled, supplied, and producing
-- its bound electricity consumer is enabled, supplied, and producing
-- reactor heat is below the terminal condition
+- every underground network present beneath the reactor control cell has positive amount and intensity,
+- the level has the required number of enabled, fed, producing fuel consumers,
+- the level has the required number of enabled, fed, producing coolant consumers,
+- the level has the required number of enabled, fed, producing electricity consumers,
+- reactor heat is below the terminal condition.
 
-When a reactor is ready, the level shows `REACTOR READY`. The player wins by spending an action at that reactor control site.
+The required consumer counts are level properties. The reactor is not explicitly bound to any consumer positions.
+
+When a reactor is ready, the level shows `REACTOR READY`. The player wins by activating the ready reactor at the reactor control site.
 
 The level is lost when:
 
-- reactor heat reaches the terminal threshold
-- the robot occupies an unsafe final hazard state without applicable protection
-- a rule event marks terminal failure
-- level-authored unrecoverable conditions are met
+- reactor heat reaches the terminal threshold,
+- the robot occupies an unsafe final hazard state without applicable protection,
+- fixed simulation rules mark terminal failure.
 
 Consumer starvation blocks readiness but does not directly cause loss.
 
@@ -49,17 +62,17 @@ Consumer starvation blocks readiness but does not directly cause loss.
 
 The player can always inspect:
 
-- surface terrain
-- surface props and visible prop state
-- visible leaks and repair faces
-- visible surface hazards
-- door state
-- remedy inventory and supply props
-- consumer state: disabled, starved, supplied, producing, or unknown
-- level state
-- forecasted warnings the simulation can prove
+- surface terrain,
+- surface props and visible prop state,
+- visible leaks and repair faces,
+- visible surface hazards,
+- door state,
+- remedy inventory and supply props,
+- consumer state: disabled, starved, supplied, producing, or unknown,
+- level state,
+- forecasted warnings the simulation can prove.
 
-Underground topology and numeric network values are hidden until all-seeing-eye terminal access is unlocked. With access, the player can inspect underground fuel, coolant, and electricity topology, network structural state, carrier amount, pressure or voltage, and source-to-consumer connectivity.
+Underground topology and numeric network values are available through all-seeing-eye viewing after the robot visits an all-seeing-eye terminal. There is no persistent lock or unlock state in the level data.
 
 The editor always sees and authors every layer.
 
@@ -69,31 +82,41 @@ Safe, caution, and critical labels are display and forecast bands derived from b
 
 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 hazard amounts on floor cells
-- optionally the robot, only on a floor cell
+- 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 hazard amounts 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`
+- `Absent`,
+- `Intact`,
+- `Leaking`.
 
-Underground cells store carrier amount plus pressure for fuel/coolant or voltage for electricity. Same-carrier underground cells connect by inferred cardinal adjacency.
+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
-- leaked coolant
-- leaked electricity
-- heat
-- active elemental remedy blocks
+- leaked fuel,
+- leaked coolant,
+- 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.
 
@@ -112,13 +135,13 @@ The derived level states are:
 
 Surface prop categories:
 
-- flow prop
-- consumer prop
-- junction prop
-- door prop
-- all-seeing-eye terminal prop
-- remedy supply prop
-- reactor control prop
+- flow prop,
+- consumer prop,
+- junction prop,
+- door prop,
+- all-seeing-eye terminal prop,
+- remedy supply prop,
+- reactor control prop.
 
 Props exist on floor cells. Props do not directly participate in the surface hazard pair table.
 
@@ -130,25 +153,29 @@ During network flow, an enabled flow prop injects source carrier amount and pres
 
 ### Consumer Props
 
-A consumer prop is bound to fuel, coolant, or electricity. It can be `Enabled` or `Disabled`.
+A consumer prop can be `Enabled` or `Disabled`.
 
-An enabled consumer derives one service state after network propagation:
+An enabled consumer derives one service state per underground network present beneath it:
 
-- `Supplied`: enough carrier and pressure or voltage reaches the bound underground cell.
+- `Supplied`: enough carrier and pressure or voltage reaches the underground cell.
 - `Starved`: supply predicates fail.
 - `Producing`: the consumer was supplied this simulation step and emits service.
 
-A disabled consumer consumes nothing, produces nothing, and cannot satisfy reactor readiness.
+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 reactor control prop is the activation site for one reactor. Each reactor stores required consumer bindings by grid position:
+A reactor control prop is the activation site for one reactor. Reactor readiness is derived from level-level consumer count requirements and the networks beneath the reactor control cell.
 
-- fuel consumer position
-- coolant consumer position
-- electricity consumer position
+The reactor control prop itself is not bound to any individual consumer. It is considered a local consumer for any underground network present beneath its cell:
 
-The level is invalid if any binding is missing, out of bounds, or points to the wrong prop type.
+- if no underground layer is present beneath the reactor, the local reactor 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 starved reactor-under-network blocks readiness but does not directly lose the level.
+
+Level properties define `RequiredFuelConsumers`, `RequiredCoolantConsumers`, and `RequiredElectricityConsumers`. For each carrier, readiness requires at least that many enabled consumer props whose per-carrier service state is `Producing`.
 
 ### Junction Props
 
@@ -156,25 +183,32 @@ A junction prop must be on a floor cell whose coordinate has exactly one undergr
 
 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.
 
-The gameplay UI exposes a single junction tool and cycles through balance-defined ratio presets for the inferred outgoing branch count.
-Editor commands use a verb plus parameters, so carrier-specific choices such as fuel flow or coolant flow are UI presets over one `Flow` command instead of separate simulation concepts.
-
 ### Doors
 
-A door stores one edge between two adjacent floor cells. Door states are `Open` and `Closed`.
+A door is a prop on one floor cell. Its orientation is derived from opposing wall cells:
 
-Closed doors block fuel, coolant, electricity, and heat propagation across their edge. They do not block robot movement, underground network flow, source feeding, consumer supply, or hazards already present on either side.
+- 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 door must have exactly one valid opposing wall pair. Closed doors block fuel, coolant, electricity, and heat propagation across the corridor cell. They do not block robot movement, 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 doors block surface interaction between the west neighbor, the door cell, and the east neighbor while closed,
+- north-south corridor doors block surface interaction between the north neighbor, the door cell, and the south neighbor while closed,
+- open doors do not block surface interaction,
+- door props on invalid terrain or with ambiguous opposing walls are validation errors.
 
 ### Terminals And Supplies
 
-An all-seeing-eye terminal unlocks underground inspection for the level.
+An all-seeing-eye terminal allows full underground inspection when visited.
 
 Remedy supply props are single-use pickups:
 
-- `FuelRemedySupply`
-- `CoolantRemedySupply`
-- `ElectricityRemedySupply`
-- `HeatRemedySupply`
+- `FuelRemedySupply`,
+- `CoolantRemedySupply`,
+- `ElectricityRemedySupply`,
+- `HeatRemedySupply`.
 
 Each supply provides one matching inventory item and then becomes depleted.
 
@@ -184,45 +218,30 @@ Each leak stores carrier type, underground coordinate, accessible floor coordina
 
 Fuel and coolant 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
+- 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.
 
 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
+- 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` and stops future injection. Repair does not clean existing surface hazards.
+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.
 
 The robot carries remedial consumables with balance-defined inventory capacity:
 
-- `FuelNeutralizer`
-- `CoolantNeutralizer`
-- `ElectricityNeutralizer`
-- `HeatShield`
+- `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.
 
-## Player Actions
-
-Player actions:
-
-- `MoveRobot`: move to an adjacent floor cell.
-- `InteractProp`: use the prop on the robot's current floor cell.
-- `InteractLeak`: repair a reachable leak or apply a matching elemental remedy.
-- `ApplyHeatShield`: activate a carried heat shield.
-- `ActivateReactor`: activate a ready reactor at the current reactor control prop.
-- `EndTurn`: forfeit remaining actions and run the simulation/event phases.
-
-Each valid action costs one action unless balance or level data defines otherwise. Invalid actions report refusal and do not mutate gameplay state.
-
-`InteractProp` covers flow toggles, consumer toggles, junction ratio changes, door toggles, terminal unlock, and remedy pickup.
-
 ## Network Flow
 
 Network flow runs independently for fuel, coolant, and electricity.
@@ -248,34 +267,40 @@ Leaking underground cells remain part of network propagation.
 
 During leak injection:
 
-- fuel leaks add leaked fuel to the accessible floor cell
-- coolant leaks add leaked coolant to the accessible floor cell
-- electricity leaks add leaked electricity to the stored floor emission face
-- active matching remedy blocks prevent matching element entry
+- fuel leaks add leaked fuel to the accessible floor cell,
+- coolant leaks add leaked coolant to the accessible floor cell,
+- 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.
+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, the engine evaluates local interactions between leaked fuel, leaked coolant, leaked electricity, and heat on the same floor cell and across unblocked adjacent floor cells.
 
+Surface interaction resolution is deterministic:
+
+- same-cell interactions evaluate every unordered quantity pair on each floor cell,
+- adjacent interactions evaluate every unordered pair of adjacent floor cells once,
+- same-carrier leaked fuel, coolant, electricity, and heat equalize across adjacent floor cells using `Flow(amount)`,
+- 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.
+
 ## 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`
+- `FuelSafe`, `FuelCaution`, `FuelCritical`,
+- `CoolantSafe`, `CoolantCaution`, `CoolantCritical`,
+- `ElectricitySafe`, `ElectricityCaution`, `ElectricityCritical`,
+- `HeatSafe`, `HeatCaution`, `HeatCritical`.
 
-The pair table maps projected bands to deterministic effects:
-
-- `Hold`: no direct change.
 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.
-- `Warm(amount)`: increase heat by a balance-defined amount.
-- `Quench(amount)`: reduce heat by a balance-defined amount.
-- `Short(heat, discharge)`: add heat and discharge electricity by balance-defined amounts.
+- `Hold`: no direct change,
+- `Flow(amount)`: equalize a surface quantity by a balance-defined transfer amount,
+- `Warm(amount)`: increase heat by a balance-defined amount,
+- `Quench(amount)`: reduce heat by a balance-defined amount,
+- `Short(heat, discharge)`: add heat and discharge electricity by balance-defined amounts,
 - `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 |
@@ -293,64 +318,76 @@ The pair table maps projected bands to parameterized verbs:
 | HeatCaution |  |  |  |  |  |  |  |  |  |  | Hold | Flow |
 | HeatCritical |  |  |  |  |  |  |  |  |  |  |  | Hold |
 
+Blank lower-triangle entries mirror the corresponding upper-triangle entry. Fuel and coolant do not directly react with each other; leaked coolant plus leaked fuel is `Hold` unless another pair on that cell or an adjacent cell involves heat, electricity, or same-carrier flow.
+
 Design rules:
 
-- fuel becomes dangerous through electricity or heat
-- coolant becomes dangerous through electricity
-- coolant opposes heat
-- heat equalizes between neighboring floor cells
-- same-carrier leaked surface amounts equalize between neighboring floor cells
-- doors and remedy blocks gate local interactions
+- fuel becomes dangerous through electricity or heat,
+- coolant becomes dangerous through electricity,
+- coolant opposes heat,
+- heat equalizes between neighboring floor cells,
+- same-carrier leaked surface amounts equalize between neighboring floor cells,
+- doors and remedy blocks gate local interactions.
 
-## Rule Events
+## Structural Integrity
 
-Rule events are deterministic and forecastable. Each event stores enabled state, once/repeat behavior, priority, predicates, effects, and optional forecast text. All predicates must pass for the event to trigger.
+Structural integrity is resolved after network propagation and before leak injection. It is deterministic and uses balancing values:
 
-Predicate families:
+- `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.
 
-- turn comparisons
-- level state comparisons
-- reactor readiness/loss/win comparisons
-- prop type or state at position
-- consumer service state at position
-- network value band at position
-- surface hazard band at position
-- robot position or inventory condition
-- all-seeing-eye unlocked state
+For every present underground cell:
 
-Effects:
+1. If the cell is already max integrity, high intensity does not weaken it during that step.
+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.
 
-- start a valid leak
-- worsen an existing leak
-- repair or disable a network cell
-- enable or disable a prop
-- add or remove surface hazard
-- add or remove heat
-- add or remove inventory
-- mark terminal loss
-- emit warning text
+Automatic leak access follows the same rules as authored leaks:
+
+- fuel and coolant leaks 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 doors, repair leaks, 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 adds carrier hazards to valid floor access cells,
+- surface interaction resolution spreads and reacts hazards according to the hazard pair table,
+- robot safety resolves terminal loss from unsafe final hazard states after surface interactions,
+- 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 horizon.
+
+Warnings are generated by fixed forecast and status systems when conditions can be proven.
 
 ## Simulation Order
 
-One completed turn resolves in this order:
+One lengthy interaction resolves in this order:
 
-1. Apply accepted player actions.
+1. Apply the accepted player mutation.
 2. Validate runtime state.
-3. Apply matching start-of-simulation rule events.
-4. Propagate underground networks.
-5. Resolve consumers and service production.
+3. Propagate underground networks.
+4. Resolve consumers and service production.
+5. Resolve structural integrity and automatic leak creation.
 6. Inject leaks.
 7. Evaluate same-cell surface interactions.
-8. Evaluate adjacent floor interactions across unblocked edges.
+8. Evaluate adjacent floor interactions across unblocked door cells.
 9. Accumulate and apply deltas in deterministic priority order.
 10. Clamp values.
 11. Resolve robot safety.
 12. Derive reactor readiness and level state.
-13. Apply matching end-of-turn rule events.
-14. Advance remedy blocks and heat immunity.
-15. Refresh forecasts.
-
-If multiple events modify the same value in one step, deltas accumulate and then clamp. Event priority may consume, reserve, or block a value first.
+13. Advance remedy blocks and heat immunity.
+14. Refresh forecasts.
 
 ## Forecasts
 
@@ -358,11 +395,11 @@ Forecasts are deterministic simulations over copied state. Forecasting does not
 
 Forecast output includes:
 
-- terminal loss forecasts
-- reactor ready forecasts
-- starved required consumer warnings
-- growing hazard warnings when values cross caution or critical bands
-- rule event warnings when predicates can be proven within the forecast horizon
+- terminal loss forecasts,
+- reactor ready forecasts,
+- starved required consumer warnings,
+- growing hazard warnings when values cross caution or critical bands,
+- structural integrity leak warnings when weakened cells are expected to leak.
 
 The forecast horizon is balance data.
 
@@ -372,51 +409,58 @@ The editor blocks run and save when validation errors exist. Warnings are visibl
 
 Validation errors:
 
-- invalid dimensions or cell counts
-- robot out of bounds or not on floor
-- wall cell with surface hazards
-- prop on invalid terrain
-- missing or invalid reactor consumer binding
-- invalid door edge
-- invalid leak access
-- invalid rule target
-- junction without exactly one underground carrier
-- ambiguous junction flow
-- network loop or equal-source ambiguity at a junction
-- malformed required data
+- 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,
+- invalid leak access,
+- 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
-- unused remedy supply
-- visible hazard with no detectable nearby remedy or route
+- unreachable non-required consumer,
+- underground cell with no source path,
+- initially starved required consumer,
+- initially unready reactor,
+- unused remedy supply,
+- 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 and consumer props
-- reactor controls and explicit reactor consumer bindings
-- junction props and balance-defined ratio mode index
-- door props and explicit door edges
-- all-seeing-eye terminals
-- remedy supplies
-- floor leaks and electricity wall leaks with authored access faces
-- initial surface hazards and heat
-- robot start position
-- rule events
+- surface terrain,
+- underground fuel, coolant, and electricity cells,
+- flow props,
+- multi-service consumer props,
+- required fuel, coolant, and electricity consumer counts,
+- junction props and balance-defined ratio mode index,
+- door props,
+- all-seeing-eye terminals,
+- remedy supplies,
+- floor leaks and electricity wall leaks with authored access faces,
+- initial surface hazards and heat,
+- robot start position.
 
-The serialized level schema stores level metadata, dimensions, terrain, underground layers, props and prop state, reactor bindings, leaks, doors, robot state, inventory, rule events, all-seeing-eye state, and dynamic state when saving active play.
+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.
+
+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, consumer predicates, leak magnitudes, interaction magnitudes, display thresholds, robot safety thresholds, terminal heat thresholds, inventory capacity, remedy duration, heat immunity duration, action costs, and forecast horizon.
+Balancing defines source strengths, falloff, ratio math, consumer predicates, leak magnitudes, structural integrity thresholds and damage scale, interaction magnitudes, display thresholds, robot safety 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, junction effects, consumer states, reactor readiness and activation, terminal loss, robot hazard loss, heat immunity, leak access, remedies, door blocking, rule events, forecasts, and serialization round trips.
+Tests assert behavior against configured balance values and bands. Coverage includes validation, inferred connectivity, junction effects, multi-service consumer states, reactor readiness and activation, terminal loss, robot hazard loss, heat immunity, structural integrity degradation and leak creation, leak access, remedies, door blocking, forecasts, and serialization round trips.