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?