tools/ and toolsets.py.
→ Build a Mibyan Plugin — step-by-step guide with a complete working example.
Quick overview
Drop a directory into~/.mibyan/plugins/ with a plugin.yaml and Python code:
Minimal working example
Here is a complete plugin that adds ahello_world tool and logs every tool call via a hook.
~/.mibyan/plugins/hello-world/plugin.yaml
~/.mibyan/plugins/hello-world/__init__.py
~/.mibyan/plugins/hello-world/, restart Mibyan, and the model can immediately call hello_world. The hook prints a log line after every tool invocation.
The model-facing tool description belongs in schema["description"]. The optional ctx.register_tool(description=...) value is separate ToolEntry registry metadata: when omitted, it defaults to the schema description, but Mibyan does not copy it back into a schema that lacks description. Prefer defining the text once in the schema. If you provide both values, keep them synchronized; the model sees the schema value.
Project-local plugins under ./.mibyan/plugins/ are disabled by default. Enable them only for trusted repositories by setting mibyan_ENABLE_PROJECT_PLUGINS=true before starting Mibyan.
What plugins can do
Everyctx.* API below is available inside a plugin’s register(ctx) function.
Plugin discovery
Later sources override earlier ones on name collision, so a user plugin with the same name as a bundled plugin replaces it.
Plugin sub-categories
Within each source, Mibyan also recognizes sub-category directories that route plugins to specialized discovery systems:
User plugins at
~/.mibyan/plugins/model-providers/<name>/ override bundled model providers of the same name (last-writer-wins in register_provider()), so you can replace a built-in provider profile without any repo edits. Memory providers resolve the other way round: for ~/.mibyan/plugins/memory/<name>/ the bundled provider wins on a name collision (bundled, then user, then project, then entry points; first seen wins), so a user memory provider needs its own unique name.
Plugins are opt-in (with a few exceptions)
General plugins and user-installed backends are disabled by default — discovery finds them (so they show up inmibyan plugins and /plugins), but nothing with hooks or tools loads until you add the plugin’s name to plugins.enabled in ~/.mibyan/config.yaml. This stops third-party code from running without your explicit consent.
plugins.enabled governs plugins onlyGateway event hooks under ~/.mibyan/hooks/<name>/ are not plugins and are not gated by plugins.enabled or plugins.disabled. That directory is trusted by placement: any subdirectory holding a valid HOOK.yaml + handler.py is imported by the gateway at startup, and placing the files there is the opt-in. See the gateway hook trust model.mibyan plugins install owner/repo, you’re asked Enable 'name' now? [y/N] — defaults to no. Skip the prompt for scripted installs with --enable or --no-enable.
For a reproducible install, pin a full immutable commit (tags, branches, and
abbreviated SHAs are not accepted):
HEAD exactly matches the
requested SHA, and records the canonical source, installed revision, and pin
status in the current profile. mibyan plugins update refuses to move a pinned
plugin; choose a new exact commit explicitly with
mibyan plugins install <source> --force --ref <new-commit>. The
profile-local install metadata contains no config values, environment values,
secrets, or capability grants.
The same agent-plugin pin is available in Mibyan Desktop: Capabilities →
Plugins → Install from Git has a Pin to commit field that takes the full
40-character SHA, and Installed shows a pinned @ <sha8> badge on pinned
agent plugins. This does not guarantee a pinned standalone desktop-plugin
install. mibyan plugins list prints
the pin in its Source column (git pinned@<sha8>). Pins work for private
repositories too, through the same stored credentials described below.
Installing from a private repository
mibyan plugins install clones non-interactively (it never prompts for a
username or password), so a private repo needs a credential Mibyan can find on
its own. Every clone, pinned --ref fetch and mibyan plugins update pull is
attempted anonymously first — public repos never see your credential, so a
stale or revoked token cannot break a public install. Only when the remote
refuses anonymous access does Mibyan look for a credential. For an https://
source it tries, in order:
GITHUB_TOKENorGH_TOKENfrom your.env(GitHub hosts only).- The
ghCLI’s login (gh auth login), GitHub hosts only. - Your git credential helper (
git credential fill) for that host — works for GitLab, Bitbucket and self-hosted servers if a credential is already stored.
.git/config or the install metadata.
SSH sources (git@host:owner/repo.git) authenticate through your ssh-agent as
before. The same resolution applies to mibyan plugins update, catalog MCP
installs from git, and profile distributions fetched from a git URL.
mibyan doctor sends a configured GITHUB_TOKEN/GH_TOKEN to api.github.com
(under API Connectivity) and, when GitHub rejects it, names the variable and the
.env file that carries the expired token so you can remove or replace it.
What the allow-list does NOT gate
Several categories of plugin bypassplugins.enabled — they’re part of Mibyan’ built-in surface and would break basic functionality if gated off by default:
In short: bundled “always-works” infrastructure loads automatically; third-party general plugins are opt-in. The
plugins.enabled allow-list is the gate specifically for arbitrary code a user drops into ~/.mibyan/plugins/.
Approval transports
An approval transport changes where a human sees and answers an existing Mibyan tool-approval request. It does not decide whether a command needs approval and it is not an authorization-policy API.present may be synchronous or async. Mibyan runs it on a bounded worker and
enforces the canonical approvals.timeout even if the plugin does not. The
request is immutable and contains redacted display text, its host presentation
class (cli or gateway), the host timeout, allowed choices, and an opaque
request ID/digest.
Return the result of
request.respond(choice); unbound dictionaries and stale or changed request
IDs/digests are rejected. A plugin cannot return a scope that the host did not
offer (for example, always on a once-only request).
Registration alone does nothing. Enabling the plugin and explicitly selecting
its transport are separate consent steps:
transport_fallback: builtin. Without that exact opt-in, Mibyan never
materializes the prompt on another surface.
Mibyan still owns hardline blocks, sudo-stdin protection, user deny rules,
request binding, allowed scopes, persistence, hooks, and final authorization.
Hardline commands are blocked before any transport callback. There is
intentionally no plugin approval policy, auto-allow callback, or required
pre_tool_call policy in this interface. A future approval-policy capability
may use the plugin capability-consent model, but transport selection does not
grant it.
Migration for existing users
When you upgrade to a version of Mibyan that has opt-in plugins (config schema v21+), any user plugins already installed under~/.mibyan/plugins/ that weren’t already in plugins.disabled are automatically grandfathered into plugins.enabled. Your existing setup keeps working. Bundled standalone plugins are NOT grandfathered — even existing users have to opt in explicitly. (Bundled platform/backend plugins never needed grandfathering because they were never gated.)
Available hooks
Plugins can register the 27 lifecycle events currently accepted bymibyan_cli.plugins.VALID_HOOKS. The Event Hooks catalog is canonical for exact timing, return handling, payload fields, and privacy notes.
These categories describe current behavior rather than defining future naming rules. Plugin middleware remains a separate registry/surface.
Plugin types
Mibyan has four kinds of plugins:
Memory providers and context engines are provider plugins — only one of each type can be active at a time. Model providers are also plugins, but many load simultaneously; the user picks one at a time via
--provider or config.yaml. General plugins can be enabled in any combination.
Pluggable interfaces — where to go for each
The table above shows the four plugin categories, but within “General plugins” thePluginContext exposes several distinct extension points — and Mibyan also accepts extensions outside the Python plugin system (config-driven backends, shell-hooked commands, external servers, etc.). Use this table to find the right doc for what you want to build:
Not everything is a Python plugin. Some extension surfaces intentionally use config-driven shell commands (TTS, STT, shell hooks) so any CLI you already have becomes a plugin without writing Python. Others are external servers (MCP) the agent connects to and auto-registers tools from. And some are drop-in directories (gateway hooks) with their own manifest format. Pick the right surface for the integration style that fits your use case; the authoring guides in the table above each cover placeholders, discovery, and examples.
NixOS declarative plugins
On NixOS, plugins can be installed declaratively via the module options — nomibyan plugins install needed. See the Nix Setup guide for full details.
nix-managed- prefix — they coexist with manually installed plugins and are cleaned up automatically when removed from the Nix config.
Managing plugins
Update checks and provenance
Mibyan records Git install source and revision in.install-metadata.json.
Unpinned tracked installs compare the saved source’s remote HEAD, or a matching
saved update_url feed. Pinned installs remain pinned. Self-cloned directories
need mibyan plugins adopt NAME before they become tracked installations.
Manually copied or provenance-drifted directories receive diagnostic guidance.
Pip entry-point plugins can report an owning distribution’s available version;
that check does not turn them into Git-managed installs.
mibyan plugins check-updates leaves plugin files unchanged. A scheduled gateway
check runs when plugins.auto_update_check_hours is due: default 24 hours,
0 disables it. Its receipt is available through mibyan pm status and the
desktop sync-status view. This is not a hard once-per-day limit if you configure
a different interval.
By default, updates require mibyan plugins update NAME. Setting
plugins.auto_apply: true opts tracked Git plugins into unattended updates.
Both routes use the update security scan. Auto-apply does not manage pinned,
manual, drifted, or pip-distribution rows.
If a manifest changes or introduces update_url, Mibyan refuses the new address
until you approve it with mibyan plugins trust-update-url NAME. This is a
feed-source check, not a sandbox against already trusted plugin code.
Dependency preparation and preservation
Python dependency installation has a separate consent/admission step.plugins install --enable does not bypass that step. A declined or
non-interactive dependency install can leave the plugin installed but disabled.
Node sidecar dependencies have a separate prompt and remain plugin-local.
PM prepares Python dependencies with core and the enabled plugin set before
publishing the new environment and configuration. A resolution failure preserves
the previous selection. Restart Mibyan when a new selected environment is not
yet active in the running process.
The enabled set is the union over the default home and every profile under
profiles/, read from each config.yaml (plugins.enabled, plugins.disabled,
memory.provider). PM refuses to guess at a home it cannot read: a
config.yaml that is not valid YAML, is not a mapping, or has a non-list
plugins.enabled/plugins.disabled or non-string memory.provider fails
dependency preparation for all homes (could not parse plugin selection: <path>), rather than silently dropping that profile’s plugins from the next
environment. Fix or remove the offending file; an empty config.yaml is fine.
Ordinary Mibyan application updates preserve user plugin directories, including
wrapper files and external sidecar links. Explicit plugin updates or removals
can change those files. See Package management
and the plugin authoring guide.
Installed and Browse in Desktop
Open Capabilities → Plugins. Installed reads the app’s desktop-plugin registry and the selected profile’s actual agent-plugin state, combining both halves in one row where appropriate. It is not a list of catalog entries assumed to be installed. Browse is a native catalog view, not an embedded website; it uses the same Installed / Browse tabs as Skills, with search at the top and the tab switch and actions on one row. Desktop and the public Plugin Catalog consume the same CDN snapshot,/docs/api/plugins.json.
The public alias serves the same data as Desktop’s fetch URL,
https://nousresearch.github.io/hermes-agent/docs/api/plugins.json. The docs
build generates it from plugin-catalog/*.yaml and cached star counts. The
same publish also supplies the removed-entry list used by the installer.
Browsing does not query GitHub live or fetch source repos;
the installer retrieves code only as part of the separate install flow.
One-click install links (Desktop)
Mibyan Desktop registers themibyan:// URL scheme, so a website, README, or
chat message can link straight to a plugin install:
catalog=<name> form is what the Open in Mibyan Desktop button on
every Plugin Catalog card uses. Desktop resolves the
name against the live catalog (the same feed Capabilities → Plugins → Browse
shows) and opens the same reviewed catalog entry dialog an in-app
pick does: the agent half installs at the catalog’s pinned commit, never the
branch tip. The link carries no repo URL, and a name that is not in the
catalog shows an error toast and nothing else — it is never reinterpreted as a
git path, so a link cannot smuggle an unreviewed repo behind a
familiar-looking name.
Use an updated Desktop build for catalog links and the Skills Hub’s
mibyan://skill/install?identifier=... route. If the app is missing or too old,
use the card’s copyable mibyan plugins install <catalog-name> command to
retain catalog resolution.
For a repo= link, clicking one opens Mibyan and shows a confirmation dialog — the repo id,
a “Before you install” note, and GitHub browse + clone links — then
shallow-clones the repo to detect what it ships (an agent plugin —
backend Python, a desktop plugin — app UI, or both). You pick the
components with checkboxes and confirm. Nothing is installed until you do;
deep links never auto-install, and agent-plugin installs go through the same
install-time security scanning as
mibyan plugins install.
Hybrid repos (agent + desktop halves in one repo) use one link and one
dialog. The same modal is reachable without a link via Capabilities →
Plugins → Install from Git. Legacy mibyan://plugin-agent/… and
mibyan://plugin-desktop/… URLs route into the same dialog. In dev builds
(npm run dev) the scheme is mibyan-dev://.
Websites need no SDK — a normal anchor works:
Plugin capabilities and consent
Plugins can declare the privileged host surfaces they want in theirplugin.yaml:
mibyan plugins install (and
mibyan plugins enable) shows the list with one-line risk descriptions and
asks once. Consenting records the grant under
plugins.entries.<id>.granted_capabilities together with a consent hash and
timestamp. Declining leaves the plugin enabled with those capabilities off —
a well-behaved plugin probes with ctx.has_capability() and degrades
gracefully.
Update re-consent: if a plugin update declares capabilities you haven’t
granted, mibyan plugins update surfaces the additions and asks again. New
capabilities stay off until you consent — a plugin update can never silently
widen its access. Catalog re-pins go one step further: when the new pin adds
tools, hooks, Python dependencies, host capabilities or a Desktop UI half the
installed version did not have, the CLI shows the delta and asks y/N before
anything moves, and the Desktop / dashboard Update button opens the same
confirmation. Declining (or a non-interactive session) leaves the plugin at
the old pin.
Non-interactive sessions fail closed: installing or updating without a
TTY completes the install, but declared capabilities are not granted. Run
mibyan plugins enable <id> interactively to grant them later.
Inspect the state at any time:
A gate is open when either the capability is granted or the legacy key is
set — existing configs keep working unchanged.
Platform actions
ctx.platform_actions gives a plugin a minimal, capability-gated verb set for
acting on connected chat platforms through the live gateway adapter registry —
the sanctioned alternative to monkeypatching an adapter. It is off by
default: every call re-checks the gateway.platform_actions capability
(legacy key plugins.entries.<id>.allow_platform_actions), and an ungranted
call returns a structured error instead of acting.
v1 verbs (both async, both return a plain dict, and neither ever raises into
hook dispatch):
{"ok": True, "action": <verb>}. Failures are
{"ok": False, "error": <code>, "detail": <str>} with stable error codes:
capability_not_granted, invalid_argument, gateway_unavailable,
unknown_platform, adapter_not_registered, adapter_disconnected,
unsupported_platform_action, action_failed. Actions validate that the
target adapter exists and is connected before acting; a disconnected or
missing adapter degrades to a structured error, never an exception.
Platforms supported in v1: Telegram and Discord. Telegram’s add_reaction
sets the bot’s reaction (the Bot API replaces a previous bot reaction rather
than stacking). Every action — allowed or denied — is written to the log with
the plugin id, verb, platform, and outcome.
Discovering plugins — the Mibyan plugin catalog
mibyan plugins search <term> searches the Mibyan plugin catalog — the
curated, SHA-pinned catalog maintained in the mibyan-agent repository
(plugin-catalog/). Matching covers entry names, descriptions, and declared
tools:
mibyan plugins update can re-pin when the catalog moves:
owner/repo or Git-URL identifiers never touch the catalog and are
flagged as custom (unreviewed) sources. An explicit
--ref <40-char commit SHA> pins a custom install.
See Plugin Catalog for the full trust model, admission
CI, and submission workflow.
Plugin packs
A plugin pack is a declarative, shareable YAML file (mibyan-pack.yaml)
that pins a set of plugins — like sharing a modpack. Installing a pack fans
out to ordinary pinned installs; nothing new exists at runtime.
ref must be an exact 40-character
commit SHA — tags and branch names are rejected with an error naming the
entry, the same rule as the plugin catalog. Pack installs ride the exact
same pinned install path as mibyan plugins install --ref <sha> and record
the same provenance in plugins/.install-metadata.json, so two installs of
the same pack resolve identically. Packs build on the
manifest v2 fields (manifest_version,
api_version, requires_plugins) — each plugin’s own manifest still
validates through the normal install path.
Consent is never bulk-granted. pack install shows a mandatory review
screen (every plugin, source, pinned ref, and the capabilities it declares),
then asks one confirmation for the pack contents. After that, each
plugin’s declared capabilities go through the standard per-plugin
capability-consent prompt — identical to a single mibyan plugins install.
There is no --yes, and non-interactive sessions cannot install packs.
Secrets never travel in packs. config: seeds are limited to
non-secret plugins.entries.<id> keys — secret-shaped key names
(*token*, *key*, *password*, …), capability grants, and the deprecated
allow_* trust gates are rejected on install and stripped on export.
Plugins that need secrets declare them in their own requires_env, which
prompts during install as usual. Existing user values in
plugins.entries.<id> always win over pack seeds.
Partial failure. Each plugin installs independently; failures are
reported per plugin, the rest continue, and the command exits non-zero if
any plugin failed.
Export caveats. pack export only includes plugins with known Git
provenance (installed via mibyan plugins install). Local-only plugins are
listed as warning comments in the emitted YAML, not as installable entries.
The skills: list is parsed and displayed at install time but not yet
auto-installed — install those manually for now (mibyan skills). Wiring
skill-hub ids into pack install is a documented follow-up seam.
Install-time security scanning
Everymibyan plugins install and mibyan plugins update runs a static
security scan over the plugin tree before it is activated (inspired by
Claude Cowork’s skill & plugin security scanning). The scanner reuses the
same threat-pattern engine as the Skills Hub guard
— exfiltration of credential stores, reverse shells, destructive commands,
persistence mechanisms, obfuscated execution, and prompt injection in
documentation files — with plugin-aware exemptions: a provider plugin
reading its own API key from the environment (the documented
requires_env pattern) is not flagged.
Three verdicts, matching Cowork’s pass/warn/fail:
On
mibyan plugins update, a dangerous verdict on the updated tree
disables the plugin until you review the findings and re-enable it. A
dangerous block names the critical findings that caused it (e.g.
1 critical of 42 findings (destructive_root_rm)), so a single blocking
line is not hidden behind the total.
Text that cannot run on the host at install time is scored as context, not
as the plugin’s behaviour, so it can lower a finding but never delete it —
every finding stays in the report with file and line:
- Documentation prose (
README.md,AGENTS.md,docs/**/*.md,.txt,.rst,.html) can never on its own produce dangerous: a command or credential path quoted there (an uninstall step, a refusal list naming~/.ssh) steps down one severity, and a README removing the plugin’s own install directory (rm -rf "$HOME/.mibyan/plugins/<name>") is a note. Agent-facing shapes keep full severity — prompt injection, Markdown exfil, agent-config edits,curl … | shone-liners, anauthorized_keysappend, a leaked provider key — and so does anything under a bundledskills/tree or inafter-install.md, which the agent reads as instructions. - Test trees and fixtures (
tests/,test/,testing/,spec/,specs/,fixtures/at the plugin root;__tests__/and__fixtures__/at any depth;*.test.*,*.spec.*,test_*.py,*_test.*) are still scanned — a plugin’s__init__.pycan import from them — but a quoted-only hostile string (verdict_for("rm -rf /"), a redaction corpus with a fakesk-…key) is a note, and test code that would execute on import (os.system('rm -rf /')) is capped at caution. The same finding in any other file (setup.sh,src/spec/…) is still dangerous. - Whole-line comments and
CHANGELOG.mddescribe a defense; they score as prose does. - Base64 that decodes to a media header (PNG/JPEG/GIF/WOFF/PDF … in a
data URI or JSON scenery) is informational;
base64 -dpiped into a text filter (grep,jq) is a note, piped into a shell or interpreter it keeps full severity;sudo/env|as an alternation member of a regex literal (/approval|sudo|secret/, a redaction pattern) is a note, in a command string (subprocess.run("sudo …")) it is not.
hardcoded_secret) inside a runtime .py
file’s if __name__ == "__main__": self-test block is capped at caution
— the loader imports plugins and never runs that block — while every other
finding inside it (destructive commands, provider-shaped keys such as sk-…)
and the same token anywhere above the guard keep full severity.
Scanning is on by default; disable it in config.yaml:
Interactive UI
Runningmibyan plugins with no arguments opens a composite interactive screen:
- General Plugins section — checkboxes, toggle with SPACE. A row opens checked when the plugin is active right now: listed in
plugins.enabled, or a bundled platform, backend or model provider (on without a list entry), or the selected provider of a category. Only rows you flip are written on exit: unticking adds the plugin toplugins.disabled(explicit off), ticking adds it toplugins.enabledand clears a stale disable. Opening the picker and leaving changes nothing. - Provider Plugins section — shows current selection. Press ENTER to drill into a radio picker where you choose one active provider.
- Bundled plugins appear in the same list with a
[bundled]tag.
config.yaml:
Enabled vs. disabled vs. neither
Plugins occupy one of three states:
The default for a newly-installed or bundled plugin is
not enabled. mibyan plugins list shows all three distinct states so you can tell what’s been explicitly turned off vs. what’s just waiting to be enabled.
In a running session, /plugins shows which plugins are currently loaded.
Injecting Messages
Plugins can inject messages into a CLI conversation or a known gateway session usingctx.inject_message():
ctx.inject_message(content: str, role: str = "user", *, session_key: str | None = None) -> bool
In CLI mode:
- If the agent is idle (waiting for user input), the message is queued as the next input and starts a new turn.
- If the agent is mid-turn (actively running), the message interrupts the current operation — the same as a user typing a new message and pressing Enter.
- For non-
"user"roles, the content is prefixed with[role](e.g.[system] ...). - Returns
Trueif the message was queued successfully.
session_keyis required and must identify an existing gateway session. It is the stable routing key, not the CLI session ID.- Mibyan reuses that session’s stored platform, chat, thread, profile, and conversation history. Plugins cannot supply a new chat route through this API.
- Mibyan rechecks the stored route against the gateway’s current authorisation rules before dispatch.
- Routes that relied only on an adapter-time or upstream authorisation decision are rejected unless Mibyan can revalidate them from current core allowlists, pairing, or explicit allow-all configuration.
- Injected text is always conversational input. It cannot invoke slash commands, approve tools, or resolve pending confirmation and clarification prompts.
- The route and conversation are pinned while dispatch is pending. Mibyan drops the request if topic recovery changes the route or the session rotates before handling starts.
- The request enters the platform adapter’s normal message path. Active sessions use the existing busy-session queue rather than starting a competing turn.
- Returns
Truewhen the live gateway accepts the request for asynchronous dispatch. This does not confirm that the agent turn or platform delivery has completed. - Returns
Falsewhensession_keyis omitted, the permission is not granted, or no live host can accept the request. Unknown or unroutable session keys discovered after asynchronous acceptance are written to the gateway log.
mibyan --tui) and the desktop / dashboard chat are a third host. They do not set the classic CLI reference and they do not register on the messaging-gateway injector — those two hosts stay separate so a live gateway cannot clobber the TUI (or the reverse). Pass the session’s durable session_key (the ses_… id), not the ephemeral UI session id. Mibyan queues the text on that session’s prompt queue: a busy session keeps the message for the next turn, an idle session starts one. A key that is not a live TUI session is left for the messaging gateway when one is running, and is never rerouted to a different chat.
This enables plugins like remote control viewers, messaging bridges, or webhook receivers to feed messages into the conversation from external sources.
Gateway injection can send an agent response to an external messaging platform. It is disabled by default for every plugin. Grant it per plugin in config.yaml:
This plugin API does not expose a public HTTP endpoint or CLI command for external processes. The plugin must already know the target gateway
session_key, for example from its own trusted configuration or previously retained session state.Calling MCP servers from plugins
ctx.call_mcp() lets a plugin call a tool on one of the user’s configured MCP servers — synchronously, from any hook or tool handler — routing through Mibyan’ existing native MCP client (same connections, trust-tier gates, circuit breaker, and reconnect logic as model-invoked MCP tools; never a parallel client).
ctx.call_mcp(server: str, tool: str, arguments: dict | None = None, timeout: float = 30) -> dict
Returns a stable envelope: {"ok": True, "result": ...} (plus structuredContent when the server provides it) or {"ok": False, "error": "..."}. Results over ~64 KB are truncated and flagged with "truncated": True.
Security: default-off, per-server allowlist
A plugin has no MCP access by default. The operator must grant each server explicitly inconfig.yaml:
- Calling a server not in the list raises
PermissionErrornaming the exact config key to set. - The grant is per-server and per-plugin — never ambient authority over every configured server, and
"*"wildcards are not honored. - Every call has an enforced timeout (default 30 s) so a hung MCP server cannot stall the hook or tool pipeline that invoked it.
- MCP servers return untrusted content. Treat
resultas data, not instructions — don’t feed it into privileged decisions (approvals, command execution) without validation.

