open-multi-agent-kit 0.80.2 → 0.80.3

package/docs/comparisons/omk-vs-mcp-agent.md

@@ -1,33 +0,0 @@
-# OMK vs MCP agent frameworks
-
-## Short answer
-
-MCP agent frameworks give agents tool access through the Model Context Protocol. OMK adds task-level control on top: scoped MCP per lane, provider routing, evidence gates, and replayable artifacts.
-
-## Category difference
-
-- **MCP agent frameworks**: expose tools to an agent through MCP servers.
-- **OMK**: keeps MCP servers, skills, and hooks scoped per lane, routes providers, separates read/write/shell/merge authority, and requires evidence before completion.
-
-## When to use which
-
-- Use an MCP agent framework when you mainly need tool access for one agent.
-- Use OMK when you need bounded tool authority, multi-provider routing, and verifiable, replayable runs.
-
-## How they work together
-
-OMK consumes MCP servers as scoped capabilities per lane instead of importing every global server into every agent.
-
-```bash
-omk mcp list
-omk mcp doctor
-omk do "summarize open issues" --mcp-scope project --dry-run --json
-```
-
-See [scoped MCP for coding agents](../use-cases/scoped-mcp-for-coding-agents.md).
-
-## Related
-
-- [What is OMK?](../what-is-omk.md)
-- [OMK vs OpenCode](omk-vs-opencode.md)
-- [Provider routing for AI coding](../use-cases/provider-routing-for-ai-coding.md)

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

@@ -1,32 +0,0 @@
-# OMK vs OpenCode
-
-## Short answer
-
-OpenCode is a terminal coding agent. OMK is a control plane for running coding agents with scoped authority, DAG orchestration, evidence gates, and replayable artifacts.
-
-## Category difference
-
-- **OpenCode**: a direct coding loop in the terminal.
-- **OMK**: a layer around execution that routes providers, scopes authority, requires evidence, and saves replayable run artifacts.
-
-## When to use which
-
-- Use OpenCode when you want a direct coding assistant.
-- Use OMK when you want to route tasks across providers, restrict write or shell authority, and require evidence before marking work complete.
-
-## How they work together
-
-OpenCode/CommandCode can participate as a compatibility lane when the local CLI and auth are present.
-
-```bash
-omk provider list
-omk do "refactor the parser" --provider auto --dry-run --json
-```
-
-See [provider routing](../use-cases/provider-routing-for-ai-coding.md).
-
-## Related
-
-- [What is OMK?](../what-is-omk.md)
-- [OMK vs Codex](omk-vs-codex.md)
-- [OMK vs mcp-agent](omk-vs-mcp-agent.md)

package/docs/decision-layer-calibration.md

@@ -1,20 +0,0 @@
-# Decision-Layer Formalization And Calibration
-
-This note tracks the implementation of the June 11 decision-layer hardening spec.
-
-## Implemented
-
-- Route scoring source prior is now a strict tiebreaker: `project=0.02`, `builtin=0.01`, `global=0`.
-- Route scoring computes a base-score lattice gap and asserts `priorSpread < minBaseGap` at module load.
-- Route selection emits bounded `routeTrace` records with `baseScore`, `sourcePrior`, final `score`, features, and reason for benchmark replay.
-- Route calibration helpers implement simplex projection, structured perturbation candidates, smooth keyword saturation, and exact paired McNemar adoption.
-- Trust calibration helpers implement underpowered-data refusal, MAP-style logistic fitting with shrinkage to current checklist weights, AUC comparison, and threshold selection.
-- Ensemble decision can consume Hedge persona weights; the Hedge module updates online weights with an anti-collapse floor and collapse alert.
-- Provenance ratio helpers and `npm run provenance:ratio` report layer-wise originality against an upstream or merge-base fallback.
-- CI fast gate includes a new-file size guard for source/test/script files over 1,000 LoC.
-
-## Deferred
-
-- `git filter-repo --path proof/ --invert-paths` is destructive and requires explicit branch/tag/force-push scope confirmation before execution.
-- Trust and Hedge adoption should be persisted only after enough labeled runs exist (`n >= 100` for trust calibration).
-- Route calibration needs a benchmark suite with at least 50 paired tasks before changing production weights.

package/docs/decisions/2026-06-10-git-history-bloat.md

@@ -1,61 +0,0 @@
-# Decision: Git history bloat — defer rewrite, apply linguist-vendored interim
-
-- Date: 2026-06-10
-- Status: Accepted (interim mitigation only; rewrite deferred pending owner approval)
-
-## Problem
-
-The repository pack is far larger than the working tree:
-
-- `git count-objects -vH` → `size-pack: 80.19 MiB`
-- Tracked worktree content ≈ 27 MiB
-
-The gap is caused by large binary blobs (GIF/MP4/PNG/PPTX) committed and later
-replaced/removed, which remain in history forever.
-
-## Evidence: top-10 largest blobs
-
-Command:
-
-```bash
-git rev-list --objects --all \
-  | git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' \
-  | sort -k3 -rn | head -10
-```
-
-Output (2026-06-10):
-
-```text
-blob f2aa8c50905967a71bab34b5045406ed668b3a1c 29252458 readmeasset/kimicat.gif
-blob fee8957c9ff26f7243d375f919c6cba5fa53ca3d 18261906 readmeasset/oneprompt.mp4
-blob 8ff0eb7cc1fa08c49fe51ade9dc016fb81f31cd7 10528089 readmeasset/kimicat.gif
-blob c4fea42c159c57e82f64e274335b9829ea1e8dbe 7016890 readmeasset/oneprompt.gif
-blob e1aa1c049e1444d250da52202944d6f8ef1aed9f 3643625 EGG_PEAK_IR_Malgun_Gothic_FIXED_TRUE_ANIM.pptx
-blob f6097940de448e09de07e9b949f6caab13fec433 3041622 readmeasset/kimicat.mp4
-blob 5f671d8ac6c8a6011891164a0bdfa84ea7733749 2802989 readmeasset/kimicat.mp4
-blob 75169d7c30c48b552c621c2f23779d6354974e9f 1849634 kimichan.png
-blob 8edbf5a56bf456284bbd8fb5aa580245684d72e0 1708509 readmeasset/kimicat.png
-blob 13a70fc8e0a35e20c1967b0306b29540bfb75b88 1522325 readmeasset/kimicat.png
-```
-
-The top 4 blobs alone account for ~65 MB of the 80.19 MiB pack.
-
-## Decision
-
-1. **No history rewrite now.** A `git filter-repo` rewrite of the blobs above
-   would shrink the pack to roughly worktree scale, but it rewrites every
-   commit hash, **invalidates all existing clones, forks, and open PRs**, and
-   requires a coordinated force-push. Execute it ONLY with explicit owner
-   approval and a scheduled migration window.
-2. **Interim mitigation:** mark the intentionally hand-written template JS
-   under `templates/web-bridge/chrome-extension/**` as `linguist-vendored` in
-   `.gitattributes` so language stats and code-scanning surfaces stay clean.
-   `dist/` and `coverage/` remain git-ignored (already present in `.gitignore`).
-
-## Follow-up (requires owner approval)
-
-- `git filter-repo --strip-blobs-bigger-than 1M` (or an explicit path list for
-  `readmeasset/` historical media + the stray `.pptx`/`.png`), then force-push
-  and re-clone guidance for all contributors.
-- Move future README media to GitHub release assets or an external CDN instead
-  of committing binaries.

package/docs/decisions/ADR-theme-dark-only-assets.md

@@ -1,43 +0,0 @@
-# ADR: Dark-only README SVG assets derived from the night-city theme
-
-- Status: accepted
-- Date: 2026-06-10
-- Owners: OMK theme contract lane (T4)
-- Related: `themes/night-city.theme.json`, `scripts/assets-build.mjs`, `scripts/theme-check.mjs`, `proof/theme-2026-06-10/t1-t2-summary.md`
-
-## Context
-
-OMK ships a single `omk.theme.v1` theme — `night-city` (`mode: dark`) — as the source of
-truth for all branded surfaces. Every foreground/background pair in that theme is
-contrast-gated by `npm run theme:check` (text ≥ 4.5, indicator ≥ 3.0; 48 pairs, 0 failed),
-and the gate blocks merge in CI. The 5 README SVG assets
-(`readmeasset/omk-{badges,core-loop,evidence-ledger,logo-mark,provider-lanes}.svg`) are now
-derived from that theme's primitives by `npm run assets:build`, which embeds a
-`derived-from: omk.theme.v1/night-city@<hash>` provenance comment per SVG.
-
-A light variant of the assets was considered for GitHub light-mode READMEs. There is no
-light theme file, no light contrast matrix, and no reviewed light palette — generating one
-by naive color inversion would ship pairs that were never gated.
-
-## Decision
-
-Do **not** build a light variant. Assets are dark-only and derive exclusively from the
-single contrast-gated dark theme.
-
-`scripts/assets-build.mjs` enforces this: it refuses any theme with `mode` other than
-`dark` unless every foreground/background token pair actually used by the SVGs passes the
-same 4.5/3.0 WCAG gates inline (the same model `theme:check` applies). The inline gate
-also runs for dark themes, so a drifted primitive cannot silently ship an unreadable
-asset.
-
-## Consequences
-
-- README assets render correctly on dark backgrounds only; light-mode viewers see the
-  dark cards as framed panels (each SVG paints its own `dark` background rect, so nothing
-  becomes unreadable on a light page).
-- Introducing a light variant requires: a new `omk.theme.v1` theme file with
-  `mode: light`, a full `npm run theme:check` pass for that file, and only then will
-  `npm run assets:build --theme <file>` accept it (its inline used-pair gate must pass).
-- Theme color changes propagate to assets only via `npm run assets:build`; the
-  `@<hash>` provenance suffix makes a stale asset detectable against the current theme
-  file hash.

package/docs/demo/verified-run/README.md

@@ -1,32 +0,0 @@
-# Verified-run demo evidence skeleton
-
-Status: **skeleton only**. This bundle defines TODO/capture slots for a future verified run; it does not contain real proof yet.
-
-## Story
-
-One prompt -> Kimi edits -> OMK blocks premature done -> evidence passes -> cockpit/replay shows proof.
-
-## Bundle map
-
-| Path | Purpose | Status |
-| --- | --- | --- |
-| `raw-prompt.md` | Exact prompt for the capture run | Ready to copy |
-| `generated-diff.md` | Diff capture rules and placeholder metadata | TODO/capture slot |
-| `capture-plan.md` | Commands and paths for verify, cockpit, and replay proof | TODO/capture slots |
-| `video-shot-list.md` | 60-90s recording outline | Ready storyboard |
-| `artifacts/README.md` | Expected raw evidence filenames | TODO/capture slots |
-
-## Acceptance criteria for filling this bundle
-
-- Use a disposable branch or worktree.
-- Capture Kimi's generated diff before manual cleanup.
-- Capture the premature-done block exactly as emitted; if no block occurs, mark the demo failed.
-- Capture `omk verify --json` to the documented JSON path and validate it parses.
-- Capture cockpit and replay proof from the same run id.
-- Do not commit secrets, tokens, private paths requiring redaction, or fabricated outputs.
-
-## Known limitation
-
-This skeleton cannot prove the verified-run story by itself.
-It becomes demo evidence only after TODO slots are filled from a real local run
-with matching run id, timestamps, and captured artifacts.

package/docs/demo/verified-run/artifacts/README.md

@@ -1,18 +0,0 @@
-# Artifact capture slots
-
-This directory is intentionally empty of real proof until a verified demo run is captured.
-
-Expected future files:
-
-- `command-log.txt` — exact run command and environment notes, no secrets
-- `generated-diff.patch` — real Kimi-generated diff
-- `generated-diff.stat.txt` — diff summary
-- `premature-done-block.txt` — exact evidence-gate rejection excerpt
-- `verify-result.json` — real `omk verify --run "$RUN_ID" --json` output
-- `cockpit-proof.png` — screenshot for the same run id
-- `cockpit-proof.txt` — optional text copy of cockpit state
-- `replay-proof.txt` — `omk replay "$RUN_ID" --evidence --decisions` output
-- `replay-proof.png` — screenshot of replay proof
-- `verified-run-demo.mp4` — final 60-90s video
-
-Do not add fabricated sample outputs. Leave absent files absent until captured.

package/docs/demo/verified-run/capture-plan.md

@@ -1,51 +0,0 @@
-# Evidence capture plan
-
-Use one real `RUN_ID` for every artifact below.
-
-```bash
-RUN_ID=<capture-run-id>
-CAPTURE_ROOT=docs/demo/verified-run/artifacts
-mkdir -p "$CAPTURE_ROOT"
-```
-
-## 1. Prompt and command log
-
-- Prompt source: `docs/demo/verified-run/raw-prompt.md`
-- Capture slot: `artifacts/command-log.txt`
-- TODO: record the exact OMK/Kimi command used for the run.
-
-## 2. Premature-done block
-
-- Capture slot: `artifacts/premature-done-block.txt`
-- TODO: save the exact terminal excerpt where OMK rejects completion because evidence is missing.
-- Failure rule: if no block occurs, write `DEMO FAILED: no premature-done block captured` in the slot.
-
-## 3. Verify JSON
-
-```bash
-omk verify --run "$RUN_ID" --json > "$CAPTURE_ROOT/verify-result.json"
-node -e 'JSON.parse(require("fs").readFileSync(process.argv[1], "utf8")); console.log("json ok")' "$CAPTURE_ROOT/verify-result.json"
-```
-
-- Capture slot: `artifacts/verify-result.json`
-- TODO: capture only real command output.
-
-## 4. Cockpit proof
-
-```bash
-omk cockpit --run-id "$RUN_ID" --height 24 --no-clear
-```
-
-- Screenshot capture slot: `artifacts/cockpit-proof.png`
-- Optional text slot: `artifacts/cockpit-proof.txt`
-- TODO: capture the cockpit view showing run state, TODO/evidence status, and changed files.
-
-## 5. Replay proof
-
-```bash
-omk replay "$RUN_ID" --evidence --decisions > "$CAPTURE_ROOT/replay-proof.txt"
-```
-
-- Transcript slot: `artifacts/replay-proof.txt`
-- Screenshot capture slot: `artifacts/replay-proof.png`
-- TODO: capture replay output showing evidence/decision history for the same run.

package/docs/demo/verified-run/generated-diff.md

@@ -1,27 +0,0 @@
-# Generated diff capture slot
-
-Expected future file: `artifacts/generated-diff.patch`
-
-## Capture rules
-
-1. Run the raw prompt in a disposable branch/worktree.
-2. Before manual cleanup, save Kimi's generated diff:
-
-```bash
-git diff --binary > docs/demo/verified-run/artifacts/generated-diff.patch
-git diff --stat > docs/demo/verified-run/artifacts/generated-diff.stat.txt
-```
-
-3. If the diff contains secrets or private data, discard the run and recapture with a safe fixture. Do not hand-edit a proof patch.
-4. Record metadata only after the real patch exists.
-
-## Metadata placeholder
-
-| Field | Value |
-| --- | --- |
-| Run id | TODO: capture |
-| Branch/worktree | TODO: capture |
-| Diff path | `docs/demo/verified-run/artifacts/generated-diff.patch` |
-| Diff stat path | `docs/demo/verified-run/artifacts/generated-diff.stat.txt` |
-| SHA-256 | TODO: capture after file exists |
-| Capture time | TODO: capture |

package/docs/demo/verified-run/raw-prompt.md

@@ -1,21 +0,0 @@
-# Raw prompt for verified-run capture
-
-Copy the block below into the future OMK/Kimi capture session.
-Replace bracketed placeholders before running.
-Do not edit the captured transcript afterward.
-
-```txt
-Goal: Make one tiny, reviewable change in the disposable demo fixture so the run has a real diff and evidence.
-Scope/write ownership: [DEMO_FIXTURE_PATH] only.
-Story requirement: show that OMK does not accept premature completion before evidence exists.
-Then show the run passing after evidence is captured.
-Constraints: no secrets, no production files, no package metadata, no unrelated refactor, no fabricated outputs.
-Required evidence:
-1. generated diff from Kimi's edit
-2. terminal excerpt where premature done is blocked by OMK evidence gate
-3. `omk verify --run [RUN_ID] --json` result
-4. cockpit proof for `[RUN_ID]`
-5. replay proof for `[RUN_ID]` with evidence/decision details
-Stop condition: report done only after evidence exists and `omk verify --json` passes.
-If evidence is missing, leave TODO/capture slots open instead of claiming completion.
-```

package/docs/demo/verified-run/video-shot-list.md

@@ -1,14 +0,0 @@
-# 60-90s verified-run video shot list
-
-| Time | Shot | Proof point |
-| --- | --- | --- |
-| 0-8s | Title card and clean terminal | Demo states: one prompt to verified proof |
-| 8-18s | Paste `raw-prompt.md` into OMK/Kimi | Single prompt starts the run |
-| 18-30s | Show Kimi edit and `git diff --stat` | Real file change exists |
-| 30-42s | Show premature completion blocked | OMK refuses done before evidence |
-| 42-55s | Run `omk verify --run "$RUN_ID" --json` | Machine-readable evidence gate passes |
-| 55-70s | Show cockpit for the same run id | Operator can inspect status and changed files |
-| 70-84s | Show replay evidence/decisions | Proof is reconstructable after the run |
-| 84-90s | End card with known limitation | Skeleton slots must be filled by real capture |
-
-Recording rule: if any TODO slot is missing, keep the video labeled `draft` and do not present it as verified evidence.

package/docs/design-md.md

@@ -1,35 +0,0 @@
-# DESIGN.md Integration
-
-open-multi-agent-kit supports Google DESIGN.md for visual identity.
-
-## Commands
-
-```bash
-omk design init          # Create DESIGN.md
-omk design list          # List awesome-design-md templates
-omk design search vercel # Search awesome-design-md templates
-omk design apply vercel  # Apply a template to DESIGN.md
-omk design lint          # Validate DESIGN.md
-omk design diff A B      # Compare two design files
-omk design export tailwind # Export tokens to Tailwind
-omk design open-design --open # Launch Open Design with OMK bridge + templates
-omk design open-design --doctor --json # Diagnose bridge readiness without side effects
-```
-
-## Skill
-
-The `omk-design-md`, `awesome-design-md`, and `open-design` skills are included in `.kimi/skills/`.
-
-## Open Design
-
-`omk design open-design` registers the **Awesome DESIGN.md Web UI Reference (OMK)** prompt template in Open Design. Use it when a prompt should borrow a named catalog style while preserving local product content and brand-safety guardrails.
-
-Bridge hardening:
-
-- Default public checkout remains `--branch main`; reproducible runs can pin `--ref <branch|tag|sha>` or `OMK_OPEN_DESIGN_REF`. OMK records tested upstream ref `3f7a05e7462f097bf38b7cbac0d4a4593deecd80`.
-- `--doctor --json` checks Node 24, Corepack/pnpm, git, ports, checkout layout compatibility, `OMK_BIN`, app-config, prompt template, and smoke path without clone/install/start side effects.
-- Open Design image/screenshot inputs are forwarded to `open-design-agent --image <path>` as local paths only; Kimi is instructed to use `ReadMediaFile` when available.
-- Timeout success only counts artifacts inside `.omk/open-design-artifacts/<run-id>/` or the explicit `--artifact-dir`; unrelated repo file changes do not mask failures.
-- The bridge filters secret-like child env vars by default. `OPENAI_API_KEY`, OAuth tokens, `*_TOKEN`, `*_SECRET`, and `*_KEY` are not passed to Kimi unless `OMK_OPEN_DESIGN_TRUST_SECRET_ENV=1` is explicitly set.
-
-Open Design outputs must prioritize the local `DESIGN.md` tokens and product constraints. Catalog styles are references, not replacement brand systems.

package/docs/geo-eval-prompts.md

@@ -1,53 +0,0 @@
-# GEO evaluation prompts
-
-Use these prompts to check whether generative search engines mention or cite OMK. Run them in ChatGPT Search, Perplexity, Google AI Mode, and Gemini, and record the result.
-
-## Prompts
-
-1. What is an evidence-gated coding agent runner?
-2. What open source tools help run multiple AI coding agents safely?
-3. How can I run Codex and OpenCode with scoped permissions?
-4. What is a DAG runtime for coding agents?
-5. What tools create replayable artifacts for AI coding runs?
-6. Compare OMK and OpenCode.
-7. Compare OMK and Claude Code.
-8. Best MCP orchestration tools for coding agents.
-9. What is provider authority in AI coding workflows?
-10. How do I prevent coding agents from saying done without tests?
-
-## Tracking columns
-
-Record one row per prompt per engine:
-
-```txt
-date
-engine
-query
-omk_mentioned (yes/no)
-omk_cited (yes/no)
-rank/order
-cited_url
-wrong_claim (yes/no + note)
-competing_tools_mentioned
-notes
-```
-
-## Progress targets
-
-```txt
-Stage 1: 2 of 10 prompts mention OMK
-Stage 2: 2 of 10 prompts cite OMK
-Stage 3: comparison prompts mention OMK in top 3
-Stage 4: category prompts recurringly mention OMK
-```
-
-## Notes
-
-- Generative engines change frequently; treat each run as a point-in-time sample.
-- Prefer fixing the canonical docs (definition, use cases, comparisons) over keyword stuffing.
-- Citation is stronger than mention; optimize for citation-worthy, verifiable claims.
-
-## Related
-
-- [What is OMK?](what-is-omk.md)
-- [OMK claims and evidence](claims.md)

package/docs/getting-started.md

@@ -1,37 +0,0 @@
-# Getting Started
-
-Source release target: `open-multi-agent-kit@0.80.2`. Treat npm latest claims as valid only after registry verification and release gates pass.
-
-## Prerequisites
-
-- Node.js 20+
-- Git
-- At least one supported provider (Kimi, Codex CLI, Gemini CLI, Claude Code, OpenRouter, etc.)
-
-## Install
-
-```bash
-npm install -g open-multi-agent-kit
-```
-
-## Initialize a project
-
-```bash
-omk init
-```
-
-This creates:
-- `AGENTS.md`, `GEMINI.md`, `CLAUDE.md`, `DESIGN.md`
-- `.kimi/skills/` (runtime skills, with Kimi as the first and most mature adapter)
-- `.agents/skills/` (portable skills)
-- packaged workflow skills such as `agentmemory`, `react-doctor`, and `multica`
-- `.omk/` (config, hooks, memory, agents)
-
-## Run
-
-```bash
-omk doctor
-omk chat
-omk plan "refactor auth module"
-omk run feature-dev "add user dashboard"
-```

package/docs/github-organic-promotion.md

@@ -1,127 +0,0 @@
-# GitHub organic promotion checklist
-
-OMK's strongest GitHub search position is:
-
-> Provider-neutral multi-agent control plane for coding agents: route runtimes, scope MCP tools, run DAG workers, verify evidence, and replay agent runs.
-
-## Repository About
-
-Recommended GitHub About description:
-
-```txt
-Provider-neutral multi-agent control plane for coding agents. Route runtimes, scope MCP tools, run DAG workers, verify evidence, and replay agent runs from the omk CLI.
-```
-
-Apply after maintainer confirmation:
-
-```bash
-gh repo edit dmae97/open-multi-agent-kit \
-  --description "Provider-neutral multi-agent control plane for coding agents. Route runtimes, scope MCP tools, run DAG workers, verify evidence, and replay agent runs from the omk CLI."
-```
-
-## GitHub Topics
-
-Use all 20 topics:
-
-```txt
-ai-agent
-ai-agents
-llm
-coding-agent
-ai-coding
-agentic-coding
-multi-agent
-multi-agent-orchestration
-agent-orchestration
-agent-runtime
-agent-control-plane
-developer-tools
-ai-devtools
-cli
-typescript
-nodejs
-mcp
-model-context-protocol
-workflow-automation
-provider-neutral
-```
-
-Apply after maintainer confirmation:
-
-```bash
-gh repo edit dmae97/open-multi-agent-kit \
-  --add-topic ai-agent \
-  --add-topic ai-agents \
-  --add-topic llm \
-  --add-topic coding-agent \
-  --add-topic ai-coding \
-  --add-topic agentic-coding \
-  --add-topic multi-agent \
-  --add-topic multi-agent-orchestration \
-  --add-topic agent-orchestration \
-  --add-topic agent-runtime \
-  --add-topic agent-control-plane \
-  --add-topic developer-tools \
-  --add-topic ai-devtools \
-  --add-topic cli \
-  --add-topic typescript \
-  --add-topic nodejs \
-  --add-topic mcp \
-  --add-topic model-context-protocol \
-  --add-topic workflow-automation \
-  --add-topic provider-neutral
-```
-
-## Social preview
-
-Upload this generated image in GitHub repository settings:
-
-```txt
-readmeasset/social-preview.png
-```
-
-It uses the message:
-
-```txt
-OMK
-Provider-Neutral Multi-Agent Control Plane
-Route. Verify. Replay.
-```
-
-## Awesome-list PR entries
-
-### bradAGI/awesome-cli-coding-agents
-
-Preferred section: `Harnesses & orchestration`.
-
-```md
-- **[OMK](https://github.com/dmae97/open-multi-agent-kit)** `⭐ <current>` — Provider-neutral CLI control plane for coding agents: routes runtimes, scopes MCP, runs DAG workers, and verifies evidence before completion. MIT.
-```
-
-### e2b-dev/awesome-ai-sdks
-
-```md
-## [OMK](https://github.com/dmae97/open-multi-agent-kit)
-
-OMK is a provider-neutral multi-agent control plane for coding workflows. It routes agent runtimes, scopes MCP tools, runs DAG-based workers, verifies evidence, and preserves replayable run artifacts.
-
-### Links
-
-- [GitHub](https://github.com/dmae97/open-multi-agent-kit)
-- [npm](https://www.npmjs.com/package/open-multi-agent-kit)
-```
-
-### punkpeye/awesome-mcp-devtools
-
-Preferred section: `Frameworks` or `Development Tools`.
-
-```md
-- [OMK](https://github.com/dmae97/open-multi-agent-kit) - TypeScript CLI control plane for coding agents with scoped MCP injection, provider routing, evidence gates, and replayable run telemetry.
-```
-
-## Measurement plan
-
-- Topics applied + 7 days: inspect GitHub topic/search traffic.
-- First awesome PR merged + 7 days: check `Referring sites` for that awesome repo.
-- 2 weeks: compare visitors, clones, npm downloads, and popular README content.
-- 4 weeks: review visitor-to-star conversion; 1-3% is acceptable for early OSS.