@abot-ai/runtime 1.0.0

package/docs/runtime-public-contracts.md

@@ -0,0 +1,304 @@
+# Runtime Public Contracts
+
+This document describes the stable runtime contracts that host applications can
+depend on. It intentionally does not describe internal request execution,
+role orchestration, model, or context modules.
+
+## Public Entrypoints
+
+Use package exports from `package.json`:
+
+- `@abot-ai/runtime/runtime`
+- `@abot-ai/runtime/runtime/config`
+- `@abot-ai/runtime/runtime/composition`
+- `@abot-ai/runtime/runtime/default-adapters`
+- `@abot-ai/runtime/runtime/adapters`
+- `@abot-ai/runtime/runtime/ports`
+- `@abot-ai/runtime/plugin-sdk`
+- `@abot-ai/runtime/model-gateway`
+
+Do not import from `src/runtime/request`, `src/runtime/orchestration`,
+`src/runtime/steps`, `src/runtime/model`, `src/runtime/context`, or
+`src/runtime/events` in a host application. Those modules are internal and may
+move while public ports remain stable.
+
+## RuntimeDependencies
+
+`createDefaultRuntimeDependencies(config)` returns the current default
+composition:
+
+- `config`
+- `host`
+- `sessions`
+- `attachments`
+- `tools`
+- `models`
+- `events`
+
+Hosts may replace any dependency except `config` through
+`RuntimeDependencyOverrides`.
+
+## RuntimeHost
+
+`RuntimeHost.start(options)` accepts the current runtime and adapter boundary:
+
+- `runtimeConfig`
+- `runtimeId`
+- `agentBridgeUrl`
+- `agentBridgeToken`
+- `eventSinkFactory`
+- `modelGatewayClient`
+- `sessionStore`
+- `attachmentStore`
+- `toolRegistry`
+
+Hosts may use `createDefaultRuntimeDependencies(config)` for default adapters or
+inject their own ports. Injected ports are responsible for preserving the same
+semantic contracts described below.
+
+`conversationContextProvider`, `skillProvider`, and `workspaceProvider` are not
+`RuntimeHostStartOptions`.
+
+## SessionStore
+
+`SessionStore` is the source of truth for durable session state. It owns:
+
+- session records and snapshots
+- user and assistant messages
+- request stream lifecycle
+- persisted request events
+- request replay by `requestId`
+- message deletion and session reset operations
+
+Request event replay is append-only from the runtime perspective. Consumers
+should treat event sequence order as meaningful and should not infer final
+request success from a single event when later failure/completion events exist.
+
+## RuntimeAttachmentStore
+
+`RuntimeAttachmentStore` owns durable request attachment storage and
+session-bound reference validation:
+
+- `saveAttachment(input)`
+- `validateAttachmentReferences(attachments, options?)`
+- `resolveAttachment(attachment)`
+- optional `deleteAttachment(attachment, options?)`
+- `deleteSessionAttachments(sessionId)`
+
+`createDefaultRuntimeDependencies(config)` exposes this port as
+`runtime.attachments`; pass it to `RuntimeHost.start(...)` as
+`attachmentStore`.
+
+Attachment references use `kind: "image" | "file"`. Supported images continue
+through the model vision input. Supported document files are exposed to the
+request-bound `document_reader` capability by id/name; their binary payload is
+never inserted into model context. The `local-search` plugin can search bounded
+filenames or text only beneath configured agent-work and workspace roots.
+
+## EventSink
+
+`EventSink` is the UI/bridge event output boundary for one request. Stable
+methods are:
+
+- `publish(payload)`
+- `event(name, extra)`
+- `runtimeState(state)`
+- `token(token)`
+- `legacyToken(text)`
+- `thinkingDelta(delta, accumulatedText)`
+- `completed(output)`
+- `failed(error, details)`
+- `drain()`
+- `dispose()`
+
+`event(name, extra)` preserves the raw runtime event name in the payload while
+UI-facing status helpers may add display-oriented names. Consumers that need
+logic should key off raw event names and payload fields, not display strings.
+
+Planner events follow snapshot-plus-diff semantics:
+
+- `planner.plan.created` and `planner.plan.updated` carry the current plan
+  snapshot.
+- `planner.plan.item.*` events are timeline/update events for individual plan
+  items.
+- Planner payloads retain `stage=development_plan` for client compatibility.
+  This field is presentation metadata and does not identify a runtime loop.
+
+These events describe canonical delegated Planner state. A `planner.graph`
+advisory under `execution-agent-v1` is a passive subordinate result and does
+not create `planner.plan.*` state or events.
+
+Runtime capabilities use the stable tool event envelope. Adapter-owned
+presentation metadata supplies the tool, operation and action type; target
+metadata contains only resolved logical paths. Physical
+roots, opaque subject identities and authored payload bodies are never exposed.
+These events describe capability execution only. Only `planner.plan.*` events
+report canonical item-status changes or semantic progress.
+
+Tool events use the current tool execution boundary:
+
+- `tool.started`
+- `tool.payload.started`
+- `tool.payload.completed`
+- `tool.payload.failed`
+- `tool.completed`
+
+A `tool.completed` event with `ok: true` proves only that the tool step
+succeeded. It does not prove the user request is complete.
+
+## ToolRegistry
+
+`ToolRegistry` owns active tool capability discovery and execution:
+
+- `listDefinitions(taskType?)`
+- `getDefinition(name)`
+- `getAdapter(name)`
+- `hasToolsAvailable()`
+- `getImplementations()`
+- `execute(call, options?)`
+
+Runtime orchestration must treat the registry as the capability authority. Tool
+names, normal-invocation contracts, payload-channel specs, and plugin-provided
+tools belong to the registry/tool layer, not to core orchestration. The frozen
+execution policy determines whether the canonical Worker or root may bind an
+offered capability; both principals use the same registry and adapter engine.
+
+`ToolModule.adapter` is the tool-layer extension point for call-shape
+normalization. Built-in tool packs and runtime plugin tools may provide an
+adapter. The parser may invoke an adapter generically through the active
+registry, but tool-specific aliases, compatibility rewrites, or routing from one
+legacy tool shape to a current tool must live in the owning tool module or pack,
+not in parser or runtime orchestration code.
+
+## ToolDefinition And ToolExecutionResult
+
+`ToolDefinition.routingCapability` and `developmentRoles` are tool metadata
+retained for compatibility. They must not select a request path or role.
+Model-facing availability and controls come from the registered
+`normalInvocation` contract.
+
+Every plugin-handler return is normalized by `ToolRegistry` into one complete
+`ToolExecutionResult`, whether the operation succeeds or fails. The selected
+tool identity is Runtime-owned; plugins provide the operation result. The
+public envelope contains:
+
+- `ok`: execution success
+- `tool`: the non-empty selected capability id added by `ToolRegistry`
+- `output`: the textual operation result
+- `progress`: step made runtime progress
+- `producedNewInformation`: step revealed new information
+- `actions`: tool-owned structured action summaries
+- optional process and failure fields: `exitCode`, `stdout`, `stderr`, `error`,
+  and `errorCode`
+- `data.mutationEvidence`: tool observed or applied mutation evidence
+- `data.stateAlreadySatisfied`: requested state was already satisfied
+- `data.hasData`: inspection returned useful data
+- `data.observationMeta`: carry policy for future request context
+
+Failed execution does not count as progress. A successful tool step proves only
+the reported result, not overall completion.
+
+The complete result is a mandatory canonical evidence object. Before capability
+settlement, the Runtime validates that it contains only plain JSON-safe data and
+fits the 256 KiB serialized producer boundary. Functions, symbols, accessors,
+cycles, non-plain prototypes, non-finite numbers, and oversized results fail
+explicitly. The Runtime does not silently truncate, partially parse, or discard
+structured fields.
+
+The registered-tool adapter wraps the complete result as
+`registered_tool_execution_result_v1`; Runtime-owned rejections and generic
+adapters use their corresponding canonical envelopes. The capability engine
+atomically settles the operation outcome and exactly one validated canonical
+adapter result in the RoleCall ledger. A settled execution cannot omit that
+evidence, and a running execution cannot carry it.
+
+Exact result projection is bound mechanically to the producing call. A direct
+root keeps its strict native assistant-tool-call / linked-tool-result lane. A
+delegated Worker receives its own complete adapter result through
+`runtime_request_tool_results_v1`, and later payload authoring in that same call
+receives the same canonical evidence. Supervisors, Planners, Reviewers, sibling
+Workers, unrelated calls, and unrelated requests receive only their existing
+bounded receipts or child handoffs; the exact body is not copied to them.
+
+This lifecycle is generic for every registered plugin and must not require
+plugin-specific Runtime projection code. See
+[tool-execution-result-evidence-contract.md](tool-execution-result-evidence-contract.md)
+for the producer rules, lifecycle, authority boundary, compaction semantics,
+and compatibility guarantees.
+
+## SkillProvider
+
+`SkillProvider` owns model-facing skill text:
+
+- `getActionContext(action)`
+
+The default provider projects this context only from the selected capability's
+mapping in its loaded plugin manifest. It has no built-in, file-backed, or
+composite skill source.
+
+## WorkspaceProvider
+
+`WorkspaceProvider.getSystemSummary()` provides host/workspace context. This is
+context only; filesystem truth for a requested mutation or verification still
+comes from tool execution results.
+
+`WorkspaceProvider` and its public adapters remain standalone public contracts;
+they are not `RuntimeHost.start(...)` options.
+
+## ModelGatewayClient
+
+`ModelGatewayClient` owns model invocation transport:
+
+- `invoke(params)` for streamed/chat-style model steps
+- `invokeRaw(params)` for raw payload generation
+
+Callers provide intent fields such as `modelStep`, `agentMode`,
+`modelPreference`, `modelPolicy`, and optional overrides. Model routing belongs
+to the model gateway policy, not request orchestration.
+
+Text-only message arrays retain their existing transport contract. When a
+message array contains the native tool-interaction lane, it is strict: one
+assistant message carries non-empty `toolCalls`, each exact call is followed in
+order by its matching `role: "tool"` result, and call id, tool name, arguments,
+and result content are not semantically rewritten. The gateway validates this
+linkage before provider projection, and token accounting includes the complete
+lane. `execution-agent-v1` uses this lane to resume the same canonical root
+after direct capability settlement; it is not a second tool or evidence store.
+
+## Runtime Completion Semantics
+
+The canonical root alone owns request completion and the final user-facing
+response. Its frozen model-facing contract is Supervisor under the omitted
+default `supervisor-worker-v1` policy and Execution Agent under the opt-in
+`execution-agent-v1` policy. Planner, Worker, Reviewer, and Auditor return
+bounded results to their exact callers. The RoleCall ledger validates state
+transitions; capability adapters establish only their reported operation
+outcomes. No layer should combine these owners into a transcript-shaped
+conditional or infer completion from one successful tool event.
+
+The default policy keeps the established normalized final-text behavior.
+`execution-agent-v1` alone selects exact terminal text mode: its committed
+terminal string, including raw non-empty `execution.response` output, passes
+through the same finalizer without trimming. This presentation choice does not
+create a policy-specific persistence or completion path.
+
+## Prompt And Policy Contracts
+
+Prompt text parsed into a Supervisor, Execution Agent, delegated Planner,
+Planner Graph, Worker, Reviewer, or Auditor action is part of the runtime
+contract. Changing a role action, advisory result, or capability envelope is a
+behavior change and requires coverage at its owning parser, ledger, or
+capability boundary. `planner.graph` and `planner.decision` are distinct model
+steps and contracts; neither is a compatibility alias for the other.
+
+Prompt and policy ownership is tracked in
+[runtime-prompt-policy-contracts.md](runtime-prompt-policy-contracts.md), and
+runtime invariant coverage is tracked in
+[runtime-invariant-coverage.md](runtime-invariant-coverage.md).
+
+## Stable Consumer Rule
+
+Host applications should depend on ports, config schema, event payloads, session
+snapshots, request replay, tool definitions, and tool execution results. They
+should not depend on internal file layout, prompt wording, private helper
+functions, or display-only event labels.

package/docs/tool-execution-result-evidence-contract.md

@@ -0,0 +1,151 @@
+# Tool Execution Result Evidence Contract
+
+## Status
+
+This document defines the stable product contract for Runtime-owned capability
+result evidence. It applies equally to direct-root and delegated execution.
+
+The contract is intentionally generic. No runtime branch may inspect a plugin
+id, capability id, operation id, field name, or prompt wording to decide which
+tool facts the model receives.
+
+## Goals
+
+1. Every settled capability execution owns one canonical, JSON-safe adapter
+   result in the RoleCall ledger.
+2. Every registered plugin result is represented by the same complete
+   `ToolExecutionResult` envelope, including `output`, `data`, actions, failure
+   fields, and execution metadata.
+3. The exact producing call can consume that result regardless of whether the
+   authorized principal is the direct root or a delegated Worker.
+4. Subsequent payload authoring inside the same call can consume the same
+   evidence without a plugin-specific bridge.
+5. Request-wide receipts, child handoffs, role authority, and completion
+   semantics remain unchanged.
+6. Invalid, cyclic, non-JSON-safe, or oversized results fail explicitly before
+   canonical settlement. Evidence is never silently truncated or partially
+   parsed.
+
+## Non-goals
+
+- The Runtime does not decide which tool a model should select.
+- The Runtime does not infer semantic completion from a successful tool result.
+- The Runtime does not add retries, repeated-call guards, or plugin-specific
+  fallback behavior.
+- The Runtime does not copy complete child evidence into a Supervisor,
+  Planner, Reviewer, sibling Worker, or unrelated request.
+- The contract does not require capability-specific projection or plugin
+  migrations.
+
+## Public Producer Contract
+
+Plugin handlers return `ToolImplementationOutput`. `ToolRegistry` is the sole
+owner that adds the selected tool identity and produces `ToolExecutionResult`:
+
+```text
+ToolExecutionResult
+  ok: boolean
+  tool: non-empty string
+  output: string
+  producedNewInformation: boolean
+  progress?: boolean
+  actions?: ToolActionSummary[]
+  exitCode?: finite number
+  stdout?: string
+  stderr?: string
+  data?: JSON-safe object
+  error?: string
+  errorCode?: string
+```
+
+The registered-tool adapter wraps this value once as
+`registered_tool_execution_result_v1`. Runtime-owned rejections use
+`runtime_capability_rejection_v1`. Legacy or injected adapters that do not
+provide an envelope are captured mechanically as
+`generic_capability_result_v1`; their payload is not semantically rewritten.
+
+All three variants are `CapabilityAdapterResult`. The capability engine must
+attach one normalized variant to every settlement.
+
+## Validation And Bounds
+
+The Runtime validates the result before ledger settlement:
+
+- plain enumerable data properties only;
+- JSON primitives, objects, and dense arrays only;
+- finite numbers only;
+- no functions, symbols, accessors, cycles, or non-plain prototypes;
+- the registered result must match the public `ToolExecutionResult` fields;
+- references remain bounded by the RoleCall reference contract;
+- one serialized canonical adapter result is limited to 256 KiB.
+
+The 256 KiB limit is a hard producer boundary, not a model-context truncation
+rule. An over-limit result becomes an explicit technical capability failure.
+The Runtime never sends a syntactically valid but incomplete object and never
+pretends that omitted structured facts were observed.
+
+Plugin results are model-facing evidence and therefore must not contain
+secrets. Secret acquisition and redaction remain responsibilities of the
+owning tool/host boundary; core orchestration must not guess sensitive field
+semantics from arbitrary JSON keys.
+
+## Canonical Lifecycle
+
+```text
+plugin handler
+  -> ToolRegistry creates ToolExecutionResult
+  -> normal invocation returns the complete result
+  -> registered adapter creates CapabilityAdapterResult
+  -> capability engine validates/captures the result
+  -> RoleCall reducer atomically settles outcome + exact result
+  -> exact producing consumer receives the result
+```
+
+Settlement is atomic. A ledger entry cannot be `settled` without a valid
+canonical adapter result. Running entries cannot contain one.
+
+## Model Projection And Authority
+
+The canonical result proves only its own recorded execution and effect. Its
+contents are untrusted reference data, never instructions, user intent,
+authority, or proof that the whole request is complete.
+
+Projection is deliberately exact-consumer scoped:
+
+- `execution-agent-v1`: the active root keeps the existing provider-native
+  assistant-tool-call / linked-tool-result lane. Its message shape and order do
+  not change.
+- `supervisor-worker-v1`: the Worker that produced the execution receives
+  `adapterResult` on its entry in `runtime_request_tool_results_v1` when it
+  resumes and when its result author runs.
+- Capability payload authoring for that same call receives the canonical
+  result in `settledCapabilityResults`.
+- Other calls receive the existing bounded receipt (`outcome`, effect,
+  `summary`, references, and allowed `referenceData`) and the normal child
+  handoff. They do not receive a second copy of the exact body.
+
+This preserves least authority and prevents context presence from being
+mistaken for user intent. A Worker may use exact facts to fulfill its immutable
+objective, but those facts cannot broaden that objective.
+
+## Compaction
+
+An exact result is a semantic-compaction source for its producing Worker. Until
+a checkpoint covers that execution id, the complete result remains in the
+Worker evidence block. After a validated checkpoint is committed, the exact
+body and legacy `referenceData` may be replaced in model context by the
+checkpoint digest plus the immutable execution receipt. The canonical ledger
+entry remains unchanged.
+
+Compaction is never a fallback for an invalid or over-limit result and never
+changes execution outcome, authority, or persistence.
+
+## Compatibility
+
+- Existing summaries and `referenceData` remain populated and projected.
+- Existing tool events and client payloads do not change.
+- Direct-root native tool linkage and exact result content remain unchanged.
+- Role result, request finalization, artifact continuity, and tool-selection
+  contracts remain unchanged.
+- Settled RoleCall execution state requires canonical result evidence for every
+  authorized principal.

package/docs/troubleshooting.md

@@ -0,0 +1,115 @@
+# Troubleshooting
+
+## `runtime.config.json` Is Missing
+
+The default config file is optional. For local development, prefer an ignored
+local config:
+
+```bash
+npm run init -- --provider ollama --model <model-id>
+```
+
+## Model Gateway Returns 500
+
+Check whether the configured provider is installed, running, and reachable.
+ABot Runtime provides the Ollama adapter; it does not install the Ollama server
+or download model weights.
+
+For Ollama, install it from the
+[official download page](https://ollama.com/download), make sure its service is
+running, and then pull the exact model id used by the runtime profile before
+checking the API:
+
+```bash
+ollama pull <model-id>
+curl http://127.0.0.1:11434/api/tags
+```
+
+Confirm that the response lists the same `<model-id>` configured in the model
+profile. `127.0.0.1` is the runtime process's own loopback network; it is not
+automatically the Windows host from WSL, the container host from inside a
+container, or a remote Ollama machine. In those layouts, pass an address
+reachable from the runtime to the initializer with
+`--base-url http://<ollama-host>:11434`, or update
+`models.providers.ollama.baseUrl` in existing runtime config. Run the
+`/api/tags` check against that URL.
+
+See [Running Locally](running-locally.md#ollama) for the complete Ollama setup
+sequence.
+
+Check gateway logs:
+
+```bash
+tail -n 100 .runtime/shared/logs/model-gateway.jsonl
+```
+
+If `MODEL_GATEWAY_TRACE_FILE` is set, read that file instead.
+
+## Missing OpenAI API Key
+
+Set the key in the environment, not in JSON config:
+
+```bash
+OPENAI_API_KEY=...
+```
+
+Provider config should contain only the env var name:
+
+```json
+{
+  "type": "openai",
+  "apiKeyEnv": "OPENAI_API_KEY"
+}
+```
+
+## Runtime Connects But App Requests Do Not Arrive
+
+The runtime bridge client connects outbound to `agentBridgeUrl`. Make sure the
+bridge server is running, the URL is correct, and `AGENT_BRIDGE_TOKEN` matches
+the bridge configuration when auth is enabled.
+
+## Dev And Prod Use The Same State
+
+Check the active profile:
+
+```bash
+echo "$LLM_RUNTIME_PROFILE"
+```
+
+Use environment profiles to isolate state:
+
+```json
+{
+  "environment": {
+    "default": "prod",
+    "profiles": {
+      "prod": {
+        "paths": {
+          "runtimeDir": ".runtime/prod",
+          "agentWorkDir": ".runtime/prod/agent-work"
+        }
+      },
+      "dev": {
+        "paths": {
+          "runtimeDir": ".runtime/dev",
+          "agentWorkDir": ".runtime/dev/agent-work"
+        }
+      }
+    }
+  }
+}
+```
+
+## Package Smoke Checks Fail
+
+Run the checks from a clean working tree after building:
+
+```bash
+npm run build
+npm run smoke:runtime-package
+npm run check:runtime-package
+npm run smoke:packed-runtime-package
+```
+
+Do not publish if package checks include `.env`, `local/runtime.config.json`,
+tests, source maps, local runtime state, or model-gateway server internals.

package/examples/env.example

@@ -0,0 +1,9 @@
+# Optional credentials for providers and integrations you explicitly configure.
+OPENAI_API_KEY=
+BRAVE_SEARCH_API_KEY=
+
+# Optional process-level runtime overrides.
+AGENT_BRIDGE_TOKEN=
+LLM_RUNTIME_CONFIG_FILE=local/runtime.config.json
+LLM_RUNTIME_SHARED_DIR=
+NODE_ENV=development

package/examples/minimal-runtime-composition.ts

@@ -0,0 +1,24 @@
+import {
+  createDefaultRuntimeDependencies,
+  loadRuntimeConfig,
+} from "@abot-ai/runtime/runtime";
+
+const config = loadRuntimeConfig({ rootDir: process.cwd() });
+const runtime = createDefaultRuntimeDependencies(config);
+
+console.log({
+  runtimeId: config.runtimeId,
+  modelGatewayUrl: config.modelGatewayUrl,
+  paths: {
+    runtimeDir: config.paths.runtimeDir,
+    attachmentsDir: config.paths.attachmentsDir,
+  },
+  dependencies: {
+    host: Boolean(runtime.host),
+    sessions: Boolean(runtime.sessions),
+    attachments: Boolean(runtime.attachments),
+    tools: Boolean(runtime.tools),
+    models: Boolean(runtime.models),
+    events: Boolean(runtime.events),
+  },
+});

package/examples/models/default.config.json

@@ -0,0 +1,28 @@
+{
+  "label": "Replace with your model",
+  "provider": "provider",
+  "model": "replace-with-model-id",
+  "contextWindowTokens": 32768,
+  "context": {
+    "formatTokenAccounting": {
+      "mode": "estimate"
+    }
+  },
+  "calibration": {
+    "supervisor.decision": { "format": "json" },
+    "worker.decision": { "format": "json" },
+    "planner.decision": { "format": "json" },
+    "planner.graph": { "format": "json" },
+    "reviewer.decision": { "format": "json" },
+    "degraded.finalization": { "format": "json" },
+    "execution.decision": { "format": "json" },
+    "auditor.decision": { "format": "json" },
+    "context.compact": { "format": "json" },
+    "toolPayload.raw": {
+      "instructions": [
+        "Return only the literal payload text requested for the selected tool.",
+        "Do not include JSON wrappers, tool names, params, status text, markdown fences, or commentary."
+      ]
+    }
+  }
+}

package/examples/request-runner.config.example.json

@@ -0,0 +1,42 @@
+{
+  "models": {
+    "defaults": {
+      "profileId": "default",
+      "steps": {
+        "supervisor.decision": "supervisor.decision",
+        "supervisor.response": "default",
+        "worker.decision": "worker.decision",
+        "worker.result": "default",
+        "planner.decision": "planner.decision",
+        "planner.graph": "planner.graph",
+        "reviewer.decision": "reviewer.decision",
+        "degraded.finalization": "degraded.finalization",
+        "execution.decision": "execution.decision",
+        "execution.response": "default",
+        "auditor.decision": "auditor.decision",
+        "context.compact": "context.compact",
+        "tool_payload.raw": "toolPayload.raw"
+      }
+    }
+  },
+  "context": {
+    "outputReserveTokens": 4096,
+    "safetyReserveTokens": 1200,
+    "attachmentReserveTokens": 1024
+  },
+  "steps": {
+    "supervisor.decision": { "timeoutMs": 90000 },
+    "supervisor.response": { "timeoutMs": 90000 },
+    "worker.decision": { "timeoutMs": 90000 },
+    "worker.result": { "timeoutMs": 90000 },
+    "planner.decision": { "timeoutMs": 90000 },
+    "planner.graph": { "timeoutMs": 90000 },
+    "reviewer.decision": { "timeoutMs": 90000 },
+    "degraded.finalization": { "timeoutMs": 90000 },
+    "execution.decision": { "timeoutMs": 90000 },
+    "execution.response": { "timeoutMs": 90000 },
+    "auditor.decision": { "timeoutMs": 90000 },
+    "context.compact": { "timeoutMs": 90000 },
+    "tool_payload.raw": { "timeoutMs": 90000 }
+  }
+}