Update readme

README.md

@@ -46,84 +46,6 @@ Install and configure oh-my-opencode-slim: https://raw.githubusercontent.com/alv
 bunx oh-my-opencode-slim@latest install
 ```
 
-### What's New in V2
-
-V2 turns oh-my-opencode-slim into a scheduler-first multi-agent workflow system.
-The Orchestrator stays focused on planning, delegation, reconciliation, and
-verification while specialists do the work in their own lanes.
-
-- **[Background agents](#background-agents)** — the Orchestrator now dispatches
-  specialists as background tasks, tracks task/session IDs, waits for completion
-  events, and reconciles results before continuing.
-- **[Companion](#companion)** — an optional floating desktop window shows which
-  agents are currently active, including parallel background specialists.
-- **[Deepwork](#deepwork)** — a structured workflow for large, multi-file, risky,
-  or phased coding work using persistent plan files and Oracle review gates.
-- **[oh-my-opencode-slim skill](#oh-my-opencode-slim-skill)** — a bundled
-  configuration skill that helps tune models, prompts, custom agents, MCP access,
-  presets, and plugin behavior safely.
-
-#### Background Agents
-
-V2 makes background specialists the default mental model: the Orchestrator plans
-the work graph, launches the right agents, avoids overlapping write ownership,
-and waits for terminal task results before acting on them.
-
-See **[Background Orchestration](docs/v2-background-orchestration.md)** for the
-full scheduler model.
-
-#### Companion
-
-The optional Companion is a floating desktop status window for live agent
-activity. It shows the current session state and which agents are active, so
-background work is easier to follow at a glance.
-
-<div align="center">
-  <img src="img/companion.gif" alt="Companion showing active agents" width="600">
-  <p><i>Left bottom visual companion.</i></p>
-</div>
-
-During interactive install, the installer asks whether to enable Companion and
-defaults to `yes`. For automation, enable it explicitly with:
-
-```bash
-bunx oh-my-opencode-slim@latest install --companion=yes
-```
-
-See **[Companion](docs/companion.md)** for configuration, positions, sizes, and
-install details.
-
-#### Deepwork
-
-Deepwork is for heavy coding sessions: broad refactors, multi-phase features,
-risky architecture changes, or work that needs a persistent plan. It creates a
-local markdown progress file, uses Oracle review gates, and keeps implementation
-phases structured.
-
-Start it with:
-
-```text
-/deepwork <heavy coding task>
-```
-
-See **[Skills](docs/skills.md#deepwork)** for when to use it and how the workflow
-runs.
-
-#### oh-my-opencode-slim Skill
-
-The bundled `oh-my-opencode-slim` skill helps the Orchestrator configure and
-improve the plugin itself. Use it for model tuning, custom agents, prompt
-overrides, skill/MCP permissions, presets, optional agents, background
-orchestration, and recurring workflow friction.
-
-<div align="center">
-  <img src="img/oh-my-opencode-skill.png" alt="oh-my-opencode-slim skill in use" width="600">
-  <p><i>Ask the bundled skill to tune and improve your agent setup.</i></p>
-</div>
-
-See **[Skills](docs/skills.md#oh-my-opencode-slim)** for examples and safety
-rules.
-
 ### Getting Started
 
 The installer generates both OpenAI and OpenCode Go presets, with OpenAI active by default. OpenAI uses `openai/gpt-5.5 (medium)` for the workflow manager/scheduler, `openai/gpt-5.5 (high)` for the Oracle, `openai/gpt-5.5 (low)` for the Fixer, and `openai/gpt-5.4-mini` variants for other specialists. To make OpenCode Go active during install, run `bunx oh-my-opencode-slim@latest install --preset=opencode-go` or change the default preset name in `~/.config/opencode/oh-my-opencode-slim.json` after installation.
@@ -208,6 +130,86 @@ If any agent fails to respond, check your provider authentication and config fil
 
 ---
 
+### What's New in V2
+
+V2 turns oh-my-opencode-slim into a scheduler-first multi-agent workflow system.
+The Orchestrator stays focused on planning, delegation, reconciliation, and
+verification while specialists do the work in their own lanes.
+
+- **[Background agents](#background-agents)** — the Orchestrator now dispatches
+  specialists as background tasks, tracks task/session IDs, waits for completion
+  events, and reconciles results before continuing.
+- **[Companion](#companion)** — an optional floating desktop window shows which
+  agents are currently active, including parallel background specialists.
+- **[Deepwork](#deepwork)** — a structured workflow for large, multi-file, risky,
+  or phased coding work using persistent plan files and Oracle review gates.
+- **[oh-my-opencode-slim skill](#oh-my-opencode-slim-skill)** — a bundled
+  configuration skill that helps tune models, prompts, custom agents, MCP access,
+  presets, and plugin behavior safely.
+
+#### Background Agents
+
+V2 makes background specialists the default mental model: the Orchestrator plans
+the work graph, launches the right agents, avoids overlapping write ownership,
+and waits for terminal task results before acting on them.
+
+See **[Background Orchestration](docs/v2-background-orchestration.md)** for the
+full scheduler model.
+
+#### Companion
+
+The optional Companion is a floating desktop status window for live agent
+activity. It shows the current session state and which agents are active, so
+background work is easier to follow at a glance.
+
+<div align="center">
+  <img src="img/companion.gif" alt="Companion showing active agents" width="600">
+  <p><i>Left bottom visual companion.</i></p>
+</div>
+
+During interactive install, the installer asks whether to enable Companion and
+defaults to `yes`. For automation, enable it explicitly with:
+
+```bash
+bunx oh-my-opencode-slim@latest install --companion=yes
+```
+
+See **[Companion](docs/companion.md)** for configuration, positions, sizes, and
+install details.
+
+#### Deepwork
+
+Deepwork is for heavy coding sessions: broad refactors, multi-phase features,
+risky architecture changes, or work that needs a persistent plan. It creates a
+local markdown progress file, uses Oracle review gates, and keeps implementation
+phases structured.
+
+Start it with:
+
+```text
+/deepwork <heavy coding task>
+```
+
+See **[Skills](docs/skills.md#deepwork)** for when to use it and how the workflow
+runs.
+
+#### oh-my-opencode-slim Skill
+
+The bundled `oh-my-opencode-slim` skill helps the Orchestrator configure and
+improve the plugin itself. Use it for model tuning, custom agents, prompt
+overrides, skill/MCP permissions, presets, optional agents, background
+orchestration, and recurring workflow friction.
+
+<div align="center">
+  <img src="img/oh-my-opencode-skill.png" alt="oh-my-opencode-slim skill in use" width="600">
+  <p><i>Ask the bundled skill to tune and improve your agent setup.</i></p>
+</div>
+
+See **[Skills](docs/skills.md#oh-my-opencode-slim)** for examples and safety
+rules.
+
+---
+
 <a id="meet-the-pantheon"></a>
 
 ## 🏛️ Meet the Pantheon
@@ -568,7 +570,6 @@ Use this section as a map: start with installation, then jump to features, confi
 | **[Council](docs/council.md)** | Run multiple models in parallel and synthesize a single answer with `@council` |
 | **[Background Orchestration](docs/background-orchestration.md)** | Scheduler-first orchestrator model built around native background subagents |
 | **[Multiplexer Integration](docs/multiplexer-integration.md)** | Watch agents work live in Tmux or Zellij panes |
-| **[Session Management](docs/session-management.md)** | Reuse recent child-agent sessions with short aliases instead of starting over |
 | **[Preset Switching](docs/preset-switching.md)** | Switch agent model presets at runtime with `/preset` |
 | **[Custom Agents](docs/configuration.md#custom-agents)** | Define your own specialists with custom prompts, models, MCP access, and Orchestrator delegation rules |
 | **[Codemap](docs/codemap.md)** | Generate hierarchical codemaps to understand large codebases faster |

docs/session-management.md

@@ -1,187 +0,0 @@
-# Session Management
-
-Background job management lets the orchestrator track native background tasks,
-wait for hook-driven completion, and reuse completed/reconciled child sessions
-when follow-up work matches the same specialist context.
-
-For implementation/debugging notes from hardening cancellation and pane cleanup,
-see [Background Job Board Lessons](background-job-board-lessons.md).
-
-It is enabled by default. You do not need to add anything to your config unless
-you want to change how many sessions are remembered.
-
----
-
-## Why It Exists
-
-Delegation works best when specialists can continue a thread they already
-understand:
-
-- Explorer can continue investigating the same part of the codebase.
-- Oracle can keep reviewing the same architecture/debugging thread.
-- Fixer can continue a scoped implementation or test update.
-- Librarian can continue the same documentation/API research.
-
-Without session management, follow-up delegations usually create fresh child
-sessions. That works, but the specialist may need repeated context. With session
-management, the orchestrator can reuse recent child sessions when it makes sense.
-
----
-
-## How It Feels in Practice
-
-When a child task runs, the plugin tracks it under a short alias such as:
-
-```text
-exp-1
-ora-1
-fix-2
-```
-
-The orchestrator sees a compact reminder in its system context, for example:
-
-```text
-### Background Job Board
-SENTINEL: background-job-board-v2
-
-#### Active / Unreconciled
-- exp-1 / child-1 / explorer / running
-  Objective: Search routing files
-
-#### Reusable Sessions
-- ora-1 / child-2 / oracle / completed, reconciled
-  Objective: Review auth architecture
-```
-
-When a child session reads files through OpenCode's `read` tool, the reminder can
-include a compact list of files that session has already inspected. This helps the
-orchestrator choose the right session to resume for related follow-up work.
-
-To keep the prompt small, read context only shows files where at least 10 lines
-were read, includes line counts, and caps each remembered session to the most
-recent 8 files by default. Both thresholds are configurable.
-
-On a related follow-up, the orchestrator can reuse a completed/reconciled session
-instead of launching a fresh one. Running jobs must wait for hook-driven completion;
-terminal jobs must be reconciled before dependent work or a final response.
-
----
-
-## Scope and Safety
-
-Session management is intentionally narrow:
-
-- It only applies to orchestrator-managed `task` delegations.
-- It is scoped to the current parent orchestrator session.
-- It is in-memory only and disappears when OpenCode/plugin state restarts.
-- It does not change manual `@agent` calls.
-- It keeps only a small number of recent sessions per specialist type.
-- Missing or deleted child sessions are cleaned up automatically.
-- Read context is best-effort and tracks normal OpenCode `read` tool usage, not
-  arbitrary filesystem access through shell commands or external MCP tools.
-
-This keeps the feature useful for continuity without turning child sessions into
-long-lived global state.
-
----
-
-## Default Behavior
-
-By default, the plugin keeps **2 reusable completed child sessions per specialist
-type** while active/unreconciled jobs remain visible until resolved.
-
-That means the generated starter config can stay clean:
-
-```jsonc
-{
-  "preset": "openai",
-  "presets": {
-    "openai": {
-      "orchestrator": { "model": "openai/gpt-5.5", "variant": "medium" },
-      "explorer": { "model": "openai/gpt-5.4-mini" },
-      "fixer": { "model": "openai/gpt-5.5", "variant": "low" }
-    }
-  }
-}
-```
-
-Background job management still works because the runtime falls back to the built-in
-default.
-
----
-
-## Configuration
-
-Only add `backgroundJobs` if you want to change the default limits:
-
-```jsonc
-{
-  "backgroundJobs": {
-    "maxSessionsPerAgent": 2,
-    "readContextMinLines": 10,
-    "readContextMaxFiles": 8
-  }
-}
-```
-
-### `backgroundJobs.maxSessionsPerAgent`
-
-| Type | Default | Range | Meaning |
-|------|---------|-------|---------|
-| integer | `2` | `1`–`10` | Number of completed/reconciled reusable child sessions retained per specialist type in the current parent session |
-
-### `backgroundJobs.readContextMinLines`
-
-| Type | Default | Range | Meaning |
-|------|---------|-------|---------|
-| integer | `10` | `0`–`1000` | Minimum number of lines read from a file before it appears in reusable job context |
-
-Set this lower if you want short config files to appear. Set it higher to keep
-the prompt focused on substantial file reads.
-
-### `backgroundJobs.readContextMaxFiles`
-
-| Type | Default | Range | Meaning |
-|------|---------|-------|---------|
-| integer | `8` | `0`–`50` | Maximum number of recent read-context files shown per remembered child session |
-
-Set this to `0` to keep session aliases but hide read-context file lists.
-
-Use a higher value if you often run several parallel threads per specialist. Use
-a lower value if you want fewer aliases in the orchestrator context.
-
----
-
-## When To Tune It
-
-Most users should leave the default alone.
-
-Consider changing it when:
-
-- You frequently run multiple independent Explorer/Oracle/Fixer threads in one
-  long orchestrator session.
-- You want the orchestrator prompt to stay smaller and prefer only one remembered
-  thread per specialist.
-- You are debugging session reuse behavior and want a predictable small window.
-
-Example with a smaller memory window:
-
-```jsonc
-{
-  "backgroundJobs": {
-    "maxSessionsPerAgent": 1,
-    "readContextMaxFiles": 4
-  }
-}
-```
-
-Example with a larger memory window:
-
-```jsonc
-{
-  "backgroundJobs": {
-    "maxSessionsPerAgent": 4,
-    "readContextMinLines": 5
-  }
-}
-```