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 and powered AllSeeingEyeTerminal.
• Avoid treating missing ReactorReadiness as a failure state; it only blocks Ready.
• Use UnsafeEntryLoss only when MoveRobot enters an Unsafe destination cell.
• 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, SprinklerControlProp, wall-mounted CoolantSprinklerValve, SprinklerWater, pressure recovery.
3	3	Electricity	wall Electricity leaks, repair faces, powered DoorProp, and powered 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-2, 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.

Do not describe numeric surface thresholds or campaign-specific formulas. Use Unsafe only as the formal movement consequence defined in docs/design.md.

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 surface hazards, 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 source startup, reactor feed, and leak isolation are separate decisions.

Setup:

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

Timeline:

1. First choice A: enable the FlowProp; Pulse feeds the open leak branch and creates visible LeakedFuel, but the closed reactor-feed valve keeps ReactorReadiness missing.
2. First choice B: open the reactor-feed IsolationValveProp; Pulse changes the route but does not create ReactorReadiness because the source is still disabled.
3. First choice C: close the leak-branch IsolationValveProp; Pulse prevents fresh leak injection but leaves the reactor unfed.
4. Player isolates or repairs the leak, enables the source, and opens the reactor-feed branch.
5. Player uses ActivateReactor.

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

Lose: Heat terminal failure is not present; LeakedFuel alone does not cause UnsafeEntryLoss.

ImplementationNotes:

• The leak branch must be visually identifiable without underground visibility.
• No first LengthyAction should make the level Ready.

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 through a closed reactor-feed IsolationValveProp.
• 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 prevents future reactor feed until reopened.
2. First choice B: close the leak-branch IsolationValveProp; Pulse stops fresh leak injection while preserving the main route.
3. First choice C: repair the leak; Pulse stops future leak injection but leaves the reactor-feed valve still closed.
4. Player opens the reactor-feed branch and keeps or restores the main feed.
5. Player uses ActivateReactor.

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

Lose: No designed UnsafeEntryLoss from LeakedFuel alone; terminal failure only if fixed rules mark the level Lost.

ImplementationNotes:

• Use surface labels or prop placement to distinguish main valve and leak-branch valve.
• The level must not begin Ready; the reactor-feed branch starts closed.

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, SprinklerControlProp, SprinklerWater, Evaporation, and pressure recovery.

2-1 - Prime The Pump

Purpose: Introduce ConsumerProp as a required production checklist.

Setup:

• Networks: Coolant.
• One enabled Coolant FlowProp.
• Two visible Coolant ConsumerProp instances:
  • one starts Enabled but is behind a closed branch IsolationValveProp, so it is not Producing,
  • one starts Disabled on a supplied branch, so it is supplied but not Producing.
• One ReactorControlProp.
• Required consumers: two Coolant.
• The ReactorControlProp is fed from the main branch.

Timeline:

1. First choice A: enable the supplied but disabled ConsumerProp; Pulse makes only that consumer Producing.
2. First choice B: open the blocked branch IsolationValveProp; Pulse supplies the already enabled consumer.
3. First choice C: close the main branch; Pulse demonstrates that consumer production depends on supply and delays readiness.
4. Player sets both consumer branches so both Coolant ConsumerProp instances are Enabled and Producing.
5. Player uses ActivateReactor.

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

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

ImplementationNotes:

• This level introduces the difference between Enabled, Supplied, and Producing 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 discharging because its linked SprinklerControlProp starts Enabled.
• One nearby SprinklerControlProp is the only direct sprinkler interaction.
• 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 linked SprinklerControlProp; 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 or adjust the required ConsumerProp first; 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 and exactly one linked SprinklerControlProp.
• 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 because its linked SprinklerControlProp 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: No designed UnsafeEntryLoss from SprinklerWater alone; 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 powered AllSeeingEyeTerminal. Level 3-1 must remain readable without underground visibility.

3-1 - Door Circuit

Purpose: Introduce DoorProp power requirements while reinforcing wall Electricity leak handling.

Setup:

• Networks: Electricity.
• One enabled Electricity FlowProp.
• One DoorProp begins Closed and its local supply branch starts blocked by an IsolationValveProp.
• One wall-based Electricity leak with exactly one adjacent floor emission/repair face.
• One Electricity ConsumerProp starts Disabled on the blocked door-supply branch.
• One ReactorControlProp is fed by the blocked door-supply branch.
• Required consumers: one Electricity.
• One IsolationValveProp can cut voltage to the leaking wall segment.

Timeline:

1. First choice A: interact with the unpowered DoorProp; Pulse resolves, the door stays Closed, and the leak can continue.
2. First choice B: open the door-supply IsolationValveProp; Pulse powers the door and keeps the leak state readable.
3. First choice C: isolate or repair the wall leak first; Pulse reduces LeakedElectricity risk before door operation.
4. Player powers and toggles the DoorProp, then restores consumer production and reactor 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.
• Door supply and leak isolation must be readable from nearby props.

3-2 - The First Eye

Purpose: Introduce powered AllSeeingEyeTerminal access and terminal-local Forecast.

Setup:

• Networks: Electricity.
• One AllSeeingEyeTerminal in a side room.
• The terminal's local supply branch starts blocked by an IsolationValveProp.
• One Electricity ConsumerProp starts Disabled on a clearly separate supplied branch.
• One ReactorControlProp starts blocked by a closed reactor-feed IsolationValveProp.
• Required consumers: one Electricity.
• One simple wall Electricity leak is visible from the surface.
• One optional DoorProp is present only if its powered state remains obvious without terminal visibility.

Timeline:

1. First choice A: interact with the unpowered AllSeeingEyeTerminal; Pulse resolves, but no underground view or Forecast appears.
2. First choice B: power the terminal branch; Pulse makes later terminal use effective.
3. First choice C: isolate or repair the visible leak first; Pulse reduces visible risk but delays terminal information.
4. Player activates the powered terminal, uses systemic Forecast, restores required production and 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 entering Unsafe LeakedElectricity; terminal failure if fixed rules mark Lost.

ImplementationNotes:

• This is the first campaign level with Forecast.
• Forecast output must be systemic; do not author level text.
• The level remains solvable from visible information, but powering the terminal should clearly improve confidence.

3-3 - Blind Grid

Purpose: Require powered AllSeeingEyeTerminal use in a complex electricity routing puzzle.

Setup:

• Networks: Electricity.
• One AllSeeingEyeTerminal starts unpowered on a branch that can be energized early.
• Two required Electricity ConsumerProp instances sit on different branches.
• One DoorProp contains surface propagation along a useful route and requires local power.
• One visible wall Electricity leak and one weakened high-voltage segment are on different possible routes.
• Required consumers: two Electricity.

Timeline:

1. First choice A: power the terminal branch; Pulse enables a later useful terminal interaction while other risks advance.
2. First choice B: interact with the unpowered terminal first; Pulse changes nothing and demonstrates the cost of missing power.
3. First choice C: route power toward visible consumers without terminal information; Pulse may feed one consumer while worsening the hidden weak route.
4. Player activates the powered terminal, reads underground topology and systemic Forecast, then chooses which branches to isolate, repair, or power.
5. Player produces both required consumers and powers the ReactorControlProp.
6. Player uses ActivateReactor.

Win: ReactorControlProp has positive Electricity amount and voltage, two Electricity ConsumerProp instances are 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 level where terminal use is essential rather than optional.
• The visible-only read should be plausible but incomplete.

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 Heat, LeakedElectricity, or wet-electric cells, 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 from Unsafe cells.

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 from Unsafe cells, 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 starts discharging because its linked SprinklerControlProp starts Enabled.
• Initial SprinklerWater is visible in a corridor between the sprinkler outlet and an electricity emission face.
• 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: disable the linked SprinklerControlProp; Pulse stops new SprinklerWater and allows pressure recovery.
2. First choice B: isolate or repair the Electricity leak first; Pulse reduces wet-conduction risk before drying.
3. First choice C: energize electricity production first; Pulse shows why wet cells and LeakedElectricity are a bad combination.
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 Unsafe wet-electric cells or fixed terminal failure.

ImplementationNotes:

• No authored forecast prose; terminal-local systemic Forecast may warn about wet conduction if a powered terminal exists.
• Do not present sprinkler activation as the intended first solution; the problem starts from an already wet corridor.

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 maintains wetness and pressure debt because its linked SprinklerControlProp starts Enabled.
• A powered DoorProp can contain electrical surface propagation.
• Required consumers: one Coolant, one Electricity.

Timeline:

1. First choice A: disable the linked SprinklerControlProp; 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 Unsafe wet-electric 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 must be powered before activation reveals Forecast.
• Two wall-mounted CoolantSprinklerValve instances affect different outlet faces through linked SprinklerControlProp instances.
• One Electricity route overlaps one wettable corridor underground.
• Required consumers: one Coolant, one Electricity.

Timeline:

1. First choice A: power the AllSeeingEyeTerminal branch; a later terminal interaction enables terminal-local visibility and systemic Forecast.
2. First choice B: disable the nearest SprinklerControlProp or isolate its coolant supply 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 Unsafe wet-electric 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 wall-mounted CoolantSprinklerValve whose linked SprinklerControlProp starts Enabled, and one wall Electricity leak.
• One optional AllSeeingEyeTerminal is off the direct route and requires positive Electricity flow.
• One HeatShield and one relevant RemedySupplyProp are available for short-term mitigation.

Timeline:

1. First choice A: isolate or repair the Fuel leak.
2. First choice B: disable the linked SprinklerControlProp or isolate the sprinkler branch to restore pressure.
3. First choice C: isolate or repair the Electricity leak before wet cells conduct.
4. First choice D: power the AllSeeingEyeTerminal branch for later terminal-local Forecast.
5. First choice E: pick up HeatShield or a RemedySupplyProp to buy access to one risky intervention.
6. Player restores required production for all three carriers.
7. 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 from Unsafe cells, wet-electric terminal failure, or other fixed terminal failure.

ImplementationNotes:

• Keep this forgiving and compact.
• Do not require hazard cleanup after Ready.
• Inventory mitigation should help with access or timing, not replace network repair and routing.

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 while its linked SprinklerControlProp is Enabled.
• A powered DoorProp can contain one surface spread path.
• One AllSeeingEyeTerminal is reachable and requires positive Electricity flow.
• Required consumers: one per carrier.

Timeline:

1. First choice A: use the SprinklerControlProp 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: power the AllSeeingEyeTerminal branch for later 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 from Unsafe cells, 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 wall-mounted CoolantSprinklerValve whose linked SprinklerControlProp starts Enabled, one wall Electricity leak, one powered DoorProp, and one weakened structural segment.
• One powered-route AllSeeingEyeTerminal, one HeatShield, and one relevant RemedySupplyProp are available.

Timeline:

1. First choice A: power the AllSeeingEyeTerminal branch; a later terminal interaction 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 the linked SprinklerControlProp 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 from Unsafe cells, 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 and powered 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, SprinklerControlProp, wall-mounted CoolantSprinklerValve, pressure drop, and Evaporation.
  4. Electricity wall leaks, UnsafeEntryLoss, powered DoorProp.
  5. Powered 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 and powered AllSeeingEyeTerminal,
• unpowered DoorProp and AllSeeingEyeTerminal interactions causing no state change while still triggering a Pulse,
• no direct interaction with CoolantSprinklerValve; sprinkler changes happen through linked SprinklerControlProp,
• no pulse-only stationary robot hazard loss,
• campaign manifest order matching this document.