▸  ←/→ navigate · P present · N notes · ESC overview · Cmd+P export PDF
FAST CAMPUS · CASE STUDY CHAPTER 04
OMX HARNESS ANALYSIS

oh-my-codex / OmX
런타임이 소유하는 진실, 그리고 그 경계

OmX는 Codex CLI 위의 workflow layer이면서, dispatch·worker·goal 상태를 event로 소유하는 런타임 코어를 가진다. 관찰 목표는 둘이다 — 어떤 claim이 LLM 판단 없이 런타임 로그로 검증되는가, 그리고 어디서 멈추는가.

Source: github.com/Yeachan-Heo/oh-my-codex · read-only observation · 2026-06-03
4-4 · 프로젝트 2 및 케이스 스터디 event-sourcing · evidence-grounded verify · 5장 연결
CLAIM
vs LOG
OMX CASE STUDY01 / 10
OMX HARNESS ANALYSIS POSITIONING

OmX를 무엇으로 볼 것인가

IS

런타임이 상태를 소유하는 사례

  • Codex CLI 위에 얹는 workflow layer이면서, dispatch·worker·authority를 event로 소유하는 Rust 코어가 있다.
  • delivered·integrated 같은 operation claim은 LLM이 아니라 런타임 상태가 판정한다.
  • goal 완료 claim을 hash로 frozen 상태에 묶는 append-only ledger가 있다.
IS NOT

복제할 도구도, 빈 껍데기도 아님

  • 특정 런타임을 정답으로 두지 않고, 설치·실행·성능을 주장하지 않는다.
  • "OmX엔 event store가 없다"는 틀렸다 — 두 고도에서 이미 event를 소유한다.
  • 다만 log를 replay해 claim을 재도출하는 일은 OmX 밖이다. 그건 5장 Ouroboros.
READ-ONLY LENS02 / 10
OMX HARNESS ANALYSIS WHAT OMX ACTUALLY IS

OmX의 실제 구조 — 세 층

L1 · WORKFLOW

Node.js 패키지

npm i -g oh-my-codex + omx setup. role keyword·skills·$deep-interview → $ralplan → $ultragoal 흐름을 얹는다. CLI/JSON이 canonical control plane, MCP는 옵션.

L2 · RUNTIME

Rust crates

omx-runtime-core가 dispatch·authority·worker 상태를 event로 소유한다. omx-mux는 tmux 전송. 상태 권위는 여기 있다.

L3 · ENGINE

Codex CLI

실제 실행은 Codex가 한다 — OmX가 대체하지 않는다. 별도 prerequisite. OmX는 그 위에서 역할·상태·검수를 조직한다.

workflow는 Node, 상태 권위는 Rust, 실행 엔진은 Codex — 세 층이 나뉘어 있다.

THREE LAYERS03 / 10
OMX HARNESS ANALYSIS RUNTIME CORE

omx-runtime-core — command이 event가 되고, event가 진실이 된다

command은 상태기계가 합법 전이로 받아들일 때만 event가 된다. 그래서 결과를 지어낼 수 없다 — event가 있다는 건 전이가 실제로 일어났다는 뜻이다. snapshot은 event_log를 replay해 재구성하므로 같은 log면 같은 상태다.
OMX runtime core — command → event → log → snapshot → replay COMMAND queue-dispatch · mark-delivered RUNTIMEENGINE state machine 합법 전이일 때만 통과 불법 전이 → InvalidTransition (거부) RUNTIMEEVENT dispatch-delivered worker.recovered EVENT_LOG Vec<RuntimeEvent> in-memory append SNAPSHOT backlog · authority readiness (파생) PERSIST() events.json + snapshot.json file lock · 통째 rewrite (file-append 아님) LOAD() = REPLAY replay_event 로 상태 재구성 같은 log → 동일 snapshot (round-trip 검증) dispatch lifecycle: pending → notified → delivered | failed · readiness는 Rust 소유 진실에서 파생 한계: compact()가 종결 dispatch event를 지운다 → 현재 상태엔 결정적 replay, 영구 불변 audit ledger는 아님

claim-vs-log: delivered는 의견이 아니라 합법 전이가 남긴 event다.

EVENT-SOURCED RUNTIME04 / 10
OMX HARNESS ANALYSIS TWO ALTITUDES

event를 소유하는 두 고도

항목operational · omx-runtime-coregoal ledger · .gjc/ultragoal
무엇을 소유dispatch · authority · worker 상태기계목표 lifecycle + completionVerification
로그event_log → events.json + snapshot.jsonledger.jsonl (append-only)
결정성replay로 현재 snapshot 재구성hash로 claim을 frozen 상태에 binding
검증되는 claimdelivered · integrated · 누가 lease 소유"goal complete"가 이 quality-gate·snapshot에 묶임
한계compact()가 종결 event 삭제 → 불변 아님테스트 재실행 X · log replay로 재도출 X
OPERATIONAL · GOAL05 / 10
OMX HARNESS ANALYSIS VERIFY = EVIDENCE

검수는 LLM 판단이 아니라 evidence에 묶인다

PLANNER · ask

성공 기준을 먼저

outcome-first 계획 — success criteria, validation path, stop condition을 정한다.

EXECUTOR · build

증거를 남긴다

edit-test-verify 후 무엇이 바뀌었는지 + validation evidence를 보고한다. chat-only 상태는 인정하지 않는다.

VERIFIER · review

claim을 증거로 검사

claim → 가장 작은 검증 → 출력 확인 → 증거. 각 claim이 검증 command나 명시적 proof gap으로 추적된다.

quality-gate-g001: APPROVE + blockers 0 + npm run build · node --test 844/844 · 'integrated'는 git reachability(leader HEAD 도달)로 판정 — 의견 아님.

PLANNER · EXECUTOR · VERIFIER06 / 10
OMX HARNESS ANALYSIS C3 CONTROL · STATUS

제어와 상태 표면 — 그리고 그 한계

HOOKS

native + fallback

Codex native hook이 있으면 쓰고, 없으면 tmux/runtime fallback. .omx/hooks/*.mjs 플러그인은 정규화된 envelope(source: native|derived)를 쓴다.

DELIVERY

전송은 확인된다

omx-mux가 pane tail을 잡아 DeliveryConfirmation(Confirmed / Unconfirmed)을 낸다. 키 입력이 닿았는지를 확인하지, 작업이 끝났는지는 아니다.

HUD STATE

가변 JSON의 projection

HUD는 session-scoped .omx/state/*.json을 읽는다. 상태마다 권위 owner가 하나, 나머지는 derivative evidence.

상태가 가변·세션 한정이라 split-brain을 막는 reconciliation 계획이 따로 있다 — 즉 불변 event log의 projection은 아니다.

STATUS → ROUTE + STATE07 / 10
OMX HARNESS ANALYSIS BRIDGE TO CHAPTER 05

OmX는 claim을 묶고, Ouroboros는 claim을 재도출한다

OMX · 4장

claim을 binding

  • operation claim(delivered·integrated)은 합법 전이·git reachability로 결정적 검증.
  • goal 완료 claim은 hash-bound ledger가 frozen 상태에 묶는다.
  • 한계: 테스트를 재실행하지 않고, log를 replay해 상태를 재도출하지 않는다.
OUROBOROS · 5장

claim을 re-derive

  • EventStore → EvidenceManifest → TraceGuard(rlm_forge) deliver gate.
  • AC claim이 admissible typed evidence를 인용했는지 구조적으로 검사 — self-report 대체.
  • log가 source of truth라, replay로 결과를 다시 도출한다 + capability graph.
BIND vs RE-DERIVE08 / 10
OMX HARNESS ANALYSIS CAPABILITY MAP

관찰 결과를 4장 산출물로

OmX 관찰 렌즈역할4장 산출물 / 5장으로 넘길 것
role keyword · skills작업 호출 단위와 역할별 책임4-1 ask / build / review protocol
planner·executor·verifierevidence-grounded 검수 분업4-3 review gate (단 결정론은 아님)
omx-runtime-coredispatch·worker 상태를 event로 소유4-4 graph의 node·guard·route 근거
.gjc/ultragoal ledgerclaim을 hash로 binding5장 event store · replay · TraceGuard의 입력
CAPABILITY MAP09 / 10
OMX HARNESS ANALYSIS NEXT
TAKEAWAY

런타임이 어디까지 진실을 소유하나

OmX는 복제할 도구가 아니라, 어떤 claim이 LLM 판단 없이 런타임 로그로 검증되는지 보는 사례다. claim을 묶는 hash-bound ledger까지가 OmX(4장), claim을 replay로 재도출하는 event store가 Ouroboros(5장)다.

Next · 5장 Ouroboros TraceGuard EventStore · EvidenceManifest · capability graph
BIND
RE-DERIVE
END10 / 10