diff --git a/docs/design.md b/docs/design.md
index 4a4bac3..0b8d189 100644
--- a/docs/design.md
+++ b/docs/design.md
@@ -4,23 +4,24 @@
 
 The player controls a maintenance robot inside a failing reactor facility.
 
-The game is a deterministic, turn-based systems puzzle. The player studies a visible machine, predicts its failures, and chooses which systems to stabilize first.
+The game is a deterministic, turn-based systems puzzle. The player studies a visible machine, predicts its failures, and chooses between short-term on-site stabilization and longer-term network control.
 
 The simulation model is intentionally narrow:
 
-- a surface grid
+- a static surface grid made of walkable floor cells and blocked wall cells
 - an underground fuel network
 - an underground coolant network
 - an underground electricity network
-- surface props that connect vertically into exactly one underground network
+- surface props that expose controls, terminals, supplies, doors, and repair access
+- leaks that are always reachable by the robot from a floor cell
 - a reactor that must receive fuel, cooling, and electricity support before activation
-- a diagnostic UI that exposes the current state and the next predicted changes
+- a diagnostic UI that exposes visible state, forecasts, and all underground layers only after all-seeing-eye terminal access
 
 Each turn has three phases:
 
 1. Player phase: the player spends a limited number of actions.
-2. Simulation phase: network flow, leaks, local hazards, consumers, and level state are resolved deterministically.
-3. Event phase: scheduled failures or scripted level events advance.
+2. Simulation phase: network flow, leaks, local hazards, doors, consumers, and level state are resolved deterministically.
+3. Event phase: scheduled failures, remedy durations, and scripted level events advance.
 
 The main fantasy is:
 
@@ -39,7 +40,7 @@ It should not feel:
 - hectic
 - random
 - action-heavy
-- dependent on hidden information
+- dependent on hidden information after the correct inspection tool is acquired
 
 ## Goal
 
@@ -79,17 +80,14 @@ Failure should not be instant unless the player knowingly allows a predicted cri
 
 The player has a fixed number of actions per turn, defined by balancing.
 
-Possible actions:
+Player actions are limited to:
 
-- move
-- inspect a cell or prop
-- enable or disable a flow prop
-- enable or disable a consumer prop
-- adjust a junction prop
-- repair a leaking network cell
+- move the robot
+- interact with a prop
+- interact with a leak or hazard cell
 - activate the reactor
 
-Each non-inspection action costs one action unless balancing or a level rule explicitly says otherwise. Inspection is intended to be free or cheap enough that it does not punish understanding the system.
+Each player action costs one action unless balancing or a level rule explicitly says otherwise. Passive inspection of visible information is free; all underground inspection requires all-seeing-eye access.
 
 ### 2. Simulation Phase
 
@@ -98,10 +96,12 @@ The facility updates all active systems.
 Examples:
 
 - enabled flow props inject pressure or voltage into connected underground networks
-- junctions throttle or boost pressure or voltage along branches
+- T-junction and cross-junction props split outflow by selected ratios
 - enabled consumers draw from their bound network and produce service if supplied
-- leaking underground cells emit their carrier into the surface cell above them
-- neighboring surface cells exchange leaked matter, charge, or heat through deterministic numeric rules
+- leaking fuel and coolant underground cells emit their carrier through a broken floor cell
+- leaking electricity wall cells emit sparks through their stored adjacent floor face
+- neighboring floor cells exchange leaked matter, charge, or heat through deterministic numeric rules
+- closed doors block surface hazard propagation across their edge
 - coolant lowers heat
 - electricity interacting with coolant or fuel raises heat
 
@@ -113,27 +113,39 @@ Examples:
 
 - a scripted leak starts
 - an existing leak worsens
+- an elemental remediation block expires
+- robot heat immunity expires
 - a scripted level event adds heat or disables a prop
-- a scripted cell block appears or clears
 
 Events are not hidden. The player sees upcoming failures before they happen.
 
 ## Information Design
 
-All relevant information is visible and predictable.
+All surface information is visible and predictable. Underground information is controlled by terminal access.
 
-The player can see:
+The player can always see:
 
-- the structural state of each underground network cell: absent, intact, or leaking
-- the current numeric local amount of leaked fuel, coolant, electricity, and heat
-- the UI label for each numeric value: safe, caution, or critical
-- the pressure value for fuel and coolant network cells
-- the voltage value for electricity network cells
-- whether each surface prop is enabled or disabled
-- the current mode of each junction
-- whether each consumer is supplied, starved, disabled, or producing service
+- floor and wall terrain
+- surface props and their visible states
+- visible leaks and their reachable repair faces
+- visible surface hazards on floor cells
+- door open or closed state
+- remedy inventory and supply props
+- whether each consumer is producing, starved, disabled, or unknown
 - the current global level state
-- scheduled upcoming events
+- scheduled upcoming events and warnings
+
+Before all-seeing-eye access, the player cannot freely inspect underground layers. Underground causes may be inferred from visible leaks, prop state, and forecasts, but exact underground topology and numeric network values are hidden.
+
+After interacting with an all-seeing-eye terminal prop, the player can inspect all underground layers:
+
+- underground fuel, coolant, and electricity topology
+- structural state of each underground network cell
+- carrier amount
+- pressure for fuel and coolant
+- voltage for electricity
+- junction split modes and downstream effects
+- source-to-consumer connectivity
 
 Safe, caution, and critical labels are UI and forecast labels only. They are derived from balance constants and are not authoritative simulation state. Exact numeric values and balance predicates drive simulation.
 
@@ -143,7 +155,7 @@ The question is not:
 
 It is:
 
-> "What happens if I let this pair of values interact for one more turn?"
+> "Do I spend scarce local resources now, or commit actions to fix the system that caused this?"
 
 ## Simulation Model
 
@@ -151,12 +163,15 @@ It is:
 
 Each map coordinate contains:
 
-- one surface cell
+- one static surface terrain cell: `Floor` or `Wall`
 - zero or one fuel network cell underground
 - zero or one coolant network cell underground
 - zero or one electricity network cell underground
 - zero or one surface prop
-- optionally the robot
+- zero or more visible hazard amounts on floor cells
+- optionally the robot, only on floor cells
+
+Cells cannot change between floor and wall during play. Terrain is level-authored and static.
 
 The three underground networks are disjunct. They do not share edges and do not directly interact underground.
 
@@ -165,9 +180,10 @@ Each network has:
 - its own outside-of-level source connection
 - one flow prop type on the surface
 - one consumer prop type on the surface
-- optional junction props on the surface
+- optional T-junction props on surface floor cells
+- optional cross-junction props on surface floor cells
 
-The surface prop is an abstract vertical connection to one underground cell.
+The surface prop is an abstract vertical control or access point. Junction props are the only way to regulate network flow after it leaves a source. Consumers can be toggled, but consumer toggles do not alter network outflow ratios.
 
 ### Network Semantics
 
@@ -189,35 +205,47 @@ Each underground network cell stores exact numeric values:
 - local pressure for fuel and coolant
 - local voltage for electricity
 
-Each surface cell stores exact numeric values:
+Each floor cell stores exact numeric values:
 
 - leaked fuel amount
 - leaked coolant amount
 - leaked electricity amount
 - heat amount
+- active elemental remediation blocks
 
-All numeric values use balance-defined minimum and maximum clamps. The design intentionally does not fix numeric thresholds in this document. Balancing defines source strength, consumer requirements, leak rates, junction deltas, display bands, terminal thresholds, and event magnitudes.
+The robot stores:
+
+- current floor position
+- carried remedial consumables
+- active heat-immunity duration
+
+All numeric values use balance-defined minimum and maximum clamps. The design intentionally does not fix numeric thresholds in this document. Balancing defines source strength, consumer requirements, leak rates, display bands, terminal thresholds, event magnitudes, inventory capacity, remedy block duration, and heat immunity duration.
 
 ### Why This Formalization
 
 This model keeps the simulation small enough to forecast while still creating tactical decisions:
 
+- terrain is static and readable
 - network topology is stored underground
 - pressure and voltage determine whether consumers are satisfied and how severe leaks are
-- leaked matter, charge, and heat are projected onto the surface
-- local surface interactions use deterministic numeric predicates
-- props, robot, and global level state modify or consume values before or after the local interaction pass
+- junction ratios are explicit and player-controlled
+- leaks project hazards onto reachable floor cells
+- doors provide local surface containment
+- remedies provide scarce local stabilization
+- global level state is derived after deterministic local interactions
 
 ## State Inventory
 
 ### Cell State
 
-Surface cell terrain states:
+Surface terrain states:
 
-- `Open`
-- `Blocked`
+- `Floor`: walkable, can hold the robot, props, visible hazards, fuel/coolant leaks, and repair access to electricity wall leaks.
+- `Wall`: not walkable, can hold wall-routed underground cells and electricity wall leaks.
 
-Surface hazard values:
+Terrain is static. There are no runtime events that create or clear floor/wall terrain.
+
+Surface hazard values on floor cells:
 
 - `Fuel`
 - `Coolant`
@@ -238,53 +266,90 @@ Notes:
 - `Absent` / `Intact` / `Leaking` describe the underground cell itself.
 - Numeric values describe the current simulation state.
 - Safe/caution/critical labels are derived from numeric values for UI and forecasts only.
-- A leaking underground cell injects its carrier into the surface cell above it during simulation.
+- A fuel or coolant leak injects into its own floor cell.
+- An electricity wall leak injects into its stored adjacent floor emission face.
+
+### Leak State
+
+Each leak stores:
+
+- carrier type
+- underground coordinate
+- accessible floor coordinate
+- current repair state
+
+Fuel and coolant leak rules:
+
+- may only occur when the underground leak coordinate is under a `Floor` cell
+- are visualized as broken floor revealing a burst underground pipe
+- use the same coordinate as their accessible floor coordinate
+- can be repaired or remediated by the robot standing on that floor cell
+
+Electricity leak rules:
+
+- may only occur when the underground leak coordinate is in a `Wall` cell
+- must store exactly one adjacent `Floor` cell as its accessible emission face
+- are visualized as cables hanging out of the wall and emitting sparks into the chosen floor cell
+- can be repaired or remediated by the robot from the chosen floor cell
+- do not emit to other adjacent floor cells
+
+All leaks introduce hazards to the robot through their visible floor cell. Every authored or scripted leak must have at least one accessible floor cell so the player can choose an on-site response.
 
 ### Prop State
 
-Each network has three surface prop categories:
+Surface prop categories:
 
 - flow prop
 - consumer prop
-- junction prop
+- T-junction prop
+- cross-junction prop
+- door prop
+- all-seeing-eye terminal prop
+- remedy supply prop
+- reactor control prop
 
 Flow and consumer props have two states:
 
 - `Enabled`
 - `Disabled`
 
-Junction props have three mode families:
+T-junction props split one incoming network path into two outgoing branches. Their allowed modes are:
 
-- `Neutral`: no pressure or voltage adjustment
-- `Throttle`: reduces downstream pressure or voltage by a balanceable amount
-- `Boost`: increases downstream pressure or voltage by a balanceable amount
+- `0/4`
+- `1/3`
+- `2/2`
+- `3/1`
+- `4/0`
 
-Concrete flow and consumer states:
+Cross-junction props split one incoming network path into three outgoing branches. Their allowed modes are:
 
-- `FuelFlowEnabled`
-- `FuelFlowDisabled`
-- `FuelConsumerEnabled`
-- `FuelConsumerDisabled`
-- `CoolantFlowEnabled`
-- `CoolantFlowDisabled`
-- `CoolantConsumerEnabled`
-- `CoolantConsumerDisabled`
-- `ElectricityFlowEnabled`
-- `ElectricityFlowDisabled`
-- `ElectricityConsumerEnabled`
-- `ElectricityConsumerDisabled`
+- `0/3/3`
+- `3/0/3`
+- `3/3/0`
+- `2/2/2`
 
-Concrete junction modes:
+The ratio numbers are weights, not fixed values. They divide available carrier amount plus pressure or voltage according to balance-defined ratio math. A zero-weight branch receives no intentional outflow from that junction.
 
-- `FuelJunctionNeutral`
-- `FuelJunctionThrottle`
-- `FuelJunctionBoost`
-- `CoolantJunctionNeutral`
-- `CoolantJunctionThrottle`
-- `CoolantJunctionBoost`
-- `ElectricityJunctionNeutral`
-- `ElectricityJunctionThrottle`
-- `ElectricityJunctionBoost`
+Door props have two states:
+
+- `Open`
+- `Closed`
+
+Closed doors block surface leak and heat propagation across their door edge. Closed doors do not block underground network flow.
+
+All-seeing-eye terminal props have two player states:
+
+- `Locked`: underground layer inspection is unavailable.
+- `Unlocked`: interacting with the terminal has enabled all underground layer inspection for the level.
+
+Remedy supply props are single-use typed pickups:
+
+- `FuelRemedySupply`
+- `CoolantRemedySupply`
+- `ElectricityRemedySupply`
+- `HeatRemedySupply`
+
+Each supply prop provides one fixed remedy type once. After pickup it becomes depleted.
 
 ### Consumer State
 
@@ -303,6 +368,36 @@ Required consumer mapping:
 - Coolant consumer: required for reactor cooling path.
 - Electricity consumer: required for reactor activation path.
 
+### Remedy State
+
+The robot has a small inventory for remedial consumables. Inventory capacity is balance data.
+
+Remedy types:
+
+- `FuelNeutralizer`
+- `CoolantNeutralizer`
+- `ElectricityNeutralizer`
+- `HeatShield`
+
+Element neutralizers:
+
+- are consumed when applied to a target floor cell or reachable leak face
+- remove the current matching surface element from that target
+- apply a temporary block preventing that same element from re-entering the target for a balance-defined duration
+- do not remove or block any other element
+- do not reduce heat
+- do not repair the underlying leak
+
+Heat shield:
+
+- is consumed when activated by the robot
+- makes the robot immune to heat damage for a balance-defined number of robot steps
+- does not reduce heat
+- does not block heat propagation
+- does not protect against fuel, coolant, or electricity hazards
+
+Mixed hazards require multiple remedies. For example, a floor cell containing fuel, electricity, and heat requires a fuel neutralizer, an electricity neutralizer, and heat immunity or another heat-management solution to make the robot locally safe.
+
 ### Level State
 
 The whole level has five states:
@@ -335,9 +430,9 @@ The robot has four states:
 Meaning:
 
 - `Ready`: free to move and act.
-- `Interacting`: currently spending an action on a prop, repair, or reactor activation.
+- `Interacting`: currently spending an action on a prop, leak, hazard, or reactor activation.
 - `Blocked`: the target move or action was refused because the destination or target is invalid.
-- `Damaged`: the robot entered or remained in an unresolved hazardous cell.
+- `Damaged`: the robot entered or remained in an unresolved hazardous cell without applicable protection.
 
 ## Flow Mechanic
 
@@ -355,38 +450,49 @@ The injected source amount and source pressure or voltage are balance constants.
 
 ### Propagation
 
-Carrier amount, pressure, and voltage propagate through connected intact underground cells using deterministic distance falloff.
+Carrier amount, pressure, and voltage propagate through connected intact and leaking underground cells using deterministic distance falloff and junction ratios.
 
 For each carrier network:
 
 - start from every enabled flow prop connected to that carrier
 - walk through connected `Intact` and `Leaking` cells of that carrier
-- stop at `Absent` cells and blocked or disabled source boundaries
+- stop at `Absent` cells and disconnected network topology
 - assign each reached cell the best available incoming carrier amount plus pressure or voltage
-- subtract the balance-defined amount falloff and pressure or voltage falloff for each network step from the source
-- apply junction modifications when a path crosses a junction
+- subtract balance-defined amount falloff and pressure or voltage falloff for each network step
+- divide outflow at T-junction and cross-junction props using the selected ratio mode
 - clamp final values to the balance-defined numeric range
 
-If multiple sources or paths reach the same cell, the cell uses the best resulting carrier amount and the best resulting pressure or voltage unless a level-specific rule states otherwise. This keeps routing predictable and prevents order-dependent results.
+If multiple sources or paths reach the same cell, the cell uses the best resulting carrier amount and the best resulting pressure or voltage. This keeps routing predictable and prevents order-dependent results.
 
 ### Junctions
 
-A junction is a player-toggleable local modifier for one carrier network.
+Junction props are the only flow regulation mechanism.
 
-Junction modes:
+A junction prop must be placed on a floor cell and is controlled by the robot through `InteractProp`. Its underground network cell defines the carrier it regulates.
 
-- `Neutral`: passes pressure or voltage without modification.
-- `Throttle`: reduces downstream pressure or voltage by a balanceable amount.
-- `Boost`: increases downstream pressure or voltage by a balanceable amount.
+T-junction behavior:
 
-The adjusted value affects downstream cells according to deterministic path traversal. The document intentionally does not define fixed delta numbers; balancing owns those constants.
+- one incoming branch is split into two authored outgoing branches
+- selected mode chooses the outflow ratio between those branches
+- `0/4` sends all intentional outflow to branch B
+- `4/0` sends all intentional outflow to branch A
+- intermediate modes split by weight
+
+Cross-junction behavior:
+
+- one incoming branch is split into three authored outgoing branches
+- selected mode chooses the outflow ratio between those branches
+- `0/3/3`, `3/0/3`, and `3/3/0` shut off one outgoing branch while splitting between the other two
+- `2/2/2` balances outflow across all three branches
+
+Ratio math is balance data. The intended design is readable branch commitment, not fine-grained numeric optimization.
 
 Strategic uses:
 
-- throttle a leaking branch so the leak injects less dangerous material
-- boost a long branch so a required consumer becomes supplied
-- shift risk from one network area to another when action economy is tight
-- temporarily disable a consumer to stop demand while repairing or rerouting
+- route pressure away from a leaking branch
+- feed a required consumer at the cost of starving another branch
+- reduce voltage near a sparking wall leak without disabling the source
+- create a longer-term fix that costs more commitment than spending a consumable
 
 ### Consumers
 
@@ -397,13 +503,13 @@ The consumer is supplied if all required balance predicates pass:
 - enough carrier amount reaches the bound underground cell
 - enough pressure reaches a fuel or coolant consumer
 - enough voltage reaches an electricity consumer
-- the bound network path is not isolated by a disabled source or invalid topology
+- the bound network path is not disconnected by topology or junction ratios
 
 If supplied, the consumer emits `ConsumeFromNetwork[n]`, removes or reserves the balance-defined demand amount, and produces its required service for this turn.
 
 If enabled but not supplied, the consumer emits `StarveConsumer[n]`. Starvation blocks readiness and contributes to `Caution` or forecast warnings, but it does not directly cause loss.
 
-If disabled, the consumer consumes nothing, produces nothing, does not starve, and cannot satisfy readiness.
+If disabled, the consumer consumes nothing, produces nothing, does not starve, and cannot satisfy readiness. Disabling a consumer is still useful as demand management, but it is not a flow-ratio control.
 
 ### Leaks And Flow Values
 
@@ -411,37 +517,90 @@ Pressure and voltage make leaks strategically meaningful.
 
 A leaking underground cell:
 
-- remains part of network propagation unless a future implementation explicitly introduces broken pipe states
-- emits its carrier into the surface cell above during `InjectLeak[n]`
+- remains part of network propagation while leaking
+- emits its carrier into the accessible floor cell during `InjectLeak[n]`
 - uses balance-defined leak predicates that can depend on carrier amount, pressure, or voltage
 - may inject more severe hazards when pressure or voltage is high
 
 Repairing a leak changes the underground cell from `Leaking` to `Intact` and stops future injection. It does not clean existing leaked surface fuel, coolant, electricity, or heat.
 
+Applying a matching elemental remedy does not repair the leak. It removes the matching visible hazard on the target and temporarily blocks re-entry of that same element, buying time for repair or flow regulation.
+
+## Doors And Surface Containment
+
+Doors are surface props that control local hazard spread.
+
+A door has an authored propagation edge between two floor cells. When open, surface fuel, coolant, electricity, and heat may propagate across that edge according to normal rules. When closed, those surface hazards do not propagate across that edge.
+
+Closed doors do not:
+
+- block robot movement
+- block underground network flow
+- block source feeding
+- block consumer supply
+- extinguish hazards already present on either side
+
+Door use is a short-term containment tool. It can isolate a hazardous area while the player fetches remedies, repairs a leak, or changes junction ratios.
+
+## Remediation Loop
+
+Every leak creates robot-facing hazard pressure. The player should always have two broad alternatives:
+
+- short-term localized stability by spending a consumable or heat immunity
+- long-term stability by repairing the leak, changing junction ratios, toggling consumers, or restoring required flow
+
+Remediation is intentionally element-specific.
+
+Examples:
+
+- A fuel spill can be neutralized with `FuelNeutralizer`, but any electricity already mixed into the cell remains.
+- An electrified coolant puddle needs both `CoolantNeutralizer` and `ElectricityNeutralizer` to fully clear the elemental hazard.
+- A hot leak zone can be crossed with `HeatShield`, but the heat remains dangerous after immunity expires.
+- A closed door can keep a neutralized corridor safe longer by preventing new spread from adjacent cells.
+
+Consumables are scarce by map design. Each supply prop grants one typed item once, so spending a remedy is a commitment.
+
 ## Events That Modify State
 
 `[n]` means one of the three carriers: fuel, coolant, or electricity.
 
 ### Player Actions
 
-- `Move`: spends one action to move the robot to an adjacent open surface cell. Invalid destinations emit `BlockRobot`.
-- `Inspect`: reveals or focuses already-known local state without changing simulation values.
-- `InteractFlow[n]`: spends one action to toggle a flow prop between enabled and disabled.
-- `InteractConsumer[n]`: spends one action to toggle a consumer prop between enabled and disabled.
-- `AdjustJunction[n]`: spends one action to cycle or set a junction between neutral, throttle, and boost.
-- `RepairLeak[n]`: spends one action at a reachable leaking network cell to restore it to `Intact`.
+- `MoveRobot`: spends one action to move the robot to an adjacent floor cell. Invalid destinations emit `BlockRobot`.
+- `InteractProp`: spends one action on the prop in the robot's current floor cell.
+- `InteractLeak`: spends one action to repair a leak reachable from the robot's current floor cell, apply a matching carried elemental remedy to the robot's current floor cell, or activate a carried heat shield while the robot occupies a hazardous floor cell.
 - `ActivateReactor`: spends one action at the reactor control site. It wins only if the level is `Ready`; otherwise it reports that the reactor is not ready.
 
+`InteractProp` covers:
+
+- enabling or disabling flow props
+- enabling or disabling consumer props
+- cycling or selecting T-junction ratio modes
+- cycling or selecting cross-junction ratio modes
+- opening or closing doors
+- unlocking all-seeing-eye terminal access
+- picking up a remedy from a supply prop
+
+`InteractLeak` covers:
+
+- repairing the underlying leak
+- applying `FuelNeutralizer`
+- applying `CoolantNeutralizer`
+- applying `ElectricityNeutralizer`
+
+`HeatShield` is activated through `InteractLeak` while targeting a hazardous floor cell. It consumes one action and affects the robot rather than the map cell.
+
 ### Cell And Network Events
 
-- `CreateCellBlock`: changes a surface cell from `Open` to `Blocked`. If the robot occupies the cell, the event must also emit `BlockRobot`, `DamageRobot`, or a scripted displacement event.
-- `ClearCellBlock`: changes a surface cell from `Blocked` to `Open`.
-- `StartLeak[n]`: changes an underground network cell from `Intact` to `Leaking`. It does not immediately add surface hazard unless the event explicitly also emits `InjectLeak[n]`.
+- `StartLeak[n]`: changes an underground network cell from `Intact` to `Leaking` if the leak placement rules are satisfied.
+- `RejectInvalidLeak[n]`: refuses or reports an authored/scripted leak that has no valid floor repair access.
 - `RepairLeak[n]`: changes an underground network cell from `Leaking` to `Intact`. Existing surface hazards remain.
 - `FeedFromOutside[n]`: writes source carrier amount and pressure or voltage into the connected network according to propagation rules.
-- `Equalize[n]`: moves a balance-defined amount of the same leaked surface carrier from a higher-value open cell to a lower-value adjacent open cell. It never crosses blocked edges.
-- `InjectLeak[n]`: adds a balance-defined leaked carrier amount from a leaking underground cell into the surface cell above. The amount may depend on local carrier amount, pressure, or voltage.
-- `HeatTransfer`: moves a balance-defined heat amount from a hotter open cell to a cooler adjacent open cell. It never crosses blocked edges.
+- `RouteThroughTJunction[n]`: divides outflow between two authored branches using the selected T-junction ratio.
+- `RouteThroughCrossJunction[n]`: divides outflow between three authored branches using the selected cross-junction ratio.
+- `Equalize[n]`: moves a balance-defined amount of the same leaked surface carrier from a higher-value floor cell to a lower-value adjacent floor cell unless a closed door blocks that edge.
+- `InjectLeak[n]`: adds a balance-defined leaked carrier amount from a leaking underground cell into its accessible floor cell. The amount may depend on local carrier amount, pressure, or voltage.
+- `HeatTransfer`: moves a balance-defined heat amount from a hotter floor cell to a cooler adjacent floor cell unless a closed door blocks that edge.
 - `HeatUp[1]`: increases local heat by a small balance-defined amount.
 - `HeatUp[2]`: increases local heat by a larger balance-defined amount.
 - `CoolDown[1]`: decreases local heat by a small balance-defined amount.
@@ -452,15 +611,22 @@ Repairing a leak changes the underground cell from `Leaking` to `Intact` and sto
 - `Ignite[2]`: stronger ignition event with larger balance-defined heat and fuel effects.
 - `ClampValues`: clamps all carrier, pressure, voltage, leaked surface, and heat values to balance-defined ranges.
 
-### Prop Events
+### Prop And Remedy Events
 
-- `EnableFlow[n]`: changes a flow prop from `Disabled` to `Enabled`. Its source participates in the next network propagation step.
-- `DisableFlow[n]`: changes a flow prop from `Enabled` to `Disabled`. Its source does not feed the next network propagation step.
-- `EnableConsumer[n]`: changes a consumer prop from `Disabled` to `Enabled`. It can consume, starve, and satisfy readiness during the next simulation step.
-- `DisableConsumer[n]`: changes a consumer prop from `Enabled` to `Disabled`. It stops consuming and starving, but also stops satisfying readiness.
-- `SetJunctionNeutral[n]`: sets a junction to pass pressure or voltage unchanged.
-- `SetJunctionThrottle[n]`: sets a junction to reduce downstream pressure or voltage by a balance-defined amount.
-- `SetJunctionBoost[n]`: sets a junction to increase downstream pressure or voltage by a balance-defined amount.
+- `EnableFlow[n]`: changes a flow prop from `Disabled` to `Enabled`.
+- `DisableFlow[n]`: changes a flow prop from `Enabled` to `Disabled`.
+- `EnableConsumer[n]`: changes a consumer prop from `Disabled` to `Enabled`.
+- `DisableConsumer[n]`: changes a consumer prop from `Enabled` to `Disabled`.
+- `SetTJunctionRatio[n]`: sets a T-junction to one of `0/4`, `1/3`, `2/2`, `3/1`, or `4/0`.
+- `SetCrossJunctionRatio[n]`: sets a cross-junction to one of `0/3/3`, `3/0/3`, `3/3/0`, or `2/2/2`.
+- `OpenDoor`: changes a door from `Closed` to `Open`.
+- `CloseDoor`: changes a door from `Open` to `Closed`.
+- `UnlockAllSeeingEye`: enables underground layer inspection for the level.
+- `PickUpRemedy`: consumes a typed supply prop and adds its remedy to robot inventory if capacity allows.
+- `ApplyElementRemedy[n]`: consumes a matching carried remedy, removes that surface element from the target floor cell, and applies a temporary same-element re-entry block.
+- `ApplyHeatImmunity`: consumes a heat shield and gives the robot heat immunity for a balance-defined number of steps.
+- `ExpireRemedyBlock[n]`: removes an active same-element re-entry block from a floor cell.
+- `ExpireHeatImmunity`: removes robot heat immunity when its step duration reaches zero.
 - `ConsumeFromNetwork[n]`: an enabled and supplied consumer removes or reserves demand and emits service for the turn.
 - `StarveConsumer[n]`: an enabled but unsupplied consumer emits a visible warning and blocks readiness. It does not directly emit `LoseLevel`.
 
@@ -475,12 +641,12 @@ Repairing a leak changes the underground cell from `Leaking` to `Intact` and sto
 
 ### Robot Events
 
-- `MoveRobot`: moves the robot into a valid neighboring open cell.
 - `StartInteraction`: changes `Ready` to `Interacting` for the duration of an action.
 - `FinishInteraction`: changes `Interacting` to `Ready` after the action resolves.
 - `BlockRobot`: changes `Ready` to `Blocked` for the attempted move or action, then returns to `Ready` once the refusal is reported.
-- `DamageRobot`: changes `Ready` or `Blocked` to `Damaged` when the robot occupies a cell whose final hazard values exceed robot safety predicates.
+- `DamageRobot`: changes `Ready` or `Blocked` to `Damaged` when the robot occupies a cell whose final hazard values exceed robot safety predicates and no carried or active protection applies.
 - `RecoverRobot`: changes `Damaged` or `Blocked` to `Ready` when recovery rules are satisfied.
+- `AdvanceHeatImmunityStep`: decrements robot heat immunity when the robot spends a movement step.
 
 ## Condition Table
 
@@ -509,11 +675,13 @@ Projection rules:
 
 - labels are derived from balance-defined UI thresholds
 - labels do not change stored simulation values
-- blocked cells do not participate in neighbor interaction across blocked edges
-- leaking underground cells first emit their carrier into the surface cell above them through `InjectLeak[n]`
+- wall cells do not participate as surface hazard cells
+- closed doors block surface neighbor interaction across their authored edge
+- leaks first emit their carrier into their accessible floor cell through `InjectLeak[n]`
+- active elemental remedy blocks prevent the matching element from entering the protected floor cell
 - flow props, junctions, and consumers act before the local surface interaction pass
 - level state is derived after local interactions
-- robot state is resolved after local interactions, using final local hazard values
+- robot state is resolved after local interactions, using final local hazard values and active heat immunity
 
 ## Simulation Order
 
@@ -522,19 +690,19 @@ The simulation loop for one turn is:
 1. Resolve player actions.
 2. Apply scheduled start-of-turn events that explicitly occur before flow.
 3. Apply `FeedFromOutside[n]` for every enabled flow prop.
-4. Propagate carrier amount plus pressure or voltage through each underground network using distance falloff and junction modifiers.
+4. Propagate carrier amount plus pressure or voltage through each underground network using distance falloff and junction ratios.
 5. Apply `ConsumeFromNetwork[n]` or `StarveConsumer[n]` for every enabled consumer.
-6. Apply `InjectLeak[n]` for every leaking underground cell.
-7. For every open cell, evaluate local numeric predicates between leaked surface values and heat.
-8. For every open cell, evaluate numeric predicates against its right neighbor and bottom neighbor.
+6. Apply `InjectLeak[n]` for every leaking underground cell, respecting active matching remedy blocks.
+7. For every floor cell, evaluate local numeric predicates between leaked surface values and heat.
+8. For every floor cell, evaluate numeric predicates against right and bottom floor neighbors when no closed door blocks the edge.
 9. Emit the corresponding interaction events from the condition table summary.
 10. Apply all emitted deltas in a deterministic order.
 11. Clamp all values with `ClampValues`.
-12. Update robot state from the final local surface cell it occupies.
+12. Update robot state from the final floor cell it occupies and any active heat immunity.
 13. Derive level state from required services, reactor prerequisites, forecasts, and terminal conditions.
-14. Advance scheduled turn events.
+14. Advance scheduled turn events, remedy block durations, and heat immunity duration.
 
-If multiple events modify the same value in one step, their deltas are accumulated before clamping unless a specific event states that it consumes or reserves a value earlier in the order.
+If multiple events modify the same value in one step, their deltas are accumulated before clamping unless a specific event states that it consumes, reserves, or blocks a value earlier in the order.
 
 ## Pair Event Legend
 
@@ -560,8 +728,9 @@ Design intent:
 - fuel only becomes dangerous through electricity or heat
 - coolant only becomes dangerous through electricity
 - coolant opposes heat
-- heat equalizes between neighboring cells
-- same-carrier leaked surface amounts equalize between neighboring cells
+- heat equalizes between neighboring floor cells
+- same-carrier leaked surface amounts equalize between neighboring floor cells
+- doors and active remedy blocks are local gates on these interactions
 
 ## Symmetric Pair Condition Table
 
@@ -584,7 +753,7 @@ Rows and columns are identical projected UI labels. Only the upper-right triangl
 
 ## Prop Rules
 
-Props do not appear as participants in the pair condition table. They are local vertical controls on top of the underground layers.
+Props do not appear as participants in the pair condition table. They are controls, access points, or resources on floor cells.
 
 Flow prop rule:
 
@@ -593,10 +762,10 @@ Flow prop rule:
 
 Junction prop rule:
 
-- if neutral, the prop does not change pressure or voltage
-- if throttling, it reduces downstream pressure or voltage
-- if boosting, it increases downstream pressure or voltage
-- the adjustment amount is a balance constant
+- T-junctions regulate two outgoing branch ratios
+- cross-junctions regulate three outgoing branch ratios
+- junctions are the only flow regulation controls
+- ratio math is balance data
 
 Consumer prop rule:
 
@@ -604,16 +773,38 @@ Consumer prop rule:
 - if enabled and unsupplied, it triggers `StarveConsumer[n]`
 - if disabled, it neither consumes, produces, nor starves
 - a disabled required consumer blocks readiness
+- consumer toggling changes demand but does not alter junction outflow ratios
+
+Door prop rule:
+
+- if open, surface hazards propagate normally
+- if closed, surface hazards and heat do not cross the door edge
+- closed doors do not block underground flow
+
+Terminal prop rule:
+
+- interacting with the all-seeing-eye terminal unlocks underground inspection for the level
+- no other action or prop grants full underground inspection
+
+Remedy supply prop rule:
+
+- interacting with a supply prop adds its fixed remedy type to inventory if capacity allows
+- the prop is depleted after one successful pickup
 
 ## Robot Rules
 
 The robot is intentionally simple.
 
-- The robot moves only on the surface.
-- The robot can occupy only `Open` cells.
-- A move into a blocked or forbidden cell changes the robot to `Blocked`.
-- A move into or continued presence in a cell whose final hazard values exceed robot safety predicates changes the robot to `Damaged`.
-- Interacting with a prop, repairing a leak, or activating the reactor changes the robot to `Interacting` until the action resolves.
+- The robot moves only on floor cells.
+- The robot cannot occupy wall cells.
+- The robot can interact with the prop on its current floor cell.
+- The robot can interact with fuel and coolant leaks from their broken floor cell.
+- The robot can interact with electricity wall leaks while standing on their stored floor emission face.
+- A move into a wall or forbidden cell changes the robot to `Blocked`.
+- A move into or continued presence in a cell whose final hazard values exceed robot safety predicates changes the robot to `Damaged` unless active protection applies.
+- Heat immunity prevents heat-caused robot damage while active, but it does not remove heat.
+- Elemental remedies are inventory items and must be applied intentionally.
+- Interacting with a prop, leak, hazard, or reactor changes the robot to `Interacting` until the action resolves.
 - Robot safety predicates are balance data. The design does not require them to match UI band thresholds exactly.
 
 ## Level Rules
@@ -632,15 +823,16 @@ Derivation:
 
 ## Strategic Interactions
 
-The flow mechanic should create tactical decisions without hidden information.
+The flow and remediation mechanics should create tactical decisions without hidden randomness.
 
 Examples:
 
-- A fuel leak on a high-pressure branch may be made safer by throttling the branch, but throttling may starve the fuel consumer and block readiness.
-- A distant coolant consumer may need boosted pressure, but boosting that path can make an unrepaired coolant leak produce more surface coolant.
-- An electricity boost can satisfy activation requirements while increasing the danger of nearby coolant leaks.
+- A fuel leak on a high-pressure branch can be stabilized locally with a fuel neutralizer, but the leak will remain a problem unless repaired or routed away from.
+- A coolant spill mixed with electricity requires multiple element-specific remedies, or the player can close a door and change junction ratios before entering.
+- A heat-shielded robot can cross a hot corridor for a limited number of steps, but the heat remains a continuing forecast problem.
+- A wall electricity leak can be made less dangerous by routing voltage away through a junction, or by spending an electricity neutralizer at the spark face.
+- Closing a door can protect a repaired corridor from renewed hazard spread while the player commits actions elsewhere.
 - Disabling a consumer can stop demand while the player repairs or reroutes, but it also prevents the level from becoming `Ready`.
-- Repairing a leak stops future injection, but existing leaked material remains a local problem until simulation effects disperse, cool, ignite, discharge, or otherwise resolve it.
 
 ## Design Pillars
 
@@ -650,20 +842,22 @@ The same actions in the same state always produce the same result.
 
 ### Visible Consequences
 
-The player sees exact local values, UI labels, global state, and forecasted consequences.
+The player sees exact local values, UI labels, global state, forecasted consequences, and underground state after all-seeing-eye access.
 
 ### Meaningful Tradeoffs
 
-Turning one network on may feed a required consumer while making a leak more dangerous.
+Spending a remedy provides immediate local stability once. Adjusting junctions, repairing leaks, and restoring flow provide longer-term stability but require more commitment.
 
 ### Small Formal Core
 
 The simulation should be explainable as:
 
+- static floor/wall terrain
 - underground network topology
 - numeric pressure and voltage flow
-- surface leaks
-- deterministic local interaction predicates
+- ratio-based junction routing
+- reachable leak emission
+- surface hazards gated by doors and remedies
 - derived global level state
 
 ### Extensible Later
@@ -678,13 +872,16 @@ The following values are deliberately assigned to balancing rather than fixed in
 
 - source strengths
 - pressure and voltage falloff
-- junction throttle and boost deltas
+- ratio-to-flow math
 - consumer demand predicates
 - leak injection magnitudes
 - local interaction magnitudes
 - UI safe/caution/critical thresholds
 - robot safety thresholds
 - terminal heat thresholds
+- inventory capacity
+- remedy block duration
+- heat immunity duration
 - action costs beyond the default one-action rule
 
 Implementation should expose these as balance data and tests should assert behavior against configured constants rather than hardcoded design numbers.
@@ -693,9 +890,11 @@ Implementation should expose these as balance data and tests should assert behav
 
 The design reduces the simulation to a small layered system:
 
+- static floor and wall cells
 - three disjunct underground networks
 - exact numeric carrier, pressure, voltage, leak, and heat values
-- flow, consumer, and junction props
+- flow, consumer, junction, door, terminal, and remedy props
+- reachable leak rules for floor pipe bursts and wall cable sparks
 - UI bands as labels rather than simulation truth
 - one deterministic condition table summary backed by numeric predicates
 - one derived global level state