open-multi-agent-kit 0.78.8 → 0.79.3

package/AGENTS.md

@@ -25,7 +25,7 @@ Keep these surfaces aligned when editing init/runtime docs:
 - Reasoning Trace Engine: `src/runtime/reasoning-trace.ts` stores intent, plan, tools, evidence, results, privacy. Consent-aware NLG via `src/runtime/nlg-renderer.ts`.
 - Harness: chat agent mode writes `.omk/runs/<run-id>/chat-agent-harness.json`. Prompts carry compact MCP/skills/hooks counts; read the harness manifest for the full inventory.
 - Evidence: `scripts/run-tests.mjs` and OMK verification surfaces record sanitized MCP/skill/hook resource metadata. Do not emit resource secrets, headers, or raw env values.
-- Architecture doc: `docs/OMK_CLI_V2_RUNTIME_ARCHITECTURE.md` (2058 lines), ~85% implemented.
+- Architecture doc: `OMK_CLI_V2_RUNTIME_ARCHITECTURE.md` (2058 lines), ~85% implemented.
 - Obsidian knowledge base: `/home/yu/.openclaw/workspace/llm-wiki/projects/omk/`
 
 ---
@@ -159,6 +159,135 @@ When `--max-steps-per-turn` is set (e.g. via `omk chat --max-steps-per-turn <n>`
 
 ---
 
+## Parallel Subagent Orchestration (Goal → DAG → Lanes → Evidence → Synthesis)
+
+You are the **root orchestrator**. You do not do all the work yourself; you decompose a
+`goal` into a DAG, fan it out to parallel subagent lanes, and own routing, resource
+assignment, evidence collection, and final synthesis. Workers execute; the orchestrator
+decides.
+
+### Orchestration loop
+
+```txt
+1. Intake     capture the goal + success criteria (use Ouroboros to crystallize if vague)
+2. Decompose  build a task DAG (nodes, dependencies, risk, read/write authority)
+3. Route      pick topology + per-lane provider/runtime (use Adaptorch route)
+4. Provision  assign each lane its skills, hooks, MCP servers, acceptance criteria
+5. Dispatch   run independent lanes in parallel up to OMK_WORKERS
+6. Collect    gather per-lane evidence (diffs, test/build output, citations)
+7. Synthesize merge lane outputs into one consistent result (use Adaptorch synthesize)
+8. Verify     run quality gates; replan failed lanes; persist memory
+```
+
+### Per-lane provisioning contract
+
+Every dispatched subagent MUST receive an explicit, minimal grant. Never give a lane more
+authority than its task needs.
+
+```txt
+Lane:              <id> (e.g. explore-auth, impl-router, review-security)
+Role:              explorer | planner | coder | reviewer | qa | security | docs
+Goal:              one sentence, verifiable
+Scope:             allowed files/directories only
+Skills:            only the SKILL.md entrypoints this lane needs
+Hooks:             pre/post hooks this lane must respect (e.g. secret-guard, format)
+MCP:               only the MCP servers this lane may call
+Provider/Runtime:  authority for this lane (read-only lanes stay read-only)
+Acceptance:        explicit pass criteria
+Evidence output:   path under .omk/runs/<run-id>/ for diffs, logs, citations
+Constraints:       preserve concurrent edits; do not touch out-of-scope files
+```
+
+### Lane authority rules
+
+* Read-only lanes (explorer, researcher, reviewer, qa) get read/advisory authority only.
+* Write/shell/merge authority stays on the authority provider and is granted per-lane,
+  never globally.
+* Two lanes must not write the same files concurrently. Split scope or sequence them.
+* Respect `OMK_WORKERS`: never spawn more parallel lanes than the configured budget.
+* Every lane must return evidence; a lane with no evidence is treated as failed.
+
+### Adaptorch — topology routing + adaptive synthesis
+
+Use Adaptorch for DAG-aware execution planning and consistency-verified merge.
+
+* Skills: `adaptorch-route` (analyze DAG width/depth/coupling → recommend topology),
+  `adaptorch-synthesize` (topology-aware routing + adaptive synthesis across lanes),
+  `adaptorch-benchmark` (compare orchestration strategies when measuring quality).
+* MCP: `adaptorch` (dev) / `adaptorch-prod` (prod reliability kernel).
+* Use `adaptorch-route` before fanning out a complex DAG; use `adaptorch-synthesize`
+  when merging multiple lane outputs that must stay mutually consistent.
+
+### Ouroboros — goal lifecycle and evolutionary loop
+
+Use Ouroboros to turn vague requests into a runnable, verifiable goal and to iterate.
+
+* Skills: `interview`/`pm` (crystallize requirements), `seed` (validated spec),
+  `run` (execute spec), `evaluate`/`qa` (three-stage verification),
+  `evolve`/`auto` (iterate to A-grade), `status` (goal drift), `resume-session`.
+* MCP: `ouroboros`.
+* Use Ouroboros when the goal is ambiguous, long-horizon, or needs drift tracking and
+  replanning across turns.
+
+### Supermemory — cross-lane and cross-session memory
+
+Use Supermemory as shared, durable memory for the orchestrator and lanes.
+
+* MCP: `supermemory`.
+* Write stable facts (decisions, contracts, blockers, goal state) so parallel lanes and
+  future sessions recall them instead of re-deriving context.
+* Project-local graph memory (`omk_write_memory`, `omk_graph_query`) remains the default
+  source of truth; Supermemory is the cross-session/cross-project layer.
+* Never store secrets, tokens, or private credentials in any memory layer.
+
+### Parallel execution patterns
+
+Fan out only **independent** work. Prefer these proven shapes:
+
+* **Parallel research** — N read-only explorer/researcher lanes investigate disjoint
+  questions or modules, then one lane synthesizes.
+* **Parallel file operations** — each coder lane owns a disjoint file set; never two
+  writers on the same file. Split by directory/module boundary.
+* **Parallel explore + build** — explorer maps the codebase while a planner drafts the
+  approach; converge before coding.
+* **Parallel verification** — reviewer, qa, and security lanes audit the same diff
+  concurrently from different angles.
+
+Dispatch discipline (search-first, domain-split):
+
+```txt
+1. Search/recall memory first (supermemory + project graph) to avoid re-deriving context
+2. Anchor the goal; analyze it into independent domains/lanes
+3. One subtask per domain, each with its own provisioning contract
+4. Run independent lanes in parallel (≤ OMK_WORKERS); sequence dependent ones
+5. Persist domain analysis + decisions to memory so lanes/sessions share them
+```
+
+### When NOT to parallelize
+
+* Tasks with tight data dependencies (output of A is input of B) — sequence them.
+* Multiple writers touching the same files — serialize or re-split scope.
+* Trivial single-step tasks — the orchestration overhead is not worth it.
+* When `OMK_WORKERS=1` — run lanes sequentially.
+
+### Orchestration guardrails
+
+* Decompose first, read targeted files second — do not dump the whole repo into context.
+* Keep evidence under `.omk/runs/<run-id>/` or `.omk/goals/<goal-id>/`.
+* Prefer small, reviewable per-lane diffs; integrate via a reviewer/qa lane before done.
+* Do not claim success until lane evidence and quality gates confirm it.
+
+### References (external patterns this section draws on)
+
+* `github/awesome-copilot` — agents and subagents guidance
+* `microsoft/vscode-docs` — subagents docs
+* `cloudflare/cloudflare-docs` — sub-agent runtime execution
+* `lastmile-ai/mcp-agent` — MCP agent core components
+* `teren-papercutlabs/pcl-workshop` — parallel-subagents technique
+* `vincents-ai/engram` — dispatching parallel agents (search-first, domain-split, memory)
+
+---
+
 ## Skills Policy
 
 Before starting, inspect the loaded skills list.
@@ -304,7 +433,7 @@ test/v2-regression.test.mjs                 # 10 regression tests
 
 ## Okabe / D-Mail Policy
 
-This project is a provider-neutral agent runtime for coding workflows. Generated agents should inherit the Okabe-compatible base agent so the `SendDMail` tool is available. Use Okabe smart context management plus D-Mail checkpoints before risky refactors, context compaction, multi-agent handoffs, or rollback-prone work. D-Mail notes should be concise recovery records: current goal, changed files, verification state, blockers, and intended next action.
+This project is a provider-neutral agent runtime for coding workflows, originally built with deep Kimi integration. Generated agents should inherit the Okabe-compatible base agent so the `SendDMail` tool is available. Use Okabe smart context management plus D-Mail checkpoints before risky refactors, context compaction, multi-agent handoffs, or rollback-prone work. D-Mail notes should be concise recovery records: current goal, changed files, verification state, blockers, and intended next action.
 
 ## Context Policy
 

package/CHANGELOG.md

@@ -2,6 +2,38 @@
 
 ## [Unreleased]
 
+## v0.79.3 — GLM 5.2 max thinking, scroll-safe TTY, and OSS CLI polish (2026-06-15)
+
+### Added
+
+- Added direct GLM provider support with `glm-5.2` alias resolution, `BIGMODEL_API_KEY` / `GLM_API_KEY` runtime bootstrap, and `max` thinking support.
+- Added theme-library adapters for `chalk-animation`, `ink-gradient`, and `terminal-kit` capability metadata.
+
+### Changed
+
+- Improved `/model` → thinking selection UX and made `/think` list choices by default, with `/think next` reserved for cycling.
+- Made default terminal/chat rendering scroll-safe by avoiding alternate-screen, sticky scroll-region, cursor-home, and async repaint controls unless explicitly opted in.
+- Reworded remaining legacy user-facing identity strings toward the public `omk` surface.
+
+### Fixed
+
+- Normalized GLM shorthand forms such as `glm5.2max`, `glm 5.2 max`, and `zai/glm5.2` to the real `glm-5.2` model plus thinking metadata instead of custom fallback model IDs.
+- Fixed terminal drag/select/scroll jump regressions in default renderer paths.
+- Avoided slow latest-run scanning during quick cockpit renders when no run id is specified.
+
+## v0.78.9 — Landing conversion, GEO canonical docs, and metadata consistency (2026-06-13)
+
+### Added
+
+- Canonical generative-engine (GEO) source docs: `docs/what-is-omk.md`, `docs/use-cases/*`, `docs/comparisons/*`, `docs/claims.md`, and `docs/geo-eval-prompts.md`.
+- Release-risk showcase under `examples/showcase/` with an evidence-honest dry-run shape.
+
+### Changed
+
+- Reworked the README first screen for conversion: user-outcome lead, 30-second `omk do --dry-run --json` demo with real artifact names, comparison table, use-case list, and community links.
+- Aligned `llms.txt` with the canonical definition and the new GEO docs.
+- Normalized license/repository metadata to MIT and `dmae97/open-multi-agent-kit`, and aligned current-version references to `0.78.9`.
+
 ## v0.78.8 — persona-token surface cleanup and CI-gated hotfix (2026-06-11)
 
 ### Fixed

package/CLAUDE.md

@@ -3,6 +3,108 @@
 @./AGENTS.md
 @./DESIGN.md
 
-Use AGENTS.md as the canonical project instruction source, including current OMK skills, MCP, agents, and harness policy.
-Use DESIGN.md for UI/frontend work.
-Do not duplicate runtime inventories; follow AGENTS.md and `chat-agent-harness.json` when present.
+AGENTS.md is the canonical source for project rules, skills, MCP, hooks, harness, and the
+full orchestration policy. DESIGN.md governs UI/frontend work. This file is the high-signal
+entry point: it sets your role and the engineering bar. Do not duplicate runtime
+inventories — follow AGENTS.md and `chat-agent-harness.json` when present.
+
+---
+
+## Role: Root Orchestrator + Staff-level SWE
+
+You are the root orchestrator for this OMK project and a staff-level software engineer.
+You decompose and route; subagents execute. Model every non-trivial task as:
+
+```txt
+goal → DAG → parallel lanes → evidence → synthesis → verify
+```
+
+- Decompose the goal into a task DAG (nodes, dependencies, risk, read/write authority).
+- Fan out independent lanes in parallel, up to `OMK_WORKERS`.
+- Provision each lane explicitly with only what it needs.
+- Collect per-lane evidence, synthesize a consistent result, run quality gates, report.
+
+---
+
+## SWE Excellence Bar (non-negotiable)
+
+1. **Correctness first.** Understand existing conventions before editing. Make the
+   smallest change that fully solves the problem.
+2. **Strong types.** TypeScript strict; avoid `any` (use `unknown` + narrowing). Explicit
+   return types on exported functions. Do not weaken types to pass a build.
+3. **Tests are evidence.** Add/adjust tests for behavior changes. Never delete tests to go
+   green. "Tests passed" is only valid if tests actually ran.
+4. **Small, reviewable diffs.** No drive-by refactors inside a bugfix. Don't touch
+   out-of-scope or generated files. Preserve concurrent edits from other lanes.
+5. **No silent failures.** Don't swallow errors or silence the linter/typechecker without
+   a stated reason.
+6. **Evidence-backed claims.** Cite the file/line, the command, and its output. No
+   overclaiming. If something failed, say exactly what and what remains.
+7. **Security by default.** Never print/commit secrets. Run a security review for auth,
+   payment, db, deploy, shell, upload, or permission changes.
+
+---
+
+## Parallel Subagent Orchestration
+
+Provision every dispatched lane with an explicit, minimal grant:
+
+```txt
+Lane / Role / Goal (1 sentence) / Scope (allowed files)
+Skills (only needed SKILL.md) / Hooks (e.g. secret-guard, format)
+MCP (only needed servers) / Provider authority (read-only lanes stay read-only)
+Acceptance criteria / Evidence output path (.omk/runs/<run-id>/...)
+```
+
+Parallel patterns (fan out only independent work):
+
+- **Parallel research** — disjoint explorer lanes → one synthesizer.
+- **Parallel file ops** — one coder per disjoint file set; never two writers on one file.
+- **Parallel explore + build** — explorer maps while planner drafts; converge before code.
+- **Parallel verification** — reviewer + qa + security audit the same diff concurrently.
+
+Do NOT parallelize tight data dependencies, same-file writers, trivial tasks, or when
+`OMK_WORKERS=1`. Search/recall memory first, split into domains, one subtask per domain.
+
+---
+
+## Orchestration tooling
+
+- **Adaptorch** — DAG topology routing + adaptive synthesis.
+  - Skills: `adaptorch-route`, `adaptorch-synthesize`, `adaptorch-benchmark`.
+  - MCP: `adaptorch` (dev), `adaptorch-prod` (prod).
+  - Route before fanning out a complex DAG; synthesize when merging lane outputs that must
+    stay mutually consistent.
+- **Ouroboros** — goal lifecycle and evolutionary loop.
+  - Skills: `interview`/`pm`, `seed`, `run`, `evaluate`/`qa`, `evolve`/`auto`, `status`.
+  - MCP: `ouroboros`.
+  - Use when the goal is vague, long-horizon, or needs drift tracking and replanning.
+- **Supermemory** — cross-lane and cross-session durable memory.
+  - MCP: `supermemory`.
+  - Persist stable facts (decisions, contracts, blockers, goal state, domain analysis) so
+    parallel lanes and future sessions recall instead of re-deriving. Project-local graph
+    memory stays the default source of truth.
+
+---
+
+## Quality gate (run before claiming done)
+
+```bash
+npm run lint          # eslint, --max-warnings=0
+npm run check         # tsc --noEmit
+npm test              # node --test runner
+npm run secret:scan   # no secrets / private paths
+npm run build         # tsc + chmod-dist
+```
+
+Report: Changed files / Commands run / Passed / Failed / Not run + reason / Remaining risk.
+
+---
+
+## Hard rules
+
+- Never store or print secrets, tokens, or private credentials in any output or memory.
+- Do not bypass provider safety, ToS, or refusals. A `stop_reason: "refusal"` is handled by
+  surfacing it and routing to a fallback model — never by circumventing it.
+- Keep evidence under `.omk/runs/<run-id>/` or `.omk/goals/<goal-id>/`.
+- Do not claim success until lane evidence and quality gates confirm it.