Align campaign with core design rules

docs/design.md

@@ -14,21 +14,41 @@ The simulation core is built from:
 - 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 once the player reaches an all-seeing-eye terminal.
+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 `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.
+- `SurfaceHazard`: any unsafe floor-cell surface value or value combination.
+- `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`, `CoolantSprinklerValve`, and `ReactorControlProp`: authored surface prop categories.
+- `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.
 
-Quick actions do not mutate the environment and do not trigger a pulse:
+`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, and reject movement into walls or out of bounds,
+- `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,
-- all-seeing-eye viewing: when the robot is at an all-seeing-eye terminal, allow the player to view every surface and underground layer.
+- `AllSeeingEyeTerminal` viewing: when the robot is at an active terminal, allow the player to view every surface and underground layer.
 
-Lengthy actions commit an intervention and immediately trigger one pulse:
+`LengthyAction` commands commit an intervention and immediately trigger one `Pulse`:
 
-- `InteractProp`: toggle flow props, toggle isolation valves, toggle consumers, cycle junction ratios, open or close doors, pick up remedy supplies, or activate all-seeing-eye access from a terminal,
+- `InteractProp`: toggle `FlowProp` state, toggle `IsolationValveProp` state, toggle `ConsumerProp` state, cycle `JunctionProp` ratios, open or close powered `DoorProp` instances, pick up `RemedySupplyProp` instances, toggle `CoolantSprinklerValve` state, or activate `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.
@@ -45,25 +65,25 @@ Movement, inspection, and layer viewing do not trigger pulses. The campaign loop
 
 ## Goal And Failure
 
-Each reactor starts offline. A reactor becomes ready when:
+Each reactor starts offline. `ReactorReadiness` is true and the level enters `Ready` when:
 
-- every underground network present beneath the reactor control cell has positive amount and intensity,
+- every underground network present beneath the `ReactorControlProp` cell has positive amount and positive pressure or voltage,
-- the level has the required number of enabled, fed, producing fuel consumers,
+- the level has the required number of `Enabled` and `Producing` `Fuel` consumers,
-- the level has the required number of enabled, fed, producing coolant consumers,
+- the level has the required number of `Enabled` and `Producing` `Coolant` consumers,
-- the level has the required number of enabled, fed, producing electricity consumers,
+- the level has the required number of `Enabled` and `Producing` `Electricity` consumers,
-- reactor heat is below the terminal condition.
+- `Heat` is below the terminal condition.
 
 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.
+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:
 
-- reactor heat reaches the terminal threshold,
+- `Heat` reaches the terminal threshold,
-- the robot occupies an unsafe final hazard state without applicable protection,
+- `MoveRobot` enters an unsafe destination floor cell without applicable protection, causing `UnsafeEntryLoss`,
 - fixed simulation rules mark terminal failure.
 
-Consumer starvation blocks readiness but does not directly cause loss.
+Missing `ReactorReadiness`, including missing `ReactorControlProp` feed or missing required `ConsumerProp` production, blocks `Ready` but does not directly cause `Lost`.
 
 ## Campaign Progression
 
@@ -72,7 +92,7 @@ The campaign grows by teaching one intervention grammar at a time. A guided tuto
 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 starve a consumer or reactor feed,
+- 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.
 
@@ -84,10 +104,12 @@ Campaign authoring should answer two questions for each level:
 Recommended progression:
 
 1. Tutorial: one safe guided action may teach that lengthy actions trigger pulses.
-2. First campaign level: one carrier, one pressure-fed leak, one source, one isolation valve, one repair site, and reactor activation.
+2. Group 1: `Fuel` source, pressure-fed leak, `IsolationValveProp`, repair site, and direct `ReactorReadiness`.
-3. Next single-carrier levels: add routing, junction ratios, doors, or limited remedies.
+3. Group 2: `Coolant` `ConsumerProp` production, wall-mounted `CoolantSprinklerValve`, pressure recovery, `SprinklerWater`, and `Evaporation`.
-4. Mid campaign: add heat and coolant sprinkler tradeoffs.
+4. Group 3: `Electricity` wall leaks, powered `DoorProp`, and first `AllSeeingEyeTerminal`.
-5. Late campaign: add electricity, wet conduction, multi-service consumers, and full three-system cascades.
+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
 
@@ -101,9 +123,9 @@ The player can always inspect:
 - remedy inventory and supply props,
 - consumer state: disabled, starved, supplied, producing, or unknown,
 - level state,
-- forecasted warnings the simulation can prove.
+- `Forecast` warnings only while the robot is at an active `AllSeeingEyeTerminal`.
 
-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.
+Underground topology and numeric network values are available only while the robot is at an active `AllSeeingEyeTerminal`. There is no persistent lock or unlock state in the level data.
 
 The editor always sees and authors every layer.
 
@@ -171,7 +193,7 @@ Surface prop categories:
 - consumer prop,
 - junction prop,
 - door prop,
-- all-seeing-eye terminal prop,
+- `AllSeeingEyeTerminal` prop,
 - remedy supply prop,
 - coolant sprinkler valve prop,
 - reactor control prop.
@@ -188,9 +210,9 @@ During network flow, an enabled flow prop injects source carrier amount and pres
 
 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 starve downstream consumers, sprinkler valves, or reactor feed.
+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. The forecast and inspection UI should make the affected branch, isolated leak, and downstream service loss readable before the player commits.
+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 `AllSeeingEyeTerminal`, systemic `Forecast` output should also warn about affected underground branches, isolated leaks, and downstream service loss.
 
 ### Consumer Props
 
@@ -208,15 +230,15 @@ The aggregate consumer prop still exposes a single switch state. Per-carrier ser
 
 ### Reactor Control Props
 
-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.
+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 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 `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 reactor, the local reactor feed requirement is satisfied,
+- 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 starved reactor-under-network blocks readiness but does not directly lose the level.
+- 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, readiness requires at least that many enabled consumer props whose per-carrier service state is `Producing`.
+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
 
@@ -226,38 +248,41 @@ The engine infers incoming and outgoing branch directions from valid network top
 
 ### Doors
 
-A door is a prop on one floor cell. Its orientation is derived from opposing wall cells:
+A `DoorProp` is an electric prop 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 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.
+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.
+
+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 doors block surface interaction between the west neighbor, the door cell, and the east neighbor while closed,
+- east-west corridor `DoorProp` instances 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,
+- north-south corridor `DoorProp` instances block surface interaction between the north neighbor, the door cell, and the south neighbor while `Closed`,
-- open doors do not block surface interaction,
+- `Open` `DoorProp` instances do not block surface interaction,
-- door props on invalid terrain or with ambiguous opposing walls are validation errors.
+- `DoorProp` instances on invalid terrain, with ambiguous opposing walls, or without local `Electricity` are validation errors.
 
 ### Coolant Sprinkler Valves
 
-A coolant sprinkler valve is a surface prop that intentionally releases coolant as sprinkler water onto authored outlet floor cells. It exists to let the player trade local fire suppression for reduced coolant service.
+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:
 
-- activating a valve is a lengthy action and triggers one pulse,
+- toggling a valve is a `LengthyAction` and triggers one `Pulse`,
-- the valve adds a balance-defined amount of sprinkler water to each authored outlet cell,
+- an `Enabled` valve adds a balance-defined amount of `SprinklerWater` to its outlet floor cell during each `Step`,
-- every outlet must be a valid floor cell,
+- 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 connected to a present `Coolant` network cell,
-- discharge creates a local coolant pressure drop for the pulse and can starve nearby or downstream coolant consumers or the reactor feed,
+- discharge creates a local `Coolant` pressure drop and can prevent nearby or downstream `ConsumerProp` production or `ReactorReadiness`,
-- discharge does not repair coolant pipe damage and does not permanently disable the coolant network.
+- disabling the valve 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 reactor feed become insufficient after a sprinkler use.
+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 all-seeing-eye terminal allows full underground inspection when visited.
+An `AllSeeingEyeTerminal` allows full underground inspection and `Forecast` viewing while the robot is at an active terminal. Activating the terminal is a `LengthyAction` and triggers one `Pulse`; viewing is terminal-local and does not persist after the robot leaves.
 
 Remedy supply props are single-use pickups:
 
@@ -328,7 +353,7 @@ Leaking underground cells remain part of network propagation unless isolated by
 During leak injection:
 
 - fed fuel leaks add leaked fuel to the accessible floor cell,
-- fed coolant pipe failures and sprinkler valves add sprinkler water to valid floor cells,
+- fed coolant pipe failures and enabled `CoolantSprinklerValve` 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.
 
@@ -433,16 +458,16 @@ Repairing a leak sets the underground cell to `Intact`, sets structural integrit
 
 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,
+- 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 terminal loss from unsafe final hazard states after surface interactions,
+- 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.
+- forecast refresh simulates copied state over the configured pulse horizon for active `AllSeeingEyeTerminal` viewing.
 
 Warnings are generated by fixed forecast and status systems when conditions can be proven.
 
@@ -456,10 +481,10 @@ One accepted lengthy interaction resolves one pulse in this order:
 4. Resolve consumers and service production.
 5. Resolve structural integrity and automatic leak creation.
 6. Resolve the configured number of deterministic steps.
-7. Resolve robot safety from the final post-pulse hazard state.
+7. Derive reactor readiness and level state.
-8. 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.
+10. Refresh forecasts for active `AllSeeingEyeTerminal` viewing.
 
 Each step inside the pulse resolves in this order:
 
@@ -473,7 +498,9 @@ Each step inside the pulse resolves in this order:
 
 ## Forecasts
 
-Forecasts are deterministic simulations over copied state. Forecasting does not mutate the actual level.
+`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 `AllSeeingEyeTerminal`. Away from an active terminal, the player relies on visible props, visible leaks, visible surface values, consumer state, and level state.
 
 Forecast output includes:
 
@@ -482,7 +509,7 @@ Forecast output includes:
 - 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 starvation,
+- 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.
 
@@ -499,9 +526,9 @@ Validation errors:
 - wall cell with surface hazards,
 - prop on invalid terrain,
 - invalid required consumer counts,
-- invalid door cell,
+- invalid door cell or door without local electricity,
 - invalid leak access,
-- invalid coolant sprinkler valve outlet or missing coolant network connection,
+- invalid wall-mounted `CoolantSprinklerValve` outlet/access face or missing coolant network connection,
 - isolation valve without exactly one matching underground carrier,
 - junction without exactly one underground carrier,
 - ambiguous junction flow,
@@ -530,9 +557,9 @@ The editor authors:
 - multi-service consumer props,
 - required fuel, coolant, and electricity consumer counts,
 - junction props and balance-defined ratio mode index,
-- door props,
+- electric door props,
-- coolant sprinkler valves and their authored outlet cells,
+- wall-mounted coolant sprinkler valves and their authored outlet/access floor cells,
-- all-seeing-eye terminals,
+- `AllSeeingEyeTerminal` props,
 - remedy supplies,
 - floor leaks and electricity wall leaks with authored access faces,
 - initial surface hazards, sprinkler water, and heat,
@@ -554,6 +581,6 @@ The loader accepts only schema-valid level data and returns clear errors for mal
 
 ## 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, robot safety thresholds, terminal heat thresholds, inventory capacity, remedy duration, heat immunity duration, and forecast horizon.
+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-entry 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, robot hazard loss, heat immunity, structural integrity degradation and leak creation, pressure-fed leak injection, leak access, sprinkler valves, coolant pressure drops, coolant mitigation, evaporation, wet-electricity spread, remedies, door blocking, forecasts, campaign authoring rules, and serialization round trips.
+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, coolant pressure drops, coolant mitigation, evaporation, wet-electricity spread, remedies, powered door toggling and blocking, terminal-local forecasts, campaign authoring rules, and serialization round trips.