oh-my-opencode-lite 0.1.0 → 0.1.2

package/dist/mcp/websearch.d.ts

@@ -1,6 +1,2 @@
 import type { RemoteMcpConfig } from './types';
-/**
- * Exa AI web search - real-time web search
- * @see https://exa.ai
- */
 export declare const websearch: RemoteMcpConfig;

package/oh-my-opencode-lite.schema.json

@@ -499,43 +499,6 @@
         }
       }
     },
-    "clarificationGate": {
-      "type": "object",
-      "properties": {
-        "mode": {
-          "default": "auto",
-          "type": "string",
-          "enum": [
-            "off",
-            "explicit-only",
-            "auto",
-            "auto-for-planning"
-          ]
-        },
-        "min_scope_signals": {
-          "default": 2,
-          "type": "number",
-          "minimum": 0
-        },
-        "hard_complex_signal_threshold": {
-          "default": 3,
-          "type": "number",
-          "minimum": 0
-        },
-        "explicit_keywords": {
-          "type": "array",
-          "items": {
-            "type": "string"
-          }
-        },
-        "planning_keywords": {
-          "type": "array",
-          "items": {
-            "type": "string"
-          }
-        }
-      }
-    },
     "artifactStore": {
       "type": "object",
       "properties": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "oh-my-opencode-lite",
-  "version": "0.1.0",
+  "version": "0.1.2",
   "description": "Delegate-first OpenCode plugin with seven agents, thoth-mem persistence, and bundled SDD skills.",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",
@@ -54,13 +54,13 @@
   "dependencies": {
     "@ast-grep/cli": "^0.40.0",
     "@modelcontextprotocol/sdk": "^1.26.0",
-    "@opencode-ai/plugin": "^1.2.6",
-    "@opencode-ai/sdk": "^1.2.6",
+    "@opencode-ai/plugin": "^1.3.3",
+    "@opencode-ai/sdk": "^1.3.3",
     "unique-names-generator": "^4.7.1",
     "vscode-jsonrpc": "^8.2.0",
     "vscode-languageserver-protocol": "^3.17.5",
     "which": "^6.0.0",
-    "zod": "^4.3.6"
+    "zod": "^4.1.8"
   },
   "devDependencies": {
     "@biomejs/biome": "2.4.2",

package/src/skills/_shared/openspec-convention.md

@@ -8,6 +8,23 @@ This convention applies only when the artifact store mode includes OpenSpec:
 - In `thoth-mem` mode, skip canonical `openspec/` file writes.
 - In `thoth-mem` mode, skip filesystem artifact recovery.
 
+## Pre-flight Validation
+
+When the selected persistence mode includes OpenSpec (`openspec` or `hybrid`),
+every SDD skill must verify this structure before proceeding:
+
+1. `openspec/config.yaml` exists
+2. `openspec/specs/` exists
+3. `openspec/changes/` exists
+
+If any required item is missing:
+
+- STOP and inform the orchestrator that `openspec/` is not initialized.
+- Recommend running the `sdd-init` skill first.
+- Do NOT attempt to create the structure in that skill.
+
+If all required items exist, continue normally.
+
 ## Directory Structure
 
 ```text

package/src/skills/_shared/persistence-contract.md

@@ -7,6 +7,7 @@
 | `thoth-mem` | thoth-mem only | thoth-mem only | The user wants no repo artifact changes |
 | `openspec` | filesystem only | OpenSpec files only | The user wants visible repo artifacts without memory overhead |
 | `hybrid` | thoth-mem, then filesystem fallback | thoth-mem and OpenSpec files | The change should survive compaction and exist in the repo |
+| `none` | orchestrator prompt context only | nowhere (inline response only) | Ephemeral exploration, privacy-sensitive work, or no persistence backend available |
 
 SDD skills MUST obey the selected artifact store mode. Do not reference or rely
 on engram.
@@ -25,6 +26,15 @@ on engram.
 2. Write SDD artifacts to canonical OpenSpec paths only.
 3. Do not call thoth-mem save or recovery tools.
 
+### `none`
+
+1. Read SDD artifacts from orchestrator prompt context only.
+2. Do not persist artifacts to any external store.
+3. Return all artifacts as inline text in the response.
+4. Do not call thoth-mem save tools.
+5. Do not create or modify OpenSpec files.
+6. Recommend enabling `thoth-mem` or `openspec` for persistent work.
+
 ## Hybrid Rules
 
 When running in `hybrid` mode:
@@ -35,24 +45,63 @@ When running in `hybrid` mode:
 4. If filesystem and memory diverge, repair them immediately by rewriting the
    stale copy from the freshest full artifact.
 
+## Memory Ownership
+
+Memory responsibilities are split between orchestrator and sub-agents:
+
+**Orchestrator owns general memory:**
+- Decisions, discoveries, bug fixes, session summaries
+- Progress checkpoints (SDD task state updates)
+- User preferences and configuration notes
+
+**Sub-agents write deterministic SDD artifacts:**
+- Canonical SDD artifacts with topic_key matching `sdd/{change}/{artifact}`
+- Includes: proposal, spec, design, tasks, apply-progress, verify-report,
+  archive-report, state
+- Sub-agents persist these directly when the active mode includes thoth-mem
+- Sub-agents do NOT write general memory observations
+
+This split preserves artifact nuance (sub-agents have full context when writing)
+while keeping general memory centralized under orchestrator control.
+
 ## Retrieval Protocol
 
-Always recover SDD dependencies in this order:
+### 3-Layer Recall for thoth-mem and hybrid modes
 
-1. If the mode is `thoth-mem`, use `thoth_mem_mem_search` with the exact SDD
-   topic key, then `thoth_mem_mem_get_observation` using the returned
-   observation ID.
+Always complete the full 3-layer recall before using content as source material:
+
+1. **Layer 1 (Compact Index):** `thoth_mem_mem_search(..., mode: "compact")` —
+   scan the compact index of observation IDs and titles. This is the most
+   token-efficient entry point.
+2. **Layer 2 (Timeline Context):** `thoth_mem_mem_timeline(observation_id: {id})`
+   — retrieve chronological context (before/after observations) to disambiguate
+   or verify the correct artifact.
+3. **Layer 3 (Full Body):** `thoth_mem_mem_get_observation(id: {id})` — retrieve
+   the complete artifact body for use as source material.
+
+**Mode guidance:**
+- Use `mode: "compact"` (default) for most queries; it returns only IDs and
+  titles.
+- Use `mode: "preview"` only when compact results are insufficient to
+  disambiguate between multiple candidates.
+
+**Never treat `mem_search` output—compact or preview—as the artifact body.**
+Always complete the 3-layer recall before using content as source material.
+
+### Mode-specific retrieval
+
+1. If the mode is `thoth-mem`, apply the 3-layer recall with the exact SDD
+   topic key.
 2. If the mode is `openspec`, read the canonical OpenSpec path from the
    filesystem only.
-3. If the mode is `hybrid`, use `thoth_mem_mem_search` with the exact SDD topic
-   key, then `thoth_mem_mem_get_observation` using the returned observation ID.
+3. If the mode is `hybrid`, apply the 3-layer recall with the exact SDD topic
+   key.
 4. In `hybrid`, if nothing is found in thoth-mem, read the canonical OpenSpec
    path from the filesystem.
 5. In `hybrid`, if filesystem recovery succeeds, re-save the artifact to
    thoth-mem so the two stores converge again.
-
-Never treat the preview returned by `thoth_mem_mem_search` as full source
-material.
+6. If the mode is `none`, read artifacts from the orchestrator prompt context
+   only. Do not attempt to retrieve from thoth-mem or filesystem.
 
 ## Artifact Ownership
 
@@ -64,12 +113,15 @@ material.
   updated `sdd/{change-name}/tasks`
 - `sdd-verify` persists `sdd/{change-name}/verify-report`
 - `sdd-archive` persists `sdd/{change-name}/archive-report`
+- `state` persists `sdd/{change-name}/state`
 
 ## Recovery Notes
 
 - Prefer exact topic-key queries over fuzzy natural-language search.
-- If multiple observations match, choose the exact topic-key match for the
-  current project.
+- Always use the 3-layer recall (`mem_search` → `mem_timeline` →
+  `mem_get_observation`) before treating an artifact as source material.
+- If multiple observations match in `mem_search`, use `mem_timeline` to inspect
+  chronological context and disambiguate.
 - In `openspec` mode, repair missing or stale artifacts by rewriting the
   canonical OpenSpec file only.
 - In `thoth-mem` mode, repair missing or stale artifacts by re-saving the full

package/src/skills/_shared/thoth-mem-convention.md

@@ -14,6 +14,7 @@ This convention applies only when the artifact store mode includes thoth-mem:
 Use the thoth-mem tool names exactly as exposed by the plugin:
 
 - `thoth_mem_mem_search`
+- `thoth_mem_mem_timeline`
 - `thoth_mem_mem_get_observation`
 - `thoth_mem_mem_save`
 - `thoth_mem_mem_update` (optional when you already have an observation ID)
@@ -36,32 +37,89 @@ Supported artifact names:
 - `apply-progress`
 - `verify-report`
 - `archive-report`
+- `state`
 
 Use the same value for `title` and `topic_key` unless there is a strong reason
 not to.
 
-## Two-Step Recovery
+## State Artifact Format
+
+The orchestrator persists a lightweight state checkpoint after each SDD phase
+transition to enable recovery:
+
+```yaml
+change: {change-name}
+phase: {last-completed-phase}
+mode: {thoth-mem|openspec|hybrid|none}
+artifacts:
+  proposal: true
+  spec: false
+  design: false
+  tasks: false
+  apply-progress: false
+  verify-report: false
+  archive-report: false
+last_updated: {ISO 8601 timestamp}
+```
 
-1. Search by exact topic key:
+Save with:
+
+```text
+thoth_mem_mem_save(
+  title: "sdd/{change-name}/state",
+  topic_key: "sdd/{change-name}/state",
+  type: "architecture",
+  project: "{project}",
+  scope: "project",
+  content: "{YAML state content}"
+)
+```
+
+Recovery: `thoth_mem_mem_search("sdd/{change-name}/state")` → `thoth_mem_mem_get_observation(id)` → parse YAML → restore phase state.
+
+## Three-Layer Recall Protocol
+
+1. **Scan compact index** by exact topic key:
 
 ```text
 thoth_mem_mem_search(
-  query: "sdd/{change-name}/{artifact}",
-  project: "{project}"
+  query: "topic_key:sdd/{change-name}/{artifact}",
+  project: "{project}",
+  mode: "compact"
+)
+```
+
+Use `mode: "compact"` (the default) for token efficiency. Switch to `mode: "preview"`
+only when compact results are insufficient to disambiguate between multiple results.
+
+2. **Get chronological context** around the found observation:
+
+```text
+thoth_mem_mem_timeline(
+  observation_id: {id},
+  before: 5,
+  after: 5
 )
 ```
 
-2. Retrieve the full artifact:
+This shows related observations in the same session, helping you understand the
+artifact's evolution and dependencies.
+
+3. **Retrieve full artifact content**:
 
 ```text
 thoth_mem_mem_get_observation(id: {observation-id})
 ```
 
-`thoth_mem_mem_search` returns previews only. Full SDD dependencies require the
-second call.
+Search returns compact results (IDs + titles) by default. Neither compact nor
+preview mode returns the full artifact body. Always complete the 3-layer recall
+to get the actual content.
 
 ## Save Contract
 
+**CRITICAL:** The orchestrator MUST persist the state artifact after each SDD
+phase transition. This is the canonical checkpoint for resume/recovery.
+
 Persist SDD artifacts with a stable topic key so repeated saves upsert instead
 of creating duplicates:
 

package/src/skills/cartography/SKILL.md

@@ -1,160 +1,160 @@
----
-name: cartography
-description: Repository understanding and hierarchical codemap generation
----
-
-# Cartography Skill
-
-You help users understand and map repositories by creating hierarchical codemaps.
-
-## When to Use
-
-- User asks to understand/map a repository
-- User wants codebase documentation
-- Starting work on an unfamiliar codebase
-
-## Workflow
-
-### Step 1: Check for Existing State
-
-**First, check if `.lite/cartography.json` exists in the repo root.**
-
-If it **exists**: Skip to Step 3 (Detect Changes) - no need to re-initialize.
-
-If it **doesn't exist**: Continue to Step 2 (Initialize).
-
-### Step 2: Initialize (Only if no state exists)
-
-1. **Analyze the repository structure** - List files, understand directories
-2. **Infer patterns** for **core code/config files ONLY** to include:
-   - **Include**: `src/**/*.ts`, `package.json`, etc.
-   - **Exclude (MANDATORY)**: Do NOT include tests, documentation, or translations.
-     - Tests: `**/*.test.ts`, `**/*.spec.ts`, `tests/**`, `__tests__/**`
-     - Docs: `docs/**`, `*.md` (except root `README.md` if needed), `LICENSE`
-     - Build/Deps: `node_modules/**`, `dist/**`, `build/**`, `*.min.js`
-   - Respect `.gitignore` automatically
-3. **Run cartographer.py init**:
-
-```bash
-python3 ~/.config/opencode/skills/cartography/scripts/cartographer.py init \
-  --root ./ \
-  --include "src/**/*.ts" \
-  --exclude "**/*.test.ts" --exclude "dist/**" --exclude "node_modules/**"
-```
-
-This creates:
-- `.lite/cartography.json` - File and folder hashes for change detection
-- Empty `codemap.md` files in all relevant subdirectories
-
-4. **Delegate to Explorer agents** - Spawn one explorer per folder to read code and fill in its specific `codemap.md` file.
-
-### Step 3: Detect Changes (If state already exists)
-
-1. **Run cartographer.py changes** to see what changed:
-
-```bash
-python3 ~/.config/opencode/skills/cartography/scripts/cartographer.py changes \
-  --root ./
-```
-
-2. **Review the output** - It shows:
-   - Added files
-   - Removed files
-   - Modified files
-   - Affected folders
-
-3. **Only update affected codemaps** - Spawn one explorer per affected folder to update its `codemap.md`.
-4. **Run update** to save new state:
-
-```bash
-python3 ~/.config/opencode/skills/cartography/scripts/cartographer.py update \
-  --root ./
-```
-
-### Step 4: Finalize Repository Atlas (Root Codemap)
-
-Once all specific directories are mapped, the Orchestrator must create or update the root `codemap.md`. This file serves as the **Master Entry Point** for any agent or human entering the repository.
-
-1.  **Map Root Assets**: Document the root-level files (e.g., `package.json`, `index.ts`, `plugin.json`) and the project's overall purpose.
-2.  **Aggregate Sub-Maps**: Create a "Repository Directory Map" section. For every folder that has a `codemap.md`, extract its **Responsibility** summary and include it in a table or list in the root map.
-3.  **Cross-Reference**: Ensure that the root map contains the absolute or relative paths to the sub-maps so agents can jump directly to the relevant details.
-
-### Step 5: Register Codemap in AGENTS.md
-
-**OpenCode auto-loads `AGENTS.md` into agent context on every session.** To ensure agents automatically discover and use the codemap, update (or create) `AGENTS.md` at the repo root:
-
-1. If `AGENTS.md` already exists and already contains a `## Repository Map` section, **skip this step** — the reference is already set up.
-2. If `AGENTS.md` exists but has no `## Repository Map` section, **append** the section below.
-3. If `AGENTS.md` doesn't exist, **create** it with the section below.
-
-```markdown
-## Repository Map
-
-A full codemap is available at `codemap.md` in the project root.
-
-Before working on any task, read `codemap.md` to understand:
-- Project architecture and entry points
-- Directory responsibilities and design patterns
-- Data flow and integration points between modules
-
-For deep work on a specific folder, also read that folder's `codemap.md`.
-```
-
-This is idempotent — repeated cartography runs will detect the existing section and skip. No duplication.
-
-
-## Codemap Content
-
-Explorers are granted write permissions for `codemap.md` files during this workflow. Use precise technical terminology to document the implementation:
-
-- **Responsibility** - Define the specific role of this directory using standard software engineering terms (e.g., "Service Layer", "Data Access Object", "Middleware").
-- **Design Patterns** - Identify and name specific patterns used (e.g., "Observer", "Singleton", "Factory", "Strategy"). Detail the abstractions and interfaces.
-- **Data & Control Flow** - Explicitly trace how data enters and leaves the module. Mention specific function call sequences and state transitions.
-- **Integration Points** - List dependencies and consumer modules. Use technical names for hooks, events, or API endpoints.
-
-Example codemap:
-
-```markdown
-# src/agents/
-
-## Responsibility
-Defines agent personalities and manages their configuration lifecycle.
-
-## Design
-Each agent is a prompt + permission set. Config system uses:
-- Default prompts (orchestrator.ts, explorer.ts, etc.)
-- User overrides from ~/.config/opencode/oh-my-opencode-lite.json
-- Permission wildcards for skill/MCP access control
-
-## Flow
-1. Plugin loads → calls getAgentConfigs()
-2. Reads user config preset
-3. Merges defaults with overrides
-4. Applies permission rules (wildcard expansion)
-5. Returns agent configs to OpenCode
-
-## Integration
-- Consumed by: Main plugin (src/index.ts)
-- Depends on: Config loader, skills registry
-```
-
-Example **Root Codemap (Atlas)**:
-
-```markdown
-# Repository Atlas: oh-my-opencode-lite
-
-## Project Responsibility
-A high-performance, low-latency agent orchestration plugin for OpenCode, focusing on specialized sub-agent delegation and background task management.
-
-## System Entry Points
-- `src/index.ts`: Plugin initialization and OpenCode integration.
-- `package.json`: Dependency manifest and build scripts.
-- `oh-my-opencode-lite.json`: User configuration schema.
-
-## Directory Map (Aggregated)
-| Directory | Responsibility Summary | Detailed Map |
-|-----------|------------------------|--------------|
-| `src/agents/` | Defines agent personalities (Orchestrator, Explorer) and manages model routing. | [View Map](src/agents/codemap.md) |
-| `src/features/` | Core logic for tmux integration, background task spawning, and session state. | [View Map](src/features/codemap.md) |
-| `src/config/` | Implements the configuration loading pipeline and environment variable injection. | [View Map](src/config/codemap.md) |
-```
+---
+name: cartography
+description: Repository understanding and hierarchical codemap generation
+---
+
+# Cartography Skill
+
+You help users understand and map repositories by creating hierarchical codemaps.
+
+## When to Use
+
+- User asks to understand/map a repository
+- User wants codebase documentation
+- Starting work on an unfamiliar codebase
+
+## Workflow
+
+### Step 1: Check for Existing State
+
+**First, check if `.lite/cartography.json` exists in the repo root.**
+
+If it **exists**: Skip to Step 3 (Detect Changes) - no need to re-initialize.
+
+If it **doesn't exist**: Continue to Step 2 (Initialize).
+
+### Step 2: Initialize (Only if no state exists)
+
+1. **Analyze the repository structure** - List files, understand directories
+2. **Infer patterns** for **core code/config files ONLY** to include:
+   - **Include**: `src/**/*.ts`, `package.json`, etc.
+   - **Exclude (MANDATORY)**: Do NOT include tests, documentation, or translations.
+     - Tests: `**/*.test.ts`, `**/*.spec.ts`, `tests/**`, `__tests__/**`
+     - Docs: `docs/**`, `*.md` (except root `README.md` if needed), `LICENSE`
+     - Build/Deps: `node_modules/**`, `dist/**`, `build/**`, `*.min.js`
+   - Respect `.gitignore` automatically
+3. **Run cartographer.py init**:
+
+```bash
+python3 ~/.config/opencode/skills/cartography/scripts/cartographer.py init \
+  --root ./ \
+  --include "src/**/*.ts" \
+  --exclude "**/*.test.ts" --exclude "dist/**" --exclude "node_modules/**"
+```
+
+This creates:
+- `.lite/cartography.json` - File and folder hashes for change detection
+- Empty `codemap.md` files in all relevant subdirectories
+
+4. **Delegate discovery to explorer agents** — Spawn one explorer per folder to read code and gather findings. Then **delegate to quick** to write each folder's `codemap.md` based on explorer findings.
+
+### Step 3: Detect Changes (If state already exists)
+
+1. **Run cartographer.py changes** to see what changed:
+
+```bash
+python3 ~/.config/opencode/skills/cartography/scripts/cartographer.py changes \
+  --root ./
+```
+
+2. **Review the output** - It shows:
+   - Added files
+   - Removed files
+   - Modified files
+   - Affected folders
+
+3. **Only update affected codemaps** — Spawn one explorer per affected folder to gather updated findings, then dispatch quick to write the updated `codemap.md`.
+4. **Run update** to save new state:
+
+```bash
+python3 ~/.config/opencode/skills/cartography/scripts/cartographer.py update \
+  --root ./
+```
+
+### Step 4: Finalize Repository Atlas (Root Codemap)
+
+Once all specific directories are mapped, the Orchestrator must dispatch quick to create or update the root `codemap.md`. This file serves as the **Master Entry Point** for any agent or human entering the repository.
+
+1.  **Map Root Assets**: Document the root-level files (e.g., `package.json`, `index.ts`, `plugin.json`) and the project's overall purpose.
+2.  **Aggregate Sub-Maps**: Create a "Repository Directory Map" section. For every folder that has a `codemap.md`, extract its **Responsibility** summary and include it in a table or list in the root map.
+3.  **Cross-Reference**: Ensure that the root map contains the absolute or relative paths to the sub-maps so agents can jump directly to the relevant details.
+
+### Step 5: Register Codemap in AGENTS.md
+
+**OpenCode auto-loads `AGENTS.md` into agent context on every session.** To ensure agents automatically discover and use the codemap, dispatch quick to update (or create) `AGENTS.md` at the repo root:
+
+1. If `AGENTS.md` already exists and already contains a `## Repository Map` section, **skip this step** — the reference is already set up.
+2. If `AGENTS.md` exists but has no `## Repository Map` section, **append** the section below.
+3. If `AGENTS.md` doesn't exist, **create** it with the section below.
+
+```markdown
+## Repository Map
+
+A full codemap is available at `codemap.md` in the project root.
+
+Before working on any task, read `codemap.md` to understand:
+- Project architecture and entry points
+- Directory responsibilities and design patterns
+- Data flow and integration points between modules
+
+For deep work on a specific folder, also read that folder's `codemap.md`.
+```
+
+This is idempotent — repeated cartography runs will detect the existing section and skip. No duplication.
+
+
+## Codemap Content
+
+Explorer agents gather the technical findings; quick agents write the `codemap.md` files. Use precise technical terminology to document the implementation:
+
+- **Responsibility** - Define the specific role of this directory using standard software engineering terms (e.g., "Service Layer", "Data Access Object", "Middleware").
+- **Design Patterns** - Identify and name specific patterns used (e.g., "Observer", "Singleton", "Factory", "Strategy"). Detail the abstractions and interfaces.
+- **Data & Control Flow** - Explicitly trace how data enters and leaves the module. Mention specific function call sequences and state transitions.
+- **Integration Points** - List dependencies and consumer modules. Use technical names for hooks, events, or API endpoints.
+
+Example codemap:
+
+```markdown
+# src/agents/
+
+## Responsibility
+Defines agent personalities and manages their configuration lifecycle.
+
+## Design
+Each agent is a prompt + permission set. Config system uses:
+- Default prompts (orchestrator.ts, explorer.ts, etc.)
+- User overrides from ~/.config/opencode/oh-my-opencode-lite.json
+- Permission wildcards for skill/MCP access control
+
+## Flow
+1. Plugin loads → calls getAgentConfigs()
+2. Reads user config preset
+3. Merges defaults with overrides
+4. Applies permission rules (wildcard expansion)
+5. Returns agent configs to OpenCode
+
+## Integration
+- Consumed by: Main plugin (src/index.ts)
+- Depends on: Config loader, skills registry
+```
+
+Example **Root Codemap (Atlas)**:
+
+```markdown
+# Repository Atlas: oh-my-opencode-lite
+
+## Project Responsibility
+A high-performance, low-latency agent orchestration plugin for OpenCode, focusing on specialized sub-agent delegation and background task management.
+
+## System Entry Points
+- `src/index.ts`: Plugin initialization and OpenCode integration.
+- `package.json`: Dependency manifest and build scripts.
+- `oh-my-opencode-lite.json`: User configuration schema.
+
+## Directory Map (Aggregated)
+| Directory | Responsibility Summary | Detailed Map |
+|-----------|------------------------|--------------|
+| `src/agents/` | Defines agent personalities (Orchestrator, Explorer) and manages model routing. | [View Map](src/agents/codemap.md) |
+| `src/features/` | Core logic for tmux integration, background task spawning, and session state. | [View Map](src/features/codemap.md) |
+| `src/config/` | Implements the configuration loading pipeline and environment variable injection. | [View Map](src/config/codemap.md) |
+```