Kihagyás

Multi-layer safety-gate playbook#

Magas-kockázatú feature-ekhez (RSI, auto-prompt-evolution, code-self-modification, auto-promotion) 4 független védelmi réteg kell. Egyetlen réteg sem elég — egymást validálják ("defense in depth").

A 4 réteg#

1. ENV-flag default-disabled#

A feature default-on NEM fut. Csak explicit <FEATURE>_MODE=enabled ENV-flag-gel aktiválódik.

# Default — minden RSI-script exit-el:
vault-skill-suggest                # ⚠️ safety-gate exit

# Explicit enable:
RSI_MODE=enabled vault-skill-suggest --analyze-last 30

Miért: Operator-friction kell az aktiváláshoz. Senki sem futtat véletlenül RSI_MODE=enabled-et — szándékos kell legyen.

2. Script-szintű safety-gate (első sor)#

Minden script első dolga ellenőrizni a flag-et + abortolni ha disabled. NEM lehet middleware vagy később-check — az első instruction:

def safety_gate():
    if os.environ.get("RSI_MODE", "disabled") != "enabled":
        print("⚠️  RSI safety-gate: disabled by default.", file=sys.stderr)
        print("    Enable with: RSI_MODE=enabled <script> ...")
        print("    PRECONDITION: <list of stability checks>")
        sys.exit(2)

def main():
    safety_gate()           # ← MINDEN script első hívása
    # ... actual logic

Miért: Még import-error vagy unexpected-state esetén sem fut a logic.

3. Git pre-commit hook — forbidden-target blokk#

A high-risk feature kimenete (kód-mutation, prompt-átírás, skill-modify) csak sandbox-branchen engedélyezett. Main-ra direkt commit BLOKKOLT.

# .git/hooks/pre-commit (symlink-elve a .vault-<feature>/safety/-ból)
FORBIDDEN_PATTERNS=("AGENTS.md" "00-Meta/" ".vault-<feature>/" "11.11")
BRANCH=$(git rev-parse --abbrev-ref HEAD)

if [[ "$BRANCH" =~ ^rsi-(sandbox|pareto)- ]]; then
  exit 0   # sandbox branchen OK
fi

STAGED=$(git diff --cached --name-only)
for pattern in "${FORBIDDEN_PATTERNS[@]}"; do
  if echo "$STAGED" | grep -qE "$pattern"; then
    echo "🚫 BLOCKED: forbidden-target on non-sandbox branch"
    exit 1
  fi
done

Override csak emergency-re: SKIP_RSI_HOOK=1 git commit ... — explicit, naplózott.

Miért: Még ha a script-szintű gate-et valaki bypass-olja, a git-szint elkapja a side-effect-et a vault-history-ban.

4. Critic-review-mandatory (B-6 reuse)#

Minden RSI/high-risk output MCP-mutation-call ELŐTT Critic-agent review-jén megy keresztül (Constitutional AI 2 minta). Confidence < 0.85 → batch-preview a user-nek.

# .vault-tools/config/skill-search.yml
mcp_server:
  write_tools:
    - vault.add_skill
    - vault.update_wiki_section
    - vault.add_decision
    - vault.crystallize_learning
  critic_review_required: write_tools

Miért: Még ha az RSI mutáció jól-formatú, a Critic szemantikai-szinten elkapja (PII-leak, ADR-konfliktus, reverziós tendencia).

Mikor használd#

Feature-típus 4-rétegű gate szükséges?
RSI (kód/prompt/skill auto-mutáció) ✅ MIND a 4
Auto-promotion (Auto-reflections → 11-wiki/) ✅ MIND a 4
Code self-modification (Gödel Agent) ✅ MIND a 4 — még Critic-multi-pass is
Auto-skill-suggest user-confirmáció nélkül ✅ MIND a 4
Új skill registration ❌ 1+2 elég (gate + script-check)
Auto-wiki-edit feature ✅ 1+2+4 (Critic kell)
Read-only auto-eval (B-3 L1 parser) ❌ Egyik sem kell — no side-effect

Ökölszabály: ha a feature vault-állapotot mutál és emberi review nélkül futna, MIND a 4 réteg kötelező.

Backout — auto-disable triggerek#

A 4 rétegen felül: minden high-risk feature-nek passzív backout-trigger-je kell, ami magától kapcsolja ki ha romlik valami:

auto_disable_triggers:
  - "vault_corruption_detected"           # vault-cleanup audit drop >20% in 1 day
  - "critic_reject_rate_above_30pct"      # B-6 Critic 30%+ reject → output rossz
  - "user_manual_disable_request"         # /11.11 emergency stop
  - "eval_quality_drop_below_threshold"   # B-3 Pass-rate <70% in 1 week

A trigger érintése NEM vissza-engedélyezi a feature-t magától — manual user-action kell az újraaktiváláshoz.

Élő példa — B-8 RSI (2026-05-13 Day 0)#

Az első projekt, ami a 4-rétegű gate-et kombinálja:

Réteg Hol implementálva Mit véd
1. ENV-flag RSI_MODE=disabled default Default-off
2. Script-gate .vault-rsi/scripts/*.py első sora safety_gate() Véletlen-futtatás
3. Git-hook .vault-rsi/safety/git-pre-commit-hook.sh Forbidden-target commit
4. Critic-review .vault-rsi/config/rsi-config.yml: critic_review_required Szemantikai rossz output

Plus 4 auto-disable trigger. Részletek: .vault-rsi/README.md + 02-Projects/superintelligent-vault.

Új minta-realizáció: flock-mutex + atomic-write komplementer (2026-05-19)#

A 4-rétegű safety-gate infrastruktúra-szintű analógja kialakult a Layer-1 vault-atomic projekt során:

Layer Védi Mechanizmus Pattern
Cross-process race két cron egyszerre indul → git-state ütközés flock -n mutex vault-cron-flock wrapper, 14 cron
Same-process partial-write cron SIGKILL mid-write → félig-írt fájl os.replace POSIX atomic vault_atomic.py modul, 15 site
Process-restart dedup daemon restart → state-loss external store (Redis/SQLite) heavyweight write-volume-ra
Audit trail "mi történt" debug append-only JSONL minden write-site

Kulcs-tanulság: egyik réteg sem helyettesíti a másikat. A flock cross-process race-t old, atomic-write same-process partial-write-ot. Mindkettő szükséges.

Reusable szabály: új mutáló-script ELŐTT mind a 4-réteget végig kell gondolni (write race / partial-write / restart-dedup / audit-trail).

2026-05-19 — Mega-session apply-discipline validation#

A 7-órás 2026-05-19-obsidian-vault mega-session 19 új CLI-t vezetett be a vault-on, és csak 1 valódi data-mutation történt az egész session alatt (SCD2 migration). Mind a 19 új script:

  • Dry-run default — --apply flag KÖTELEZŐ a side-effect-hez
  • Double-gated apply — --apply flag + VAULT_<X>_APPLY=1 env-var
  • Forbidden-target list — AGENTS.md / 00-Meta/ / .vault-* / 11.11* sosem mutálható
  • Audit-log append atomic_append_jsonl-pattern-nel minden write után

Konkrét példák a session-ből: - vault-sleep-consolidate — VAULT_SLEEP_APPLY=1 && --apply - vault-browser-history-ingest — VAULT_BROWSER_INGEST_APPLY=1 && --apply - vault-nb-ingest — VAULT_NB_INGEST_APPLY=1 && --apply - vault-entity-link — VAULT_ENTITY_LINK_APPLY=1 && --apply - vault-ko-belief — VAULT_BELIEF_APPLY=1 && --apply - vault-ko-schema-evolve — VAULT_SCHEMA_APPLY=1 && --apply

Wider lesson: skeleton-first apply-gate discipline teszi lehetővé hogy egy 7-órás "keep going" session-ben 19 idea-CLI biztonságosan ship-eljen anélkül hogy a vault-ot risk-eled. Az ELLENPÉLDA: ha egy script default-on mutál a vault-ban, akkor minden round-ban "csináld meg mindent" command-ot tudatosan re-evaluate-elni kell. A skeleton-first → "go" command explicit-és-szándékos, NEM accidental side-effect.

2026-05-20 — Sandbox-branch subset for DB-write sprints#

A 4-rétegű safety-gate high-risk RSI / auto-mutate workflow-ra van. DB-write-only sprint-ekre (KO-DB ingest, Memgraph push) egy kisebb subset is elég, mert a "veszély" adat-szennyezés, NEM kód-mutáció.

Sandbox-branch subset pattern:

  1. git checkout -b <sprint>-sandbox — minden DB-write művelet sandbox-branchen él. Main marad tiszta.
  2. DB-backup file <db>.pre-<sprint>-<date>.bak — single-shot revert garancia.
  3. Process-ready idempotency — minden DB-write művelet repeatable (SCD2 + UNIQUE(hash) verified 0 collision).
  4. Per-batch measurement + user-decision-checkpoint — minden 20-30% progress után.
  5. git merge --no-ff to main csak miután final-measurement bizonyítja az acceptance criteria-t.

Élő példa — 2026-05-20 Tier-1 backfill 171/171: treesitter-prepass-sandbox branch, 2 DB-backup, 11 process-ready cycle (0 collision), 2 checkpoint, merge 27e5e21 csak miután FCA 0.93 + XR_T1 1.0 + XR_T2 0.90 verified.

Wider lesson: match the gate to the risk profile. RSI/auto-mutate → full 4-layer. DB-write-only → sandbox + backup + idempotent + checkpoint elég. Code-only-change → simple PR review.

Layer-0 chained guards pattern (2026-05-21)#

A bmad-vault-bridge --apply safety-gate-en TÚL (ami csak CRYSTALLIZE_APPLYING=1 módban fut), egy új réteg landolt: Layer 0 always-on chained guards — minden commit-on fut, file-pattern-trigger-rel.

A minta#

A fő pre-commit hook (.vault-ko/safety/git-pre-commit-hook.sh) tetején, MINDEN egyéb gate ELŐTT:

# Layer 0 — always-on chained guards (run regardless of crystallize mode)
PLUGIN_HOOKS_WATCH="$(git rev-parse --show-toplevel)/.git/hooks/pre-commit-plugin-hooks-watch.sh"
if [[ -x "$PLUGIN_HOOKS_WATCH" ]]; then
  if ! bash "$PLUGIN_HOOKS_WATCH"; then
    exit $?
  fi
fi

A chained guard maga self-decides hogy fire-ol vagy nem, a staging-listán lévő file-pattern-ek alapján. Ha nincs releváns staging → exit 0 (no-op). Ha van → futtatja a megfelelő audit-CLI-t --strict módban.

Trigger-pattern + audit párosítások#

Staged file pattern Audit CLI Block ha
*hooks.json, .claude/*, .codex/*, .gemini/*, */settings.json vault-plugin-hooks-audit --strict HIGH-heat instruction-injection pattern (lásd claude-code-harness-blocks § 7)
*.mcp.json, */mcp.json vault-mcp-audit --strict HIGH-heat MCP risk-vector (shell-exec / non-HTTPS / literal-cred — lásd mcp-server-safety-classification)
*.sql, migrate-*.py vault-schema-migration-victim-audit --strict New schema-change ADR + unpatched downstream-callers

Miért külön réteg#

A Layer 0 szándékosan always-on és crystallize-mode-független:

  • A Layer 3 forbidden-target deny-list csak CRYSTALLIZE_APPLYING=1-nél fut (intentional — human edits + autosave NE legyenek blokkolva)
  • A Layer 0 viszont bármilyen commit-on fut — kézi git commit, autosave-cron, pre-commit-from-other-script. Akkor is, ha NEM crystallize-flow van.
  • A trigger maga file-pattern-trigger, NEM env-var-trigger — így nem lehet "kifelejteni" beállítani egy env-var-t és bypass-elni.

Hozzáadás új audit-tengelyhez#

A chain lineárisan skálázódik. Új audit-class hozzáadása:

  1. Hozz létre vault-<class>-audit CLI-t --strict flag-gel
  2. Egészítsd ki a pre-commit-plugin-hooks-watch.sh-t egy új if [[ TRIGGER_<class> ... ]] then ... fi blokkal
  3. Trigger-pattern: a class-specifikus file-glob
  4. Override env-var: SKIP_<CLASS>_AUDIT=1 git commit ... (emergency-only, audit-trail via shell history)

A pattern jelenleg hooks.json + .mcp.json triggert kezel; várakozó class-ok: *.sql schema-changes, Dockerfile permission-changes, requirements.txt package-pin-changes.

Audit-cron alá-rétegként#

Minden Layer-0 guard mögött áll egy heti audit-cron ami a teljes vault-on (NEM csak a staged-on) fut és 06-Audits/<class>-audit-YYYY-WNN.md baseline-t ír. A Layer-0 a "don't add new HIGH-heat" gate, a heti cron a "no HIGH-heat in production" monitor. Két különböző use-case, ugyanaz a CLI hajtja meg mindkettőt.

Kapcsolódó#