Warstwa Inteligencji — 4 Filary

Jak Arc OS waliduje, uczy się, skupia i doskonali się.

Przegląd

Warstwa Inteligencji znajduje się między wiadomościami użytkownika a odpowiedziami Claude. Działa w czterech etapach:

         INPUT                    PROCESSING                 OUTPUT
    ┌──────────────┐        ┌──────────────────┐       ┌─────────────────┐
    │ User Message  │───────►│  Context Router   │       │ Claude Response  │
    │               │        │  (skill scoring)  │       │  + eval warnings │
    │ Fix It / 👎   │        │                  │       │                 │
    │ (feedback)    │        │  Learnings       │       │ Quality metrics │
    │               │        │  (correction     │       │  logged         │
    └──────────────┘        │   injection)     │       └────────┬────────┘
                            │                  │                │
                            │  buildGsdPrompt()│        ┌───────┴────────┐
                            └────────┬─────────┘        │ Nightly Loop   │
                                     │                  │ (improvement   │
                                     ▼                  │  proposals)    │
                              Claude CLI                └────────────────┘

Filar 1: Binary Eval Engine

Co robi: Deklaratywne reguły sprawdzające każdą odpowiedź przed jej dostarczeniem.

Dlaczego: Wyniki AI powinny mieć bramki jakości — jak testy jednostkowe dla kodu.

Jak:

Każdy skill może mieć plik .evals.json z regułami:

{
  "rules": [
    { "id": "gm-001", "type": "string_not_contains", "value": "--force", "severity": "warning" },
    { "id": "gm-002", "type": "max_length", "value": 4000, "severity": "info" }
  ]
}

Po wygenerowaniu odpowiedzi przez Claude, silnik eval uruchamia wszystkie pasujące reguły:

Zaliczone: odpowiedź dostarczona bez zmian
Niezaliczone: odpowiedź dostarczona + dodana przypis z ostrzeżeniem

[Claude's response about git operations]
---
Eval: ⚠️ No force push | ℹ️ Response under 4000 chars

Typy Reguł

Typ	Co sprawdza
`string_contains`	Odpowiedź musi zawierać dosłowny tekst
`string_not_contains`	Odpowiedź NIE może zawierać tekstu
`regex_match`	Odpowiedź musi pasować do wzorca regex
`regex_not_match`	Odpowiedź NIE może pasować do regex
`max_length`	Odpowiedź musi mieć <= N znaków
`min_length`	Odpowiedź musi mieć >= N znaków

Kluczowe Decyzje Projektowe

Nieblokujące: Ostrzeżenia nie tłumią odpowiedzi. Użytkownik widzi zarówno odpowiedź, jak i zastrzeżenie.
Per-skill: Różne skille mają różne kryteria jakości.
Per-projekt: Ten sam skill może mieć różne reguły dla różnych stosów technologicznych.
Brak AI w walidacji: Reguły są deterministyczne. Binarne zaliczenie/niezaliczenie. Zero niejednoznaczności.

Odniesienie projektowe: Anthropic Skill Creator — strukturalne evale z binarnymi asercjami.

Filar 2: Context Router

Co robi: Inteligentny dobór skilli — do każdego promptu wstrzykuje tylko te odpowiednie.

Dlaczego: 25 skilli załadowanych naraz = rozmycie kontekstu. Model próbuje stosować porady deploymentowe do code review.

Jak:

Przed zbudowaniem promptu router ocenia każdy zarejestrowany skill względem wiadomości użytkownika:

Score = (trigger matches x 2) + (keyword matches x 1)
Sort by score descending → take top 5

Przykład:

User: "Review this code for XSS vulnerabilities"

Scoring:
  code-review:     trigger "review" (2) + keyword "XSS" (1) = 3
  code-review-protocol: trigger "code review" (2)            = 2
  deployment-flow: no match                                  = 0
  git-manager:     no match                                  = 0

Injected into prompt:
  SKILLS_HINT (focus on these):
  - code-review: Security audit and code quality review...
  - code-review-protocol: Structured code review with OWASP...

Dlaczego doradczy, nie filtrujący

Router sugeruje skille, ale nie blokuje pozostałych. Claude nadal ma pełny dostęp.

Podejście	Ryzyko
Twarde filtrowanie (`--allowedTools`)	Błędna klasyfikacja psuje sesję
Mutacje symlinków	Zmiany systemu plików na działającym procesie
Podpowiedzi doradcze	Bezpieczne: zła podpowiedź = Claude ją ignoruje

Triggery vs Słowa Kluczowe

Triggery (2 pkt): Wyraźne sygnały wywołania. Użytkownik bezpośrednio żąda tej funkcji.

"deploy", "review", "scaffold", "audit"

Słowa kluczowe (1 pkt): Szerszy kontekst semantyczny. Sugeruje trafność bez bycia poleceniem.

"OWASP", "Docker", "CI/CD", "performance"

Odniesienie projektowe: Context priming — skupiona uwaga bez twardego filtrowania.

Filar 3: Reflect Loop

Co robi: Automatyczne przechwytywanie poprawek jako trwałych reguł.

Dlaczego: Korekty AI powinny przeżywać restarty. Jedna korekta = trwałe ulepszenie.

Jak:

CEO presses 🛠️ Fix It
    │
    ├── addLearning(source: "fixit", rule: "Fix requested for: <last response>")
    ├── projectLearnings reloaded from disk
    └── Fix prompt sent to Claude for immediate correction

CEO presses 👎
    │
    ├── addLearning(source: "negative", rule: "Negative feedback on: <response>")
    ├── qualityTracker.logFeedback(positive: false)
    └── projectLearnings reloaded from disk

Reguły są przechowywane w learnings.md:

# Learnings

## Rules

- [2026-04-03T14:22:00Z] [fixit] Always use t-call for translations in Odoo QWeb
- [2026-04-03T15:10:00Z] [negative] Avoid sudo in deployment scripts

Przy każdej kolejnej wiadomości zgromadzone learnings są wstrzykiwane:

LEARNINGS (past corrections — follow these rules):
- Avoid sudo in deployment scripts
- Always use t-call for translations in Odoo QWeb

Kluczowe Właściwości

Automatyczne: Bez ręcznego pisania reguł. Naciśnij przycisk → reguła utworzona.
Trwałe: Przeżywają restarty bota. Zapisywane na dysk jako Markdown.
Per-projekt: Każdy Child Bot ma własny learnings.md. Korekty dla Odoo nie wpływają na bota React.
Najnowsze pierwsze: Najnowsze korekty mają największą widoczność w prompcie.
Budżetowane: Maksymalnie 2000 znaków w bloku LEARNINGS. Najstarsze reguły wypadają.

Odniesienie projektowe: Claude Reflect System — korekty stają się trwałymi regułami zapobiegającymi regresji.

Filar 4: Karpathy Loop

Co robi: Nocna automatyczna analiza metryk jakości z propozycjami ulepszeń wysyłanymi do CEO.

Dlaczego: Ludzie zapominają przeglądać wyniki. System powinien sam znajdować swoje słabe punkty.

Jak:

Każdego dnia o 03:00 UTC uruchamia się scripts/nightly-improve.ts:

Odczyt rejestru — wyliczenie wszystkich Child Botów z bot_registry.json
Odczyt metryk — załadowanie quality-metrics.json per child
Znalezienie słabych punktów — filtrowanie skilli, gdzie:
- applied_count >= 3 (minimalna próbka, żeby uniknąć szumu)
- ORAZ success_rate < 80% LUB feedback_negative > feedback_positive
Odczyt learnings — wyodrębnienie powiązanych wzorców korekt
Generowanie propozycji — szablonowe (deterministyczne, bez AI)
Wysłanie do CEO — raport podsumowujący + karty poszczególnych propozycji w Telegram

Przepływ Zatwierdzania przez CEO

Telegram: Proposal Card
┌──────────────────────────────────────┐
│ Improvement Proposal                  │
│                                       │
│ Child: citadel-v2                     │
│ Skill: code-review                    │
│ Reason: low success rate (72%)        │
│ Feedback: 👍 4 / 👎 6                │
│                                       │
│ Related learnings:                    │
│   • Always use t-call for i18n        │
│                                       │
│ [✅ Approve]  [❌ Reject]             │
└──────────────────────────────────────┘

Zatwierdź: Backup skill.md → skill.v1.md (maks. 3 wersje). Oznacz jako zatwierdzone.
Odrzuć: Oznacz jako odrzucone w proposals.json. Brak zmian.

Kluczowe Decyzje Projektowe

Propozycje szablonowe: AI nie generuje ulepszeń. System identyfikuje problem; człowiek decyduje o rozwiązaniu.
CEO w pętli: Bez autonomicznego przepisywania skilli. Wymagane jedno zatwierdzenie.
Wersjonowanie skilli: Backupy zapobiegają utracie danych. Maksymalnie 3 wersje per skill.
Minimalna próbka: Skille z mniej niż 3 użyciami są wykluczone z analizy (unikanie fałszywych pozytywów).

Odniesienie projektowe: Karpathy AutoResearch Loop — modyfikuj → weryfikuj → zachowaj/odrzuć → powtarzaj. Z kluczowym dodatkiem ludzkiego zatwierdzenia.

Jak 4 Filary Działają Razem

Day 1:
  CEO sends message → Context Router suggests relevant skills
  Claude responds → Evals check output → Warning: "No force push"
  CEO sees warning, presses Fix It → Learning saved to learnings.md

Day 2:
  CEO sends similar message → Learnings injected: "Don't use --force"
  Claude avoids the mistake → No eval warnings → thumbs-up
  Quality metrics improve for that skill

Day 30:
  Nightly loop detects git-manager skill has 95% success rate
  No proposal needed — skill is healthy

Day 30 (different skill):
  Nightly loop detects code-review at 68% success
  Sends proposal to CEO → CEO approves → skill backed up
  CEO manually improves skill.md
  Next cycle: success rate climbs

System tworzy pętlę pozytywnego sprzężenia zwrotnego: korekty stają się trwałymi regułami → reguły poprawiają jakość → metryki odzwierciedlają poprawę → nocna pętla potwierdza zdrowie.

Filar 5: Sage Worker (Phase 40.11+)

Co robi: Analiza skilli wspomagana przez AI, benchmarking i odkrywanie marketplace.

Dlaczego: Ręczne ulepszanie skilli nie skaluje się. Potrzeba zautomatyzowanej analizy jakości skilli i dostępu do wiedzy społeczności.

Jak:

Analiza Skilli

Wybierz dowolny skill w UI Skill Evolution → kliknij "Sage Analyze" → Sage (Claude Haiku) ocenia:

Przejrzystość i kompletność instrukcji skilla
Pokrycie regułami eval
Rekomendacje ulepszeń

Benchmarki A/B

Porównaj dwie wersje skilla:

Wybierz aktualizację skilla (PR)
Uruchom benchmark → Sage testuje obie wersje na przykładowych promptach
Wyniki pokazują porównanie jakości z podsumowaniem

Odkrywanie Marketplace

Przeszukaj claudemarketplaces.com w poszukiwaniu skilli tworzonych przez społeczność:

"Sage Scout" → wyszukaj po słowie kluczowym
Analizuj kompatybilność ze swoim projektem
Zainstaluj globalnie lub sforkuj do konkretnego projektu

Odniesienie projektowe: Menedżery pakietów (npm, pip) dla zarządzania skillami AI, z analizą kompatybilności opartą na LLM.