Aktualizacje i samonaprawa

Zasada

Samonaprawa oznacza zdolność wykrycia problemu, zebrania dowodów, zbudowania i przetestowania kandydata oraz przedstawienia bezpiecznej rekomendacji. Nie oznacza prawa do cichej modyfikacji aktywnego systemu. NORBI może autonomicznie pracować nad naprawą, ale promocja kodu, instalacja pakietu, aktualizacja firmware, restart krytycznej usługi i zwiększenie uprawnień są odrębnymi skutkami.

Karta modułu

Pole	Kontrakt
Odpowiedzialności	health, detekcja regresji, diagnoza hipotez, candidate patch/config, test, canary, rollback plan, raport.
Wejścia	alerty, logi redagowane, metryki, traces, wersje, manifesty, testy, zgłoszenia użytkownika.
Wyjścia	incident, diagnosis, candidate, evidence bundle, update proposal, recovery action.
Zależności	observability, Execution Fabric, worktrees, Tool/Agent Registry, backup, Approval Center.
Uprawnienia	read diagnostics, write/test candidate; brak automatycznego main, install, activate i restart poza pre-approved safe class.
Autonomia	triage i iteracja kandydata w budżecie; nie rozszerza zakresu incydentu.
Walidacja	reprodukcja, regression suite, security gates, canary, post-change health i rollback readiness.
Awaria	freeze updates, powrót do known-good, recovery mode i człowiek przez Management Node/KVM.

Polityka aktualizacji

Każda aktualizacja ma kanał (security, stable, preview), pochodzenie, podpis, checksum, SBOM, zgodność platformy, wymagania migracji, przewidywany downtime, rollback i testy. Auto-download może być dozwolony dla publicznych metadanych, lecz download nie oznacza install. Pakiet trafia do quarantine, przechodzi weryfikację i staje się candidate.

Typowe klasy:

Klasa	Przykład	Wymagana decyzja
dane niskiego ryzyka	indeks kompatybilności, sygnatury wykrywania	według zatwierdzonej polityki kanału
model	nowe wagi lub quant	test benchmark + approval aktywacji
plugin/adapter	nowa wersja integracji	capability diff + review + activation
core/control plane	broker, policy, migracja DB	maintenance approval + backup + recovery plan
system/firmware	sterownik GPU, BIOS, KVM, UPS	jawne okno serwisowe i operator

Pętla samonaprawy

flowchart LR
    A["Wykrycie"] --> B["Triage i zakres"]
    B --> C["Hipotezy"]
    C --> D["Reprodukcja izolowana"]
    D --> E["Candidate fix"]
    E --> F["Testy + porównanie"]
    F --> G["Review evidence"]
    G --> H["Approval wdrożenia"]
    H --> I["Canary"]
    I --> J{"Health OK?"}
    J -->|tak| K["Kontrolowany rollout"]
    J -->|nie| L["Rollback / recovery"]

Diagnoza rozważa kilka hipotez i wybiera test rozróżniający. System nie powtarza nieskutecznego patcha. Jeśli trzy iteracje nie poprawiają miernika, eskaluje z pełną historią, zamiast zwiększać losowo zakres zmian.

Kod i konfiguracja

Zmiana kodu powstaje w dedykowanym worktree. Main pozostaje read-only dla zwykłych tools. Candidate zawiera base commit, diff hash, changed paths i test receipts. Przed review jest zamrażany. Każda dalsza edycja unieważnia evidence i approvals. Promocję realizuje oddzielny principal/tool, który ponownie sprawdza main oraz candidate.

Konfiguracja runtime również jest wersjonowanym artefaktem. „Mała zmiana flagi” może zmienić granicę bezpieczeństwa, dlatego ma schema, diff, validator i rollback. Dynamiczny tuning dopuszcza się wyłącznie dla pól oznaczonych jako bezpieczne i w zatwierdzonym zakresie, np. limit równoległości 2–4; nie dla capability czy protected roots.

Backup i migracje

Przed migracją powstaje zweryfikowany copy-only backup. Migracja działa pod maintenance lock, zapisuje wersję kodu/schema i checksums, jest transakcyjna, gdy to możliwe. Po zmianie wykonywane są integrity checks oraz próba kluczowych workflow. Nieudana migracja przywraca pre-migration DB przed wznowieniem dispatch. Backup uznaje się za wiarygodny dopiero po odtworzeniu w izolacji.

Przykładowe polecenia

• „Zdiagnozuj wzrost błędów transkrypcji i przygotuj kandydata, nie zmieniaj aktywnego modelu.”
• „Sprawdź aktualizację pluginu Adobe w shadow i pokaż diff uprawnień.”
• „Przygotuj bezpieczne okno aktualizacji sterownika GPU z planem wycofania.”
• „Po awarii odtwórz stan do izolowanej lokalizacji i zatrzymaj się przed przełączeniem.”

Walidacja i obserwacja po zmianie

Gates obejmują schema, UTF-8, secret scan, testy jednostkowe, integracyjne, concurrency, restart/crash, security invariants i scenariusze domenowe. Canary ma jawne SLO i czas obserwacji. Brak błędów w logu nie wystarcza: sprawdza się rezultaty biznesowe, latency, queue depth, zasoby i alarmy użytkowników.

Ryzyka i scenariusz awaryjny

Ryzyka to błędna diagnoza, naprawa objawu, supply chain, migracja niekompatybilna w dół, canary bez reprezentatywnego ruchu i rollback niszczący nowe dane. Dlatego downgrade nie może automatycznie usuwać rekordów powstałych w nowym schemacie; może wymagać forward fix.

W razie nieudanego rollout system zatrzymuje kolejne węzły, odcina wersję od routingu, zachowuje receipty i przechodzi do known-good, jeśli plan wycofania jest dowiedziony. Gdy stan jest niepewny, uruchamia Recovery Console. Awaryjne sterowanie z KVM/Management Node przywraca infrastrukturę, ale nie jest używane do omijania approvali normalnej pracy.