oh-my-forge

English | 한국어

oh-my-forge

Every time an agent makes a mistake, change the system so that mistake cannot structurally happen again.

A customized Claude Code harness built on everything-claude-code. The core addition: an ontology-driven structural error prevention system that makes agent failures self-correcting at the harness level.

---

Why

everything-claude-code is a production-ready performance optimization system for AI agent harnesses — skills, instincts, memory persistence, continuous learning, and cross-harness compatibility (Claude Code, Codex, Cowork).

oh-my-forge keeps all of that and adds two things on top:

1. Ontology-driven structural error prevention

When an agent makes a mistake, the default response is to patch the prompt. That's fragile — the same mistake resurfaces in a new session with a fresh context. oh-my-forge treats mistakes as system signals: each error is classified, routed, and converted into a structural change (a new constraint in the ontology, or a failure instinct in the learning pipeline) so the same failure cannot happen again.

2. Ontology as a GPS for implementation

Claude Code plans. The ontology index (index.json) acts as a coordinate map — Claude reads only the domain index and one spec doc (~3K tokens) instead of exploring the full source tree, then generates a structured BRIEF. Implementation is handled by whichever engine is available:

• Codex — if the codex CLI is installed (/codex-delegate)
• Claude — automatic fallback when Codex is not installed (/claude-implement)

No configuration needed. The engine is auto-detected at plan time.

Three principles:

1. Structural prevention over prompt patching — if a mistake can happen twice, the system is wrong, not the prompt
2. Ontology + harness co-design — constraints, file coordinates, and specs are defined together
3. Every session teaches the system — learning is automatic, not manual

---

Core Systems

1. Ontology (/.claude/ontology/)

The central knowledge graph. Maps logical domains to their files, constraints, and feature specs.

"domain_hooks": {
  "files": ["hooks/hooks.json", "scripts/hooks/..."],
  "spec": "docs/features/hooks.md",
  "constraints": [
    "블로킹 훅(PreToolUse, Stop)은 200ms 이하 — 네트워크 호출 금지",
    "신규 훅은 run-with-flags.js 래퍼를 통해서만 등록"
  ],
  "riskLevel": "high",
  "codexWorkerHint": "workspace-write"
}

Each domain_* entry defines:

• files — which files belong to this domain
• spec — the feature doc agents read to understand intent
• constraints — rules agents must follow, with optional machine-checkable patterns (|pattern:keyword)
• codexWorkerHint — "read-only" or "workspace-write", tells Codex what role to take
• riskLevel — "high" triggers stronger warnings from the constraint guard

Schema: /.claude/ontology/_schema.json validates every domain entry.

---

2. Implementation Delegation (/commands/codex-delegate.md, /commands/claude-implement.md)

The ontology index doubles as a GPS for implementation. Instead of giving the implementer the full source tree, Claude reads only index.json and the relevant spec doc (~3K tokens total), then generates a structured BRIEF.

/plan  →  auto-detects engine  →  /codex-delegate   (Codex CLI installed)
                                →  /claude-implement  (no Codex, Claude-only)

Both commands use the same BRIEF format and produce the same HANDOFF output — the engine is interchangeable. The /plan skill enforces Codex-first delegation and guards against silent fallback loops (fixed in v1.10.x).

Engine detection (first match wins):

1. CLAUDE_IMPL_ENGINE env var (claude or codex)
2. Project .claude/settings.json → implementationEngine
3. Global ~/.claude/settings.json → implementationEngine
4. Auto-detect: codex binary absent → "claude"
5. Default: "codex"

Project/global implementationEngine is operator configuration, not an in-session escape hatch. pre-write-edit-codex-guard pins the resolved engine per session and blocks direct .claude/settings.json engine flips unless ECC_BYPASS_CODEX_GUARD=1 is set explicitly.