Egzekwowanie Reguł
Mechaniczne egzekwowanie, które zamienia pisane reguły w gwarantowane zachowania.
Ostatnia aktualizacja: Marzec 2026
Dlaczego pisane reguły nie wystarczą
Napisałem 14 reguł dla mojego systemu AI. Przestrzegał dokładnie zera z nich konsekwentnie — dopóki nie dodałem hooków egzekwujących. Nie dlatego, że AI się buntowało, ale dlatego, że kontekst się zapełnia, instrukcje są kompresowane i AI dryfuje od swoich ograniczeń. Pisane reguły to życzenia. Egzekwowane reguły to rzeczywistość. Genesis Framework rozwiązuje to skryptami Python zwanymi hookami, które uruchamiają się przed lub po każdym wywołaniu narzędzia.
Jak działają hooki
Claude Code obsługuje hook events — skrypty Python, które uruchamiają się w konkretnych punktach workflow. Te hooki mogą sprawdzać, zatwierdzać lub blokować akcje.
- 1PreToolUse: Uruchamia się PRZED użyciem narzędzia. Może zablokować akcję.
- 2PostToolUse: Uruchamia się PO zakończeniu narzędzia. Może zwalidować output.
- 3SubagentStop: Uruchamia się gdy agent kończy. Może sprawdzić jakość outputu.
Rejestrowanie hooków
Hooki rejestruje się w ustawieniach Claude Code. Oto jak dodać hook do pliku settings.json.
{
"hooks": {
"PreToolUse": [
{
"matcher": "Write|Edit",
"hooks": [
{
"type": "command",
"command": "python3 ~/.claude/hooks/file-guard.py"
}
]
}
],
"PostToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "python3 ~/.claude/hooks/verify-output.py"
}
]
}
]
}
}Przykład: Guard dostępu do plików
Ten hook blokuje zapisy plików, dopóki nie istnieje odpowiedni lockfile. Wymusza wzorzec, że tylko autoryzowani agenci mogą modyfikować pliki.
#!/usr/bin/env python3
"""
File Guard Hook — blocks Write/Edit unless a lockfile is active.
Enforces: Only authorized agents can modify files.
"""
import sys
import os
import json
def main():
# Read tool input from stdin
data = json.load(sys.stdin)
tool_name = data.get("tool_name", "")
# Check if any agent lockfile exists
lockfiles = [
"/tmp/.file-executor-active",
"/tmp/.web-developer-active",
"/tmp/.code-debugger-active",
]
has_lockfile = any(os.path.exists(f) for f in lockfiles)
if not has_lockfile:
# Block the action
result = {
"decision": "block",
"reason": "No agent lockfile found. File operations require an active agent."
}
print(json.dumps(result))
sys.exit(0)
# Allow the action
result = {"decision": "approve"}
print(json.dumps(result))
if __name__ == "__main__":
main()Protokół lockfile
Protokół lockfile jest prosty: agenci tworzą lockfile gdy zaczynają pracę i usuwają go gdy kończą. Hooki sprawdzają te lockfile'e przed zezwoleniem na chronione operacje.
# Agent startup
touch /tmp/.file-executor-active
# ... agent does its work ...
# Agent cleanup
rm /tmp/.file-executor-activeHooki egzekwujące współpracują z regułami z Rozdziału 4: System Reguł i protokołami z Rozdziału 5: Protokoły. Każdy hook egzekwuje konkretne reguły mechanicznie — tabela routingu, ograniczenia agentów i protokół lockfile stają się zweryfikowanymi zachowaniami zamiast pisanymi sugestiami.
Wzorzec bramki QA
Po każdej istotnej implementacji uruchom agenta weryfikacji QA. Bramka QA ma domyślną postawę WYMAGA PRACY — oznacza PASS tylko z konkretnymi dowodami. Zapobiega to zatwierdzeniom w stylu 'wygląda dobrze'.
Bramka QA używa ustrukturyzowanego formatu FAIL, żeby deweloperzy dokładnie wiedzieli, co naprawić.
## Structured FAIL Format (Every failure must include ALL fields)
| Field | Description |
|-------------------|------------------------------------------------|
| Issue | Specific problem (not vague "doesn't work") |
| Severity | Critical / Major / Minor |
| Location | File path + line number |
| Fix Instructions | Specific steps to resolve |
| Expected Outcome | What success looks like after fix |
| Retry Count | Which attempt (1/3, 2/3, 3/3) |
## 3-Strike Escalation
| Attempt | Action |
|---------|------------------------------------------------|
| FAIL 1 | Structured feedback -> developer fixes -> retry |
| FAIL 2 | Structured feedback + pattern analysis -> retry |
| FAIL 3 | ESCALATE to human with root cause hypothesis |Proaktywne wyzwalacze — akcje bez promptu
Niektórzy agenci powinni uruchamiać się bez proszenia. Te proaktywne wyzwalacze gwarantują, że krytyczne kroki nigdy nie zostaną pominięte.
| Situation | Auto-Trigger Agent |
|------------------------------|---------------------------|
| Before git push | Security scanner |
| Morning greeting | Chief of staff |
| Creating new tool/agent | Registry check first |
| Before any implementation | Cartographer (blueprint) |
| After any implementation | Cartographer (document) |
| Photo/image request | Check existing templates |
| Student name mentioned | Load student profile |
To implement: add detection logic in your hooks that
identifies these situations and injects reminders into
the AI's context.Scoring pewności — kwantyfikacja niepewności
Agenci strategiczni powinni kwantyfikować, jak pewni są swoich rekomendacji. Zapobiega to nadmiernie pewnym radom AI i podkreśla obszary wymagające ludzkiej weryfikacji.
When an agent provides strategic recommendations,
require a confidence breakdown:
| Recommendation | Confidence | Rationale |
|-------------------------|------------|--------------------|
| Use React for frontend | 0.95 | Industry standard |
| Redis for caching | 0.80 | Good fit, untested |
| Custom auth solution | 0.45 | Complex, risky |
Flag items below 0.6 with a warning for human review.
Agents that should score confidence:
- Implementation planners
- Researchers
- Debuggers (hypothesis ranking)
- Strategy agentsBaza wiedzy (Rozdział 7: Baza Wiedzy) przechwytuje wzorce egzekwowania jako wielokrotnego użytku skille. Gdy odkryjesz nowy tryb awarii, pętla samodoskonalenia ekstrahuje go do pliku skill, żeby ten sam błąd był łapany automatycznie następnym razem.