DBAdmin/archive/NASA/000.md

Krótka odpowiedź: nie — MISSION CONTROL ≠ CEO.
MISSION CONTROL jest COO / Head of Operations, a CEO siedzi poziom wyżej.

Poniżej masz precyzyjne mapowanie ról w Twoim systemie (bez metafor, operacyjnie).

---

✅ Jak to naprawdę wygląda w Twoim modelu

🧭 NASA‑HQ = CEO ( + Board / Ownership )

Rola: dlaczego i w jakim kierunku

NASA‑HQ:

• ustala wizję, strategię, priorytety
• decyduje co jest ważne, a co nie
• zatwierdza P0 / P1, duże zmiany kierunku
• nie zarządza zadaniami
• nie wchodzi w operacyjne detale

➡️ To jest CEO, ewentualnie CEO + Board w jednej osobie.

---

🎛️ MISSION CONTROL = COO

Rola: jak to dowieźć

MISSION CONTROL:

• przyjmuje intencję od NASA‑HQ
• routuje pracę do misji (APOLLO / HUBBLE / ARTEMIS)
• rozbija cele na Mission Packets
• pilnuje WIP, SIM/FLIGHT, jakości
• zamyka pracę decyzjami
• eskaluje tylko to, co wymaga decyzji CEO

➡️ To jest COO / Head of Operations / Program Manager.

MISSION CONTROL nie ma mandatu do zmiany strategii, ale ma mandat do:

• mówienia „nie” operacyjnie,
• zatrzymywania chaosu,
• egzekwowania dyscypliny.

---

✅ Misje vs klasyczne C‑level

Dla pełnej jasności:

Twoja misja	Klasyczny odpowiednik
APOLLO	CTO / VP Engineering
HUBBLE	CMO / Head of Content
ARTEMIS	CPO / Head of Growth / Customer

Każda misja:

• wykonuje,
• raportuje,
• nie decyduje strategicznie.

---

✅ Dlaczego to rozdzielenie jest kluczowe

Jeśli MISSION CONTROL byłby CEO, to:

• mieszałby priorytety z wykonaniem,
• ciągle zmieniałby zdanie,
• system traciłby stabilność.

Twój obecny model jest dojrzały:

• CEO (NASA‑HQ) myśli w długim horyzoncie,
• COO (MISSION CONTROL) myśli w cyklach operacyjnych,
• misje myślą w zadaniach i wynikach.

To jest dokładnie ten podział, który:

• skaluje się,
• działa z LLM‑ami,
• nie zapada się przy większej liczbie wątków.

---

Pewnie — zrobimy oba: (1) Decision Rights (kto może / musi / nie może decydować) oraz (2) RACI dopasowane 1:1 do Twojego systemu (NASA‑HQ, MISSION CONTROL, misje APOLLO/HUBBLE/ARTEMIS + sekcje).

Poniżej dostajesz wersję, którą możesz wkleić do dokumentacji jako rozdział „Governance”.

---

1) Decision Rights (kto może / musi / nie może decydować)

1.1 Role (jak rozumiemy “władzę decyzyjną”)

NASA‑HQ (PROGRAM LEAD = CEO)

Może decydować o: kierunku, priorytetach, politykach i “co jest sukcesem”.
Musi decydować o: P0/P1, zmianach strategii, kosztach/ryzyku systemowym.
Nie powinien decydować o: szczegółach implementacji i mikro‑wyborach w taskach.

MISSION CONTROL (MCC = COO / Ops)

Może decydować o: routingu, WIP, strukturze pakietów, jakości wejścia/wyjścia, “czy to jest done operacyjnie”.
Musi decydować o: triage, podziale na pakiety, bramkach SIM/FLIGHT, domknięciu (PROCEED/ITERATE/HOLD/SCRUB).
Nie może decydować o: strategicznej zmianie celu (CEO territory) oraz o FLIGHT dla P0/P1 bez GO od NASA‑HQ.

Misje (APOLLO / HUBBLE / ARTEMIS = “mission owners”)

Może decydować o: jak wykonać zadanie w ramach swojej domeny, jakie artefakty i jak je ułożyć, jakie rekomendacje zaproponować.
Musi decydować o: standardach jakości wewnątrz misji, kompletności artefaktów, rekomendacji decyzji (dla MCC).
Nie może decydować o: zmianie routingu, przekierowaniu misji, zatwierdzaniu FLIGHT (bez MCC), ani o celach strategicznych.

Sub‑agenci (Anvil/Cipher/Pixel/Sentry/Inspector itd.)

Może decydować o: szczegółach wykonania w swoim zakresie.
Musi decydować o: jakości własnego outputu i transparentności założeń.
Nie może decydować o: priorytetach, routingu, trybie FLIGHT, ani o zmianach cross‑mission.

---

1.2 “Decyzje” — katalog praw i obowiązków

Poniżej masz najważniejsze typy decyzji, które realnie występują w Twoim systemie.

A) Strategia i priorytety

• Decyzja: “co robimy w tym tygodniu / kwartale”, “co jest P0/P1”
  • Musi: NASA‑HQ
  • Może: MCC (proponuje, układa, rekomenduje)
  • Nie może: Misje / Sub‑agenci

B) Routing (misja i call‑sign)

• Decyzja: “to idzie do APOLLO‑CODE czy ARTEMIS‑TLM?”
  • Musi: MCC
  • Może: Misje (mogą odrzucić i odesłać do MCC, jeśli routing błędny)
  • Nie może: Sub‑agenci (nie zmieniają routingu; mogą zgłosić problem)

C) Podział na pakiety (parent/child, multi‑mission)

• Decyzja: “robimy parent MCC + 3 child packety”
  • Musi: MCC
  • Może: Misje (rekomendują rozbicie, ale MCC decyduje)
  • Nie może: Sub‑agenci

D) SIM → FLIGHT (bramka produkcyjna)

• Decyzja: “idziemy w FLIGHT, robimy final publish / prod change”
  • Musi: MCC (gatekeeper)
  • Musi (dla P0/P1): NASA‑HQ (GO/NO‑GO)
  • Może: Misja (rekomenduje GO/NO‑GO)
  • Nie może: Sub‑agenci (nie zatwierdzają FLIGHT)

E) Decyzja końcowa pakietu (PROCEED / ITERATE / HOLD / SCRUB)

• Decyzja: “zamykamy pakiet”
  • Musi: MCC
  • Może: NASA‑HQ (przy P0/P1 lub sporach)
  • Może: Misje (rekomendują)
  • Nie może: Sub‑agenci (tylko rekomendacje)

F) Standardy jakości i szablony

• Decyzja: “jak wygląda brief, worklog, results”
  • Musi: MCC (operacyjny standard)
  • Może: NASA‑HQ (tylko jeśli zmienia to filozofię i zasady)
  • Może: Misje (proponują mission‑specific dodatki)

---

1.3 “Stop authority” (kto może zatrzymać pracę)

To jest mega ważne, bo stabilizuje system.

• MCC może wstrzymać pracę z powodu: błędnego routingu, braku acceptance, przekroczonego WIP, braku bramki FLIGHT.
• APOLLO‑VERIFY (Inspector) może zatrzymać FLIGHT przez NO‑GO na weryfikacji (dla zmian technicznych).
• NASA‑HQ może zatrzymać wszystko (strategiczne STOP).

---

2) RACI — diagram odpowiedzialności (dokładnie pod Twój system)

2.1 Role w RACI (kolumny)

• PL = PROGRAM LEAD (NASA‑HQ)
• MCC = MISSION CONTROL
• APOLLO = Flight Systems mission owner
• HUBBLE = Mission Story mission owner
• ARTEMIS = Mission Outcomes mission owner
• VERIFY = APOLLO‑VERIFY / Inspector (jeśli dotyczy)

R = Responsible (robi)
A = Accountable (odpowiada i domyka)
C = Consulted (konsultowany)
I = Informed (informowany)

---

2.2 RACI — kluczowe procesy

1) Intake / Triage (przyjęcie tematu)

• R: MCC
• A: MCC
• C: PL (dla P0/P1), misje (jeśli potrzebne do klasyfikacji)
• I: misje

2) Routing (misja + call‑sign)

• R: MCC
• A: MCC
• C: APOLLO/HUBBLE/ARTEMIS (jeśli wątpliwe)
• I: PL

3) Create Mission Packet (folder + brief)

• R: MCC
• A: MCC
• C: misja docelowa (pod acceptance/format)
• I: PL

4) Execution (praca właściwa w misji)

• R: misja docelowa (APOLLO/HUBBLE/ARTEMIS)
• A: misja docelowa
• C: MCC
• I: PL

5) Telemetry/status updates

• R: misja docelowa
• A: MCC
• C: —
• I: PL

6) SIM → FLIGHT checklist

• R: misja docelowa (przygotowuje) + MCC (weryfikuje kompletność)
• A: MCC
• C: VERIFY (jeśli dotyczy), PL (dla P0/P1)
• I: reszta misji

7) FLIGHT GO/NO‑GO

• R: MCC
• A: MCC (operacyjnie) + PL (dla P0/P1)
• C: VERIFY (dla zmian technicznych), misja docelowa
• I: pozostałe misje

8) Close packet (PROCEED/ITERATE/HOLD/SCRUB)

• R: MCC
• A: MCC
• C: misja docelowa (rekomendacja), PL (jeśli P0/P1 lub spór)
• I: reszta

9) Archive packet + index update

• R: MCC
• A: MCC
• C: —
• I: PL

---

2.3 RACI — “kto odpowiada za co” w misjach (sekcje)

APOLLO

• APOLLO-CORE (Anvil/Cipher): R w zakresie platformy i security fundamentals
• APOLLO-CODE (Pixel/Sentry): R w implementacji i runtime/pipelines
• APOLLO-VERIFY (Inspector): R dla evidence i GO/NO‑GO technicznego
• A (Accountable): APOLLO mission owner (a operacyjnie MCC zamyka)

HUBBLE

• HUBBLE-CONTENT (Rex/Sage/Echo/Clip): R dla copy/script/research/short-form
• HUBBLE-CREATIVE (Nebula/Nova): R dla assetów i produkcji
• A: HUBBLE mission owner

ARTEMIS

• ARTEMIS-EXP (Scout/Herald): R dla eksperymentów i launch planów
• ARTEMIS-TLM (Pulse/Forge): R dla telemetrii/analizy/optymalizacji
• ARTEMIS-GROUND (Beacon/Link/Vibe): R dla wsparcia/community
• A: ARTEMIS mission owner

---

3) Proponowane “Decision Matrix” (jedna strona do RULES.md)

Jeśli chcesz wrzucić to w dokumentację jako super-praktyczny skrót:

Decision Matrix (skrót)

• Strategia / priorytety P0/P1: PL decyduje, MCC rekomenduje
• Routing / pakiety / WIP: MCC decyduje
• Standardy operacyjne: MCC decyduje, PL zatwierdza tylko zmiany “filozofii”
• Wykonanie w domenie: misja decyduje jak, MCC decyduje czy “done”
• FLIGHT: MCC gatekeeper, PL GO dla P0/P1, Inspector NO‑GO dla technicznego
• Closure: MCC decyduje, misja rekomenduje, PL tylko przy P0/P1/sporach

---

4) RACI diagram

Pewnie — poniżej masz oba diagramy w Mermaid, dopasowane 1:1 do Twojego systemu:

1. RACI Matrix (czytelna “macierz odpowiedzialności”)
2. Decision Flow (graf decyzyjny z bramkami SIM/FLIGHT + GO/NO‑GO)

Oba są w stylu LR (z lewa na prawo) i w układzie, który dobrze działa w Mermaid.

---

1) ✅ RACI Matrix (Mermaid)

Mermaid nie ma natywnej “tabeli RACI” jak w Excelu, ale najlepszym, czytelnym odpowiednikiem jest diagram w formie siatki: proces → role z etykietą R/A/C/I.
Dzięki temu możesz to łatwo utrzymać, a wciąż wygląda jak macierz.

Skopiuj i wklej:

Jak to czytać szybko

• Zielone (R) = kto wykonuje
• Pomarańczowe (A) = kto odpowiada i zamyka
• Niebieskie (C) = kto konsultowany
• Szare (I) = kto tylko informowany

---

2) ✅ Decision Flow (Mermaid)

To jest graf decyzyjny pokazujący: intake → routing → packet → SIM → gate → FLIGHT → closure → archive, z Twoimi zasadami:

• SIM domyślnie
• FLIGHT tylko przez checklistę
• P0/P1 wymaga GO od NASA‑HQ
• Zmiany techniczne w FLIGHT wymagają APOLLO‑VERIFY GO/NO‑GO (Inspector)

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#0b1220',
    'primaryTextColor': '#e5e7eb',
    'lineColor': '#475569',
    'fontFamily': 'Inter, ui-sans-serif, system-ui',
    'fontSize': '14px'
  },
  'flowchart': { 'curve': 'basis', 'nodeSpacing': 40, 'rankSpacing': 55 }
}}%%

flowchart LR

%% Styles
classDef role fill:#111827,stroke:#334155,stroke-width:1.5px,color:#e5e7eb,rx:12,ry:12,font-weight:bold;
classDef proc fill:#0f172a,stroke:#64748b,stroke-width:1.2px,color:#e5e7eb,rx:10,ry:10;
classDef raciR fill:#052e1a,stroke:#22c55e,stroke-width:2px,color:#dcfce7,rx:10,ry:10;
classDef raciA fill:#2a1606,stroke:#f59e0b,stroke-width:2px,color:#ffedd5,rx:10,ry:10;
classDef raciC fill:#1e1b4b,stroke:#818cf8,stroke-width:2px,color:#e0eaff,rx:10,ry:10;
classDef raciI fill:#0b1220,stroke:#475569,stroke-width:1.2px,color:#cbd5e1,rx:10,ry:10;

%% Roles (columns)
subgraph ROLES["ROLES"]
  direction TB
  PL["🧭 NASA‑HQ\nPROGRAM LEAD (CEO)"]:::role
  MCC["🎛️ MISSION CONTROL\n(MCC / COO)"]:::role
  AP["🚀 APOLLO\nFlight Systems"]:::role
  HU["🔭 HUBBLE\nMission Story"]:::role
  AR["🌙 ARTEMIS\nMission Outcomes"]:::role
  VFY["✅ APOLLO‑VERIFY\n(Inspector)"]:::role
end

%% Processes (rows)
subgraph PROCESSES["PROCESSES"]
  direction TB
  P1["1) Intake / Triage"]:::proc
  P2["2) Routing (Mission + Call‑sign)"]:::proc
  P3["3) Packet Creation (folder + brief)"]:::proc
  P4["4) Execution (produce artifacts)"]:::proc
  P5["5) Status / Telemetry updates"]:::proc
  P6["6) SIM→FLIGHT Checklist prepared"]:::proc
  P7["7) FLIGHT GO/NO‑GO"]:::proc
  P8["8) Close Packet (PROCEED/ITERATE/HOLD/SCRUB)"]:::proc
  P9["9) Archive + Index update"]:::proc
end

%% RACI links: each process points to roles with R/A/C/I tags

%% 1 Intake / Triage
P1 -->|"A"| MCC:::raciA
P1 -->|"I"| PL:::raciI
P1 -->|"C"| AP:::raciC
P1 -->|"C"| HU:::raciC
P1 -->|"C"| AR:::raciC

%% 2 Routing
P2 -->|"A"| MCC:::raciA
P2 -->|"I"| PL:::raciI
P2 -->|"C"| AP:::raciC
P2 -->|"C"| HU:::raciC
P2 -->|"C"| AR:::raciC

%% 3 Packet Creation
P3 -->|"R/A"| MCC:::raciA
P3 -->|"C"| AP:::raciC
P3 -->|"C"| HU:::raciC
P3 -->|"C"| AR:::raciC
P3 -->|"I"| PL:::raciI

%% 4 Execution
P4 -->|"I"| MCC:::raciI
P4 -->|"R/A"| AP:::raciR
P4 -->|"R/A"| HU:::raciR
P4 -->|"R/A"| AR:::raciR
P4 -->|"I"| PL:::raciI

%% 5 Telemetry updates
P5 -->|"A"| MCC:::raciA
P5 -->|"R"| AP:::raciR
P5 -->|"R"| HU:::raciR
P5 -->|"R"| AR:::raciR
P5 -->|"I"| PL:::raciI

%% 6 SIM→FLIGHT checklist prepared
P6 -->|"A"| MCC:::raciA
P6 -->|"R"| AP:::raciR
P6 -->|"R"| HU:::raciR
P6 -->|"R"| AR:::raciR
P6 -->|"C"| VFY:::raciC
P6 -->|"C"| PL:::raciC

%% 7 FLIGHT GO/NO‑GO
P7 -->|"A"| MCC:::raciA
P7 -->|"C"| VFY:::raciC
P7 -->|"C"| AP:::raciC
P7 -->|"C"| HU:::raciC
P7 -->|"C"| AR:::raciC
P7 -->|"A (P0/P1)"| PL:::raciA

%% 8 Close Packet
P8 -->|"A"| MCC:::raciA
P8 -->|"C"| AP:::raciC
P8 -->|"C"| HU:::raciC
P8 -->|"C"| AR:::raciC
P8 -->|"C (P0/P1 or dispute)"| PL:::raciC

%% 9 Archive + Index update
P9 -->|"R/A"| MCC:::raciA
P9 -->|"I"| PL:::raciI
P9 -->|"I"| AP:::raciI
P9 -->|"I"| HU:::raciI
P9 -->|"I"| AR:::raciI

Jak to czytać

• Routing zawsze robi MCC (Mission Control).
• SIM to domyślny tryb pracy.
• FLIGHT wymaga:
  • checklisty,
  • MCC GO,
  • NASA‑HQ GO tylko dla P0/P1,
  • APOLLO‑VERIFY GO dla technicznych zmian w FLIGHT.

---

Jasne — Decision Flow w Mermaid najczęściej wywala się przez znaki Unicode (np. →, ‑), emoji w labelach albo przez to, że Mermaid różnie parsuje znaki w zależności od renderera (Obsidian/GitHub/Live Editor). U Ciebie w tym diagramie są m.in. strzałki → w tekście oraz łączniki ‑, co bardzo często robi parse error.

Poniżej masz poprawioną wersję (100% kompatybilną):

• bez znaków → (zamienione na ->)
• bez twardych łączników ‑ (zamienione na -)
• emoji zostawiłem, ale jeśli dalej będzie błąd, dam wariant „bez emoji” (na końcu).

---

✅ Decision Flow — wersja naprawiona (Mermaid, LR)

Skopiuj i wklej:

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#0b1220',
    'primaryTextColor': '#e5e7eb',
    'lineColor': '#475569',
    'fontFamily': 'Inter, ui-sans-serif, system-ui',
    'fontSize': '14px'
  },
  'flowchart': { 'curve': 'basis', 'nodeSpacing': 50, 'rankSpacing': 70 }
}}%%

flowchart LR

%% Styles
classDef lead fill:#111827,stroke:#f59e0b,stroke-width:2.5px,color:#ffffff,rx:14,ry:14,font-weight:bold;
classDef ops fill:#0b2a4a,stroke:#22c55e,stroke-width:2.5px,color:#e0f2fe,rx:14,ry:14,font-weight:bold;

classDef missionApollo fill:#0b2a4a,stroke:#38bdf8,stroke-width:2px,color:#e0f2fe,rx:14,ry:14;
classDef missionHubble fill:#2a1606,stroke:#f59e0b,stroke-width:2px,color:#ffedd5,rx:14,ry:14;
classDef missionArtemis fill:#052e1a,stroke:#22c55e,stroke-width:2px,color:#dcfce7,rx:14,ry:14;

classDef step fill:#0f172a,stroke:#334155,stroke-width:1.4px,color:#e5e7eb,rx:12,ry:12;
classDef gate fill:#2a0f14,stroke:#fb7185,stroke-width:2px,color:#ffe4e6,rx:14,ry:14,font-weight:bold;
classDef ok fill:#052e1a,stroke:#22c55e,stroke-width:2px,color:#dcfce7,rx:14,ry:14,font-weight:bold;
classDef decision fill:#0b1220,stroke:#94a3b8,stroke-width:1.4px,color:#e5e7eb,rx:12,ry:12;

%% Actors
PL["🧭 NASA-HQ\nPROGRAM LEAD"]:::lead
MCC["🎛️ MISSION CONTROL\n(MCC)"]:::ops

%% Core flow nodes
IN["Incoming request / idea / problem"]:::step
TRI["MCC Triage\n(clarify, reduce ambiguity)"]:::step
ROUTE{"Select mission + call-sign\n(APOLLO / HUBBLE / ARTEMIS)"}:::decision
PACKET["Create Mission Packet\n(folder + 00_brief.md)"]:::step
SIM["SIM execution\n(drafts, analysis, prototypes)"]:::step
FLIGHT_REQ{"FLIGHT required?\n(publish / prod change / irreversible)"}:::decision
CHK["Prepare SIM->FLIGHT checklist\n(quality + risks + telemetry)"]:::step

GO_MCC{"MCC GO?"}:::gate
GO_PL{"NASA-HQ GO?\n(required for P0/P1)"}:::gate
GO_VFY{"APOLLO-VERIFY GO?\n(required for technical FLIGHT)"}:::gate

FLIGHT["FLIGHT execution\n(final publish / production)"]:::ok
CLOSE{"Close decision\nPROCEED | ITERATE | HOLD | SCRUB"}:::decision
ARCH["Archive packet + update indexes"]:::step

%% Mission destinations
AP["🚀 APOLLO\nFlight Systems"]:::missionApollo
HU["🔭 HUBBLE\nMission Story"]:::missionHubble
AR["🌙 ARTEMIS\nMission Outcomes"]:::missionArtemis

%% Wiring
PL -->|"sets priorities"| MCC
IN --> TRI --> ROUTE

ROUTE -->|"APOLLO-*"| AP
ROUTE -->|"HUBBLE-*"| HU
ROUTE -->|"ARTEMIS-*"| AR

AP --> PACKET
HU --> PACKET
AR --> PACKET

PACKET --> SIM --> FLIGHT_REQ

FLIGHT_REQ -->|"No (SIM only)"| CLOSE
FLIGHT_REQ -->|"Yes"| CHK --> GO_MCC

GO_MCC -->|"NO"| SIM
GO_MCC -->|"YES"| GO_PL

GO_PL -->|"Not needed (P2+)"| GO_VFY
GO_PL -->|"YES (P0/P1)"| GO_VFY
GO_PL -->|"NO"| SIM

GO_VFY -->|"Not needed (non-technical)"| FLIGHT
GO_VFY -->|"YES"| FLIGHT
GO_VFY -->|"NO"| SIM

FLIGHT --> CLOSE --> ARCH

---

Jeśli dalej masz błąd: wariant „bez emoji” (ultra-safe)

Czasem renderer (np. wtyczka w jakimś narzędziu) nie lubi emoji. Wtedy użyj tej wersji:

flowchart LR
PL["NASA-HQ\nPROGRAM LEAD"] --> MCC["MISSION CONTROL\n(MCC)"]
IN["Incoming request"] --> TRI["MCC Triage"] --> ROUTE{"Select mission + call-sign"}
ROUTE -->|"APOLLO-*"| AP["APOLLO"]
ROUTE -->|"HUBBLE-*"| HU["HUBBLE"]
ROUTE -->|"ARTEMIS-*"| AR["ARTEMIS"]
AP --> PACKET["Create Mission Packet"] --> SIM["SIM execution"] --> FLIGHT_REQ{"FLIGHT required?"}
HU --> PACKET
AR --> PACKET
FLIGHT_REQ -->|"No"| CLOSE{"Close decision"} --> ARCH["Archive + index update"]
FLIGHT_REQ -->|"Yes"| CHK["Prepare SIM->FLIGHT checklist"] --> GO_MCC{"MCC GO?"}
GO_MCC -->|"NO"| SIM
GO_MCC -->|"YES"| GO_PL{"NASA-HQ GO? (P0/P1)"} --> GO_VFY{"APOLLO-VERIFY GO? (technical)"}
GO_PL -->|"NO"| SIM
GO_VFY -->|"NO"| SIM
GO_VFY -->|"YES/Not needed"| FLIGHT["FLIGHT execution"] --> CLOSE --> ARCH

---

Żeby trafić idealnie: jaki błąd dokładnie widzisz?

Wklej proszę 1 linijkę komunikatu (np. Parse error on line X:).
W Mermaid najczęściej to jest:

• linia z → / ‑
• linia z emoji
• linia z labelami w {} albo " w nietypowym miejscu

Jak podasz komunikat, dopasuję wersję 1:1 pod Twój renderer (Obsidian / GitHub / Mermaid Live).

Jasne — dodam krótkie opisy przy każdym kroku, zostawię emoji, a jednocześnie dopilnuję, żeby diagram był parsowalny (bez znaków typu → i bez “twardych” łączników). Poniżej masz wersję Decision Flow (LR) z opisami i emoji, kompatybilną z większością rendererów Mermaid.

---

✅ Decision Flow (LR) — z opisami + emoji (bez “problemowych” znaków)

Zmiany vs poprzednio:

• brak → (jest ->)
• brak ‑ (jest zwykły -)
• emoji zostają
• dodałem krótkie opisy w węzłach + na krawędziach

Skopiuj i wklej:

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#0b1220',
    'primaryTextColor': '#e5e7eb',
    'lineColor': '#475569',
    'fontFamily': 'Inter, ui-sans-serif, system-ui',
    'fontSize': '14px'
  },
  'flowchart': { 'curve': 'basis', 'nodeSpacing': 55, 'rankSpacing': 75 }
}}%%

flowchart LR

%% =========================
%% STYLES
%% =========================
classDef lead fill:#111827,stroke:#f59e0b,stroke-width:2.5px,color:#ffffff,rx:14,ry:14,font-weight:bold;
classDef ops fill:#0b2a4a,stroke:#22c55e,stroke-width:2.5px,color:#e0f2fe,rx:14,ry:14,font-weight:bold;

classDef missionApollo fill:#0b2a4a,stroke:#38bdf8,stroke-width:2px,color:#e0f2fe,rx:14,ry:14;
classDef missionHubble fill:#2a1606,stroke:#f59e0b,stroke-width:2px,color:#ffedd5,rx:14,ry:14;
classDef missionArtemis fill:#052e1a,stroke:#22c55e,stroke-width:2px,color:#dcfce7,rx:14,ry:14;

classDef step fill:#0f172a,stroke:#334155,stroke-width:1.4px,color:#e5e7eb,rx:12,ry:12;
classDef gate fill:#2a0f14,stroke:#fb7185,stroke-width:2px,color:#ffe4e6,rx:14,ry:14,font-weight:bold;
classDef ok fill:#052e1a,stroke:#22c55e,stroke-width:2px,color:#dcfce7,rx:14,ry:14,font-weight:bold;
classDef decision fill:#0b1220,stroke:#94a3b8,stroke-width:1.4px,color:#e5e7eb,rx:12,ry:12;

%% =========================
%% ACTORS
%% =========================
PL["🧭 NASA-HQ (PROGRAM LEAD)\n- priorytety, strategia, P0/P1 GO"]:::lead
MCC["🎛️ MISSION CONTROL (MCC)\n- triage, routing, WIP, gate, closure"]:::ops

%% =========================
%% FLOW NODES
%% =========================
IN["📥 Intake\nNowa prośba / problem / pomysł"]:::step
TRI["🧹 Triage (MCC)\nDoprecyzuj cel, ogranicz niejasność\n(max 1-3 pytania)"]:::step
ROUTE{"🧭 Routing\nWybierz misję + call-sign\n(APOLLO / HUBBLE / ARTEMIS)"}:::decision

PACKET["📦 Mission Packet\nUtwórz folder + 00_brief.md\n(kontekst, cel, acceptance, ryzyka)"]:::step

SIM["🟡 SIM\nWykonanie bez ryzyka\n(draft, analiza, prototyp)"]:::step

REQ_FLIGHT{"🟩 FLIGHT potrzebny?\nPublikacja / produkcja / nieodwracalne"}:::decision

CHK["🧾 SIM->FLIGHT Checklist\nJakość, ryzyka, telemetry\n+ plan weryfikacji/rollback"]:::step

GO_MCC{"🚦 MCC GO?\nCzy brief i checklist są kompletne?"}:::gate
GO_PL{"🧭 NASA-HQ GO?\nWymagane dla P0/P1"}:::gate
GO_VFY{"✅ APOLLO-VERIFY GO?\nWymagane dla technicznego FLIGHT"}:::gate

FLIGHT["🟢 FLIGHT\nFinal: publikuj / wdrażaj / uruchom\n(z pełnym audytem)"]:::ok

CLOSE{"🔒 Closure\nDecyzja: PROCEED | ITERATE | HOLD | SCRUB"}:::decision
ARCH["🗄️ Archive\nPrzenieś do 99_archive\n+ update indeksów MCC"]:::step

%% =========================
%% MISSION DESTINATIONS
%% =========================
AP["🚀 APOLLO\nFlight Systems\n(APOLLO-CORE/CODE/VERIFY)"]:::missionApollo
HU["🔭 HUBBLE\nMission Story\n(HUBBLE-CONTENT/CREATIVE)"]:::missionHubble
AR["🌙 ARTEMIS\nMission Outcomes\n(ARTEMIS-EXP/TLM/GROUND)"]:::missionArtemis

%% =========================
%% WIRES
%% =========================
PL -->|"ustanawia priorytety\n+ GO dla P0/P1"| MCC

IN --> TRI --> ROUTE

ROUTE -->|"APOLLO-* (system, infra, security, QA)"| AP
ROUTE -->|"HUBBLE-* (content, creative, dist)"| HU
ROUTE -->|"ARTEMIS-* (experiments, telemetry, ground)"| AR

AP --> PACKET
HU --> PACKET
AR --> PACKET

PACKET -->|"praca w SIM domyślnie"| SIM --> REQ_FLIGHT

REQ_FLIGHT -->|"Nie: zostajemy w SIM\nzamykamy decyzją"| CLOSE
REQ_FLIGHT -->|"Tak: przygotuj bramki"| CHK --> GO_MCC

GO_MCC -->|"NO: braki w brief/checklist\nwróć do SIM"| SIM
GO_MCC -->|"YES: bramka operacyjna przejścia"| GO_PL

GO_PL -->|"Nie dotyczy (P2+)\nprzejdź dalej"| GO_VFY
GO_PL -->|"YES: P0/P1 zatwierdzone"| GO_VFY
GO_PL -->|"NO: brak zgody\nwróć do SIM"| SIM

GO_VFY -->|"Nie dotyczy (nietecz.)"| FLIGHT
GO_VFY -->|"YES: weryfikacja OK"| FLIGHT
GO_VFY -->|"NO: brak weryfikacji\nwróć do SIM"| SIM

FLIGHT --> CLOSE --> ARCH

---

Co dokładnie dodałem (żeby “łatwiej się czytało”)

• Każdy krok ma opis “po co” (np. Triage, Packet, Checklist, Closure).
• Na strzałkach dopisałem kiedy i dlaczego przechodzisz dalej lub wracasz do SIM.
• Emoji są w labelach, ale bez znaków, które typowo psują parser (np. →).

---

Jeśli nadal wyskoczy błąd

Wtedy prawie na pewno winne jest Twoje środowisko renderujące (czasem nie lubi np. emoji w decyzjach).
Wklej proszę dokładny komunikat błędu (1 linijka) i powiem Ci, czy:

• usunąć konkretne emoji,
• zmienić cudzysłowy,
• czy np. skrócić label w jednym węźle.

Chcesz też, żebym dodał legendę do kolorów/znaczeń (SIM/FLIGHT/GO/NO-GO) jako mały blok po prawej?