Step 26.10: plan amendments and regression

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

DECISIONS.md

@@ -1973,3 +1973,8 @@ Implementation decisions not spelled out in `memory-bank/implementation-plan.md`
 - **The measured fleet starts past its first event** (`firstEventDone`), as a mid-game company is, and events start with the scenario window, so the run before it matches a no-events run.
 - **Weights retuned for the realised good share**: most bad events need belt, Jupiter, Venus or special-cargo routes, so on the long hauls the fleet flies, good events came out at 75%. Bad events that can happen anywhere (customs at Earth and Mars, flares, micrometeors, hiccups) now weigh more and the route-specific ones less; total good weight is 30%.
 - **The away scenario for the report's world reads 90%** (above 40–80%) now that the active player pays for repairs and Independent pilots don't repair; the test's median over seven worlds holds.
+
+## Step 26.10
+
+- **CR-018's completability rule is CR-019's Step 18.1** in this repo: the hull reason is recorded there as a temporary one.
+- **The game design document is left to the designer** (CR-026 §9).

memory-bank/change-requests/CR-009-ship-upgrades.md

@@ -67,6 +67,7 @@ Record these in `DECISIONS.md` and `implementation-plan.md` §0.5.
 - Set the Courier's `fuel-tanks` values so decision 0.5.50 holds (adjust the Courier's per-level bonus or cap, not the Courier's base range, and don't break any Step 3.7 range test).
 - **Test:** All upgrades validate. Every upgrade affects a stat that exists on ShipModel. Tests for decision 0.5.49 (all three inequalities). Tests for decision 0.5.50: sampling Earth–Mars distance monthly over two game years, a maxed Courier is in range on at least one sample and out of range on at least one sample; a Courier with fuel tanks at level 2 is never in range.
 - **Amended by CR-012:** Caps follow the amended 0.5.49/0.5.50 (this plan's 0.5.67/0.5.68): three more distinctness inequalities, Courier-to-Mars measured from Earth over 16 game years; the Courier's tanks are 450 % per level (Step 10L.5).
+- **Amended by CR-026:** Hull Plating is added (+1 hull rating a level, three levels, the usual costs and shop times); upgrades may add a flat amount (`flatPerLevel`) instead of a percent.
 
 ### Step 10F.2 — Sim: effective stats
 - Add a pure function that returns a ship's effective stats from its model and installed upgrade levels.

memory-bank/change-requests/CR-014-local-first.md

@@ -106,6 +106,7 @@ Record these in `DECISIONS.md` and `implementation-plan.md` §0.5.
 - Resolve due dispatches, rest endings, and shop completions on load, when the app resumes (Capacitor `resume`, browser `visibilitychange`), and every 5 seconds while open. Uses the same idempotent resolution as Step 6.1.
 - **Test:** A dispatch whose arrival passed while the app was closed is resolved exactly once on load. Running the loop twice in a row changes nothing the second time. "While you were away" summaries appear as before.
 - **Amended by CR-021:** The loop (and every command) runs the event-queue catch-up: arrivals, each at its own time, and Independent pilots' decisions, in time order, at most 7 days, in chunks with a progress hook (Step 21.4).
+- **Amended by CR-026:** The loop and catch-up also settle trip events in time order, before anything else at the same moment: automatic events when they fire, radio calls with their default when the window closes unanswered.
 
 ### Step 10K.7 — Switch the client to the engine
 - The typed API client calls engine commands instead of HTTP. TanStack Query keeps working with engine calls as its query and mutation functions. Remove the server-time sync (Step 8.3); use the engine clock.
@@ -120,6 +121,7 @@ Record these in `DECISIONS.md` and `implementation-plan.md` §0.5.
 - Ask for permission right after the deal is accepted. Add a **Notifications** on/off toggle to Settings (CR-008 left this out because push didn't exist).
 - **Test:** With a mocked plugin: dispatching schedules one notification at the arrival time; two arrivals in the same minute produce one combined notification; starting a new company cancels all scheduled notifications; with the toggle off, nothing is scheduled. On web, the no-op scheduler is used and nothing errors.
 - **Amended by CR-024:** The scheduler also plans one notification at the fleet's sleep time ("Your pilots are waiting for orders."), while some pilot is Independent; each manual decision moves it.
+- **Amended by CR-026:** The scheduler also plans each radio call on a trip the player sent, at its fire time ("Debris field ahead — Rosa needs a call.").
 
 ### Step 10K.10 — Settings changes
 - Replace the backup code (CR-008 Steps 10H.8–10H.9) with **Export save** (shows the code with Copy and Share as file) and **Import save** (paste or open a file, then confirm). Keep the import warning about replacing the current company.

memory-bank/change-requests/CR-019-completable-boards.md

@@ -80,6 +80,7 @@ Record these in `DECISIONS.md` and `implementation-plan.md` §0.5, using the nex
 - Add a pure function: given a contract and a list of ship-and-pilot capability snapshots (effective stats, landing class, skills, location), return whether any pair can complete it and, per pair, the first failing permanent check.
 - Add a function that builds the qualifying fleet for a location per §2.
 - **Test:** One test per permanent check, each with a pair that fails only that check. A job is completable if any one pair passes. Resting, in-shop, low-fuel, and no-credit states don't change the result. A location with no ships returns the whole fleet as qualifying.
+- **Amended by CR-026:** A hull below 50% can't take Dangerous cargo, but that's a temporary reason (`hull-too-damaged`), not a permanent check: boards don't hide those jobs.
 
 ### Step 18.2 — Sim: generation keeps only completable jobs
 - The board generator takes the qualifying fleet snapshot and keeps only completable candidates, up to the board size or the attempt limit. First-contact candidates are filtered the same way.

memory-bank/change-requests/CR-021-independent-pilots.md

@@ -135,6 +135,7 @@ Removes "automation / standing routes and auto-accept rules" from the deferred l
 - Cap catch-up at 7 days; process in chunks with a progress indicator hook.
 - **Test:** Determinism: from the same save, catching up 8 hours in one go and in eight 1-hour pieces gives identical saves. Two Independent pilots at the same location never take the same contract; the one whose decision comes first (then lower pilot id) gets it. A pilot over the duty limit rests on arrival and resumes after rest. Catch-up past 7 days stops at 7 days. No pilot is ever dispatched in a way that fails normal validation.
 - **Amended by CR-024:** Independent pilots start no new work at or after the fleet's sleep time (the last manual decision plus the threshold); arrivals, rest and shop ends still resolve, and the next manual decision wakes them from that moment.
+- **Amended by CR-026:** Independent pilots' trips get the same events, radio calls and defaults; the player can answer their calls too.
 
 ### Step 19.5 — Engine: live play
 - While the app is open, the loop runs pilot decisions in real time. Add a client-to-engine signal for the contract currently open in the detail view; pilots skip it.

memory-bank/change-requests/CR-024-fleet-sleep.md

@@ -57,6 +57,7 @@ Record these in `DECISIONS.md` and `implementation-plan.md` §0.5, using the nex
 - **Test:** Config validates. A new company starts with the last manual decision time set to its creation and the default threshold. An older save migrates as described.
 
 ### Step 22.2 — Engine: manual decision flag
+- **Amended by CR-026:** Answering a radio call (`answerRadioCall`) and repairing a ship (`repairShip`) are manual decisions.
 
 - Add a "manual decision" flag to every command in the command catalog per §2. Running a flagged command updates the last manual decision time.
 - **Test:** A catalog test fails if any command is missing the flag. Dispatching updates the time; changing a display preference or exporting a save doesn't. Commands run by Independent pilots (CR-019) never update it.

memory-bank/change-requests/CR-025-short-away-summary.md

@@ -81,6 +81,7 @@ Record these in `DECISIONS.md` and `implementation-plan.md` §0.5, using the nex
 - **Test:** Each event type creates one entry with the right fields. Entries older than 7 days are pruned; newer ones remain. Catch-up and live play produce the same entries.
 
 ### Step 23.2 — Sim: summary builder
+- **Amended by CR-026:** Events are logbook entries; good ones and any that hurt a hull are highlights just below level-ups, and a short absence lists its trips' events (not counted towards the 3).
 
 - A pure function that turns the entries for an absence into: duration, totals, up to 3 highlights in priority order with an overflow count, up to 5 pilot lines sorted by net profit with an overflow line, the idle-pilots line, and the "short absence" direct list when there are 3 events or fewer.
 - **Test:** With 50 pilots' worth of entries, the result has exactly 5 pilot lines and an overflow line whose totals equal the rest. Highlights follow the priority order and cap at 3 with the right overflow count. Totals equal the sum of entries. With 2 events, the result is the direct list. Net matches the delivery-summary calculation.

memory-bank/implementation-plan.md

@@ -36,7 +36,7 @@ This plan covers the **base game only**: the core loop of taking contracts, disp
 
 ### 0.3 Explicitly deferred (do NOT build)
 
-Random events, reputation, fuel price drift and depot shortages *(CR-015: fixed per-location prices are in, decision 0.5.96)*, fuel storage at HQ bays, throttle setting, multi-leg routes, recurring bay rent, pilot salaries over time, pilot poaching, ~~automation/standing routes~~ *(CR-021: Independent pilots are in; standing orders, pilot traits, decision events and a hiring market stay deferred)*, interstellar, push notifications, Capacitor builds, Hardened landing class, surface Io and Venus's surface *(CR-016 added Venus Cloud City and Io Sulfur Works, which need no Hardened ships)*, asteroid-belt hazards, mining claims and belt events *(CR-016's belt is visual only)*, Fragile/Urgent/Fuel-efficiency skills, social features, monetization, account linking (email, Apple, Google sign-in) *(CR-011)*.
+~~Random events~~ *(CR-026: random events, radio calls and hull condition are in, decisions 0.5.143–0.5.152)*, reputation, fuel price drift and depot shortages *(CR-015: fixed per-location prices are in, decision 0.5.96)*, fuel storage at HQ bays, throttle setting, multi-leg routes, recurring bay rent, pilot salaries over time, pilot poaching, ~~automation/standing routes~~ *(CR-021: Independent pilots are in; standing orders, pilot traits, decision events and a hiring market stay deferred)*, interstellar, push notifications, Capacitor builds, Hardened landing class, surface Io and Venus's surface *(CR-016 added Venus Cloud City and Io Sulfur Works, which need no Hardened ships)*, asteroid-belt hazards, mining claims and belt events *(CR-016's belt is visual only)*, Fragile/Urgent/Fuel-efficiency skills, social features, monetization, account linking (email, Apple, Google sign-in) *(CR-011)*.
 
 ### 0.4 Glossary
 
@@ -383,6 +383,7 @@ The game has had no server since CR-014. When a later or unfinished change reque
 ### Step 3.13 — Dispatch record creation
 - Add a function that turns a validated dispatch into a Dispatch record: id, ship, pilot, contract (or none for reposition), origin, destination, departure real time, arrival real time (computed from travel time and clock conversion), fuel cost, expected payout, seed.
 - **Test:** Arrival time minus departure time equals the travel time converted to real time. Creating two records from identical inputs yields identical records.
+- **Amended by CR-026:** A trip's event is rolled at dispatch from the record's seed (`rollTripEvent`) and stored beside the record on the dispatch; applying its option updates the record's arrival and fuel (Steps 26.2–26.5).
 
 ### Step 3.14 — Reposition dispatch
 - Allow a dispatch with no contract to any discovered location that has a player bay, paying fuel only and earning no payout or XP.
@@ -402,6 +403,7 @@ The game has had no server since CR-014. When a later or unfinished change reque
 - **Test:** Before arrival → in flight. At or after arrival → Resolution. A delivery to an undiscovered location marks it discovered. A delivery flown by the avatar deducts no pilot pay; one flown by a hired pilot does. A reposition gives no credits or XP. Resolving the same dispatch twice with the same inputs returns identical results.
 - **Amended by CR-004:** Resolution returns the pilot's new duty hours and, on mandatory rest, rest-ends-at from the arrival time (Step 10D.3).
 - **Amended by CR-010:** Hired pilots earn round(max(0, payout − fuel) × profit share); the loan repayment is taken from what remains (decisions 0.5.12, 0.5.69; Step 10J.2).
+- **Amended by CR-026:** Resolution takes the applied event: the payout changes by its losses, fee, missed Priority bonus and bonuses (never below zero), the pilot's share and the loan come from that, and XP gets its extra percent; landing also wears the hull (Steps 26.3, 26.9).
 
 ### Step 3.18 — Sim package public API and coverage
 - Export only the public functions from a single entry point. Configure coverage reporting for `packages/sim`.

memory-bank/progress.md

@@ -556,4 +556,6 @@ Spec: `memory-bank/change-requests/CR-026-random-events-hull.md` (received as "C
 - [x] **Step 26.7 — Client: hull and results.** Fleet cards have a hull bar (`HullGauge`: green, amber below 50%, red below 25% with "Needs repair") and say "Under repair" in the shop. The ship's Upgrades sheet has a Hull section: Repair to 100% with its cost and shop time at an HQ (with "Not enough credits" when short), "Repairs are done at one of your HQs" elsewhere; Hull Plating shows in the upgrade list ("Hull rating 1 → 2"). The client's ship state carries the hull, and the dispatch sheet lists "Hull too damaged for hazardous cargo: repair at an HQ". Event results (`apps/web/src/components/EventResults.tsx`): "Debris field ahead — Rosa: Go around (no answer) · +3 h" in the pop-up's short list, the Logbook (and repairs there), and as highlights: good events and hull hits rank just below level-ups (the builder's new `event` highlight; a short absence lists its trips' events, not counted towards the 3). Developer tools: Damage hull (to 20%). Tests: `apps/web/test/hull-events.test.tsx` (the bar and Needs repair; Repair's cost, time and call; away from an HQ; Hull Plating in the shop; the dispatch reason at 40% and not at 50%; event and repair wording; highlight order); `packages/engine/test/trip-events.test.ts` (Damage hull). Screenshots: `docs/screenshots/26-7-hull-card-{phone,desktop}.png`, `26-7-repair-{phone,desktop}.png`.
 - [x] **Step 26.8 — Notifications.** `plannedNotifications` adds one notification per radio call still to come on a trip the player sent (`upcomingRadioCalls`), at its fire time: "Debris field ahead — Rosa needs a call.", on its own (not grouped by minute). Independent pilots' trips get none; fleet sleep doesn't stop them. Like the rest, the plan is rebuilt from the save after every change, so a new company, an import or an answered call drops it, and the Notifications toggle (now "Arrivals, radio calls, rest, upgrades and a quiet fleet") turns them off. Tests (`packages/engine/test/notifications.test.ts`): a dispatch with a radio call schedules one at its fire time; a quiet trip and an Independent pilot's trip schedule none; turning notifications off cancels it, and so does the call firing.
 - [x] **Step 26.9 — Balance.** The balance simulator has events (`events: "off" | "defaults" | "best"`, default "defaults"; `eventsFromMinute`; `firstEventDone`): every non-tutorial launch rolls and applies its event, the player repairs at an HQ below 60%, and every hull wears on landing. A long-haul option (`longHaulMinGameHours`) has the player take only long jobs in the scenario window. The CR's targets can't be met by the usual fleet (93% Earth↔Moon shuttles, where events are capped at 3%; repairs came only from rare event damage), so, by the user's choice, they're measured on a long-haul fleet, and hulls now wear 0.35 points per game hour flown (decision 0.5.152, engine and simulator). Tuned (not the targets): event weights (bad 70: flare 12, micrometeor 10, hiccup 13, debris 5, storm 4, customs 20, hazmat 2, load shift 2, spoilage 2; good 30: tailwind 5, grateful client 5, pod 8, beacon 6, spot freight 6), wear 0.35/h, repair cost 1% of price per point. Medians over 20 worlds, 48 h of a long-haul fleet: events on 12.8% of trips (8–15%), 30.8% good (28–38%), defaults worth 99.8% of no events (≥ 93%), answered well 100.4% (≥ 100%), repairs 5.9% of income (5–10%). Earlier targets still hold (balance tests, every seed). Tests: `packages/sim/test/balance.test.ts` (the long-haul targets); `packages/engine/test/trip-events.test.ts` (wear on landing); `packages/sim/test/events.test.ts` and `hull.test.ts` follow the new weights and cost. `pnpm balance` reports them; `balance/measure-events.ts` compares off, defaults and best by hand.
-- [ ] Step 26.10 — Plan amendments and regression
+- [x] **Step 26.10 — Plan amendments and regression.** CR-026 §9 applied: plan 0.3 (random events no longer deferred), 0.5 (0.5.143–0.5.152, recorded with the CR and in Step 26.9), Steps 3.13 and 3.17; CR-009 Step 10F.1 (Hull Plating); CR-014 Steps 10K.6 (events in the loop and catch-up) and 10K.9 (radio-call notifications); CR-019 Step 18.1 (the hull reason isn't a hidden-job rule); CR-021 Step 19.4 (Independent pilots get events); CR-024 Step 22.2 (answer and repair are manual decisions); CR-025 Step 23.2 (event highlights). `game-design-document.md` §13 is the designer's to update. Full suite: typecheck, lint, 1564 unit tests and 11 e2e tests pass.
+
+**Phase 26 is complete; stopped for review.** Manual check for the user: on a fresh company, fly past the deal and three more trips, send a ship on a long contract (6+ game hours), and check the first event is the Derelict cargo pod radio call; answer it; later let a radio call run out and check the default applied (its result in the summary and the Logbook); use Developer tools → Damage hull on a ship, then repair it at an HQ from its Upgrades sheet.