Trzy poziomy wejścia i kontroli

Junexis ma pomagać zbudować i zrozumieć system, a jednocześnie pozwalać świadomie ustalać szczegóły jego działania. Trzy poziomy opisują zakres prowadzenia i decyzji, których potrzebujesz przy danym zadaniu.

Dobierasz zakres kontroli, nie rangę użytkownika

Pracujesz w tym samym języku i nad tym samym projektem. Możesz korzystać z prowadzenia w nieznanym obszarze, a w znanym samodzielnie ustalać szczegóły. Nie musisz przechodzić poziomów po kolei ani rezygnować z pomocy po zdobyciu doświadczenia.

Nazwy początkujący, średniozaawansowany i ekspert pomagają dobrać materiały oraz zakres wyjaśnień. Nie oznaczają roli konta, uprawnień administratora, planu abonamentowego ani wyboru architektury systemu.

Co opisuje ta strona

Jest to zasada projektowania i kierunek rozwoju Junexis, a nie deklaracja trzech gotowych, jednolitych trybów całej platformy. Działające scenariusze i poziom pomocy różnią się między narzędziami oraz środowiskami wykonania. Wybór poziomu nie udostępnia konstrukcji, której dany generator jeszcze nie obsługuje, ani nie potwierdza bezpieczeństwa konkretnego wdrożenia.

To nie są trzy wersje języka ani trzy niezgodne tryby CLI. To wspólny kontrakt dla kompilatora, Studio, Mentora i dokumentacji.

flowchart LR
    P["Ten sam projekt<br/>czego potrzebujesz przy tym zadaniu?"] --> B["Poziom 1<br/>prowadź mnie"]
    P --> I["Poziom 2<br/>wyjaśnij i pomóż dostroić"]
    P --> E["Poziom 3<br/>pokaż decyzje i konfigurację"]

Poziom	Potrzeba użytkownika	Odpowiedzialność narzędzi	Odpowiedzialność użytkownika
Początkujący	„Chcę zbudować wartościowy system bez ręcznej konfiguracji infrastruktury”	bezpieczne wartości domyślne, prowadzenie od problemu do dostarczenia, czytelne błędy i odmowa ryzykownej operacji	opisać cel, dane i reguły oraz poprawić wskazane błędy
Średniozaawansowany	„Chcę zrozumieć i dostroić system”	pokazać analizę, skutki decyzji i zalecane ustawienia	świadomie wybierać środowiska, narzędzia i polityki
Ekspert	„Chcę kontrolować każdy istotny parametr”	pokazać pełną konfigurację efektywną i niczego po cichu nie zmieniać	jawnie skonfigurować system i przyjąć konsekwencje decyzji

Wybierz ścieżkę wykonawczą

Każda ścieżka ma odpowiadający jej pełny kurs. Ścieżka jest krótką mapą, a kursy i tutoriale prowadzą przez lekcje oraz ćwiczenia.

Ścieżka początkująca prowadzi do pierwszego działającego serwera z bezpiecznymi wartościami domyślnymi.
Ścieżka średniozaawansowana dodaje analizę, wielośrodowiskowy build, bramki artefaktów, paczkę i kontrolę gotowości.
Ścieżka ekspercka odsłania identyfikatory, extern, podpisy, politykę zaufania i jawny wybór urządzenia.

flowchart TB
    START{"Czego teraz potrzebujesz?"}
    START -->|"bezpieczne prowadzenie"| BEGINNER["Ścieżka początkująca"]
    START -->|"zrozumienie i dostrojenie"| INTERMEDIATE["Ścieżka średniozaawansowana"]
    START -->|"pełna kontrola"| EXPERT["Ścieżka ekspercka"]

Ten sam problem, inny zakres decyzji

W przykładzie temperatury magazynu celem pozostaje wykrycie przekroczenia progu i pokazanie aktualnego stanu. Zmienia się zakres decyzji podejmowanych samodzielnie, a nie wartość budowanego systemu.

Potrzeba przy tym zadaniu	Jak powinno wyglądać prowadzenie
Prowadź mnie	otrzymuję sprawdzony przykład, wymagania, kolejne kroki, oczekiwany wynik i granicę lokalnego uruchomienia
Pomóż mi zrozumieć i dostroić	sprawdzam regułę i przepływ, zmieniam próg lub rytm pomiarów i obserwuję skutki
Pozwól mi ustalić szczegóły	jawnie konfiguruję obsługiwane parametry komunikacji, trwałego stanu i uruchomienia oraz sprawdzam skutki awarii

To przykład oczekiwanego sposobu pracy, nie obietnica automatycznej konfiguracji dowolnego magazynu, urządzenia czy sieci. Instrukcja dla konkretnej ścieżki musi wskazywać, co rzeczywiście zostało sprawdzone.

Przy każdym zakresie trzeba określić cel, sprawdzić wynik i zdecydować o uruchomieniu. Prowadzenie ogranicza liczbę decyzji technicznych podejmowanych na początku; nie przenosi odpowiedzialności za rzeczywisty system na narzędzie.

Poziom 1: bezpieczny rezultat

Początkujący nie powinien znać protokołów, generatorów i struktury artefaktów, aby zbudować wartościowy system. Początkujący może modelować dane, komunikację, decyzje i skutki awarii; narzędzia prowadzą go przez bezpieczną ścieżkę:

problem → model → doctor → check → analyze → build → artifact-gate
→ package → kontrola gotowości → ograniczone uruchomienie

Na tym poziomie narzędzia powinny:

wybierać wyłącznie bezpieczne, obsługiwane wartości domyślne,
wygenerować działający artefakt albo zatrzymać budowanie z jasnym komunikatem,
nie programować urządzenia ani nie wykonywać nieodwracalnej operacji bez jawnego wyboru użytkownika,
zachować podjęte decyzje w analizie i manifestach, aby można je było później sprawdzić,
podawać jedno zalecane rozwiązanie przed listą wariantów eksperckich.

Poziom początkujący nie kończy się po poznaniu składni ani po pierwszym budowaniu. Można pozostać na nim przez wiele projektów, jeżeli bezpieczne ustawienia spełniają potrzeby. Większy zakres kontroli wybierasz wtedy, gdy wymaga go zadanie, a nie po zaliczeniu przykładu.

Zacznij od ścieżki początkującej. Pełny projekt, dziesięć lekcji i ćwiczenia zawiera kurs początkujący. Obecna sprawdzona ścieżka prowadzi przez wielozadaniowy system @server, natywny artefakt, paczkę i lokalne uruchomienie. Studio domyślnie używa na tym poziomie trybu Mentora Teaching.

Poziom 2: świadome prowadzenie

Średniozaawansowany zna już model Junexis i podstawy systemów rozproszonych. Nie potrzebuje ukrywania szczegółów, ale nadal korzysta z pomocy narzędzi.

Na tym poziomie pojawiają się:

analyze oraz zapis modelu i topologii,
artifact-gate do sprawdzenia natywnych zestawów narzędzi,
package i deploy preflight przed lokalnym uruchomieniem,
diagnostyka z wyjaśnieniem przyczyny i proponowanego następnego kroku,
Studio, Mentor i Narrative jako pomoc w rozumieniu struktury oraz wykonania,
tryb Mentora Balanced, gdy pełne objaśnienia nie są już potrzebne,
jawny wybór środowisk docelowych i przegląd wygenerowanych artefaktów.

Dobrym wejściem jest ścieżka średniozaawansowana, kurs średniozaawansowany, pełny przykład, a następnie przepisy użytkowe i diagnostyka.

Poziom 3: pełna kontrola

Ekspert powinien widzieć wszystkie decyzje istotne dla wykonania i móc je zastąpić własną konfiguracją. Wejście w powierzchnię ekspercką oznacza jednak, że wymagane parametry muszą być jawne — narzędzie nie powinno zgadywać ustawień protokołu, zaufania, wdrożenia lub urządzenia.

Na tym poziomie mieszczą się między innymi:

własne implementacje extern i integracja kodu należącego do autora,
jawny wybór generatorów, zestawów narzędzi i urządzenia,
polityki podpisu paczki, zaufanych podpisujących i dopuszczenia wdrożenia,
konfiguracja uruchomienia, odporności, obserwacji i debugowania,
bezpośrednia inspekcja manifestów, map źródeł, analizy i dowodów wykonania,
własne adaptery oraz integracje natywne w zakresie obsługiwanym przez dany komponent.
tryb Mentora Quiet, gdy ekspert chce sięgać po analizę wyłącznie na żądanie.

Pełna kontrola nie wyłącza walidacji semantyki ani kontroli bezpieczeństwa. Ekspert może zastąpić wartość domyślną, ale narzędzie nadal powinno odrzucić niespójny system i pokazać dokładną przyczynę.

Zacznij od ścieżki eksperckiej, a następnie zobacz kurs ekspercki, katalog CLI, architekturę budowania, pakowanie i wdrożenie oraz zgodność wersji.

Jak przechodzi się pomiędzy poziomami

Nie trzeba migrować projektu ani zmieniać odmiany języka. Przy zwiększaniu zakresu kontroli projekt rośnie addytywnie:

zaczyna od minimalnego opisu i wartości domyślnych,
dodaje konfigurację tylko tam, gdzie pojawia się świadoma potrzeba,
zastępuje wybrane decyzje pełną konfiguracją ekspercką.

Każda wartość domyślna powinna być możliwa do odczytania. Każde ustawienie eksperckie powinno mieć opis konsekwencji. To usuwa „magię” dla eksperta bez obciążania nią początkującego.

Możesz też wrócić do prowadzenia w kolejnym zadaniu. Powrót do wartości domyślnych w istniejącym projekcie wymaga jednak sprawdzenia zgodności z jego konfiguracją; nie oznacza automatycznego usunięcia wcześniejszych decyzji.

Stan obecny

Portal opisuje ten model jako kontrakt rozwoju produktu. Bezpieczna ścieżka początkująca dla @server działa już dziś. Narzędzia poziomu drugiego mają działające scenariusze. Zakres pełnej kontroli eksperckiej jest nadal rozszerzany i różni się pomiędzy środowiskami docelowymi.

Zasada dla każdej instrukcji

Każdy poradnik powinien podawać poziom i zachować właściwy zakres:

początkujący: dokładne polecenia, oczekiwany rezultat i bezpieczna granica,
średniozaawansowany: wyjaśnienie decyzji, diagnostyka i możliwe warianty,
ekspert: wszystkie założenia, parametry, skutki i tryby awarii.

Opcje eksperckie nie powinny pojawiać się w ścieżce początkującej bez potrzeby. Wartości domyślne nie powinny pozostawać niewidoczne w materiałach eksperckich.