zfxaction26_2/docs/CAMPAIGN.md

Reactor Maintenance Campaign Design

This document prepares the handcrafted campaign for implementation. It references docs/design.md terminology directly; campaign text should not introduce mechanics that are absent from the design document.

Campaign Goals

• Teach one LengthyAction grammar at a time, then combine systems.
• Keep MoveRobot, inspection, and visible-state reading calm and free.
• Make every environment-changing action trigger exactly one Pulse.
• Keep Forecast output systemic and available only at an active AllSeeingEyeTerminal.
• Avoid treating missing ReactorReadiness as a failure state; it only blocks Ready.
• Use UnsafeEntryLoss only when MoveRobot enters an unsafe destination SurfaceHazard.
• Keep the campaign small enough for a two-week game jam.

Campaign Structure

The campaign uses one tutorial plus six groups. Group 1 intentionally has two levels; Groups 2-6 have three levels each.

Group	Levels	Networks	Main Lesson
Tutorial	1	Fuel	LengthyAction triggers Pulse; Ready then ActivateReactor wins.
1	2	Fuel	FlowProp, IsolationValveProp, reachable leaks, and direct ReactorReadiness.
2	3	Coolant	ConsumerProp, Producing, wall-mounted CoolantSprinklerValve, SprinklerWater, pressure recovery.
3	3	Electricity	wall Electricity leaks, repair faces, powered DoorProp, and AllSeeingEyeTerminal.
4	3	Fuel + Electricity	first dual-system interaction: Ignite creates recurring Heat.
5	3	Coolant + Electricity	SprinklerWater, Evaporation, and wet-electricity Conduct risk.
6	3	Fuel + Coolant + Electricity	full startup with fire, suppression, wet conduction, and terminal-local Forecast use.

Authoring Rules

Before AllSeeingEyeTerminal appears in 3-3, all levels must be readable from surface props and visible effects alone. Use simple branches, clear source positions, visible leak access, and obvious valve placement.

Every non-tutorial level must offer at least two plausible first LengthyAction choices. The later the group, the more those choices should require sequencing rather than a single obvious answer.

Do not author level-specific forecast strings. The campaign can require that systemic Forecast output is useful, but the level spec must describe the underlying state that fixed forecast rules can detect.

Each level below includes:

• Purpose: the reason the level exists.
• Setup: authored starting conditions.
• Timeline: intended reasoning and Pulse consequences.
• Win: required ReactorReadiness and ActivateReactor condition.
• Lose: terminal failure or UnsafeEntryLoss conditions.
• ImplementationNotes: content constraints for level data.

Tutorial: First Pulse

T0 - Wake The Feed

Purpose: Teach that one accepted LengthyAction triggers one Pulse, after which Ready can be activated.

Setup:

• Networks: Fuel.
• One disabled Fuel FlowProp feeds the ReactorControlProp.
• Required consumer counts are zero.
• No leaks, no SurfaceHazard, no DoorProp, no AllSeeingEyeTerminal.
• Robot starts a few floor cells away from the FlowProp.

Timeline:

1. Player uses MoveRobot and inspection freely.
2. Player uses InteractProp on the Fuel FlowProp.
3. One Pulse propagates Fuel to the ReactorControlProp.
4. Level enters Ready.
5. Player uses ActivateReactor.

Win: ReactorControlProp has positive Fuel amount and pressure, required consumer counts are zero, and ActivateReactor changes level state to Won.

Lose: No designed loss condition beyond invalid actions; this is guided tutorial content.

ImplementationNotes:

• This is the only single-action setup.
• Do not include Forecast; no AllSeeingEyeTerminal exists.

Group 1: Fuel

Group 1 teaches pressure-fed Fuel faults with no required ConsumerProp instances and no Forecast. Branches must be visually obvious from FlowProp, IsolationValveProp, leak access, and ReactorControlProp placement.

1-1 - Bleed Line

Purpose: Teach that an enabled FlowProp can both satisfy ReactorReadiness and feed a visible leak.

Setup:

• Networks: Fuel.
• One disabled Fuel FlowProp.
• One ReactorControlProp on the main branch.
• One leaking Fuel segment on a short side branch with a reachable floor access cell.
• One IsolationValveProp on the side branch before the leak.
• Required consumer counts are zero.

Timeline:

1. First choice A: enable the FlowProp; Pulse feeds the ReactorControlProp and injects LeakedFuel.
2. First choice B: close the leak-branch IsolationValveProp; Pulse prevents fresh leak injection but leaves ReactorReadiness missing until fuel is enabled.
3. Player either repairs the leak or keeps it isolated.
4. Player ensures the ReactorControlProp has positive Fuel amount and pressure.
5. Player uses ActivateReactor.

Win: ReactorReadiness is true for Fuel with zero required consumers, then ActivateReactor.

Lose: Heat terminal failure is not present; UnsafeEntryLoss occurs only if the player moves into unsafe LeakedFuel.

ImplementationNotes:

• The leak branch must be visually identifiable without underground visibility.
• Surface LeakedFuel amount should become unsafe only after a player mistake, not immediately.

1-2 - Valve Choice

Purpose: Teach branch-specific isolation versus over-isolating the main feed.

Setup:

• Networks: Fuel.
• One enabled Fuel FlowProp feeds a fork.
• One fork branch reaches the ReactorControlProp.
• The other fork branch reaches a leaking Fuel segment.
• One main IsolationValveProp before the fork.
• One leak-branch IsolationValveProp before the leaking segment.
• Required consumer counts are zero.

Timeline:

1. First choice A: close the main IsolationValveProp; Pulse stops fresh leak injection and also removes ReactorReadiness.
2. First choice B: close the leak-branch IsolationValveProp; Pulse stops fresh leak injection while preserving the main feed.
3. First choice C: repair the leak; Pulse preserves current network pressure and leaves existing LeakedFuel unchanged.
4. Player restores direct Fuel feed to the ReactorControlProp.
5. Player uses ActivateReactor.

Win: ReactorReadiness is true for Fuel with zero required consumers, then ActivateReactor.

Lose: UnsafeEntryLoss from moving into unsafe LeakedFuel; terminal failure if fixed rules mark the level Lost.

ImplementationNotes:

• Use surface labels or prop placement to distinguish main valve and leak-branch valve.
• Describe a closed main feed as missing ReactorReadiness.

Group 2: Coolant

Group 2 introduces ConsumerProp requirements and CoolantSprinklerValve pressure tradeoffs. Since Coolant alone is not a fire system yet, these levels focus on Producing consumers, SprinklerWater, Evaporation, and pressure recovery.

2-1 - Prime The Pump

Purpose: Introduce ConsumerProp as a required production checklist.

Setup:

• Networks: Coolant.
• One disabled Coolant FlowProp.
• Two visible Coolant ConsumerProp instances.
• One ReactorControlProp.
• Required consumers: one Coolant.
• One branch IsolationValveProp can cut off one consumer while leaving another consumer and the control feed available.

Timeline:

1. First choice A: enable the FlowProp; Pulse allows at least one ConsumerProp to become Producing and can make the level Ready.
2. First choice B: toggle the branch IsolationValveProp; Pulse demonstrates that consumer production depends on supply.
3. Player sets valve/source state so at least one Coolant ConsumerProp is Enabled and Producing.
4. Player uses ActivateReactor.

Win: ReactorControlProp has positive Coolant amount and pressure, at least one required Coolant ConsumerProp is Enabled and Producing, then ActivateReactor.

Lose: No designed terminal pressure; only invalid actions or explicit terminal rules.

ImplementationNotes:

• This level introduces ConsumerProp before any CoolantSprinklerValve.
• Use visible prop placement; no AllSeeingEyeTerminal.

2-2 - Sprinkler Debt

Purpose: Teach that an enabled wall-mounted CoolantSprinklerValve can reduce pressure until disabled or isolated.

Setup:

• Networks: Coolant.
• One enabled Coolant FlowProp.
• One wall-mounted CoolantSprinklerValve starts Enabled.
• The sprinkler has one adjacent floor outlet/access face and emits SprinklerWater.
• One Coolant ConsumerProp and the ReactorControlProp are on the same pressure-sensitive branch.
• Required consumers: one Coolant.
• One upstream IsolationValveProp can shut the sprinkler branch without shutting the consumer branch.

Timeline:

1. First choice A: disable the CoolantSprinklerValve; Pulse stops discharge and allows pressure recovery.
2. First choice B: close the sprinkler-branch IsolationValveProp; Pulse stops discharge by cutting supply to the sprinkler.
3. First choice C: enable/adjust the main FlowProp first if authored disabled; Pulse keeps sprinkler debt visible.
4. SprinklerWater evaporates through normal Step rules during pulses caused by useful actions.
5. Player reaches ReactorReadiness after Coolant pressure and required consumer production recover.
6. Player uses ActivateReactor.

Win: ReactorControlProp has positive Coolant amount and pressure, one Coolant ConsumerProp is Enabled and Producing, then ActivateReactor.

Lose: No authored Heat or fire; avoid loss pressure except explicit terminal rules.

ImplementationNotes:

• Do not author standalone Heat in this Coolant-only level.
• Sprinkler is wall-mounted with exactly one outlet/access floor face.
• This level visually teaches SprinklerWater and Evaporation without suppression yet.

2-3 - Split Flow

Purpose: Teach JunctionProp routing and consumer requirements in a readable Coolant network.

Setup:

• Networks: Coolant.
• One enabled Coolant FlowProp.
• One JunctionProp controls two consumer branches.
• Three visible Coolant ConsumerProp instances.
• One wall-mounted CoolantSprinklerValve starts Disabled.
• Required consumers: two Coolant.
• One branch has a weakened or leaking Coolant segment that emits SprinklerWater when fed.

Timeline:

1. First choice A: cycle the JunctionProp; Pulse changes which consumers can become Producing.
2. First choice B: close the damaged branch IsolationValveProp; Pulse stops fresh SprinklerWater injection but reduces available production paths.
3. First choice C: repair the Coolant leak; Pulse stops future leak injection but does not remove existing SprinklerWater.
4. Player configures routing so two Coolant consumers are Enabled and Producing.
5. Player uses ActivateReactor.

Win: ReactorControlProp has positive Coolant amount and pressure, two Coolant ConsumerProp instances are Enabled and Producing, then ActivateReactor.

Lose: UnsafeEntryLoss only if the player moves into an unsafe SurfaceHazard; otherwise no designed terminal pressure.

ImplementationNotes:

• Keep all relevant branches readable from surface prop placement.
• No Forecast; no AllSeeingEyeTerminal.

Group 3: Electricity

Group 3 introduces wall Electricity leaks, powered DoorProp behavior, and then AllSeeingEyeTerminal. Levels 3-1 and 3-2 must remain readable without underground visibility.

3-1 - Live Face

Purpose: Teach wall Electricity leak access and repair from the adjacent emission face.

Setup:

• Networks: Electricity.
• One disabled Electricity FlowProp.
• One wall-based Electricity leak with exactly one adjacent floor emission/repair face.
• One Electricity ConsumerProp.
• One ReactorControlProp.
• Required consumers: one Electricity.
• One IsolationValveProp can cut voltage to the leaking wall segment.

Timeline:

1. First choice A: enable the FlowProp; Pulse powers the consumer/control and emits LeakedElectricity.
2. First choice B: close the leak IsolationValveProp; Pulse prevents emission but leaves required electricity production missing until a valid powered path exists.
3. Player repairs the leak from the marked floor face or keeps it isolated if another path can satisfy readiness.
4. Player achieves Electricity consumer production and local control feed.
5. Player uses ActivateReactor.

Win: ReactorControlProp has positive Electricity amount and voltage, one Electricity ConsumerProp is Enabled and Producing, then ActivateReactor.

Lose: UnsafeEntryLoss from moving into unsafe LeakedElectricity; terminal failure if fixed rules mark Lost.

ImplementationNotes:

• Emission/repair face must be visually unambiguous.
• No Forecast; no AllSeeingEyeTerminal.

3-2 - Powered Door

Purpose: Introduce DoorProp toggling as an electricity-dependent action.

Setup:

• Networks: Electricity.
• One Electricity FlowProp feeds a DoorProp local supply branch.
• One Electricity ConsumerProp and one ReactorControlProp.
• Required consumers: one Electricity.
• One DoorProp begins Closed; it can be toggled only while its local Electricity feed is positive.
• One wall Electricity leak is positioned so the closed door blocks surface propagation across the corridor.

Timeline:

1. First choice A: power the door branch, then toggle the DoorProp; Pulse changes surface propagation boundaries.
2. First choice B: isolate or repair the wall leak first; Pulse reduces LeakedElectricity risk before opening.
3. First choice C: keep the door Closed and power the required consumer path first.
4. Player sequences powered door operation with leak management.
5. Player uses ActivateReactor.

Win: ReactorControlProp has positive Electricity amount and voltage, one Electricity ConsumerProp is Enabled and Producing, then ActivateReactor.

Lose: UnsafeEntryLoss from entering unsafe LeakedElectricity; terminal failure if fixed rules mark Lost.

ImplementationNotes:

• Use an authored wall Electricity leak for surface electricity risk.
• The door’s electric supply should be obvious from nearby surface props before terminal access exists.

3-3 - The All-Seeing Eye

Purpose: Introduce terminal-local underground visibility and systemic Forecast.

Setup:

• Networks: Electricity.
• One AllSeeingEyeTerminal in a side room.
• One route powers the required Electricity ConsumerProp; another route reaches a weakened high-voltage segment.
• One DoorProp or IsolationValveProp can change which route is used.
• Required consumers: one Electricity.

Timeline:

1. First choice A: activate the AllSeeingEyeTerminal; Pulse advances the environment and enables terminal-local underground visibility plus systemic Forecast.
2. First choice B: route power without terminal information; Pulse may power the correct path or expose visible consequences.
3. First choice C: isolate the visibly risky branch first; Pulse may preserve safety but delay required production.
4. While at the active terminal, player uses Forecast and underground visibility to choose route state.
5. Player restores required production and control feed.
6. Player uses ActivateReactor.

Win: ReactorControlProp has positive Electricity amount and voltage, one Electricity ConsumerProp is Enabled and Producing, then ActivateReactor.

Lose: UnsafeEntryLoss from unsafe LeakedElectricity, terminal Heat if generated by fixed rules, or another fixed terminal rule.

ImplementationNotes:

• This is the first campaign level with Forecast.
• Forecast output must be systemic; do not author level text.

Group 4: Fuel + Electricity

Group 4 introduces the first dual-system interaction: Fuel and Electricity can Ignite, generating recurring Heat. From this point onward, Heat is a recurring campaign problem.

4-1 - First Spark

Purpose: Teach that combining LeakedFuel and LeakedElectricity can create Heat.

Setup:

• Networks: Fuel, Electricity.
• One visible Fuel leak emits near a corridor.
• One wall Electricity leak emits toward the same corridor.
• One Fuel ConsumerProp, one Electricity ConsumerProp, and one ReactorControlProp on both networks.
• Required consumers: one Fuel, one Electricity.
• One IsolationValveProp can isolate either damaged branch.

Timeline:

1. First choice A: enable Fuel; Pulse grows LeakedFuel.
2. First choice B: enable Electricity; Pulse grows LeakedElectricity.
3. First choice C: isolate or repair one leak before both networks are active.
4. If both leaked values meet, fixed surface rules can Ignite and create Heat.
5. Player stabilizes at least one leak path, restores required production, and activates.

Win: ReactorReadiness is true for Fuel and Electricity, required consumers are Enabled and Producing, then ActivateReactor.

Lose: terminal Heat, UnsafeEntryLoss from unsafe LeakedFuel or LeakedElectricity, or fixed terminal failure.

ImplementationNotes:

• Use only designed interactions from the hazard pair table.
• Heat appears as a consequence of Ignite, not as an arbitrary authored patch.

4-2 - Break Before Make

Purpose: Teach source sequencing: fixing or isolating first can be safer than powering both networks.

Setup:

• Networks: Fuel, Electricity.
• Fuel source starts enabled and a small visible LeakedFuel patch exists.
• Electricity source starts disabled.
• One wall Electricity leak is near the fuel patch.
• One powered DoorProp can contain surface spread if operated before electricity/fuel overlap grows.
• Required consumers: one Fuel, one Electricity.

Timeline:

1. First choice A: enable Electricity; Pulse may create Heat if leaked values interact.
2. First choice B: close or open a powered DoorProp to change surface propagation before energizing.
3. First choice C: isolate or repair the Fuel leak first.
4. Player prevents or contains Ignite, then restores both required services.
5. Player uses ActivateReactor.

Win: ReactorReadiness is true for Fuel and Electricity, required consumers are Enabled and Producing, then ActivateReactor.

Lose: terminal Heat or UnsafeEntryLoss.

ImplementationNotes:

• Door mechanics are centered on electricity supply: the DoorProp can only toggle while powered.
• If an AllSeeingEyeTerminal is present, its Forecast is optional and terminal-local.

4-3 - Hot Bypass

Purpose: Combine structural integrity, route choice, and fire risk.

Setup:

• Networks: Fuel, Electricity.
• Two visible branches can satisfy each required consumer set.
• One high-voltage branch threatens structural degradation near a Fuel leak path.
• One DoorProp can contain Heat or LeakedElectricity propagation if powered and closed.
• Required consumers: one Fuel, one Electricity.
• One HeatShield supply is available for movement safety.

Timeline:

1. First choice A: route Electricity through the high-voltage branch; Pulse may create a new wall leak by fixed integrity rules.
2. First choice B: isolate the Fuel bypass; Pulse reduces ignition risk but changes available production path.
3. First choice C: pick up HeatShield; Pulse improves future movement safety but does not solve the system.
4. Player chooses one stable production route per network.
5. Player uses ActivateReactor.

Win: ReactorReadiness is true for Fuel and Electricity, required consumers are Enabled and Producing, then ActivateReactor.

Lose: terminal Heat, UnsafeEntryLoss, or fixed terminal failure.

ImplementationNotes:

• HeatShield only affects movement safety; it does not quench Heat.
• Avoid perfect cleanup requirements.

Group 5: Coolant + Electricity

Group 5 teaches that SprinklerWater is useful system material but dangerous with Electricity. Evaporation becomes important without adding a wait command.

5-1 - Charged Water

Purpose: Teach wet-electricity Conduct.

Setup:

• Networks: Coolant, Electricity.
• One wall-mounted CoolantSprinklerValve can wet a corridor.
• One wall Electricity leak emits toward that corridor.
• Required consumers: one Coolant, one Electricity.
• One IsolationValveProp can cut voltage to the leak branch.

Timeline:

1. First choice A: enable the CoolantSprinklerValve; Pulse adds SprinklerWater.
2. First choice B: isolate or repair the Electricity leak first.
3. First choice C: energize electricity production first while keeping the sprinkler disabled.
4. If LeakedElectricity reaches wet cells, fixed rules use Conduct.
5. Player restores both required services and activates.

Win: ReactorReadiness is true for Coolant and Electricity, required consumers are Enabled and Producing, then ActivateReactor.

Lose: UnsafeEntryLoss from wet-electric unsafe cells or fixed terminal failure.

ImplementationNotes:

• No authored forecast prose; terminal-local systemic Forecast may warn about wet conduction if a terminal exists.

5-2 - Dry Before Live

Purpose: Teach that Evaporation can be part of useful action sequencing.

Setup:

• Networks: Coolant, Electricity.
• Initial SprinklerWater exists on a floor route near an Electricity leak face.
• A wall-mounted CoolantSprinklerValve starts Enabled, maintaining wetness and pressure debt.
• A powered DoorProp can contain electrical surface propagation.
• Required consumers: one Coolant, one Electricity.

Timeline:

1. First choice A: disable the CoolantSprinklerValve; Pulse stops new SprinklerWater and allows Evaporation.
2. First choice B: close an upstream IsolationValveProp; Pulse cuts sprinkler supply and changes coolant pressure.
3. First choice C: power and operate the DoorProp before energizing the leak branch.
4. Player uses meaningful network actions while Evaporation reduces wetness.
5. Player energizes safely, restores both services, and activates.

Win: ReactorReadiness is true for Coolant and Electricity, required consumers are Enabled and Producing, then ActivateReactor.

Lose: UnsafeEntryLoss from wet-electric unsafe cells or fixed terminal failure.

ImplementationNotes:

• Do not add a wait or fast-forward action.
• Do not author standalone Heat; drying comes from Evaporation rules during pulses.

5-3 - Eye In The Storm

Purpose: Combine AllSeeingEyeTerminal with wet-conduction routing.

Setup:

• Networks: Coolant, Electricity.
• One AllSeeingEyeTerminal is reachable but requires a Pulse to activate.
• Two wall-mounted CoolantSprinklerValve instances affect different outlet faces.
• One Electricity route overlaps one wettable corridor underground.
• Required consumers: one Coolant, one Electricity.

Timeline:

1. First choice A: activate the AllSeeingEyeTerminal; Pulse enables terminal-local visibility and systemic Forecast.
2. First choice B: disable or isolate the nearest sprinkler without terminal information.
3. First choice C: isolate electricity before changing sprinkler state.
4. Player uses terminal-local information to avoid wet conduction and restore required production.
5. Player uses ActivateReactor.

Win: ReactorReadiness is true for Coolant and Electricity, required consumers are Enabled and Producing, then ActivateReactor.

Lose: UnsafeEntryLoss from wet-electric unsafe cells, or fixed terminal failure.

ImplementationNotes:

• Terminal should reveal why one sprinkler/electric route combination is riskier.
• Forecast remains systemic and terminal-local.

Group 6: Full Startup

Group 6 uses Fuel, Coolant, and Electricity. Heat can arise from Fuel + Electricity; CoolantSprinklerValve and SprinklerWater provide suppression while creating pressure and wet-conduction tradeoffs.

6-1 - Three-Key Start

Purpose: First all-network level with one readable problem per network.

Setup:

• Networks: Fuel, Coolant, Electricity.
• ReactorControlProp sits on all three networks.
• Required consumers: one Fuel, one Coolant, one Electricity.
• One visible Fuel leak, one enabled wall-mounted CoolantSprinklerValve, and one wall Electricity leak.
• One optional AllSeeingEyeTerminal is off the direct route.

Timeline:

1. First choice A: isolate or repair the Fuel leak.
2. First choice B: disable or isolate the CoolantSprinklerValve to restore pressure.
3. First choice C: isolate or repair the Electricity leak before wet cells conduct.
4. First choice D: activate the AllSeeingEyeTerminal for terminal-local Forecast.
5. Player restores required production for all three carriers.
6. Player uses ActivateReactor.

Win: ReactorReadiness is true for all three carriers, one required ConsumerProp per carrier is Enabled and Producing, then ActivateReactor.

Lose: terminal Heat, UnsafeEntryLoss, wet-electric terminal failure, or other fixed terminal failure.

ImplementationNotes:

• Keep this forgiving and compact.
• Do not require hazard cleanup after Ready.

6-2 - Cascade Lockout

Purpose: Require ordering because one fix can worsen another surface interaction.

Setup:

• Networks: Fuel, Coolant, Electricity.
• A Fuel leak can meet an Electricity leak and Ignite.
• A wall-mounted CoolantSprinklerValve can quench or dilute but creates SprinklerWater.
• A powered DoorProp can contain one surface spread path.
• One AllSeeingEyeTerminal is reachable.
• Required consumers: one per carrier.

Timeline:

1. First choice A: use the sprinkler to suppress/dilute; Pulse creates wet-conduction risk.
2. First choice B: isolate electricity before using sprinkler; Pulse delays electricity production.
3. First choice C: power and toggle the DoorProp to change containment.
4. First choice D: activate the AllSeeingEyeTerminal for systemic Forecast.
5. Player chooses containment, suppression, isolation, and production order.
6. Player uses ActivateReactor.

Win: ReactorReadiness is true for all three carriers, one required ConsumerProp per carrier is Enabled and Producing, then ActivateReactor.

Lose: terminal Heat, UnsafeEntryLoss, wet-electric terminal failure, or other fixed terminal failure.

ImplementationNotes:

• This is the main test of previous group lessons in one compact level.
• Door operation must depend on local Electricity supply.

6-3 - Critical Path

Purpose: Final capstone with multiple valid solution orders.

Setup:

• Networks: Fuel, Coolant, Electricity.
• ReactorControlProp sits on all three networks.
• Two ConsumerProp instances per carrier exist; one per carrier is required.
• One Fuel leak, one enabled wall-mounted CoolantSprinklerValve, one wall Electricity leak, one powered DoorProp, and one weakened structural segment.
• One AllSeeingEyeTerminal, one HeatShield, and one relevant RemedySupplyProp are available.

Timeline:

1. First choice A: activate the AllSeeingEyeTerminal; Pulse grants terminal-local topology and Forecast while hazards advance.
2. First choice B: isolate or repair the Fuel leak before Ignite.
3. First choice C: disable or isolate the sprinkler before energizing wet areas.
4. First choice D: isolate or repair electricity before using sprinkler suppression.
5. First choice E: pick up HeatShield or a RemedySupplyProp for movement/access safety.
6. Player selects a minimum viable producing consumer set and stabilizes the most terminal interaction.
7. Player uses ActivateReactor as soon as Ready appears.

Win: ReactorReadiness is true for all three carriers, one required ConsumerProp per carrier is Enabled and Producing, then ActivateReactor.

Lose: terminal Heat, UnsafeEntryLoss, wet-electric terminal failure, or other fixed terminal failure.

ImplementationNotes:

• Winning with controlled remaining hazards is valid.
• Forecast output should come only from fixed systemic rules while at the active terminal.

Implementation Checklist

• Add campaign manifest entries in this document order once level data exists.
• Use stable level names because save data and UI can reference them.
• Implement one tutorial level first, then one representative level from each group before filling every group.
• Prioritize mechanics in this order:
  1. Pulse playback and ReactorReadiness.
  2. Fuel source, leak, repair, isolation, and ActivateReactor.
  3. Coolant ConsumerProp, wall-mounted CoolantSprinklerValve, pressure drop, and Evaporation.
  4. Electricity wall leaks, UnsafeEntryLoss, powered DoorProp.
  5. AllSeeingEyeTerminal and terminal-local systemic Forecast.
  6. Ignite, Heat, Dilute, Quench, and wet-electric Conduct.
  7. Full campaign content pass.
• If scope tightens, ship tutorial, Group 1, one level each from Groups 2-5, and one final Group 6 level.

Test Expectations

Campaign implementation should add tests for:

• every level loading and validating,
• required consumer counts matching intended group mechanics,
• tutorial solvable with exactly one LengthyAction before ActivateReactor,
• every non-tutorial level exposing at least two valid first LengthyAction choices,
• win criteria reachable for each authored level,
• no level requiring a wait or fast-forward command,
• no Forecast visible away from an active AllSeeingEyeTerminal,
• no pulse-only stationary robot hazard loss,
• campaign manifest order matching this document.