Enforcement capability ledger: paritet mellan motorer, inte en Claude-hook-spegel

När du jobbar i Codex eller Gemini beter sig agenten annorlunda och mindre säkert. Inte för att reglerna saknas, utan för att den inte vet vilka skydd Claude får mekaniskt. Fixen är en kanonisk ledger nycklad på risk-intent: per skydd, vad varje motor faktiskt kan upprätthålla, och var den failar open.

En kanonisk enforcement-ledger som ger varje motor paritet via medvetenhet, inte via samma mekanik. Den är klar när:

• varje policy (risk-intent) har en enforcement-grad per motor (Claude, Codex, Gemini), plus fail-läge och ett testfall
• en agent mitt i en Codex- eller Gemini-session kan slå upp ett symptom, hitta policyn, och se sin motors grad plus vad den ska självupprätthålla
• adaptrarnas felaktiga "inga hooks i denna motor" är ersatt av faktiska grader
• gotcha-loggen matar ledgern: 2+ incidenter formaliseras till en rad eller ett hook
• en riktig Codex-session har självupprätthållit ett skydd ur ledgern, med bevis

I scope: ledger-strukturen, nyckling på risk-intent, per-motor-grader för de hårdaste skydden, fail-läge-dimensionen, gotcha-konvergensen, render-modellen, adapter-rättningen.

Uttryckligt uppskjutet: full population av alla 16 policyer gånger 3 motorer med källverifierad grad per rad (görs fas för fas), och faktisk auto-installation av genererade hooks (gated, senare beslut).

Codex bias-checken rev upp antagandet, verifierat mot primärkällor: både Codex CLI (developers.openai.com/codex/hooks) och Gemini CLI (geminicli.com/docs/hooks) har hook-system. Men de är olika starka, och båda failar open. Codex PreToolUse är uttryckligen "a guardrail rather than a complete enforcement boundary" (fångar inte alla shell-vägar, ej-stödda fält gör att tool-call fortsätter). Gemini defaultar till "Allow" om hookens stdout inte är ren JSON. Gemini har äkta hard block på BeforeTool; Codex har en native approval gate (PermissionRequest) som Gemini saknar. Slutsats: paritet byggs inte genom att spegla Claudes 32 hooks, utan genom en ledger som per skydd säger vad varje motor faktiskt klarar, och var den brister.

Grader: hard = deterministisk blockering. guardrail = soft, kan kringgås eller failar open. gate = approval allow/deny. text = bara medvetenhet. saknas = ingen mekanism. Fullständig population av alla 16 policyer sker fas för fas med källkoll per rad.

# policies/enforcement-ledger.md, en rad per risk-intent
| risk-intent | claude | codex | gemini | fail | test | symptom |
| filradering | hard (PreToolUse Bash) | guardrail* | hard (BeforeTool) | open | probe-rm | "den raderade en fil" |
# *guardrail: Codex fangar bara enkla shell-anrop, ej unified_exec/ekvivalent vag
# sekundarindex: symptom -> rad. gotcha-logg matar nya rader vid 2+.

Marginalnot: graderna kommer ur den verifierade kapabilitets-workflowen (Codex-doc + Gemini-doc, adversariellt granskad). Tre grader flaggades osäkra och källverifieras vid population.

1. Bygg ledger-skelettet + MAP-trigger (fas A)
2. Populera de hårdaste skydden först (secret, radering, em-dash, publikt repo) med källverifierad grad per rad
3. Rätta adaptrarna (fas B)
4. Koppla gotcha-loggen, seed HG-001 och HG-002 (fas C)
5. Kör validation/probes per policy per motor som gate
6. Först när bevisad: render per-motor-vyer, och senare (gated) self-bootstrap

Inte bara att ledgern finns: en riktig Codex-session ges ett symptom (t.ex. "den var på väg att radera en fil"), slår upp policyn, läser sin grad och självupprätthåller med bevis. Plus validation/probes som kör ett testfall per policy per motor och rapporterar grad-utfallet mot ledgern, så drift och overclaim syns mekaniskt.