Paweł Domański
1735 lines
48 KiB
Markdown
1735 lines
48 KiB
Markdown
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:
|
||
|
||
1. **cel**,
|
||
2. **zakres**,
|
||
3. **sekcje**,
|
||
4. **agentów**,
|
||
5. **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:
|
||
|
||
1. **Misja**: `APOLLO` / `HUBBLE` / `ARTEMIS`
|
||
2. **Sekcja**: `APOLLO-CORE`, `ARTEMIS-TLM`…
|
||
3. **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
|
||
|
||
1. PROGRAM LEAD ustala cel/prior (np. “podnieść retencję”, “dowiezć release”).
|
||
2. 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ś:
|
||
|
||
1. **Struktura folderów** (jak to trzymać na dysku / w repo / w `.org`)
|
||
2. **Routing zadań i komend** (jak nawigować i delegować w OpenClaw)
|
||
3. **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
|
||
|
||
```text
|
||
/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):
|
||
|
||
```text
|
||
[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)
|
||
|
||
```text
|
||
[MCC][ARTEMIS-TLM]
|
||
Goal: Zrozumieć spadek konwersji w ostatnich 14 dniach
|
||
Output: Raport + rekomendacje
|
||
Owner: Pulse
|
||
```
|
||
|
||
Albo krócej:
|
||
|
||
```text
|
||
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ą**:
|
||
|
||
```text
|
||
Objective: Improve 7-day retention
|
||
Constraint: No major infra changes this week
|
||
```
|
||
|
||
***
|
||
|
||
## 3.2 MISSION CONTROL przejmuje sterowanie
|
||
|
||
MISSION CONTROL robi 3 rzeczy:
|
||
|
||
1. Rozbija problem na strumienie:
|
||
* **dlaczego spada?** → ARTEMIS (Telemetry)
|
||
* **jak to komunikujemy?** → HUBBLE (Story)
|
||
* **czy system coś psuje?** → APOLLO (Verify)
|
||
|
||
2. Nadaje routing:
|
||
|
||
```text
|
||
[MCC][ARTEMIS-TLM] Analyze retention drop
|
||
[MCC][HUBBLE-CONTENT] Explain value better to users
|
||
[MCC][APOLLO-VERIFY] Check for regressions
|
||
```
|
||
|
||
3. Definiuje “done”.
|
||
|
||
***
|
||
|
||
## 3.3 Wykonanie w misjach
|
||
|
||
### ARTEMIS — Telemetry
|
||
|
||
* **Pulse** analizuje dane,
|
||
* **Forge** sugeruje optymalizacje,
|
||
* output: raport + hipotezy.
|
||
|
||
Folder:
|
||
|
||
```text
|
||
/missions/ARTEMIS/TELEMETRY/analysis/retention-7d.md
|
||
```
|
||
|
||
***
|
||
|
||
### HUBBLE — Mission Story
|
||
|
||
* **Sage** robi research,
|
||
* **Rex** pisze nową narrację,
|
||
* **Clip/Nova** przygotowują materiały.
|
||
|
||
Folder:
|
||
|
||
```text
|
||
/missions/HUBBLE/CONTENT/scripts/retention-story.md
|
||
```
|
||
|
||
***
|
||
|
||
### APOLLO — Verification
|
||
|
||
* **Inspector** sprawdza testy,
|
||
* **Cipher** audytuje security,
|
||
* brak regresji → zielone światło.
|
||
|
||
Folder:
|
||
|
||
```text
|
||
/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ą.
|
||
|
||
```text
|
||
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)
|
||
|
||
1. **Misja jest najwyższą jednostką organizacji**: APOLLO/HUBBLE/ARTEMIS
|
||
2. Każda misja ma sekcje odpowiadające call‑signom
|
||
3. Każde zadanie ma swój „pakiet” (folder) z:
|
||
* briefem,
|
||
* artefaktami,
|
||
* decyzją końcową,
|
||
* logiem zmian.
|
||
|
||
## 1.2 Proponowana struktura główna (repo / `.org`)
|
||
|
||
```text
|
||
/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:
|
||
|
||
```text
|
||
/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:
|
||
|
||
```text
|
||
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ć)
|
||
|
||
1. Czy dotyka **stabilności, bezpieczeństwa, infra, kodu lub jakości**? → **APOLLO**
|
||
2. Czy dotyka **treści, narracji, kreatywy, dystrybucji**? → **HUBBLE**
|
||
3. Czy dotyka **wyniku, wzrostu, telemetrii, community/support**? → **ARTEMIS**
|
||
4. 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)
|
||
|
||
```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)
|
||
|
||
```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)
|
||
|
||
```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)
|
||
|
||
```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)
|
||
|
||
```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)
|
||
|
||
1. Uzupełnij `30_results.md` i `40_decision.md`
|
||
2. Przenieś folder pakietu do `99_archive/` w danej misji
|
||
3. Dodaj wpis do `_MCC/90_archive-index.md`
|
||
|
||
### Wpis do archive index (przykład)
|
||
|
||
```md
|
||
- 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:
|
||
|
||
1. `[ARTEMIS-TLM]` analiza przyczyny i metryk
|
||
2. `[HUBBLE-CONTENT]` poprawa onboardingowej historii
|
||
3. `[APOLLO-VERIFY]` sprawdzenie regresji / jakości
|
||
|
||
Foldery:
|
||
|
||
```text
|
||
/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:
|
||
|
||
```md
|
||
# 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):
|
||
|
||
```text
|
||
[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:
|
||
|
||
1. **SYSTEM PROMPT (master)** – to jest rdzeń zachowania modelu
|
||
2. **CONTEXT PACK** – stałe informacje o Twoim systemie (misje, routing, foldery)
|
||
3. **TASK TEMPLATES** – wzorce odpowiedzi i dokumentów (Brief/Worklog/Results/Decision)
|
||
4. **OPERATING RULES** – SIM/FLIGHT, WIP, triage, archiwizacja
|
||
5. **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.
|
||
|
||
```text
|
||
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.
|
||
|
||
```text
|
||
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ń”.
|
||
|
||
```text
|
||
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`
|
||
|
||
```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`
|
||
|
||
```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`
|
||
|
||
```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`
|
||
|
||
```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)
|
||
|
||
```text
|
||
[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)
|
||
|
||
```text
|
||
[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
|
||
|
||
```text
|
||
[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:
|
||
|
||
1. **MASTER SYSTEM PROMPT** (sekcja 1)
|
||
2. **CONTEXT PACK** (sekcja 2) z `{{ROOT_PATH}}` i `{{WIP_LIMIT}}`
|
||
3. (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:
|
||
|
||
1. **Router (MCC)** — funkcja, która bierze request i przypina `callsign`, `mode`, `packet_path`, `owner_agent`
|
||
2. **FileOps** — narzędzia do tworzenia/aktualizacji pakietów w strukturze folderów
|
||
3. **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ę:
|
||
|
||
```text
|
||
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ę:
|
||
|
||
```text
|
||
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:
|
||
|
||
```json
|
||
{
|
||
"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:
|
||
|
||
1. **Validate**: czy callsign istnieje w mapie
|
||
2. **Resolve path**: policz `packet_path`:
|
||
* `YYYY-MM-DD__CALLSIGN__slug`
|
||
3. **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)
|
||
|
||
1. `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`
|
||
|
||
2. `append_worklog(packet_path, entry)`
|
||
➜ dopisuje statusy i wydarzenia
|
||
|
||
3. `write_artifact(packet_path, relative_path, content)`
|
||
➜ zapisuje artefakty do `20_artifacts/…`
|
||
|
||
4. `set_decision(packet_path, decision, rationale, tradeoffs, followup)`
|
||
➜ wypełnia `40_decision.md` + ewentualnie podbija `30_results.md`
|
||
|
||
5. `archive_packet(packet_path)`
|
||
➜ przenosi pakiet do `99_archive/` w obrębie misji i dopisuje indeks w `_MCC/90_archive-index.md`
|
||
|
||
6. `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)
|
||
|
||
```json
|
||
{
|
||
"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:
|
||
|
||
1. `request_flight(packet)` → generuje checklistę w pakiecie
|
||
2. `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
|
||
|
||
```text
|
||
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:**
|
||
|
||
```json
|
||
{
|
||
"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:
|
||
|
||
1. **Jak wygląda wywołanie narzędzi w OpenClaw?**
|
||
* JSON RPC? REST? “tools” jak w function calling?
|
||
2. **Jaki jest ROOT\_PATH** na maszynie, gdzie OpenClaw ma pisać pliki?
|
||
3. 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**.
|