open-multi-agent-kit 0.80.2 → 0.80.4

package/docs/adr/0001-no-native-rust-lane.md

@@ -1,52 +0,0 @@
-# ADR-0001: No native Rust lane for omk-safety
-
-Status: Accepted
-Date: 2026-06-10
-
-## Context
-
-`crates/omk-safety` was scaffolded as a future native lane for safety hot paths
-(redact_stream / sanitize_env / check_path_policy). Remediation item A4 required either
-building it into a measured, shippable lane or killing it with evidence.
-
-## Decision
-
-Remove the Rust surface. Keep TypeScript as the only implementation.
-
-## Evidence (measured, not estimated)
-
-| candidate | p (wall fraction, representative run) | Amdahl ceiling 1/(1−p) | gate (≥1.15) | capability gate |
-|---|---|---|---|---|
-| redact_stream | 0.297% | 1.0030 | FAIL (unreachable even at s=∞) | FAIL — TS hot lane already 65–428 MB/s; 0.26–0.70 ms per 64 KiB ≤ 2 ms budget |
-| sanitize_env | 0.018% | 1.0002 | FAIL | FAIL — cold path, once per spawn |
-| check_path_policy | <0.06% (below sampler resolution) | ≈1.0000 | FAIL | FAIL — realpath syscall-bound |
-
-s (local Rust speedup) was not measured: with all ceilings < 1.004, no finite or infinite
-s can satisfy the gate; building napi bindings to measure it cannot change the outcome.
-
-Profiles, throughput benches, and analysis: `proof/rust-lane-2026-06-10/`.
-
-## Removal scope (larger than "delete crates/" — wired surfaces)
-
-- `crates/`, root `Cargo.toml`, `Cargo.lock` (no rust-toolchain.toml exists)
-- package.json: `rust:build`, `native:build`, and `native:build` steps inside
-  `release:check`, `release:full`, `release:rc`; `native:no-kimi:turn` reference check
-- `scripts/build-native.mjs`, `scripts/rust-safety-check.mjs`,
-  `scripts/normalize-native-artifacts.mjs`, native branch of `scripts/package-audit.mjs`
-- `src/util/native-safety.ts` + doctor lane report (`src/commands/doctor/checks.ts:253,358`)
-- CI: rust/cargo steps in `.github/workflows/{ci,release,smoke-test}.yml`
-- README/CHANGELOG native-lane claims; SECURITY.md stays unchanged (it never claimed
-  native sandboxing — verify on execution)
-
-## What we keep instead (TS follow-ups carrying the real value)
-
-1. Fix O(matches × n) `SecretScanner.getLineColumn` (secret-scanner.ts:729) — measured
-   3 404 ms/call at 1 MiB match-heavy input vs 11.7 ms clean.
-2. Enforce `writableRoots` (src/runtime/sandbox-profile.ts:13) in tool dispatch — currently
-   declared but never consulted against any path.
-3. Deduplicate child-env sanitizer clones (kimi runner ↔ adapter).
-
-## Consequences
-
-- No supply-chain surface from prebuilds; `--ignore-scripts` installs remain trivially safe.
-- A future native lane proposal must re-run this gate with new measured p.

package/docs/algorithm-hardening-playbook.md

@@ -1,219 +0,0 @@
-# OMK Algorithm Hardening Playbook
-
-> How to evolve OMK's runtime algorithms safely, contract-first, and with evidence.
-
-## 1. Principles
-
-### 1.1 Change contracts before code
-
-When hardening an algorithm, start with:
-
-1. Type/interface changes (e.g., `AgentTask.safety`, `RuntimeHealthVectorV2`).
-2. Unit tests that express the new contract in isolation.
-3. Adapter updates to satisfy the compiler.
-4. Integration tests.
-5. Documentation updates.
-
-This order catches contract violations at compile time rather than at runtime.
-
-### 1.2 Declare, observe, then verify
-
-For evidence gates:
-
-- **Declare**: node/task says what evidence kinds are required.
-- **Observe**: after execution, extract actual observations from stdout, metadata, artifacts.
-- **Verify**: compare observations against declarations.
-
-A declaration is never proof.
-
-### 1.3 Runtime-mode authority
-
-Authority is not provider identity. It is `(provider, runtimeMode)`:
-
-```text
-kimi:api   → read, review (advisory)
-kimi:cli   → read, write, patch, shell, merge, review (authority)
-deepseek:api → read, review (advisory)
-codex:cli  → read, plan, review (advisory unless explicit policy)
-```
-
-Any code path that selects a runtime must consult this matrix.
-
-### 1.4 Fail-closed defaults
-
-- Unknown health → route with penalty or block.
-- Missing evidence → exit 78.
-- Advisory runtime asked to write/shell/merge → exit 78.
-- Low-confidence risk → downgrade to `ask`.
-
-### 1.5 Preserve backward compatibility
-
-- Do not remove old fields until the full phase is released.
-- Use optional/new fields first, then deprecate.
-- Keep existing smoke tests passing.
-
-## 2. Step-by-step hardening loop
-
-### Step 0 — Isolate the concern
-
-Pick one algorithm concern per phase:
-
-- evidence semantics
-- health probes
-- authority matrix
-- prompt privacy
-- audit graph
-
-Do not mix two concerns in one diff.
-
-### Step 1 — Specify the contract
-
-Write the LaTeX/TypeScript contract first. Example:
-
-```ts
-// Before changing implementations, add the new contract.
-export interface AgentTaskSafety {
-  readonly risk: string;
-  readonly approvalPolicy: string;
-  readonly sandboxMode: string;
-  readonly evidenceRequired: boolean;
-  readonly authorityMode: string;
-}
-```
-
-### Step 2 — Add isolated tests
-
-Create a new test file that fails before implementation:
-
-```text
-test/evidence-v2-declared-vs-observed.test.mjs
-test/health-vector-tri-state.test.mjs
-test/authority-matrix-kimi-api-advisory.test.mjs
-```
-
-### Step 3 — Implement behind a flag when possible
-
-For large changes, use an environment flag:
-
-```ts
-const evidenceModelV2 = process.env.OMK_EVIDENCE_MODEL === "v2";
-```
-
-This lets you merge incrementally without breaking existing paths.
-
-### Step 4 — Update adapters incrementally
-
-For each runtime adapter:
-
-1. Make it compile with the new contract.
-2. Add a focused test for that adapter.
-3. Move to the next adapter.
-
-### Step 5 — Integrate and remove flag
-
-Once all adapters and tests pass:
-
-1. Default the flag to the new behavior.
-2. Add a revert path.
-3. Run full quality gates.
-
-### Step 6 — Document and release-gate
-
-- Update `docs/provider-maturity.md`, `docs/native-root-runtime-hardening.md`.
-- Add the new behavior to `release:check` or a dedicated smoke script.
-- Update `CHANGELOG.md`.
-
-## 3. Parallel subagent orchestration
-
-When spawning parallel workers (when the tool is available):
-
-### 3.1 Decompose by concern, not by file
-
-Each worker owns one concern end-to-end:
-
-- evidence worker: contract + tests + runtime-backed + DAG executor
-- health worker: vector v2 + adapters + scoring
-- authority worker: matrix + resolver + docs + smoke
-
-### 3.2 Grant least privilege
-
-| Worker | Authority | Allowed paths | Blocked paths |
-|--------|-----------|---------------|---------------|
-| evidence | write-scoped | `src/runtime/contracts/evidence.ts`, `src/runtime/runtime-backed-task-runner.ts`, `src/orchestration/executor.ts`, `test/evidence-*.mjs` | secrets, env files |
-| health | write-scoped | `src/runtime/contracts/shared.ts`, `src/runtime/runtime-router.ts`, `src/runtime/*-runtime.ts`, `test/health-*.mjs` | secrets, env files |
-| authority | write-scoped | `src/runtime/authority-matrix.ts`, `src/runtime/runtime-bootstrap.ts`, `src/runtime/runtime-router.ts`, `docs/provider-maturity.md`, `test/authority-*.mjs` | secrets, env files |
-
-### 3.3 Shared read-only reviewers
-
-Run reviewer/QA/security lanes in parallel after implementation lanes:
-
-- `omk-reviewer`: diff review, type safety
-- `omk-tester`: test matrix, release gate
-- `omk-security`: secret exposure, authority boundary
-
-### 3.4 Synthesis gate
-
-Do not merge until:
-
-1. Every lane produced evidence.
-2. `npm run check` passes.
-3. `npm run release:check` passes.
-4. New negative tests pass.
-5. Documentation is updated.
-
-## 4. Regression prevention
-
-### 4.1 Test hierarchy
-
-1. **Contract tests**: pure functions, no IO.
-2. **Adapter tests**: runtime mocks, no live provider calls.
-3. **Integration tests**: local CLI with `--dry-run`.
-4. **Smoke tests**: real provider only in CI with ephemeral keys.
-
-### 4.2 Required negative tests
-
-For every new gate, add a negative test:
-
-- Evidence declared but not observed → blocked.
-- Health fail → runtime excluded or penalized.
-- Advisory runtime asked for write → exit 78.
-- Private prompt leaked to public node → redaction/failure.
-
-### 4.3 Durable checkpoints
-
-Before each phase:
-
-```bash
-git branch phase-<N>-<concern>
-npm run check
-npm run test
-```
-
-After each phase:
-
-```bash
-npm run check
-npm run release:check
-git commit -m "feat(<concern>): <phase N> hardening"
-```
-
-## 5. When to stop
-
-Stop a phase and ask for guidance when:
-
-- A contract change would break public CLI behavior.
-- A runtime adapter cannot satisfy the new contract without a large refactor.
-- `npm run check` fails and the fix is not local.
-- A lane would need to write files outside its granted scope.
-
-## 6. Checklist
-
-- [ ] Contract specified in TypeScript/LaTeX
-- [ ] Isolated failing tests added
-- [ ] Implementation behind flag or in isolated file
-- [ ] All adapters updated incrementally
-- [ ] Negative tests added
-- [ ] Documentation updated
-- [ ] Quality gates pass
-- [ ] Evidence artifacts recorded
-- [ ] Result artifact written

package/docs/benchmark-design.md

@@ -1,122 +0,0 @@
-# OMK Control Plane Replay Benchmark Design
-
-## 1. Purpose
-
-Design a reproducible benchmark suite that measures OMK control plane
-performance across 10 representative task categories. The benchmark runs in
-**shadow mode** (recorded traces, no live LLM calls) for baseline
-reproducibility, with optional **live-evaluation mode** for regression
-testing against real providers.
-
-## 2. Task Categories
-
-| # | Category | Intent | Description |
-|---|----------|--------|-------------|
-| 1 | read-only repo Q&A | research | Agent answers questions about codebase structure |
-| 2 | small bug fix | debugging | Single-file typo / logic fix |
-| 3 | failing test repair | debugging | Update implementation to satisfy failing test |
-| 4 | multi-file refactor | refactor | Rename/move symbols across 3+ files |
-| 5 | CLI command task | shell-operation | Execute and verify CLI output |
-| 6 | dependency update | coding | Bump package version, fix breaking changes |
-| 7 | merge-conflict task | merge | Resolve git merge conflict automatically |
-| 8 | security-sensitive task | review | Patch vulnerability with audit trail |
-| 9 | provider failure fallback | debugging | Primary provider fails; fallback succeeds |
-| 10 | quota/auth failure fallback | debugging | Quota/auth error triggers provider switch |
-
-## 3. Metrics
-
-| Metric | Definition | Source |
-|--------|-----------|--------|
-| solve_rate | passed_tasks / total_tasks | harness result |
-| evidence_trust_score | ETS v2 score per task | evidence-trust-score engine |
-| false_done_rate | tasks claiming success with failing evidence / total | harness+ETS |
-| fallback_success_rate | fallback attempts that succeed / total fallback attempts | router decision trace |
-| router_regret | best_available_runtime_score − selected_runtime_score | shadow-mode diff |
-| cost_per_solved_task | Σ costUsdEstimated / solved_count | attempt records |
-| p95_latency | 95th percentile of task latencyMs | attempt records |
-| rollback_rate | tasks rolled back / total tasks | decision trace |
-| sandbox_violation_count | tasks with unexpected file writes outside worktree | sandbox audit |
-
-**router_regret** is computed in shadow mode by scoring all candidates for
-every decision and comparing the selected runtime’s composite against the
-maximum composite.
-
-## 4. Reproducibility Contract
-
-Every benchmark run must pin:
-- **treeHash**: git commit SHA of the repo under test
-- **seed**: PRNG seed for synthetic fixture generation
-- **providerConfigHash**: hash of the runtime provider configuration
-- **omkVersion**: package version
-- **benchmarkSchemaVersion**: `omk.benchmark.v1`
-
-Shadow-mode runs use pre-recorded `BenchmarkTrace` fixtures (see
-`src/benchmark/fixtures.ts`). Live-evaluation mode records new traces into
-`.omk/benchmarks/<runId>/`.
-
-## 5. Shadow Mode
-
-Shadow mode runs router v1 and v2 side-by-side on identical inputs:
-1. Load a `BenchmarkTask` fixture.
-2. Run `createRuntimeRouter` (v1) and `createRouterV2ScoringEngine` (v2).
-3. Record both decisions into `ShadowModeRecord`.
-4. Compute `router_regret` for each.
-5. Diff v1/v2 selections and log disagreements.
-
-No LLM API calls are made. Runtime `runNode` is replaced with a stub that
-returns the recorded outcome from the fixture.
-
-## 6. Benchmark Harness Lifecycle
-
-```
-loadConfig() → discoverTasks() → for each task:
-  setupWorktree() → runTask() → evaluateEvidence() → teardown()
-→ computeSummary() → writeJsonReport()
-```
-
-The harness integrates with `scripts/run-tests.mjs` via:
-```bash
-node scripts/run-benchmark.mjs --shadow --summary-json .omk/benchmarks/latest.json
-```
-
-## 7. CI Integration
-
-A new `benchmark` job runs after `fast-gate` passes on `main` branch merges
-and nightly cron. It:
-1. Checks out the repo at the merge commit.
-2. Runs `npm run benchmark:shadow`.
-3. Uploads `.omk/benchmarks/latest.json` as artifact.
-4. Fails if `solve_rate < 0.85` or `false_done_rate > 0.05`.
-
-## 8. Directory Layout
-
-```
-src/benchmark/
-  contracts.ts      # BenchmarkTask, BenchmarkResult, BenchmarkSummary
-  harness.ts        # runBenchmarkSuite(), runBenchmarkTask()
-  shadow-mode.ts    # ShadowModeEngine, computeRouterRegret()
-  fixtures.ts       # generateSyntheticTraces(), loadRecordedTraces()
-scripts/
-  run-benchmark.mjs # CLI entrypoint
-test/
-  benchmark-harness.test.mjs
-.omk/benchmarks/
-  sample-run.json   # example output
-```
-
-## 9. Extending the Benchmark
-
-To add a new task category:
-1. Add intent mapping in `src/benchmark/fixtures.ts`.
-2. Create a fixture under `test/benchmark-fixtures/`.
-3. Add an evaluation rule in `src/benchmark/harness.ts`.
-4. Register the category in `scripts/run-benchmark.mjs`.
-
-## 10. Risks & Mitigations
-
-| Risk | Mitigation |
-|------|-----------|
-| Fixture drift (codebase changes) | Pin treeHash; auto-regenerate fixtures in CI if drift detected |
-| Shadow mode not representative of live behavior | Weekly live-evaluation job with small sample |
-| Metrics gaming (fake evidence) | ETS v2 gaming penalty + runner-source requirement |
-| Secret leakage in recorded traces | Redact with `redactTrace()` before persistence |

package/docs/claims.md

@@ -1,85 +0,0 @@
-# OMK claims and evidence
-
-This document lists what OMK claims, the current status, and how to verify it. Claims are scoped to the exact adapter, command, and gate that produced them.
-
-## Claim: OMK creates replayable run artifacts
-
-Status: implemented.
-
-Evidence:
-- `.omk/runs/<run-id>/input-envelope.json`
-- `.omk/runs/<run-id>/dag.json`
-- `.omk/runs/<run-id>/dag-compile-report.json`
-- loop artifacts on execution: `loop-state.json`, `loop-decisions.jsonl`
-
-Verification:
-```bash
-omk do "review this repo for release risk" --dry-run --json
-omk runs
-```
-
-## Claim: OMK can run without Kimi
-
-Status: implemented and tested.
-
-Evidence:
-- package name `open-multi-agent-kit`, binary `omk`
-- no-Kimi runtime routing and smoke paths
-
-Verification:
-```bash
-npm run verify:no-kimi
-```
-
-## Claim: OMK blocks completion when required evidence is missing
-
-Status: implemented.
-
-Evidence:
-- evidence-block proof bundle `proof/verified-runs/006-evidence-block/proof-bundle.json`
-
-Verification:
-```bash
-npm run proof:check
-```
-
-## Claim: OMK scopes provider authority by task
-
-Status: implemented at the routing/contract level; enforcement depends on the adapter path.
-
-Evidence:
-- read/write/shell/merge authority metadata in task contracts
-- [provider maturity](provider-maturity.md)
-
-Verification:
-```bash
-omk provider list
-omk do "explain this repo" --dry-run --json
-```
-
-## Claim: OMK provides OS-level sandboxing
-
-Status: not claimed. Child-env hardening and approval gates exist; OS-level sandboxing is planned.
-
-Evidence:
-- [SECURITY.md](../SECURITY.md)
-
-## Claim: OMK is a stable 1.x release
-
-Status: not claimed. Current source version is `0.80.2` (`pre-1.0`); `v1.2` is a runtime contract family.
-
-Evidence:
-- [versioning](versioning.md)
-- release truthfulness proof `proof/verified-runs/012-release-truthfulness/proof-bundle.json`
-
-Verification:
-```bash
-npm run version:check
-npm run proof:check
-```
-
-## Related
-
-- [What is OMK?](what-is-omk.md)
-- [Proof index](https://github.com/dmae97/open-multi-agent-kit/blob/main/proof/PROOF_INDEX.md)
-- [Provider maturity](provider-maturity.md)

package/docs/cli-v2-migration.md

@@ -1,87 +0,0 @@
-# CLI v2 Migration Guide
-
-## Overview
-
-OMK CLI v2 migrates from Commander.js to Clipanion + Clack for a modern CLI experience matching opencode-style terminal UX.
-
-## Enabling CLI v2
-
-```bash
-OMK_CLI_V2=1 omk <command>
-```
-
-## Migrated Commands
-
-### Core Commands (cli-v2-skeleton.ts)
-| Command | Clipanion Class | Status |
-|---------|----------------|--------|
-| `omk chat` | ChatCommand | ✅ |
-| `omk run` | RunCommand | ✅ |
-| `omk status` | StatusCommand | ✅ |
-| `omk model` | ModelCommand | ✅ |
-| `omk doctor` | DoctorCommand | ✅ |
-| `omk memory` | MemoryCommand | ✅ |
-| `omk theme` | ThemeCommand | ✅ |
-
-### Provider Commands (provider-commands.ts)
-| Command | Clipanion Class | Status |
-|---------|----------------|--------|
-| `omk provider list` | ProviderListCommand | ✅ |
-| `omk provider use` | ProviderUseCommand | ✅ |
-| `omk provider set` | ProviderSetCommand | ✅ |
-| `omk provider enable` | ProviderEnableCommand | ✅ |
-| `omk provider disable` | ProviderDisableCommand | ✅ |
-| `omk provider doctor` | ProviderDoctorCommand | ✅ |
-| `omk provider profiles` | ProviderProfilesCommand | ✅ |
-| `omk model list` | ModelListCommand | ✅ |
-| `omk model aliases` | ModelAliasesCommand | ✅ |
-| `omk model resolve` | ModelResolveCommand | ✅ |
-| `omk model use` | ModelUseCommand | ✅ |
-
-### Workflow Commands (workflow-commands.ts)
-| Command | Clipanion Class | Status |
-|---------|----------------|--------|
-| `omk plan` | PlanCommand | ✅ |
-| `omk feature` | FeatureCommand | ✅ |
-| `omk bugfix` | BugfixCommand | ✅ |
-| `omk refactor` | RefactorCommand | ✅ |
-| `omk review` | ReviewCommand | ✅ |
-| `omk team` | TeamCommand | ✅ |
-| `omk orchestrate` | OrchestrateCommand | ✅ |
-| `omk consent` | ConsentCommand | ✅ |
-
-## Architecture
-
-All CLI v2 commands route through the full runtime pipeline:
-
-```
-User Input → Clipanion CLI → OmkCommand.executePipeline()
-  → CommandBus → IntentClassifier → CapabilitySelector
-  → RuntimeSidecar → OutputRouter → ThemeRenderer/NlpRenderer/JsonRenderer
-```
-
-## Key Files
-
-- `src/cli/v2/cli-v2-skeleton.ts`: Core commands + createCliV2()
-- `src/cli/v2/provider-commands.ts`: Provider + Model commands
-- `src/cli/v2/workflow-commands.ts`: Workflow + Consent commands
-- `src/cli/v2/chat-repl.ts`: Interactive REPL
-- `src/cli/v2/interactive-prompt.ts`: Clack prompts
-- `src/cli/v2/persistent-memory.ts`: Memory store
-- `src/cli/main.ts`: CLI v2 routing (isCliV2Enabled())
-
-## UI/UX Style
-
-CLI v2 uses opencode-style terminal output:
-- `> provider · model` one-line header
-- Spinner animation during processing
-- Compact error display with box drawing
-- Status bar at bottom
-- Bilingual (KO/EN) via i18n
-
-## Testing
-
-```bash
-node --test test/cli-v2-gating.test.mjs  # 7 tests
-node --test test/v2-regression.test.mjs   # 10 tests
-```

package/docs/codex-oauth-setup.md

@@ -1,62 +0,0 @@
-# Codex app / OAuth setup
-
-OMK uses the official Codex app/CLI for Codex authentication. OMK does not store Codex login data, read `~/.codex/auth.json`, or print OAuth/session tokens.
-
-## Recommended flow
-
-1. Install or expose the official Codex CLI/app on `PATH`.
-   ```bash
-   codex --version
-   ```
-2. Complete the official Codex OAuth login.
-   ```bash
-   codex login
-   ```
-3. Ask OMK to guide or run the official login flow.
-   ```bash
-   omk codex auth --choice plus-pro --run
-   omk provider doctor codex --soft
-   ```
-4. Import only safe Codex MCP server configuration when needed.
-   ```bash
-   omk mcp import-codex
-   ```
-
-## Policy
-
-- OMK project configuration lives under `.omk/`.
-- Codex-specific login state remains owned by the official Codex app/CLI.
-- OMK may inspect Codex MCP server configuration, but secret-bearing `headers`, `env`, bearer values, and token files are not copied into project MCP config.
-- Do not `cat` token/session files or paste OAuth values into logs.
-
-## OpenAI Images API is separate
-
-Codex/ChatGPT OAuth proves the Codex CLI login state only. It is not an OpenAI Platform API key.
-
-`omk image generate` and `omk image edit`, including `--model gpt-image-2`, require a separate OpenAI Platform project API key supplied only at runtime.
-
-```bash
-OPENAI_API_KEY=<platform-project-key> omk image generate "OMK control-plane hero" --model gpt-image-2
-```
-
-You can also run the guided key setup instead of exporting the variable manually:
-
-```bash
-omk openai setup
-```
-
-Do not store the API key in project files; prefer environment variables or a user-local secret store.
-
-See [`openai-platform-image-keys.md`](openai-platform-image-keys.md) for the one-shot key flow.
-
-## Troubleshooting
-
-- If `codex` is not found, install the official Codex CLI/app or add it to `PATH`.
-- If login status is unclear, run `codex login`, then `omk provider doctor codex --soft`.
-- If MCP import finds nothing, check whether your Codex config has importable MCP servers.
-
-## Security principles
-
-- Never print token/session files.
-- OMK never reuses Codex OAuth values as OpenAI API bearer keys.
-- In shared environments, keep per-provider authentication and project configuration separate.

package/docs/comparisons/omk-vs-claude-code.md

@@ -1,31 +0,0 @@
-# OMK vs Claude Code
-
-## Short answer
-
-Claude Code is a coding agent. OMK is a control plane that can run Claude Code as one provider lane with scoped authority, DAG orchestration, evidence gates, and replayable artifacts.
-
-## Category difference
-
-- **Claude Code**: executes coding tasks as a single-agent assistant.
-- **OMK**: routes tasks across providers, scopes read/write/shell/merge authority, requires evidence before completion, and records replayable run artifacts.
-
-## When to use which
-
-- Use Claude Code when you want a direct coding assistant.
-- Use OMK when you want multi-provider routing, per-task authority, and verifiable completion across agents in the same repository.
-
-## How they work together
-
-Claude Code can act as a coding agent surface inside an OMK lane while OMK keeps routing, authority, and evidence explicit.
-
-```bash
-omk do "review this repo for release risk" --dry-run --json
-```
-
-See [evidence-gated coding agents](../use-cases/evidence-gated-coding-agents.md).
-
-## Related
-
-- [What is OMK?](../what-is-omk.md)
-- [OMK vs Codex](omk-vs-codex.md)
-- [OMK vs OpenCode](omk-vs-opencode.md)

package/docs/comparisons/omk-vs-codex.md

@@ -1,33 +0,0 @@
-# OMK vs Codex
-
-## Short answer
-
-Codex is a coding agent. OMK is a control plane that can run Codex as one provider lane with scoped authority, DAG orchestration, evidence gates, and replayable artifacts.
-
-## Category difference
-
-- **Codex**: executes coding tasks through the official Codex app/CLI.
-- **OMK**: routes tasks across providers, scopes read/write/shell/merge authority, requires evidence before completion, and records replayable run artifacts.
-
-## When to use which
-
-- Use Codex when you want a direct coding assistant.
-- Use OMK when you want to route across providers, restrict authority per task, and require evidence before marking work complete.
-
-## How they work together
-
-OMK delegates Codex auth to the official Codex app/CLI and never reads or prints `~/.codex/auth.json` tokens.
-
-```bash
-codex login
-omk codex auth --choice plus-pro --run
-omk provider doctor codex --soft
-```
-
-See [Codex OAuth setup](../codex-oauth-setup.md) and [provider routing](../use-cases/provider-routing-for-ai-coding.md).
-
-## Related
-
-- [What is OMK?](../what-is-omk.md)
-- [OMK vs OpenCode](omk-vs-opencode.md)
-- [OMK vs Claude Code](omk-vs-claude-code.md)