Playbook · doorwerken zonder Claude

AI-Failover Playbook (provider/model)

Versie 1 · 2026-06-15. Aanvulling op FAILOVER-PLAYBOOK.md (die dekt machine-failover). Dit document dekt het scenario dat Claude/Anthropic zelf onbereikbaar is (geo-blokkade buiten de VS, outage, account/billing), terwijl je Mac en data prima werken.

Eis

Lokaal op de Mac doorwerken met Codex (primair) of Gemini (secundair) als Claude wegvalt, met zoveel mogelijk gelijkwaardigheid: dezelfde kennis, dezelfde tools/MCP, dezelfde claude-mem-historie, dezelfde creds en bestanden. Een minder slim model is acceptabel; functionele gaten niet. Realistisch plafond ~95% (zie Grenzen).

Principe: 3 lagen gelijktrekken (niet het model, maar de lagen eronder)

  1. Harness — Codex CLI + Gemini CLI lokaal geïnstalleerd. ✓
  2. Toegang — dezelfde MCP-servers + Vaultwarden + filesystem + bash. MCP is de draagbare laag.
  3. Context — de canonieke kennis uit ~/.claude/CLAUDE.md + project-MEMORY.md + claude-mem.

Bron van waarheid: ~/.claude/CLAUDE.md (kennis) en ~/.claude.json (MCP-servers). Codex/Gemini wijzen daarnaar; de Claude-setup wordt nooit gewijzigd, alleen gelezen.

Wat er is ingericht (2026-06-15)

Activatie bij uitval

cd <projectmap>
codex          # of: gemini

Eerste prompt-advies: "Lees eerst de MEMORY.md + CLAUDE.md van dit project en bevraag claude-mem voor context."

Sync & drift-controle

bash ~/Documents/michelmedia/infra/failover-sync.sh (alleen rapporteren) of --apply (symlink/import herstellen). Draai dit na elke wijziging aan Claude's MCP-set en als onderdeel van de maandelijkse parity-check. Het script vergelijkt .claude.json met Codex/Gemini en valideert beide configs.

Eenmalig nog te doen (interactief)

Drill (per kwartaal, of nu als test)

Open codex in bv. ~/Documents/michelmedia en stel een paar controlevragen: 1. Kennis (test laag 3): "Wat is mijn KOR-cutoverdatum en wat is de Te Kloeze-deal?" → moet uit CLAUDE.md/memory komen. 2. Memory/MCP (test laag 2): een claude-mem zoekvraag over eerder werk. 3. Tool (test laag 2): een og-ops health-call of een Vaultwarden-lookup. Alles correct = failover gelijkwaardig.

Grenzen (eerlijk, de ~5%)

Onderhoud

Bij elke nieuwe MCP-server of grote CLAUDE.md-wijziging: niets extra's nodig voor kennis (symlink/import volgt vanzelf), wél failover-sync.sh draaien om MCP-parity te herstellen.

Testen (toegevoegd 30-07-2026)

Het plan is nu controleerbaar in plaats van een aanname. Draai op elke machine:

bash ~/.claude/failover/failover-test.sh          # alles
bash ~/.claude/failover/failover-test.sh --snel   # zonder trage netwerkchecks
bash ~/.claude/failover/failover-test.sh --json   # machineleesbaar

Alles read-only: er wordt niets gewijzigd, verzonden of verwijderd. De Telegram-check gebruikt getMe en stuurt dus géén bericht.

Per regel komt er WERKT, FAALT, HANDMATIG of OVERGESLAGEN uit, met bij een probleem het commando om het te herstellen. Exit 0 betekent: alles wat automatisch te testen valt werkt.

Het script staat bewust in ~/.claude/failover/, want die map gaat via Syncthing naar alle drie de Macs. Zo is het noodplan er nog als juist de M5 wegvalt. Bron blijft ~/Documents/michelmedia/infra/, en de site is infra.vakwark.ai.

Uitslag, 30-07-2026

Machine WERKT FAALT HANDMATIG
M5 22 0 0
M4 22 0 0
Mac mini 22 0 0

Onderweg gerepareerd: mb/mb-stand naar M4 en mini, bw-unlock en mail-lees.py naar de mini, de Vaultwarden-sleutel in de Keychain van M4 en mini, de server-URL van de mini (die stond nergens op en zou dus bij bitwarden.com aankloppen in plaats van bij je eigen Vaultwarden), en de geauthenticeerde bw-staat van M4 naar de mini gekopieerd omdat een verse bw login daar een 404 gaf.

Twee dingen om te onthouden

1. Draai de test op de machine zelf, niet via ssh

De macOS-Keychain hangt aan de grafische sessie. Vanuit een ssh-sessie weigert macOS élke toegang met "User interaction is not allowed", ook lezen, ook als alles correct staat. De test meldde daardoor eerst ten onrechte FAALT op Vaultwarden. Dat is nu afgevangen: via ssh zegt hij HANDMATIG met de reden erbij, in plaats van vals alarm te slaan.

2. Je kunt tóch op afstand in de grafische sessie werken

Zolang je op die Mac grafisch ingelogd bent, kun je vanuit ssh een commando láten uitvoeren door Terminal in díe sessie, en dan is de Keychain wél open:

ssh macmini 'osascript -e "tell application \"Terminal\" to do script \"bash /tmp/klus.sh; exit\""'

Zo is de Keychain-sleutel op beide machines gezet zonder dat er iemand naartoe hoefde. Zet het commando in een script met umask 077 en ruim het daarna op, dan blijft er niets in de scrollback van het Terminal-venster staan.

Kan de vervanger het werk ook echt DOEN? (toegevoegd 30-07-2026)

failover-test.sh toetst of de deuren open staan. Dat is niet hetzelfde als of een vervanger het werk kan doen. Daarvoor is er een tweede script:

bash ~/.claude/failover/failover-ai-test.sh            # alle harnassen
bash ~/.claude/failover/failover-ai-test.sh codex grok # alleen deze
bash ~/.claude/failover/failover-ai-test.sh --lijst    # wat is beschikbaar

Het meet eerst zelf de waarheid (aantal observaties, worker-poort, hostnaam van de M4), geeft daarna elk harnas dezelfde drie opdrachten en vergelijkt de antwoorden. Een model dat niets kan uitvoeren of een getal verzint, valt hier door de mand. Alles read-only.

De drie proeven: iets uitvoeren (tel rijen in de SQLite-database), bij configuratie komen (lees de worker-poort uit settings.json), en een andere machine bereiken (ssh naar de M4 en de hostnaam ophalen).

Uitslag 30-07-2026

Harnas Score Oordeel
codex 3/3 primaire vervanger. 7-10s per opdracht
grok 3/3 gelijkwaardig alternatief, even snel
opencode 2/3 kan het, maar weigert in niet-interactieve modus een tool-aanroep ("user rejected permission"). Vraagt eenmalige permissie-configuratie
gemini 0/3 onbruikbaar: geen auth ingesteld. Geen GEMINI_API_KEY in de omgeving, niet in infra.md, niet in Vaultwarden

Dit corrigeert het plan hierboven. Gemini stond genoemd als secundaire vervanger maar is nooit bruikbaar geweest. Grok deed het meteen en stond er niet in. De volgorde is dus: Codex primair, Grok secundair, opencode als derde na een permissie-fix. Gemini pas meetellen als er een sleutel is.

Aanroepen per harnas (niet-interactief)

Harnas Commando
codex codex exec --skip-git-repo-check --sandbox danger-full-access "<opdracht>"
grok grok -p "<opdracht>"
opencode opencode run "<opdracht>"
gemini gemini -p "<opdracht>"

Codex weigert zonder --skip-git-repo-check buiten een git-repo, en zonder een sandbox-vlag mag hij niets uitvoeren.

Over OpenRouter en losse API-sleutels

OpenRouter levert modellen, geen harnas. Een model zonder harnas kan niets uitvoeren, niet bij je bestanden en niet bij je machines. Voor failover telt dus het harnas, niet het model. OpenRouter is nuttig als je binnen een bestaand harnas een ander model wilt gebruiken, niet als vervanger op zichzelf.