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)**

``` mermaid
%%{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:

``` mermaid
%%{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:

``` mermaid
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:

``` mermaid
%%{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?