open-multi-agent-kit 0.80.7 → 0.80.8

package/docs/loadout-domains/mobile.md

@@ -0,0 +1,84 @@
+# Mobile (iOS / Android / KMP) (`mobile`)
+
+> Inherited domain capability document. Auto-generated from `src/core/domain-loadouts.ts` — do not edit by hand.
+
+
+## Identity
+
+| field | value |
+|---|---|
+| id | `mobile` |
+| authority | `write-scoped` |
+| tools | read, grep, find, ls, edit, write, bash |
+| command mode | `scoped-shell` |
+
+## Routing prompt
+
+> Prepended to the lane task prompt when the router selects this domain.
+
+```text
+DOMAIN: Mobile (iOS / Android / KMP). You are operating in a mobile capability lane.
+Prioritize platform idiom, main-thread performance, and on-device correctness.
+
+SEQUENCE:
+1. Identify the stack (SwiftUI / UIKit / Jetpack Compose / KMP / React Native / Flutter) and follow its idioms strictly.
+2. iOS: swiftui-patterns + swift-concurrency-6-2 (structured concurrency, actor isolation). Persistence via swift-actor-persistence; testing via swift-protocol-di-testing. Use liquid-glass-design + foundation-models-on-device for iOS 26 features.
+3. Android/KMP: android-clean-architecture (module boundaries, UseCase/Repository), compose-multiplatform-patterns, kotlin-coroutines-flows for async. Verify with kotlin-testing.
+4. Performance: react-native-best-practices for RN (Hermes, FlashList, JS-thread); profile jank, never block the main thread, hoist heavy work off-thread.
+5. Accessibility: accessibility-audit — Dynamic Type / VoiceOver / TalkBack, hit-target sizes, labeled controls.
+6. Build gate: typecheck-after-edit must pass; prefer the platform's native test runner over ad-hoc scripts.
+
+HARD RULES: no main-thread blocking; respect safe areas / insets / notches; lifecycle-aware state; pin toolchain versions (gradle/xcode) explicitly.
+```
+
+## Curated skills (16)
+
+- `swiftui-patterns`
+- `swiftui-ui-patterns`
+- `swift-actor-persistence`
+- `swift-concurrency-6-2`
+- `swift-protocol-di-testing`
+- `foundation-models-on-device`
+- `liquid-glass-design`
+- `android-clean-architecture`
+- `compose-multiplatform-patterns`
+- `kotlin-patterns`
+- `kotlin-coroutines-flows`
+- `kotlin-testing`
+- `kotlin-exposed-patterns`
+- `kotlin-ktor-patterns`
+- `react-native-best-practices`
+- `accessibility-audit`
+
+## Curated MCP servers (3)
+
+- `filesystem`
+- `chrome-devtools`
+- `context7`
+
+## Curated hooks (3)
+
+- `typecheck-after-edit`
+- `pre-shell-guard`
+- `protect-secrets`
+
+## Routing triggers (16)
+
+| kind | pattern | weight |
+|---|---|---|
+| keyword | `ios` | 6 |
+| keyword | `android` | 6 |
+| keyword | `mobile` | 6 |
+| keyword | `swift` | 6 |
+| keyword | `swiftui` | 7 |
+| keyword | `kotlin` | 6 |
+| keyword | `compose` | 5 |
+| keyword | `kmp` | 6 |
+| keyword | `react native` | 6 |
+| keyword | `expo` | 5 |
+| keyword | `flutter` | 6 |
+| regex | `\b(viewcontroller|uiview|jetpack|gradle|xcode)\b` | 6 |
+| extension | `.swift` | 8 |
+| extension | `.kt` | 7 |
+| path | `android/app` | 6 |
+| path | `ios/` | 6 |

package/docs/loadout-domains/qa-testing.md

@@ -0,0 +1,87 @@
+# QA & Testing (`qa-testing`)
+
+> Inherited domain capability document. Auto-generated from `src/core/domain-loadouts.ts` — do not edit by hand.
+
+
+## Identity
+
+| field | value |
+|---|---|
+| id | `qa-testing` |
+| authority | `execute-tests` |
+| tools | read, grep, find, ls, bash |
+| command mode | `tests-only` |
+
+## Routing prompt
+
+> Prepended to the lane task prompt when the router selects this domain.
+
+```text
+DOMAIN: QA & Testing. You are operating in an execute-tests lane.
+Prioritize real evidence (green runs, captured output) over claims.
+
+SEQUENCE:
+1. Reproduce first: never fix a test you have not seen fail. Capture the exact failure output.
+2. New behavior: test-driven-development / tdd-workflow (red->green->refactor). tdd-write-tests for coverage of uncommitted changes; tdd-fix-tests to make the suite green after a change.
+3. Web QA: browser-qa / webapp-testing with playwright + chrome-devtools MCP (navigate, interact, screenshot, assert). e2e-testing for Page Object Model + CI wiring + flake strategy.
+4. React: react-doctor (lint/a11y/bundle/arch + regression check) before declaring healthy.
+5. Regression safety: ai-regression-testing for sandbox-mode API tests without DB deps; verification-before-completion requires a passing command before any "done" claim.
+6. Flakiness: quarantine or fix, never disable silently; record the root cause.
+
+HARD RULES: tests-only command mode (no arbitrary shell); every fix is re-verified by a green run; coverage gaps are reported, not hidden; flaky tests are rooted, not retried blindly.
+```
+
+## Curated skills (16)
+
+- `ai-regression-testing`
+- `e2e-testing`
+- `tdd-workflow`
+- `test-driven-development`
+- `tdd-fix-tests`
+- `tdd-write-tests`
+- `react-doctor`
+- `web-quality-audit`
+- `audit-and-fix`
+- `browser-qa`
+- `webapp-testing`
+- `verification-before-completion`
+- `verification-loop`
+- `playwright-cli`
+- `gstack-qa`
+- `gstack-qa-only`
+
+## Curated MCP servers (3)
+
+- `playwright`
+- `chrome-devtools`
+- `filesystem`
+
+## Curated hooks (3)
+
+- `stop-verify`
+- `pre-shell-guard`
+- `protect-secrets`
+
+## Routing triggers (19)
+
+| kind | pattern | weight |
+|---|---|---|
+| keyword | `test` | 4 |
+| keyword | `testing` | 5 |
+| keyword | `qa` | 6 |
+| keyword | `bug` | 4 |
+| keyword | `regression` | 6 |
+| keyword | `e2e` | 7 |
+| keyword | `playwright` | 7 |
+| keyword | `vitest` | 6 |
+| keyword | `jest` | 5 |
+| keyword | `pytest` | 6 |
+| keyword | `coverage` | 5 |
+| keyword | `fix test` | 5 |
+| keyword | `failing` | 4 |
+| keyword | `flaky` | 6 |
+| regex | `\b(unit test|integration test|snapshot|mock|fixture)\b` | 5 |
+| path | `test/` | 5 |
+| path | `tests/` | 5 |
+| path | `.test.` | 5 |
+| path | `.spec.` | 5 |

package/docs/loadout-domains/research.md

@@ -0,0 +1,80 @@
+# Research & Investigation (`research`)
+
+> Inherited domain capability document. Auto-generated from `src/core/domain-loadouts.ts` — do not edit by hand.
+
+
+## Identity
+
+| field | value |
+|---|---|
+| id | `research` |
+| authority | `read-only` |
+| tools | read, grep, find, ls |
+| command mode | `read-only-shell` |
+
+## Routing prompt
+
+> Prepended to the lane task prompt when the router selects this domain.
+
+```text
+DOMAIN: Research & Investigation. You are operating in a read-only research lane.
+Prioritize sourced, cited, reproducible findings over speculation.
+
+SEQUENCE:
+1. Decompose the question into sub-queries. Gather with the right source: arxiv-database / pubmed-database for academic, exa-search + firecrawl + fetch for web/github, market-research for commercial intel.
+2. literature-review for systematic synthesis (PRISMA where applicable, verified citations, dedupe).
+3. Evaluate evidence quality with scientific-critical-thinking (GRADE / risk of bias) before trusting a source.
+4. Hypothesis generation when the goal is ideation; competitive-analysis when positioning a product.
+5. Persist durable findings to memory + obsidian with source URLs and access dates; never store secrets or private PII.
+
+HARD RULES: every claim has a citation; distinguish evidence vs inference explicitly; prefer primary/official sources; flag when evidence is thin rather than confabulating. Read-only: do not modify the codebase.
+```
+
+## Curated skills (13)
+
+- `deep-research`
+- `literature-review`
+- `market-research`
+- `exa-search`
+- `best-practice-research`
+- `arxiv-database`
+- `pubmed-database`
+- `scientific-brainstorming`
+- `hypothesis-generation`
+- `scientific-critical-thinking`
+- `competitive-analysis`
+- `content-strategy`
+- `analyze`
+
+## Curated MCP servers (5)
+
+- `firecrawl`
+- `fetch`
+- `github`
+- `memory`
+- `obsidian`
+
+## Curated hooks (2)
+
+- `session-context`
+- `precompact-checkpoint`
+
+## Routing triggers (15)
+
+| kind | pattern | weight |
+|---|---|---|
+| keyword | `research` | 6 |
+| keyword | `investigate` | 5 |
+| keyword | `literature` | 6 |
+| keyword | `survey` | 4 |
+| keyword | `compare` | 3 |
+| keyword | `market` | 4 |
+| keyword | `competitor` | 5 |
+| keyword | `paper` | 5 |
+| keyword | `arxiv` | 7 |
+| keyword | `pubmed` | 7 |
+| keyword | `summarize` | 3 |
+| keyword | `sources` | 4 |
+| keyword | `cite` | 4 |
+| regex | `\b(state of the art|sota|benchmark|related work)\b` | 5 |
+| regex | `\b(find out|look up|what does|why does)\b` | 2 |

package/docs/loadout-domains/security-audit.md

@@ -0,0 +1,97 @@
+# Security Audit (`security-audit`)
+
+> Inherited domain capability document. Auto-generated from `src/core/domain-loadouts.ts` — do not edit by hand.
+
+
+## Identity
+
+| field | value |
+|---|---|
+| id | `security-audit` |
+| authority | `security-review` |
+| tools | read, grep, find, ls, bash |
+| command mode | `read-only-shell` |
+
+## Routing prompt
+
+> Prepended to the lane task prompt when the router selects this domain.
+
+```text
+DOMAIN: Security Audit. You are operating in a security-review lane (read-biased, evidence-bound).
+Prioritize true-positive findings with proof, exact locations, and remediation.
+
+SEQUENCE:
+1. Scope the audit: read entry-point-analyzer output (externally callable, state-changing surfaces) before reading internals.
+2. Build deep context with audit-context-building; shallow reads miss cross-file data flow.
+3. Run static analysis: semgrep (custom rules via semgrep-rule-creator) + codeql for inter-procedural taint. Parse results with sarif-parsing and dedupe.
+4. Verify every candidate with fp-check — return TRUE/FALSE POSITIVE with evidence, never a bare "might be vulnerable".
+5. Differential scope: differential-review on the diff/PR, not just the whole tree, to catch regressions.
+6. Domain lenses: constant-time-analysis + zeroize-audit for crypto; supply-chain-risk-auditor for deps; agentic-actions-auditor for CI/LLM-agent workflows; sharp-edges + insecure-defaults for misuse-prone APIs.
+7. After fixes: variant-analysis to find the same bug class elsewhere.
+
+HARD RULES: read-only by default; every finding needs file:line + exploit sketch + fix; rank by real exploitability not CWE count; secrets are reported, never printed (protect-secrets hook).
+```
+
+## Curated skills (23)
+
+- `security-review`
+- `security-scan`
+- `differential-review`
+- `semgrep`
+- `codeql`
+- `sarif-parsing`
+- `semgrep-rule-creator`
+- `sharp-edges`
+- `supply-chain-risk-auditor`
+- `spec-to-code-compliance`
+- `entry-point-analyzer`
+- `audit-context-building`
+- `fp-check`
+- `constant-time-analysis`
+- `zeroize-audit`
+- `agentic-actions-auditor`
+- `insecure-defaults`
+- `property-based-testing`
+- `variant-analysis`
+- `yara-rule-authoring`
+- `code-maturity-assessor`
+- `django-security`
+- `springboot-security`
+
+## Curated MCP servers (3)
+
+- `filesystem`
+- `github`
+- `memory`
+
+## Curated hooks (4)
+
+- `pre-shell-guard`
+- `protect-secrets`
+- `stop-verify`
+- `subagent-stop-audit`
+
+## Routing triggers (20)
+
+| kind | pattern | weight |
+|---|---|---|
+| keyword | `security` | 6 |
+| keyword | `vulnerability` | 6 |
+| keyword | `vuln` | 6 |
+| keyword | `exploit` | 6 |
+| keyword | `audit` | 5 |
+| keyword | `cve` | 7 |
+| keyword | `xss` | 6 |
+| keyword | `csrf` | 6 |
+| keyword | `injection` | 6 |
+| keyword | `secret` | 5 |
+| keyword | `leak` | 5 |
+| keyword | `crypto` | 4 |
+| keyword | `hardening` | 5 |
+| keyword | `threat` | 5 |
+| keyword | `penetration` | 6 |
+| keyword | `malware` | 6 |
+| keyword | `supply chain` | 6 |
+| regex | `sql[ -]?inj|command[ -]?inj|path[ -]?traversal` | 7 |
+| regex | `cve-\d{4}-\d+` | 8 |
+| regex | `\b(authz|rbac|privilege escalation|idor)\b` | 6 |

package/docs/packages.md

@@ -19,20 +19,6 @@ OMK packages bundle extensions, skills, prompt templates, and themes so you can
 
 > **Security:** OMK packages run with full system access. Extensions execute arbitrary code, and skills can instruct the model to perform any action including running executables. Review source code before installing third-party packages.
 
-> **Lifecycle scripts:** By default, `install` and `update` run with `--ignore-scripts`, so package `preinstall`/`install`/`postinstall` scripts do not execute. Only opt a reviewed package in via the `install.allowScripts` allowlist or `omk install --allow-scripts <name>`. Entries are exact-match identities/specs (`npm:@scope/pkg`, `npm:@scope/pkg@1.2.3`, `git:github.com/org/repo`) — no glob, semver range, download count, or gallery popularity is ever used, and entries are never added silently. The allowlist is per install unit: when allowed, lifecycle scripts for the entire dependency tree may run (package managers cannot scope script execution to a single top-level package). A mixed install where any top-level spec is not listed stays fail-closed under `--ignore-scripts`. This is independent of gallery `code-execution` trust; the source-review warning above still applies.
-
-Manual settings example:
-
-```json
-{
-  "install": {
-    "allowScripts": ["npm:@scope/pkg", "git:github.com/org/repo"]
-  }
-}
-```
-
-Project `install.allowScripts` overrides the user array; set it to `[]` in a project to block all lifecycle scripts for that repo. Use `-l` with `--allow-scripts` to persist the entry to project settings (`.omk/settings.json`) instead of user settings.
-
 ```bash
 omk install npm:@foo/bar@1.0.0
 omk install git:github.com/user/repo@v1
@@ -42,17 +28,15 @@ omk install ./relative/path/to/package
 
 omk remove npm:@foo/bar
 omk list                     # show installed packages from settings
-omk update                   # update OMK packages/extensions and OMK 본체 when supported
-omk update --extensions      # update OMK packages/extensions only; skip OMK 본체
-omk update --self            # update OMK 본체 only
-omk update --self --force    # reinstall OMK 본체 even if current
-omk update npm:@foo/bar      # update one OMK package
+omk update                   # update omk, update packages, and reconcile pinned git refs
+omk update --extensions      # update packages and reconcile pinned git refs only
+omk update --self            # update omk only
+omk update --self --force    # reinstall omk even if current
+omk update npm:@foo/bar      # update one package
 omk update --extension npm:@foo/bar
 ```
 
-Except for `omk update --self` and `omk update omk`, these commands manage OMK packages, not `OMK 본체` (the main OMK CLI). To uninstall `OMK 본체`, see [Quickstart](quickstart.md#uninstall).
-
-`omk update` reports separate `OMK 본체` and `OMK packages/extensions` results. The default command exits 0 when OMK packages/extensions update successfully, even if `OMK 본체` reports `unsupported` because the installation is managed by a source checkout, package manager, or wrapper. It exits 1 when OMK packages/extensions fail or when an attempted `OMK 본체` update fails. `omk update --self` and `omk update omk` target `OMK 본체` only, so `unsupported` exits 1 there.
+These commands manage omk packages, not the omk CLI installation. To uninstall omk itself, see [Quickstart](quickstart.md#uninstall).
 
 By default, `install` and `remove` write to user settings (`~/.omk/agent/settings.json`). Use `-l` to write to project settings (`.omk/settings.json`) instead. Project settings can be shared with your team, and omk installs any missing packages automatically on startup.
 
@@ -63,31 +47,6 @@ omk -e npm:@foo/bar
 omk -e git:github.com/user/repo
 ```
 
-### Built-in MCP presets
-
-OMK ships read-only metadata for selected MCP server presets. These presets are not bundled dependencies and are not started automatically; they give `/mcp` an exact-pinned configuration hint while keeping secrets out of the UI.
-
-#### Korean Law MCP
-
-The built-in `korean-law` preset targets [`korean-law-mcp`](https://github.com/chrisryugj/korean-law-mcp) `4.4.0` (MIT, upstream tag `v4.4.0`, commit `2ef8f1827d349381fc2bde15120c803fd2e7bfed`). It uses stdio via an exact npm pin:
-
-```json
-{
-  "mcpServers": {
-    "korean-law": {
-      "command": "npx",
-      "args": ["-y", "korean-law-mcp@4.4.0"],
-      "env": {
-        "LAW_OC": "${LAW_OC}"
-      },
-      "startup_timeout_sec": 30
-    }
-  }
-}
-```
-
-Set `LAW_OC` (or `KOREAN_LAW_API_KEY`, if your MCP client inherits shell env) through your shell or secret manager. OMK's `/mcp` inventory displays only env key names, never env values.
-
 ## Package Sources
 
 OMK accepts three source types in settings and `omk install`.
@@ -207,7 +166,7 @@ If no `omk` manifest is present, omk auto-discovers resources from these directo
 
 Third party runtime dependencies belong in `dependencies` in `package.json`. Dependencies that do not register extensions, skills, prompt templates, or themes also belong in `dependencies`. When omk installs a package from npm or git, it runs `npm install`, so those dependencies are installed automatically.
 
-OMK bundles core packages for extensions and skills. If you import any of these, list them in `peerDependencies` with a `"*"` range and do not bundle them: `@earendil-works/omk-ai`, `@earendil-works/omk-agent-core`, `open-multi-agent-kit`, `@earendil-works/omk-tui`, `typebox`.
+OMK bundles core packages for extensions and skills. If you import any of these, list them in `peerDependencies` with a `"*"` range and do not bundle them: `omk-ai`, `omk-agent-core`, `open-multi-agent-kit`, `omk-tui`, `typebox`.
 
 Other omk packages must be bundled in your tarball. Add them to `dependencies` and `bundledDependencies`, then reference their resources through `node_modules/` paths. OMK loads packages with separate module roots, so separate installs do not collide or share modules.
 

package/docs/prompt-templates.md

@@ -4,8 +4,6 @@
 
 Prompt templates are Markdown snippets that expand into full prompts. Type `/name` in the editor to invoke a template, where `name` is the filename without `.md`.
 
-**Parent rules apply**: Any GOD Mode / jailbreak content in templates is subject to the same detection and refusal as AGENTS.md / CLAUDE.md (see usage.md and root AGENTS.md PARENT section).
-
 ## Locations
 
 OMK loads prompt templates from:

package/docs/sdk.md

@@ -239,7 +239,7 @@ Both `steer()` and `followUp()` expand file-based prompt templates but error on
 
 ### Agent and AgentState
 
-The `Agent` class (from `@earendil-works/omk-agent-core`) handles the core LLM interaction. Access it via `session.agent`.
+The `Agent` class (from `omk-agent-core`) handles the core LLM interaction. Access it via `session.agent`.
 
 ```typescript
 // Access current state
@@ -368,7 +368,7 @@ When you pass a custom `ResourceLoader`, `cwd` and `agentDir` no longer control
 ### Model
 
 ```typescript
-import { getModel } from "@earendil-works/omk-ai";
+import { getModel } from "omk-ai";
 import { AuthStorage, ModelRegistry } from "open-multi-agent-kit";
 
 const authStorage = AuthStorage.create();
@@ -877,7 +877,7 @@ interface LoadExtensionsResult {
 ## Complete Example
 
 ```typescript
-import { getModel } from "@earendil-works/omk-ai";
+import { getModel } from "omk-ai";
 import { Type } from "typebox";
 import {
   AuthStorage,

package/docs/security.md

@@ -0,0 +1,145 @@
+# Extension Full-Access Threat Model
+
+> **Scope**: This document analyzes the security implications of OMK extensions that request `full-access` permissions. It applies to the OMK (Open Multi-Agent Kit) coding agent CLI and its extension runtime.
+>
+> **Version**: 0.80.3
+
+## 1. Overview
+
+OMK extensions can operate at different permission levels. The `full-access` level grants an extension unrestricted access to the OMK runtime, including the ability to:
+
+- Read and modify the agent's configuration (`~/.omk/agent/`)
+- Intercept and mutate tool calls and their results
+- Access session state, including conversation history
+- Execute arbitrary code within the extension's context
+- Register custom tools that run with the same privileges as built-in tools
+
+This document outlines the threat model for such extensions and provides guidance for users, extension developers, and security auditors.
+
+## 2. Threat Actors
+
+| Actor | Motivation | Capability |
+|-------|-----------|------------|
+| Malicious Extension Author | Data exfiltration, credential theft, supply-chain compromise | Distributes a seemingly benign extension with hidden malicious logic |
+| Compromised Extension Dependency | Indirect compromise via a dependency of a legitimate extension | Injects malicious code into a trusted extension's dependency tree |
+| Insider Threat | Espionage, sabotage, unauthorized data access | Installs or modifies an extension on a target's machine |
+| User (Self-Inflicted) | Accidental misconfiguration | Grants `full-access` to an untrusted extension without review |
+
+## 3. Attack Scenarios
+
+### 3.1 Configuration Exfiltration
+
+A `full-access` extension can read `~/.omk/agent/auth.json`, which contains API keys and OAuth tokens for LLM providers (e.g., `ANTHROPIC_API_KEY`, `OPENAI_API_KEY`).
+
+**Impact**: Credential theft leading to unauthorized LLM API usage, financial loss, or data leakage through the compromised API account.
+
+**Mitigation**:
+- Store auth credentials in OS keychain or encrypted vault rather than plaintext `auth.json` where possible.
+- Audit extensions before granting `full-access`.
+- Run extensions with restricted permissions if full access is not strictly required.
+
+### 3.2 Session Hijacking
+
+A malicious extension can intercept session `.jsonl` files in `~/.omk/agent/sessions/`, extracting conversation history, source code, and proprietary business logic discussed with the agent.
+
+**Impact**: Intellectual property theft, privacy violation, exposure of secrets mentioned in prompts.
+
+**Mitigation**:
+- Encrypt session files at rest.
+- Use sandboxed session directories per project.
+- Review extension code for file-system access patterns.
+
+### 3.3 Tool Call Interception and Mutation
+
+Extensions with `full-access` can wrap built-in tools (e.g., `bash`, `read`, `write`). A malicious wrapper could:
+- Log all `bash` commands and their outputs to a remote server.
+- Modify `write` tool calls to inject backdoors into source files.
+- Block `read` operations on sensitive files to hide evidence of tampering.
+
+**Impact**: Supply-chain compromise, data integrity loss, covert surveillance.
+
+**Mitigation**:
+- Use the `--no-extensions` flag when working with highly sensitive codebases.
+- Pin extension versions and review diffs on updates.
+- Run extensions in an isolated environment (container, VM) where feasible.
+
+### 3.4 Privilege Escalation via Custom Tools
+
+A `full-access` extension can register new tools that appear in the agent's tool list. These tools execute with the same privileges as the OMK process.
+
+**Impact**: Arbitrary code execution, system compromise if the agent process has elevated privileges.
+
+**Mitigation**:
+- Never run OMK as root or with sudo.
+- Use OS-level sandboxing (e.g., `sandbox-exec` on macOS, `seccomp` on Linux) for the OMK process.
+- Review the full source code of any extension before installation.
+
+### 3.5 Telemetry and Data Leakage
+
+Extensions can silently exfiltrate data via DNS queries, HTTP requests, or by writing to shared directories.
+
+**Impact**: Loss of confidentiality for proprietary code, conversation content, and system information.
+
+**Mitigation**:
+- Block outbound network access for the OMK process using a firewall or network namespace.
+- Monitor DNS and network traffic for anomalies.
+- Use offline mode (`--offline`) when extensions are not required to fetch remote resources.
+
+## 4. Default Sandbox Path
+
+OMK provides a default sandbox path for extensions that do not explicitly request `full-access`. This path restricts the extension to:
+
+- A dedicated subdirectory under `~/.omk/agent/extensions/<extension-name>/`
+- Read-only access to the project workspace (current working directory)
+- No access to `~/.omk/agent/auth.json`, `~/.omk/agent/mcp.json`, or session files
+- No network access (unless explicitly granted via extension manifest)
+
+**Default Sandbox Directory**: `~/.omk/agent/extensions/<extension-id>/`
+
+Extensions operating within this sandbox cannot:
+- Access files outside the project workspace and their own extension directory.
+- Intercept tool calls from other extensions or the core agent.
+- Read or write global agent configuration.
+
+## 5. Security Checklist for Users
+
+Before installing or upgrading a `full-access` extension, verify:
+
+- [ ] The extension source code is available and has been reviewed.
+- [ ] The extension is from a trusted author or has been audited by a third party.
+- [ ] The extension's `package.json` or manifest does not include unexpected dependencies.
+- [ ] The extension's network permissions (if any) are justified by its functionality.
+- [ ] You have a backup of `~/.omk/agent/` (especially `auth.json` and sessions).
+- [ ] You have considered running the extension in a sandboxed environment.
+
+## 6. Security Checklist for Extension Developers
+
+When building a `full-access` extension, adhere to:
+
+- [ ] **Principle of Least Privilege**: Only request `full-access` if absolutely necessary. Use the default sandbox for everything else.
+- [ ] **No Credential Access**: Never read `auth.json` or environment variables containing API keys unless the extension's core purpose is authentication management.
+- [ ] **Transparent Logging**: Log all file system and network operations to a user-visible location.
+- [ ] **Minimal Dependencies**: Keep the dependency tree small to reduce supply-chain risk.
+- [ ] **Signed Releases**: Provide cryptographic signatures for extension releases.
+- [ ] **Auditable Code**: Avoid obfuscation, minification, or dynamic code evaluation (`eval`, `new Function`).
+
+## 7. Incident Response
+
+If a malicious or compromised `full-access` extension is suspected:
+
+1. **Immediately revoke** any exposed API keys (check `auth.json` and provider dashboards).
+2. **Remove** the extension directory from `~/.omk/agent/extensions/`.
+3. **Audit** session files in `~/.omk/agent/sessions/` for leaked secrets or sensitive data.
+4. **Review** recent `bash` tool history and file modifications for unauthorized changes.
+5. **Re-install** OMK from a trusted source if the core runtime may have been tampered with.
+6. **Report** the incident to the OMK security team or open a confidential issue on the repository.
+
+## 8. References
+
+- OMK Extension Manifest Specification: `packages/coding-agent/docs/extensions.md`
+- OMK Session Format: `packages/coding-agent/docs/session-format.md`
+- OMK Settings and Configuration: `packages/coding-agent/docs/settings.md`
+
+---
+
+*Last updated: 2026-06-25*

package/docs/session-format.md

@@ -34,7 +34,7 @@ Source on GitHub ([omk-mono](https://github.com/earendil-works/omk-mono)):
 - [`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
 
-For TypeScript definitions in your project, inspect `node_modules/open-multi-agent-kit/dist/` and `node_modules/@earendil-works/omk-ai/dist/`.
+For TypeScript definitions in your project, inspect `node_modules/open-multi-agent-kit/dist/` and `node_modules/omk-ai/dist/`.
 
 ## Message Types
 

package/docs/themes.md

@@ -18,7 +18,7 @@ Themes are JSON files that define colors for the TUI.
 
 OMK loads themes from:
 
-- Built-in: `dark`, `light`, `catppuccin-mocha`, `dracula`, `gruvbox-dark`, `kanagawa-dragon`, `omk-control`, `omk-control-grid-dark`, `omk-control-light`, `omk-control-panel`, `rust-forge`, `tokyo-night-storm`
+- Built-in: `dark`, `light`, `omk-control`, `omk-control-grid-dark`, `omk-control-light`, `rust-forge`, plus bundled Tinted schemes (`catppuccin-mocha`, `tokyo-night-storm`, `kanagawa-dragon`, `gruvbox-dark`, `dracula`)
 - Global: `~/.omk/agent/themes/*.json`
 - Project: `.omk/themes/*.json`
 - Packages: `themes/` directories or `omk.themes` entries in `package.json`
@@ -37,7 +37,9 @@ Select a theme via `/settings` or in `settings.json`:
 }
 ```
 
-On first run, omk detects your terminal background and defaults to `omk-control-grid-dark` on dark terminals or `omk-control-light` on light terminals. `omk-control-grid-dark` is the dark control-grid palette; `control`, `night-city`, `night-city-ops`, `neon-grid`, `cyberpunk`, and `omk-control-dark` also resolve to it. `omk-control-panel` remains available via the `g0dm0d3`, `control-panel`, and `omk-control-ansi` aliases. Additional aliases include `catppuccin`/`mocha`, `tokyo-night`/`tokyo`, `kanagawa`, and `gruvbox`.
+On first run, omk detects your terminal background and defaults to `omk-control-grid-dark` on dark terminals or `omk-control-light` on light terminals. `omk-control-grid-dark` ports the OMK//CONTROL Night City TUI palette from the 0.78.8 visual console (`cyan`, `mint`, `magenta`, `purple`, `amber`, `red`, `cream`, `muted`, `gray` on `dark`/`surface`). The `rust-forge` and Tinted scheme themes are installed as additional selectable built-in themes, but they do not change the default OMK//CONTROL brand/tone.
+
+The bundled Tinted themes are generated from [`tinted-theming/schemes`](https://github.com/tinted-theming/schemes) Base24 palettes (MIT): Catppuccin Mocha, Tokyo Night Storm, Kanagawa Dragon, Gruvbox Dark, and Dracula.
 
 ## Creating a Custom Theme
 
@@ -293,13 +295,12 @@ echo $COLORTERM  # Should output "truecolor" or "24bit"
 See the built-in themes:
 - [dark.json](../src/modes/interactive/theme/dark.json)
 - [light.json](../src/modes/interactive/theme/light.json)
-- [catppuccin-mocha.json](../src/modes/interactive/theme/catppuccin-mocha.json)
-- [dracula.json](../src/modes/interactive/theme/dracula.json)
-- [gruvbox-dark.json](../src/modes/interactive/theme/gruvbox-dark.json)
-- [kanagawa-dragon.json](../src/modes/interactive/theme/kanagawa-dragon.json)
 - [omk-control.json](../src/modes/interactive/theme/omk-control.json)
 - [omk-control-grid-dark.json](../src/modes/interactive/theme/omk-control-grid-dark.json)
 - [omk-control-light.json](../src/modes/interactive/theme/omk-control-light.json)
-- [omk-control-panel.json](../src/modes/interactive/theme/omk-control-panel.json)
 - [rust-forge.json](../src/modes/interactive/theme/rust-forge.json)
+- [catppuccin-mocha.json](../src/modes/interactive/theme/catppuccin-mocha.json)
 - [tokyo-night-storm.json](../src/modes/interactive/theme/tokyo-night-storm.json)
+- [kanagawa-dragon.json](../src/modes/interactive/theme/kanagawa-dragon.json)
+- [gruvbox-dark.json](../src/modes/interactive/theme/gruvbox-dark.json)
+- [dracula.json](../src/modes/interactive/theme/dracula.json)