skykoi 2026.3.11 → 2026.3.13

package/docs/concepts/models.md

@@ -15,7 +15,7 @@ Quick provider overview + examples: [/concepts/model-providers](/concepts/model-
 
 ## How model selection works
 
-SkyKoi selects models in this order:
+SKYKOI selects models in this order:
 
 1. **Primary** model (`agents.defaults.model.primary` or `agents.defaults.model`).
 2. **Fallbacks** in `agents.defaults.model.fallbacks` (in order).
@@ -24,7 +24,7 @@ SkyKoi selects models in this order:
 
 Related:
 
-- `agents.defaults.models` is the allowlist/catalog of models SkyKoi can use (plus aliases).
+- `agents.defaults.models` is the allowlist/catalog of models SKYKOI can use (plus aliases).
 - `agents.defaults.imageModel` is used **only when** the primary model can’t accept images.
 - Per-agent defaults can override `agents.defaults.model` via `agents.list[].model` plus bindings (see [/concepts/multi-agent](/concepts/multi-agent)).
 
@@ -38,7 +38,7 @@ Related:
 If you don’t want to hand-edit config, run the onboarding wizard:
 
 ```bash
-SkyKoi onboard
+SKYKOI onboard
 ```
 
 It can set up model + auth for common providers, including **OpenAI Code (Codex)
@@ -62,7 +62,7 @@ Provider configuration examples (including OpenCode Zen) live in
 
 If `agents.defaults.models` is set, it becomes the **allowlist** for `/model` and for
 session overrides. When a user selects a model that isn’t in that allowlist,
-SkyKoi returns:
+SKYKOI returns:
 
 ```
 Model "provider/model" is not allowed. Use /model to list available models.
@@ -108,34 +108,34 @@ Notes:
 - `/model status` is the detailed view (auth candidates and, when configured, provider endpoint `baseUrl` + `api` mode).
 - Model refs are parsed by splitting on the **first** `/`. Use `provider/model` when typing `/model <ref>`.
 - If the model ID itself contains `/` (OpenRouter-style), you must include the provider prefix (example: `/model openrouter/moonshotai/kimi-k2`).
-- If you omit the provider, SkyKoi treats the input as an alias or a model for the **default provider** (only works when there is no `/` in the model ID).
+- If you omit the provider, SKYKOI treats the input as an alias or a model for the **default provider** (only works when there is no `/` in the model ID).
 
 Full command behavior/config: [Slash commands](/tools/slash-commands).
 
 ## CLI commands
 
 ```bash
-SkyKoi models list
-SkyKoi models status
-SkyKoi models set <provider/model>
-SkyKoi models set-image <provider/model>
-
-SkyKoi models aliases list
-SkyKoi models aliases add <alias> <provider/model>
-SkyKoi models aliases remove <alias>
-
-SkyKoi models fallbacks list
-SkyKoi models fallbacks add <provider/model>
-SkyKoi models fallbacks remove <provider/model>
-SkyKoi models fallbacks clear
-
-SkyKoi models image-fallbacks list
-SkyKoi models image-fallbacks add <provider/model>
-SkyKoi models image-fallbacks remove <provider/model>
-SkyKoi models image-fallbacks clear
+SKYKOI models list
+SKYKOI models status
+SKYKOI models set <provider/model>
+SKYKOI models set-image <provider/model>
+
+SKYKOI models aliases list
+SKYKOI models aliases add <alias> <provider/model>
+SKYKOI models aliases remove <alias>
+
+SKYKOI models fallbacks list
+SKYKOI models fallbacks add <provider/model>
+SKYKOI models fallbacks remove <provider/model>
+SKYKOI models fallbacks clear
+
+SKYKOI models image-fallbacks list
+SKYKOI models image-fallbacks add <provider/model>
+SKYKOI models image-fallbacks remove <provider/model>
+SKYKOI models image-fallbacks clear
 ```
 
-`SkyKoi models` (no subcommand) is a shortcut for `models status`.
+`SKYKOI models` (no subcommand) is a shortcut for `models status`.
 
 ### `models list`
 
@@ -163,12 +163,12 @@ Preferred Anthropic auth is the Claude Code CLI setup-token (run anywhere; paste
 
 ```bash
 claude setup-token
-SkyKoi models status
+SKYKOI models status
 ```
 
 ## Scanning (OpenRouter free models)
 
-`SkyKoi models scan` inspects OpenRouter’s **free model catalog** and can
+`SKYKOI models scan` inspects OpenRouter’s **free model catalog** and can
 optionally probe models for tool and image support.
 
 Key flags:
@@ -204,5 +204,5 @@ mode, pass `--yes` to accept defaults.
 ## Models registry (`models.json`)
 
 Custom providers in `models.providers` are written into `models.json` under the
-agent directory (default `~/.skykoi/agents/<agentId>/models.json`). This file
+agent directory (default `~/.SKYKOI/agents/<agentId>/models.json`). This file
 is merged by default unless `models.mode` is set to `replace`.

package/docs/concepts/multi-agent.md

@@ -15,12 +15,12 @@ An **agent** is a fully scoped brain with its own:
 
 - **Workspace** (files, AGENTS.md/SOUL.md/USER.md, local notes, persona rules).
 - **State directory** (`agentDir`) for auth profiles, model registry, and per-agent config.
-- **Session store** (chat history + routing state) under `~/.skykoi/agents/<agentId>/sessions`.
+- **Session store** (chat history + routing state) under `~/.SKYKOI/agents/<agentId>/sessions`.
 
 Auth profiles are **per-agent**. Each agent reads from its own:
 
 ```
-~/.skykoi/agents/<agentId>/agent/auth-profiles.json
+~/.SKYKOI/agents/<agentId>/agent/auth-profiles.json
 ```
 
 Main agent credentials are **not** shared automatically. Never reuse `agentDir`
@@ -28,7 +28,7 @@ across agents (it causes auth/session collisions). If you want to share creds,
 copy `auth-profiles.json` into the other agent's `agentDir`.
 
 Skills are per-agent via each workspace’s `skills/` folder, with shared skills
-available from `~/.skykoi/skills`. See [Skills: per-agent vs shared](/tools/skills#per-agent-vs-shared-skills).
+available from `~/.SKYKOI/skills`. See [Skills: per-agent vs shared](/tools/skills#per-agent-vs-shared-skills).
 
 The Gateway can host **one agent** (default) or **many agents** side-by-side.
 
@@ -39,27 +39,27 @@ reach other host locations unless sandboxing is enabled. See
 
 ## Paths (quick map)
 
-- Config: `~/.skykoi/skykoi.json` (or `SKYKOI_CONFIG_PATH`)
-- State dir: `~/.skykoi` (or `SKYKOI_STATE_DIR`)
-- Workspace: `~/.skykoi/workspace` (or `~/.skykoi/workspace-<agentId>`)
-- Agent dir: `~/.skykoi/agents/<agentId>/agent` (or `agents.list[].agentDir`)
-- Sessions: `~/.skykoi/agents/<agentId>/sessions`
+- Config: `~/.SKYKOI/SKYKOI.json` (or `SKYKOI_CONFIG_PATH`)
+- State dir: `~/.SKYKOI` (or `SKYKOI_STATE_DIR`)
+- Workspace: `~/.SKYKOI/workspace` (or `~/.SKYKOI/workspace-<agentId>`)
+- Agent dir: `~/.SKYKOI/agents/<agentId>/agent` (or `agents.list[].agentDir`)
+- Sessions: `~/.SKYKOI/agents/<agentId>/sessions`
 
 ### Single-agent mode (default)
 
-If you do nothing, SkyKoi runs a single agent:
+If you do nothing, SKYKOI runs a single agent:
 
 - `agentId` defaults to **`main`**.
 - Sessions are keyed as `agent:main:<mainKey>`.
-- Workspace defaults to `~/.skykoi/workspace` (or `~/.skykoi/workspace-<profile>` when `SKYKOI_PROFILE` is set).
-- State defaults to `~/.skykoi/agents/main/agent`.
+- Workspace defaults to `~/.SKYKOI/workspace` (or `~/.SKYKOI/workspace-<profile>` when `SKYKOI_PROFILE` is set).
+- State defaults to `~/.SKYKOI/agents/main/agent`.
 
 ## Agent helper
 
 Use the agent wizard to add a new isolated agent:
 
 ```bash
-SkyKoi agents add work
+SKYKOI agents add work
 ```
 
 Then add `bindings` (or let the wizard do it) to route inbound messages.
@@ -67,7 +67,7 @@ Then add `bindings` (or let the wizard do it) to route inbound messages.
 Verify with:
 
 ```bash
-SkyKoi agents list --bindings
+SKYKOI agents list --bindings
 ```
 
 ## Multiple agents = multiple people, multiple personalities
@@ -92,8 +92,8 @@ Example:
 {
   agents: {
     list: [
-      { id: "alex", workspace: "~/.skykoi/workspace-alex" },
-      { id: "mia", workspace: "~/.skykoi/workspace-mia" },
+      { id: "alex", workspace: "~/.SKYKOI/workspace-alex" },
+      { id: "mia", workspace: "~/.SKYKOI/workspace-mia" },
     ],
   },
   bindings: [
@@ -140,7 +140,7 @@ multiple phone numbers without mixing sessions.
 
 ## Example: two WhatsApps → two agents
 
-`~/.skykoi/skykoi.json` (JSON5):
+`~/.SKYKOI/SKYKOI.json` (JSON5):
 
 ```js
 {
@@ -150,14 +150,14 @@ multiple phone numbers without mixing sessions.
         id: "home",
         default: true,
         name: "Home",
-        workspace: "~/.skykoi/workspace-home",
-        agentDir: "~/.skykoi/agents/home/agent",
+        workspace: "~/.SKYKOI/workspace-home",
+        agentDir: "~/.SKYKOI/agents/home/agent",
       },
       {
         id: "work",
         name: "Work",
-        workspace: "~/.skykoi/workspace-work",
-        agentDir: "~/.skykoi/agents/work/agent",
+        workspace: "~/.SKYKOI/workspace-work",
+        agentDir: "~/.SKYKOI/agents/work/agent",
       },
     ],
   },
@@ -190,12 +190,12 @@ multiple phone numbers without mixing sessions.
     whatsapp: {
       accounts: {
         personal: {
-          // Optional override. Default: ~/.skykoi/credentials/whatsapp/personal
-          // authDir: "~/.skykoi/credentials/whatsapp/personal",
+          // Optional override. Default: ~/.SKYKOI/credentials/whatsapp/personal
+          // authDir: "~/.SKYKOI/credentials/whatsapp/personal",
         },
         biz: {
-          // Optional override. Default: ~/.skykoi/credentials/whatsapp/biz
-          // authDir: "~/.skykoi/credentials/whatsapp/biz",
+          // Optional override. Default: ~/.SKYKOI/credentials/whatsapp/biz
+          // authDir: "~/.SKYKOI/credentials/whatsapp/biz",
         },
       },
     },
@@ -214,13 +214,13 @@ Split by channel: route WhatsApp to a fast everyday agent and Telegram to an Opu
       {
         id: "chat",
         name: "Everyday",
-        workspace: "~/.skykoi/workspace-chat",
+        workspace: "~/.SKYKOI/workspace-chat",
         model: "anthropic/claude-sonnet-4-5",
       },
       {
         id: "opus",
         name: "Deep Work",
-        workspace: "~/.skykoi/workspace-opus",
+        workspace: "~/.SKYKOI/workspace-opus",
         model: "anthropic/claude-opus-4-6",
       },
     ],
@@ -248,13 +248,13 @@ Keep WhatsApp on the fast agent, but route one DM to Opus:
       {
         id: "chat",
         name: "Everyday",
-        workspace: "~/.skykoi/workspace-chat",
+        workspace: "~/.SKYKOI/workspace-chat",
         model: "anthropic/claude-sonnet-4-5",
       },
       {
         id: "opus",
         name: "Deep Work",
-        workspace: "~/.skykoi/workspace-opus",
+        workspace: "~/.SKYKOI/workspace-opus",
         model: "anthropic/claude-opus-4-6",
       },
     ],
@@ -280,7 +280,7 @@ and a tighter tool policy:
       {
         id: "family",
         name: "Family",
-        workspace: "~/.skykoi/workspace-family",
+        workspace: "~/.SKYKOI/workspace-family",
         identity: { name: "Family Bot" },
         groupChat: {
           mentionPatterns: ["@family", "@familybot", "@Family Bot"],
@@ -333,7 +333,7 @@ Starting with v2026.1.6, each agent can have its own sandbox and tool restrictio
     list: [
       {
         id: "personal",
-        workspace: "~/.skykoi/workspace-personal",
+        workspace: "~/.SKYKOI/workspace-personal",
         sandbox: {
           mode: "off",  // No sandbox for personal agent
         },
@@ -341,7 +341,7 @@ Starting with v2026.1.6, each agent can have its own sandbox and tool restrictio
       },
       {
         id: "family",
-        workspace: "~/.skykoi/workspace-family",
+        workspace: "~/.SKYKOI/workspace-family",
         sandbox: {
           mode: "all",     // Always sandboxed
           scope: "agent",  // One container per agent

package/docs/concepts/oauth.md

@@ -1,7 +1,7 @@
 ---
-summary: "OAuth in SkyKoi: token exchange, storage, and multi-account patterns"
+summary: "OAuth in SKYKOI: token exchange, storage, and multi-account patterns"
 read_when:
-  - You want to understand SkyKoi OAuth end-to-end
+  - You want to understand SKYKOI OAuth end-to-end
   - You hit token invalidation / logout issues
   - You want setup-token or OAuth auth flows
   - You want multiple accounts or profile routing
@@ -10,17 +10,17 @@ title: "OAuth"
 
 # OAuth
 
-SkyKoi supports “subscription auth” via OAuth for providers that offer it (notably **OpenAI Codex (ChatGPT OAuth)**). For Anthropic subscriptions, use the **setup-token** flow. This page explains:
+SKYKOI supports “subscription auth” via OAuth for providers that offer it (notably **OpenAI Codex (ChatGPT OAuth)**). For Anthropic subscriptions, use the **setup-token** flow. This page explains:
 
 - how the OAuth **token exchange** works (PKCE)
 - where tokens are **stored** (and why)
 - how to handle **multiple accounts** (profiles + per-session overrides)
 
-SkyKoi also supports **provider plugins** that ship their own OAuth or API‑key
+SKYKOI also supports **provider plugins** that ship their own OAuth or API‑key
 flows. Run them via:
 
 ```bash
-SkyKoi models auth login --provider <id>
+SKYKOI models auth login --provider <id>
 ```
 
 ## The token sink (why it exists)
@@ -29,9 +29,9 @@ OAuth providers commonly mint a **new refresh token** during login/refresh flows
 
 Practical symptom:
 
-- you log in via SkyKoi _and_ via Claude Code / Codex CLI → one of them randomly gets “logged out” later
+- you log in via SKYKOI _and_ via Claude Code / Codex CLI → one of them randomly gets “logged out” later
 
-To reduce that, SkyKoi treats `auth-profiles.json` as a **token sink**:
+To reduce that, SKYKOI treats `auth-profiles.json` as a **token sink**:
 
 - the runtime reads credentials from **one place**
 - we can keep multiple profiles and route them deterministically
@@ -40,48 +40,48 @@ To reduce that, SkyKoi treats `auth-profiles.json` as a **token sink**:
 
 Secrets are stored **per-agent**:
 
-- Auth profiles (OAuth + API keys): `~/.skykoi/agents/<agentId>/agent/auth-profiles.json`
-- Runtime cache (managed automatically; don’t edit): `~/.skykoi/agents/<agentId>/agent/auth.json`
+- Auth profiles (OAuth + API keys): `~/.SKYKOI/agents/<agentId>/agent/auth-profiles.json`
+- Runtime cache (managed automatically; don’t edit): `~/.SKYKOI/agents/<agentId>/agent/auth.json`
 
 Legacy import-only file (still supported, but not the main store):
 
-- `~/.skykoi/credentials/oauth.json` (imported into `auth-profiles.json` on first use)
+- `~/.SKYKOI/credentials/oauth.json` (imported into `auth-profiles.json` on first use)
 
 All of the above also respect `$SKYKOI_STATE_DIR` (state dir override). Full reference: [/gateway/configuration](/gateway/configuration#auth-storage-oauth--api-keys)
 
 ## Anthropic setup-token (subscription auth)
 
-Run `claude setup-token` on any machine, then paste it into SkyKoi:
+Run `claude setup-token` on any machine, then paste it into SKYKOI:
 
 ```bash
-SkyKoi models auth setup-token --provider anthropic
+SKYKOI models auth setup-token --provider anthropic
 ```
 
 If you generated the token elsewhere, paste it manually:
 
 ```bash
-SkyKoi models auth paste-token --provider anthropic
+SKYKOI models auth paste-token --provider anthropic
 ```
 
 Verify:
 
 ```bash
-SkyKoi models status
+SKYKOI models status
 ```
 
 ## OAuth exchange (how login works)
 
-SkyKoi’s interactive login flows are implemented in `@mariozechner/pi-ai` and wired into the wizards/commands.
+SKYKOI’s interactive login flows are implemented in `@mariozechner/pi-ai` and wired into the wizards/commands.
 
 ### Anthropic (Claude Pro/Max) setup-token
 
 Flow shape:
 
 1. run `claude setup-token`
-2. paste the token into SkyKoi
+2. paste the token into SKYKOI
 3. store as a token auth profile (no refresh)
 
-The wizard path is `SkyKoi onboard` → auth choice `setup-token` (Anthropic).
+The wizard path is `SKYKOI onboard` → auth choice `setup-token` (Anthropic).
 
 ### OpenAI Codex (ChatGPT OAuth)
 
@@ -94,7 +94,7 @@ Flow shape (PKCE):
 5. exchange at `https://auth.openai.com/oauth/token`
 6. extract `accountId` from the access token and store `{ access, refresh, expires, accountId }`
 
-Wizard path is `SkyKoi onboard` → auth choice `openai-codex`.
+Wizard path is `SKYKOI onboard` → auth choice `openai-codex`.
 
 ## Refresh + expiry
 
@@ -116,8 +116,8 @@ Two patterns:
 If you want “personal” and “work” to never interact, use isolated agents (separate sessions + credentials + workspace):
 
 ```bash
-SkyKoi agents add work
-SkyKoi agents add personal
+SKYKOI agents add work
+SKYKOI agents add personal
 ```
 
 Then configure auth per-agent (wizard) and route chats to the right agent.
@@ -137,7 +137,7 @@ Example (session override):
 
 How to see what profile IDs exist:
 
-- `SkyKoi channels list --json` (shows `auth[]`)
+- `SKYKOI channels list --json` (shows `auth[]`)
 
 Related docs:
 

package/docs/concepts/presence.md

@@ -1,5 +1,5 @@
 ---
-summary: "How SkyKoi presence entries are produced, merged, and displayed"
+summary: "How SKYKOI presence entries are produced, merged, and displayed"
 read_when:
   - Debugging the Instances tab
   - Investigating duplicate or stale instance rows
@@ -9,7 +9,7 @@ title: "Presence"
 
 # Presence
 
-SkyKoi “presence” is a lightweight, best‑effort view of:
+SKYKOI “presence” is a lightweight, best‑effort view of:
 
 - the **Gateway** itself, and
 - **clients connected to the Gateway** (mac app, WebChat, CLI, etc.)

package/docs/concepts/retry.md

@@ -38,7 +38,7 @@ title: "Retry Policy"
 
 ## Configuration
 
-Set retry policy per provider in `~/.skykoi/skykoi.json`:
+Set retry policy per provider in `~/.SKYKOI/SKYKOI.json`:
 
 ```json5
 {

package/docs/concepts/session-pruning.md

@@ -21,7 +21,7 @@ Session pruning trims **old tool results** from the in-memory context right befo
 
 - **OAuth or setup-token** profiles: enable `cache-ttl` pruning and set heartbeat to `1h`.
 - **API key** profiles: enable `cache-ttl` pruning, set heartbeat to `30m`, and default `cacheControlTtl` to `1h` on Anthropic models.
-- If you set any of these values explicitly, SkyKoi does **not** override them.
+- If you set any of these values explicitly, SKYKOI does **not** override them.
 
 ## What this improves (cost + cache behavior)
 

package/docs/concepts/session-tool.md

@@ -73,7 +73,7 @@ Behavior:
 
 - `includeTools=false` filters `role: "toolResult"` messages.
 - Returns messages array in the raw transcript format.
-- When given a `sessionId`, SkyKoi resolves it to the corresponding session key (missing ids error).
+- When given a `sessionId`, SKYKOI resolves it to the corresponding session key (missing ids error).
 
 ## sessions_send
 
@@ -94,11 +94,11 @@ Behavior:
 - Announce delivery runs after the primary run completes and is best-effort; `status: "ok"` does not guarantee the announce was delivered.
 - Waits via gateway `agent.wait` (server-side) so reconnects don't drop the wait.
 - Agent-to-agent message context is injected for the primary run.
-- After the primary run completes, SkyKoi runs a **reply-back loop**:
+- After the primary run completes, SKYKOI runs a **reply-back loop**:
   - Round 2+ alternates between requester and target agents.
   - Reply exactly `REPLY_SKIP` to stop the ping‑pong.
   - Max turns is `session.agentToAgent.maxPingPongTurns` (0–5, default 5).
-- Once the loop ends, SkyKoi runs the **agent‑to‑agent announce step** (target agent only):
+- Once the loop ends, SKYKOI runs the **agent‑to‑agent announce step** (target agent only):
   - Reply exactly `ANNOUNCE_SKIP` to stay silent.
   - Any other reply is sent to the target channel.
   - Announce step includes the original request + round‑1 reply + latest ping‑pong reply.
@@ -167,7 +167,7 @@ Behavior:
 - Sub-agents default to the full tool set **minus session tools** (configurable via `tools.subagents.tools`).
 - Sub-agents are not allowed to call `sessions_spawn` (no sub-agent → sub-agent spawning).
 - Always non-blocking: returns `{ status: "accepted", runId, childSessionKey }` immediately.
-- After completion, SkyKoi runs a sub-agent **announce step** and posts the result to the requester chat channel.
+- After completion, SKYKOI runs a sub-agent **announce step** and posts the result to the requester chat channel.
 - Reply exactly `ANNOUNCE_SKIP` during the announce step to stay silent.
 - Announce replies are normalized to `Status`/`Result`/`Notes`; `Status` comes from runtime outcome (not model text).
 - Sub-agent sessions are auto-archived after `agents.defaults.subagents.archiveAfterMinutes` (default: 60).

package/docs/concepts/session.md

@@ -7,7 +7,7 @@ title: "Session Management"
 
 # Session Management
 
-SkyKoi treats **one direct-chat session per agent** as primary. Direct chats collapse to `agent:<agentId>:<mainKey>` (default `main`), while group/channel chats get their own keys. `session.mainKey` is honored.
+SKYKOI treats **one direct-chat session per agent** as primary. Direct chats collapse to `agent:<agentId>:<mainKey>` (default `main`), while group/channel chats get their own keys. `session.mainKey` is honored.
 
 Use `session.dmScope` to control how **direct messages** are grouped:
 
@@ -30,7 +30,7 @@ Use `session.dmScope` to control how **direct messages** are grouped:
 **The fix:** Set `dmScope` to isolate sessions per user:
 
 ```json5
-// ~/.skykoi/skykoi.json
+// ~/.SKYKOI/SKYKOI.json
 {
   session: {
     // Secure DM mode: isolate DM context per channel + sender.
@@ -51,11 +51,11 @@ Notes:
 - Default is `dmScope: "main"` for continuity (all DMs share the main session). This is fine for single-user setups.
 - For multi-account inboxes on the same channel, prefer `per-account-channel-peer`.
 - If the same person contacts you on multiple channels, use `session.identityLinks` to collapse their DM sessions into one canonical identity.
-- You can verify your DM settings with `SkyKoi security audit` (see [security](/cli/security)).
+- You can verify your DM settings with `SKYKOI security audit` (see [security](/cli/security)).
 
 ## Gateway is the source of truth
 
-All session state is **owned by the gateway** (the “master” SkyKoi). UI clients (macOS app, WebChat, etc.) must query the gateway for session lists and token counts instead of reading local files.
+All session state is **owned by the gateway** (the “master” SKYKOI). UI clients (macOS app, WebChat, etc.) must query the gateway for session lists and token counts instead of reading local files.
 
 - In **remote mode**, the session store you care about lives on the remote gateway host, not your Mac.
 - Token counts shown in UIs come from the gateway’s store fields (`inputTokens`, `outputTokens`, `totalTokens`, `contextTokens`). Clients do not parse JSONL transcripts to “fix up” totals.
@@ -63,21 +63,21 @@ All session state is **owned by the gateway** (the “master” SkyKoi). UI clie
 ## Where state lives
 
 - On the **gateway host**:
-  - Store file: `~/.skykoi/agents/<agentId>/sessions/sessions.json` (per agent).
-- Transcripts: `~/.skykoi/agents/<agentId>/sessions/<SessionId>.jsonl` (Telegram topic sessions use `.../<SessionId>-topic-<threadId>.jsonl`).
+  - Store file: `~/.SKYKOI/agents/<agentId>/sessions/sessions.json` (per agent).
+- Transcripts: `~/.SKYKOI/agents/<agentId>/sessions/<SessionId>.jsonl` (Telegram topic sessions use `.../<SessionId>-topic-<threadId>.jsonl`).
 - The store is a map `sessionKey -> { sessionId, updatedAt, ... }`. Deleting entries is safe; they are recreated on demand.
 - Group entries may include `displayName`, `channel`, `subject`, `room`, and `space` to label sessions in UIs.
 - Session entries include `origin` metadata (label + routing hints) so UIs can explain where a session came from.
-- SkyKoi does **not** read legacy Pi/Tau session folders.
+- SKYKOI does **not** read legacy Pi/Tau session folders.
 
 ## Session pruning
 
-SkyKoi trims **old tool results** from the in-memory context right before LLM calls by default.
+SKYKOI trims **old tool results** from the in-memory context right before LLM calls by default.
 This does **not** rewrite JSONL history. See [/concepts/session-pruning](/concepts/session-pruning).
 
 ## Pre-compaction memory flush
 
-When a session nears auto-compaction, SkyKoi can run a **silent memory flush**
+When a session nears auto-compaction, SKYKOI can run a **silent memory flush**
 turn that reminds the model to write durable notes to disk. This only runs when
 the workspace is writable. See [Memory](/concepts/memory) and
 [Compaction](/concepts/compaction).
@@ -105,10 +105,10 @@ the workspace is writable. See [Memory](/concepts/memory) and
 - Reset policy: sessions are reused until they expire, and expiry is evaluated on the next inbound message.
 - Daily reset: defaults to **4:00 AM local time on the gateway host**. A session is stale once its last update is earlier than the most recent daily reset time.
 - Idle reset (optional): `idleMinutes` adds a sliding idle window. When both daily and idle resets are configured, **whichever expires first** forces a new session.
-- Legacy idle-only: if you set `session.idleMinutes` without any `session.reset`/`resetByType` config, SkyKoi stays in idle-only mode for backward compatibility.
+- Legacy idle-only: if you set `session.idleMinutes` without any `session.reset`/`resetByType` config, SKYKOI stays in idle-only mode for backward compatibility.
 - Per-type overrides (optional): `resetByType` lets you override the policy for `dm`, `group`, and `thread` sessions (thread = Slack/Discord threads, Telegram topics, Matrix threads when provided by the connector).
 - Per-channel overrides (optional): `resetByChannel` overrides the reset policy for a channel (applies to all session types for that channel and takes precedence over `reset`/`resetByType`).
-- Reset triggers: exact `/new` or `/reset` (plus any extras in `resetTriggers`) start a fresh session id and pass the remainder of the message through. `/new <model>` accepts a model alias, `provider/model`, or provider name (fuzzy match) to set the new session model. If `/new` or `/reset` is sent alone, SkyKoi runs a short “hello” greeting turn to confirm the reset.
+- Reset triggers: exact `/new` or `/reset` (plus any extras in `resetTriggers`) start a fresh session id and pass the remainder of the message through. `/new <model>` accepts a model alias, `provider/model`, or provider name (fuzzy match) to set the new session model. If `/new` or `/reset` is sent alone, SKYKOI runs a short “hello” greeting turn to confirm the reset.
 - Manual reset: delete specific keys from the store or remove the JSONL transcript; the next message recreates them.
 - Isolated cron jobs always mint a fresh `sessionId` per run (no idle reuse).
 
@@ -140,7 +140,7 @@ Runtime override (owner only):
 ## Configuration (optional rename example)
 
 ```json5
-// ~/.skykoi/skykoi.json
+// ~/.SKYKOI/SKYKOI.json
 {
   session: {
     scope: "per-sender", // keep group keys separate
@@ -164,7 +164,7 @@ Runtime override (owner only):
       discord: { mode: "idle", idleMinutes: 10080 },
     },
     resetTriggers: ["/new", "/reset"],
-    store: "~/.skykoi/agents/{agentId}/sessions/sessions.json",
+    store: "~/.SKYKOI/agents/{agentId}/sessions/sessions.json",
     mainKey: "main",
   },
 }
@@ -172,9 +172,9 @@ Runtime override (owner only):
 
 ## Inspecting
 
-- `SkyKoi status` — shows store path and recent sessions.
-- `SkyKoi sessions --json` — dumps every entry (filter with `--active <minutes>`).
-- `SkyKoi gateway call sessions.list --params '{}'` — fetch sessions from the running gateway (use `--url`/`--token` for remote gateway access).
+- `SKYKOI status` — shows store path and recent sessions.
+- `SKYKOI sessions --json` — dumps every entry (filter with `--active <minutes>`).
+- `SKYKOI gateway call sessions.list --params '{}'` — fetch sessions from the running gateway (use `--url`/`--token` for remote gateway access).
 - Send `/status` as a standalone message in chat to see whether the agent is reachable, how much of the session context is used, current thinking/verbose toggles, and when your WhatsApp web creds were last refreshed (helps spot relink needs).
 - Send `/context list` or `/context detail` to see what’s in the system prompt and injected workspace files (and the biggest context contributors).
 - Send `/stop` as a standalone message to abort the current run, clear queued followups for that session, and stop any sub-agent runs spawned from it (the reply includes the stopped count).

package/docs/concepts/streaming.md

@@ -9,7 +9,7 @@ title: "Streaming and Chunking"
 
 # Streaming + chunking
 
-SkyKoi has two separate “streaming” layers:
+SKYKOI has two separate “streaming” layers:
 
 - **Block streaming (channels):** emit completed **blocks** as the assistant writes. These are normal channel messages (not token deltas).
 - **Token-ish streaming (Telegram only):** update a **draft bubble** with partial text while generating; final message is sent at the end.
@@ -67,7 +67,7 @@ Block chunking is implemented by `EmbeddedBlockChunker`:
 
 ## Coalescing (merge streamed blocks)
 
-When block streaming is enabled, SkyKoi can **merge consecutive block chunks**
+When block streaming is enabled, SKYKOI can **merge consecutive block chunks**
 before sending them out. This reduces “single-line spam” while still providing
 progressive output.
 
@@ -119,7 +119,7 @@ Telegram is the only channel with draft streaming:
 - Final reply is still a normal message.
 - `/reasoning stream` writes reasoning into the draft bubble (Telegram only).
 
-When draft streaming is active, SkyKoi disables block streaming for that reply to avoid double-streaming.
+When draft streaming is active, SKYKOI disables block streaming for that reply to avoid double-streaming.
 
 ```
 Telegram (private + topics)