open-multi-agent-kit 0.90.9 → 0.92.0

package/docs/adaptorch-preview-spec.md

@@ -0,0 +1,174 @@
+# Lane F — AdaptTorch Preview Algorithm (structured spec)
+
+**Status:** documentation / interface blueprint only.  
+**Evidence roots:** `packages/adaptorch-wpl/`, `.omk/runs/adaptorch-native-loop-algorithm-20260701/final-part1-core-algorithm.md`, `packages/coding-agent/src/core/adaptorch-bridge.ts`, `packages/coding-agent/docs/loadout-domains/README.md`.  
+**Not a shipped runtime:** this spec describes a **preview** path (planning, routing, and evidence contracts) unless a future implementation lane wires it.
+
+---
+
+## Inputs
+
+| Input | Type | Source | Notes |
+| --- | --- | --- | --- |
+| `task_text` | string | user / lane kickoff | Primary routing signal; may be truncated for headroom. |
+| `path_hints` | string[] | cwd, owned paths, globs | Optional; used for domain triggers and write-scope checks. |
+| `upstream_tags` | string[] | goal id, lane role, preset | e.g. `grok-adaptorch-prod`, `omk-planner`. |
+| `payload_shape` | object | planner / DAG artifact | Sanitized shape for topology preview only — **no** raw prompts, secrets, or session ids. |
+| `provider_profile` | enum | session | `grok-oauth-proxy` \| `default` \| other registered provider. |
+| `adaptorch_transport` | optional | MCP grant | If absent, preview runs **local-only** (OMK compose + deterministic fallbacks). |
+| `lane_grants[]` | object[] | root coordinator | Each: scope, authority, skills, MCP, acceptance, evidence path. |
+| `budget_caps` | object | loop / goal | `max_lanes`, `max_dispatch_preview_calls`, wall-clock cap (immutable per preview instance). |
+
+**Hard input exclusions (never pass into AdaptOrch advisory or preview payloads):** prompt text/hash, file paths as bulk lists, model/provider identifiers in advisory bridge shape, session/user ids, tool names from live turns, hook stderr, credentials, `.env` material.
+
+---
+
+## Stage A — Signal intake and domain preview
+
+**Purpose:** Normalize the kickoff into scored domain signals and a confidence band before any external control-plane call.
+
+**Steps:**
+
+1. Lowercase and tokenize `task_text`; merge `path_hints` and `upstream_tags` into the scoring buffer.
+2. Score each registered domain profile (keyword, regex, extension, path triggers) per `loadout-domains` rules.
+3. Emit `domain_leader`, `confidence` (`confident` \| `tentative` \| `fallback`), and `ambiguous` flag (runner-up within margin).
+4. Attach recommended **read-only** skills tier (max 2–3) from domain + task class — do not bulk-load the catalog.
+
+**Outputs:** `PreviewSignalRecord { domain_id, confidence, ambiguous, suggested_skills[] }`.
+
+---
+
+## Stage B — Topology preview (AdaptOrch read/local)
+
+**Purpose:** Classify execution topology **without** submitting `adaptorch_run`.
+
+**Precondition:** `adaptorch_transport` granted **and** `payload_shape` is sanitized.
+
+**Steps:**
+
+1. Call `adaptorch_capabilities` once per preview session (cache TTL).
+2. Call `adaptorch_route_topology` with `{ payload_shape }`.
+3. Map classification to one of: `singleton`, `pipeline`, `DAG`, `ensemble` (closed enum).
+4. If transport missing: set `classification = unknown_local` and record `skipped_reason = no_verified_transport`.
+
+**Outputs:** `TopologyPreview { classification, raw_redacted_summary }`.
+
+---
+
+## Stage C — Lane grant and loadout compose
+
+**Purpose:** Turn topology + domain into non-overlapping lane grants for parallel workers.
+
+**Steps:**
+
+1. If `classification` is `DAG` or `ensemble`, decompose into lane candidates along **write-scope boundaries** (one writer per file).
+2. Compose each lane: `scope`, `authority`, `skills[]`, `mcp[]`, relevant hooks, `acceptance`, `evidence_output_path`.
+3. Run read-only authority stripping and always-on security hooks policy.
+4. Reject parallel grants that share the same write path.
+
+**Outputs:** `LaneGrantTable[]`, `compose_diagnostics[]`.
+
+---
+
+## Stage D — Dispatch cardinality preview
+
+**Purpose:** Preview how many `adaptorch_run` invocations a full loop **might** need without issuing them.
+
+**Steps:**
+
+1. Read `observed_cardinality_mode` if configured (`single_call` \| `fanout_n` \| `uncalibrated`).
+2. Under `single_call`: `expected_run_ids = 1` per dispatch record.
+3. Under `fanout_n`: derive N from topology template (ensemble = N parallel; pipeline = stage count) — **labeled as hypothesis** until calibrated.
+4. Flag `cardinality_anomaly` if prior observations disagree with mode.
+
+**Outputs:** `DispatchPreview { cardinality_mode, expected_run_ids, anomaly_flag }`.
+
+---
+
+## Stage E — Verification preview (adjudicator contract)
+
+**Purpose:** State what evidence the Outcome Adjudicator would require **before** any run exists.
+
+**Steps:**
+
+1. Select verifier registry entry by packet `kind` (string class, stable across retries).
+2. List required checks: terminal run status, artifact presence, trace sanity, scope/schema/content gates.
+3. Map foreseeable `reason_code` values to disposition classes (`escalate`, `reroute_on_recurrence`, `retry_same_topology`) — preview only, no `adjudicate()` call.
+
+**Outputs:** `VerificationPreview { kind, required_checks[], reason_code_map_summary }`.
+
+---
+
+## Stage F — Evidence and synthesis contract
+
+**Purpose:** Fix the artifact paths and synthesis inputs for the root coordinator.
+
+**Steps:**
+
+1. Require per-lane evidence files under `.omk/goals/<goal-id>/evidence/` (or lane grant path).
+2. Define synthesis inputs: explorer facts, planner DAG, tester output, reviewer verdict — **no** success claims without attached evidence class.
+3. Optional: if synthesis is explicitly authorized post-evidence, list allowed tools; else local `SYNTHESIS.md` merge.
+4. Emit `PreviewResult` bundle for operators and doc cross-links.
+
+**Outputs:** `PreviewResult`, pointers to `packages/coding-agent/docs/adaptorch-preview.md` and this file.
+
+---
+
+## Algorithm 1 — PreviewOrchestrate
+
+```
+function PreviewOrchestrate(inputs):
+  assert inputs.task_text is non-empty
+  A <- StageA_SignalIntake(inputs.task_text, inputs.path_hints, inputs.upstream_tags)
+  if inputs.adaptorch_transport is granted and inputs.payload_shape is sanitized:
+    B <- StageB_TopologyPreview(inputs.adaptorch_transport, inputs.payload_shape)
+  else:
+    B <- { classification: unknown_local, skipped_reason: transport_or_shape }
+  C <- StageC_ComposeLanes(A, B, inputs.lane_grants, inputs.budget_caps)
+  D <- StageD_DispatchCardinalityPreview(B, loop_config.observed_cardinality_mode)
+  E <- StageE_VerificationPreview(C.default_kind)
+  F <- StageF_EvidenceContract(inputs.goal_id, C.lanes)
+  return PreviewResult(A, B, C, D, E, F)
+```
+
+---
+
+## Algorithm 2 — TopologyClassifyPreview
+
+```
+function TopologyClassifyPreview(transport, payload_shape):
+  caps <- transport.call("adaptorch_capabilities", {})
+  if caps indicates unsupported connector:
+    return { classification: unknown_local, skipped_reason: capabilities }
+  raw <- transport.call("adaptorch_route_topology", { payload_shape: payload_shape })
+  class <- extract_enum(raw.classification, {singleton, pipeline, DAG, ensemble})
+  if class is missing:
+    return { classification: unknown_local, skipped_reason: unparseable }
+  return { classification: class, raw_redacted_summary: redact(raw) }
+```
+
+---
+
+## Algorithm 3 — ClaimSafeNarration
+
+```
+function ClaimSafeNarration(preview_result, utterance):
+  FORBIDDEN <- phrases implying production AdaptOrch execution without run evidence
+  ALLOWED <- planning, routing preview, lane grants, read/local tool names, fallback paths
+  if utterance matches any FORBIDDEN pattern:
+    return { ok: false, rewrite_hint: use ALLOWED framing + cite evidence path }
+  if utterance claims "done" or "verified":
+    require preview_result.F.evidence_paths exist and tester evidence class satisfied
+  return { ok: true, utterance }
+```
+
+---
+
+## Acceptance (Lane F)
+
+| Criterion | Evidence |
+| --- | --- |
+| This spec exists at the path above | read in session |
+| adaptorch-preview.md links here | link check in intro doc |
+| No adaptorch-wpl src edits | git status scoped to docs + goal only |
+| Algorithms 1–3 present as pseudocode | this file Algorithms section |

package/docs/adaptorch-preview.md

@@ -14,7 +14,7 @@ Do **not** treat preview output as proof that `adaptorch_run` completed; termina
 
 Related packages:
 
-- Experimental WPL loop design: `packages/adaptorch-wpl/` (design-stage; not wired into the default OMK CLI).
+- WPL loop package: `packages/adaptorch-wpl/` (stable since 0.91.0; ships with the CLI as a runtime dependency).
 - Advisory bridge (default-off): `packages/coding-agent/src/core/adaptorch-bridge.ts`.
 - Grok + AdaptOrch presets: [grok-harness.md](./grok-harness.md).
 
@@ -59,7 +59,7 @@ When in doubt, cite an evidence class from `AGENTS.md` (read, diff, test output,
 
 The canonical stage breakdown (Inputs, Stages A–F, Algorithms 1–3 as pseudocode) lives in the goal artifact:
 
-**[laneF-preview-spec.md](../../../.omk/goals/adaptorch-preview-omk-plan-2026-07-08/laneF-preview-spec.md)**
+**[adaptorch-preview-spec.md](./adaptorch-preview-spec.md)**
 
 Use that file for implementation planning; this page is the operator-facing intro and claim boundary.
 

package/docs/compaction.md

@@ -2,12 +2,12 @@
 
 LLMs have limited context windows. When conversations grow too long, omk uses compaction to summarize older content while preserving recent work. This page covers both auto-compaction and branch summarization.
 
-**Source files** ([omk-mono](https://github.com/earendil-works/omk-mono)):
-- [`packages/coding-agent/src/core/compaction/compaction.ts`](https://github.com/earendil-works/omk-mono/blob/main/packages/coding-agent/src/core/compaction/compaction.ts) - Auto-compaction logic
-- [`packages/coding-agent/src/core/compaction/branch-summarization.ts`](https://github.com/earendil-works/omk-mono/blob/main/packages/coding-agent/src/core/compaction/branch-summarization.ts) - Branch summarization
-- [`packages/coding-agent/src/core/compaction/utils.ts`](https://github.com/earendil-works/omk-mono/blob/main/packages/coding-agent/src/core/compaction/utils.ts) - Shared utilities (file tracking, serialization)
-- [`packages/coding-agent/src/core/session-manager.ts`](https://github.com/earendil-works/omk-mono/blob/main/packages/coding-agent/src/core/session-manager.ts) - Entry types (`CompactionEntry`, `BranchSummaryEntry`)
-- [`packages/coding-agent/src/core/extensions/types.ts`](https://github.com/earendil-works/omk-mono/blob/main/packages/coding-agent/src/core/extensions/types.ts) - Extension event types
+**Source files** ([omk-mono](https://github.com/dmae97/omk)):
+- [`packages/coding-agent/src/core/compaction/compaction.ts`](https://github.com/dmae97/omk/blob/main/packages/coding-agent/src/core/compaction/compaction.ts) - Auto-compaction logic
+- [`packages/coding-agent/src/core/compaction/branch-summarization.ts`](https://github.com/dmae97/omk/blob/main/packages/coding-agent/src/core/compaction/branch-summarization.ts) - Branch summarization
+- [`packages/coding-agent/src/core/compaction/utils.ts`](https://github.com/dmae97/omk/blob/main/packages/coding-agent/src/core/compaction/utils.ts) - Shared utilities (file tracking, serialization)
+- [`packages/coding-agent/src/core/session-manager.ts`](https://github.com/dmae97/omk/blob/main/packages/coding-agent/src/core/session-manager.ts) - Entry types (`CompactionEntry`, `BranchSummaryEntry`)
+- [`packages/coding-agent/src/core/extensions/types.ts`](https://github.com/dmae97/omk/blob/main/packages/coding-agent/src/core/extensions/types.ts) - Extension event types
 
 For TypeScript definitions in your project, inspect `node_modules/open-multi-agent-kit/dist/`.
 
@@ -67,7 +67,7 @@ By default, compaction uses the active session model. Set `compaction.model` to
 1. **Find cut point**: Walk backwards from newest message, accumulating token estimates until `keepRecentTokens` (default 20k, configurable in `~/.omk/agent/settings.json` or `<project-dir>/.omk/settings.json`) is reached
 2. **Extract messages**: Collect messages from the previous kept boundary (or session start) up to the cut point
 3. **Generate summary**: Call LLM to summarize with structured format, passing the previous summary as iterative context when present
-4. **Append entry**: Save `CompactionEntry` with summary and `firstKeptEntryId`
+4. **Sanitize and append**: Deterministically redact sensitive values, then save the `CompactionEntry` with its summary and `firstKeptEntryId`. Exact `[REDACTED]` assignment placeholders are valid; appended data and unredacted credential-shaped literals remain rejected.
 5. **Reload**: Session reloads, using summary + messages from `firstKeptEntryId` onwards
 
 ```
@@ -144,7 +144,7 @@ Never cut at tool results (they must stay with their tool call).
 
 ### CompactionEntry Structure
 
-Defined in [`session-manager.ts`](https://github.com/earendil-works/omk-mono/blob/main/packages/coding-agent/src/core/session-manager.ts):
+Defined in [`session-manager.ts`](https://github.com/dmae97/omk/blob/main/packages/coding-agent/src/core/session-manager.ts):
 
 ```typescript
 interface CompactionEntry<T = unknown> {
@@ -168,7 +168,7 @@ interface CompactionDetails {
 
 Extensions can store any JSON-serializable data in `details`. The default compaction tracks file operations, but custom extension implementations can use their own structure.
 
-See [`prepareCompaction()`](https://github.com/earendil-works/omk-mono/blob/main/packages/coding-agent/src/core/compaction/compaction.ts) and [`compact()`](https://github.com/earendil-works/omk-mono/blob/main/packages/coding-agent/src/core/compaction/compaction.ts) for the implementation.
+See [`prepareCompaction()`](https://github.com/dmae97/omk/blob/main/packages/coding-agent/src/core/compaction/compaction.ts) and [`compact()`](https://github.com/dmae97/omk/blob/main/packages/coding-agent/src/core/compaction/compaction.ts) for the implementation.
 
 ## Branch Summarization
 
@@ -211,7 +211,7 @@ This means file tracking accumulates across multiple compactions or nested branc
 
 ### BranchSummaryEntry Structure
 
-Defined in [`session-manager.ts`](https://github.com/earendil-works/omk-mono/blob/main/packages/coding-agent/src/core/session-manager.ts):
+Defined in [`session-manager.ts`](https://github.com/dmae97/omk/blob/main/packages/coding-agent/src/core/session-manager.ts):
 
 ```typescript
 interface BranchSummaryEntry<T = unknown> {
@@ -234,7 +234,7 @@ interface BranchSummaryDetails {
 
 Same as compaction, extensions can store custom data in `details`.
 
-See [`collectEntriesForBranchSummary()`](https://github.com/earendil-works/omk-mono/blob/main/packages/coding-agent/src/core/compaction/branch-summarization.ts), [`prepareBranchEntries()`](https://github.com/earendil-works/omk-mono/blob/main/packages/coding-agent/src/core/compaction/branch-summarization.ts), and [`generateBranchSummary()`](https://github.com/earendil-works/omk-mono/blob/main/packages/coding-agent/src/core/compaction/branch-summarization.ts) for the implementation.
+See [`collectEntriesForBranchSummary()`](https://github.com/dmae97/omk/blob/main/packages/coding-agent/src/core/compaction/branch-summarization.ts), [`prepareBranchEntries()`](https://github.com/dmae97/omk/blob/main/packages/coding-agent/src/core/compaction/branch-summarization.ts), and [`generateBranchSummary()`](https://github.com/dmae97/omk/blob/main/packages/coding-agent/src/core/compaction/branch-summarization.ts) for the implementation.
 
 ## Summary Format
 
@@ -278,7 +278,7 @@ path/to/changed.ts
 
 ### Message Serialization
 
-Before summarization, messages are serialized to text via [`serializeConversation()`](https://github.com/earendil-works/omk-mono/blob/main/packages/coding-agent/src/core/compaction/utils.ts):
+Before summarization, messages are serialized to text via [`serializeConversation()`](https://github.com/dmae97/omk/blob/main/packages/coding-agent/src/core/compaction/utils.ts):
 
 ```
 [User]: What they said
@@ -294,7 +294,7 @@ Tool results are truncated to 2000 characters during serialization. Content beyo
 
 ## Custom Summarization via Extensions
 
-Extensions can intercept and customize both compaction and branch summarization. See [`extensions/types.ts`](https://github.com/earendil-works/omk-mono/blob/main/packages/coding-agent/src/core/extensions/types.ts) for event type definitions.
+Extensions can intercept and customize both compaction and branch summarization. See [`extensions/types.ts`](https://github.com/dmae97/omk/blob/main/packages/coding-agent/src/core/extensions/types.ts) for event type definitions.
 
 ### session_before_compact
 

package/docs/correctness-wall.md

@@ -28,7 +28,7 @@ Structured next steps on the verdict card: **Apply**, **Deep Check**, **Regenera
 ## Fast wall vs deep wall
 
 - **Fast wall (default):** Pure policy — diff paths, scope globs, secret-shaped lines, preview-only limits (`BATCH1_NO_DOCKER_RUNNER`). No Docker runner in batch 1.
-- **Deep wall (Pro / future):** Hermetic paired base/patch replay. Today `deepWall: true` returns **unavailable** with the same batch-1 limit code.
+- **Deep wall (Pro / future):** Hermetic paired base/patch replay. Today `deepWall: true` returns **unavailable** (evidence-gated: requires a valid execution receipt per ALG-003 strict mode; no Docker runner wired in batch 1).
 
 ## Relationship to Adaptorch
 
@@ -74,7 +74,7 @@ The correctness wall is **not** part of the default `omk-core-verified` preset o
 | **Role loadouts** | `code` / `executor` lanes still get `pre-shell-guard`, `protect-secrets`, and `typecheck-after-edit`; the wall **adds** a pre-apply policy gate on `edit` / `write` only when the extension is loaded |
 | **Domain router** | No dedicated domain profile today; patch-safety work may route to [`ai-agent-ops`](./loadout-domains/ai-agent-ops.md) for harness/eval discipline, but that does **not** auto-load this extension |
 
-**Future hook (code, not batch-1):** `packages/coding-agent/src/core/domain-loadouts.ts` could gain triggers (e.g. `patch safety`, `correctness wall`) and a curated extension entry pointing at the correctness-wall example. Until then, document-only reference — do not hand-edit auto-generated files under `docs/loadout-domains/`.
+**Domain router triggers (implemented):** `packages/coding-agent/src/core/domain-loadouts.ts` already contains keyword triggers (`correctness wall`, `patch safety`) and a path trigger (`correctness-wall`) that route to the PATCH SAFETY domain profile. The profile instructs operators to load the correctness-wall extension explicitly (not in default preset) and follow the shadow → soft → hard rollout. Auto-generated docs under `docs/loadout-domains/` should be regenerated via `gen-domain-docs.mjs`, not hand-edited.
 
 Regression coverage for the wall library surface lives in `packages/coding-agent/test/suite/regressions/018-b2c-correctness-wall.test.ts` (imports `omk-adaptorch-wpl` the same way the extension does).
 
@@ -105,9 +105,17 @@ Goal orchestration v2 artifacts (planner P3) live beside batch-1 plan files:
 | Three-wave execution DAG (JSON) | `.omk/goals/b2c-correctness-wall-2026-07-08/dag-v2.json` |
 | Explorer: browser-smoke vs extension load + loadout gaps | `.omk/goals/b2c-correctness-wall-2026-07-08/laneE-explorer.md` |
 
-**Wave 2 (prove / integrate):** wire `AdaptOrchClient` on hooks when session has run context; lift `BATCH1_NO_DOCKER_RUNNER` for non-preview deep wall; optional preset documentation in `~/.omk/runtime-preset.json` comments only (no default-on extension).
-
-**Wave 3 (productize):** publish `omk-adaptorch-wpl` from `dist/` for out-of-monorepo extensions; optional `domain-loadouts.ts` profile + `gen-domain-docs.mjs` regen; default **soft** for internal dogfood presets after Wave 2 evidence.
+**Wave 2 (prove / integrate) — Partial:**
+- ✅ `domain-loadouts.ts` triggers for `correctness wall` / `patch safety` shipped (keyword + path patterns, PATCH SAFETY domain profile).
+- ✅ Evidence receipt v3 (ALG-003 15/15) gates deep-wall availability on valid execution receipts.
+- ⬜ `AdaptOrchClient` hook wiring when session has run context — not yet connected.
+- ⬜ Lift `BATCH1_NO_DOCKER_RUNNER` for non-preview deep wall — still stub.
+- ⬜ Preset documentation in `~/.omk/runtime-preset.json` — deferred.
+
+**Wave 3 (productize) — Not started:**
+- ⬜ Publish `omk-adaptorch-wpl` from `dist/` for out-of-monorepo extensions.
+- ✅ `domain-loadouts.ts` profile exists; `gen-domain-docs.mjs` regen pending.
+- ⬜ Default **soft** for internal dogfood presets after Wave 2 evidence.
 
 ## See also
 

package/docs/custom-provider.md

@@ -372,12 +372,12 @@ interface OAuthCredentials {
 For providers with non-standard APIs, implement `streamSimple`. Study the existing provider implementations before writing your own:
 
 **Reference implementations:**
-- [anthropic.ts](https://github.com/earendil-works/omk-mono/blob/main/packages/ai/src/providers/anthropic.ts) - Anthropic Messages API
-- [mistral.ts](https://github.com/earendil-works/omk-mono/blob/main/packages/ai/src/providers/mistral.ts) - Mistral Conversations API
-- [openai-completions.ts](https://github.com/earendil-works/omk-mono/blob/main/packages/ai/src/providers/openai-completions.ts) - OpenAI Chat Completions
-- [openai-responses.ts](https://github.com/earendil-works/omk-mono/blob/main/packages/ai/src/providers/openai-responses.ts) - OpenAI Responses API
-- [google.ts](https://github.com/earendil-works/omk-mono/blob/main/packages/ai/src/providers/google.ts) - Google Generative AI
-- [amazon-bedrock.ts](https://github.com/earendil-works/omk-mono/blob/main/packages/ai/src/providers/amazon-bedrock.ts) - AWS Bedrock
+- [anthropic.ts](https://github.com/dmae97/omk/blob/main/packages/ai/src/providers/anthropic.ts) - Anthropic Messages API
+- [mistral.ts](https://github.com/dmae97/omk/blob/main/packages/ai/src/providers/mistral.ts) - Mistral Conversations API
+- [openai-completions.ts](https://github.com/dmae97/omk/blob/main/packages/ai/src/providers/openai-completions.ts) - OpenAI Chat Completions
+- [openai-responses.ts](https://github.com/dmae97/omk/blob/main/packages/ai/src/providers/openai-responses.ts) - OpenAI Responses API
+- [google.ts](https://github.com/dmae97/omk/blob/main/packages/ai/src/providers/google.ts) - Google Generative AI
+- [amazon-bedrock.ts](https://github.com/dmae97/omk/blob/main/packages/ai/src/providers/amazon-bedrock.ts) - AWS Bedrock
 
 ### Stream Pattern
 
@@ -540,7 +540,7 @@ When a request exceeds the model's context window, omk can recover automatically
 Detection runs on the finalized assistant message:
 
 - `stopReason === "error"`
-- `errorMessage` matches one of omk's known overflow patterns (see [`packages/ai/src/utils/overflow.ts`](https://github.com/earendil-works/omk-mono/blob/main/packages/ai/src/utils/overflow.ts))
+- `errorMessage` matches one of omk's known overflow patterns (see [`packages/ai/src/utils/overflow.ts`](https://github.com/dmae97/omk/blob/main/packages/ai/src/utils/overflow.ts))
 
 If your provider returns overflow errors with a message omk does not recognize, normalize the error from the same extension that registers the provider. Use a `message_end` handler to rewrite the assistant message so its `errorMessage` starts with a phrase omk recognizes. The generic fallback `context_length_exceeded` is the safest choice.
 
@@ -603,7 +603,7 @@ omk.registerProvider("my-provider", {
 
 ## Testing Your Implementation
 
-Test your provider against the same test suites used by built-in providers. Copy and adapt these test files from [packages/ai/test/](https://github.com/earendil-works/omk-mono/tree/main/packages/ai/test):
+Test your provider against the same test suites used by built-in providers. Copy and adapt these test files from [packages/ai/test/](https://github.com/dmae97/omk/tree/main/packages/ai/test):
 
 | Test | Purpose |
 |------|---------|

package/docs/development.md

@@ -1,11 +1,11 @@
 # Development
 
-See [AGENTS.md](https://github.com/earendil-works/omk-mono/blob/main/AGENTS.md) for additional guidelines.
+See [AGENTS.md](https://github.com/dmae97/omk/blob/main/AGENTS.md) for additional guidelines.
 
 ## Setup
 
 ```bash
-git clone https://github.com/earendil-works/omk-mono
+git clone https://github.com/dmae97/omk
 cd omk-mono
 npm install
 npm run build

package/docs/extensions.md

@@ -1868,13 +1868,13 @@ See [examples/extensions/tool-override.ts](../examples/extensions/tool-override.
 **Your implementation must match the exact result shape**, including the `details` type. The UI and session logic depend on these shapes for rendering and state tracking.
 
 Built-in tool implementations:
-- [read.ts](https://github.com/earendil-works/omk-mono/blob/main/packages/coding-agent/src/core/tools/read.ts) - `ReadToolDetails`
-- [bash.ts](https://github.com/earendil-works/omk-mono/blob/main/packages/coding-agent/src/core/tools/bash.ts) - `BashToolDetails`
-- [edit.ts](https://github.com/earendil-works/omk-mono/blob/main/packages/coding-agent/src/core/tools/edit.ts)
-- [write.ts](https://github.com/earendil-works/omk-mono/blob/main/packages/coding-agent/src/core/tools/write.ts)
-- [grep.ts](https://github.com/earendil-works/omk-mono/blob/main/packages/coding-agent/src/core/tools/grep.ts) - `GrepToolDetails`
-- [find.ts](https://github.com/earendil-works/omk-mono/blob/main/packages/coding-agent/src/core/tools/find.ts) - `FindToolDetails`
-- [ls.ts](https://github.com/earendil-works/omk-mono/blob/main/packages/coding-agent/src/core/tools/ls.ts) - `LsToolDetails`
+- [read.ts](https://github.com/dmae97/omk/blob/main/packages/coding-agent/src/core/tools/read.ts) - `ReadToolDetails`
+- [bash.ts](https://github.com/dmae97/omk/blob/main/packages/coding-agent/src/core/tools/bash.ts) - `BashToolDetails`
+- [edit.ts](https://github.com/dmae97/omk/blob/main/packages/coding-agent/src/core/tools/edit.ts)
+- [write.ts](https://github.com/dmae97/omk/blob/main/packages/coding-agent/src/core/tools/write.ts)
+- [grep.ts](https://github.com/dmae97/omk/blob/main/packages/coding-agent/src/core/tools/grep.ts) - `GrepToolDetails`
+- [find.ts](https://github.com/dmae97/omk/blob/main/packages/coding-agent/src/core/tools/find.ts) - `FindToolDetails`
+- [ls.ts](https://github.com/dmae97/omk/blob/main/packages/coding-agent/src/core/tools/ls.ts) - `LsToolDetails`
 
 ### Remote Execution
 
@@ -1997,7 +1997,7 @@ export default function (omk: ExtensionAPI) {
 
 ### Custom Rendering
 
-Tools can provide `renderCall` and `renderResult` for custom TUI display. See [tui.md](tui.md) for the full component API and [tool-execution.ts](https://github.com/earendil-works/omk-mono/blob/main/packages/coding-agent/src/modes/interactive/components/tool-execution.ts) for how tool rows are composed.
+Tools can provide `renderCall` and `renderResult` for custom TUI display. See [tui.md](tui.md) for the full component API and [tool-execution.ts](https://github.com/dmae97/omk/blob/main/packages/coding-agent/src/modes/interactive/components/tool-execution.ts) for how tool rows are composed.
 
 By default, tool output is wrapped in a `Box` that handles padding and background. A defined `renderCall` or `renderResult` must return a `Component`. If a slot renderer is not defined, `tool-execution.ts` uses fallback rendering for that slot.
 

package/docs/json.md

@@ -8,7 +8,7 @@ Outputs all session events as JSON lines to stdout. Useful for integrating omk i
 
 ## Event Types
 
-Events are defined in [`AgentSessionEvent`](https://github.com/earendil-works/omk-mono/blob/main/packages/coding-agent/src/core/agent-session.ts#L102):
+Events are defined in [`AgentSessionEvent`](https://github.com/dmae97/omk/blob/main/packages/coding-agent/src/core/agent-session.ts#L102):
 
 ```typescript
 type AgentSessionEvent =
@@ -22,7 +22,7 @@ type AgentSessionEvent =
 
 `queue_update` emits the full pending steering and follow-up queues whenever they change. `compaction_start` and `compaction_end` cover both manual and automatic compaction.
 
-Base events from [`AgentEvent`](https://github.com/earendil-works/omk-mono/blob/main/packages/agent/src/types.ts#L179):
+Base events from [`AgentEvent`](https://github.com/dmae97/omk/blob/main/packages/agent/src/types.ts#L179):
 
 ```typescript
 type AgentEvent =
@@ -44,12 +44,12 @@ type AgentEvent =
 
 ## Message Types
 
-Base messages from [`packages/ai/src/types.ts`](https://github.com/earendil-works/omk-mono/blob/main/packages/ai/src/types.ts#L134):
+Base messages from [`packages/ai/src/types.ts`](https://github.com/dmae97/omk/blob/main/packages/ai/src/types.ts#L134):
 - `UserMessage` (line 134)
 - `AssistantMessage` (line 140)
 - `ToolResultMessage` (line 152)
 
-Extended messages from [`packages/coding-agent/src/core/messages.ts`](https://github.com/earendil-works/omk-mono/blob/main/packages/coding-agent/src/core/messages.ts#L29):
+Extended messages from [`packages/coding-agent/src/core/messages.ts`](https://github.com/dmae97/omk/blob/main/packages/coding-agent/src/core/messages.ts#L29):
 - `BashExecutionMessage` (line 29)
 - `CustomMessage` (line 46)
 - `BranchSummaryMessage` (line 55)

package/docs/provider-resilience.md

@@ -0,0 +1,87 @@
+# Provider resilience (root-level)
+
+Built into OMK core — not an optional extension.
+
+## What it does
+
+1. **Blocks sticky safety models** (e.g. `claude-fable-5`) from being selected as the session chat model.
+2. **Ejects** them at prompt time if a resumed session still has one loaded.
+3. On **content/safety stop** (`stop_reason=refusal`), **auto-failovers** to `k3 → grok-4.5 → deepseek` before retry.
+4. Works with message sanitize (`transform-messages` orphan `tool_call_id` drop) so K3 protocol 400s can heal on retry.
+
+This is session survival engineering, not a jailbreak.
+
+## Settings (`~/.omk/agent/settings.json`)
+
+```json
+{
+  "defaultProvider": "kimi-coding",
+  "defaultModel": "k3",
+  "providerResilience": {
+    "blockStickySafetyModels": true,
+    "autoFailoverOnSafetyStop": true,
+    "failoverCandidates": [
+      { "provider": "kimi-coding", "id": "k3" },
+      { "provider": "grok-oauth-proxy", "id": "grok-4.5" },
+      { "provider": "deepseek", "id": "deepseek-v4-pro" }
+    ]
+  }
+}
+```
+
+| Key | Default | Meaning |
+|---|---|---|
+| `blockStickySafetyModels` | `true` | Refuse `setModel` / initial pick of Fable-class ids |
+| `autoFailoverOnSafetyStop` | `true` | Switch model before auto-retry on safety stop |
+| `failoverCandidates` | k3→grok→deepseek… | Ordered targets |
+
+Disable only if you intentionally want Fable:
+
+```json
+"providerResilience": { "blockStickySafetyModels": false, "autoFailoverOnSafetyStop": false }
+```
+
+## Code
+
+| Module | Role |
+|---|---|
+| `src/core/provider-resilience.ts` | Shared detectors + failover pick |
+| `src/core/agent-session.ts` | eject / failover / retry wiring |
+| `src/core/model-resolver.ts` | skip sticky on initial model pick |
+| `src/core/settings-manager.ts` | `providerResilience` settings |
+| `packages/ai/.../transform-messages.ts` | drop orphan tool results |
+
+## How Fable is neutralized (not "jailbroken")
+
+Server-side content/safety stops cannot be removed by OAuth RE or local patches.
+OMK **deletes Fable from the operational surface**:
+
+| Layer | Kill switch |
+|---|---|
+| `models.json` | `claude-fable-5` removed from anthropic catalog |
+| `model-registry.loadModels` | `/fable/i` filtered unless `OMK_ALLOW_STICKY_SAFETY_MODELS=1` |
+| `model-resolver` | sticky skipped; k3 preferred |
+| `setModel` | throws if sticky + block on |
+| `cycleModel` (scoped + available) | sticky filtered; goes through `setModel` |
+| prompt boundary | ejects leftover Fable session model → k3 |
+| safety-stop retry | failover chain before continue |
+
+**You don't fight Fable. You never load it.**
+
+## Operator
+
+```
+# after rebuild — restart OMK session (required)
+
+/model k3          # if still on a bad model
+/new               # if transcript is corrupted (orphan tool ids)
+
+# emergency re-enable Fable (not recommended)
+OMK_ALLOW_STICKY_SAFETY_MODELS=1 omk
+# and settings: providerResilience.blockStickySafetyModels=false
+```
+
+## arXiv note (2026-07)
+
+Recent cs.CL hits on refusal/jailbreak are mostly attack-ASR / weight-edit / prefill studies.
+No immediate ops patch beyond routing+sanitize already in-tree. Skip theory-only papers.

package/docs/providers.md

@@ -89,7 +89,7 @@ omk
 | Xiaomi MiMo Token Plan (Singapore) | `XIAOMI_TOKEN_PLAN_SGP_API_KEY` | `xiaomi-token-plan-sgp` |
 | Zyloo | `ZYLOO_API_KEY` | `zyloo` |
 
-Reference for environment variables and `auth.json` keys: [`const envMap`](https://github.com/earendil-works/omk-mono/blob/main/packages/ai/src/env-api-keys.ts) in [`packages/ai/src/env-api-keys.ts`](https://github.com/earendil-works/omk-mono/blob/main/packages/ai/src/env-api-keys.ts).
+Reference for environment variables and `auth.json` keys: [`const envMap`](https://github.com/dmae97/omk/blob/main/packages/ai/src/env-api-keys.ts) in [`packages/ai/src/env-api-keys.ts`](https://github.com/dmae97/omk/blob/main/packages/ai/src/env-api-keys.ts).
 
 #### Zyloo
 

package/docs/session-format.md

@@ -28,11 +28,11 @@ Existing sessions are automatically migrated to the current version (v3) when lo
 
 ## Source Files
 
-Source on GitHub ([omk-mono](https://github.com/earendil-works/omk-mono)):
-- [`packages/coding-agent/src/core/session-manager.ts`](https://github.com/earendil-works/omk-mono/blob/main/packages/coding-agent/src/core/session-manager.ts) - Session entry types and SessionManager
-- [`packages/coding-agent/src/core/messages.ts`](https://github.com/earendil-works/omk-mono/blob/main/packages/coding-agent/src/core/messages.ts) - Extended message types (BashExecutionMessage, CustomMessage, etc.)
-- [`packages/ai/src/types.ts`](https://github.com/earendil-works/omk-mono/blob/main/packages/ai/src/types.ts) - Base message types (UserMessage, AssistantMessage, ToolResultMessage)
-- [`packages/agent/src/types.ts`](https://github.com/earendil-works/omk-mono/blob/main/packages/agent/src/types.ts) - AgentMessage union type
+Source on GitHub ([omk-mono](https://github.com/dmae97/omk)):
+- [`packages/coding-agent/src/core/session-manager.ts`](https://github.com/dmae97/omk/blob/main/packages/coding-agent/src/core/session-manager.ts) - Session entry types and SessionManager
+- [`packages/coding-agent/src/core/messages.ts`](https://github.com/dmae97/omk/blob/main/packages/coding-agent/src/core/messages.ts) - Extended message types (BashExecutionMessage, CustomMessage, etc.)
+- [`packages/ai/src/types.ts`](https://github.com/dmae97/omk/blob/main/packages/ai/src/types.ts) - Base message types (UserMessage, AssistantMessage, ToolResultMessage)
+- [`packages/agent/src/types.ts`](https://github.com/dmae97/omk/blob/main/packages/agent/src/types.ts) - AgentMessage union type
 
 For TypeScript definitions in your project, inspect `node_modules/open-multi-agent-kit/dist/` and `node_modules/omk-ai/dist/`.
 

package/docs/settings.md

@@ -20,6 +20,8 @@ Edit directly or use `/settings` for common options.
 | `defaultThinkingLevel` | string | - | `"off"`, `"minimal"`, `"low"`, `"medium"`, `"high"`, `"xhigh"` |
 | `hideThinkingBlock` | boolean | `false` | Hide thinking blocks in output |
 | `thinkingBudgets` | object | - | Custom token budgets per thinking level |
+| `reasoningRouterLearning` | object | - | Opt-in v4 router learning bias (global settings file only) |
+| `adaptorchBridge` | object | - | Opt-in AdaptOrch advisory bridge for the auto thinking-level resolver (global settings file only) |
 
 #### thinkingBudgets
 
@@ -34,6 +36,34 @@ Edit directly or use `/settings` for common options.
 }
 ```
 
+#### reasoningRouterLearning
+
+```json
+{
+  "reasoningRouterLearning": {
+    "enabled": false,
+    "biasSnapshotPath": "~/.omk/agent/router-bias.json",
+    "feedbackLedgerPath": "~/.omk/agent/router-feedback.jsonl"
+  }
+}
+```
+
+#### adaptorchBridge
+
+Advisory-only hint source for the v4 auto thinking-level resolver. Read from the **global** settings file only — a project-scope `.omk/settings.json` value is ignored by design. Default is fully off; the bridge is circuit-breaker protected and TTL-cached, and its hint can only nudge the resolved level by a bounded ±2 steps.
+
+```json
+{
+  "adaptorchBridge": {
+    "enabled": false,
+    "ttlMs": 300000,
+    "timeoutMs": 1500,
+    "maxConsultsPerSession": 5,
+    "failureThreshold": 3
+  }
+}
+```
+
 ### UI & Display
 
 | Setting | Type | Default | Description |

package/docs/skills.md

@@ -4,6 +4,8 @@
 
 Skills are self-contained capability packages that the agent loads on-demand. A skill provides specialized workflows, setup instructions, helper scripts, and reference documentation for specific tasks.
 
+OMK ships with **no built-in skills** — every skill is user-installed via the locations below, an OMK package, or `--skill`. The default session has zero skills and zero MCP servers configured.
+
 OMK implements the [Agent Skills standard](https://agentskills.io/specification), warning about most violations but remaining lenient. OMK allows skill names to differ from their parent directory even though the standard disallows it; that rule is suboptimal for shared skill directories used across multiple agent harnesses.
 
 ## Table of Contents