open-multi-agent-kit 0.78.8 → 0.79.1

package/docs/headroom-omk-usage-examples.md

@@ -1,371 +0,0 @@
-# Headroom OMK 사용 예시
-
-## 1. 기본 컨텍스트 압축
-
-### 예시 1: 대용량 코드 출력 압축
-
-```
-사용자: 이 대용량 코드 출력을 압축해줘
-
-에이전트: headroom_compress 도구를 사용하여 컨텍스트를 압축하겠습니다.
-
-[에이전트가 headroom_compress 도구를 사용]
-
-결과: 60-95% 토큰 절약, 답변 품질 유지
-```
-
-### 예시 2: 로그 파일 압축
-
-```
-사용자: 이 에러 로그를 분석해줘 (10,000줄)
-
-에이전트: 먼저 headroom으로 로그를 압축하겠습니다.
-
-[에이전트가 headroom_compress 도구를 사용]
-
-결과: 10,000줄 로그 → 1,000줄로 압축, 토큰 90% 절약
-```
-
-## 2. 병렬 서브에이전트 작업
-
-### 예시 1: 코드베이스 보안 분석
-
-```
-사용자: 3개의 다른 코드베이스를 병렬로 분석해줘
-
-에이전트: 3개의 병렬 서브에이전트를 생성하겠습니다.
-
-[에이전트가 spawn_parallel_agents 도구를 사용]
-
-결과:
-- 에이전트 1: SQL 인젝션 취약점 스캔
-- 에이전트 2: 인증 결함 검사
-- 에이전트 3: 권한 부여 문제 분석
-```
-
-### 예시 2: 멀티 프로젝트 빌드
-
-```
-사용자: 5개의 마이크로서비스를 병렬로 빌드해줘
-
-에이전트: 5개의 병렬 빌드 에이전트를 생성하겠습니다.
-
-[에이전트가 spawn_parallel_agents 도구를 사용]
-
-결과:
-- 각 에이전트가 다른 서비스를 빌드
-- 모든 빌드가 병렬로 실행
-- 결과가 통합되어 보고
-```
-
-## 3. 목표 지향적 오케스트레이션
-
-### 예시 1: REST API 구축
-
-```
-사용자: JWT 인증이 있는 REST API를 구축해줘
-
-에이전트: 이 목표를 위해 여러 서브에이전트를 오케스트레이션하겠습니다.
-
-[에이전트가 orchestrate_goal 도구를 사용]
-
-결과:
-- API 설계사: 엔드포인트 및 스키마 설계
-- 인증 전문가: JWT 인증 구현
-- 데이터베이스 엔지니어: 데이터베이스 스키마 설계
-- 테스트 작성자: 포괄적인 테스트 작성
-```
-
-### 예시 2: 실시간 알림 시스템
-
-```
-사용자: 실시간 알림 시스템을 구축해줘
-
-에이전트: 이 목표를 위해 5개의 서브에이전트를 오케스트레이션하겠습니다.
-
-[에이전트가 orchestrate_goal 도구를 사용]
-
-결과:
-- WebSocket 전문가
-- 데이터베이스 설계자
-- API 개발자
-- 프론트엔드 통합자
-- 테스트 자동화 전문가
-```
-
-## 4. 통합 사용 예시
-
-### 예시 1: 보안 감사 with 토큰 절약
-
-```
-사용자: 대규모 코드베이스의 보안 감사를 수행해줘
-
-에이전트: 먼저 코드베이스를 분석하고, 병렬로 보안 검사를 수행하겠습니다.
-
-1단계: 코드베이스 탐색 (대용량)
-   → headroom_compress로 탐색 결과 압축
-   → 토큰 80% 절약
-
-2단계: 병렬 보안 검사
-   → 4개의 병렬 에이전트 생성
-   → 각각 다른 보안 측면 검사
-
-3단계: 결과 통합
-   → coordinate_agent_results로 결과 병합
-   → 포괄적인 보안 보고서 생성
-```
-
-### 예시 2: 코드 리팩토링 with 오케스트레이션
-
-```
-사용자: 레거시 인증 시스템을 리팩토링해줘
-
-에이전트: 이 목표를 위해 오케스트레이션을 사용하겠습니다.
-
-1단계: 현재 시스템 분석
-   → 코드 분석 에이전트
-   → 대용량 코드 압축 with headroom
-
-2단계: 새 패턴 설계
-   → 패턴 설계 에이전트
-   → 설계 문서 압축
-
-3단계: 마이그레이션 계획
-   → 마이그레이션 플래너 에이전트
-   → 계획 문서 압축
-
-4단계: 테스트 작성
-   → 테스트 작성 에이전트
-   → 테스트 코드 압축
-```
-
-## 5. 고급 사용 예시
-
-### 예시 1: 적응형 오케스트레이션
-
-```
-사용자: 복잡한 데이터 파이프라인을 구축해줘
-
-에이전트: 적응형 오케스트레이션을 사용하겠습니다.
-
-[에이전트가 orchestrate_goal 도구를 사용 with strategy: "adaptive"]
-
-결과:
-- 의존성 기반 실행
-- 이전 에이전트 완료 후 다음 에이전트 시작
-- 자동 조정 및 최적화
-```
-
-### 예시 2: 파이프라인 오케스트레이션
-
-```
-사용자: 머신러닝 모델 학습 파이프라인을 구축해줘
-
-에이전트: 파이프라인 오케스트레이션을 사용하겠습니다.
-
-[에이전트가 orchestrate_goal 도구를 사용 with strategy: "pipeline"]
-
-결과:
-- 데이터 수집 → 전처리 → 모델 학습 → 평가 → 배포
-- 각 단계가 이전 단계 결과를 사용
-- 순차적 but 효율적 실행
-```
-
-## 6. 토큰 절약 최적화
-
-### 예시 1: 반복적 압축
-
-```
-사용자: 대규모 코드 리뷰를 수행해줘
-
-에이전트: 반복적 압축을 사용하여 토큰을 최적화하겠습니다.
-
-1단계: 코드 탐색 (대용량)
-   → headroom_compress로 탐색 결과 압축
-   → 토큰 90% 절약
-
-2단계: 상세 분석 (중간 크기)
-   → 압축된 컨텍스트 사용
-   → 추가 압축 필요시 다시 압축
-
-3단계: 최종 보고서 (소규모)
-   → 압축된 결과 사용
-   → 최소한의 토큰으로 보고서 생성
-```
-
-### 예시 2: 컨텍스트 윈도우 관리
-
-```
-사용자: 긴 대화에서 컨텍스트를 관리해줘
-
-에이전트: headroom을 사용하여 컨텍스트 윈도우를 관리하겠습니다.
-
-[에이전트가 자동으로 컨텍스트 압축]
-
-결과:
-- 대화 시작: 원본 컨텍스트
-- 대화 중반: 압축된 컨텍스트 (60-95% 절약)
-- 대화 후반: 추가 압축 필요시 자동 압축
-- 컨텍스트 윈도우 한계 방지
-```
-
-## 7. 에이전트 장비 설정
-
-### 예시 1: 보안 전문 에이전트 장비
-
-```
-사용자: 보안 전문 에이전트를 장비해줘
-
-에이전트: equip_agent 도구를 사용하여 에이전트를 장비하겠습니다.
-
-[에이전트가 equip_agent 도구를 사용]
-
-결과:
-- Skills: 보안 스캐너, 취약점 분석기, 침입 탐지기
-- Hooks: 사전 커밋 검사, 사후 커밋 분석
-- MCP Servers: 취약점 데이터베이스, 보안 패턴 저장소
-```
-
-### 예시 2: 데이터베이스 전문 에이전트 장비
-
-```
-사용자: 데이터베이스 전문 에이전트를 장비해줘
-
-에이전트: equip_agent 도구를 사용하여 에이전트를 장비하겠습니다.
-
-[에이전트가 equip_agent 도구를 사용]
-
-결과:
-- Skills: 데이터베이스 설계, 마이그레이션, 최적화
-- Hooks: 백업, 복원, 무결성 검사
-- MCP Servers: PostgreSQL, Redis, Elasticsearch
-```
-
-## 8. 모니터링 및 통계
-
-### 예시 1: 압축 통계 확인
-
-```
-사용자: headroom 압축 통계를 보여줘
-
-에이전트: headroom_stats 도구를 사용하여 통계를 확인하겠습니다.
-
-[에이전트가 headroom_stats 도구를 사용]
-
-결과:
-- 총 압축 횟수: 150회
-- 평균 절약률: 75%
-- 총 절약된 토큰: 1,500,000개
-```
-
-### 예시 2: 오케스트레이터 상태 확인
-
-```
-사용자: 오케스트레이터 상태를 확인해줘
-
-에이전트: orchestrator_status 도구를 사용하여 상태를 확인하겠습니다.
-
-[에이전트가 orchestrator_status 도구를 사용]
-
-결과:
-- 현재 목표: REST API 구축
-- 활성 에이전트: 5개
-- 완료된 에이전트: 3개
-- 실패한 에이전트: 0개
-```
-
-## 9. 문제 해결
-
-### 예시 1: 압축 실패 시
-
-```
-사용자: 압축이 실패했어
-
-에이전트: headroom_install 도구를 사용하여 headroom을 재설치하겠습니다.
-
-[에이전트가 headroom_install 도구를 사용 with force: true]
-
-결과: headroom 재설치, 압축 기능 복구
-```
-
-### 예시 2: 에이전트 스폰 실패 시
-
-```
-사용자: 에이전트가 스폰되지 않아
-
-에이전트: check_parallel_agents 도구를 사용하여 상태를 확인하겠습니다.
-
-[에이전트가 check_parallel_agents 도구를 사용]
-
-결과: 에이전트 상태 확인, 문제 진단, 해결책 제시
-```
-
-## 10. 통합 워크플로우
-
-### 예시 1: 완전한 개발 워크플로우
-
-```
-사용자: 새로운 기능을 개발해줘
-
-에이전트: 완전한 개발 워크플로우를 시작하겠습니다.
-
-1단계: 요구사항 분석
-   → 오케스트레이터가 목표 설정
-   → 분석 에이전트 생성
-
-2단계: 설계
-   → 설계 에이전트 생성
-   → 설계 문서 압축 with headroom
-
-3단계: 구현
-   → 구현 에이전트 생성 (병렬)
-   → 코드 압축 with headroom
-
-4단계: 테스트
-   → 테스트 에이전트 생성
-   → 테스트 결과 압축
-
-5단계: 배포
-   → 배포 에이전트 생성
-   → 배포 로그 압축
-
-결과: 토큰 70% 절약, 개발 시간 50% 단축
-```
-
-### 예시 2: 지속적 통합 워크플로우
-
-```
-사용자: CI/CD 파이프라인을 구축해줘
-
-에이전트: 지속적 통합 워크플로우를 구축하겠습니다.
-
-1단계: 코드 변경 감지
-   → Git 훅 에이전트
-   → 변경사항 압축
-
-2단계: 빌드
-   → 빌드 에이전트 (병렬)
-   → 빌드 로그 압축
-
-3단계: 테스트
-   → 테스트 에이전트 (병렬)
-   → 테스트 결과 압축
-
-4단계: 배포
-   → 배포 에이전트
-   → 배포 로그 압축
-
-결과: 자동화된 CI/CD, 토큰 80% 절약
-```
-
-## 결론
-
-이 예시들은 headroom과 OMK의 통합이如何提供하는지 보여줍니다:
-
-1. **토큰 절약**: 60-95% 토큰 절약 through headroom 압축
-2. **병렬 처리**:多个 서브에이전트가 동시에 작업
-3. **목표 오케스트레이션**: 복잡한 목표를 향한协调된 작업
-4. **유연한 장비**: 각 에이전트에特定한 skills, hooks, MCP 서버
-5. **모니터링 및 통계**: 압축效果 및 에이전트状态 모니터링
-
-이러한 도구들을 사용하여 OMK 워크플로우를 효율적인 컨텍스트 압축과 병렬 에이전트 오케스트레이션으로 향상시키세요.

package/docs/hud-and-parallel-ux.md

@@ -1,155 +0,0 @@
-# HUD and Parallel UX
-
-This document covers the live terminal interfaces for monitoring and executing OMK runs.
-
----
-
-## HUD (`omk hud`)
-
-The HUD is a **read-only dashboard** that gives you a real-time view of your project, system, and active runs without leaving the terminal.
-
-### Panels
-
-| Panel | Content |
-|-------|---------|
-| **System Usage** | CPU, memory, and disk utilization |
-| **Kimi Usage** | OAuth account badge, 5-hour quota, weekly quota (with optional bar gauges via `OMK_KIMI_STATUS_GAUGES=1`) |
-| **Project Status** | Git branch, changed files count, scaffold health |
-| **Latest Run** | Most recent run ID, goal, status, and health |
-| **TODO / Changed Files** | Sidebar list of open TODOs and uncommitted changes |
-
-### Top Summary Bar
-
-A compact header line shows:
-
-- **Goal** — current or most-recent run goal
-- **Run health** — `healthy` / `degraded` / `blocked` / `unknown`
-- **Next action** — suggested command or recovery step
-
-### Responsive Modes
-
-The HUD adapts to terminal width automatically:
-
-| Width | Layout |
-|-------|--------|
-| `>= 120 cols` | Full dashboard + right rail (all panels + sidebar) |
-| `90–119 cols` | Summary bar + latest run + TODO list |
-| `< 90 cols` | Compact single-column (summary bar + critical gauges only) |
-
-### Flags
-
-| Flag | Behavior |
-|------|----------|
-| `--watch` | Refresh every few seconds (default in TTY) |
-| `--compact` | Force compact layout regardless of width |
-| `--section <name>` | Show only one section: `run`, `project`, or `resources` |
-| `--no-clear` | Do not clear the terminal between refreshes |
-| `--alternate-screen` | Use the terminal alternate screen buffer (no scrollback pollution) |
-
-### Goal-aware Display
-
-The HUD resolves the current goal in this priority order:
-
-1. `.omk/goals/<id>/goal.json` — active goal file
-2. RunState snapshot — goal embedded in the latest persisted run
-3. `goal.md` — fallback project goal document
-
-### State Error UX
-
-If a run state file is corrupt, missing, or invalid, the HUD shows a **recovery suggestion** instead of crashing:
-
-- Missing state → prompt to run `omk parallel <goal>` or `omk run <flow> <goal>`
-- Corrupt JSON → suggest checking `.omk/runs/` or running `omk doctor`
-- Invalid schema → display the validation error and a link to relevant docs
-
----
-
-## Parallel (`omk parallel`)
-
-Parallel is the **DAG executor with live UI**. It orchestrates coordinator → worker fan-out → reviewer runs and renders progress in real time.
-
-Runtime/provider UI fields should follow the canonical routing and worker-scope
-contracts in
-[`native-root-runtime-algorithms.md`](./native-root-runtime-algorithms.md):
-Algorithm 5 for selected runtime, fallback chain, and route evidence;
-Algorithm 7 for worker environment/capability scope.
-
-### Header
-
-The top of the parallel UI shows:
-
-- **Goal** — the task being executed
-- **Run ID** — unique timestamped identifier
-- **Workers** — number of active worker slots
-- **Approval policy** — `yolo`, `confirm`, or `reject`
-- **Mode** — `watch` or `no-watch`
-
-### Worker Grid
-
-Each worker is rendered as a labeled card:
-
-- **Role label** — e.g., `coder`, `reviewer`, `qa`
-- **Elapsed time** — since the worker started its current task
-- **Retry count** — number of retries for the current node
-
-### Blocker Panel
-
-Shown **only when a node fails or is blocked**:
-
-- Failed node name and role
-- Error summary
-- Suggested recovery action (e.g., `omk chat --run-id <id>`, `omk summary`)
-
-### Completion Panel
-
-When the run finishes, a completion panel appears with next steps:
-
-```txt
-Run complete. Next steps:
-  omk summary          → generate summary.md + report.md
-  omk verify           → run quality gates on the result
-  omk chat --run-id    → resume interactively
-```
-
-### Flags
-
-| Flag | Behavior |
-|------|----------|
-| `--watch` | Live UI refresh every 1.5 s (default in TTY) |
-| `--no-watch` | Static output, no refresh (default non-TTY) |
-| `--alternate-screen` | Full-screen alternate buffer (opt-in) |
-| `--no-pause` | Do not pause on completion; exit immediately |
-| `--compact` | Force compact worker grid layout |
-
-### Trust
-
-- Alternate screen is **opt-in** (`--alternate-screen`).
-- No forced scrollback loss: without the flag, output is appended to the main terminal buffer so you can scroll back through history.
-
----
-
-## RunViewModel
-
-`RunViewModel` is the **shared abstraction** between HUD and parallel UI. It interprets raw run state into a consistent, display-ready model.
-
-### Inputs
-
-| Input | Source |
-|-------|--------|
-| `RunState` | `.omk/runs/<run-id>/run-state.json` |
-| Goal (optional) | `.omk/goals/<id>/goal.json` or `goal.md` |
-| Changed files | `git status --short` |
-
-### Outputs
-
-| Output | Description |
-|--------|-------------|
-| **Health** | `healthy` / `degraded` / `blocked` / `unknown` |
-| **Progress** | Completed nodes / total nodes |
-| **ETA** | Estimated time remaining (when enough data exists) |
-| **Active node** | Currently executing node + role |
-| **Blocker** | First blocking or failed node, if any |
-| **Workers** | Array of active workers with elapsed time and retry count |
-| **Runtime route** | Selected provider/runtime, fallback chain, risk, sandbox, and approval policy when available |
-
-Both HUD and parallel UI consume the same `RunViewModel`, so their interpretations of run health and progress are always consistent.

package/docs/integrations/ouroboros.md

@@ -1,96 +0,0 @@
-# Ouroboros integration (embedded in OMK)
-
-[Ouroboros](https://github.com/Q00/ouroboros) is a spec-first "Agent OS"
-(PyPI `ouroboros-ai`). OMK embeds it through the documented runtime-adapter
-surface that Ouroboros already supports for the `pi`-family CLI that OMK builds
-on:
-
-- an **MCP server** (`ouroboros mcp serve`, ~29 `ouroboros_*` tools) registered in OMK's MCP config,
-- the official **`ooo` bridge extension** installed into OMK's agent extensions dir, so `ooo ...` works inside interactive OMK sessions, and
-- the 20 Ouroboros **skills** (SKILL.md) installed namespaced as `ouroboros-*`.
-
-Ouroboros owns its own workflow engine; the OMK runtime CLI is selected as its
-`runtime_backend` (a `--mode json` subprocess). This follows the runtime guide
-in the Ouroboros repository.
-
-## Prerequisites
-
-- Python `>=3.12`, `uv` (or `pipx`), and the OMK runtime CLI on `PATH`.
-- OMK global agent dir at `~/.omk/agent` (extensions, skills, `mcp.json`).
-
-## Install (reproducible)
-
-```bash
-# 0. Back up the global MCP config (mode 600, contains secrets) before merging.
-ts=$(date +%Y%m%d-%H%M%S)
-cp -a ~/.omk/agent/mcp.json ~/.omk/agent/mcp.json.bak-$ts
-
-# 1. Install the package with MCP support.
-uv tool install 'ouroboros-ai[mcp,claude]'      # or: pipx install 'ouroboros-ai[mcp,claude]'
-
-# 2. Non-interactive runtime setup: writes ~/.ouroboros/config.yaml
-#    (runtime_backend) and generates the ooo bridge extension.
-ouroboros setup --runtime pi --non-interactive
-
-# 3. Mirror the generated ooo bridge into OMK's extension dir.
-#    (locate the file Ouroboros generated, regardless of upstream dir)
-BRIDGE_SRC=$(find "$HOME" -maxdepth 4 -name ouroboros-ooo-bridge.ts -not -path '*/.omk/*' 2>/dev/null | head -1)
-cp "$BRIDGE_SRC" ~/.omk/agent/extensions/ouroboros-ooo-bridge.ts
-
-# 4. Register the MCP server in OMK (additive jq merge; keep mode 600).
-OURO_BIN="$(command -v ouroboros)"
-jq --arg bin "$OURO_BIN" '.mcpServers.ouroboros = {command:$bin, args:["mcp","serve"], env:{}}' \
-  ~/.omk/agent/mcp.json > /tmp/omk-mcp.new \
-  && python3 -m json.tool < /tmp/omk-mcp.new >/dev/null \
-  && install -m600 /tmp/omk-mcp.new ~/.omk/agent/mcp.json && rm -f /tmp/omk-mcp.new
-
-# 5. Install the 20 Ouroboros skills (namespaced).
-git clone --depth 1 https://github.com/Q00/ouroboros.git /tmp/ouroboros-src
-for d in /tmp/ouroboros-src/skills/*/; do b=$(basename "$d");
-  mkdir -p ~/.omk/agent/skills/ouroboros-$b;
-  cp "$d/SKILL.md" ~/.omk/agent/skills/ouroboros-$b/SKILL.md; done
-```
-
-> The MCP entry uses the absolute `ouroboros` binary path because OMK sanitizes
-> the child environment; a bare `ouroboros`/`uvx` command may not resolve under
-> the sanitized `PATH`.
-
-## Verify
-
-```bash
-ouroboros --version
-ouroboros mcp serve --help                  # MCP entrypoint
-ouroboros dispatch --help                   # ooo bridge dispatch entrypoint
-test -f ~/.omk/agent/extensions/ouroboros-ooo-bridge.ts && echo "omk bridge OK"
-grep -q ouroboros ~/.omk/agent/mcp.json && echo "mcp registered"
-ls -d ~/.omk/agent/skills/ouroboros-* | wc -l   # expect 20
-grep runtime_backend ~/.ouroboros/config.yaml   # expect: pi
-```
-
-A successful MCP handshake reports `serverInfo: ouroboros-mcp` and ~29
-`ouroboros_*` tools. In an interactive OMK session, after restart or `/reload`:
-
-```text
-ooo status
-ooo auto build a small CLI
-```
-
-## Scope and safety notes
-
-- The `ouroboros` MCP server is registered in the **global** `~/.omk/agent/mcp.json`,
-  so it is available under all-scope MCP sessions. Default project-scope sessions
-  (`omk-project` only) are unaffected, so OMK startup is not slowed by Ouroboros.
-- `ouroboros setup` mutates `~/.ouroboros/config.yaml` and the upstream runtime's
-  global extensions dir; it does not touch the OMK repo.
-- First MCP cold start resolves the uv tool venv and can be slow; `omk mcp doctor
-  ouroboros` may need a longer timeout on first run.
-
-## Rollback
-
-```bash
-ts=<backup timestamp>
-rm -f ~/.omk/agent/extensions/ouroboros-ooo-bridge.ts
-[ -f ~/.omk/agent/mcp.json.bak-$ts ] && install -m600 ~/.omk/agent/mcp.json.bak-$ts ~/.omk/agent/mcp.json
-rm -rf ~/.omk/agent/skills/ouroboros-*
-uv tool uninstall ouroboros-ai                # or: pipx uninstall ouroboros-ai
-```

package/docs/kimi-oauth-usage-status.md

@@ -1,33 +0,0 @@
-# Kimi OAuth usage status line
-
-OMK augments the Kimi interactive context status line with a compact local usage badge:
-
-```txt
-context: 35.6% (93.2k/262.1k) | in:93.2k out:1.8k | omk:acct:de…r@example.com | 5h:70% left | wk:80% left
-```
-
-## What is shown
-
-- `acct`: the current `/login` OAuth identity from `~/.kimi/credentials/kimi-code.json`.
-  - Tokens are never printed.
-  - Emails/usernames are masked.
-  - If no safe identity claim exists, OMK shows a stable hashed `oauth:<hash>` id.
-- `5h`: Kimi Code 5-hour quota remaining when `/usages` is reachable.
-- `wk`: Kimi Code weekly quota remaining when `/usages` is reachable.
-- If the remote quota endpoint is unavailable, OMK falls back to local session-time estimates from `~/.kimi/sessions`.
-
-## Implementation
-
-The wrapper does not patch Kimi's installed Python package. Instead, `runKimiInteractive()` post-processes PTY output and appends the OMK badge whenever it sees Kimi's native `context:` status span.
-
-Disable the badge if needed:
-
-```bash
-OMK_KIMI_STATUS_USAGE=0 omk chat
-```
-
-The HUD also uses the same OAuth/usage reader:
-
-```bash
-omk hud
-```

package/docs/kimi-okabe-dmail.md

@@ -1,44 +0,0 @@
-# Kimi Okabe + D-Mail context recovery
-
-open-multi-agent-kit exposes a Kimi adapter lane. Generated root and role agents inherit an Okabe-compatible base agent that keeps the default tools and adds Kimi's `SendDMail` tool.
-
-## Why it matters
-
-Okabe/D-Mail is the fast context-safety layer:
-
-- use Okabe for smart context management instead of stuffing the main prompt with every detail;
-- send D-Mail before risky refactors, dependency migrations, long-running multi-agent handoffs, or `/compact`;
-- keep D-Mail notes short and future-facing so rollback/recovery knows the goal, changed files, tests, blockers, and next action.
-
-Project-local ontology graph memory is the durable project/session memory layer. D-Mail is for checkpoint recovery; graph memory is for long-term recall. Embedded Kuzu remains available when Cypher-style graph queries are needed.
-
-## Generated agent default
-
-Official Kimi docs expose built-in `okabe` via `kimi --agent okabe`, and note `--agent` / `--agent-file` are mutually exclusive. Because OMK uses custom `--agent-file` configs, it ships an `okabe.yaml` base that extends `default` and adds `kimi_cli.tools.dmail:SendDMail`.
-
-
-Generated `.omk/agents/*.yaml` files use:
-
-```yaml
-agent:
-  extend: ./okabe.yaml  # Okabe-compatible base adds SendDMail/D-Mail checkpoints
-```
-
-## Recommended D-Mail shape
-
-```txt
-Goal:
-Checkpoint reason:
-Changed files:
-Verification:
-Blockers:
-Next action:
-Rollback note:
-```
-
-Do not put secrets in D-Mail. Store durable, non-secret project facts through `omk_write_memory`; inspect ontology recall through `omk_memory_mindmap` or `omk_graph_query`.
-
-## References
-
-- Kimi Code CLI Agents and Subagents: https://moonshotai.github.io/kimi-cli/en/customization/agents.html
-- Kimi command agent flags: https://moonshotai.github.io/kimi-cli/en/reference/kimi-command.html