===== CYBER-HANDOFF.md =====
# Cyber Command — bieżący handoff

Stan na: **2026-09-12**  
Kod: **C-01…C-06 GO** · **E-01 CONTENT GO** · **E-02 CONTENT REVIEW LGD** · UI lab **V-01G · V-02 · V-02E · V-03** · silnik dalej bez C-07 · EDU: E-03 nie startować  
Domena: `cyber.gramy.biz` (istnieje, niepodłączona do builda)  
`game_key`: `cyber` · produkt: **CYBER COMMAND**

**Jedyny dokument startowy dla Cyber.** Audyt silnika: rozmowa `GRAMY-SHARED-ENGINE-AUDIT`.  
Standard nowej gry: `docs/STANDARD-NOWEJ-GRY-GRAMY-BIZ.md`.  
Karty i modele: `docs/games/cyber/CYBER-PODZIAL-MODELI.md`.  
Kontrakt i Reuse Map: `docs/games/cyber/CYBER-CONTRACT.md`.  
Świat kampanii V1: `docs/games/cyber/CYBER-WORLD-V1.md` (**W-01**; w nowszych kartach: **COMPANY-01**, former NEXORA).  
Kanon incydentu V1: `docs/games/cyber/CYBER-INCIDENT-V1.md` (**W-02**).  
Mission Control V1: `docs/games/cyber/CYBER-MISSION-CONTROL-V1.md` (**W-03**).  
Audyt UI: `docs/games/cyber/CYBER-UI-REUSE-AUDIT.md` (**U-01**).  
Prototyp COMMAND: `cyber-prototype.html` → `src/prototypes/cyber-mission-control/` (**V-01**).  
Curriculum Map V1: `docs/games/cyber/CYBER-CURRICULUM-MAP-V1.md` (**E-01**).  
Pre-Game Briefing V1: `docs/games/cyber/CYBER-PRE-GAME-BRIEFING-V1.md` (**E-02**).

Nie czytaj Gminy, Hotelu ani `docs/analiza` „na wszelki wypadek”.  
TARGETED REUSE REVIEW: tylko 1–3 pliki wskazane w karcie / Reuse Map.

---

## Decyzja LGD (wiążąca)

**CYBER SHOULD USE = wariant 2**

```text
istniejąca platforma GRAMY
+ istniejące kontrakty CORE (bez zmian sygnatur)
+ lokalne moduły domenowe w src/lib/cyber
```

Kolejność pracy:

```text
REUSE FIRST → ADAPT SECOND → DESIGN NEW LAST
```

- Nie projektujemy mechaniki Cyber od zera, jeśli Gmina (lub CORE) ma sprawdzony mechanizm.
- Runtime Gminy **nie wolno importować** (`src/lib/gmina/*`).
- Przed analogicznym modułem Cyber: TARGETED REUSE REVIEW wskazanych plików.
- Dobry mechanizm Gminy: zachować logikę, adaptować ontologię, położyć kopię w `src/lib/cyber`, dodać lokalny test Cyber.
- **Nie** wyciągamy Crisis Engine do `src/core`. Identyczny stabilny kontrakt → zgłoszenie `SHARED-EXTRACTION CANDIDATE`, bez refaktoru.
- **Nie** wyginać Cyber do `weekly-loop`, turówkowego `delayed-effects`, `cashDelta`, P&L, ekonomii Hotelu/Agro.

---

## Twardy podział

| Warstwa | Co |
|---|---|
| **SHARED / PLATFORM** | auth, launch, instytucje, grupy, sloty, `game_progress`, save/resume, panel nauczyciela, kontrakt replay, RNG, decision record, neutralne UI |
| **REUSE BY ADAPTATION** | injecty warunkowe, zegar kryzysowy, delayed effects w czasie kryzysu, fog of war, zależności infrastruktury, inbox, wzorzec AAR |
| **CYBER LOCAL (NEW)** | stan atakującego, kill chain, tożsamości, privilege / lateral / exfil / ransomware, twin IT, zasoby i działania IR, comms SOC/IT/CEO/DPO/media, regulatory deadlines, scoring i fakty Cyber, dane scenariusza |

**Nie zmieniamy na start:** `src/core/*`, Gmina, Hotel, inne gry, istniejące kontrakty CORE.

---

## Model czasu (zatwierdzony)

- Jednostka logiczna: **1 minuta czasu symulacji**.
- To **nie** jest tick co minutę ani zegar ścienny.
- Silnik **event-driven**: następny event = koniec działania **lub** inject **lub** postęp ataku **lub** komunikat **lub** deadline **lub** delayed consequence.
- Determinizm: ten sam seed + ten sam stan + te same decyzje = ten sam wynik. Los wyłącznie przez `mulberry32` z seeda w stanie.

---

## Testy (wiążące)

- Implementacja lokalnego modułu Cyber → **jeden** test `scripts/cyber-*-test.mjs`.
- Nie ruszamy kodu Gminy → **nie** odpalamy regresji Gminy.
- Zakaz: `build:all-surfaces`, pełny test suite, golden innych gier.
- Zmiana shared/CORE → **CROSS-GAME ESCALATION**, osobna karta, osobne testy.

---

## Plan (nie przeskakuj)

| # | Krok | Status |
|---|---|---|
| 1 | Audyt shared engine (`GRAMY-SHARED-ENGINE-AUDIT`) | ✅ |
| 2 | Decyzja LGD: wariant 2 | ✅ |
| 3 | Dokumenty: ten handoff, kontrakt, podział modeli | ✅ ten commit dokumentacyjny |
| 4 | LGD zamyka max. 5 otwartych kwestii z raportu | ⏳ |
| 5 | Prymitywy: `C-01`…`C-06` (zegar, kolejka, inject, wiedza, graf, player twin) | ✅ GO |
| 5a | **W-01** World Bible | ✅ `CYBER-WORLD-V1.md` |
| 5c | **W-02** Adversary & Incident Canon | ✅ `CYBER-INCIDENT-V1.md` |
| 5d | **W-03** Mission Control experience | ✅ `CYBER-MISSION-CONTROL-V1.md` |
| 5e | **U-01** Targeted UI reuse audit | ✅ `CYBER-UI-REUSE-AUDIT.md` |
| 5f | **V-01 / V-01G** Static Mission Control slice | ✅ LAB; `http://127.0.0.1:5173/cyber-prototype.html` |
| 5g | **V-02** Incoming Call / CEO pressure | ✅ LAB mock; bez audio, bez silnika |
| 5h | **V-02E** Educational terminology layer | ✅ registry + tooltip/karta; TRAINING/EXAM |
| 5i | **V-03** Dynamics & visual state language | ✅ LAB overlay + demo; bez silnika |
| 5b | `C-04` fog of war (kod) | ✅ `src/lib/cyber/cyber-knowledge.js` |
| 5j | `C-05` Digital Twin Graph | ✅ `src/lib/cyber/cyber-graph.js` + `world/company-v1-graph.js` |
| 5k | `C-06` Player Twin Projection | ✅ `src/lib/cyber/cyber-twin-projection.js` |
| E1 | **E-01** Curriculum Map | ✅ CONTENT GO `CYBER-CURRICULUM-MAP-V1.md` |
| E2 | **E-02** Pre-game briefing / miniwykład | ⏳ CONTENT REVIEW LGD `CYBER-PRE-GAME-BRIEFING-V1.md` |
| E3 | **E-03** Student Handbook / e-book | ⏸ |
| E4 | **E-04** Teacher Guide | ⏸ |
| E5 | **E-05** Mission Advisor / avatar | ⏸ nie kodować teraz |
| E6 | **E-06** Debrief & learning report | ⏸ |
| 6 | Manifest / surface / zapis pustego stanu | ⏸ po prymitywach Etapu 1 |
| 7 | Mission Control UI / kampania / twin IT | ⏸ poza Etapem 1 |

---

## ▶ CO TERAZ

| Wybierz | Znaczenie |
|---|---|
| **`stop`** | E-02 CONTENT REVIEW LGD. Nie startować E-03 bez karty. |
| **`lgd`** | Przegląd Curriculum Map (baseline, 8 kompetencji, briefing). |
| **`E-02`** | ⏳ CONTENT REVIEW LGD — treść briefingu V1 na review channel. Final GO po LGD. |
| **`C-07`** | **Nie zaczynać.** |

**Następny krok:** E-02 CONTENT REVIEW LGD na docs.gramy.biz/cyber-review/. Final GO po akceptacji. E-03 nie startować samodzielnie.  
**Nie implementować teraz:** skrypt wykładu, handbook, avatar, C-07, UI→C-06.

Hotel, Gmina, Recepcja — poza tym handoffem. W working copy są obce zmiany Hotel/Gmina: **nie ruszać**.

---

## EDU / LEARNING TRACK (obowiązkowy)

To są **planowane, obowiązkowe** części CYBER COMMAND.  
Nie traktować ich jako opcjonalnych dodatków.  
Dalsza architektura **nie może** pominąć tej warstwy.

**Zakaz w kartach silnika C-\*:** wykład, avatar, ebook, slajdy, onboarding flow, Learning Content Registry.

| Karta | Tytuł | Status |
|---|---|---|
| **E-01** | CURRICULUM MAP | ✅ CONTENT GO |
| **E-02** | PRE-GAME BRIEFING / MINIWYKŁAD | ⏳ CONTENT REVIEW LGD (przed final GO) |
| **E-03** | STUDENT HANDBOOK / E-BOOK | ⏸ |
| **E-04** | TEACHER GUIDE / PODRĘCZNIK PROWADZĄCEGO | ⏸ |
| **E-05** | MISSION ADVISOR / AVATAR | ⏸ |
| **E-06** | DEBRIEF & LEARNING REPORT | ⏸ |

### Pre-game briefing

Przed właściwą symulacją uczestnik dostaje krótkie przygotowanie dydaktyczne. Docelowo **8–15 minut**.

Dwa sposoby — treść **merytorycznie spójna**:

- **A. TEACHER-LED** — briefing prowadzi nauczyciel / prowadzący.
- **B. SELF-GUIDED** — jeżeli nauczyciel nie prowadzi wprowadzenia, CYBER COMMAND przeprowadza briefing samodzielnie.

Minimalny zakres (uczeń rozumie przed misją):

- czym jest cyberatak;
- czym jest incydent cyberbezpieczeństwa;
- nie każdy alert oznacza potwierdzony atak;
- phishing / przejęcie konta;
- ransomware;
- możliwość kradzieży danych;
- znaczenie tożsamości cyfrowej i kont;
- czym jest SOC;
- czym jest WMS i dlaczego system IT może zatrzymać magazyn;
- czym jest containment;
- czym jest recovery;
- różnica SIGNAL / SUSPECTED / CONFIRMED;
- bezpieczeństwo może kolidować z ciągłością działania firmy;
- rola Incident Commandera;
- gracz podejmuje decyzje przy niepełnej informacji.

Briefing **nie może** zdradzać rozwiązania scenariusza ani ścieżki ataku W-02.

Treść V1: `docs/games/cyber/CYBER-PRE-GAME-BRIEFING-V1.md` (**E-02**).  
Review channel: `CYBER-PRE-GAME-BRIEFING-V1.html` na docs.gramy.biz/cyber-review/.

**Decyzje LGD (E-02 / E-02R):**

- **Self-guided briefing** = wymaganie **V1 i pilotażu** (nie opcjonalny dodatek).
- **Self-guided:** osobny ekran dla **dwóch osi** — pewność informacji (confidence/verification) vs stan operacyjny (operational status).
- **Baseline** pozostaje **10 węzłów**; visibility **nie** oznacza obowiązku omawiania każdego node w briefingu.
- **EXAM** używa **tego samego rdzenia** pre-game briefing; różni się **pomocą podczas właściwej misji** (Advisor, hints — nie treścią miniwykładu).
- **E-02** wymaga **CONTENT REVIEW LGD** przed **final GO**.

### Wiedza organizacyjna przed grą

E-01 / E-02 określą, które elementy COMPANY V1 uczestnik zna jeszcze przed T0.  
To później stanie się właściwym `baselineVisibleNodeIds` dla C-06.

C-06 ma **mechanizm** baseline. C-06 **nie** ustala finalnej listy.

### Student Handbook

Docelowy materiał ucznia:

- podstawy cyberbezpieczeństwa potrzebne do gry;
- opis organizacji;
- słownik;
- role;
- sposób czytania Mission Control;
- rodzaje statusów;
- rodzaje decyzji;
- podstawy incident response;
- materiały do powtórki po grze.

**Nie może** zawierać: ground truth scenariusza, poprawnych decyzji dla W-02, ukrytych ścieżek ataku.

### Teacher Guide

Szerszy niż handbook ucznia. Docelowo:

- cele dydaktyczne;
- wymagania wstępne;
- gotowy scenariusz miniwykładu;
- odpowiedzi i wyjaśnienia;
- pełny przebieg scenariusza;
- Ground Truth dostępny prowadzącemu;
- Decision Windows;
- typowe błędy studentów;
- pytania do debriefingu;
- możliwe warianty przebiegu;
- sposób oceniania;
- instrukcja przeprowadzenia zajęć;
- tryb TRAINING i EXAM.

### Mission Advisor / Avatar

Docelowy prowadzący w produkcie. **Nie implementować teraz.**

Może: poprowadzić pre-game briefing; wyjaśniać terminy; pomagać w orientacji w interfejsie; pojawiać się przy nowych rodzajach zdarzeń; uczestniczyć w debriefingu.

**Nie może:** wskazywać właściwej decyzji; zdradzać Ground Truth; mówić, którędy idzie atak; zastępować samodzielnego rozumowania uczestnika.

TRAINING — większa dostępność Advisora.  
EXAM — silnie ograniczona pomoc.

### Przyszły kontrakt EDU: CYBER LEARNING CONTENT REGISTRY

Tooltipy, słownik, pre-game briefing, avatar, Student Handbook i Teacher Guide **nie mogą** mieć sześciu różnych wersji definicji.

Jedna wspólna warstwa treści edukacyjnych: **CYBER LEARNING CONTENT REGISTRY**.

Nie implementować w C-06. Osobna karta EDU, nie silnik.

---

## REVIEW DOCS CHANNEL

Public review index: https://docs.gramy.biz/cyber-review/

**Jeden URL dla narzędzi AI (ChatGPT / fetch):**  
https://docs.gramy.biz/cyber-review/review-bundle.txt  
Cała whitelist w jednym pliku tekstowym — nie trzeba ręcznie wklejać `.md`.

Alternatywa per dokument (HTML, `text/html`):  
https://docs.gramy.biz/cyber-review/CYBER-CURRICULUM-MAP-V1.html  
(pełna lista w `manifest.json` → pola `html`).

Publikacja: **explicit whitelist only**.  
Nowe pliki z `docs/games/cyber/` nie wchodzą automatycznie — wymagają jawnego dopisania do whitelisty.

Skrypt: `scripts/publish-cyber-review-docs.sh`  
Zdalny katalog: `pub/docs/cyber-review`

**Crawl / fetch (robots.txt w katalogu review):**
- `OAI-SearchBot` — **Allow**
- `ChatGPT-User` — **Allow**
- `GPTBot` — **Disallow** (trening, nie search)
- Brak `noindex` na indexie review

**WAF (Hosti24 — ręcznie poza skryptem):** upewnij się, że reguły WAF **nie blokują** `OAI-SearchBot` ani `ChatGPT-User` na `docs.gramy.biz`. Test po deployu:
`curl -A OAI-SearchBot -I https://docs.gramy.biz/cyber-review/review-bundle.txt` → oczekiwane **200**.

---

## Budżet kontekstu

**ONE CARD = ONE PROBLEM.**

Agent czyta: ten plik, kontrakt Cyber, kartę z podziału modeli, pliki dozwolone na karcie.  
TARGETED REUSE REVIEW: wyłącznie źródła z kolumny „files allowed” w Reuse Map.

===== CYBER-CONTRACT.md =====
# Cyber Command — kontrakt etapu dokumentacyjnego

Status: **kontrakt decyzji i reuse**, nie specyfikacja silnika  
Data: **2026-09-11**  
Handoff: `docs/games/cyber/CYBER-HANDOFF.md`

Ten plik wiąże granice. **Nie** opisuje kampanii, HUD-u ani pełnego schematu stanu ataku.  
To, czego tu nie ma, jest albo **OPEN DECISION**, albo należy do późniejszej karty Etapu 2.

---

## 1. Wariant architektury

Cyber jest **ósmą grą** w monorepo, nie forkiem Gminy i nie nową platformą.

```text
SHARED:   platforma + kontrakty CORE (użycie, bez zmiany sygnatur)
ADAPT:    mechanizmy kryzysowe Gminy → kopia logiki w src/lib/cyber
NEW:      ontologia IR / adwersarz / twin IT / prawo / scoring Cyber
```

Zakaz runtime:

```javascript
// ❌
import { selectGminaInjects } from '@/lib/gmina/gmina-injects';
import { enqueueDelayedEffect } from '@/core/consequences/delayed-effects';
import { needsWeeklyPriority } from '@/lib/weekly-loop';
```

CORE wolno importować tylko tam, gdzie kontrakt jest neutralny: RNG, `createDecisionRecord`, później adapter `createUniversalMetrics` i obserwacje kompetencji.  
`enqueueDelayedEffect` z CORE **nie** jest kolejką Cyber (tury + `cashDelta`).

---

## 2. Czas i determinizm

| Pole | Wartość |
|---|---|
| Jednostka | 1 minuta symulacji (`simTime`, liczba całkowita ≥ 0) |
| Tick ścienny | zakazany w ścieżce obliczeń |
| Postęp | event-driven: następny `dueAtMinute` spośród działań, injectów, ataku, comms, deadline’ów, kolejki skutków. C-01 ustawia tylko `clock.simTime` skokiem (`advanceCyberClockTo`), bez ticka co minutę. |
| Los | wyłącznie `mulberry32(seed)` z `src/core/simulation/rng.js` |
| Tożsamość | `seed + state + decisions` → identyczny stan |

Gmina liczy **godziny** i **tury 2 h**. Cyber adaptuje **tę samą ideę znacznika absolutnego**, nie ten sam przelicznik. Okno injectu Gminy (`window: [fromTurn, toTurn]`) w Cyber ma być oknem minutowym albo oknem zdarzeniowym — decyzja implementacyjna karty `C-03`, nie zmiana Gminy.

---

## 3. Co wolno zapisać w stanie (szkielet, nie schemat)

Na Etapie 1 (prymitywy headless) wystarczy:

- `meta`: `gameKey`, wersje, `seed`
- `clock.simTime`
- kolejka `{ id, dueAtMinute, payload, note, sourceId }`
- bank injectów jako **dane** + `firedInjectIds`
- warstwa wiedzy vs fakty silnika (fog) — bez ontologii IT

Pola kill chain, twin IT, regulatory, scoring, inbox aktorów Cyber — **Etap 2 / NEW**. Nie projektować ich w tym pliku.

UI nigdy nie czyta ukrytej prawdy ataku. To niezmiennik, gdy te pola powstaną.  
C-04: `toPlayerKnowledgeView` oddaje wyłącznie `observations` / `assessments` / `revealedSubjectIds`. Warstwa wiedzy nie przyjmuje i nie zwraca `truth` ani ground truth.  
C-05: graf to **topologia**. Krawędź `{ from, to }` znaczy: **TO zależy od FROM**. Przykład: `{ from: 'active-directory', to: 'wms' }` = WMS zależy od AD. Brak statusu, knowledge i atakującego. Dane świata: `src/lib/cyber/world/company-v1-graph.js` — silnik grafu nie importuje COMPANY-01.  
C-06: `FULL GRAPH + knowledgeView + baselineVisibleNodeIds → { nodes, edges }`. Node widoczny = baseline ∪ revealed (tylko id z grafu). Edge tylko gdy oba końce widoczne. Assessments per topic, bez `node.status` i bez liczników ukrytych. UI nie dostaje pełnego grafu. Finalna lista baseline COMPANY V1 = karta E-01/E-02, nie C-06.

---

## 4. Metryki i kompetencje

- Scoring rozgrywki Cyber **nie** jest P&L Hotelu.
- Adapter `createUniversalMetrics` — dopiero przy zapisie do panelu; oczekiwany kierunek jak w Gminie: `revenue = 0`, koszty / osie w `domainMetrics`. **Nie zmieniać** `src/core/metrics/universal.js`.
- `createDecisionRecord`: `context × choice × actual`, bez oceny.
- Katalog CORE (`capacity_awareness`, `prioritization`, `risk_management`) — mapowanie albo pominięcie = **OPEN DECISION**. Nie rozszerzać `evaluate.js` na start.

---

## 5. Zapis i nauczyciel

Gdy powstanie surface: `saveGameProgress` w kontekście `game_key` + `class_instance_id`.  
Replay: kontrakt `PlatformGameModule.loadReplayComponent`, komponent w drzewie Cyber.  
Panel nie liczy wyniku — czyta zapis.

Na Etapie 1 **nie** ma manifestu ani subdomeny, o ile LGD nie każe inaczej.

---

## Reuse Map

Strategia: **SHARED** = import wspólnego kontraktu; **ADAPT** = TARGETED REUSE REVIEW, potem lokalna kopia logiki; **NEW** = brak wzorca, projekt po prymitywach.

| Cyber mechanism | Existing GRAMY mechanism | Source | Strategy | Files allowed for targeted review |
|---|---|---|---|---|
| Auth / launch / zajęcia / sloty | Platforma wielogry | `docs/KONTRAKT-PLATFORMY-WIELOGRY.md`, `src/lib/AuthContext.jsx`, `src/surfaces/GameSurfaceApp.jsx` | SHARED | te 3; nie czytać silników gier |
| Save / resume | `game-progress-save` | `src/lib/platform/php-platform-adapter.js` (`saveGameProgress`), wzorzec payloadu w `src/pages/GminaShell.jsx` (tylko zapis, nie silnik) | SHARED | adapter + 1 shell jako wzorzec payloadu |
| Teacher panel / replay contract | `PlatformGameModule` | `src/platform/contracts/game-module.js`, `src/platform/games/gmina/index.js` | SHARED | kontrakt + 1 adapter jako wzorzec; nie cały panel |
| Neutral UI / help shell | Intro / help | `src/components/help/IntroGuide.jsx`, `src/lib/help/help-kb.js` (powłoka, nie treść Gminy) | SHARED | 2 pliki powłoki |
| Deterministic RNG | `mulberry32` | `src/core/simulation/rng.js` | SHARED | ten plik |
| Decision record | `createDecisionRecord` | `src/core/decisions/record.js` | SHARED | ten plik |
| Competency observations | `createObservation` / `buildCompetencyProfile` | `src/core/competency/evaluate.js` | SHARED (adapter later) | ten plik; **nie** zmieniać katalogu 3 osi |
| Panel metrics adapter | `createUniversalMetrics` | `src/core/metrics/universal.js`, wzorzec mapowania: `src/lib/gmina/gmina-metrics.js` | SHARED + ADAPT mapowania | te 2; nie zmieniać CORE |
| Crisis clock (minuty, event-driven) | Zegar kryzysowy (godziny / tura 2 h, `elapsedHours`, `dueAtHour`) | `src/lib/gmina/gmina-constants.js`, `src/lib/gmina/gmina-effects.js` | ADAPT | te 2 |
| Delayed crisis effects | `enqueue* / process* / { state, fired }` + `payload` | `src/lib/gmina/gmina-effects.js` (kształt); **nie** `src/core/consequences/delayed-effects.js` jako runtime | ADAPT | `gmina-effects.js`; CORE tylko żeby **nie** kopiować ładunku `cashDelta` |
| Conditional inject engine | okno → warunek → priorytet → limit; inne zdarzenie po przygotowaniu; zamknięte `effect.kind` | `src/lib/gmina/gmina-injects.js` (`GMINA_EFFECT_KINDS`, `selectGminaInjects`) | ADAPT | ten plik; test Gminy injectów tylko gdy karta C-03 |
| Fog of war / knowledge vs real | węzeł istnieje przed odkryciem; `revealedNodes`; `message.truth` ukryte przed graczem | `src/lib/gmina/gmina-state.js` (pola `revealedNodes`; nie cały plik — nagłówek stanu + `runAudit`), `src/lib/gmina/gmina-contract.js` (`createMessage`) | ADAPT | te 2, wąski wycinek |
| Infrastructure dependency concepts | graf: hard/soft, `delay`, zapas, kaskada; KPI z węzłów, nie z eventu | `src/lib/gmina/gmina-graph.js` (interfejs + reguły), `src/lib/gmina/gmina-contract.js` (`createNode`, `createEdge`) | ADAPT (koncepcja) | te 2; ontologia IT = NEW, nie kopiować węzłów gminy |
| Inbox / information flow | skrzynka, źródło, wiarygodność, status potwierdzenia | `src/lib/gmina/gmina-contract.js` (`createMessage`), `src/lib/gmina/gmina-information.js` (założenia 1–3 + `verify` — nie cały chaos społeczny) | ADAPT | te 2 |
| AAR / facts-then-score | najpierw fakty z zapisu, scoring i tekst czytają ten sam obiekt | `src/lib/gmina/gmina-report.js` (nagłówek + `collectGminaFacts`), `src/lib/gmina/gmina-scoring.js` (nagłówek rubryki) | ADAPT (wzorzec) | te 2; osie i wagi Cyber = NEW |
| Weekly loop / CAPEX / P&L | pętla tygodnia, `cashDelta` | `src/lib/weekly-loop.js`, `src/core/consequences/delayed-effects.js` | **NIE UŻYWAĆ** | — |
| Attacker / kill chain / identity / lateral / ransomware | — | brak w GRAMY | NEW | brak review Gminy |
| IT digital twin (identity, segment, datastore, control) | graf Gminy jest analogią zależności, nie modelem IT | `gmina-graph.js` tylko jako koncepcja kaskady | NEW + ADAPT koncepcji | jak wiersz zależności |
| Cyber resources / IR actions | zasoby i zadania Gminy / Zespołu — inna ontologia | nie importować | NEW | review dopiero na karcie zasobów (1 plik Gminy `gmina-contract.js` `createResource` jeśli LGD potwierdzi analogię pojemności) |
| Comms SOC / IT / CEO / DPO / media | źródła wiadomości Gminy (urząd, operator) | `createMessage` + słownik źródeł | NEW aktorzy, ADAPT kształt wiadomości | `gmina-contract.js` (`createMessage`) |
| Regulatory deadline engine | `dueAtHour` zadań i obietnic, nie prawo | `gmina-effects.js` / zadania — tylko idea absolutnego terminu | NEW | brak; nie czytać GUNB/recovery |
| Cyber scoring / scenario data | rubryki i banki Gminy | — | NEW | nie kopiować injectów blackout/powódź |

---

## 6. SHARED-EXTRACTION CANDIDATES (nie wykonywać)

Zgłaszać przy implementacji, jeśli kontrakt się ustabilizuje i będzie **identyczny** u dwóch konsumentów:

1. Kolejka `{ dueAt, payload }` + `enqueue` / `process` / `{ state, fired }` — Gmina V-1 już to odkłada; Cyber będzie piątym wariantem lokalnym.
2. Selektor injectów: okno + warunek + priorytet + limit + remis z RNG.
3. Wzorzec AAR: `collectFacts(state)` → scoring i narracja z jednego obiektu.

**Zakaz ekstrakcji** bez osobnej decyzji (P4 / Codeks).

---

## 7. CROSS-GAME ESCALATION

Dotknięcie któregokolwiek z poniższych przerywa kartę Cyber:

- `src/core/*` (sygnatura lub zachowanie)
- `src/lib/gmina/*`, `src/lib/hotel/*`, inne gry
- `src/lib/weekly-loop.js`
- tożsamości `universal-metrics` / katalog kompetencji
- twarde rejestry powierzchni (`vite.config.js`, `app-surface.js`, `build:all-surfaces`) — tylko na osobnej karcie platformy

---

## Otwarte decyzje LGD

Nie rozstrzygać w kodzie. Lista robocza — max. 5 w raporcie agenta:

1. Identyfikatory: `game_key`, nazwa handlowa, subdomena.
2. Tryb MVP: tylko SOLO headless → SOLO UI, czy od razu observer nauczyciela.
3. Pierwsza organizacja / sektor kampanii (dane, nie silnik).
4. Ramy prawne V1 i moment startu zegara obowiązku (zdarzenie vs wiedza).
5. Kompetencje: mapować 3 osie CORE, czy trzymać ocenę IR tylko w AAR Cyber.

===== CYBER-WORLD-V1.md =====
# CYBER COMMAND — World Bible V1

Status: **kanon świata pierwszej kampanii** (nie silnik, nie scenariusz ataku)  
Data: **2026-09-11**  
Organizacja: **NEXORA Logistics S.A.** (nazwa robocza)  
Karta: **W-01**  
Handoff: `docs/games/cyber/CYBER-HANDOFF.md`

Ten plik opisuje **świat**, w którym później rozegra się incydent.  
Nie opisuje kill chain, exploitów ani konkretnej kampanii phishing → ransomware.

MVP: **SOLO / Incident Commander**. Osoby poniżej to zasoby i źródła informacji sterowane przez symulację, nie gracze.

---

## 1. Profil organizacji

NEXORA to średniej wielkości polski operator logistyczny (spółka akcyjna). Zatrudnia ok. **820** osób.

Zakres: logistyka kontraktowa, magazynowanie, dystrybucja krajowa i regionalna, integracje zleceń z klientami i przewoźnikami.

Fizycznie:

| Miejsce | Rola |
|---|---|
| Centrala (Warszawa, godziny biurowe + dyżur) | zarząd, finanse, HR, IT, sprzedaż, biuro obsługi klienta |
| Główne centrum logistyczne (24/7) | picking, packing, załadunek, automatyka, dyspozycja transportu |
| Trzy lokalizacje regionalne (zmiany, nie pełne 24/7 IT) | mniejsze magazyny / cross-dock, lokalny dispatch |

Organizacja jest wystarczająco duża, by mieć profesjonalne IT i umowę SOC, za mała, by wszystkie funkcje trzymać w rozbudowanych zespołach wewnętrznych. Część bezpieczeństwa, chmury i utrzymania idzie na zewnątrz.

Dojrzałość: **MEDIUM / REALISTIC**. Da się wygrać dobrymi decyzjami. Nie da się „mieć wszystkiego od razu”.

---

## 2. Dojrzałość i dług techniczny

### Jest

- MFA na poczcie i VPN (nie wszędzie jednakowo).
- EDR na stacjach i serwerach Windows; słabszy zasięg na terminalach magazynowych.
- SIEM + zewnętrzny SOC (alerty, nie pełny IR na miejscu).
- Kopia zapasowa produkcji + wydzielone repozytorium z elementem immutable/offline.
- Procedura IR (papier / wiki): eskalacja, war room, kontakty.
- Podstawowa segmentacja: biuro / DC / OT magazynowe / goście — **nierówna**.
- Monitoring dostępności kluczowych aplikacji.

### Dług (strukturalny, nie exploit)

- Hybrydowa tożsamość (AD + Entra + synchronizacja).
- Legacy EDI i stare konektory klientów.
- Konta serwisowe z szerokimi uprawnieniami, hasła w skryptach i Harmonogramie zadań.
- Regionalne sieci „prawie jak DC”, ale z wyjątkami.
- Stały zdalny dostęp dostawców (WMS, automatyka, MSP).
- SaaS i partnerzy poza pełną kontrolą NEXORY.

Firma **nie** jest goła i **nie** jest fortecą.

---

## 3. Warstwy świata

Nazwy produktów Microsoft zostają, bo tak wygląda ten stack. Pozostali dostawcy: role, nie marki.

### 3.1. Tożsamość

| Element | Opis |
|---|---|
| Microsoft Entra ID | tożsamość chmurowa, MFA, dostępy do M365 i części SaaS |
| Active Directory | domena lokalna: stacje, serwery, udziały, część aplikacji on-prem |
| Synchronizacja | most AD ↔ Entra; awaria sync nie wyłącza od razu obu stron, ale rozjeżdża konta i blokady |
| MFA | wymuszane dla poczty, VPN, adminów; wyjątki: część kont serwisowych i stare integracje |
| Użytkownicy | ok. 820 kont osobistych + sezonowi / agencja w DC |
| Administratorzy | IT, Identity/M365, infra, sieć — osobne role, częściowo te same osoby |
| Konta uprzywilejowane | Domain Admin, Global Admin, break-glass (procedura, nie codzienny login) |
| Konta serwisowe | WMS, TMS, kopie, konektory EDI, skrypty; często poza MFA i poza recertyfikacją |

### 3.2. Współpraca

Microsoft 365: Exchange Online, Teams, SharePoint / OneDrive.  
Tu żyje koordynacja incydentu, decyzje zarządu i komunikacja z klientem — oraz skrzynki, które da się podmienić albo wyciszyć.

### 3.3. Dostęp i sieć

- Krawędź internetu + firewall (jedna brama logiczna).
- VPN pracowników i home office.
- Sieć centrali, sieć DC 24/7, sieci trzech regionów.
- Wi-Fi biurowe (pracownicy / goście).
- Urządzenia magazynowe (terminale, skanery, drukarki) w VLAN OT — nie wszędzie czysto oddzielone.
- Zdalny dostęp dostawców: jump / VPN vendorski, często stały.

### 3.4. Bezpieczeństwo

- EDR: telemetria endpoint, izolacja stacji (nie izolacja sieci OT).
- SIEM: korelacja logów tożsamości, poczty, firewalla, EDR, części aplikacji.
- SOC zewnętrzny: 24/7 triaż, telefon do NEXORY, **nie** właściciel biznesu.
- Logi: 30–90 dni online w SIEM; starsze w archiwum, wolniejsze.
- Alerting: reguły „dobre na papierze”, szum w godzinach szczytu magazynu.

### 3.5. Magazyn

- WMS (dostawca zewnętrzny + wewnętrzny application owner).
- Terminale, skanery, drukarki etykiet, stanowiska operatorów.
- Integracja z automatyką (przenośniki, sortownia) — bez WMS automatyka stoi albo jedzie „na ślepo”.

### 3.6. Transport

- TMS: planowanie tras, dispatch, okna załadunku.
- Przewoźnicy: statusy przez integracje, nie przez ręczny telefon w normalnym dniu.

### 3.7. Integracje

- Warstwa integracji: API Gateway + EDI (jeden węzeł logiczny „hub”).
- Klienci: zlecenia, ASN, statusy.
- Przewoźnicy: zlecenia transportu, ETA, POD.

### 3.8. Biznes

- ERP (zlecenia, stany, master data).
- Finanse / fakturowanie (zależne od ERP i poczty).
- HR (kadry, dostęp sezonowych).
- Udziały plików (umowy, SOP, etykiety, skany CMR).

### 3.9. Klient

- Portal: status przesyłki / zlecenia, reklamacje, dokumenty.
- Komunikacja: portal + e-mail + opiekunowie (telefon przy awarii).

### 3.10. Odtwarzanie

- Backup produkcyjny (agenci na serwerach i wybranych SaaS).
- Repozytorium kopii.
- Element immutable / offline (nie cały majątek — wybrane systemy CRITICAL).
- DR: priorytety odtworzenia, nie pełny równoległy ośrodek.
- RTO poniżej to **parametry scenariusza**, nie audyt BIA.

### 3.11. Strony trzecie

| Rola | Co daje NEXORZE | Czego NEXORA nie kontroluje w pełni |
|---|---|---|
| Operator SOC | alert, triaż, rekomendacja | decyzję biznesową, izolację magazynu |
| Dostawca WMS | aplikacja, poprawki, zdalny support | zmianę procesu picking w 15 min |
| MSP / infra | hosty, AD care, łatki, część backupu | priorytet NEXORY vs innych klientów MSP |
| Cloud / SaaS (M365 i inni) | poczta, tożsamość chmurowa | globalną awarię tenanta |
| Przewoźnicy | flota i ostatnia mila | ich własne IT |
| Kluczowi klienci (EDI/API) | wolumen zleceń | ich oczekiwanie „system ma działać” |

---

## 4. Zależności biznesowe

To jest oś Twin i Mission Control. System nie jest pudełkiem.

| System | Zależy od | Proces | Skutek awarii |
|---|---|---|---|
| **WMS** | tożsamość (AD/Entra), sieć DC, platforma serwerów, (miękko) automatyka i EDR | picking, pakowanie, załadunek, etykiety | DC zwalnia albo staje; automatyka bez zleceń |
| **Automatyka magazynowa** | sieć OT, WMS (zlecenia), zasilanie (poza IT) | sortowanie, przenośniki | ręczne taczki / obejścia; wydajność spada ostro |
| **TMS** | tożsamość, hub integracji, (miękko) WMS (gotowość załadunku) | plan tras, dispatch, okna | opóźnione wyjazdy, puste przebiegi, kary umowne |
| **Hub EDI/API** | sieć / krawędź, tożsamość serwisowa, (miękko) ERP | zlecenia klientów, statusy, zlecenia dla przewoźników | nowe zlecenia nie wpadają same; statusy milczą |
| **ERP** | tożsamość, sieć, backup przy odtwarzaniu | master data, stany, rozliczenie zlecenia | WMS/TMS jedzą stare dane; faktury się sypią |
| **Finanse / FV** | ERP, M365 (wysyłka), tożsamość | fakturowanie, windykacja | utrata płynności informacyjnej, nie od razu fizycznego towaru |
| **HR** | tożsamość, M365 | onboarding sezonowych, listy obecności | spóźniony dostęp ludzi na zmianę; nie zatrzymuje DC od razu |
| **M365** | Entra, internet | koordynacja, poczta do klienta i SOC | war room utyka; oszustwo „z poczty zarządu” staje się wiarygodne |
| **Portal klienta** | hub, ERP/WMS (dane), Entra (logowanie B2B/B2C uproszczone) | self-service statusów | lawina telefonów; zaufanie spada szybciej niż fizyczny outbound |
| **Entra ID** | internet, (miękko) sync z AD | logowanie do chmury i MFA | M365, część VPN i SaaS; AD on-prem może jeszcze żyć |
| **Active Directory** | sieć HQ/DC, kontrolery | logowanie stacji, udziały, WMS/TMS on-prem | magazyn i pliki; chmura może jeszcze żyć |
| **Synchronizacja** | AD + Entra + sieć | spójność kont i blokad | rozjazd: zablokowany tu, żywy tam |
| **VPN** | krawędź, tożsamość, MFA | praca zdalna, część adminów | spowolnienie biura, niekoniecznie zmiana 24/7 w DC |
| **Dostęp dostawców** | VPN/jump, tożsamość serwisowa | support WMS/automatyki/MSP | utrata pomocy albo zostawione otwarte drzwi |
| **EDR** | sieć do chmury EDR, tożsamość agentów | izolacja stacji, telemetria | ślepota endpoint; izolacja przestaje być dźwignią |
| **SIEM / SOC** | logi ze źródeł, internet do SOC | świadomość sytuacyjna | gracz działa w mgle; atak nie znika |
| **Backup** | tożsamość, sieć do repo, agenci | odtworzenie | brak dźwigni recovery |
| **Repo / vault** | izolacja od domeny produkcyjnej (założenie częściowe) | last resort | jeśli ta sama tożsamość rządzi vaultem — recovery jest pozorne |
| **File services** | AD, sieć | SOP, CMR, etykiety awaryjne | tryb ręczny traci instrukcje i numery |

---

## 5. Tryby manual / degraded

Parametry projektowe do późniejszej kalibracji. Nie punkty gry.

| Proces | Czy jest tryb ręczny? | Wydajność orientacyjna | Sensowny horyzont | Ryzyko z czasem |
|---|---|---|---|---|
| Magazyn bez WMS | tak: listy papierowe / Excel, skanery jako notatnik | **25–35%** pojemności zmiany | 1–2 zmiany (8–16 h), potem chaos etykiet i lokacji | pomyłki SKU, zgubione nośniki, reklamacje |
| Automatyka bez WMS | tak: wyłączyć i iść ręcznie | **15–25%** na sortowni | kilka godzin | zatory, BHP |
| Transport bez TMS | tak: telefon + whiteboard + znani przewoźnicy | **40–50%** zaplanowanych wyjazdów | 1 doba | puste auta, okna klienta, kary |
| Zlecenia bez EDI/API | tak: e-mail / Excel od opiekunów | **20–30%** wolumenu kluczowych klientów | 4–12 h, potem backlog nie do odrobienia w dniu | złe ilości, podwójne zlecenia |
| Portal down | tak: infolinia / opiekun | **~10%** zapytań obsłużonych dobrze | 2–4 h zanim call center pęka | sprzeczne statusy, utrata zaufania |
| Poczta / Teams down | tak: telefon, SMS, spotkanie w DC | koordynacja **~50%**, dokumentacja **~10%** | 2–6 h | decyzje bez śladu, plotki |
| Tożsamość chmurowa down | częściowo: konta AD lokalne w DC | DC może iść, jeśli WMS jest on-prem i sesje żyją | sesje wygasają w ciągu godzin | nowe logowania i MFA padają |
| AD down | bardzo słaby tryb: zalogowane sesje do wygaśnięcia | **gasnące 1–3 h** | nie utrzymasz zmiany | nowe terminy i udziały umierają |
| Finanse / FV down | tak: faktury ręcznie następnego dnia | biznes fizyczny jedzie | 24–48 h | spór o dostawy, nie postój rampy |
| Backup niedostępny | nie ma „ręcznego backupu” w incydencie | 0% recovery z kopii | natychmiast | tylko containment i odbudowa z tego, co żyje |

---

## 6. Krytyczność i odtworzenie (dane do gry, nie BIA)

| Klasa | Systemy |
|---|---|
| **CRITICAL** | Active Directory, Entra ID (dla chmury), WMS, sieć DC, hub integracji, backup vault |
| **HIGH** | TMS, M365, SIEM/SOC, EDR, ERP, krawędź/VPN, automatyka, serwery DC |
| **MEDIUM** | portal klienta, finanse, file services, dostęp dostawców, sync, regiony, Wi-Fi |
| **LOW** | HR (w horyzoncie 24 h), drukarki poza etykietą wysyłkową, Wi-Fi gości |

| Priorytet odtworzenia (orientacja) | Co najpierw | RTO scenariusza |
|---|---|---|
| P1 | Tożsamość + sieć DC + WMS | **2–8 h** (cel gry: zmiana nie pada w całości) |
| P2 | Hub EDI/API + TMS | **4–12 h** |
| P3 | M365 + EDR/SIEM | **4–24 h** |
| P4 | Portal, ERP spójność, finanse | **24–48 h** |
| P5 | HR, wygoda biura, regiony w pełnym self-service | **48 h+** |

Vault immutable jest P1 **jako dźwignia**, nie jako pierwszy system, który „ma działać dla magazynu”.

---

## 7. Ludzie (zasoby SOLO)

Incident Commander (gracz) nie jest osobną etatową rolą w NEXORZE — w praktyce bywa CISO albo CIO. Poniżej: co wiedzą, czym dysponują, czego potrzebują, gdzie się zderzą.

| Rola | Wie | Dysponuje | Potrzebuje | Konflikt w incydencie |
|---|---|---|---|---|
| **CEO** | reputacja, kontrakty kluczowe, media | decyzja „stój / jedź / mówimy” | prosty obraz ryzyka, nie logów | presja „magazyn ma jechać” vs izolacja |
| **COO** | SLA, kary, pojemność DC i floty | priorytet operacji, tryb ręczny | czas do zapaści wydajności | będzie bronić outboundu |
| **CIO / IT Director** | mapa systemów, dostawcy, dług | priorytet IT, budżet doraźny | zgoda biznesu na przestój | może bagatelizować bezpieczeństwo albo odwrotnie — wszystko gasić |
| **CISO / IC** | ryzyko, IR, SOC | eskalacja, war room, rekomendacja isolate | uprawnienia, których sam nie klika | odpowiedzialność bez rąk na WMS |
| **SOC** (zewn.) | alerty, timeline telemetrii | triaż, IOC, rec. izolacji stacji | kontekst biznesowy („co to za host”) | szum; „to tylko phishing” albo odwrotnie |
| **Identity / M365 admin** | konta, MFA, role, skrzynki | reset, blokada, revoke sesji, reguły poczty | potwierdzenie, że to nie legalny admin | zablokuje zbyt dużo albo za mało |
| **Infra admin** | AD, serwery, backup | restart, restore, wyłączenie hosta | okno serwisowe od COO | restore bez containment = powtórka |
| **Network admin** | VLAN, VPN, firewall, dostawcy | segment, cut VPN, ACL | lista „kogo odcinać” | odcina DC razem z atakiem i z WMS |
| **WMS owner** | procesy magazynu, vendor | tryb awaryjny aplikacji, ticket do dostawcy | sieć + tożsamość + decyzja COO | nie pozwoli „ruszyć bazy” |
| **TMS owner** | trasy, przewoźnicy | ręczny dispatch | dane z rampy (WMS) | obiecuje klientowi okna, których nie ma |
| **DPO / Legal** | RODO, KSC/NIS2, umowy | ocena, czy to incydent / naruszenie; zegary zgłoszeń | fakty: co wyciekło, od kiedy wiemy | będzie chciał dokumentacji, gdy IC chce działać |
| **Communications / PR** | ton, media, personel | komunikat wewnętrzny / klient / prasa | zatwierdzenie CEO + fakty od IC | pusta pociecha albo przeciek |
| **Business Continuity** | karty trybów ręcznych, priorytety DR | uruchomienie BCP | ludzie z magazynu i transportu | plan vs realna zmiana 02:00 |
| **Warehouse Ops Manager** | zmiana, BHP, backlog | ludzie na rampie, tryb papierowy | działający (choć zdegradowany) proces | safety vs tempo |
| **Transport Ops Manager** | flota, okna, przewoźnicy | telefony, przekierowania | analog „co jest załadowane” | wyśle auta w ślepą |

Gracz steruje **uwagą i kolejnością poleceń**, nie wszystkimi rękami naraz. Czas ludzi jest zasobem (późniejszy Resource Engine).

---

## 8. Dane

| Kategoria | Gdzie głównie | Wrażliwość | Dostępność | Integralność |
|---|---|---|---|---|
| Pracownicy (kadry) | HR, Entra/AD, M365 | wysoka (osobowe) | średnia (24 h) | wysoka |
| Użytkownicy systemów (konta, role) | AD, Entra, aplikacje | wysoka (klucze dostępu) | **krytyczna** | **krytyczna** |
| Klienci (firmy, umowy) | ERP, SharePoint, CRM-lekki | średnia–wysoka | średnia | wysoka |
| Kontakty klientów | M365, portal, ERP | wysoka (osobowe / B2B) | średnia | wysoka |
| Dane operacyjne przesyłek | WMS, TMS, hub, portal | średnia; utrata = chaos operacyjny | **krytyczna** | **krytyczna** (zła lokacja = zły towar) |
| Dokumentacja handlowa | SharePoint, file services | średnia | niska–średnia | średnia |
| Dane finansowe | ERP, finanse, poczta FV | wysoka | średnia (48 h) | wysoka |
| Konfiguracje IT | AD, firewall, repo MSP, wiki | wysoka | wysoka dla recovery | **krytyczna** |
| Logi bezpieczeństwa | SIEM, EDR, archiwum | średnia (śledztwo) | wysoka dla IR | wysoka (antytampering) |

Scoring RODO **nie** jest w tym dokumencie. World Bible tylko mówi, że dane osobowe i operacyjne **są** i **gdzie** żyją — żeby później dało się oddzielić „wyciek” od „niedostępność” od „fałszywy status”.

---

## 9. Fog of war (zdolność świata, nie atak)

Każdy ważny element ma **prawdę silnika** i **to, co NEXORA może zobaczyć**. Poniżej zdolności obserwacji, nie fabuła kampanii.

| Element | Ground truth (silnik może trzymać) | Co NEXORA zwykle widzi |
|---|---|---|
| Konto | skompromitowane / sesja przejęta / czyste | logowanie, MFA success/fail, zgłoszenie usera „to nie ja”, alert SOC |
| Host | kontrola atakującego / czysty / izolowany | telemetria EDR, izolacja, użytkownik „komp dziwnie działa” |
| Sieć | tunel, skok, odcięty segment | log firewalla, VPN up/down, „nie działa WMS” bez przyczyny |
| WMS | sprawny / zdegradowany / stoi / dane sfałszowane | błąd UI, kolejka dokumentów, skarga zmiany — nie „kto wpisał lokację” |
| Integracje | zlecenia idą / stoją / idą z błędnym payloadem | brak pliku EDI, 5xx, telefon klienta |
| Backup | kompletny / niekompletny / ten sam wektor dostępu | job OK/FAIL; **nie** widać od razu, czy kopia jest użyteczna |
| Dostawca | sesja legalna / nadużyta | log jump hosta, ticket „jesteśmy na bramce” |
| Świadomość | IC zna skalę / nie zna | inbox, SOC, plotka z rampy, milczenie regionu |

Zasada: **obserwacja nie tworzy faktu**. Fakt może istnieć bez alertu. Alert może być mylny.

---

## 10. Kontrolki bezpieczeństwa (baseline do gry)

Gracz ma dźwignie, które można użyć dobrze, źle, przeciążyć albo stracić.

| Kontrolka | Użycie | Złe użycie | Ominięcie / utrata |
|---|---|---|---|
| MFA | blokuje nowe sesje czyste | lockout zmiany magazynu | wyjątki serwisowe, przejęta sesja już wydana |
| EDR isolate | odcina stację | izolacja serwera WMS / skanera „bo alert” | brak agenta na OT |
| SIEM / SOC | timeline, priorytet | pogoń za szumem | utrata logów albo łączności z SOC |
| Segmentacja / ACL | odcina VLAN, VPN dostawcy | odcina DC razem z atakiem | dziury regionalne, flat OT |
| Backup + vault | recovery | restore na zainfekowane, za wcześnie | ten sam login do vaultu |
| Procedura IR / war room | tempo i ślad decyzji | teatr bez poleceń | brak ludzi o 03:00 |
| Dostęp just-in-time admin | ogranicza privilege | nikt nie wejdzie, gdy break-glass leży w szafie | stałe Domain Admin na co dzień (dług) |
| Komunikacja kryzysowa | zaufanie | sprzeczne statusy | poczta wyłączona, plotka wygrywa |

---

## 11. Słabości strukturalne (potencjał, nie scenariusz)

Ograniczona lista. **Nie** wskazujemy, która wejdzie do kampanii V1.

1. **Most hybrydowy** — sync i dwa światy tożsamości; blokada po jednej stronie nie znaczy blokady po drugiej.  
2. **Konta serwisowe** — szerokie, bez MFA, znane wielu dostawcom.  
3. **Nierówna segmentacja** — DC wygląda nowocześnie, region i OT mają mostki.  
4. **Zawsze włączony dostęp vendorów** — WMS, automatyka, MSP.  
5. **Legacy hub** — stare konektory EDI/API, wspólne sekrety, słabszy nadzór.  
6. **Vault nie w pełni poza domeną** — element immutable jest, ale operacje restore często z tej samej tożsamości admina.  
7. **Telemetria ślepa na magazyn** — skanery i automatyka słabo w EDR/SIEM.

To są **możliwości** świata. Kill chain, wektor i kolejność — osobna karta produktowa, nie W-01.

---

## 12. Graf Digital Twin V1 (logiczny)

**29 węzłów.** Nie kod. Mission Control ma czytać ten poziom, nie każdy switch.

Legenda: **HARD** = bez tego nie działa. **SOFT** = działa zdegradowanie.

| Node | Hard | Soft | Wpływ biznesowy |
|---|---|---|---|
| `entra-id` | internet-edge | identity-sync, siem | M365, część SaaS i MFA |
| `active-directory` | net-hq **lub** net-dc (replikacja) | identity-sync | stacje, udziały, app on-prem |
| `identity-sync` | entra-id, active-directory, sieć | — | rozjazd kont i blokad |
| `m365` | entra-id, internet-edge | — | poczta, Teams, war room, mail do klienta |
| `internet-edge` | — (punkt wejścia) | — | internet, SaaS, SOC, część backupu chmurowego |
| `vpn-access` | internet-edge, entra-id (MFA) | — | zdalni pracownicy i część adminów |
| `net-hq` | internet-edge | vpn-access | biuro, finanse, część IT |
| `net-dc` | internet-edge (dla chmury), lokalny rdzeń | net-hq | cały magazyn 24/7 |
| `net-regional` | internet-edge | net-dc (centralne app) | 3 lokalizacje; da się jechać lokalnie krótko |
| `wifi-staff` | net-hq / net-dc | — | wygoda; DC 24/7 nie stoi na Wi-Fi |
| `vendor-access` | vpn-access **lub** jump przy edge | tożsamość serwisowa | support albo otwarte drzwi |
| `dc-compute` | net-dc, active-directory | edr, backup-prod | hosty WMS/ERP/TMS on-prem |
| `warehouse-devices` | net-dc (VLAN OT) | wms, edr | skan, etykieta, terminal |
| `warehouse-automation` | net-dc OT, zasilanie (poza twin IT) | wms | sortownia / przenośniki |
| `wms` | dc-compute, active-directory, net-dc | warehouse-automation, edr, integration-hub | picking / loading |
| `tms` | dc-compute **lub** SaaS+entra, tożsamość | wms, integration-hub | dispatch i trasy |
| `integration-hub` | internet-edge, konta serwisowe, net-hq/dc | erp | zlecenia i statusy |
| `erp` | dc-compute, tożsamość | integration-hub | stany, master data |
| `finance` | erp, m365, tożsamość | — | faktury, nie rampa |
| `hr` | entra-id / m365 | active-directory | sezonowi, nie outbound dnia 0 |
| `file-services` | active-directory, net-hq/dc | backup-prod | SOP, CMR, etykiety awaryjne |
| `customer-portal` | integration-hub, entra-id, internet-edge | wms/erp (dane) | self-service i telefony |
| `edr` | internet-edge (chmura EDR), agenci | siem | izolacja stacji, ślepota bez agentów |
| `siem` | internet-edge, źródła logów | soc-external | świadomość |
| `soc-external` | siem, m365/telefon | — | triaż 24/7 |
| `msp-infra` | vendor-access, dc-compute | backup-prod | ręce na hostach, konflikt priorytetów |
| `backup-prod` | dc-compute, tożsamość, sieć do vault | — | joby kopii |
| `backup-vault` | (częściowo) izolacja od AD/Entra | backup-prod | last resort |
| `regional-ops` | net-regional, wms/tms (centralne) | ludzie na miejscu | 3 site’y jako jeden węzeł biznesowy |

`regional-ops` jest węzłem **biznesowym** (trzy lokalizacje), nie trzema kopiami całego grafu.

---

## 13. Zgodność ze światem zagrożeń (bez range’u)

Świat ma unieść później — jako **możliwość**, nie jako zaplanowany przebieg:

- zakłócenie operacji magazynu i transportu przez IT,
- presję ransomware / utraty dostępności,
- presję na dane (wyciek ≠ postój rampy),
- phishing i nadużycie tożsamości jako **klasa** zdarzeń,
- zależność od stron trzecich,
- konieczność response **i** recovery.

Nie opisujemy technik ofensywnych. Nie budujemy Cyber Range.

---

## 14. Czego W-01 świadomie nie zamyka

- Która słabość wejdzie do kampanii V1.  
- Kolejność etapów ataku.  
- Rubryka RODO / KSC (osobna karta prawa).  
- Liczba punktów i dokładne mnożniki wydajności.  
- Schema JS i silnik Twin.

---

## Otwarte decyzje LGD (świat)

1. Czy nazwa **NEXORA Logistics S.A.** zostaje na pilotaż.  
2. Czy trzy regiony zostają jednym węzłem `regional-ops`, czy Mission Control ma je rozdzielać.  
3. Czy TMS jest on-prem (ten sam `dc-compute`) czy SaaS — zmienia HARD do Entra vs AD.  
4. Czy vault ma być **faktycznie** poza wspólną tożsamością, czy tylko „na slajdzie” (słabość 6).  
5. Czy SOC zewnętrzny może izolować stacje sam, czy tylko rekomenduje IC.

===== CYBER-INCIDENT-V1.md =====
# CYBER COMMAND — Incident Canon V1

Status: **kanon ukrytego przebiegu** (nie silnik, nie kod, nie UI)  
Data: **2026-09-11**  
Karta: **W-02**  
Organizacja: **COMPANY-01** (former codename: NEXORA)  
Świat: `docs/games/cyber/CYBER-WORLD-V1.md`  
Handoff: `docs/games/cyber/CYBER-HANDOFF.md`

To jest **prawda świata** i system możliwości.  
Nie jest to film, playbook ofensywny ani Incident Engine.

MVP: SOLO Incident Commander. C-04 pozostaje zablokowane.

---

## Decyzje LGD obowiązujące ten kanon

Nakładka na W-01 (W-01 nie był w tej karcie przepisywany):

1. W dokumentacji: **COMPANY-01**. NEXORA tylko jako dawny kryptonim.  
2. Trzy regiony = jeden węzeł `regional-ops` (UI może pokazać rozdzielone lokalizacje).  
3. **TMS = SaaS + Entra ID.** WMS = AD / DC / `dc-compute`. Dwie domeny awarii.  
4. **`backup-vault` ma rzeczywistą separację** od produkcyjnego AD/Entra. Staging, management i repozytoria online **mogą** paść. Vault immutable **nie** ginie sam z kompromitacji AD.  
5. SOC może **sam** izolować **jeden workstation** przy alercie wysokiej pewności. Nie może: serwera krytycznego, segmentu, masówki, WMS/TMS/ERP, kont uprzywilejowanych o dużym znaczeniu — bez IC / właściciela.

Słabość W-01 „vault na slajdzie” jest **uchylona**. Zostaje słabość: **operacje restore i backup-prod** są w strefie produkcyjnej.

---

## 1. Adversary profile

**Nazwa TTX:** ORBIT MARGIN (fikcyjna; nie jest realną grupą).

| Cecha | Poziom do symulacji |
|---|---|
| Cel ekonomiczny | okup + dźwignia (postój operacji i strach o dane klientów) |
| Cierpliwość | średnia–wysoka: cicho, dopóki mają czas i niski szum |
| Kompetencja | profesjonalny przestępca ekonomiczny, nie mocarstwo |
| Stealth | preferują niewykrycie do momentu dźwigni |
| Cel biznesowy | pieniądze; COMPANY-01 jest celem, bo logistics = presja czasu, nie bo „łatwy łup” |
| Przejście ciche → destrukcja | gdy mają **albo** (reach na WMS **lub** TMS + materiał do szantażu), **albo** rosnący `detection_pressure` przy już zdobytym persistence |

Nie skrypt. Jeśli stracą jedyny dostęp i nie mają persistence — **mogą odejść**. Jeśli gracz ich przypiera, mogą przyspieszyć destrukcję **gorzej przygotowaną** (mniej danych, więcej hałasu).

Brak: kodu, payloadów, komend, instrukcji ominięcia kontroli.

---

## 2. Ground Truth Timeline (przebieg bazowy)

Zakres główny: **T0 … T0+480** (8 h). T0 = piątek 16:00, zmiana DC jedzie, HQ domyka tydzień.

Przebieg bazowy zakłada **opóźnioną / niepełną** reakcję. Każdy skok etapu ma **warunek**. Jeśli warunek nie jest spełniony — punkt się **nie wydarza**.

| # | simTime | Ground truth | Cel przeciwnika | Węzły | Observable? | Przerwanie? |
|---|---|---|---|---|---|---|
| 1 | 0 | Użytkownik operacji (koordynator zleceń, Entra) otwiera wiarygodną wiadomość służbową i oddaje sesję chmurową | ACCESS na M365 | `m365`, `entra-id` | częściowo: logowanie, później zgłoszenie | tak — świadomość usera / blokada zanim sesja żyje |
| 2 | 20 | Sesja chmurowa aktywna; skrzynka i Teams w zasięgu | utrzymać ACCESS, rozpoznać ludzi | `m365` | LOW: nietypowa geolokacja / nowy klient | tak — revoke sesji, reset, MFA refresh |
| 3 | 35 | **FP równoległy:** dyrektor sprzedaży loguje się z hotelu (legalna podróż) | — | `entra-id`, `vpn-access` | tak, wygląda jak #2 | analiza, nie automatyczna masakra kont |
| 4 | 50 | Przeciwnik czyta korespondencję zleceń i listę kontaktów klientów w skrzynce / SharePoint | DATA ACCESS (kontakty, operacja) | `m365` | LOW–MEDIUM: nietypowe pobrania | tak — blokada konta + audit |
| 5 | 70 | Jeśli sesja żyje: reguła / przekierowanie w skrzynce (**persistence chmurowe**) | PERSISTENCE | `m365` | MEDIUM: reguła poczty (Identity/M365) | tak — czyszczenie skrzynki, nie sam reset hasła |
| 6 | 90 | Próba TMS SaaS tym samym kontem Entra (rola dyspozytorska ograniczona) | REACH na transport bez AD | `tms`, `entra-id` | MEDIUM: nietypowy login TMS | tak — blokada Entra / rola TMS |
| 7 | 110 | SOC: alert korelacji poczta+login (pewność średnia) | — | `siem`, `soc-external` | tak | IC: eskalacja vs „poczekaj na usera” |
| 8 | 130 | Jeśli brak revoke: drugi mailbox (asystent COO) przez zaufaną korespondencję wewnętrzną | ACCESS×2 | `m365` | MEDIUM | tak — świadomość phishingu wewnętrznego |
| 9 | 150 | **FP:** skaner w DC gubi agenta EDR (stary obraz) | — | `warehouse-devices`, `edr` | tak: host „offline” | nie izolować automatyki / WMS |
| 10 | 170 | Szukanie w poczcie IT wątków dostawcy WMS / MSP (wiedza, nie magiczne DA) | mapa vendor-access | `m365`, `vendor-access` | LOW | tak — ograniczenie skrzynki IT |
| 11 | 190 | Jeśli persistence + brak containment: wyższy przywilej Entra **z istniejącego błędu delegacji** (rola pomocy technicznej / app), nie „bo fabuła” | PRIVILEGE (Entra, nie AD) | `entra-id` | HIGH jeśli Identity patrzy na role | tak — recertyfikacja ról, break-glass nie na czacie |
| 12 | 210 | Staging backupu online dostaje nieudane / dziwne joby (produkcja, **nie vault**) | osłabić RECOVERY, nie skasować last resort | `backup-prod` | MEDIUM: job FAIL | tak — odciąć backup-prod od tożsamości prod, vault zostawić |
| 13 | 230 | Jeśli Entra privileged i vendor-access otwarty: sesja na jumpie „jak support” | REACH w stronę DC bez łamania WMS od razu | `vendor-access`, `net-hq` | MEDIUM: log jump | tak — cut vendor VPN (koszt supportu) |
| 14 | 250 | COO widzi pierwsze opóźnienia okien TMS (jeśli #6 nieucięte) | presja biznesu | `tms` | tak, bez „ataku” w nazwie | decyzja: TMS read-only / stop vs jedziemy |
| 15 | 270 | Jeśli jump żywy **i** słabe konto serwisowe WMS nadal ważne: sesja aplikacyjna WMS (nie Domain Admin) | REACH WMS | `wms`, `dc-compute` | LOW–MEDIUM: nietypowy user app | tak — wyłączyć konto serwisowe (koszt WMS) |
| 16 | 290 | Pakiet danych operacyjnych + kontaktów oznaczony jako **przygotowany do wyniesienia** (jeszcze nie potwierdzony wychód) | EXFIL przygotowanie | `m365`, `integration-hub` | LOW | tak — DLP/reguły, odcięcie huba |
| 17 | 310 | Jeśli #16 nieprzerwane: częściowa eksfiltracja (kontakty + wycinek zleceń) | EXFIL partial | `internet-edge`, `m365` | MEDIUM: volume / atypical egress | tak — edge rules; za późno na „nic nie wyszło” |
| 18 | 330 | Detection pressure rośnie (SOC + user + TMS owner) | decyzja: cisza albo przyspieszenie | `soc-external` | tak | komunikacja vs cisza operacyjna |
| 19 | 350 | Jeśli WMS reach **lub** (TMS reach + exfil): zdolność destrukcji **przygotowana**, nie odpalona | DISRUPTION CAPABILITY | `wms` i/lub `tms` | nie (prawda ukryta) | tak — isolate app / segment **z kosztem** |
| 20 | 370 | Magazyn zgłasza „WMS wolny / dziwne etykiety” **tylko jeśli** #15 zaszło | — | `wms`, `warehouse-devices` | tak | tryb ręczny vs gaszenie IT |
| 21 | 390 | Notatka okupu / blokada plików w HQ **tylko jeśli** disruption capability + (brak twardego containment **lub** wysoki detection_pressure) | przejście destrukcyjne | `file-services`, `net-hq` | HIGH | izolacja HQ ≠ wyłączenie AD w DC |
| 22 | 410 | Jeśli WMS w zasięgu i brak twardego cut: zakłócenie WMS (niedostępność / integralność etykiet) | postój DC | `wms` | HIGH | tryb 25–35%; nie restore w 5 min |
| 23 | 430 | TMS SaaS: jeśli konto/rola nieucięte — sabotaż okien / fałszywe anulacje | flota w chaosie | `tms` | HIGH | odciąć Entra od TMS, jedź ręcznie 40–50% |
| 24 | 450 | Klient strategiczny i portal: statusy kłamią albo milczą | presja reputacji | `customer-portal`, `integration-hub` | tak | comms vs cisza |
| 25 | 470 | Vault **dostępny jako dźwignia**; restore WMS/AD nie jest natychmiastowy i wymaga czystego punktu | RECOVERY | `backup-vault`, `backup-prod` | vault: tak że „jest”; czystość punktu: niepewna | kolejność P1, dowody, ludzie |
| 26 | 480 | Stan końcowy zależy od przerw, nie od zegara | — | — | AAR | — |

**26 punktów prawdy.** Punkty 21–23 **nie spadają z kalendarza** — tylko ze stanu przeciwnika + braku skutecznej reakcji.

---

## 3. Warunki etapów (atak nie jest nieunikniony)

| Następny fakt | Wymaga |
|---|---|
| Persistence skrzynki | żywa sesja ≥ ~70 min **lub** brak audytu reguł |
| Drugie konto | pierwsze żywe + korespondencja wewnętrzna nieucięta |
| Privilege Entra | persistence **lub** drugie konto **oraz** istniejąca zła delegacja **oraz** brak recertyfikacji |
| REACH TMS | konto Entra z rolą TMS **lub** skradziona sesja TMS; nie wymaga AD |
| REACH WMS | ścieżka vendor/jump **lub** konto serwisowe AD **oraz** brak cut vendor / disable service |
| Privilege AD / DA | **nie** wynika z samego phishu; tylko ze ścieżki on-prem + błędu konta serwisowego / admina — może **nie nastąpić** w V1 |
| EXFIL partial | DATA ACCESS + czas + brak ograniczenia egress |
| DISRUPTION | (REACH WMS **lub** REACH TMS) **oraz** (EXFIL partial **lub** wysoki detection_pressure) |
| Ransomware / blokada HQ | DISRUPTION CAPABILITY **oraz** (brak twardego containment HQ **lub** decyzja przyspieszenia) |
| Utrata vault | **nie** z kompromitacji AD; tylko z osobnego, świadomego błędu proceduralnego (poza baseline’em V1) |

Wczesne: revoke + reset + czysta skrzynka + brak drugiego konta → **koniec incydentu** (CLEAN CONTAINMENT), jeśli persistence nie zdążył.

---

## 4. Attack state (fakty dla przyszłego Incident Engine)

Nie paski 0–100. Silnik ma znać **fakty dyskretne**:

| Fakt | Wartości (koncepcja) | Znaczenie |
|---|---|---|
| `access` | none / cloud_user / cloud_multi | czy jest sesja Entra/M365 |
| `persistence` | none / mailbox / device / cloud_app | czy reset hasła wystarczy |
| `privilege_entra` | user / helpdesk / privileged | czy mogą ruszać rolami / TMS szerzej |
| `privilege_ad` | none / service / admin | osobna domena; default V1: none lub service |
| `reach` | zestaw: `hq_ws`, `tms`, `vendor_jump`, `wms`, `hub`, `backup_prod` | gdzie mogą działać |
| `data_access` | none / mailbox / customer_contacts / ops_slice / finance_mail | co widzieli |
| `exfiltration` | none / staged / partial / substantial | co wyszło |
| `disruption_capability` | none / hq_files / tms / wms / combined | czy mogą zniszczyć |
| `disruption_active` | które węzły już stoją / kłamią | skutek, nie intencja |
| `detection_pressure` | low / rising / high | czy przyspieszają |
| `vault_integrity` | intact (baseline) | nie ginie z AD |
| `backup_prod_status` | ok / degraded / untrusted | restore „szybki” może kłamać |

Każda zmiana stanu = poprzedni stan + zdolność + (brak reakcji | reakcja gracza).

---

## 5. Ścieżki

### PRIMARY (bazowa, wolny obrońca)

Phish → sesja Entra → persistence skrzynki → TMS SaaS → privilege Entra (delegacja) → szum backup-prod → jump vendorski → WMS app → exfil częściowy → destrukcja HQ + WMS i/lub TMS → kryzys operacyjny → recovery z vaultem i kolejką P1.

### ALT A — czyste cięcie w chmurze (wczesne zwycięstwo)

Do ~T+90: revoke wszystkich sesji, reset, audyt reguł, user potwierdza „to nie ja”, TMS bez loginu.  
`persistence = none`, `access = none` → ORBIT MARGIN **odchodzi**.  
Trudne, jeśli IC czeka na „pewność” albo goni FP podróży (#3).

### ALT B — chmura ucięta, persist został

Hasło zmienione, sesja żyje / reguła żyje / drugie konto. Atak **cichnie i wraca** przez skrzynkę lub asystenta COO. Gracz myśli, że wygrał.

### ALT C — twardy cut operacyjny

IC odcina AD, segment DC albo WMS „na wszelki wypadek” zanim REACH WMS istnieje. Atak w chmurze może żyć (TMS/Entra). Magazyn spada do 25–35% **z decyzji obrońcy**. Ending: MAJOR BUSINESS INTERRUPTION przy ograniczonym breach.

### ALT D — vendor zostaje otwarty

Chmura posprzątana, jump WMS/MSP nie. Przeciwnik **zmienia cel** na on-prem. PRIMARY bez pięknego privilege Entra.

Nie ma obowiązku „atak musi trwać do ransomware”.

---

## 6. Observability (fundament C-04, bez kodu)

| Ground truth | Sygnały | Pewność | Kto widzi |
|---|---|---|---|
| Sesja Entra przejęta | nowe logowanie, client, pora; user „kliknąłem / nie ja” | LOW samotnie; MEDIUM z userem | SOC, Identity, user, IC po eskalacji |
| Persistence skrzynki | reguła, forwarding, inbox rule | HIGH jeśli ktoś **sprawdzi** skrzynkę | Identity/M365; SOC nie zawsze |
| Login TMS | audyt SaaS, nietypowa pora | MEDIUM | TMS owner, Identity, SOC jeśli podłączone |
| Drugie konto | analogiczne logowanie + mail wewnętrzny | MEDIUM | SOC, Identity |
| Privilege Entra | zmiana ról, PIM, consent | HIGH | Identity; IC tylko gdy mu powiedzą |
| Jump vendorski | log VPN/jump, ticket „jesteśmy na bramce” | MEDIUM | Network, MSP, WMS owner |
| Sesja WMS app | user serwisowy o dziwnej porze | LOW–MEDIUM | WMS owner; EDR słabo na app |
| Staging exfil | volume, nietypowy egress | MEDIUM | Network/SOC; nie „co to za plik” |
| Exfil partial | to samo + czas | HIGH dopiero po złożeniu | SOC, IC, później DPO |
| Backup-prod chory | job FAIL, dziwny harmonogram | MEDIUM | Infra; **nie** znaczy „vault martwy” |
| Vault intact | procedura off-domain, osobny dostęp | HIGH dla Infra/BC jeśli zapytani | nie na slajdzie SOC |
| Destrukcja HQ | użytkownicy, EDR | HIGH | wszyscy |
| WMS kłamie / stoi | zmiana, etykiety, automatyka | HIGH operacyjnie, LOW jako „atak” | Warehouse, WMS owner |
| Legalna podróż (#3) | to samo co złe logowanie | LOW aż do kalendarza / rozmowy | SOC vs HR/asystent |
| EDR skanera offline (#9) | host missing | LOW jako atak | SOC, Warehouse |

Dwa niezależne sygnały o **tym samym koncie** podnoszą pewność. Jeden sygnał = analiza, nie wyrok.

---

## 7. Fałszywe / dwuznaczne (mało)

1. **Podróż sprzedaży (#3)** — obce IP + MFA success.  
2. **Skaner bez EDR (#9)** — „martwy agent” w szczycie zmiany.  
3. **Opóźnienie rampy** — może być atak TMS **albo** zwykły brak kierowcy (jeden incydent bez drugiego sygnału).  
4. **Ticket dostawcy WMS** — legalny patch window w piątek wieczór **albo** nadużycie jumpa.

Nie więcej. Celem jest analiza, nie labirynt.

---

## 8. Decision windows (12)

Okna zamyka czas **lub** zmiana attack state.

| ID | Co wie gracz | Co jest prawdą | Co da się zrobić (klasa, nie katalog) | Koszt działania | Koszt czekania | Zamknięcie |
|---|---|---|---|---|---|---|
| DW1 | Alert logowania + może user | Sesja przejęta lub podróż | potwierdzić tożsamość, nie masowe blokady | czas Identity, irytacja usera | persistence zdąży | ~T+70 jeśli skrzynka nieaudytowana |
| DW2 | User: „kliknąłem / to nie ja” | ACCESS | revoke + reset + audyt reguł | lockout jednej osoby | drugie konto, TMS | ~T+90–130 |
| DW3 | SOC prosi o isolate 1 WS | stacja HQ może być czysta lub nie | SOC może sam przy HIGH; IC przy niższej pewności | utrata 1 laptopa | jeśli to wektor — persist device | pierwsze 2 h |
| DW4 | Dwa logowania „dziwne” | jedno atak, jedno podróż | rozdzielić, nie blokować całej sprzedaży | czas na telefon | zablokowanie legalnego CFO-path analog | ~T+120 |
| DW5 | TMS „ktoś wszedł” | REACH TMS albo legalny dispatch | obciąć rolę Entra / TMS read-only | 40–50% transportu ręcznie | sabotaż okien | ~T+250–430 |
| DW6 | Jump / vendor online | legalny support lub REACH | cut vendor-access | brak rąk WMS/MSP | ścieżka do WMS | ~T+230 |
| DW7 | Job backup FAIL | backup-prod chory, vault żywy | nie restore w ciemno; chronić vault | opóźnienie recovery | restore brudny / utrata zaufania do kopii | ~T+210+ |
| DW8 | Privilege / dziwna rola Entra | eskalacja chmurowa | zdjąć delegację, nie wyłączać Entra w całości | część SaaS i TMS | szeroki REACH chmury | ~T+190+ |
| DW9 | Magazyn: WMS dziwny | REACH WMS lub awaria dnia | isolate WMS vs tryb ręczny 25–35% | outbound | integralność lokacji / destrukcja | ~T+370–410 |
| DW10 | COO: „jedziemy, bo SLA” | może jeszcze nie ma disruption | świadomy risk-accept vs cut | kara umowna / reputacja | utrata dźwigni containment | dopóki disruption_capability rośnie |
| DW11 | Egress / DPO: „czy dane?” | staged lub partial | ograniczyć hub/edge; nie obiecywać „nic nie wyszło” | zlecenia 20–30% ręcznie | substantial exfil | ~T+290–330 |
| DW12 | Destrukcja / okup / presja CEO | vault intact, prod leży | kolejność restore, dowody, comms | czas ludzi, RTO | restore za wcześnie, utrata śladu | T+450+ (recovery) |

---

## 9. Konflikty security vs operations

Wynikają z WORLD V1 + LGD (dwie tożsamości, TMS SaaS).

1. **Isolate / stop WMS** vs **utrzymać picking 24/7** (25–35% ręcznie, BHP, backlog).  
2. **Wyłączyć / twarde AD** vs **sesje DC i etykiety** (AD down = 1–3 h i zmiana pada).  
3. **Odciąć hub EDI/API** vs **przyjmować zlecenia** (20–30% mailem, klient strategiczny).  
4. **Cut vendor-access** vs **dostawca ma naprawić WMS**.  
5. **TMS Entra cut** vs **dispatch w piątek wieczór** (SaaS; WMS może jeszcze jechać).  
6. **Restore już** vs **najpierw containment i czysty punkt** (COO vs Infra).  
7. **Komunikat do klienta** vs **cisza, bo nie wiemy o exfil**.

Nie ma jednej idealnej odpowiedzi w każdym oknie. **Piątka kanoniczna do raportu:** 1–5.

---

## 10. Backup / recovery (nie przycisk WIN)

- `backup-vault` **przeżywa** kompromitację AD. To szansa, nie zwycięstwo.  
- `backup-prod` i konsola restore mogą kłamać, stać albo być nieufne (#12, DW7).  
- Kolejność: tożsamość właściwej domeny → sieć DC → WMS (P1); hub + TMS Entra (P2); M365 (P3). TMS nie wraca z AD restore — to SaaS.  
- Niepewność: który punkt jest **sprzed** REACH WMS / **sprzed** sabotażu TMS.  
- Ludzie: Infra + WMS owner + Identity nie robią trzech restore naraz.  
- COO chce rampę; Infra chce obraz.  
- Dowody: logi SIEM i złoty obraz vaultu nie idą do tego samego „formatu dysku”.  
- Ręczne tryby trzymają firmę **godziny**, nie dni bez narastającego błędu.

---

## 11. Presja komunikacji (kiedy / dlaczego)

| Aktor | Od kiedy (orientacja) | Dlaczego |
|---|---|---|
| SOC | T+90–110 | alert, prośba o isolate 1 WS lub eskalacja |
| User / Identity | T+20–130 | MFA, „to nie ja”, lockout |
| TMS owner | T+90 / T+250 | dziwny login, potem okna |
| Warehouse Ops | T+370+ albo gdy IC tnie WMS | wydajność, BHP, etykiety |
| Transport Ops | gdy TMS ucięty lub okna kłamią | auta, kary |
| COO | T+250+ | SLA, weekendowy outbound |
| Dostawca WMS / MSP | gdy jump tną lub WMS stoi | „wpuśćcie nas / to nie my” |
| Klient strategiczny | T+430–450 | statusy, spóźnienia |
| Pracownicy | poczta/Teams/plotka z rampy | „czy pracujemy?” |
| CEO | gdy COO albo klient albo destrukcja HQ | reputacja, mówić / nie mówić |
| DPO / Legal | gdy exfil staged/partial albo IC potwierdza dostęp do skrzynek klientów | świadomość, nie zegar 72 h w tym dokumencie |
| Media | tylko jeśli wyciek narracji lub duży postój widoczny z zewnątrz | zwykle późno; nie obowiązkowe w każdej ścieżce |

Dialogów brak — tylko wektory presji.

---

## 12. Wyzwalacze regulacyjne (fakty, nie zegar)

Późniejsza karta prawa może ocenić m.in.:

| Fakt scenariuszowy | Dlaczego ma znaczenie |
|---|---|
| Dostęp do skrzynki z kontaktami klientów / danymi pracowników | potencjalny dostęp do danych osobowych |
| `exfiltration = partial` lub więcej | potwierdzenie wyniesienia (gdy IC **wie**) |
| Postój WMS / TMS / istotna usługa logistyczna | istotność, ciągłość |
| Moment, w którym IC / DPO **uznaje** incydent / naruszenie | świadomość ≠ czas ataku |
| Czy portal podawał fałszywe statusy | integralność wobec klienta (nie to samo co RODO) |

**Nie** wpisujemy tu startu 72 h ani obowiązku KSC. Tylko fakty, które nadejdą do walidacji.

---

## 13. Zakończenia (nie WIN/LOSE)

| Ending | Gdy mniej więcej |
|---|---|
| **CLEAN CONTAINMENT** | ACCESS ucięty wcześnie, persist brak, brak exfil, brak cut DC |
| **LIMITED BREACH** | 1–2 konta, persist posprzątany, brak WMS, brak substantial exfil |
| **DATA BREACH WITHOUT MASS DISRUPTION** | exfil partial+, operacja jedzie (może TMS poturbowany) |
| **RANSOMWARE WITH SUCCESSFUL RECOVERY** | destrukcja była, vault + kolejność zadziałały, outbound wraca w RTO gry |
| **MAJOR BUSINESS INTERRUPTION** | DC/TMS leżą długo — często z **nadmiarowego** cięcia obrońcy |
| **COMPOUND CRISIS** | disruption + exfil + sprzeczne comms + restore w ciemno |

AAR: co uratowano i **jakim kosztem** (wydajność, zaufanie, dowody, prawo).

---

## 14. Kontrfaktyki (AAR)

Bez liczb „prawdopodobieństwa silnika” — kierunek skutku:

1. **Revoke+audyt reguł ≤ T+70** → zwykle brak persist → droga do CLEAN.  
2. **Blokada Entra TMS ≤ T+110** → brak REACH TMS; WMS może być nadal czysty.  
3. **Cut vendor ≤ T+230** przy braku konta serwisowego WMS → brak REACH WMS.  
4. **Twarde AD/WMS ≤ T+200 bez REACH WMS** → MAJOR INTERRUPTION z decyzji gracza.  
5. **Hub/edge na EXFIL staged (T+290)** → partial może nie powstać.  
6. **Restore z backup-prod przed oceną vaultu** → brudny powrót, COMPOUND.  
7. **Cisza wobec klienta przy kłamliwym portalu** → zaufanie gorsze niż krótki uczciwy status.  
8. **Wysoki detection_pressure bez containment** → wcześniejsza, brudniejsza destrukcja.

---

## 15. Zasada przyczynowości

Zakazane: „nagle Domain Admin, bo akt”.  
Dozwolone: Entra helpdesk, bo zła delegacja już była; WMS app, bo konto serwisowe i otwarty jump; TMS, bo to samo Entra co poczta.

ORBIT MARGIN nie dostaje AD „w prezencie”. Jeśli gracz utnie chmurę i jump — **nie muszą** dostać magazynu.

---

## 16. Poziom TTX

Dokument mówi: co jest prawdą, co widać, jaki skutek, jaka klasa odpowiedzi.  
Nie mówi: jak przejąć konto, jak eskalować, jak iść w poprzek, jak wyłączyć EDR, jak postawić ransomware.

---

## Otwarte decyzje LGD (incydent)

1. Czy pierwsze konto zostaje **koordynatorem zleceń** (TMS+poczta), czy inna persona.  
2. Czy V1 w ogóle dopuszcza `privilege_ad` powyżej service, czy AD zostaje tylko terenem obrony.  
3. Czy notatka okupu jest widoczna graczowi, czy tylko skutek (pliki/WMS).  
4. Czy klient strategiczny ma **imienną** presję w V1, czy ogólny „kluczowy kontrakt”.  
5. Czy CLEAN CONTAINMENT kończy sesję wcześniej niż 8 h, czy reszta to debrief w war roomie.

===== CYBER-MISSION-CONTROL-V1.md =====
# CYBER COMMAND — Mission Control V1

Status: **projekt doświadczenia** (nie kod, nie React, nie silnik)  
Data: **2026-09-11**  
Karta: **W-03**  
Organizacja: **COMPANY-01** · klient: **CLIENT-ALPHA**  
Świat: `CYBER-WORLD-V1.md` · Incydent: `CYBER-INCIDENT-V1.md`  
Handoff: `docs/games/cyber/CYBER-HANDOFF.md`

C-04 i implementacja UI pozostają **zablokowane**.  
Najpierw idealny produkt. TARGETED UI REUSE REVIEW — osobna karta.

Desktop first: **1440p / ~1920×1080**. Laptop musi się zmieścić. Mobile nie jest V1.

---

## 1. Wizja

Gracz jest **Incident Commanderem** w żywym kryzysie, nie uczniem w LMS.

Emocja: Mission Control + kokpit + SOC/NOC + crisis room.  
Estetyka: ciemna, precyzyjna, gęsta, kontrastowa, profesjonalna.

**Nie:** Moodle, BI, admin panel, quiz ABCD, 20 kafelków, czysty SOC-only, neonowy cyberpunk, puste SaaS-karty, science-fiction dla ozdoby.

---

## 2. Siedem pytań (2–3 sekundy)

Główny ekran **COMMAND** musi odpowiadać bez przełączania zakładek:

| # | Pytanie | Gdzie na COMMAND |
|---|---|---|
| 1 | Co właśnie się stało? | ostatni wpis LIVE FEED + pasek MISSION |
| 2 | Co jest teraz najważniejsze? | NEEDS ATTENTION (góra COMMAND STACK) |
| 3 | Co wiem? | SITUATION BOARD (statusy z wiedzy) + EVIDENCE w drawerze |
| 4 | Czego nie wiem? | UNKNOWN / UNCONFIRMED / SUSPECTED na węzłach i w feedzie |
| 5 | Co robi mój zespół? | IN PROGRESS |
| 6 | Jak długo to potrwa? | ETA przy działaniach + SIM TIME |
| 7 | Co muszę zdecydować? | NEEDS ATTENTION + otwarty Action Console |

Jeśli któregoś pytania nie da się zdjąć wzrokiem z COMMAND — za dużo UI.

---

## 3. Ground truth zabroniony w UI

Mission Control czyta **wyłącznie player knowledge**.

Zakaz bezpośredni: etap atakującego, prawdziwy exfil, ukryte persistence, rzeczywista liczba kont, następny cel, flagi scenariusza, „attacker 67%”.

Język pewności (nie fałszywy procent):

| Stan wiedzy | Znaczenie |
|---|---|
| UNKNOWN | brak wiarygodnej obserwacji |
| UNCONFIRMED | jest sygnał, nie złożony |
| SUSPECTED | hipoteza robocza |
| PARTIALLY VERIFIED | dwa niezależne źródła częściowo się zgadzają |
| CONFIRMED | organizacja uznała fakt |

---

## 4–9. Architektura COMMAND

Jeden ekran. Większość czasu tu. Dock otwiera **drawer/overlay** — COMMAND zostaje w tle.

### Wireframe (1920×1080, proporcje)

```
 ~56px MISSION BAR  (pełna szerokość, nigdy się nie chowa)
┌──────────────────────────────────────────────────────────────────────────┐
│ CYBER COMMAND · COMPANY-01     SIM 17:42     INCIDENT ELEVATED          │
│ OPS DEGRADED   ACTIONS 2   CRITICAL 1   DEADLINE —                     │
├────────────┬────────────────────────────────────┬────────────────────────┤
│ LIVE FEED  │         SITUATION BOARD            │ COMMAND STACK          │
│ ~22%       │         ~50%                       │ ~28%                   │
│            │  [ BUSINESS | SYSTEMS |            │ NEEDS ATTENTION        │
│  17:41 SOC │    IDENTITY | SECURITY ]           │  • Identity contain    │
│  HIGH      │                                    │  • CEO sitrep          │
│  Sign-in   │     CLIENT-ALPHA                    │                        │
│  linked…   │          │                         │ IN PROGRESS            │
│            │         EDI/API                    │  Revoke  Identity  8m  │
│  17:17     │          │                         │                        │
│  USER      │    WMS ──┼── TMS (SaaS)            │ RESOURCE PRESSURE      │
│  MEDIUM    │     │         │                    │  SOC ● Identity ●      │
│  „to nie   │    DC      DISPATCH                │  Infra ○ Net ○ Legal ○ │
│   ja”      │                                    │                        │
│            │  węzeł: NORMAL|UNKNOWN|SUSPECTED|  │                        │
│  pin:      │  DEGRADED|ISOLATED|UNAVAIL|RECOV   │                        │
│  CRITICAL  │                                    │                        │
├────────────┴────────────────────────────────────┴────────────────────────┤
│ DOCK  COMMS │ EVIDENCE │ ACTIONS │ PLAYBOOK │ DEADLINES     ~48px        │
└──────────────────────────────────────────────────────────────────────────┘
```

**5 trwałych stref + dock** (dock nie zabiera świata):

1. Mission Bar  
2. Live Incident Feed  
3. Situation Board  
4. Command Stack (Needs / In Progress / Pressure)  
5. Command Dock → drawery  

### Mission Bar

Tylko to, bez czego nie ma dowodzenia:

- CYBER COMMAND · COMPANY-01  
- **SIM TIME** (zegar ścienny nieeksponowany)  
- INCIDENT STATUS: MONITORING / ELEVATED / MAJOR / CRITICAL — **z wiedzy**, nie z hidden stage  
- BUSINESS OPERATIONS: NORMAL / DEGRADED / SEVERE — z obserwacji magazynu/transportu/klienta  
- ACTIVE ACTIONS (liczba IN PROGRESS)  
- OPEN CRITICAL ITEMS (liczba pinów CRITICAL w feedzie / Needs)  
- REGULATORY / RESPONSE — tylko jeśli organizacja **wie**, że zegar istnieje  

Skok silnika (np. 17:10 → 17:42): krótki, czytelny mostek „SIM +32 min” — bez tickania UI.

### Live Incident Feed (lewy puls)

Wpisy: TIME · SOURCE · TYPE · SHORT MESSAGE · CONFIDENCE/STATUS.

Źródła m.in.: SIEM, SOC, admin, user, WMS, TMS, CLIENT-ALPHA, helpdesk, vendor, CEO, DPO, media.

Stany wpisu: NEW → ACKNOWLEDGED → INVESTIGATING → RESOLVED / SUPERSEDED.

**Dyscyplina:** CRITICAL nie tonie. Pin + osobna półka „pinned” na górze feedu. Starsze ADVISORY zwijają się.

Zakaz: „attacker reached lateral movement”.

### Situation Board (centrum)

20–35 węzłów z WORLD V1, **nie** 100 hostów.

Jedna tablica, cztery **projekcje** (nie cztery aplikacje):

| Warstwa | Co łączy |
|---|---|
| BUSINESS | zlecenia CLIENT-ALPHA → hub → WMS → magazyn → TMS → dispatch |
| SYSTEMS | Entra, AD, M365, WMS, TMS, ERP, hub, backup, DC, regional-ops… |
| IDENTITY | users / privileged / service / vendor |
| SECURITY | EDR, SIEM, SOC, vault, edge |

Status węzła **tylko z wiedzy:** NORMAL · UNKNOWN · SUSPECTED · DEGRADED · ISOLATED · UNAVAILABLE · RECOVERING.

Jeśli WMS jest w zasięgu ataku, a firma nie wie — węzeł jest NORMAL albo UNKNOWN, nie „compromised”.

Kliknięcie węzła → **NodeInspector** (drawer), nie nowa strona.

`regional-ops`: jeden węzeł logiczny; w inspectorze można pokazać trzy lokalizacje jako etykiety, nie trzy kopie grafu.

### Command Stack (prawo)

**Needs Attention** — problemy, nie ABCD.  
Pola: WHY NOW · KNOWN IMPACT · TIME PRESSURE. Bez „poprawnej odpowiedzi”.

**In Progress** — rozkaz · kto · ETA (z silnika, później).

**Resource Pressure** — SOC, Identity, Infra, Network, Legal, Comms, Vendor: AVAILABLE / BUSY / OVERLOADED / UNAVAILABLE.

### Command Dock

COMMS · EVIDENCE · ACTIONS · PLAYBOOK · DEADLINES  

Drawer od dołu lub od prawej, **COMMAND widoczny**. Escape zamyka drawer.

---

## 10. COMMS

Centrum komunikacji, nie chat społecznościowy.

Kanały: SOC · IT · MANAGEMENT · OPERATIONS · LEGAL/DPO · VENDORS · CUSTOMERS · MEDIA.

Formaty: wiadomość, e-mail, telefon, pilny request, raport.

**Miejsce na voice (później):** RING → ACCEPT → krótki inject audio → transcript. W-03 tylko rezerwuje **IncomingCall**. Audio nie w V1 kodu.

---

## 11. EVIDENCE

Artefakt decyzyjny, nie range: alert, historia logowań, mail, raport SOC, lista systemów, relacja usera, status backupu.

Pola: SOURCE · TIME · CONFIDENCE · RELATED SYSTEMS · VERIFICATION STATUS.

Nowy artefakt **może zmienić** interpretację starego (np. kalendarz podróży → FP #3). Inspector pokazuje „updates earlier signal”.

---

## 12. Action Console

Rozkazy, nie A/B/C/D.

Klasy: INVESTIGATE · CONTAIN · PROTECT · RECOVER · COMMUNICATE · ESCALATE.

Przed potwierdzeniem: TARGET · TEAM · EST. TIME · KNOWN OPERATIONAL IMPACT · KNOWN RISK · REVERSIBLE / HARD TO REVERSE.

Zakaz: „+20 cybersecurity”, ukryta skuteczność, pasek atakującego.

SOC może sam potwierdzić isolate **jednego** workstation przy HIGH (W-02). Reszta — autoryzacja IC.

---

## 13. Decision flow

```
SIGNAL → TRIAGE → EVIDENCE → SITUATION ASSESSMENT
      → COMMAND → RESOURCE ASSIGNMENT → ACTION IN PROGRESS
      → OBSERVED CONSEQUENCE
```

Brak rozkazu jest legalny. Nie każde NEW wymaga natychmiastowego kliknięcia.

Ocena jakości decyzji **nie** wyskakuje po 2 sekundach. Skutek obserwowalny przychodzi z czasem (C-02).

---

## 14. Alarm discipline (3 poziomy)

| Poziom | Prezentacja | Dźwięk | Ack |
|---|---|---|---|
| **ADVISORY** | spokojny wpis w feedzie, bez pinu | brak lub bardzo krótki tick (opcjonalnie off) | nie wymaga |
| **WARNING** | podkreślenie, badge na Needs | jeden krótki ton incoming | zalecane, nie blokuje |
| **CRITICAL** | pin + Mission Bar + jeden pulse (nie pętla) | jeden distinct chime, **nie** syrena | wymaga acknowledgement |

CRITICAL jest **rzadkie** (izolacja DC, WMS UNAVAILABLE, notatka okupu jako artefakt, deadline znany i bliski).  
Zakaz: wszystko czerwone, ciągłe miganie, agresywne animacje.

---

## 15. Dźwięk (rezerwa, nie implementacja)

| Cue | Rola |
|---|---|
| incoming signal | WARNING w feedzie |
| telefon | IncomingCall |
| action completed | IN PROGRESS → skutek obserwowalny |
| deadline warning | znany obowiązek zbliża się |
| critical operational | WMS/TMS/ops SEVERE |

Jak kokpit/OS: informuje. Nie arcade, nie minutowy alarm, nie „hacker beep”.

---

## 16. Pięć WOW (z kryzysu, nie z FX)

1. **Link:** dwa niezależne alerty (logowanie + „to nie ja”) **łączą się wizualnie** w jedną sprawę IDENTITY.  
2. **Twin:** węzeł WMS NORMAL → DEGRADED na oczach gracza, bez cutscenki.  
3. **Presja:** telefon CEO / IncomingCall, gdy IN PROGRESS już zajmuje Identity.  
4. **Propagacja BUSINESS:** WMS → picking → loading → dispatch / CLIENT-ALPHA.  
5. **Recovery mode:** po destrukcji pasek i dock zmieniają akcent na RECOVERY (kolejność P1, vault), nie GAME OVER.

Brak wybuchów i cyberpunku.

---

## 17. Język wizualny

DARK · PRECISE · HIGH-CONTRAST · DENSE BUT ORDERED · PROFESSIONAL.

Typografia: czytelna, tabular figures na czas.  
Kolor: semantyka (advisory/warning/critical + status węzła), nie ozdoba.  
Siatka: ostre krawędzie, cienkie separatory, mało pustki.

Nie: neon, grube gradienty SaaS, duże puste karty.

---

## 18. Progressive disclosure

COMMAND = operacja.  
WMS → NodeInspector. Alert → Evidence. Osoba/zasób → Resource + dostępne rozkazy. Deadline → DeadlineDrawer.

---

## 19. Zakaz fałszywych gauge’y

Na COMMAND nie ma: CYBERSECURITY 74%, ATTACKER 53%, DATA LOSS 37%.

Dozwolone: `WMS: DEGRADED` · `DATA EXPOSURE: UNCONFIRMED` · `IDENTITY: HIGH CONFIDENCE` · `BACKUP: LAST VERIFIED COPY 02:00` · vault: `OFF-DOMAIN COPY: CONFIRMED AVAILABLE` (jeśli Infra to potwierdziła).

---

## 20. Czas

Eksponujemy **SIM TIME**. ETA działania w minutach sim.  
Skok: „SIM advanced +32 min — 2 new items”. Nie real-time clock jako prawda.

---

## 21. CLEAN CONTAINMENT

Nie sztuczny kryzys. Przejście:

ACTIVE INCIDENT → CONTAINMENT VERIFICATION → STABILIZATION → DEBRIEF.

Mission Bar: INCIDENT → CONTAINED. Needs puste. Feed: SUPERSEDED. Satysfakcja, nie „gra skończona za wcześnie, dokładamy bossa”.

---

## 22. Ścieżka destrukcyjna

Notatka okupu = **jeden artefakt / wpis COMMS**, nie pełnoekranowe GAME OVER.

Gra trwa: BCP + RECOVERY + COMMUNICATION + LEGAL.  
RecoveryPanel: kolejność P1, niepewność punktu restore, vault vs backup-prod.

---

## 23–25. Persona i świat na HUD

- Pierwsze konto: **Coordinator / Customer Operations** — M365, TMS, kontakty, dane operacyjne. Bez DA / global admin.  
- Privilege V1: możliwe delegated / server-management on-prem; **nie wymagamy Domain Admin**.  
- Klient: **CLIENT-ALPHA** — strategiczny, wymagający, zależny od terminów. Marka później.

---

## 26. Desktop

V1: stanowisko 1920 / 1440p. Laptop: te same 5 stref, węższa tablica (scroll poziomy tablicy **zakazany** — gęstsze węzły / collapse regional).  
Nie projektujemy apki telefonicznej.

---

## 28. Pięć stanów tego samego COMMAND

Stałe zawsze: 5 stref, dock, SIM TIME, zakaz ground truth.

### STATE A — normal / pierwszy słaby sygnał (~T+20)

- Bar: MONITORING · OPS NORMAL · ACTIONS 0 · CRITICAL 0  
- Feed: jeden ADVISORY/WARNING — nietypowe logowanie Coordinator  
- Board: wszystko NORMAL; Entra/M365 lekko UNKNOWN jeśli SOC nie skorelował  
- Stack: puste Needs albo jedno słabe  
- **Nie wie:** czy to atak, czy podróż analogiczna do FP  

### STATE B — identity suspected (~T+50–70)

- Bar: ELEVATED  
- Feed: logowanie + relacja usera; WOW #1 (link dwóch sygnałów)  
- Board: IDENTITY — konto Coordinator SUSPECTED; M365 UNCONFIRMED  
- Needs: Account containment  
- **Nie wie:** persist skrzynki, TMS reach, exfil  

### STATE C — confirmed, działania trwają (~T+110–130)

- Bar: ELEVATED/MAJOR · ACTIONS ≥1  
- In Progress: revoke / forensic ETA  
- Pressure: Identity BUSY, SOC BUSY  
- Board: M365 SUSPECTED/CONFIRMED incident; TMS może SUSPECTED jeśli był login  
- **Nie wie:** drugie konto, privilege Entra, jump  

### STATE D — ops degraded (~T+370+, jeśli ścieżka doszła)

- Bar: MAJOR/CRITICAL · OPS DEGRADED/SEVERE  
- Board BUSINESS: WMS DEGRADED, strzałki do picking/loading; TMS osobno (Entra)  
- Needs: izolacja WMS vs tryb ręczny; presja COO  
- Feed: Warehouse Ops, nie „ransomware planted”  
- **Nie wie:** disruption_capability ukryte, czy vault wejdzie, pełny exfil  

### STATE E — recovery

- Bar: akcent RECOVERY · OPS SEVERE lub wraca DEGRADED  
- Dock: DEADLINES + PLAYBOOK na wierzchu  
- Board: WMS RECOVERING / ISOLATED; vault CONFIRMED jeśli Infra potwierdziła  
- In Progress: restore validation ETA  
- **Nie wie:** czy punkt kopii jest czysty, aż verification wróci  

---

## 29. Pełny moment — DW9 (WMS vs operacje)

Źródło: `CYBER-INCIDENT-V1.md` DW9.  
Warunek: magazyn zgłasza dziwny WMS; IC nie dostaje napisu „REACH WMS = true”.

1. **Ekran:** Feed WARNING→CRITICAL od Warehouse Ops + WMS owner; węzeł `wms` → DEGRADED (WOW #2). BUSINESS pokazuje pęknięcie picking → loading. Needs: „WMS isolation recommendation — authorization required”.  
2. **Dźwięk:** jeden CRITICAL chime + opcjonalnie IncomingCall COO (WOW #3), jeśli Identity już BUSY.  
3. **Gracz widzi:** OPS DEGRADED, WMS DEGRADED, TMS może być NORMAL (inna domena). DATA EXPOSURE zostaje UNCONFIRMED, jeśli nie było egress.  
4. **Otwiera:** NodeInspector WMS, Evidence (log app user, ticket vendor), COMMS Operations.  
5. **Zbiera:** „nietypowy user serwisowy” PARTIALLY VERIFIED; brak potwierdzenia DA; vendor jump UNCONFIRMED/SUSPECTED.  
6. **Rozkaz:** Action Console → CONTAIN → Isolate / restrict WMS **albo** PROTECT → hold isolate + manual mode. Nie ABCD.  
7. **Koszt operacyjny:** przed commitem: „szacunek 25–35% pojemności zmiany, horyzont 8–16 h, ryzyko etykiet” — z WORLD V1, jako **known impact**, nie hidden score.  
8. **Zasób:** Infra lub WMS owner → BUSY; jeśli Vendor UNAVAILABLE po wcześniejszym cut — widać to na Pressure.  
9. **IN PROGRESS:** „WMS restriction · WMS owner · ETA ~18 min”.  
10. **Skutek później:** obserwowalny — WMS ISOLATED/UNAVAILABLE albo nadal DEGRADED; outbound spada; **brak natychmiastowego werdyktu** „dobra decyzja +20”. Atak może być ucięty albo nie — UI pokaże tylko to, co firma zobaczy.

---

## 30. Component inventory (bez kodu)

| Komponent | Odpowiedzialność |
|---|---|
| **MissionBar** | SIM, status incydentu i ops, liczniki, znane deadline’y |
| **IncidentFeed** | Puls wpisów, pin CRITICAL, stany NEW…SUPERSEDED |
| **FeedItem** | Czas, źródło, pewność, skrót, wejście w evidence |
| **SituationBoard** | Graf 20–35 węzłów, 4 projekcje |
| **BoardLayerToggle** | BUSINESS / SYSTEMS / IDENTITY / SECURITY |
| **TwinNode** | Status z wiedzy, wejście w inspector |
| **DependencyLink** | Widoczna zależność / propagacja skutku |
| **NodeInspector** | Szczegóły węzła, related evidence, dostępne rozkazy |
| **CommandStack** | Kolumna Needs + Progress + Pressure |
| **AttentionCard** | Problem decyzyjny: why now, impact, pressure |
| **ActionCard** | Trwające działanie i ETA |
| **ResourceStrip** | Stan zespołów AVAILABLE…UNAVAILABLE |
| **CommandDock** | Pięć wejść do drawerów |
| **CommsDrawer** | Kanały i wątki, bez opuszczania COMMAND |
| **EvidenceDrawer** | Artefakty, pewność, powiązania, rewizja starych sygnałów |
| **ActionConsole** | Rozkaz z kosztem i odwracalnością |
| **PlaybookDrawer** | IRP/BCP jako pomoc, nie quiz |
| **DeadlineDrawer** | Tylko znane obowiązki |
| **IncomingCall** | RING / ACCEPT / placeholder audio / transcript |
| **AlertToast** | Jeden pulse CRITICAL/WARNING, nie stos 20 toastów |
| **TimeJumpBanner** | Czytelny skok SIM |
| **RecoveryPanel** | Kolejność restore, vault vs prod, niepewność punktu |
| **ContainmentBanner** | Wejście w verification / debrief po CLEAN |
| **ConfidenceChip** | UNKNOWN…CONFIRMED |
| **ClientChip** | CLIENT-ALPHA na warstwie BUSINESS |

TARGETED UI REUSE REVIEW — później, nie dopasowywać tej listy do Hotel/Gmina teraz.

---

## 31. Reuse

W-03 nie analizuje UI GRAMY.  
Idealny COMMAND najpierw. Potem osobna karta: co wspólne (shell, drawer, typografia), czego nie wpychać (quiz, weekly cockpit, inbox gminy 1:1).

---

## OPEN DECISIONS LGD

1. Czy V1 ma **dźwięk** (choćby 3 cue), czy cisza do pilotażu.  
2. Czy IncomingCall w V1 jest tylko tekst+RING, czy od razu rezerwujemy audio.  
3. Czy warstwa BUSINESS jest **domyślna** przy starcie (logistyka), czy SYSTEMS.  
4. Czy IC widzi **trzy lokalizacje** w inspectorze `regional-ops` od V1.  
5. Czy PLAYBOOK w docku jest dostępny w trybie egzaminacyjnym, czy tylko edukacyjnym.

===== CYBER-CURRICULUM-MAP-V1.md =====
# CYBER COMMAND — Curriculum Map V1

Status: **kontrakt dydaktyczny** (nie kod, nie wykład, nie handbook)  
Data: **2026-09-12**  
Karta: **E-01**  
Organizacja: **COMPANY-01**  
Handoff: `docs/games/cyber/CYBER-HANDOFF.md`

Nadrzędny kontrakt dla: **E-02…E-06** oraz przyszłego **CYBER LEARNING CONTENT REGISTRY**.

Nie uczymy pentestingu, exploitacji, analizy malware ani administracji.  
Nie uczymy, jak włamać się do systemu.

---

## 1. Cel edukacyjny

CYBER COMMAND uczy:

**zarządzania incydentem cyberbezpieczeństwa  
w warunkach niepełnej informacji  
i konfliktu między bezpieczeństwem a ciągłością działania.**

Uczestnik ma skończyć sesję z umiejętnością dowodzenia, nie z listą skrótów.

Trzy zdania, które gra ma zostawić:

1. Alert to nie wyrok.
2. Bezpieczniejsza decyzja techniczna może zatrzymać magazyn.
3. Recovery nie jest przyciskiem „wróć do NORMAL”.

---

## 2. Profile uczestników

V1 projektujemy przede wszystkim dla **BEGINNER + INTERMEDIATE**.  
Świata nie spłaszczamy do quizu.

| Profil | Kim jest | Co może nie znać | Jak gra ma działać |
|---|---|---|---|
| **A. BEGINNER** | uczeń / student bez praktyki cyber | SOC, SIEM, EDR, WMS, TMS, containment, recovery, CISO, DPO | obowiązkowy briefing + tooltipy + Advisor w TRAINING |
| **B. INTERMEDIATE** | zna podstawy IT/cyber, nie prowadził incydentu | IR w warunkach biznesowych, fog of war, koszt izolacji | briefing krótszy w praktyce; te same decyzje |
| **C. PROFESSIONAL** | IT / cyber / management | — | ten sam świat; mniej pomocy; debrief głębszy |

EXAM nie podnosi trudności słownika. Podcina pomoc decyzyjną.

---

## 3. Mapa kompetencji

Osiem kompetencji. Dziesiątka z karty była za szeroka: komunikację i eskalację łączy W-02 (CEO / COO / DPO), a priorytetyzację zasobów widać w recovery i izolacji — nie jako osobny przedmiot.

| ID | Kompetencja | Poziom | Faza wiodąca |
|---|---|---|---|
| K1 | Sytuacyjna świadomość | MUST KNOW | DURING + DEBRIEF |
| K2 | Triage incydentu | MUST KNOW | DURING |
| K3 | Decyzja w niepewności | MUST KNOW | BEFORE (zasada) + DURING |
| K4 | Containment | MUST KNOW | BEFORE (słowo) + DURING |
| K5 | Ciągłość działania | MUST KNOW | BEFORE + DURING |
| K6 | Recovery | MUST KNOW | BEFORE (słowo) + DURING + DEBRIEF |
| K7 | Komunikacja i ład decyzyjny | MUST KNOW | DURING + DEBRIEF |
| K8 | Świadomość danych i prywatności | SHOULD KNOW | DURING + DEBRIEF |

ADVANCED (nie osobne kompetencje V1): prawo KSC/NIS2, forensics, privilege model, hybrid sync. Zostają w Teacher Guide.

### K1 — Sytuacyjna świadomość

**Definicja:** Umiejętność złożenia tego, co organizacja **widzi**, bez mylenia tego z prawdą świata.

**Czego się uczy:** obserwacja ≠ fakt; dwa niezależne sygnały podnoszą pewność; jeden sygnał to analiza.

**Po czym widać zrozumienie:** nie traktuje SIGNAL jako CONFIRMED; po korekcie zmienia ocenę; szuka drugiego źródła.

**DW:** DW1, DW4, DW7, DW9  
**Faza:** DURING (ćwiczenie), DEBRIEF (nazwanie). BEFORE tylko definicje SIGNAL…RETRACTED.

### K2 — Triage incydentu

**Definicja:** Który sygnał jest pilny, który dwuznaczny, którego nie da się rozwiązać masową blokadą.

**Czego się uczy:** potwierdzić tożsamość zanim zetnie się sprzedaż; rozdzielić dwa „dziwne logowania”; isolate jednej stacji ≠ isolate magazynu.

**Po czym widać:** priorytetuje konto / stację / system; nie blokuje „wszystkiego na wszelki wypadek”.

**DW:** DW1, DW2, DW3, DW4  
**Faza:** DURING. BEFORE: „nie każdy alert = atak”.

### K3 — Decyzja w niepewności

**Definicja:** Podjęcie działania przy niepełnym obrazie i świadomym ryzyku czekania.

**Czego się uczy:** czekanie też jest decyzją; brak pewności nie oznacza braku działania; hipoteza nie jest faktem.

**Po czym widać:** wybiera klasę działania z kosztem; nie czeka na „pełny raport”; nie udaje pewności w comms.

**DW:** wszystkie, szczególnie DW1, DW6, DW9, DW10  
**Faza:** BEFORE (zasada), DURING (wszystkie okna), DEBRIEF (oś czasu).

### K4 — Containment

**Definicja:** Ograniczenie dalszego wpływu incydentu — nie to samo co wyłączenie firmy.

**Czego się uczy:** revoke / isolate / cut roli / cut vendora to różne dźwignie; zakres musi być współmierny do pewności; twarde cięcie AD albo WMS ma koszt zmiany.

**Po czym widać:** tnie wąsko, gdy pewność niska; nie wyłącza Entra „w całości”; rozumie, że izolacja WMS to decyzja operacyjna.

**DW:** DW2, DW3, DW5, DW6, DW8, DW9  
**Faza:** BEFORE (słowo), DURING (okna).

### K5 — Ciągłość działania

**Definicja:** Utrzymanie kluczowego procesu (magazyn, transport, zlecenia) w trybie zdegradowanym.

**Czego się uczy:** izolacja ma cenę outboundu; istnieje tryb ręczny z horyzontem, nie z cudowną wydajnością; SLA nie unieważnia ryzyka.

**Po czym widać:** uruchamia / akceptuje tryb ręczny; nazywa koszt izolacji; nie obiecuje COO „jedziemy jak zwykle”.

**DW:** DW5, DW9, DW10, DW11  
**Faza:** BEFORE (WMS/TMS/tryb ręczny), DURING.

### K6 — Recovery

**Definicja:** Przywracanie działania po ograniczeniu albo awarii — kolejność, zaufanie do kopii, ludzie.

**Czego się uczy:** job FAIL ≠ vault martwy; restore w ciemno może powtórzyć problem; recovery ≠ natychmiastowy NORMAL; nie wszystko wraca z jednej kopii.

**Po czym widać:** nie restore’uje pierwszego zielonego przycisku; pyta o vault / punkt czysty; szereguje tożsamość i magazyn przed wygodą biura.

**DW:** DW7, DW12  
**Faza:** BEFORE (jedno zdanie), DURING, DEBRIEF (kolejność).

### K7 — Komunikacja i ład decyzyjny

**Definicja:** Kto decyduje, komu się mówi, czego nie przedstawia się jako fakt.

**Czego się uczy:** SOC rekomenduje, IC autoryzuje izolację krytyczną; CEO/COO dostają obraz zgodny z wiedzą; DPO pyta o dane — nie obiecuje się „nic nie wyszło”.

**Po czym widać:** comms rozróżnia hipotezę i potwierdzenie; nie kłamie klientowi; nie oddaje COO prawa do „jedziemy” bez świadomego risk-accept.

**DW:** DW3, DW10, DW11, DW12 + Incoming Call  
**Faza:** DURING, DEBRIEF.

### K8 — Świadomość danych i prywatności

**Definicja:** Incydent dostępności ≠ incydent wycieku; obie mogą iść razem.

**Czego się uczy:** egress to sygnał, nie kompletna lista plików; cisza wobec klienta przy kłamliwym portalu niszczy zaufanie; zegar obowiązku startuje od **wiedzy**, nie od hidden stage (kontrakt, nie wykład prawa).

**Po czym widać:** nie mówi „na pewno nic nie wyciekło”; ogranicza hub świadomie; wciąga DPO gdy pojawia się pytanie o dane.

**DW:** DW11 (wspiera DW5/DW9 comms)  
**Faza:** DURING, DEBRIEF. BEFORE: jedno zdanie „dane mogą wyciec niezależnie od postoju rampy”.

---

## 4. Learning outcomes (obserwowalne)

Nie: „zna cyberbezpieczeństwo”.

| ID | Outcome | Kompetencja |
|---|---|---|
| LO-01 | Odróżnia pojedynczy sygnał od potwierdzonego incydentu. | K1 |
| LO-02 | Po korekcie informacji porzuca starą hipotezę (RETRACTED nie jest „błędem UI”). | K1 |
| LO-03 | Szuka drugiego niezależnego źródła zanim wyda wyrok. | K1, K2 |
| LO-04 | Nie stosuje masowej blokady tam, gdzie wystarczy potwierdzenie jednej tożsamości. | K2, K4 |
| LO-05 | Rozdziela dwa podobne sygnały (np. dwa logowania) zamiast ciąć cały proces. | K2 |
| LO-06 | Podejmuje decyzję bez pełnego obrazu i potrafi powiedzieć, czego nie wie. | K3 |
| LO-07 | Traktuje czekanie jako decyzję z kosztem. | K3 |
| LO-08 | Dobiera zakres containment do pewności (stacja ≠ magazyn ≠ cała tożsamość chmurowa). | K4 |
| LO-09 | Wskazuje koszt biznesowy izolacji krytycznego systemu. | K5 |
| LO-10 | Uruchamia albo akceptuje tryb ręczny z realnym horyzontem, nie jako „pełny zamiennik”. | K5 |
| LO-11 | Rozumie, że recovery nie oznacza natychmiastowego powrotu do SPRAWNE. | K6 |
| LO-12 | Nie odtwarza z kopii, której nie ufamy, tylko dlatego że job kiedyś był zielony. | K6 |
| LO-13 | Przekazuje CEO/COO stan zgodny z wiedzą; hipotezy nie nazywa faktem. | K7 |
| LO-14 | Wie, że SOC nie jest właścicielem decyzji o odcięciu magazynu. | K7 |
| LO-15 | Nie obiecuje „nic nie wyszło”, gdy zna tylko brak pewności. | K8 |
| LO-16 | Czyta kokpit: Feed = nowe info, Board = obraz, Stack = sprawy, Dock = narzędzia. | literacy |

**16 outcomes.** Scoring/AAR później czyta zachowania, nie te etykiety.

---

## 5. Trzy fazy uczenia

### A. BEFORE GAME

Uczestnik **musi** dostać przed T0:

- pojęcia LEVEL 1;
- obraz firmy i 3 systemów operacyjnych (WMS, TMS, EDI/API);
- tożsamość = konta ludzi i uprawnienia;
- SIGNAL ≠ CONFIRMED; SUSPECTED ≠ fakt;
- containment ≠ recovery;
- konflikt bezpieczeństwo / rampa;
- rolę Incident Commandera;
- 90-sekundowy odczyt Mission Control.

Nie wyjaśniamy: przebiegu ataku, kolejności DW, tego, który system „naprawdę” padnie, vault vs AD, ścieżek ALT.

### B. DURING GAME

Uczy się przez zdarzenia, decyzje, konsekwencje, tooltipy, Advisora (TRAINING), konflikt z COO/CEO.

Tu żyją: triage, fałszywy trop, koszt izolacji, tryb ręczny, backup FAIL, pytanie DPO, presja SLA.

Discovery i niepewność są **cechą**, nie błędem briefingu.

### C. DEBRIEF

Dopiero po grze nazywamy i porządkujemy:

- kiedy uznał incydent za realny;
- które informacje zmieniły ocenę;
- koszt operacyjny decyzji bezpieczeństwa;
- czy komunikował hipotezę jako fakt;
- oś czasu vs to, co widział;
- że inne zakończenia były możliwe (bez recytowania „poprawnej ścieżki” studentowi).

Teacher Guide może pokazać Ground Truth. Student-facing debrief — refleksja, nie facit.

---

## 6. Pre-game briefing — zakres (E-02 napisze skrypt)

**MUST HAVE przed T0.** Czas: **12 minut** (±3). Maks. 10 tematów.

| # | Temat | Cel | Czas | Czego nie mówić |
|---|---|---|---|---|
| 1 | Incydent ≠ alert | Ramka: coś wymaga skoordynowanej odpowiedzi | 1:00 | „to na pewno atak z zewnątrz” |
| 2 | Niepełna informacja | Gracz decyduje, nie czekając na pełny obraz | 1:00 | że silnik zna prawdę atakującego |
| 3 | Pewność: SIGNAL…CONFIRMED | Wyrok wymaga więcej niż jednego sygnału | 1:30 | progi silnika / „dwa alerty = CONFIRMED zawsze” |
| 4 | Konto i phishing | Ktoś może używać cudzego dostępu | 1:30 | wektor kampanii V1, imię konta, kill chain |
| 5 | COMPANY-01 | Logistyka 24/7; postój IT = postój towaru | 1:30 | mapa attack surface, 29 węzłów, vault |
| 6 | WMS / TMS / EDI-API | Trzy zdania: kompletacja, dyspozycja, wejście zleceń | 1:30 | że TMS jest SaaS-wektorem; że WMS „zostanie przejęty” |
| 7 | Tożsamość | Ludzie i konta; chmura i magazyn mogą żyć osobno | 1:00 | hybrid sync jako wektor; Entra vs AD jako spoiler |
| 8 | Containment vs recovery | Najpierw ograniczyć wpływ; odtwarzanie to osobny tor | 1:00 | kolejność restore P1–P5; „backup was zawsze uratuje” |
| 9 | Bezpieczeństwo vs biznes | Izolacja ma cenę rampy / zleceń / klienta | 1:00 | kanoniczna piątka konfliktów jako facit |
| 10 | Twoja rola + kokpit | IC dowodzi uwagi; Feed / Board / Stack / Dock | 1:30 | „w DW9 zrobisz X” |

Ransomware: **jedno zdanie w temacie 1 albo 8** — „czasem pojawia się żądanie okupu albo szyfrowanie; to nie jest natychmiastowy koniec misji”. Bez zapowiedzi, że V1 tam dojdzie.

Self-guided i teacher-led: **ta sama dziesiątka**. E-02 rozpisze dwa nośniki.

---

## 7. Terminology map (na bazie V-02E)

Klasyfikacja, nie kopia registry.

### LEVEL 1 — MUST KNOW BEFORE T0

| Termin | Minimum |
|---|---|
| cyberatak | celowe działanie przeciw systemom / danym / tożsamości |
| incydent | zdarzenie wymagające skoordynowanej odpowiedzi |
| alert | sygnał, że coś może być nie tak |
| phishing | próba wyłudzenia dostępu albo działania |
| konto / tożsamość | kto może się zalogować i z jakim prawem |
| MFA | dodatkowe potwierdzenie przy logowaniu |
| ransomware | blokada / szyfrowanie / okup — nie „game over” |
| containment | ograniczenie dalszego wpływu |
| recovery | odtwarzanie po ograniczeniu albo awarii |
| SIGNAL / SUSPECTED / CONFIRMED | pewność informacji |
| Incident Commander | dowodzi kolejnością i uwagą, nie klika wszystkiego sam |

### LEVEL 2 — EXPLAIN IN CONTEXT (briefing krótko **albo** tooltip / karta w grze)

SOC, SIEM, EDR, WMS, TMS, EDI/API, Entra ID, Active Directory, CISO, DPO, COO, CEO, BCP / tryb ręczny, SLA, picking / loading / dispatch, isolate, vendor / MSP, backup (ogólnie).

### LEVEL 3 — ADVANCED / TEACHER / OPTIONAL

Domain Admin, PIM, consent, jump host, hybrid sync, vault immutable, egress staging, NIS2/KSC, RODO clocks, privilege escalation, lateral movement (słowo nauczyciela, **nie** HUD gracza).

---

## 8. Język statusów

Dwie osie. **Nie scalać** w jedno `node.status` (kontrakt C-06).

**Pewność informacji (C-04):**

| Status | Uczeń ma rozumieć |
|---|---|
| SIGNAL | jest ślad; to nie wyrok |
| SUSPECTED | hipoteza robocza |
| PARTIALLY_VERIFIED | część się zgadza; obraz niepełny |
| CONFIRMED | informacja sprawdzona — **nie** oznacza pełnej wiedzy o incydencie |
| RETRACTED | informacja została skorygowana; to nie „system się pomylił dla żartu” |

**Stan operacyjny (V-02E / V-03):**

| Status | PL | Sens |
|---|---|---|
| NORMAL | SPRAWNE | działa jak się spodziewamy |
| UNKNOWN | NIEZNANY | brak wiarygodnej informacji — nie „bezpieczne” |
| SUSPECTED | PODEJRZANY | sygnał o stanie, bez pewności |
| DEGRADED | OGRANICZONE DZIAŁANIE | jedzie gorzej / częściowo |
| ISOLATED | IZOLOWANY | odcięty świadomie |
| UNAVAILABLE | NIEDOSTĘPNY | nie można korzystać |
| RECOVERING | ODTWARZANIE | trwa przywracanie ≠ już SPRAWNE |

Przepływ BUSINESS (PŁYNIE / OGRANICZONY / WSTRZYMANY) to ruch zleceń/towaru, nie „zdrowie serwera”.

---

## 9. Bezpieczeństwo vs biznes

Centralny efekt dydaktyczny. Piątka kanoniczna W-02:

| Konflikt | Czego ma się nauczyć |
|---|---|
| Izolacja WMS vs picking 24/7 | Bezpieczeństwo magazynowego IT może zejść do 25–35% ręcznie; BHP i backlog są realne. |
| Twarde AD vs sesje DC | Cięcie tożsamości on-prem gasi zmianę w 1–3 h; to nie „darmowy containment”. |
| Cut EDI/API vs nowe zlecenia | Ograniczenie integracji tnie wejście zleceń (~20–30% mailem); klient nie znika. |
| Cut vendor vs naprawa WMS | Zamykasz drzwi albo zostawiasz ręce, które mogą naprawić — i nadużyć. |
| Cut TMS / Entra vs dispatch | Transport może jechać osobno od WMS; odcięcie ról ma koszt 40–50% ręcznego dispatchu. |

W debriefie (nie w briefingu): restore vs containment; komunikat vs cisza o danych.

---

## 10. Baseline — wiedza organizacyjna

Nie pokazujemy 29 węzłów, bo istnieją.

| Klasa | Sens |
|---|---|
| **A. KNOWN BEFORE INCIDENT** | uczestnik zna z briefingu i widzi na twinie od T0 |
| **B. DISCOVERABLE DURING** | pojawia się przez obserwację / inspect / comms |
| **C. TECHNICAL DETAIL** | nie potrzebne w domyślnym BUSINESS view |

### 10.1. Propozycja `baselineVisibleNodeIds` (dla C-06 / E-02)

```text
entra-id
active-directory
m365
wms
tms
integration-hub
warehouse-automation
regional-ops
customer-portal
soc-external
```

**10 węzłów.** Uzasadnienie:

- **WMS, TMS, integration-hub** — MUST przed pierwszą decyzją operacyjną (LO-09, temat 6).
- **warehouse-automation, regional-ops, customer-portal** — BUSINESS: kompletacja → regiony → klient; bez nich Board jest pustą IT-mapą.
- **entra-id, active-directory, m365** — tożsamość i war room; dwa światy logowania bez spoilera sync.
- **soc-external** — „mamy SOC”; źródło alertów, nie właściciel magazynu.

To **rekomendacja dydaktyczna**, nie zamknięta lista produkcyjna. E-02 może skrócić do 8, jeśli briefing nie uniesie portalu i SOC jako węzłów (zostaną wtedy LEVEL 2 + klasa B).

### 10.2. Klasa B — discoverable

`net-dc`, `dc-compute`, `warehouse-devices`, `vendor-access`, `vpn-access`, `edr`, `siem`, `backup-prod`, `backup-vault`, `msp-infra`, `erp`, `identity-sync`, `internet-edge`, `net-hq`.

Pojawiają się, gdy organizacja **dostaje** o nich informację. Nie liczymy ich graczowi z góry (zakaz C-06).

### 10.3. Klasa C — poza domyślnym BUSINESS

`wifi-staff`, `net-regional`, `file-services`, `finance`, `hr`.

Pojęcia (backup, vault, sieć DC) **wolno** powiedzieć zdaniem w briefingu. Węzeł nie musi być widoczny od T0.

---

## 11. Organisation briefing (skrót do E-02)

Student przed T0 dostaje:

- COMPANY-01: polski operator logistyczny; centrala + DC 24/7 + regiony jako jeden obraz.
- Magazyn kompletuje i ładuje; bez systemu jedzie wolniej i krócej trzyma porządek.
- **WMS** mówi, co zbierać i etykietować.
- **TMS** układa okna i auta — osobno od WMS.
- **EDI/API** wpuszcza zlecenia klienta.
- Tożsamość: konta ludzi (poczta / chmura) i konta magazynu mogą być w różnych światach.
- Zespoły: SOC (zewnętrzny triaż), IT/Identity/Network, operacje magazynu i transportu, zarząd, DPO.
- Tryb ręczny istnieje i jest gorszy — nie jest oszustwem tutoriala.

**Nie** dawać pełnej mapy attack surface.

---

## 12. Role — jedno zdanie przed grą

| Rola | Za co odpowiada |
|---|---|
| **Incident Commander** | Kolejność decyzji i uwaga zespołów; nie wykonuje wszystkich kliknięć. |
| **SOC** | Triaż alertów i rekomendacje; nie właściciel biznesu ani rampy. |
| **IT / Infrastructure** | Hosty, AD, kopie, restore. |
| **Identity** | Konta, MFA, sesje, role chmurowe. |
| **Network** | Segmenty, VPN, dostęp dostawców. |
| **Operations** | Magazyn i transport: czy towar wyjeżdża. |
| **CEO** | Reputacja, „stój / jedź / mówimy”. |
| **COO** | SLA, pojemność, presja „jedziemy”. |
| **CISO** | Ryzyko i ramka IR — w SOLO często to gra IC. |
| **DPO** | Czy to naruszenie danych; czego nie wolno obiecać. |

---

## 13. Mission Control literacy

Wejście do E-02 jako **krótki onboarding po miniwykładzie** (~90 s), nie osobny kurs UI.

| Element | Uczeń ma wiedzieć |
|---|---|
| **Feed** | Nowe informacje. Źródło + pewność. CRITICAL nie tonie. |
| **Situation Board** | Aktualny obraz organizacji z **wiedzy**, nie z ukrytej prawdy. |
| **Command Stack** | Sprawy: Needs / In Progress / Pressure. |
| **Command Dock** | Narzędzia: COMMS, EVIDENCE, ACTIONS, PLAYBOOK, DEADLINES. |
| **Pewność / weryfikacja** | Chip przy informacji; nie przy „zdrowiu ataku”. |
| **Action in progress** | Rozkaz trwa; nie jest natychmiastowym skutkiem. |
| **Dependencies** | Co od czego zależy — struktura, nie ścieżka ataku. |
| **Flow status** | PŁYNIE / OGRANICZONY / WSTRZYMANY = ruch procesu. |

Zakaz HUD: attacker stage, hidden persistence, „compromised” bez wiedzy.

---

## 14. TRAINING vs EXAM

Różnica = **pomoc**, nie trudność słownika.

| Powierzchnia | TRAINING | EXAM |
|---|---|---|
| Tooltip / definicja pojęcia | pełna | **zostaje** (to nie test skrótów) |
| Glossary / karta pojęcia | pełna + kontekst organizacyjny | definicja, bez podpowiedzi decyzyjnej |
| Context explanation („co teraz zrobić”) | tak | nie |
| Mission Advisor | A–C + delikatne D | tylko A (termin) i B (UI), bez C strategicznego |
| Playbook | pełniejszy IRP/BCP | zredukowany; bez „w tym oknie wybierz” |
| Hints przy Needs | WHY NOW bez facitu | sam fakt presji, bez interpretacji |

EXAM nadal pozwala zrozumieć, czym jest WMS.  
EXAM nie mówi, czy izolować WMS.

---

## 15. Zachowania obserwowalne (wejście pod AAR, nie scoring)

| Kompetencja | Przykłady zachowania |
|---|---|
| K1 | Otwiera Evidence zanim zatwierdzi isolate; nie oznacza SIGNAL jako CONFIRMED; po RETRACTED zmienia ocenę. |
| K2 | Najpierw konto/stacja, nie hurtowa blokada sprzedaży; rozdziela dwa logowania. |
| K3 | Akceptuje działanie przy UNKNOWN; w comms dopisuje, czego nie wie. |
| K4 | Isolate 1 WS ≠ isolate WMS; nie gasi całego Entra przy jednej roli. |
| K5 | Nazywa spadek outboundu; włącza tryb ręczny; nie obiecuje 100% rampy. |
| K6 | Nie restore z FAIL w ciemno; pyta o vault; szereguje odtworzenie. |
| K7 | CEO słyszy stan z wiedzy; hipoteza oznaczona; SOC nie dostaje blank check na magazyn. |
| K8 | DPO dostaje „nie wiemy” zamiast „nic nie wyszło”; rozważa ograniczenie hubu. |

---

## 16. Błędne przekonania (10)

| # | Przekonanie | Konfrontacja w grze | Debrief |
|---|---|---|---|
| 1 | Każdy alert = atak | DW1 / DW4 (sygnał vs podróż) | Kiedy alert stał się incydentem? |
| 2 | Najbezpieczniej odłączyć wszystko | DW8, DW9, twarde AD | Jaki był koszt nadmiarowego cięcia? |
| 3 | Ransomware = natychmiast game over | DW12, endingi bez WIN/LOSE | Co jeszcze było do uratowania? |
| 4 | Backup = gwarancja natychmiastowego recovery | DW7 | Czemu zielony job nie kończy sprawy? |
| 5 | CONFIRMED = znamy pełny zakres | DW9 / DW11 | Co było potwierdzone, a czego nie? |
| 6 | SOC sam może odciąć magazyn | DW3 vs DW9 | Kto jest właścicielem izolacji krytycznej? |
| 7 | Brak alertu EDR = czysto | DW9, ślepe OT | Gdzie telemetria nie sięga? |
| 8 | Izolacja nie boli biznesu | DW5, DW9, DW10 | Która decyzja bezpieczeństwa była najdroższa? |
| 9 | Tryb ręczny zastępuje system | parametr 25–35% / horyzont | Jak długo ręczny tryb jest uczciwy? |
| 10 | „Nic nie wyszło”, bo rampa jedzie | DW11 | Czym wyciek różni się od postoju? |

(11–12 opcjonalnie dla nauczyciela: „dostawca na jumpie jest zawsze legalny”; „restore najpierw, pytania później”.)

---

## 17. Pytania debriefingu (14)

Wersja student-facing. Bez facitu ścieżki W-02.

1. Kiedy po raz pierwszy uznałeś, że incydent jest realny — i na jakiej podstawie?
2. Jakie informacje najbardziej zmieniły Twoją ocenę?
3. Którego sygnału nie doceniłeś albo przeceniłeś?
4. Która decyzja bezpieczeństwa miała największy koszt operacyjny?
5. Czy komunikowałeś coś jako fakt, zanim było potwierdzone?
6. Komu odmówiłeś albo uległeś pod presją (COO / CEO / SOC) i dlaczego?
7. Co zrobiłbyś inaczej, widząc pełną oś **tego, co wiedziałeś wtedy** — nie facit nauczyciela?
8. Gdzie czekanie było świadome, a gdzie odwlekaniem?
9. Czy tryb ręczny był dla Ciebie planem, czy porażką?
10. Czego nie wiedziałeś o danych / kliencie, a mówiłeś na zewnątrz?
11. Który zespół był przeciążony — i co wtedy odpuściłeś?
12. Co oznaczało dla Ciebie „odtworzyć”, zanim zobaczyłeś skutek?
13. Która hipoteza okazała się zbędna i kiedy powinna była spaść?
14. Jaką jedną zasadę zabierasz do następnego incydentu?

---

## 18. Mission Advisor — granice (nie UI)

### Kiedy może pomóc

| Kategoria | Przykład |
|---|---|
| **A. TERMINOLOGY** | „WMS to system magazynu.” |
| **B. INTERFACE** | „Feed to nowe informacje; Board to obraz organizacji.” |
| **C. CONCEPT** | „Containment ogranicza wpływ; to nie to samo co recovery.” (TRAINING) |
| **D. DEBRIEF PROMPT** | „Zatrzymaj się: co wtedy wiedziałeś?” (po sesji albo w TRAINING pause) |

### Kiedy MUSI milczeć

- przy wyborze strategicznym (izolować WMS czy jechać);
- gdy zdanie zdradziłoby konsekwencję („jeśli zetniesz jump, atak nie wejdzie do WMS”);
- gdy niepewność **jest** lekcją (podróż vs atak);
- gdy ujawniłby Ground Truth, hidden stage, persistence, exfil real.

TRAINING: A, B, C, ostrożne D.  
EXAM: A + B; bez C decyzyjnego i bez D w trakcie.

---

## 19. Learning Content Registry — propozycja schematu

**Nie implementować.** Jeden rekord zasila: tooltip, glossary, briefing, Advisor, handbook, teacher guide.

```text
id
term
shortDefinition          // 1 zdanie, PUBLIC
studentExplanation       // prosty język, PUBLIC
teacherNotes             // TEACHER; może linkować DW
gameContext              // kiedy pojęcie pojawia się w sesji; bez spoilera
relatedCompetencies[]    // K1…K8
relatedNodes[]           // id z C-05 albo puste
relatedDecisionWindows[] // DW1…DW12 albo puste
spoilerLevel             // PUBLIC | TRAINING | TEACHER | GROUND_TRUTH
surfaces[]               // tooltip | glossary | briefing | advisor | handbook | teacher
```

Zakaz osobnych definicji WMS w sześciu miejscach.  
V-02E LAB registry jest **zalążkiem słownika**, nie docelowym registry.

---

## 20. Model spoilerów

| Poziom | Kto | Przykład |
|---|---|---|
| **PUBLIC** | uczeń zawsze | definicja WMS; SIGNAL ≠ CONFIRMED |
| **TRAINING** | pomoc dydaktyczna, nie EXAM | „Containment i rampa często stoją w napięciu” przy Needs |
| **TEACHER** | prowadzący | typowe błędy przy DW9; pytania naprowadzające |
| **GROUND_TRUTH** | nigdy gracz w sesji | timeline W-02, persist, exfil, ALT A–D, ending conditions |

Permissions nie implementujemy. To kontrakt treści.

---

## 21. Otwarte pytania (LGD)

1. Czy baseline zostaje przy **10** węzłach, czy E-02 ścina portal i SOC do klasy B?
2. Czy ransomware w briefingu to obowiązkowe jedno zdanie, czy tylko karta pojęcia (LEVEL 1 bez slajdu)?
3. Czy EXAM zostawia **pełne** tooltipy operacyjne (DEGRADED/ISOLATED), czy tylko słownik pojęć?
4. Czy self-guided briefing jest w produkcie V1, czy najpierw tylko teacher-led + karty?
5. Czy debrief studenta pokazuje **oś jego wiedzy**, czy nauczyciel może odsłonić Ground Truth na sali?

---

## 22. Czego E-01 świadomie nie zamyka

Pełnego skryptu E-02, slajdów, ebooka, handbooka, avatara, audio, scoringu, testu egzaminacyjnego, finalnej listy baseline w kodzie C-06.

===== CYBER-PRE-GAME-BRIEFING-V1.md =====
# CYBER COMMAND — Pre-Game Briefing V1

Status: **kontrakt treści dydaktycznej** (nie kod, nie slajdy, nie UI)  
Data: **2026-09-12**  
Karta: **E-02**  
Organizacja: **COMPANY-01** (NEXORA Logistics S.A. — nazwa robocza)  
Handoff: `docs/games/cyber/CYBER-HANDOFF.md`  
Nadrzędny kontrakt: `docs/games/cyber/CYBER-CURRICULUM-MAP-V1.md` (**E-01**)

Dwie równoważne wersji dostawy: **TEACHER-LED** i **SELF-GUIDED**.  
Ta sama treść merytoryczna. Różny nośnik i głos.

Nie uczymy jednej poprawnej sekwencji decyzji.  
Przykłady zachowań w grze są **ilustracją**, nie facitem.

---

## 1. Purpose

Przygotować uczestnika **BEGINNER** do pierwszej sesji CYBER COMMAND w **10–13 minut**.

Po briefingu uczestnik:

- rozumie, że **alert ≠ incydent ≠ cyberatak**;
- odróżnia **pewność informacji** od **stanu systemu**;
- zna minimum organizacji logistycznej 24/7 i trzech systemów operacyjnych (WMS, TMS, EDI/API);
- wie, czym jest **containment** i **recovery** — i że to nie to samo;
- rozumie napięcie **bezpieczeństwo vs ciągłość działania**;
- zna rolę **Incident Commandera** i podstawowy odczyt **Mission Control**;
- może rozpocząć symulację bez poczucia „nie rozumiem połowy ekranu”.

Briefing **nie** zastępuje gry, debriefu ani Teacher Guide.

---

## 2. Timing

| Element | Czas |
|---|---|
| Otwarcie sytuacyjne | **0:30–0:45** |
| Bloki 1–9 (treść merytoryczna) | **~10:30** |
| Blok 10 + Mission Control onboarding | **~1:30** |
| **Razem (teacher-led, spokojne tempo)** | **~12:45** |
| **Self-guided (czytanie + NEXT)** | **~11:00–12:30** |

Teacher-led może skrócić bloki 5–7 o ~30 s u grupy INTERMEDIATE.  
Self-guided: uczestnik kontroluje tempo; punkty ekranowe skracają narrację.

**Realny czas teacher-led (szacunek po redakcji):** **12 min 45 s** (+ otwarcie 40 s).  
**Realny czas self-guided (szacunek):** **11 min 30 s** (bez pauz na pytania grupy).

**Liczba bloków merytorycznych:** **10** (+ otwarcie osobno).

---

## 3. Otwarcie sytuacyjne (0:30–0:45)

Wspólne dla obu wersji. Nie liczy się do dziesięciu bloków E-01.

### CANONICAL CONTENT

Firma logistyczna pracuje całą dobę. Towar wjeżdża na magazyn, system mówi, co skompletować, auta wyjeżdżają w okienka załadunku. Nagle coś w IT zaczyna wyglądać nienormalnie — alert, dziwne logowanie, skarga ze zmiany.

To może być atak. Awaria. Pomyłka. Albo fałszywy alarm.

Za chwilę **Ty** będziesz dowodzić reakcją — nie czekając, aż ktoś inny „domknie sprawę”.

### TEACHER DELIVERY

> Wyobraźcie sobie magazyn, który nie śpi. Zlecenia wpadały automatycznie, rampa jechała, kierowcy mieli swoje okna. I nagle — sygnał z monitoringu albo telefon ze zmiany: „coś jest nie tak z systemem albo z dostępem”.
>
> Czy to atak? Awaria? Ktoś kliknął źle? A może nic poważnego?
>
> Za kilka minut w tej grze to **wy** będziecie musieli zdecydować — jako dowódca incydentu. Nie musicie być hackerami. Musicie prowadzić firmę przez chaos informacji.

**Pytanie do grupy (opcjonalne):** „Kiedy ostatnio słyszeliście o cyberataku w wiadomościach — co najpierw padło: alert, incydent, czy od razu ‚wszystko padło’?”

**VISUAL CUE:** Noc / zmiana magazynowa. Rampa, wózki, ekran z ikoną alertu — bez logów technicznych.

### SELF-GUIDED DELIVERY

**Headline:** Za chwilę poprowadzisz firmę przez incydent.

**Punkty:**
- Logistyka 24/7: towar, magazyn, transport — non stop.
- Pojawia się nietypowy sygnał IT.
- Atak, awaria i pomyłka wyglądają podobnie na początku.
- Twoja rola: decyzje przy niepełnej wiedzy.

**NEXT** → Blok 1

---

## 4. Canonical briefing blocks

Każdy blok: **CANONICAL CONTENT** → **TEACHER DELIVERY** → **SELF-GUIDED DELIVERY**.

---

### BLOK 1 — ALERT / INCYDENT / CYBERATAK

**Czas:** 1:00  
**Kompetencje:** K1, K2 · **LO:** LO-01

#### CANONICAL CONTENT

- **Alert** — sygnał, że coś **może** wymagać uwagi. Nie jest jeszcze werdyktem.
- **Incydent** — sytuacja wymagająca **skoordynowanej reakcji** zespołu (IT, bezpieczeństwo, biznes, prawo).
- **Cyberatak** — **celowe** działanie przeciw systemom, danym albo dostępowi.

**Najważniejsza lekcja:** alert **nie** jest automatycznie dowodem ataku.

Niektóre incydenty mogą prowadzić do szyfrowania, blokady systemów albo żądania okupu — ale to **nie** oznacza automatycznego końca misji. W tej grze liczy się to, co zrobisz dalej, nie sama etykieta „ransomware”.

#### TEACHER DELIVERY

> W monitoringu coś zabłyśnie — to jest **alert**. Dopiero gdy zaczynacie organizować reakcję — kto patrzy, kto decyduje, co zatrzymać, komu zadzwonić — mówimy o **incydencie**.
>
> **Cyberatak** to sytuacja, w której ktoś **celowo** chce zaszkodzić: ukraść dostęp, zablokować system, wyciągnąć dane. Ale pierwszy alert może być równie dobrze dziwnym logowaniem albo błędem integracji.
>
> W grze macie za zadanie **nie panikować na pierwszy sygnał** i **nie udawać**, że nic się nie dzieje, gdy sygnałów jest już kilka.
>
> I jedno zdanie na marginesie: czasem w realnych incydentach pojawia się szyfrowanie albo żądanie okupu. To nie jest magiczny „game over” — nadal trzeba dowodzić reakcją.

**Pytanie do grupy:** „Czy każdy alert z antywirusa to atak?” (oczekiwane: nie)

**VISUAL CUE:** Trzy karty: ALERT → INCYDENT → CYBERATAK. Strzałka „alert ≠ werdykt”.

#### SELF-GUIDED DELIVERY

**Headline:** Alert to sygnał — nie wyrok.

**Punkty:**
- **Alert** — coś może być nie tak.
- **Incydent** — trzeba skoordynować reakcję.
- **Cyberatak** — celowe działanie przeciw IT / danym / dostępowi.
- Okup i szyfrowanie **mogą** się zdarzyć w incydentach — nie kończą misji z definicji.

**NEXT** → Blok 2

---

### BLOK 2 — NIEPEŁNA INFORMACJA

**Czas:** 1:00  
**Kompetencje:** K3 · **LO:** LO-06, LO-07

#### CANONICAL CONTENT

W prawdziwym incydencie **nikt** nie ma pełnego obrazu od pierwszej minuty. Monitoring pokazuje fragment. Użytkownik coś zgłasza. SOC widzi inny wycinek. Magazyn czuje skutek, zanim IT zna przyczynę.

**Czekanie** też jest decyzją — ma koszt (czas, rampa, zaufanie klienta).  
**Działanie** przy niepełnej wiedzy też ma koszt (możesz odciąć za dużo albo za mało).

Gra **celowo** nie daje pełnej prawdy od razu. To nie błąd — to warunek ćwiczenia.

#### TEACHER DELIVERY

> W filmach ktoś wpisuje trzy komendy i wie wszystko. W firmie logistycznej o trzeciej w nocy wie ktoś inny coś innego.
>
> W tej grze **decydujecie bez pełnego obrazu** — tak jak w realnym IR. Możecie poprosić o dowód, poczekać na SOC, zadzwonić na zmianę. Ale magazyn nie czeka w nieskończoność.
>
> Pamiętajcie: **„nie wiemy jeszcze”** to uczciwa informacja dla zarządu. Lepiej niż udawanie pewności.

**Pytanie do grupy:** „Czy lepiej czekać na 100% pewności, czy działać na 60% — i skąd wiecie, że to już 60%?”

**VISUAL CUE:** Mapa firmy w mgle — widoczne 2–3 obszary, reszta szara. Napis: „To, co widzisz ≠ cała prawda”.

#### SELF-GUIDED DELIVERY

**Headline:** Decydujesz bez pełnego obrazu.

**Punkty:**
- Każdy widzi inny fragment sytuacji.
- Czekanie ma koszt; działanie też.
- „Nie wiemy jeszcze” — OK w komunikacji wewnętrznej.
- Gra **nie** ukrywa błędu — mgła informacji jest zamierzona.

**NEXT** → Blok 3

---

### BLOK 3 — PEWNOŚĆ INFORMACJI

**Czas:** 1:30  
**Kompetencje:** K1 · **LO:** LO-01, LO-02, LO-03

#### CANONICAL CONTENT

Statusy **pewności informacji** (to, co wie organizacja o danym fakcie):

| Status | Znaczenie dla ucznia |
|---|---|
| **SIGNAL** | Jest ślad — to **nie** wyrok. |
| **SUSPECTED** | Sensowna hipoteza — **nie** fakt. |
| **PARTIALLY VERIFIED** | Część się potwierdza; obraz nadal niepełny. |
| **CONFIRMED** | Informacja **sprawdzona** — ale **nie** oznacza „wiemy wszystko o incydencie”. |
| **RETRACTED** | Późniejsza informacja **koryguje** wcześniejszą — to nie „bug w grze”. |

**Najważniejsze zdanie:** CONFIRMED dotyczy **konkretnej informacji**, nie całego incydentu.

Dwa niezależne sygnały zwykle podnoszą pewność. Jeden sygnał — to materiał do analizy, nie materiał do paniki.

#### TEACHER DELIVERY

> Na ekranie zobaczycie chipy przy informacjach: SIGNAL, SUSPECTED, CONFIRMED i inne. To mówi **jak bardzo organizacja ufa danej wiadomości** — nie „czy magazyn jest zdrowy”.
>
> **SIGNAL** — coś mrugnęło: log, alert, telefon ze zmiany.  
> **SUSPECTED** — mamy hipotezę: „może to konto”.  
> **PARTIALLY VERIFIED** — część się zgadza, reszta jeszcze nie.  
> **CONFIRMED** — ten **konkretny fakt** został zweryfikowany.  
> **RETRACTED** — ups, wcześniejsza informacja była nieprecyzyjna. **Zmieniacie zdanie** — to dobra reakcja.
>
> **CONFIRMED nie znaczy „sprawa zamknięta”.** Możecie potwierdzić „dziwne logowanie”, a nadal nie wiedzieć, co dotknęło magazyn.

**Pytanie do grupy:** „SOC mówi CONFIRMED na ‚podejrzane logowanie’. Czy możecie już odciąć cały magazyn?” (oczekiwane: niekoniecznie — to inna decyzja)

**VISUAL CUE:** Pasek Feed z chipami SIGNAL → SUSPECTED → CONFIRMED. Osobno RETRACTED ze strzałką „zmiana oceny”.

#### SELF-GUIDED DELIVERY

**Headline:** Pewność informacji — osobna skala.

**Punkty:**
- **SIGNAL** → ślad, nie werdykt.
- **SUSPECTED** → hipoteza.
- **PARTIALLY VERIFIED** → częściowo potwierdzone.
- **CONFIRMED** → ten fakt sprawdzony — **nie** „cały incydent rozwiązany”.
- **RETRACTED** → korekta — zmień ocenę.

**NEXT** → Blok 4

---

### BLOK 4 — KONTO / PHISHING / MFA

**Czas:** 1:30  
**Kompetencje:** K2, K4 · **LO:** LO-04

#### CANONICAL CONTENT

**Konto użytkownika** to cyfrowy klucz: ktoś zalogowany może czytać pocztę, zatwierdzać zmiany, wchodzić do systemów zgodnie ze swoimi uprawnieniami.

**Phishing** — próba skłonienia kogoś do podania hasła, kodu albo kliknięcia w coś, co daje atakującemu dostęp **jako legalny użytkownik**.

**MFA** (wieloskładnikowe logowanie) — drugi krok potwierdzenia (telefon, aplikacja). Utrudnia **nowe** logowanie; **nie** anuluje już otwartej sesji.

W incydencie często zaczyna się od pytania: **czy to naprawdę ta osoba?** — zanim dotkniecie całej firmy.

#### TEACHER DELIVERY

> Atakujący często nie „łamie muru” od razu. Czasem **używa czyjegoś konta** — bo ktoś kliknął w fałszywy link, albo zdradził kod z SMS-a.
>
> **Phishing** to nie tylko „głupi mail”. To scenariusz: podszywasz się pod IT, szefa, dostawcę — i prosisz o coś, co daje dostęp.
>
> **MFA** pomaga — ale pamiętajcie: jeśli ktoś **już** jest zalogowany, samo MFA nie magicznie go wyrzuca.
>
> W grze będziecie czasem musieli **potwierdzić tożsamość** zanim zetniecie coś większego — np. cały kanał zleceń od klientów.

**Pytanie do grupy:** „Co groźniejsze: skompromitowane konto magazyniera czy konto bez MFA w biurze — czy to zależy od uprawnień?”

**VISUAL CUE:** Ikona klucza + skrzynka „Phishing?” + telefon MFA. Bez prawdziwych nazw kont.

#### SELF-GUIDED DELIVERY

**Headline:** Konto to klucz — phishing go kradnie.

**Punkty:**
- Konto = logowanie + uprawnienia w systemach.
- Phishing = wyłudzenie dostępu jako „legalny” user.
- MFA = drugi krok; chroni **nowe** logowanie.
- Najpierw często weryfikujesz **kto** — potem **co** odciąć.

**NEXT** → Blok 5

---

### BLOK 5 — ORGANIZACJA (COMPANY-01)

**Czas:** 1:30  
**Kompetencje:** K5 · **LO:** LO-09

#### CANONICAL CONTENT

**COMPANY-01** (NEXORA Logistics — nazwa robocza) to polski operator logistyczny, ok. 800 osób. Centrala w biurach; **główne centrum magazynowe pracuje 24/7**; mniejsze lokalizacje regionalne.

Łańcuch fizyczny, który musi być w głowie:

**ZLECENIE → MAGAZYN → KOMPLETACJA → ZAŁADUNEK → TRANSPORT**

Cyber **dotyka towaru**: postój IT może oznaczać wolniejszą rampę, błędne etykiety, opóźnione auta, telefony od klientów.

Zespoły w grze (jako źródła informacji, nie inni gracze): SOC zewnętrzny, IT, tożsamość, sieć, magazyn, transport, zarząd (CEO, COO), DPO.

#### TEACHER DELIVERY

> Gramy w firmie, która **nie jest „tylko IT”**. To magazyn, rampa, auta, klienci z umowami SLA.
>
> Zlecenie wpada — ręcznie albo automatycznie. Magazyn **kompletuje** towar. **Ładuje** na pojazd. **Transport** dowozi w oknie czasowym.
>
> Gdy coś padnie w systemie, fizyczny świat **nie znika** — ludzie próbują jechać na papierze, telefonie, Excelu. Tylko **wolniej**, z błędami i presją.
>
> Wy jesteście dowódcą incydentu — nie siedzicie w serwerowni sami. Macie SOC, IT, magazyn, COO, który pyta „czy rampa jedzie”.

**Pytanie do grupy:** „Co wcześniej odczuje klient: że padł monitoring, czy że nie ma statusu przesyłki?”

**VISUAL CUE:** Schemat 5 kroków (zlecenie → transport). Zdjęcie rampy / wózka — nie diagram 29 węzłów.

#### SELF-GUIDED DELIVERY

**Headline:** Logistyka 24/7 — cyber ma cenę w towarze.

**Punkty:**
- COMPANY-01: operator logistyczny, magazyn non stop.
- Łańcuch: zlecenie → kompletacja → załadunek → transport.
- Postój IT = wolniejsza lub chaotyczna operacja.
- Ty koordynujesz zespoły — SOC, IT, magazyn, zarząd.

**NEXT** → Blok 6

---

### BLOK 6 — WMS / TMS / EDI·API

**Czas:** 1:30  
**Kompetencje:** K5 · **LO:** LO-09, LO-16

#### CANONICAL CONTENT

Trzy systemy operacyjne — minimum przed pierwszą decyzją:

| System | Jedno zdanie |
|---|---|
| **WMS** (Warehouse Management System) | Mówi magazynowi, **co znaleźć, skompletować, zapakować i przygotować do wysyłki**. |
| **TMS** (Transport Management System) | Pomaga **zaplanować transport**: trasy, auta, okna załadunku. |
| **EDI / API** (hub integracji) | **Automatyczny kanał zleceń** i statusów między klientami a firmą — bez ręcznego przepisywania każdego zamówienia. |

WMS i TMS **współpracują**, ale **można je dotknąć osobno** — decyzja o odcięciu jednego nie jest automatycznie decyzją o drugim.

Na **Situation Board** zobaczysz m.in. te obszary — nie musisz pamiętać całej mapy IT.

#### TEACHER DELIVERY

> **WMS** — mózg operacji magazynowej: lokacje, picking, etykiety. Bez niego magazyn **może** jechać ręcznie — ale wolno i ryzykownie.
>
> **TMS** — dyspozycja transportu: które auto, która trasa, które okno. Transport może żyć chwilę **osobno** od magazynu — ale bez danych z rampy szybko się rozjedzie.
>
> **EDI/API** — automatyczne zlecenia od klientów. Utniesz hub — nowe zamówienia **nie wpłyną same**. Stare mogą jeszcze być w kolejce.
>
> Na planszy zobaczycie te bloki jako **węzły organizacji** — to wasz obraz „jak wygląda firma”, nie lista do wykucia na pamięć.

**Pytanie do grupy:** „Co bardziej boli w pierwszej godzinie: brak WMS czy brak TMS — zależy od fazy dnia?”

**VISUAL CUE:** Trzy ikony: regał (WMS), ciężarówka (TMS), strzałka między firmami (EDI/API). Podpis: „Operacje, nie serwerownia”.

#### SELF-GUIDED DELIVERY

**Headline:** Trzy systemy, które łączą IT z rampą.

**Punkty:**
- **WMS** — co kompletować i wysyłać z magazynu.
- **TMS** — jak planować transport.
- **EDI/API** — automatyczne zlecenia i statusy.
- Można ograniczyć jeden bez automatycznego cięcia wszystkiego.

**NEXT** → Blok 7

---

### BLOK 7 — TOŻSAMOŚĆ (IDENTITY)

**Czas:** 1:00  
**Kompetencje:** K4 · **LO:** LO-04

#### CANONICAL CONTENT

**Tożsamość** w tej firmie to ludzie i ich konta — w biurze (poczta, Teams), w magazynie (terminale), u administratorów.

W świecie gry występują m.in. **Entra ID** (chmura, MFA, M365) i **Active Directory** (środowisko lokalne: stacje, serwery, część aplikacji magazynowych). To **dwa powiązane światy logowania** — awaria albo blokada po jednej stronie **nie zawsze** gasi drugą od razu.

Incident Commander **nie** konfiguruje tych systemów ręcznie — **decyduje**, kiedy poprosić zespół tożsamości o blokadę konta, sesji albo roli — i **jak szeroki** ma być zakres.

#### TEACHER DELIVERY

> Kto może się zalogować — i **gdzie** — to tożsamość. Biuro na poczcie w chmurze. Magazyn na terminalu. Admin na serwerze.
>
> W firmie hybrydowej macie **Entra** i **Active Directory**. Nie musicie tego dziś konfigurować — musicie wiedzieć, że **„wyłączyć logowanie”** może znaczyć coś innego dla biura niż dla rampy.
>
> Wasza rola: **kiedy** i **jak szeroko** prosić o cięcie dostępu — nie wpisywanie komend.

**VISUAL CUE:** Dwa obłoki: „Chmura (Entra, M365)” i „Lokalnie (AD, magazyn)”. Strzałka „sync” — bez technikaliów sync.

#### SELF-GUIDED DELIVERY

**Headline:** Tożsamość — kto wchodzi i z jakim prawem.

**Punkty:**
- Konta ludzi: biuro, magazyn, admini.
- Entra ID (chmura) i Active Directory (lokalnie) — powiązane, nie identyczne.
- Ty decydujesz o zakresie blokady — IT ją wykonuje.

**NEXT** → Blok 8

---

### BLOK 8 — CONTAINMENT / RECOVERY

**Czas:** 1:00  
**Kompetencje:** K4, K6 · **LO:** LO-08, LO-11

#### CANONICAL CONTENT

**Containment** (ograniczenie wpływu) — działania, które **ograniczają dalszy wpływ** incydentu: odcięcie konta, izolacja urządzenia, ograniczenie dostępu, odłączenie systemu od sieci.

**Recovery** (odtwarzanie) — **przywracanie działania** po awarii, izolacji albo ataku. To **osobny tor** — nie to samo co containment.

Recovery **nie** jest: „backup → wszystko działa jak wczejniej”.  
**Odtwarzanie również jest procesem decyzyjnym** — kolejność, zaufanie do kopii, ludzie na zmianie.

Nie ma jednej uniwersalnej reguły typu „zawsze tnij najwężej” albo „zawsze tnij najszybciej”.  
**Dobierasz zakres działania do tego, co wiesz, ryzyka czekania i kosztu dla firmy** — i potrafisz to **uzasadnić**.

#### TEACHER DELIVERY

> **Containment** — „nie pozwólmy, żeby rosło”. Odcięcie konta. Izolacja komputera. Odłączenie systemu. Czasem to konieczne — ale **szersze cięcie** może **zatrzymać magazyn**.
>
> **Recovery** — „wróćmy do jazdy”. Ale nie ma magicznego przycisku. Kopia może być stara, brudna albo niedostępna. Ludzie muszą wiedzieć, **co** przywracamy **najpierw**.
>
> W grze **nie ma jednej poprawnej sekwencji**. Są decyzje z kosztem. Przykład z późniejszej rozgrywki: czasem wąskie cięcie konta wystarczy; czasem trzeba dotknąć systemu operacyjnego — **ale to wasza ocena**, nie sztywna reguła tutoriala.

**Pytanie do grupy:** „Containment czy recovery — co robisz, gdy magazyn jeszcze jedzie, ale masz podejrzenie na koncie admina?”

**VISUAL CUE:** Dwa tory: CONTAINMENT (tarcza — „ogranicz”) vs RECOVERY (strzałka w górę — „przywróć”). Nie timeline restore.

#### SELF-GUIDED DELIVERY

**Headline:** Najpierw ogranicz wpływ — potem odtwarzaj.

**Punkty:**
- **Containment** — ograniczenie dalszego wpływu (konto, urządzenie, system).
- **Recovery** — przywracanie działania; **nie** instant fix.
- To dwa **osobne** tory decyzyjne.
- Zakres dobierasz do wiedzy, ryzyka i kosztu — nie do sztywnej reguły.

**NEXT** → Blok 9

---

### BLOK 9 — SECURITY VS BUSINESS

**Czas:** 1:00  
**Kompetencje:** K5, K7 · **LO:** LO-09, LO-13

#### CANONICAL CONTENT

Decyzje bezpieczeństwa **mają cenę operacyjną**. Bezpieczniejsza decyzja techniczna **może** spowolnić magazyn, zablokować zlecenia, opóźnić transport albo zwiększyć chaos na zmianie.

Przykład **neutralny** (bez liczb z gry):  
*Jeżeli odetniesz system magazynowy, możesz zmniejszyć ryzyko cyber — ale jednocześnie magazyn może stracić część wydajności.*

**Pytanie retoryczne** (nie odpowiadaj za gracza):  
*Czy zawsze najbezpieczniejsza decyzja techniczna jest najlepszą decyzją dla całej firmy?*

SOC **rekomenduje** — Incident Commander **decyduje** o odcięciu krytycznej operacji. COO będzie bronił rampy — to **nie wróg**, to presja biznesowa.

#### TEACHER DELIVERY

> Tu łamie się schemat „bezpiecznie = dobrze”. Możecie **uratować IT** i **ukarać magazyn** — albo odwrotnie.
>
> Wyobraźcie sobie: izolujecie WMS, żeby być spokojni. Ryzyko cyber spada — ale picking spada też. Klienci dzwonią. COO pyta, czy **musiało** być tak szeroko.
>
> **Nie ma automatycznej dobrej odpowiedzi.** Gra sprawdzi, czy potraficie **ważyć** — i czy mówicie zarządowi prawdę, gdy **nie wiecie**.
>
> Zapamiętajcie jedno pytanie na całą sesję: *Czy najbezpieczniejsze technicznie jest najlepsze dla firmy?*

**VISUAL CUE:** Waga: „Bezpieczeństwo IT” vs „Rampa / klienci”. Bez procentów.

#### SELF-GUIDED DELIVERY

**Headline:** Bezpieczeństwo i biznes ciągną w różne strony.

**Punkty:**
- Izolacja systemu może chronić — i spowolnić operacje.
- SOC doradza; **Ty** decydujesz o krytycznych cięciach.
- COO / CEO reprezentują presję SLA — to część scenariusza.
- Najbezpieczniejsze ≠ zawsze najlepsze dla całej firmy.

**NEXT** → Blok 10

---

### BLOK 10 — ROLA IC + MISSION CONTROL (wstęp)

**Czas:** 0:45 (rola) — szczegóły UI w sekcji 6  
**Kompetencje:** K7 · **LO:** LO-14, LO-16

#### CANONICAL CONTENT

**Incident Commander (Dowodzący incydentem)** — Ty w tej grze.

**Nie musisz:** konfigurować firewalli, analizować malware, wpisywać komend administratora.

**Musisz:** ustalać priorytety, wydawać rozkazy zespołom, ważyć informacje, zarządzać uwagą, komunikować niepewność, podejmować decyzje przy presji czasu.

To gra **strategiczna** — dowodzenie incydentem, nie „klikaj w poprawne narzędzie”.

Mission Control to kokpit. Podstawy w sekcji 6.

#### TEACHER DELIVERY

> Nie gracie pentesterów. Gracie **szefa operacji kryzysowej IT** w firmie, która musi **dowieźć towar**.
>
> Klikniecie „izoluj” — ale najpierw **decydujecie**, czy w ogóle, co, i jak szybko informujecie COO.
>
> Za chwilę — **90 sekund** — przejdziemy po ekranie gry. Na razie: **wy jesteście centrum dowodzenia**.

**VISUAL CUE:** Sylwetka IC na tle Mission Control (zblurowany UI). Lista „decydujesz / nie musisz”.

#### SELF-GUIDED DELIVERY

**Headline:** Jesteś Incident Commanderem.

**Punkty:**
- Priorytety, rozkazy, komunikacja — **Twoja** rola.
- Nie musisz być adminem firewalla ani analitykiem malware.
- Gra testuje **decyzje**, nie skróty klawiszowe.
- Dalej: 90 s po Mission Control.

**NEXT** → Sekcja 6 (Mission Control onboarding)

---

## 5. Teacher-led script — skrót prowadzenia

Pełny tekst w blokach 1–10 (TEACHER DELIVERY). Poniżej **kartka prowadzącego** — kolejność i tempo.

| # | Blok | Czas | Uwaga prowadzącego |
|---|---|---|---|
| — | Otwarcie | 0:40 | Wciągnij w rolę; bez definicji akademickich |
| 1 | Alert / incydent / atak | 1:00 | Jedno zdanie o okupie/szyfrowaniu **tutaj** |
| 2 | Niepełna informacja | 1:00 | Podkreśl koszt czekania |
| 3 | Pewność informacji | 1:30 | Rozdziel od stanu systemu — most do bloku 3b poniżej |
| 3b | **Stan systemu (wpleciony)** | *(w bloku 3 lub 6)* | 30 s w teacher-led: patrz sekcja poniżej |
| 4 | Konto / phishing / MFA | 1:30 | Bez kampanii, bez nazw kont |
| 5 | Organizacja | 1:30 | Łańcuch fizyczny 5 kroków |
| 6 | WMS / TMS / EDI | 1:30 | Trzy ikony — nie 10 węzłów |
| 7 | Tożsamość | 1:00 | Entra + AD — dwa światy |
| 8 | Containment / recovery | 1:00 | Bez „zawsze tnij wąsko” |
| 9 | Security vs business | 1:00 | Pytanie retoryczne — **nie** odpowiadaj |
| 10 | Rola IC | 0:45 | Most do UI |
| — | Mission Control | 1:30 | Sekcja 6 |

### Wpleciony fragment — STAN SYSTEMU (teacher-led, ~30 s)

W bloku 3 lub na początku bloku 6 prowadzący mówi:

> Osobna sprawa: **jak działa system** — SPRAWNY, OGRANICZONY, IZOLOWANY, NIEDOSTĘPNY, ODTWARZANY. To **stan operacyjny**, nie to samo co SIGNAL czy CONFIRMED. Możecie **wiedzieć**, że logowanie jest podejrzane, a WMS **jeszcze jedzie** — albo odwrotnie. **Nie mieszajcie osi.**

**VISUAL CUE:** Dwie osie prostopadle: „Pewność informacji” vs „Stan systemu”.

---

## 6. Self-guided script — skrót

Pełny tekst w blokach 1–10 (SELF-GUIDED DELIVERY). Każdy ekran: **headline + 2–4 punkty + NEXT**.

Dodatkowy ekran **3b — Stan systemu** (wpleciony między blok 3 a 4):

**Headline:** Pewność informacji ≠ stan systemu.

**Punkty:**
- Informacja: SIGNAL … CONFIRMED (jak wierzysz wiadomości).
- System: SPRAWNY / OGRANICZONY / IZOLOWANY / NIEDOSTĘPNY / ODTWARZANY.
- Dwie osie **niezależne**.

**NEXT** → Blok 4

Self-guided **nie** zawiera quizu końcowego. Dozwolone: „Pokaż przykład” (statyczny), bez strategicznych wyborów.

---

## 7. Mission Control onboarding (~90 s)

Wspólne po blokach 1–10. Ostatni element przed T0.

### CANONICAL CONTENT

| Element | Uczeń ma wiedzieć |
|---|---|
| **FEED** | Co **nowego** wpłynęło: alert, telefon, raport SOC. Źródło + **pewność** informacji. Ważne nie ginie w szumie. |
| **SITUATION BOARD** | Jak wygląda firma według **obecnej wiedzy** — nie ukrytej prawdy silnika. WMS, transport, tożsamość jako obszary do obserwacji. |
| **COMMAND STACK** | Co **wymaga uwagi**: Needs, In Progress, Pressure. Kolejka spraw, nie lista zadań tutoriala. |
| **COMMAND DOCK** | Narzędzia: komunikacja, dowody, działania, playbook, terminy. Tu **składasz** rozkazy — nie wszystko naraz. |
| **STATUS / CONFIDENCE** | Chip przy **informacji** — nie myl z **stanem systemu** na Boardzie. |
| **ACTION IN PROGRESS** | Rozkaz **trwa** — efekt może przyjść po czasie. |

Nie tłumacz wszystkich przycisków. Nie pokazuj ścieżki ataku.

### TEACHER DELIVERY (~90 s)

> **Feed** — ticker świata: co wpada. Czytajcie **pewność**, nie tylko nagłówek.  
> **Situation Board** — mapa firmy **tak, jak ją dziś rozumiecie**. Będzie się zmieniać.  
> **Command Stack** — „co pilne”. Nie musicie załatwić wszystkiego naraz.  
> **Command Dock** — skrzynka narzędzi: pogadaj, zbierz dowód, wydaj rozkaz.  
> **Action in progress** — ktoś **wykonuje** — magazyn nie resetuje się w sekundę.  
> **Status vs confidence** — system **OGRANICZONY** to nie to samo co alert **CONFIRMED**. Dwie osie — pamiętajcie z briefingu.

**VISUAL CUE:** Zrzut Mission Control z podpisanymi 4 strefami (Feed, Board, Stack, Dock). Strzałki — bez numeracji przycisków.

### SELF-GUIDED DELIVERY (~90 s, 4 ekrany)

**Ekran MC-1 — Headline:** Feed i Board  
- **Feed** — nowe informacje + pewność.  
- **Board** — obraz organizacji z **Twojej** wiedzy.  
**NEXT**

**Ekran MC-2 — Headline:** Stack i Dock  
- **Stack** — co wymaga uwagi / decyzji.  
- **Dock** — comms, dowody, działania.  
**NEXT**

**Ekran MC-3 — Headline:** Czas i dwie osie  
- **Action in progress** — rozkaz trwa.  
- Pewność informacji ≠ stan systemu.  
**NEXT**

**Ekran MC-4 — Headline:** Gotowy do T0  
- Jesteś Incident Commanderem.  
- Alert to nie wyrok. Decyzje mają koszt.  
**START MISJI**

---

## 8. Terminology used (LEVEL 1 + LEVEL 2 z briefingu)

| Termin | PL / wyjaśnienie | Poziom |
|---|---|---|
| Alert | sygnał | L1 |
| Incydent | sytuacja wymagająca skoordynowanej reakcji | L1 |
| Cyberatak | celowe działanie przeciw IT / danym / dostępowi | L1 |
| SIGNAL / SUSPECTED / PARTIALLY VERIFIED / CONFIRMED / RETRACTED | pewność informacji | L1 |
| SPRAWNY / OGRANICZONY / IZOLOWANY / NIEDOSTĘPNY / ODTWARZANY | stan operacyjny systemu | L1 (w briefingu) |
| Phishing | wyłudzenie dostępu | L1 |
| MFA | drugi krok logowania | L1 |
| Containment | ograniczenie wpływu | L1 + EN |
| Recovery | odtwarzanie | L1 + EN |
| Incident Commander | dowodzący incydentem | L1 + EN |
| WMS | system magazynowy | L2 |
| TMS | system transportowy | L2 |
| EDI/API | automatyczna wymiana zleceń | L2 |
| Entra ID | tożsamość chmurowa (Microsoft) | L2 |
| Active Directory | tożsamość lokalna / domena | L2 |
| SOC | zewnętrzny monitoring bezpieczeństwa 24/7 | L2 (kontekst) |
| COO / CEO / DPO | role biznesowe / prawne | L2 (kontekst) |

**Nie wprowadzono w briefingu:** SIEM, EDR, vault, kill chain, NIS2, restore order, Domain Admin, 29 węzłów.

---

## 9. Spoiler audit

Dla każdego bloku: czy ujawnia W-02 / kampanię? **Wynik: PASS** (po redakcji).

| Blok | Ujawnia W-02? | Uwagi |
|---|---|---|
| Otwarcie | Nie | Ogólna sytuacja logistyczna |
| 1 Alert/incydent | Nie | Ogólne zdanie o okupie — bez zapowiedzi scenariusza |
| 2 Niepełna informacja | Nie | Meta-zasada gry |
| 3 Pewność | Nie | Statusy learner-facing tylko |
| 3b Stan systemu | Nie | Osie UI, nie timeline |
| 4 Konto/phishing | Nie | Brak initial account, kampanii, wektora |
| 5 Organizacja | Nie | COMPANY-01 publiczny z W-01 |
| 6 WMS/TMS/EDI | Nie | Brak „TMS SaaS wektor”, „WMS zostanie przejęty” |
| 7 Tożsamość | Nie | Entra/AD ogólnie; brak sync jako wektor |
| 8 Containment/recovery | Nie | Brak vault, restore order, DW12 |
| 9 Security vs business | Nie | Przykład neutralny; brak % i DW |
| 10 Rola IC | Nie | |
| Mission Control | Nie | Brak HUD ataku, hidden stage |

**Zakazane elementy — status:**

| Element | W briefingu? |
|---|---|
| Initial compromised account | ❌ |
| TMS route / WMS path | ❌ |
| ORBIT MARGIN | ❌ |
| Destructive trigger | ❌ |
| Exfil | ❌ (tylko ogólne „dane” w K8 poza briefingiem) |
| Backup/vault outcome | ❌ |
| ALT A–D | ❌ |
| Ending conditions | ❌ |

---

## 10. Training vs Exam implications

Zapis do kontraktu E-01/E-02 (zgodnie z LGD):

### TRAINING

- Pełny briefing (teacher-led lub self-guided) przed T0.
- Mission Advisor / context help: **termin**, **mechanizm**, **dlaczego istotne**, **typy ryzyka** — **nigdy** „wybierz X” / „co teraz zrobić”.
- Tooltipy i glossary: pełne definicje + kontekst organizacyjny.
- Playbook: pełniejszy — bez facitu sekwencji.

### EXAM

- **Zostaje:** definicje terminów, znaczenie statusów pewności i stanu systemu, pomoc UI (Feed, Board, Stack, Dock).
- **Usunięte:** interpretacja sytuacyjna, porada decyzyjna, „co teraz zrobić”, sugerowanie konsekwencji.
- Advisor: tylko kategorie A (termin) i B (UI) — bez strategicznego C.

Briefing **ten sam** przed EXAM — różnica zaczyna się **w trakcie** misji (pomoc), nie w treści miniwykładu.

---

## 11. Debrief — dwustopniowy (kontrakt E-01/E-02)

**STAGE 1 — PLAYER KNOWLEDGE TIMELINE** (student-facing):  
„Co **wiedziałeś wtedy**?” — oś decyzji i informacji **z perspektywy gracza**, bez Ground Truth.

**STAGE 2 — TEACHER-LED GROUND TRUTH REVEAL** (teacher-only):  
Dopiero po refleksji Stage 1 prowadzący **może** pokazać: co naprawdę się działo w silniku, timeline kampanii, typowe błędy przy oknach decyzyjnych.

Ground Truth **nie** jest student-facing podczas misji.  
Pełny projekt debriefu — **E-06**, nie E-02.

---

## 12. Baseline visibility — wykorzystanie bez przeciążenia

Rekomendowane `baselineVisibleNodeIds` (10 węzłów z E-01) **nie są** listą do zapamiętania w briefingu.

**W briefingu explicite:**

| Priorytet narracji | Węzły / pojęcia |
|---|---|
| **Główna scena** | WMS, TMS, integration-hub (EDI/API), warehouse-automation / operacje magazynu |
| **Tożsamość** | Entra ID, Active Directory, M365 — „dwa światy logowania” |
| **Kontekst** | regional-ops (regiony), customer-portal (klient dzwoni), soc-external (skąd alerty) — **jednym zdaniem**, nie lista 10 |

Uczestnik **widzi** te obszary na Boardzie od T0 — briefing daje **sens**, nie nazwę po nazwie. Reszta grafu (klasa B) odkrywa się w grze.

---

## 13. Delivery notes

### Teacher-led

- Czytaj TEACHER DELIVERY **prawie 1:1** — naturalny język, nie monoton podręcznik.
- Pytania do grupy **opcjonalne** — nie wydłużają ponad 13 min bez kontroli.
- INTERMEDIATE: skróć bloki 5–7 o ~30 s łącznie.
- PROFESSIONAL: może pominąć bloki 4–6 definicyjnie — **nie** osobna treść V1.

### Self-guided

- Jeden ekran ≈ 45–75 s czytania.
- „Pokaż przykład” = statyczna ilustracja VISUAL CUE — bez gałęzi decyzyjnej.
- Po MC-4 → bezpośrednio T0 (bez quizu).

### Wspólne

- Po zmianie treści: `scripts/publish-cyber-review-docs.sh` → review channel.
- Treść briefingu **nie** trafia automatycznie na whitelist review (tylko 6 dokumentów E-01) — dopisanie do whitelisty = osobna decyzja LGD.

### Ransomware — lokalizacja jednego zdania

**Blok 1** (CANONICAL + TEACHER + SELF-GUIDED):  
*„Niektóre incydenty mogą prowadzić do szyfrowania… okupu… nie oznacza automatycznego końca misji.”*  
Bez sugestii, że V1 „na pewno” tam dojdzie.

---

## 14. Open questions (max 5 do decyzji LGD)

1. **Whitelist review:** Czy `CYBER-PRE-GAME-BRIEFING-V1.md` ma wejść na `docs.gramy.biz/cyber-review/` po akceptacji?
2. **Self-guided V1 produkt:** Czy self-guided jest **obowiązkowy** w pilotażu, czy wystarczy teacher-led + skrócony self-guided jako PDF?
3. **Ekran 3b:** Czy stan systemu zostaje **osobnym** ekranem self-guided, czy tylko wpleciony w blok 3 (obecnie: oba — teacher wpleciony, self osobny ekran)?
4. **SOC / portal na Boardzie:** Czy baseline 10 węzłów zostaje, czy E-03 registry przeniesie SOC i portal do klasy B (tooltip only)?
5. **Długość EXAM briefingu:** Czy EXAM używa **identycznego** briefingu, czy skróconej wersji samych bloków 3 + 6 + MC (tylko UI)?

---

## 15. Pięć najważniejszych zdań uczestnika

1. **Alert to sygnał — nie wyrok.**
2. **CONFIRMED dotyczy informacji — nie całego incydentu.**
3. **Pewność informacji i stan systemu to dwie osobne osie.**
4. **Containment ogranicza wpływ; recovery to osobny, trudny proces decyzyjny.**
5. **Najbezpieczniejsza decyzja techniczna nie zawsze jest najlepsza dla całej firmy.**

---

## 16. Powiązania

| Dokument | Relacja |
|---|---|
| `CYBER-CURRICULUM-MAP-V1.md` | §6 zakres 10 tematów; §10 baseline; §14 Advisor |
| `CYBER-WORLD-V1.md` | COMPANY-01, WMS/TMS/hub, role, tryby manual |
| `CYBER-MISSION-CONTROL-V1.md` | W-03 — szczegóły UI poza 90 s onboarding |
| `CYBER-INCIDENT-V1.md` | **nie** cytowany w treści — spoiler firewall |

---

*E-02 V1 — treść i struktura. Implementacja UI / slajdów / registry: kolejne karty EDU.*