# 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.