open-multi-agent-kit 0.78.8 → 0.79.3

package/docs/2026-06-14/critical-issues.md

@@ -0,0 +1,19 @@
+# 2026-06-14 Critical Issues
+
+## Critical Init Status
+
+### Missing critical artifacts
+- `.omk/hooks/pre-shell-guard.sh` — destructive shell guard
+- `.omk/hooks/protect-secrets.sh` — secret write guard
+
+
+## Critical Artifacts Present
+- ✅ `AGENTS.md` — top-level operating contract
+- ✅ `.kimi/AGENTS.md` — Kimi-specific operating rules
+- ✅ `.omk/config.toml` — OMK project runtime settings
+- ✅ `.omk/agents/root.yaml` — root coordinator agent
+- ✅ `.kimi/mcp.json` — Kimi project MCP registry
+- ✅ `.omk/memory/graph-state.json` — local ontology graph database
+
+## Escalation Rule
+- Treat missing shell/secret guards, root agent config, MCP registry, or ontology graph as critical until restored.

package/docs/2026-06-14/improvements.md

@@ -0,0 +1,15 @@
+# 2026-06-14 Improvements
+
+## Current Improvement Backlog
+### Optional init/support artifacts to add or refresh
+- None detected.
+
+### Critical init artifacts currently blocking reliable chat startup
+- `.omk/hooks/pre-shell-guard.sh` — destructive shell guard
+- `.omk/hooks/protect-secrets.sh` — secret write guard
+
+
+## Suggested Focus
+- Keep `omk chat` startup idempotent and non-destructive.
+- Prefer local graph memory for default ontology state.
+- Keep generated daily docs small, dated, and safe to edit by hand.

package/docs/2026-06-14/init-checklist.md

@@ -0,0 +1,25 @@
+# 2026-06-14 Required Init Checklist
+
+**Run ID:** chat-2026-06-14T14-55-41-793Z-666566
+**Ontology graph:** `.omk/memory/graph-state.json`
+
+## Required Artifacts
+- ✅ `AGENTS.md` — critical; top-level operating contract
+- ✅ `.kimi/AGENTS.md` — critical; Kimi-specific operating rules
+- ✅ `DESIGN.md` — support; design/brand source of truth
+- ✅ `.omk/config.toml` — critical; OMK project runtime settings
+- ✅ `.omk/agents/root.yaml` — critical; root coordinator agent
+- ✅ `.kimi/mcp.json` — critical; Kimi project MCP registry
+- ✅ `.omk/mcp.json` — support; legacy OMK MCP fallback
+- ✅ `.omk/lsp.json` — support; bundled TypeScript/Python LSP config
+- 🚨 `.omk/hooks/pre-shell-guard.sh` — critical; destructive shell guard
+- 🚨 `.omk/hooks/protect-secrets.sh` — critical; secret write guard
+- ✅ `.omk/memory/graph-state.json` — critical; local ontology graph database
+- ✅ `.kimi/skills` — support; Kimi skill directory
+- ✅ `.agents/skills` — support; portable skill directory
+
+## Recovery Command
+```bash
+omk init
+omk doctor
+```

package/docs/2026-06-14/plan.md

@@ -0,0 +1,20 @@
+# 2026-06-14 OMK Chat Plan
+
+**Run ID:** chat-2026-06-14T14-55-41-793Z-666566
+**Generated by:** omk chat bootstrap
+
+## Purpose
+- Start every chat with a dated workspace for planning, issue triage, and verification evidence.
+- Keep ontology-backed memory available before the root coordinator starts.
+- Make required init state visible without overwriting user-authored docs.
+
+## Today Plan
+1. Review `init-checklist.md` and resolve missing critical init artifacts first.
+2. Use `improvements.md` as the active improvement backlog.
+3. Use `critical-issues.md` for blocking defects, safety risks, and verification gaps.
+4. Record command evidence before claiming work is complete.
+
+## Stop Condition
+- Critical init artifacts are present.
+- Ontology graph exists at `.omk/memory/graph-state.json`.
+- Any new code/docs changes have explicit verification evidence.

package/docs/2026-06-15/critical-issues.md

@@ -0,0 +1,19 @@
+# 2026-06-15 Critical Issues
+
+## Critical Init Status
+
+### Missing critical artifacts
+- `.omk/hooks/pre-shell-guard.sh` — destructive shell guard
+- `.omk/hooks/protect-secrets.sh` — secret write guard
+
+
+## Critical Artifacts Present
+- ✅ `AGENTS.md` — top-level operating contract
+- ✅ `.kimi/AGENTS.md` — Kimi-specific operating rules
+- ✅ `.omk/config.toml` — OMK project runtime settings
+- ✅ `.omk/agents/root.yaml` — root coordinator agent
+- ✅ `.kimi/mcp.json` — Kimi project MCP registry
+- ✅ `.omk/memory/graph-state.json` — local ontology graph database
+
+## Escalation Rule
+- Treat missing shell/secret guards, root agent config, MCP registry, or ontology graph as critical until restored.

package/docs/2026-06-15/improvements.md

@@ -0,0 +1,15 @@
+# 2026-06-15 Improvements
+
+## Current Improvement Backlog
+### Optional init/support artifacts to add or refresh
+- None detected.
+
+### Critical init artifacts currently blocking reliable chat startup
+- `.omk/hooks/pre-shell-guard.sh` — destructive shell guard
+- `.omk/hooks/protect-secrets.sh` — secret write guard
+
+
+## Suggested Focus
+- Keep `omk chat` startup idempotent and non-destructive.
+- Prefer local graph memory for default ontology state.
+- Keep generated daily docs small, dated, and safe to edit by hand.

package/docs/2026-06-15/init-checklist.md

@@ -0,0 +1,25 @@
+# 2026-06-15 Required Init Checklist
+
+**Run ID:** chat-2026-06-14T15-00-42-301Z-741114
+**Ontology graph:** `.omk/memory/graph-state.json`
+
+## Required Artifacts
+- ✅ `AGENTS.md` — critical; top-level operating contract
+- ✅ `.kimi/AGENTS.md` — critical; Kimi-specific operating rules
+- ✅ `DESIGN.md` — support; design/brand source of truth
+- ✅ `.omk/config.toml` — critical; OMK project runtime settings
+- ✅ `.omk/agents/root.yaml` — critical; root coordinator agent
+- ✅ `.kimi/mcp.json` — critical; Kimi project MCP registry
+- ✅ `.omk/mcp.json` — support; legacy OMK MCP fallback
+- ✅ `.omk/lsp.json` — support; bundled TypeScript/Python LSP config
+- 🚨 `.omk/hooks/pre-shell-guard.sh` — critical; destructive shell guard
+- 🚨 `.omk/hooks/protect-secrets.sh` — critical; secret write guard
+- ✅ `.omk/memory/graph-state.json` — critical; local ontology graph database
+- ✅ `.kimi/skills` — support; Kimi skill directory
+- ✅ `.agents/skills` — support; portable skill directory
+
+## Recovery Command
+```bash
+omk init
+omk doctor
+```

package/docs/2026-06-15/plan.md

@@ -0,0 +1,20 @@
+# 2026-06-15 OMK Chat Plan
+
+**Run ID:** chat-2026-06-14T15-00-42-301Z-741114
+**Generated by:** omk chat bootstrap
+
+## Purpose
+- Start every chat with a dated workspace for planning, issue triage, and verification evidence.
+- Keep ontology-backed memory available before the root coordinator starts.
+- Make required init state visible without overwriting user-authored docs.
+
+## Today Plan
+1. Review `init-checklist.md` and resolve missing critical init artifacts first.
+2. Use `improvements.md` as the active improvement backlog.
+3. Use `critical-issues.md` for blocking defects, safety risks, and verification gaps.
+4. Record command evidence before claiming work is complete.
+
+## Stop Condition
+- Critical init artifacts are present.
+- Ontology graph exists at `.omk/memory/graph-state.json`.
+- Any new code/docs changes have explicit verification evidence.

package/docs/claims.md

@@ -0,0 +1,85 @@
+# 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.78.9` (`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/comparisons/omk-vs-claude-code.md

@@ -0,0 +1,31 @@
+# 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

@@ -0,0 +1,33 @@
+# 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)

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

@@ -0,0 +1,33 @@
+# 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

@@ -0,0 +1,32 @@
+# 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

@@ -0,0 +1,20 @@
+# 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/geo-eval-prompts.md

@@ -0,0 +1,53 @@
+# 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,12 +1,12 @@
 # Getting Started
 
-Source release target: `open-multi-agent-kit@0.78.8` (`pre-1.0`).
+Source release target: `open-multi-agent-kit@0.79.3`. Treat npm latest claims as valid only after registry verification and release gates pass.
 
 ## Prerequisites
 
 - Node.js 20+
 - Git
-- At least one configured provider or local runtime adapter. Kimi is the most mature authority path; other lanes depend on local CLI/API availability and the provider-maturity contract.
+- At least one supported provider (Kimi, Codex CLI, Gemini CLI, Claude Code, OpenRouter, etc.)
 
 ## Install
 
@@ -22,7 +22,7 @@ omk init
 
 This creates:
 - `AGENTS.md`, `GEMINI.md`, `CLAUDE.md`, `DESIGN.md`
-- `.kimi/skills/` (runtime adapter skills used by the OMK control loop)
+- `.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)
@@ -35,31 +35,3 @@ omk chat
 omk plan "refactor auth module"
 omk run feature-dev "add user dashboard"
 ```
-
-## Updates
-
-On startup OMK checks npm for a newer release and, when one exists, shows an
-interactive prompt (Update now / Skip this version / Remind me later). Choosing
-"Update now" runs `npm i -g open-multi-agent-kit`.
-
-- **Automatic (non-interactive) updates:** set `OMK_AUTO_UPDATE=1` (also accepts
-  `true|yes|on|always`). When OMK is outdated it self-updates on startup without
-  prompting. CI is always skipped, and `OMK_UPDATE_PROMPT=off` disables update
-  checks entirely.
-- Manual check: `omk update check` (add `--refresh` to bypass the cache).
-
-## Adaptive runtime algorithms
-
-OMK embeds three adaptive control behaviors (all additive, safe defaults, non-fatal fallback):
-
-- **Topology-routed first run** — on the first DAG composition OMK derives structural features (width, critical depth, coupling, parallel ratio) and selects an execution topology (parallel / pipeline / map-reduce / hierarchical / hybrid / dag) with layered waves. Toggle with `OMK_ADAPTORCH_ROUTING=off`.
-- **Context guard before 90%** — before the context window crosses a threshold (default `0.90`) OMK compacts via [headroom](https://github.com/chopratejas/headroom) when available, otherwise its built-in budget optimizer. Tune with `OMK_HEADROOM_THRESHOLD` (0.50–0.99), `OMK_CONTEXT_WINDOW`, or disable with `OMK_HEADROOM=off`.
-- **Spec-first via Ouroboros** — goal/spec/orchestration intents prefer the embedded Ouroboros flow by default; when Ouroboros is not installed OMK degrades to the native path with no error. Modes: `OMK_OUROBOROS=always` (default) `| auto | off`. See [Ouroboros integration](integrations/ouroboros.md).
-
-## Support the project (GitHub star)
-
-First-time users get a one-time prompt to star the repository. If the GitHub CLI
-(`gh`) is authenticated the star is applied directly; otherwise OMK prints the
-repo URL and, on a desktop session, opens it in your browser so you can star in
-one click. You can star anytime with `omk star`, check status with
-`omk star --status`, and disable the prompt with `OMK_STAR_PROMPT=off`.

package/docs/headroom-omk-setup-guide.md

@@ -367,8 +367,8 @@ ls $OMK_RUNTIME_HOME/.agents/skills/headroom/
 
 ### 13.1 학습 리소스
 - [Headroom 문서](https://headroom-docs.vercel.app/docs)
-- [OMK 문서](https://github.com/open_multi-agent_kit)
-- [OMK 런타임 문서](https://github.com/dmae97/open_multi-agent_kit)
+- [OMK 문서](https://github.com/dmae97/open-multi-agent-kit)
+- [OMK 런타임 문서](https://github.com/dmae97/open-multi-agent-kit)
 
 ### 13.2 커뮤니티 참여
 - GitHub 이슈 및 PR

package/docs/integrations/adaptorch.md

@@ -0,0 +1,46 @@
+# Adaptorch Integration
+
+Adaptorch is OMK's optional topology-routing and adaptive-synthesis companion. OMK ships a pure TypeScript Adaptorch-style topology router by default, so DAG composition works without any external service. If an Adaptorch MCP server is configured locally, OMK can also route MCP-aware lanes through that server in trusted local-user scope.
+
+## Runtime Modes
+
+- **Built-in router**: enabled unless `OMK_ADAPTORCH_ROUTING=off|0|false`.
+- **MCP bridge**: trusted local config from `~/.omk/agent/mcp.json`, `~/.omk/mcp.json`, or `~/.kimi/mcp.json` is active only when `OMK_MCP_SCOPE=all` or after importing a reviewed server into project `.kimi/mcp.json`.
+- **Typo alias**: `adptorch` is accepted by `omk mcp add/remove/test` and maps to `adaptorch`.
+
+## Enable From Existing Global Agent Config
+
+If your Adaptorch MCP entry already exists in `~/.omk/agent/mcp.json`:
+
+```bash
+omk mcp list
+OMK_MCP_SCOPE=all omk mcp list
+omk mcp add adaptorch      # or: omk mcp add adptorch
+omk mcp test adaptorch
+```
+
+`omk mcp add adaptorch` copies a sanitized server definition into project `.kimi/mcp.json`. Secret-like env values are stored as runtime placeholders such as `${ADAPTORCH_CONTROL_PLANE_TOKEN}` rather than literal secrets.
+
+## Direct Project Install
+
+Use this only after reviewing the launcher path and secret handling:
+
+```bash
+omk mcp install adaptorch bash /absolute/path/to/run_adaptorch_mcp.sh \
+  --env ADAPTORCH_CONTROL_PLANE_BASE_URL=http://127.0.0.1:8080 \
+  --env ADAPTORCH_CONTROL_PLANE_TOKEN='${ADAPTORCH_CONTROL_PLANE_TOKEN}'
+```
+
+Then verify:
+
+```bash
+omk mcp doctor
+omk mcp test adaptorch
+OMK_MCP_SCOPE=all omk chat "plan this DAG with adaptorch routing"
+```
+
+## Safety Notes
+
+- Do not commit real Adaptorch tokens, headers, or `.env.local` files.
+- Keep production `adaptorch-prod` in global/user config unless the project explicitly requires it.
+- Prefer project import for reproducible local runs; prefer `OMK_MCP_SCOPE=all` only for trusted local operator sessions.