Files

T

Paweł Domański 64944cf004 May 17, 2026, 11:40 PM

2026-05-18 06:40:19 +00:00

48 KiB

Raw Blame History

Jasne — poniżej masz dokładny opis Twojego systemu zarządzania (w tej wersji, którą zbudowaliśmy: PROGRAM LEAD → MISSION CONTROL → misje NASA (APOLLO / HUBBLE / ARTEMIS) → sekcje → agenci) oraz jak to praktycznie wykorzystać do nawigacji i egzekucji w OpenClaw.

1) Co to za system (w jednym zdaniu)

To jest operacyjny system zarządzania pracą, w którym:

PROGRAM LEAD ustala kierunek i priorytety,
MISSION CONTROL zamienia priorytety na zadania i orkiestruje wykonanie,
a trzy „misje” (APOLLO / HUBBLE / ARTEMIS) są stałymi strumieniami pracy (workstreams) z własnym słownikiem, sekcjami i agentami.

To nie jest tylko „ładny org chart”. To jest: ✅ routing zadań,
✅ standard nazewnictwa,
✅ wspólna nawigacja,
✅ a docelowo także logika dostępu i audytu.

2) Warstwy odpowiedzialności (governance)

2.1 PROGRAM LEAD — warstwa decyzji

Rola: “dlaczego i po co?”
Odpowiada za:

wizję i zasady gry,
finalne decyzje (trade‑offs),
priorytety (co jest ważniejsze),
definicję “co znaczy sukces”.

W praktyce:
PROGRAM LEAD nie schodzi do agentów. PROGRAM LEAD steruje przez MISSION CONTROL.

2.2 MISSION CONTROL — warstwa operacji

Rola: “co robimy teraz i jak to dowieźć?”
Odpowiada za:

przyjmowanie zleceń/priorytetów,
rozbijanie na konkretne zadania,
delegowanie do misji i sekcji,
pilnowanie wykonania i domykanie wątków.

MISSION CONTROL jest Twoim “dispatcherem”:

kontroluje backlog,
kontroluje WIP,
kontroluje jakość wejścia/wyjścia.

3) “Misje NASA” jako system nawigacji (dlaczego to działa)

Zamiast klasycznych działów typu “Engineering/Marketing/Sales”, masz trzy misje, które są:

łatwe do zapamiętania,
rozłączne semantycznie (mniej chaosu),
idealne do tagowania (OpenClaw, logi, foldery, eventy).

Każda misja ma:

cel,
zakres,
sekcje,
agentów,
prefiks (call‑sign) do identyfikacji.

4) Misje: znaczenie, routing i sekcje

🚀 [APOLLO] — FLIGHT SYSTEMS

Slogan: “Sprawność, stabilność, niezawodność”
Po co istnieje: utrzymuje i rozwija fundament techniczny, żeby reszta mogła działać bez tarcia.

Sekcje APOLLO

🧱 [APOLLO-CORE] Core Tech
fundamenty, bezpieczeństwo, platforma, krytyczne komponenty
💻 [APOLLO-CODE] Flight Code
kod produktu, implementacja, UI, integracje, automatyzacje wykonawcze
✅ [APOLLO-VERIFY] Verification
testy, jakość, niezawodność, audyt

Agenci APOLLO (collapsed w diagramie)

APOLLO-CORE / Anvil — Systems Engineer
APOLLO-CORE / Cipher — Security Engineer
APOLLO-CODE / Pixel — Frontend Engineer
APOLLO-CODE / Sentry — DevOps & Infra
APOLLO-VERIFY / Inspector — QA & Reliability

Routing przykładów:

„Zrób hardening i polityki” → APOLLO-CORE/Cipher
„Deploy pipeline / infra / runtime” → APOLLO-CODE/Sentry
„Sprawdź regresję, testy, audit” → APOLLO-VERIFY/Inspector

🔭 [HUBBLE] — MISSION STORY

Slogan: “Misja musi być widoczna i zrozumiała”
Po co istnieje: produkuje i dystrybuuje treści + utrzymuje spójność historii/komunikacji.

Sekcje HUBBLE

📝 [HUBBLE-CONTENT] Mission Content
pisanie, research contentowy, pakowanie historii misji
🎨 [HUBBLE-CREATIVE] Creative Studio
grafika, wideo, assety

Agenci HUBBLE

HUBBLE-CONTENT / Rex — Script Writer
HUBBLE-CONTENT / Sage — Research & Analysis
HUBBLE-CONTENT / Echo — Newsletter Engine
HUBBLE-CONTENT / Clip — Short‑form Video
HUBBLE-CREATIVE / Nebula — Visual Design
HUBBLE-CREATIVE / Nova — Video Production

Routing przykładów:

„Potrzebuję skryptu do filmu” → HUBBLE-CONTENT/Rex
„Zrób research, wnioski i tezy” → HUBBLE-CONTENT/Sage
„Grafiki i layout” → HUBBLE-CREATIVE/Nebula
„Montage / final cut” → HUBBLE-CREATIVE/Nova

🌙 [ARTEMIS] — MISSION OUTCOMES

Slogan: “Efekt misji: produkt, wzrost, społeczność”
Po co istnieje: dowozi wartość, mierzy ją i zamienia feedback na kolejne iteracje.

Sekcje ARTEMIS

🧪 [ARTEMIS-EXP] Experiments
nowe inicjatywy, launch, eksperymenty produktowe
📡 [ARTEMIS-TLM] Telemetry
pomiary, analityka, optymalizacja
🤝 [ARTEMIS-GROUND] Ground Crew
społeczność, wsparcie, onboarding, operacje community

Agenci ARTEMIS

ARTEMIS-EXP / Scout — Product Intelligence
ARTEMIS-EXP / Herald — Launch & Announcements
ARTEMIS-TLM / Forge — Optimization
ARTEMIS-TLM / Pulse — Telemetry & Analytics
ARTEMIS-GROUND / Beacon — Support & Onboarding
ARTEMIS-GROUND / Link — Community Ops
ARTEMIS-GROUND / Vibe — Engagement

Routing przykładów:

„Wypuść nową funkcję/ogłoszenie” → ARTEMIS-EXP/Herald
„Zbadaj rynek / potrzeby / kierunek produktu” → ARTEMIS-EXP/Scout
„Analiza KPI i anomalie” → ARTEMIS-TLM/Pulse
„Optymalizacja SEO/lejków/konwersji” → ARTEMIS-TLM/Forge
„Wsparcie i onboarding” → ARTEMIS-GROUND/Beacon

5) Dlaczego call‑signy są kluczowe w OpenClaw

Twoje prefiksy typu:

[APOLLO-CORE]
[HUBBLE-CONTENT]
[ARTEMIS-TLM]

działają jak routing key.

5.1 Co zyskujesz od razu

Szybkie filtrowanie: po tagu w logach i telemetrii
Jednoznaczny właściciel: z samej nazwy wiesz “kto”
Stabilne ścieżki: nadają się do folderów, pipeline’ów i eventów

5.2 Jak to mapować “operacyjnie”

Masz 3 poziomy adresowania:

Misja: APOLLO / HUBBLE / ARTEMIS
Sekcja: APOLLO-CORE, ARTEMIS-TLM…
Agent: Pulse, Anvil, Nebula…

W praktyce możesz mówić:

„Wrzuć to do ARTEMIS‑TLM”
albo
„Niech APOLLO‑VERIFY/Inspector to sprawdzi”.

To jest dokładnie to, co chciałeś: łatwa nawigacja w OpenClaw.

6) Typowy przepływ pracy (end‑to‑end)

Poniżej najważniejszy element: jak praca płynie przez system.

6.1 Start: decyzja i intencja

PROGRAM LEAD ustala cel/prior (np. “podnieść retencję”, “dowiezć release”).
MISSION CONTROL robi z tego pakiet operacyjny:
- definicja celu,
- definicja outputów,
- ograniczenia (czas, ryzyko),
- akceptacja (co znaczy “done”).

6.2 Routing do misji

MISSION CONTROL przypina zadanie do misji call‑signem:

[APOLLO] jeśli to stabilność/infra/security/testy
[HUBBLE] jeśli to content/creative/distribution
[ARTEMIS] jeśli to eksperymenty/growth/telemetry/community

6.3 Rozbicie na sekcje i wykonanie

Wewnątrz misji zadanie trafia do sekcji:

np. [ARTEMIS-TLM] → Pulse/Forge
[APOLLO-VERIFY] → Inspector

6.4 Telemetria i domknięcie

MISSION CONTROL zbiera status:

co zrobione,
co zablokowane,
jaka jakość,
jakie metryki.

I domyka temat:

decyzja “ship / iterate / kill”.

7) Jak tego używać jako “system zarządzania” (praktyczne zasady)

7.1 Prosta reguła przypisania

Jeśli nie wiesz gdzie coś wrzucić:

Czy to zmienia/utrzymuje system? → APOLLO
Czy to komunikuje/kreuje/wyjaśnia? → HUBBLE
Czy to dowozi wynik i mierzy wpływ? → ARTEMIS

7.2 Minimalny standard zlecenia (żeby agenci nie błądzili)

MISSION CONTROL powinien dać zawsze:

Context: dlaczego
Goal: co ma być osiągnięte
Output: jaki artefakt ma powstać (plik, PRD, skrypt, raport)
Constraints: deadline, format, ograniczenia
Acceptance: jak sprawdzamy, że done

7.3 Ograniczenie chaosu (WIP)

To działa świetnie, gdy:

MISSION CONTROL trzyma mało aktywnych tematów naraz,
tematy są w miarę “pakietowe” (nie mikrozadania).

8) Co mogę dopisać, żeby opis był „pełny” pod OpenClaw

Jeśli chcesz, dopracuję to jeszcze o dwie warstwy, które zwykle robią różnicę:

8.1 „Command grammar” dla OpenClaw

Czyli: jak wygląda nazwa komendy i ścieżki:

run MCC ARTEMIS-TLM Pulse --task "...",
tag [APOLLO-VERIFY],
emit telemetry ARTEMIS-TLM.

8.2 Mapowanie na storage (Twoje `.org` / Johnny Decimal)

Możemy przypisać każdej misji stałe foldery typu:

missions/APOLLO/...
missions/HUBBLE/...
missions/ARTEMIS/...

…żeby nawigacja była spójna nie tylko w UI, ale też w plikach.

Świetnie — poniżej masz konkretny, operacyjny opis Twojego systemu w trzech częściach, dokładnie tak jak prosiłeś:

Struktura folderów (jak to trzymać na dysku / w repo / w .org)
Routing zadań i komend (jak nawigować i delegować w OpenClaw)
Pełny przykład użycia systemu end‑to‑end (od decyzji do efektu)

To nie jest wizja ani teoria — to jest instrukcja użytkowania systemu zarządzania.

1️⃣ Struktura folderów (Mission‑first, nie „działy”)

1.1 Zasada nadrzędna

Foldery odzwierciedlają misje, nie ludzi ani role.

Nie: engineering/marketing/product
Tylko: APOLLO / HUBBLE / ARTEMIS

Każda misja:

ma własną przestrzeń roboczą,
ma własne sekcje,
jest jednostką nawigacyjną w OpenClaw.

1.2 Proponowana struktura główna

/missions
├── APOLLO/                # FLIGHT SYSTEMS
│   ├── CORE_TECH/
│   │   ├── architecture/
│   │   ├── security/
│   │   ├── platform/
│   │   └── notes.md
│   ├── FLIGHT_CODE/
│   │   ├── features/
│   │   ├── ui/
│   │   ├── pipelines/
│   │   └── notes.md
│   ├── VERIFICATION/
│   │   ├── tests/
│   │   ├── audits/
│   │   ├── reports/
│   │   └── notes.md
│   └── README.md
│
├── HUBBLE/                # MISSION STORY
│   ├── CONTENT/
│   │   ├── scripts/
│   │   ├── research/
│   │   ├── newsletters/
│   │   └── notes.md
│   ├── CREATIVE/
│   │   ├── design/
│   │   ├── video/
│   │   ├── thumbnails/
│   │   └── notes.md
│   └── README.md
│
├── ARTEMIS/               # MISSION OUTCOMES
│   ├── EXPERIMENTS/
│   │   ├── ideas/
│   │   ├── launches/
│   │   ├── results/
│   │   └── notes.md
│   ├── TELEMETRY/
│   │   ├── dashboards/
│   │   ├── metrics/
│   │   ├── analysis/
│   │   └── notes.md
│   ├── GROUND_CREW/
│   │   ├── onboarding/
│   │   ├── support/
│   │   ├── community/
│   │   └── notes.md
│   └── README.md
│
└── _MCC/                  # MISSION CONTROL
    ├── backlog.md
    ├── active-missions.md
    ├── decisions.md
    └── routing-rules.md

Dlaczego to działa

✅ wiesz gdzie coś jest po samej nazwie,
✅ łatwe do mapowania na call‑signy,
✅ folder = misja = odpowiedzialność,
✅ zero chaosu „czy to engineering czy product?”.

2️⃣ Routing w OpenClaw (jak delegować i sterować)

2.1 Zasada routingu (najważniejsza)

MISSION CONTROL zawsze routuje przez MISJĘ, nie przez agenta.

Najpierw gdzie (APOLLO / HUBBLE / ARTEMIS),
potem co (sekcja),
na końcu kto (agent).

2.2 Standardowy routing taska

Format mentalny (i do logów):

[MCC] → [MISJA-SEKCJA] → Agent

Przykłady:

[MCC] → [APOLLO-CORE] → Anvil
[MCC] → [HUBBLE-CONTENT] → Rex
[MCC] → [ARTEMIS-TLM] → Pulse

To jest Twój GPS w systemie.

2.3 Jak to wygląda w praktyce (OpenClaw‑style)

Komenda / zadanie (przykład)

[MCC][ARTEMIS-TLM]
Goal: Zrozumieć spadek konwersji w ostatnich 14 dniach
Output: Raport + rekomendacje
Owner: Pulse

Albo krócej:

Route to ARTEMIS-TLM / Pulse
Task: Analyze conversion drop (14d)

2.4 Reguły decyzyjne (bardzo ważne)

Jeśli masz wątpliwość, gdzie coś wrzucić:

Pytanie	Idzie do
Czy to stabilność / infra / kod?	APOLLO
Czy to komunikacja / treść / forma?	HUBBLE
Czy to efekt, metryki, wzrost, feedback?	ARTEMIS

Jeśli nie pasuje nigdzie → MISSION CONTROL decyduje.

3️⃣ Przykład użycia systemu (end‑to‑end)

Poniżej pełny, realistyczny scenariusz, krok po kroku.

3.1 Sytuacja startowa (PROGRAM LEAD)

PROGRAM LEAD widzi problem:

„Spada retencja użytkowników po 7 dniach.”

Nie analizuje szczegółów.
Formułuje intencję strategiczną:

Objective: Improve 7-day retention
Constraint: No major infra changes this week

3.2 MISSION CONTROL przejmuje sterowanie

MISSION CONTROL robi 3 rzeczy:

Rozbija problem na strumienie:
- dlaczego spada? → ARTEMIS (Telemetry)
- jak to komunikujemy? → HUBBLE (Story)
- czy system coś psuje? → APOLLO (Verify)
Nadaje routing:

[MCC][ARTEMIS-TLM] Analyze retention drop
[MCC][HUBBLE-CONTENT] Explain value better to users
[MCC][APOLLO-VERIFY] Check for regressions

Definiuje “done”.

3.3 Wykonanie w misjach

ARTEMIS — Telemetry

Pulse analizuje dane,
Forge sugeruje optymalizacje,
output: raport + hipotezy.

Folder:

/missions/ARTEMIS/TELEMETRY/analysis/retention-7d.md

HUBBLE — Mission Story

Sage robi research,
Rex pisze nową narrację,
Clip/Nova przygotowują materiały.

Folder:

/missions/HUBBLE/CONTENT/scripts/retention-story.md

APOLLO — Verification

Inspector sprawdza testy,
Cipher audytuje security,
brak regresji → zielone światło.

Folder:

/missions/APOLLO/VERIFICATION/reports/retention-check.md

3.4 Domknięcie (MISSION CONTROL)

MISSION CONTROL:

zbiera wyniki,
rekomenduje decyzję,
wraca do PROGRAM LEAD z syntezą.

Decision:
- No system regression
- Messaging unclear → improve onboarding
- Metric to watch: activation rate D1-D3

PROGRAM LEAD zatwierdza → kolejna iteracja.

4️⃣ Dlaczego to jest system zarządzania, a nie „ładny diagram”

Bo:

✅ masz jednoznaczne miejsca (foldery),
✅ masz jednoznaczny routing (call‑signy),
✅ masz jasny przepływ decyzji,
✅ możesz to skalować (więcej agentów, te same misje),
✅ OpenClaw staje się Mission Control, nie chatem.

Świetnie — robię wszystko, co proponowałem: dostajesz kompletny, spójny „Operating Manual” Twojego systemu zarządzania + gotową strukturę folderów + reguły routingu + szablony zadań + tryby SIM/FLIGHT + archiwizacja misji + checklista jakości + przykłady end‑to‑end.
Tak, żebyś mógł to wkleić do .org / wiki i od jutra jechać na tym operacyjnie.

0) TL;DR — jak działa system (30 sekund)

PROGRAM LEAD: decyduje co i dlaczego (priorytety, trade‑offy, definicja sukcesu).
MISSION CONTROL: zamienia to na pakiety wykonawcze (routing, WIP, kontrola jakości, domykanie).
Praca zawsze trafia do jednej z misji:
- 🚀 [APOLLO] FLIGHT SYSTEMS → stabilność, infra, bezpieczeństwo, kod, weryfikacja
- 🔭 [HUBBLE] MISSION STORY → content, kreatywa, dystrybucja
- 🌙 [ARTEMIS] MISSION OUTCOMES → eksperymenty produktowe, telemetria, community/support
Każdy element ma call‑sign (np. APOLLO-CORE, ARTEMIS-TLM), który jest Twoim routing key w OpenClaw, folderach i logach.

1) Struktura folderów (gotowiec do wdrożenia)

1.1 Zasady folderów (żeby nie robić chaosu)

Misja jest najwyższą jednostką organizacji: APOLLO/HUBBLE/ARTEMIS
Każda misja ma sekcje odpowiadające call‑signom
Każde zadanie ma swój „pakiet” (folder) z:
- briefem,
- artefaktami,
- decyzją końcową,
- logiem zmian.

1.2 Proponowana struktura główna (repo / `.org`)

/missions
├── _MCC/                           # MISSION CONTROL (operacje)
│   ├── 00_operating-manual.md
│   ├── 10_backlog.md
│   ├── 20_active-missions.md
│   ├── 30_decisions.md
│   ├── 40_routing-rules.md
│   ├── 50_templates/
│   │   ├── task-brief.md
│   │   ├── sim-flight-checklist.md
│   │   ├── post-mission-report.md
│   │   └── decision-record.md
│   └── 90_archive-index.md
│
├── APOLLO/                         # 🚀 FLIGHT SYSTEMS
│   ├── CORE_TECH/                  # [APOLLO-CORE]
│   │   ├── 00_readme.md
│   │   ├── architecture/
│   │   ├── security/
│   │   ├── platform/
│   │   ├── missions/               # zadania/pakiety
│   │   └── runbooks/
│   ├── FLIGHT_CODE/                # [APOLLO-CODE]
│   │   ├── 00_readme.md
│   │   ├── features/
│   │   ├── ui/
│   │   ├── pipelines/
│   │   ├── missions/
│   │   └── runbooks/
│   ├── VERIFICATION/               # [APOLLO-VERIFY]
│   │   ├── 00_readme.md
│   │   ├── tests/
│   │   ├── audits/
│   │   ├── reports/
│   │   └── missions/
│   └── 99_archive/
│
├── HUBBLE/                         # 🔭 MISSION STORY
│   ├── CONTENT/                    # [HUBBLE-CONTENT]
│   │   ├── 00_readme.md
│   │   ├── scripts/
│   │   ├── research/
│   │   ├── newsletters/
│   │   ├── distribution/
│   │   └── missions/
│   ├── CREATIVE/                   # [HUBBLE-CREATIVE]
│   │   ├── 00_readme.md
│   │   ├── design/
│   │   ├── video/
│   │   ├── thumbnails/
│   │   └── missions/
│   └── 99_archive/
│
└── ARTEMIS/                        # 🌙 MISSION OUTCOMES
    ├── EXPERIMENTS/                # [ARTEMIS-EXP]
    │   ├── 00_readme.md
    │   ├── ideas/
    │   ├── launches/
    │   ├── results/
    │   └── missions/
    ├── TELEMETRY/                  # [ARTEMIS-TLM]
    │   ├── 00_readme.md
    │   ├── dashboards/
    │   ├── metrics/
    │   ├── analysis/
    │   └── missions/
    ├── GROUND_CREW/                # [ARTEMIS-GROUND]
    │   ├── 00_readme.md
    │   ├── onboarding/
    │   ├── support/
    │   ├── community/
    │   └── missions/
    └── 99_archive/

1.3 Standard nazwy „pakietu zadania” (folderu misji)

Ustalmy jednolity format:
YYYY-MM-DD__CALLSIGN__krótki-slug

Przykłady:

/missions/ARTEMIS/TELEMETRY/missions/
  2026-02-23__ARTEMIS-TLM__retention-drop-7d/

/missions/HUBBLE/CONTENT/missions/
  2026-02-23__HUBBLE-CONTENT__onboarding-story-refresh/

/missions/APOLLO/VERIFICATION/missions/
  2026-02-23__APOLLO-VERIFY__regression-check-release-1-4/

Wewnątrz każdego pakietu:

2026-02-23__ARTEMIS-TLM__retention-drop-7d/
├── 00_brief.md
├── 10_worklog.md
├── 20_artifacts/
├── 30_results.md
├── 40_decision.md
└── 90_links.md

2) Routing: reguły kierowania pracy (OpenClaw-friendly)

2.1 Routing Key (Twoja „nawigacja”)

Każde zadanie ma dokładnie jeden routing key w formacie:

APOLLO-CORE, APOLLO-CODE, APOLLO-VERIFY
HUBBLE-CONTENT, HUBBLE-CREATIVE
ARTEMIS-EXP, ARTEMIS-TLM, ARTEMIS-GROUND

To jest Twój:

tag w backlogu,
prefiks w folderze,
klucz w telemetrii,
ścieżka w logach.

2.2 Reguła „pierwszego strzału” (gdy nie wiesz gdzie wrzucić)

Czy dotyka stabilności, bezpieczeństwa, infra, kodu lub jakości? → APOLLO
Czy dotyka treści, narracji, kreatywy, dystrybucji? → HUBBLE
Czy dotyka wyniku, wzrostu, telemetrii, community/support? → ARTEMIS
Nadal nie wiesz? → wrzuć do _MCC jako „triage”, MISSION CONTROL podejmie decyzję.

2.3 Reguły eskalacji (żeby nie zabić czasu)

Jeśli zadanie wymaga dwóch misji:
➜ MISSION CONTROL robi pakiet nadrzędny + sub‑pakiety per misja.
(czyli nie robimy jednego taska dla dwóch misji)
Jeśli coś blokuje pracę > 24h:
➜ zgłoszenie blokera do MISSION CONTROL (w worklogu + status).

3) Szablony (copy‑paste): backlog / brief / status / decyzja

Poniżej masz gotowe szablony do _MCC/50_templates/.

3.1 Task Brief (00_brief.md)

# [CALLSIGN] Task Brief — <title>

**Routing:** [CALLSIGN]  
**Owner (Agent):** <AgentName>  
**Mode:** SIM | FLIGHT  
**Priority:** P0 | P1 | P2  
**Start:** YYYY-MM-DD  
**Due:** YYYY-MM-DD (optional)

## Context
Dlaczego to robimy? Jaki problem/okazja?

## Goal (1–2 zdania)
Co ma być osiągnięte?

## Output / Deliverables
- [ ] Artefakt 1 (np. raport / plik / PRD / skrypt / wideo)
- [ ] Artefakt 2

## Constraints
- deadline, format, ograniczenia techniczne, polityki

## Acceptance Criteria (Definition of Done)
- Warunek A
- Warunek B
- Metryka/obserwacja C (jeśli dotyczy)

## Risks / Unknowns
- ryzyko 1 + plan mitigacji

3.2 Worklog (10_worklog.md)

# Worklog — <title>

## Timeline
- YYYY-MM-DD HH:MM — start, pierwsze kroki
- YYYY-MM-DD HH:MM — status update
- YYYY-MM-DD HH:MM — blocker + co potrzebne

## Notes
- obserwacje
- decyzje w trakcie
- linki do artefaktów

3.3 Results (30_results.md)

# Results — <title>

## Summary
1–3 zdania: co zrobiono, jaki efekt.

## Artifacts
- linki/ścieżki do plików

## Measurements / Evidence
- metryki, screeny, logi, testy

## What changed?
- lista zmian (konkret)

## Next steps
- co dalej (jeśli trzeba)

3.4 Decision Record (40_decision.md)

# Decision — <title>

**Decision:** PROCEED | HOLD | SCRUB | ITERATE  
**Owner:** PROGRAM LEAD / MISSION CONTROL  
**Date:** YYYY-MM-DD

## Rationale
Dlaczego taka decyzja?

## Trade-offs
Co świadomie poświęcamy?

## Follow-up
- [ ] co trzeba zrobić po decyzji

4) Tryby SIM / FLIGHT (żeby system był bezpieczny i powtarzalny)

Wprowadzasz prostą, genialną zasadę:

🟡 SIM = eksperyment, drafty, próby, praca „bez ryzyka”
🟢 FLIGHT = produkcyjna zmiana / publikacja / final

4.1 Co wolno w SIM

szkice, drafty, testowe raporty
eksperymenty w ARTEMIS‑EXP
wstępne koncepcje w HUBBLE
prototypy / branch’e w APOLLO‑CODE

4.2 Co wolno w FLIGHT

merge do main / deploy
publikacja contentu “final”
decyzje wpływające na system
uruchomienie kampanii/launch

4.3 Checklista SIM→FLIGHT (sim-flight-checklist.md)

# SIM → FLIGHT Checklist

## Quality Gate
- [ ] Acceptance criteria spełnione
- [ ] Ryzyka opisane + mitigacja
- [ ] Artefakty gotowe i podlinkowane

## Verification Gate (jeśli dotyczy)
- [ ] APOLLO-VERIFY: testy/audyt wykonane
- [ ] Rollback/undo plan istnieje

## Telemetry Gate (jeśli dotyczy)
- [ ] ARTEMIS-TLM: metryki do obserwacji zdefiniowane
- [ ] Kiedy i jak mierzymy efekt?

## Approval
- [ ] MISSION CONTROL: GO
- [ ] PROGRAM LEAD: GO (dla P0/P1)

5) Archiwizacja misji (żeby nie utonąć w historii)

5.1 Kiedy archiwizować?

Archiwizujesz pakiet, gdy:

decyzja to PROCEED (zrobione i wysłane),
decyzja to SCRUB (zabite),
decyzja to HOLD (zamrożone na > 2 tygodnie).

5.2 Jak archiwizować (procedura)

Uzupełnij 30_results.md i 40_decision.md
Przenieś folder pakietu do 99_archive/ w danej misji
Dodaj wpis do _MCC/90_archive-index.md

Wpis do archive index (przykład)

- 2026-02-23 — [ARTEMIS-TLM] retention-drop-7d — Decision: ITERATE — Link: missions/ARTEMIS/99_archive/2026-02-23__ARTEMIS-TLM__retention-drop-7d

6) Przykład użycia systemu (pełny scenariusz)

Problem

PROGRAM LEAD: „Spada retencja 7‑dniowa”.

Krok 1 — MISSION CONTROL robi triage i routing

MISSION CONTROL tworzy 3 pakiety:

[ARTEMIS-TLM] analiza przyczyny i metryk
[HUBBLE-CONTENT] poprawa onboardingowej historii
[APOLLO-VERIFY] sprawdzenie regresji / jakości

Foldery:

/missions/ARTEMIS/TELEMETRY/missions/2026-02-23__ARTEMIS-TLM__retention-drop-7d/
/missions/HUBBLE/CONTENT/missions/2026-02-23__HUBBLE-CONTENT__onboarding-story-refresh/
/missions/APOLLO/VERIFICATION/missions/2026-02-23__APOLLO-VERIFY__release-regression-check/

Krok 2 — Wykonanie (SIM)

ARTEMIS‑TLM/Pulse: raport + hipotezy
HUBBLE‑CONTENT/Sage + Rex: research + nowy onboarding copy/story
APOLLO‑VERIFY/Inspector: check regresji

Wyniki lądują w 20_artifacts/, streszczenie w 30_results.md.

Krok 3 — SIM→FLIGHT

MISSION CONTROL odpala checklistę:

acceptance ✅
verify ✅
telemetry gate ✅

Krok 4 — FLIGHT

publikacja nowego onboarding story (HUBBLE)
uruchomienie experimentu (ARTEMIS‑EXP lub w ramach product rollout)
monitor telemetry (ARTEMIS‑TLM)

Krok 5 — Decision

Po czasie obserwacji:

PROGRAM LEAD + MISSION CONTROL: PROCEED / ITERATE / SCRUB
archiwizacja pakietów

7) Minimalny “Operating Manual” do `_MCC/00_operating-manual.md`

Wklej i używaj:

# Operating Manual — Mission Management System

## Roles
- PROGRAM LEAD: vision, priorities, final decisions
- MISSION CONTROL: triage, routing, execution, WIP, closure

## Workstreams (Missions)
- APOLLO (Flight Systems): Core Tech, Flight Code, Verification
- HUBBLE (Mission Story): Mission Content, Creative Studio
- ARTEMIS (Mission Outcomes): Experiments, Telemetry, Ground Crew

## Routing
Always route by CALLSIGN:
APOLLO-CORE | APOLLO-CODE | APOLLO-VERIFY
HUBBLE-CONTENT | HUBBLE-CREATIVE
ARTEMIS-EXP | ARTEMIS-TLM | ARTEMIS-GROUND

## Modes
- SIM: drafts, experiments, prototypes
- FLIGHT: production changes, final content, launches

## Standard Packet
Each task is a mission packet folder with:
00_brief.md, 10_worklog.md, 30_results.md, 40_decision.md

## Closure
Every packet ends with a Decision:
PROCEED | HOLD | SCRUB | ITERATE
Archive after closure.

8) Jak to spiąć z OpenClaw (praktycznie, bez zgadywania)

Ponieważ OpenClaw ma Ci służyć do nawigacji, trzymaj się prostego standardu:

Komenda/entry zawsze zaczyna się od:

[MCC] + [CALLSIGN]

Przykłady tekstowe (do UI, do logów, do komend):

[MCC][APOLLO-CODE] Implement feature flag for onboarding flow (Owner: Pixel)
[MCC][HUBBLE-CONTENT] Draft onboarding story v2 (Owner: Rex)
[MCC][ARTEMIS-TLM] Define telemetry dashboard for retention (Owner: Pulse)

Pewnie — poniżej masz gotowy “prompt systemowy” (system prompt) + pakiet kontekstu i zasad operacyjnych, który możesz wkleić do innego LLM-a (Claude / GPT / Llama / lokalny) jako System albo Developer message.

Daję Ci:

SYSTEM PROMPT (master) – to jest rdzeń zachowania modelu
CONTEXT PACK – stałe informacje o Twoim systemie (misje, routing, foldery)
TASK TEMPLATES – wzorce odpowiedzi i dokumentów (Brief/Worklog/Results/Decision)
OPERATING RULES – SIM/FLIGHT, WIP, triage, archiwizacja
EXAMPLE INVOCATION – jak wydawać polecenia, żeby działało przewidywalnie

Możesz to wkleić 1:1. W miejscach oznaczonych {{...}} podstawisz swoje konkretne ścieżki/ustawienia.

1) SYSTEM PROMPT (MASTER)

Wklej jako „System” w innym LLM.

You are "Mission Control Copilot" for a mission-based operations system. Your job is to route work, produce mission packets, enforce SIM/FLIGHT safety gates, and maintain a clean knowledge base. You must be concise, operational, and structured.

CORE PRINCIPLES
1) Always think in Missions and Call-Signs. Every request must be routed to exactly one CALLSIGN (unless it is triage to MCC).
2) Maintain the governance chain: PROGRAM LEAD defines priorities and success; MISSION CONTROL translates into executable packets and closes them.
3) Prefer clarity over creativity. Avoid fluff. Produce actionable outputs.
4) Never mix missions inside one packet. If work spans missions, create a parent MCC packet and child mission packets per mission.
5) Every mission packet must end with a decision: PROCEED | ITERATE | HOLD | SCRUB.
6) Enforce SIM/FLIGHT: SIM = drafts/experiments; FLIGHT = production/final changes. Never move to FLIGHT without checklist gates.

WHAT YOU DO
- Triage incoming requests and assign ROUTING: [MISSION]-[SECTION] (CALLSIGN).
- Create and maintain "Mission Packets" with standard files: 00_brief, 10_worklog, 30_results, 40_decision, 90_links.
- Produce the exact artifacts requested (docs, checklists, plans, reports, scripts outlines) and place them into the correct mission folder path.
- Provide status summaries in a consistent telemetry format.
- Ask clarifying questions only when absolutely required to choose a routing or define acceptance criteria.

OUTPUT FORMAT (MANDATORY)
When responding to a new request, you MUST output:
A) Routing: [CALLSIGN] and suggested Agent (optional)
B) Mode: SIM or FLIGHT (default SIM unless user explicitly requests production/final)
C) Mission Packet Path (folder path)
D) Task Brief (00_brief.md) in markdown
E) Next Actions (3–7 bullet points)
F) Telemetry fields (Status, ETA, Risks, Blockers)

ROUTING RULES (MANDATORY)
- APOLLO = stability, infrastructure, security, code changes, verification.
- HUBBLE = content, creative, distribution, messaging.
- ARTEMIS = experiments, telemetry/metrics, growth, community/support.
If uncertain, route to [MCC-TRIAGE] and ask 1–3 targeted questions.

MISSION STRUCTURE (FIXED)
PROGRAM LEAD -> MISSION CONTROL -> Missions: APOLLO (Flight Systems), HUBBLE (Mission Story), ARTEMIS (Mission Outcomes)
Each mission has sections with call-signs and agents listed in the Context Pack.

SAFETY / QUALITY
- Never claim you executed actions unless the user confirms external execution.
- If you do not have access to files/tools, write clear instructions and produce the files’ contents for copy/paste.
- Keep a clear audit trail: decision records and links.

LANGUAGE
Default language: Polish. Use English only for call-signs and file names.

2) CONTEXT PACK (Wklej jako „System” albo „Developer” zaraz po master prompt)

To jest Twoja “konfiguracja świata” — misje, sekcje, agenci, foldery, nazewnictwo.

CONTEXT PACK — Mission Management System (v1)

GOVERNANCE
- PROGRAM LEAD: Vision · Strategy · Final Decisions
- MISSION CONTROL (MCC): Research · Delegation · Execution · Orchestration

MISSIONS (NAVIGATION KEYS)
1) 🚀 APOLLO — FLIGHT SYSTEMS (Engineering · Infrastructure · Reliability)
   Sections / Call-signs:
   - [APOLLO-CORE] Core Tech
   - [APOLLO-CODE] Flight Code
   - [APOLLO-VERIFY] Verification
   Agents:
   - APOLLO-CORE / Anvil — Systems Engineer
   - APOLLO-CORE / Cipher — Security Engineer
   - APOLLO-CODE / Pixel — Frontend Engineer
   - APOLLO-CODE / Sentry — DevOps & Infra
   - APOLLO-VERIFY / Inspector — QA & Reliability

2) 🔭 HUBBLE — MISSION STORY (Content · Creative · Distribution)
   Sections / Call-signs:
   - [HUBBLE-CONTENT] Mission Content
   - [HUBBLE-CREATIVE] Creative Studio
   Agents:
   - HUBBLE-CONTENT / Rex — Script Writer
   - HUBBLE-CONTENT / Sage — Research & Analysis
   - HUBBLE-CONTENT / Echo — Newsletter Engine
   - HUBBLE-CONTENT / Clip — Short-form Video
   - HUBBLE-CREATIVE / Nebula — Visual Design
   - HUBBLE-CREATIVE / Nova — Video Production

3) 🌙 ARTEMIS — MISSION OUTCOMES (Product · Growth · Community)
   Sections / Call-signs:
   - [ARTEMIS-EXP] Experiments
   - [ARTEMIS-TLM] Telemetry
   - [ARTEMIS-GROUND] Ground Crew
   Agents:
   - ARTEMIS-EXP / Scout — Product Intelligence
   - ARTEMIS-EXP / Herald — Launch & Announcements
   - ARTEMIS-TLM / Forge — Optimization
   - ARTEMIS-TLM / Pulse — Telemetry & Analytics
   - ARTEMIS-GROUND / Beacon — Support & Onboarding
   - ARTEMIS-GROUND / Link — Community Ops
   - ARTEMIS-GROUND / Vibe — Engagement

FOLDER SYSTEM (ROOT)
Root path: {{ROOT_PATH}}   (example: /missions)

Fixed structure:
{{ROOT_PATH}}/
  _MCC/
    00_operating-manual.md
    10_backlog.md
    20_active-missions.md
    30_decisions.md
    40_routing-rules.md
    50_templates/
    90_archive-index.md
  APOLLO/
    CORE_TECH/missions/
    FLIGHT_CODE/missions/
    VERIFICATION/missions/
    99_archive/
  HUBBLE/
    CONTENT/missions/
    CREATIVE/missions/
    99_archive/
  ARTEMIS/
    EXPERIMENTS/missions/
    TELEMETRY/missions/
    GROUND_CREW/missions/
    99_archive/

MISSION PACKET NAMING
Folder name format:
YYYY-MM-DD__CALLSIGN__slug

Packet contents (minimum):
00_brief.md
10_worklog.md
30_results.md
40_decision.md
90_links.md

MODES
- SIM (default): drafts, experiments, prototypes, non-production changes.
- FLIGHT: final publish, production changes, deployments, irreversible actions.

CLOSURE STATES
PROCEED | ITERATE | HOLD | SCRUB

WIP RULE
MISSION CONTROL limits active packets to {{WIP_LIMIT}} (recommended 3–5).

3) OPERATING RULES (SIM/FLIGHT, triage, archiwizacja)

To jest “jak pracujemy na co dzień”.

OPERATING RULES — MCC

1) Intake & Triage
- For every new request: choose exactly one CALLSIGN.
- If unsure: route to [MCC-TRIAGE] and ask max 3 questions needed to decide routing and acceptance.

2) SIM/FLIGHT gate
- Default mode is SIM.
- To switch to FLIGHT, run the SIM→FLIGHT checklist and record it in 00_brief or 40_decision.

3) Multi-mission work
- If a request spans missions: create a parent MCC packet:
  [MCC] packet links to 2–3 child packets (one per mission).
- Never put APOLLO + HUBBLE artifacts into the same mission packet folder.

4) Telemetry format (every update)
Status: NOT_STARTED | IN_PROGRESS | BLOCKED | READY_FOR_FLIGHT | DONE
ETA: date/time or “unknown”
Risks: up to 3 bullets
Blockers: up to 3 bullets
Next: up to 5 bullets

5) Archival procedure
- After decision (PROCEED/HOLD/SCRUB/ITERATE) fill 30_results and 40_decision.
- Move packet folder to mission 99_archive if done/hold/scrub.
- Add entry to _MCC/90_archive-index.md.

6) Documentation hygiene
- Keep briefs short but precise.
- Ensure every artifact is linked in 90_links.md.
- Use call-sign tags in headings: [ARTEMIS-TLM], [HUBBLE-CONTENT], etc.

4) TEMPLATES (wklej jako pliki do `_MCC/50_templates/`)

4.1 `task-brief.md`

# [CALLSIGN] Task Brief — <tytuł>

**Routing:** [CALLSIGN]  
**Agent:** <AgentName>  
**Mode:** SIM | FLIGHT  
**Priority:** P0 | P1 | P2  
**Start:** YYYY-MM-DD  
**Due:** YYYY-MM-DD (optional)

## Context
Dlaczego to robimy? Jaki problem/okazja?

## Goal
Co ma być osiągnięte? (1–2 zdania)

## Output / Deliverables
- [ ] Artefakt 1 (format + miejsce)
- [ ] Artefakt 2

## Constraints
- Terminy, formaty, ograniczenia, polityki, “must not”.

## Acceptance Criteria (Definition of Done)
- [ ] Kryterium A
- [ ] Kryterium B
- [ ] Metryka/obserwacja C (jeśli dotyczy)

## Risks / Unknowns
- Ryzyko 1 + mitigacja
- Ryzyko 2 + mitigacja

4.2 `sim-flight-checklist.md`

# SIM → FLIGHT Checklist

## Quality Gate
- [ ] Acceptance criteria spełnione
- [ ] Artefakty gotowe (linki dodane do 90_links.md)
- [ ] Ryzyka opisane + plan mitigacji

## APOLLO-VERIFY Gate (jeśli dotyczy)
- [ ] Testy/regresja
- [ ] Audit/QA
- [ ] Rollback plan (jeśli produkcja)

## ARTEMIS-TLM Gate (jeśli dotyczy)
- [ ] Metryki do obserwacji zdefiniowane
- [ ] Okno obserwacji + progi alarmów

## Approval
- [ ] MISSION CONTROL: GO
- [ ] PROGRAM LEAD: GO (dla P0/P1)

4.3 `post-mission-report.md`

# Post-Mission Report — <tytuł>

**Packet:** YYYY-MM-DD__CALLSIGN__slug  
**Decision:** PROCEED | ITERATE | HOLD | SCRUB  
**Owner:** MISSION CONTROL / PROGRAM LEAD  
**Date:** YYYY-MM-DD

## Summary
1–3 zdania: co zrobiono i po co.

## Artifacts
- linki/ścieżki

## Measurements / Evidence
- metryki, telemetry, testy, feedback

## Learnings
- co zadziałało
- co nie zadziałało

## Next Steps
- 1–5 kroków

4.4 `decision-record.md`

# Decision Record — <tytuł>

**Decision:** PROCEED | ITERATE | HOLD | SCRUB  
**Date:** YYYY-MM-DD  
**Owner:** PROGRAM LEAD / MISSION CONTROL

## Rationale
Dlaczego taka decyzja?

## Trade-offs
Co świadomie poświęcamy?

## Follow-up
- [ ] zadanie 1
- [ ] zadanie 2

5) EXAMPLE INVOCATION (jak wydawać polecenia innemu LLM)

Poniżej masz „prompt użytkownika” (User prompt), który zawsze zadziała przewidywalnie:

5.1 Prosty request (jedna misja)

[MCC] Nowe zadanie:
Problem: spadła konwersja na onboarding w ostatnich 14 dniach.
Poproszę routing, packet folder, brief i plan działań.

Oczekiwane zachowanie modelu:

wybierze [ARTEMIS-TLM],
utworzy packet path,
wygeneruje 00_brief.md,
poda Next Actions + Telemetry.

5.2 Request wielomisjowy (parent + children)

[MCC] Duże zlecenie:
Chcę poprawić onboarding: (1) telemetria i analiza, (2) nowa historia/onboarding copy, (3) weryfikacja czy nie ma regresji.
Zrób parent packet MCC + 3 child packety w odpowiednich misjach.

Model ma:

zrobić parent w _MCC,
child w ARTEMIS-TLM, HUBBLE-CONTENT, APOLLO-VERIFY,
podlinkować je w 90_links.md.

5.3 Przejście SIM → FLIGHT

[MCC] Przejdźmy z SIM do FLIGHT dla packetu 2026-02-23__HUBBLE-CONTENT__onboarding-story-refresh.
Wygeneruj checklistę SIM→FLIGHT i decyzję GO/NO-GO.

Model ma:

wypełnić checklist,
zaproponować decyzję,
zasugerować telemetrię po wdrożeniu.

6) Minimalne “wszystko co potrzebne do uruchomienia” na innym LLM

Żeby odpalić to na dowolnym LLM, potrzebujesz tylko:

MASTER SYSTEM PROMPT (sekcja 1)
CONTEXT PACK (sekcja 2) z {{ROOT_PATH}} i {{WIP_LIMIT}}
(Opcjonalnie) OPERATING RULES + TEMPLATES (sekcje 3–4) jako dodatkowe system/developer message lub stałe dokumenty w repo.

To wszystko.

Jasne — zmapujmy to konkretnie i operacyjnie na OpenClaw, ale tak, żeby nie zgadywać Twojej implementacji. Zrobię to w formie “OpenClaw Integration Spec”: jak OpenClaw ma rozumieć misje, routing, foldery, tryby SIM/FLIGHT, telemetrię i pakiety zadań.

Założenie (minimalne): OpenClaw to Twój gateway/serwer narzędzi (tool manager + orkiestracja), który potrafi:

wykonywać “narzędzia” (np. operacje na plikach),

przyjmować komendy/żądania z UI/LLM,

zwracać status/telemetrię.

Jeśli coś u Ciebie nazywa się inaczej, mapowanie dalej i tak zostaje — zmienimy tylko nazwy endpointów/komend.

1) Co mapujemy: Twoje “byty” → byty OpenClaw

1.1 Byty domenowe (z Twojego systemu)

PROGRAM LEAD (governance)
MISSION CONTROL (triage, routing, WIP, closure)
MISSIONS: APOLLO / HUBBLE / ARTEMIS
SECTIONS / CALLSIGNS: APOLLO-CORE, HUBBLE-CONTENT, ARTEMIS-TLM, …
AGENTS: Anvil, Cipher, Pulse, Rex, …
MODE: SIM / FLIGHT
PACKET: folder zadania + standard plików (00_brief, 10_worklog, …)

1.2 Najprostsze odwzorowanie w OpenClaw (proponowane)

OpenClaw dostaje 3 warstwy:

Router (MCC) — funkcja, która bierze request i przypina callsign, mode, packet_path, owner_agent
FileOps — narzędzia do tworzenia/aktualizacji pakietów w strukturze folderów
Telemetry — emitowanie statusów + indeksowanie aktywnych pakietów

Czyli OpenClaw staje się Twoim “system of record” dla:

struktury na dysku,
routingu,
statusów,
decyzji.

2) “OpenClaw Workspace”: jak ustawić foldery i konwencje

2.1 Jedna stała zmienna: `ROOT_PATH`

W OpenClaw konfigurujesz jedną ścieżkę:

ROOT_PATH = {{ROOT_PATH}}

np.

/missions (Linux)
D:\org\missions (Windows)
~/org/missions

Ważne: To jest jedyny “global”, reszta jest deterministyczna.

2.2 Słownik mapowania CALLSIGN → folder

W OpenClaw trzymasz mapę:

APOLLO-CORE   -> APOLLO/CORE_TECH
APOLLO-CODE   -> APOLLO/FLIGHT_CODE
APOLLO-VERIFY -> APOLLO/VERIFICATION

HUBBLE-CONTENT  -> HUBBLE/CONTENT
HUBBLE-CREATIVE -> HUBBLE/CREATIVE

ARTEMIS-EXP    -> ARTEMIS/EXPERIMENTS
ARTEMIS-TLM    -> ARTEMIS/TELEMETRY
ARTEMIS-GROUND -> ARTEMIS/GROUND_CREW

Dzięki temu każde polecenie z callsignem automatycznie wie:

gdzie tworzyć pakiet
gdzie zapisywać artefakty
gdzie szukać istniejących pakietów

3) “Routing” w OpenClaw: jak OpenClaw ma rozumieć Twoje komendy

3.1 Standardowy format requestu (kontrakt)

Ustalmy 1 kontrakt, który działa dla wszystkich LLM i UI:

{
  "intent": "create_packet | update_packet | close_packet | list_active | search",
  "callsign": "ARTEMIS-TLM",
  "mode": "SIM",
  "priority": "P1",
  "title": "retention-drop-7d",
  "slug": "retention-drop-7d",
  "owner_agent": "Pulse",
  "brief": {
    "context": "...",
    "goal": "...",
    "deliverables": ["..."],
    "constraints": ["..."],
    "acceptance": ["..."],
    "risks": ["..."]
  }
}

W praktyce UI/LLM może wysłać mniej pól — OpenClaw uzupełnia brakujące:

mode domyślnie SIM
owner_agent domyślnie z mapy “preferowany agent dla callsigna”
slug generowany z title

3.2 “MCC Router” — logika routingu (minimalna)

Routing ma 3 kroki:

Validate: czy callsign istnieje w mapie
Resolve path: policz packet_path:
- YYYY-MM-DD__CALLSIGN__slug
Decide mode:
- jeśli user wprost: “publish/deploy/final” → FLIGHT (ale tylko jeśli przejdzie checklist)
- inaczej SIM

To oznacza, że model/LLM może być “głupi”, a system i tak będzie spójny.

4) “FileOps” w OpenClaw: zestaw narzędzi (tooling)

Żeby to działało na innym LLM, OpenClaw musi mieć zestaw narzędzi do plików. Minimalny zestaw:

4.1 Tools (minimum)

create_packet(callsign, slug, mode, owner, priority, brief)
➜ tworzy folder + pliki: 00_brief.md, 10_worklog.md, 30_results.md, 40_decision.md, 90_links.md
append_worklog(packet_path, entry)
➜ dopisuje statusy i wydarzenia
write_artifact(packet_path, relative_path, content)
➜ zapisuje artefakty do 20_artifacts/…
set_decision(packet_path, decision, rationale, tradeoffs, followup)
➜ wypełnia 40_decision.md + ewentualnie podbija 30_results.md
archive_packet(packet_path)
➜ przenosi pakiet do 99_archive/ w obrębie misji i dopisuje indeks w _MCC/90_archive-index.md
list_active_packets(filters)
➜ czyta _MCC/20_active-missions.md lub skanuje missions/*/*/missions po statusie

Jeśli masz już swój ToolManager do plików, to jest dokładnie to miejsce.

5) Telemetry: jak OpenClaw raportuje stan Twojego systemu

Twoje “metryki operacyjne” to:

status pakietów (NOT_STARTED/IN_PROGRESS/BLOCKED/READY_FOR_FLIGHT/DONE)
WIP per misja i global (MCC)
blockers i ryzyka
czas w SIM/FLIGHT
decyzje (PROCEED/ITERATE/HOLD/SCRUB)

5.1 Format jednego eventu telemetry (proponowany)

{
  "ts": "2026-02-23T09:30:00+01:00",
  "packet": "2026-02-23__ARTEMIS-TLM__retention-drop-7d",
  "callsign": "ARTEMIS-TLM",
  "mode": "SIM",
  "status": "IN_PROGRESS",
  "owner_agent": "Pulse",
  "eta": "2026-02-24",
  "risks": ["data incomplete"],
  "blockers": [],
  "next": ["pull cohort data", "check funnel step drop-off"]
}

5.2 Gdzie to ląduje

UI dashboard (SSE/stream)
_MCC/20_active-missions.md (human-readable)
10_worklog.md w pakiecie (audit trail)

OpenClaw może emitować event i równolegle dopisać worklog.

6) SIM/FLIGHT w OpenClaw: bramka jakości (gate)

Najważniejsze: OpenClaw powinien blokować FLIGHT bez checklisty.

6.1 “Switch to FLIGHT” jako osobna akcja

Zamiast pozwalać na mode=FLIGHT od razu, robisz:

request_flight(packet) → generuje checklistę w pakiecie
approve_flight(packet, approver) → dopiero przełącza mode=FLIGHT

Minimalna logika

Jeżeli priority P0/P1 → wymaga “PROGRAM LEAD GO”
Jeżeli dotyczy systemu (APOLLO) → wymaga “APOLLO-VERIFY GO” (Inspector)

7) Agent routing w OpenClaw: jak mapować “kto robi”

W Twoim systemie agent jest “call-signowym specjalistą”. Najprościej:

7.1 Mapa preferowanych agentów per sekcja

APOLLO-CORE   -> [Anvil, Cipher]
APOLLO-CODE   -> [Pixel, Sentry]
APOLLO-VERIFY -> [Inspector]

HUBBLE-CONTENT  -> [Rex, Sage, Echo, Clip]
HUBBLE-CREATIVE -> [Nebula, Nova]

ARTEMIS-EXP    -> [Scout, Herald]
ARTEMIS-TLM    -> [Pulse, Forge]
ARTEMIS-GROUND -> [Beacon, Link, Vibe]

OpenClaw może:

wybrać pierwszego dostępnego,
albo przyjąć owner_agent z requestu,
albo pozwolić MISSION CONTROL ręcznie przypisać.

8) Przykład użycia w OpenClaw (realny przepływ)

8.1 Zlecenie od PROGRAM LEAD

“Spada retencja 7‑dniowa, zdiagnozuj i zaproponuj działania.”

Krok A — MCC tworzy pakiet (ARTEMIS-TLM)

Request:

{
  "intent": "create_packet",
  "callsign": "ARTEMIS-TLM",
  "mode": "SIM",
  "priority": "P1",
  "title": "retention-drop-7d",
  "owner_agent": "Pulse",
  "brief": {
    "context": "Spadek retencji 7d obserwowany od 2 tygodni.",
    "goal": "Zidentyfikować źródło spadku i zaproponować działania korygujące.",
    "deliverables": ["Raport + hipotezy", "Lista rekomendacji", "Plan pomiaru po wdrożeniu"],
    "constraints": ["Bez zmian produkcyjnych bez gate FLIGHT"],
    "acceptance": ["Wskazany etap lejka lub segment odpowiedzialny za spadek", "Proponowane 2–3 eksperymenty", "Telemetry plan z progami"],
    "risks": ["Brak kompletnych danych kohortowych"]
  }
}

OpenClaw rezultat:

tworzy folder: ARTEMIS/TELEMETRY/missions/2026-02-23__ARTEMIS-TLM__retention-drop-7d/
generuje 5 plików standardowych
emituje telemetry IN_PROGRESS

Krok B — Pulse dopisuje wyniki i artefakty

zapis do 20_artifacts/retention_analysis.md
dopis do 10_worklog.md

Krok C — MISSION CONTROL domyka decyzję

set_decision(..., decision="ITERATE" ...)
(opcjonalnie) tworzy child packet w ARTEMIS-EXP na eksperyment

9) Jak to “uruchomić na innym LLM-ie” (praktyka)

W Twoim prompt systemowym (ten, który już masz) LLM:

generuje request JSON,
OpenClaw jest “wykonawcą” (tworzy foldery/pliki),
LLM potem czyta potwierdzenia i robi kolejne kroki.

W skrócie:

LLM = planowanie i treść
OpenClaw = deterministyczna egzekucja w FS + telemetry

10) Minimalne rzeczy, które muszę od Ciebie dostać, żeby dopiąć mapowanie “na 100%”

Żeby nie zgadywać Twoich endpointów/komend w OpenClaw, potrzebuję 3 krótkich informacji:

Jak wygląda wywołanie narzędzi w OpenClaw?
- JSON RPC? REST? “tools” jak w function calling?
Jaki jest ROOT_PATH na maszynie, gdzie OpenClaw ma pisać pliki?
Czy OpenClaw ma już narzędzia plikowe typu: write_file, mkdir, append_file?

Odpowiedz nawet skrótowo, np.:

„REST + JSON, root: /data/org/missions, mam mkdir/write/append” i ja od razu przerobię powyższe na konkretne endpointy i przykładowe payloady dokładnie pod Twoją implementację.

Jeśli chcesz, mogę też przygotować “OpenClaw Config Pack”

Czyli gotowy plik konfiguracyjny (np. openclaw.missions.json) zawierający:

mapę callsign → folder,
mapę callsign → agenci,
domyślne reguły SIM/FLIGHT,
WIP limit,
szablony plików.

Tylko daj znać jaki format configu preferujesz: JSON / YAML / TOML.

48 KiB Raw Blame History Unescape Escape

1) Co to za system (w jednym zdaniu)

2) Warstwy odpowiedzialności (governance)

2.1 PROGRAM LEAD — warstwa decyzji

2.2 MISSION CONTROL — warstwa operacji

3) “Misje NASA” jako system nawigacji (dlaczego to działa)

4) Misje: znaczenie, routing i sekcje

🚀 [APOLLO] — FLIGHT SYSTEMS

Sekcje APOLLO

Agenci APOLLO (collapsed w diagramie)

🔭 [HUBBLE] — MISSION STORY

Sekcje HUBBLE

Agenci HUBBLE

🌙 [ARTEMIS] — MISSION OUTCOMES

Sekcje ARTEMIS

Agenci ARTEMIS

5) Dlaczego call‑signy są kluczowe w OpenClaw

5.1 Co zyskujesz od razu

5.2 Jak to mapować “operacyjnie”

6) Typowy przepływ pracy (end‑to‑end)

6.1 Start: decyzja i intencja

6.2 Routing do misji

6.3 Rozbicie na sekcje i wykonanie

6.4 Telemetria i domknięcie

7) Jak tego używać jako “system zarządzania” (praktyczne zasady)

7.1 Prosta reguła przypisania

7.2 Minimalny standard zlecenia (żeby agenci nie błądzili)

7.3 Ograniczenie chaosu (WIP)

8) Co mogę dopisać, żeby opis był „pełny” pod OpenClaw

8.1 „Command grammar” dla OpenClaw

8.2 Mapowanie na storage (Twoje .org / Johnny Decimal)

1️⃣ Struktura folderów (Mission‑first, nie „działy”)

1.1 Zasada nadrzędna

1.2 Proponowana struktura główna

Dlaczego to działa

2️⃣ Routing w OpenClaw (jak delegować i sterować)

2.1 Zasada routingu (najważniejsza)

2.2 Standardowy routing taska

Format mentalny (i do logów):

Przykłady:

2.3 Jak to wygląda w praktyce (OpenClaw‑style)

Komenda / zadanie (przykład)

2.4 Reguły decyzyjne (bardzo ważne)

3️⃣ Przykład użycia systemu (end‑to‑end)

3.1 Sytuacja startowa (PROGRAM LEAD)

3.2 MISSION CONTROL przejmuje sterowanie

3.3 Wykonanie w misjach

ARTEMIS — Telemetry

HUBBLE — Mission Story

APOLLO — Verification

3.4 Domknięcie (MISSION CONTROL)

4️⃣ Dlaczego to jest system zarządzania, a nie „ładny diagram”

0) TL;DR — jak działa system (30 sekund)

1) Struktura folderów (gotowiec do wdrożenia)

1.1 Zasady folderów (żeby nie robić chaosu)

1.2 Proponowana struktura główna (repo / .org)

1.3 Standard nazwy „pakietu zadania” (folderu misji)

2) Routing: reguły kierowania pracy (OpenClaw-friendly)

2.1 Routing Key (Twoja „nawigacja”)

2.2 Reguła „pierwszego strzału” (gdy nie wiesz gdzie wrzucić)

2.3 Reguły eskalacji (żeby nie zabić czasu)

3) Szablony (copy‑paste): backlog / brief / status / decyzja

3.1 Task Brief (00_brief.md)

3.2 Worklog (10_worklog.md)

3.3 Results (30_results.md)

3.4 Decision Record (40_decision.md)

4) Tryby SIM / FLIGHT (żeby system był bezpieczny i powtarzalny)

4.1 Co wolno w SIM

4.2 Co wolno w FLIGHT

4.3 Checklista SIM→FLIGHT (sim-flight-checklist.md)

5) Archiwizacja misji (żeby nie utonąć w historii)

5.1 Kiedy archiwizować?

5.2 Jak archiwizować (procedura)

Wpis do archive index (przykład)

6) Przykład użycia systemu (pełny scenariusz)

Problem

Krok 1 — MISSION CONTROL robi triage i routing

Krok 2 — Wykonanie (SIM)

Krok 3 — SIM→FLIGHT

Krok 4 — FLIGHT

48 KiB

Raw Blame History

8.2 Mapowanie na storage (Twoje `.org` / Johnny Decimal)

1.2 Proponowana struktura główna (repo / `.org`)

7) Minimalny “Operating Manual” do `_MCC/00_operating-manual.md`

4) TEMPLATES (wklej jako pliki do `_MCC/50_templates/`)

4.1 `task-brief.md`

4.2 `sim-flight-checklist.md`

4.3 `post-mission-report.md`

4.4 `decision-record.md`

2.1 Jedna stała zmienna: `ROOT_PATH`