From 9868bff87369fd7abcbe75275eaf44d6f8f31b6b Mon Sep 17 00:00:00 2001 From: Arul Sharma <31745423+arul28@users.noreply.github.com> Date: Tue, 16 Jun 2026 22:21:41 -0400 Subject: [PATCH 1/3] docs: overhaul Mintlify site + changelog for v1.2.7 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Rebuild the public docs around ADE's real feature set (grounded in docs/features/**): correct lane model (primary lane + worktree/child/ import/attach), add Review, iOS Simulator, Automations, GitHub, and troubleshooting pages, consolidate Integrations (GitHub + Linear) and AI Connections, swap the stale green logo for the real purple brand, and wire the full /media library into the pages. Adds the v1.2.7 changelog. Docs-only — no app code touched. Co-Authored-By: Claude Opus 4.8 --- .mintignore | 6 +- ai-tools/claude-code.mdx | 70 +++++++---- ai-tools/cursor.mdx | 124 +++++++------------- ai-tools/windsurf.mdx | 162 ++++++++------------------ architecture.mdx | 82 +++++++------ changelog/v1.2.7.mdx | 24 ++++ chat/capabilities.mdx | 88 +++++++++++--- chat/context.mdx | 61 +++++----- chat/grid.mdx | 52 +++++++++ chat/overview.mdx | 99 ++++++++++------ computer-use/config.mdx | 52 ++++++--- computer-use/overview.mdx | 74 +++++++----- computer-use/proofs.mdx | 79 +++++++------ computer-use/setup.mdx | 127 ++++++++++++++------ configuration/ai-providers.mdx | 95 +++++++++++---- configuration/overview.mdx | 59 ++++++---- configuration/permissions.mdx | 80 +++++++++---- configuration/settings.mdx | 75 +++++++----- cto/linear.mdx | 59 ---------- cto/overview.mdx | 72 +++++++++--- cto/setup.mdx | 81 ++++++++++--- cto/workers.mdx | 80 ++++++++++--- docs.json | 167 +++++++++++++-------------- favicon.svg | 5 - getting-started/connect-provider.mdx | 80 ++++++++++--- getting-started/first-agent.mdx | 51 +++++--- getting-started/first-lane.mdx | 34 ++++-- getting-started/install.mdx | 63 ++++++---- getting-started/open-project.mdx | 18 ++- getting-started/project-setup.mdx | 40 ------- guides/cto-linear-workflow.mdx | 153 ------------------------ guides/multi-agent-setup.mdx | 63 +++++++--- guides/stacked-prs.mdx | 64 +++++----- index.mdx | 44 ------- integrations/github.mdx | 62 ++++++++++ integrations/linear.mdx | 114 ++++++++++++++++++ introduction.mdx | 37 ------ key-concepts.mdx | 4 +- lanes/creating.mdx | 139 +++++++++++++++++++--- lanes/environment.mdx | 114 ++++++++++++------ lanes/overview.mdx | 123 ++++++++++++++------ lanes/packs.mdx | 40 ------- lanes/stacks.mdx | 72 ++++++++---- logo/dark.svg | 10 -- logo/light.svg | 10 -- quickstart.mdx | 8 +- reference/cli.mdx | 144 +++++++++++++++++++++++ reference/troubleshooting.mdx | 94 +++++++++++++++ tools/ade-code.mdx | 71 ++++++++++++ tools/automations.mdx | 117 +++++++++++++++++++ tools/browser.mdx | 58 ++++++++++ tools/conflicts.mdx | 105 +++++++++++------ tools/files-editor.mdx | 87 +++++++++++--- tools/history.mdx | 85 +++++++++----- tools/ios-companion.mdx | 85 ++++++++++---- tools/ios-simulator.mdx | 114 ++++++++++++++++++ tools/project-home.mdx | 89 ++++++++------ tools/pull-requests.mdx | 124 +++++++++++++++----- tools/remote-machines.mdx | 74 ++++++++++++ tools/review.mdx | 94 +++++++++++++++ tools/terminals.mdx | 79 +++++++++---- tools/workspace-graph.mdx | 75 +++++++++--- welcome.mdx | 129 ++++++++++++++++----- 63 files changed, 3293 insertions(+), 1547 deletions(-) create mode 100644 changelog/v1.2.7.mdx create mode 100644 chat/grid.mdx delete mode 100644 cto/linear.mdx delete mode 100644 favicon.svg delete mode 100644 getting-started/project-setup.mdx delete mode 100644 guides/cto-linear-workflow.mdx delete mode 100644 index.mdx create mode 100644 integrations/github.mdx create mode 100644 integrations/linear.mdx delete mode 100644 introduction.mdx delete mode 100644 lanes/packs.mdx delete mode 100644 logo/dark.svg delete mode 100644 logo/light.svg create mode 100644 reference/cli.mdx create mode 100644 reference/troubleshooting.mdx create mode 100644 tools/ade-code.mdx create mode 100644 tools/automations.mdx create mode 100644 tools/browser.mdx create mode 100644 tools/ios-simulator.mdx create mode 100644 tools/remote-machines.mdx create mode 100644 tools/review.mdx diff --git a/.mintignore b/.mintignore index b247b2306..bb746115e 100644 --- a/.mintignore +++ b/.mintignore @@ -15,7 +15,5 @@ docs/ packages/ .factory/ -# Template files we're replacing -essentials/ -ai-tools/ -api-reference/ +# Source-of-truth media library lives elsewhere; the docs reference the +# committed copies under /media, /logo, and /favicon.png directly. diff --git a/ai-tools/claude-code.mdx b/ai-tools/claude-code.mdx index c764bcd0d..ccab88572 100644 --- a/ai-tools/claude-code.mdx +++ b/ai-tools/claude-code.mdx @@ -1,42 +1,70 @@ --- title: "Claude Code" -description: "Use Claude Code as an ADE chat and worker backend." -icon: "terminal" +description: "Claude Code runs inside ADE through the bundled Claude Agent SDK — scoped to a lane, with permission modes and transcripts handled for you." +icon: "robot" --- -Claude Code can run inside ADE as a coding agent. ADE starts sessions in the selected lane, passes the right project context, and records the transcript and tool activity. + +
+ Claude +
+ + +Claude Code runs inside ADE through the **bundled Claude Agent SDK** — there's no separate `claude` CLI to install. Pick a Claude model in any chat and ADE starts the session in the selected lane's worktree, applies your permission mode, streams tool calls live, and records the transcript to History. ## Setup - - Make sure the `claude` CLI works in a normal terminal. - - - Refresh provider detection and verify Claude Code. + + Sign in with a Claude subscription or paste an Anthropic API key. A green status means Claude is ready. - - Choose Claude from the model/provider selector. + + Open the model picker in the chat header and choose a Claude model. That session now runs on Claude. -## What ADE adds +## What ADE handles for you -- Lane-scoped working directories. -- Session transcripts in History. -- File and Git attribution. -- Provider permission controls. -- Links to PRs, Linear issues, and proof artifacts when used. + + + Every session runs in the active lane's worktree, so Claude edits and runs commands against that task's isolated checkout. + + + Tool calls, thinking, and diffs stream into chat and are saved to History. + + + A native permission mode decides what Claude can do without asking. + + + Changes attribute to Files and Git, and link out to PRs, Linear issues, and proof when used. + + ## Permission modes -Claude Code uses Claude's native permission model. Pick a stricter mode when exploring an unfamiliar repo, and a more permissive mode only when you trust the lane and task. +Claude Code uses Claude's native permission model. Pick a stricter mode when exploring an unfamiliar repo, and a more permissive one only when you trust the lane and task. + + + + | Mode | Behavior | + |------|----------| + | `default` | Claude's built-in permission flow — asks before risky operations. | + | `plan` | Read-only. Writing and executing are blocked until you approve a plan. | + | `acceptEdits` | File writes allowed; shell commands still require approval. | + | `bypassPermissions` | Proceeds without asking. | + + The mode can change mid-session from the permission picker. See [Permissions](/configuration/permissions) for how modes map across providers. + + + Claude is also one of the providers you can launch as a CLI session in the Work tab, and as a CTO worker backend. Wherever it runs, it's the same bundled Claude Agent SDK against the same lane worktree — desktop, [`ade code`](/tools/ade-code), and your phone all see the session. + + - - Run Claude in a lane. - - Configure provider defaults. + Connect each agent and set defaults. + + + Run Claude in a lane and watch tool calls stream. diff --git a/ai-tools/cursor.mdx b/ai-tools/cursor.mdx index 0f50c577e..9e56178e3 100644 --- a/ai-tools/cursor.mdx +++ b/ai-tools/cursor.mdx @@ -1,98 +1,54 @@ --- -title: "Cursor Integration" -description: "Use Cursor as an agent provider in ADE — launch sessions, route models, and track work through the Cursor SDK." +title: "Cursor" +description: "Run Cursor as an agent provider in ADE through the Cursor SDK — one of ADE's five agents, scoped to a lane." icon: "arrow-pointer" --- -## Overview +[Cursor](https://cursor.com) runs inside ADE as one of its five agent providers, alongside Claude Code, Codex, Factory Droid, and OpenCode. ADE drives Cursor's agent through the official **Cursor SDK** — ADE owns the lane scope, permissions, and system prompt; the SDK owns the model and tool execution. -ADE integrates with [Cursor](https://cursor.com) in two ways: +## Connect Cursor -1. **Launch Cursor from ADE** — open your project or a lane's worktree in Cursor from the Run tab -2. **Cursor as an agent provider** — use Cursor's AI agent as a chat provider inside ADE via the Cursor SDK +Cursor chat authenticates with an API key. Add a Cursor API key in **Settings → AI**, or set `CURSOR_API_KEY` in the environment ADE launches from — ADE accepts either. -The SDK integration means Cursor's agent capabilities are available directly in ADE's chat interface, alongside Claude, Codex, and other providers. You can switch between providers per-session. - ---- - -## Requirements - -| Requirement | Details | -|------------|---------| -| **Cursor installed** | Cursor desktop app must be installed to launch Cursor from ADE | -| **Cursor SDK auth** | Cursor chat requires `CURSOR_API_KEY` or a Cursor API key saved in ADE Settings | -| **Authentication** | ADE uses API-key authentication for Cursor chat. Cursor desktop sign-in is only needed for launching the editor. | - -ADE checks Cursor API-key authentication during onboarding and in **Settings → AI**. When `CURSOR_API_KEY` is present, ADE recognizes it as a valid authentication signal. You can also save the key in ADE's encrypted provider settings. - ---- - -## Launching Cursor from ADE - -Open the **Run** tab and click the **Cursor** launcher. ADE opens the current project (or the selected lane's worktree) in Cursor as a separate application window. - -The session is linked back to the active lane for tracking. File changes made in Cursor appear in the lane's diff view as soon as they are saved. - ---- - -## Cursor as an agent provider - -When Cursor API-key auth is configured, ADE can use Cursor as a chat provider through the **Cursor SDK**. - -### How it works - -1. ADE starts an isolated SDK worker for the active lane -2. The worker creates or resumes a Cursor SDK agent with the selected model -3. Chat messages are routed through SDK runs, and Cursor has access to the `ade` CLI for ADE workflows -4. Model discovery queries Cursor SDK metadata for available models and capabilities - -### Selecting Cursor in chat - -In any Agent Chat session, use the **model selector** in the chat header to choose a Cursor-provided model. Models discovered from Cursor appear alongside Claude, GPT, and other configured providers. - -### Model discovery - -ADE queries Cursor for its available models at startup and caches the result. The discovered models appear in: -- The chat model selector -- The worker run model configuration -- The unified model selector throughout the app - -### Session behavior - -| Behavior | Details | -|----------|---------| -| **Session lifecycle** | Managed by the Cursor SDK pool; sessions are reused when possible | -| **Event mapping** | SDK events are mapped to ADE's chat event model for consistent UI | -| **ADE CLI access** | The `ade` CLI is on `PATH` so Cursor agents can call ADE lane, git, PR, and action tools | -| **Interrupts** | Supported via SDK run cancel | - ---- - -## Connection status - -ADE shows Cursor's connection status in **Settings → AI**: - -| Status | Meaning | -|--------|---------| -| **Connected** (green) | Cursor API key found and ready | -| **Not authenticated** (amber) | Cursor API key is missing or invalid | -| **Not found** (gray) | Cursor desktop is not detected for editor launch | - ---- - -## Troubleshooting +Once connected, ADE discovers Cursor's available models and they appear in the model picker alongside every other provider. Pick one in any chat header to route that session through Cursor. - - ADE checks standard installation paths for the Cursor desktop app when launching the editor. If Cursor is installed in a non-standard location, open the project directly from Cursor or add the app to the standard Applications location. + + When a Cursor key is configured, ADE runs the official `@cursor/sdk` in a Node worker pool. The worker creates or resumes a Cursor SDK agent with the selected model in the active lane's worktree, and routes chat turns through SDK runs. Sessions are pooled and reused, SDK events map to ADE's chat event model, and interrupts cancel the run. Because the `ade` CLI is on `PATH`, Cursor agents can call ADE's lane, git, PR, and action tools. + + + ADE shows Cursor's status in **Settings → AI**: + + | Status | Meaning | + |--------|---------| + | **Connected** (green) | Cursor API key found and ready. | + | **Not authenticated** (amber) | Cursor API key is missing or invalid. | - - Add a Cursor API key in **Settings → AI Providers** or set `CURSOR_API_KEY` in the environment used to launch ADE. + + You can also launch the `cursor-agent` CLI as a tracked terminal session in the Work tab. ADE probes `cursor-agent` for CLI-only models and merges them into the picker, so the chat-vs-CLI distinction stays clear. This needs the `cursor-agent` binary on your `PATH`. - - Model discovery runs at ADE startup. If you installed Cursor after starting ADE, restart ADE or go to **Settings → AI** and click **Refresh** to re-run model discovery. + + Kick off Cursor's hosted cloud agents from ADE and follow them in a lane: + + ```bash + ade cursor cloud agents list --text + ade cursor cloud agents create --repo https://github.com/owner/repo --prompt "fix flaky test" --auto-pr + ``` + + The chat panel can open a cloud agent as an ADE chat (replies still run in the cloud) or jump to it on cursor.com. - - If SDK sessions fail, check that the Cursor API key is configured and that the selected model is available. Check ADE's developer logs (**Settings → Developer → Log file**) for detailed SDK worker errors. + + - **Authentication failed** — add a Cursor API key in **Settings → AI**, or set `CURSOR_API_KEY` in ADE's launch environment. + - **Models not appearing** — discovery serves last-known-good rows and revalidates in the background. If Cursor was just connected, restart ADE or refresh in **Settings → AI**. + - **Session errors** — confirm the key is valid and the selected model is available; check developer logs at **Settings → Developer → Log file**. + + + + Connect each agent and set defaults. + + + Run Cursor in a lane and compare it with other providers. + + diff --git a/ai-tools/windsurf.mdx b/ai-tools/windsurf.mdx index 55c98bddb..533328f71 100644 --- a/ai-tools/windsurf.mdx +++ b/ai-tools/windsurf.mdx @@ -1,144 +1,78 @@ --- -title: "Windsurf & OpenCode" -description: "Launch Windsurf from ADE for editor sessions, or run OpenCode as a local AI backend directly inside ADE." +title: "OpenCode & Windsurf" +description: "Run OpenCode as a managed agent provider inside ADE — and keep using Windsurf as your editor on the same worktrees." icon: "water" --- -## OpenCode Integration +This page covers two things: **OpenCode**, one of ADE's five agent providers, and how to keep using **Windsurf** as your editor next to ADE. -[OpenCode](https://opencode.ai) runs as a local server process and exposes an OpenAI-compatible endpoint. ADE manages the OpenCode process lifecycle — starting, stopping, and monitoring it — and routes chat and worker run requests through it like any other provider. +## OpenCode as a provider -### How it works - -ADE's OpenCode integration has three layers: -- **Binary manager** — downloads and verifies the OpenCode binary, checks for updates -- **Server manager** — starts and monitors the OpenCode process, detects crashes, and restarts automatically -- **Runtime** — handles session lifecycle, model discovery, and event routing +[OpenCode](https://opencode.ai) is one of ADE's five agents, alongside Claude Code, Codex, Cursor, and Factory Droid. ADE runs it as a local server and routes chat and worker turns through it like any other provider. OpenCode gives you the broadest model reach — back it with a provider API key, OpenRouter, or a local model (Ollama, LM Studio, vLLM). ### Setup - - Navigate to **Settings → AI Providers → OpenCode**. - - - Toggle OpenCode on. ADE downloads the binary if it is not already present and starts the local server. + + Turn OpenCode on. ADE downloads the binary if needed and starts the local server. - OpenCode supports three backend modes: - | Mode | Config | |------|--------| - | **API key** | Provide an Anthropic or OpenAI key — OpenCode calls the provider directly | - | **OpenRouter** | Provide an OpenRouter key for access to any model | - | **Local** | No key — use Ollama or another local OpenAI-compatible endpoint | - - - OpenCode models appear in the model selector alongside Claude, Codex, and Cursor. Choose any discovered model to route that session through OpenCode. - - - - -OpenCode and Windsurf use different approaches: OpenCode integrates as a managed backend inside ADE, while Windsurf is an external editor you launch from ADE. You can use both independently. - - ---- - -## Windsurf Editor Integration - -ADE can launch [Windsurf](https://codeium.com/windsurf) (by Codeium) as an external editor for any lane. When you open Windsurf through ADE, the session is tracked in the lane's history, the correct worktree directory is opened, and any file changes you make in Windsurf appear in the lane's diff view as soon as they are saved. - -This is a one-way integration — ADE launches Windsurf and tracks the session, but does not route AI agent requests through Windsurf or manage Windsurf's internal AI features. You use Windsurf's built-in AI capabilities directly within the Windsurf editor. - ---- - -## Requirements - -| Requirement | Details | -|------------|---------| -| **Windsurf installed** | The Windsurf desktop app must be installed on your machine | -| **CLI available** | The `windsurf` command must be available in your PATH. Windsurf typically adds this during installation. Verify with `which windsurf` in a terminal. | - ---- - -## Launching Windsurf from ADE - - - - Navigate to the lane you want to work in. Windsurf will open the lane's worktree directory — not the primary checkout. - - - Click the **Run** tab in the lane's toolbar, or open **Project Home** from the sidebar. - - - If Windsurf is detected or configured, a **Windsurf** button appears alongside other external tool launchers (Cursor, VS Code, Claude Code, etc.). Click it. + | **API key** | An Anthropic, OpenAI, Google, or other supported key — OpenCode calls the provider directly. | + | **OpenRouter** | An OpenRouter key for broad model access. | + | **Local** | No key — point at Ollama, LM Studio, or another local endpoint. | - - ADE launches Windsurf pointed at the lane's worktree path. The session is registered in ADE's history system. + + OpenCode models appear in the model picker alongside the other agents. Choose one to route that session through OpenCode. ---- - -## What ADE Tracks - -When you launch Windsurf through ADE: - -- **Session registration** — the launch is recorded as a managed session in the lane, visible in the History view -- **File change detection** — ADE watches the lane's worktree for filesystem changes. Edits made in Windsurf appear in the lane's diff view in real time. -- **Environment inheritance** — Windsurf inherits the lane's environment variable overlays and port assignments + + + ADE owns the full lifecycle: + - **Binary manager** — downloads and verifies the OpenCode binary and checks for updates. + - **Server manager** — starts and monitors the local server process, detects crashes, and restarts it. + - **Runtime** — handles session lifecycle, model discovery, and event routing into ADE's chat model. + + + OpenCode uses its own permission modes: -ADE does not monitor Windsurf's internal AI usage, chat history, or token consumption. Those are managed entirely within Windsurf. + | Mode | Behavior | + |------|----------| + | `plan` | Read-only. | + | `edit` | Read and write allowed; bash commands are gated. | + | `full-auto` | Proceeds without asking. | ---- + See [Permissions](/configuration/permissions) for how modes map across providers. + + -## Configuring a Custom Launcher +## Using Windsurf alongside ADE -If Windsurf does not appear in the Run tab by default, you can add it as a custom CLI launcher: +ADE doesn't run [Windsurf](https://windsurf.com) as an agent provider — ADE's five agents are Claude Code, Codex, Cursor, Factory Droid, and OpenCode. But you can still use Windsurf as your editor on the same code, because a lane is just a git worktree on disk. - - Navigate to **Settings > Project Home > Custom CLI Launchers**. + + Open the lane in ADE; its worktree path is shown in the lane detail header (under `.ade/worktrees/`). - - Click **Add Launcher** and configure: - - **Name:** `Windsurf` - - **Command:** `windsurf` (or the full path to the Windsurf executable if it is not in PATH) - - **Arguments:** `{worktreePath}` — ADE substitutes the lane's worktree directory at launch time + + Open the worktree directory in Windsurf the way you normally open any project — from Windsurf, or with `windsurf ` if its CLI is on your `PATH`. - - Save the launcher. It now appears in the Run tab for all lanes. + + ADE watches the worktree, so edits you save in Windsurf show up in the lane's diff, Files view, and Git status in real time. Use Windsurf's own AI features in the editor; ADE doesn't route requests through Windsurf. ---- - -## Windsurf vs. Cursor vs. Claude Code - -ADE supports multiple external AI tools. Here is how Windsurf compares: - -| Capability | Windsurf | Cursor | Claude Code | -|-----------|----------|--------|-------------| -| **Launch from ADE** | Yes | Yes | Yes | -| **Session tracking** | Yes | Yes | Yes | -| **Agent provider in ADE chat** | No | Yes (via SDK) | Yes (via CLI) | -| **ADE CLI access** | No | Yes | Yes | -| **Model routing through ADE** | No | Yes | Yes | - -Windsurf is a good choice when you want to use Codeium's AI features directly in the editor while keeping the session tracked in ADE. For deeper integration where ADE manages the AI agent lifecycle, use Cursor (via SDK) or Claude Code (via CLI). - ---- - -## Troubleshooting + +Edit inside the **lane's worktree** (`.ade/worktrees//…`), not the primary checkout — otherwise your changes won't land in that lane's diff. + - - - ADE may not detect Windsurf automatically. Add it as a custom CLI launcher in **Settings > Project Home > Custom CLI Launchers** using the `windsurf` command. - - - Verify you selected the correct lane before launching. If Windsurf opens the primary checkout instead of the lane worktree, check that the lane was created as a Worktree Lane (not the primary lane). - - - ADE watches the lane's worktree for filesystem changes. If changes are not appearing, check that you are editing files inside the lane's worktree path (visible in the lane detail header), not in a different directory. - - + + + Connect each agent and set defaults. + + + Run OpenCode in a lane and compare it with other providers. + + diff --git a/architecture.mdx b/architecture.mdx index c98fbc3f5..ec36a8711 100644 --- a/architecture.mdx +++ b/architecture.mdx @@ -1,69 +1,77 @@ --- title: "Architecture" -description: "How ADE desktop, the local runtime, project state, CLI, iOS companion, and optional remote runtimes fit together." +description: "How the ADE brain, project state, the desktop app, ade code, iOS, and optional remote runtimes over SSH fit together." icon: "diagram-project" --- -ADE is local-first. The desktop app is the visible control plane, and a machine-local ADE runtime owns the durable project state and action surface. +ADE is local-first. The center is the **brain** — the always-on, machine-owned ADE process for a channel. The brain owns the project catalog, the durable project state, the sync websocket, and the authority to run agents. Everything you see is a **client** of that brain: the desktop app, `ade code`, the iOS app, and any SSH-attached desktop window. ```mermaid flowchart TB Desktop["ADE desktop app"] - Work["Work tab
chats and terminals"] - CLI["ade CLI and ade code"] - Runtime["Local ADE runtime
~/.ade/sock/ade.sock"] + CLI["ade CLI + ade code"] + IOS["iOS app"] + Brain["ADE brain
~/.ade/sock/ade.sock"] Project["Project .ade/
database, worktrees, artifacts"] - IOS["iOS companion"] - Remote["Optional remote ADE runtime"] - - Desktop --> Runtime - Work --> Runtime - CLI --> Runtime - Runtime --> Project - IOS <-->|"paired sync and commands"| Runtime - Desktop <-->|"SSH/RPC when configured"| Remote + Remote["Remote ADE brain
(another machine)"] + + Desktop --> Brain + CLI --> Brain + IOS <-->|"paired sync + commands"| Brain + Brain --> Project + Desktop <-->|"SSH · ade rpc --stdio"| Remote ``` -## The desktop app +## The brain -Desktop owns the window, navigation, renderer UI, and Mac-only integrations. It displays lanes, Work sessions, files, PRs, History, Settings, CTO, and mobile pairing state. +The brain is the source of truth on a machine. It owns lanes, agent chats, terminals, Git operations, PR actions, provider sessions, proof artifacts, the project catalog, and the sync service. It runs every agent — **Claude Code, Codex, Cursor, Factory Droid, and OpenCode** — against the same projects. Because desktop and CLI clients call the same brain, a chat you start in the app and one you start with [`ade code`](/tools/ade-code) operate on the same project state. -## The ADE runtime +The brain installs as a per-user login service (launchd on macOS), so it stays running even when no window is open. -The runtime is the local service that reads and writes project state. It handles lanes, chats, terminals, Git operations, PR actions, provider sessions, proof artifacts, and mobile sync. Desktop and CLI clients call the same runtime surface, so a chat in the app and `ade code` in a terminal operate on the same project. +## Clients + + + + The Electron control plane — windows, navigation, the renderer UI, and Mac-only integrations. Each window attaches to a local brain, or binds to a remote one over SSH. + + + The terminal-native client. Attaches to the same brain — the same lanes, chats, and PRs in a fast TUI. + + + A SwiftUI controller that pairs with a machine over WebSocket. It mirrors state and sends commands; it never runs agents itself. + + + The typed control plane for any shell — used by humans and by the agents running inside ADE. + + ## Project state -ADE writes local state under the repository's `.ade/` directory: +ADE writes local state under each repository's `.ade/` directory and leaves your source tree under Git's control: ```text .ade/ - ade.db - worktrees/ - artifacts/ - cache/ - secrets/ + ade.db # the project database + worktrees/ # one git worktree per lane + artifacts/ # proof and capture artifacts + secrets/ # encrypted project credentials ``` -The source repository remains a normal Git checkout. ADE uses Git branches, worktrees, commits, and PRs rather than replacing them. - -## CLI and terminal clients - -The `ade` CLI gives agents and humans a typed way to reach ADE actions from a shell. `ade code` is the terminal-native Work client for people who prefer to stay in a terminal while sharing the same runtime and project state as desktop. - -## iOS companion +A **lane** is a git worktree under `worktrees/`. ADE uses real Git branches, worktrees, commits, and PRs rather than replacing them, so a lane is a normal checkout on disk you can also open in any editor. -The iOS app pairs with the local runtime. It mirrors useful state and can send commands back to the Mac. Agents still run on the Mac or configured remote runtime. +## Remote runtimes over SSH -## Optional remote runtimes +A desktop window can bind to a brain on **another machine** over SSH. ADE runs `ade rpc --stdio` on the remote and tunnels the same JSON-RPC back, so lanes, chats, diffs, and PRs behave exactly as they do locally — but the agents, builds, and tests run on the remote, against its filesystem and its own GitHub, Linear, and provider credentials. The desktop stays local and stays the control plane. -ADE can connect to another machine over SSH and talk to an ADE runtime there. Use this when the repository or dev stack lives on a remote box, but you still want the desktop control plane locally. + +iOS does not SSH into machines. The phone pairs with a brain and connects to its sync websocket over the LAN or a Tailscale tailnet — install Tailscale on both when they aren't on the same network. + - Learn the product vocabulary. + The product vocabulary — brain, lane, stack, CTO — in two minutes. - - Pair your phone and understand what mobile can do. + + The typed control plane behind everything ADE does. diff --git a/changelog/v1.2.7.mdx b/changelog/v1.2.7.mdx new file mode 100644 index 000000000..8233d83a6 --- /dev/null +++ b/changelog/v1.2.7.mdx @@ -0,0 +1,24 @@ +--- +title: "v1.2.7" +description: "Release notes for ADE v1.2.7 - June 16, 2026" +--- + +v1.2.7 sharpens ADE Code in the terminal — no more drawer flicker, plus multi-question approvals — auto-names your lanes with AI on mobile, speeds up chat scrolling on iOS, and retires the macOS VM and mobile push surfaces. + +--- + +## Desktop + +- **ADE Code, without the flicker.** Selecting a lane in `ade code` no longer reflows the whole drawer — lane cards are single-line, the expanded and compact chat lists render through one shared row, and the TUI reserves viewport rows to avoid Ink full-screen redraws. Provider glyphs and colors now match the model picker one-to-one, grid navigation escapes cleanly with Tab, and terminal previews dedupe their frames. +- **Multi-question approvals in the terminal.** When an agent asks several questions at once, `ade code` shows a proper multi-question selector — arrow keys to choose an option and move between questions, number keys to pick and submit — replacing the old single-question quick-select. +- **Leaner stored transcripts.** Bulky chat transcript payloads are compacted in storage while keeping durable replay and live output intact, fixing cases where a transcript could return missing content. +- **macOS VM removed.** ADE's macOS VM runtime, its UI, and the related `ade vm` CLI commands have been removed. + +--- + +## iOS + +- **AI-named lanes.** Auto-creating a lane on mobile now names it from your prompt using the host's small AI model — for both Chat and CLI — with a deterministic fallback if the model is offline or times out. Lane creation is never blocked by naming. +- **New-chat composer parity.** The new-chat composer now matches an in-session thread: a single permission dropdown when space is tight, the model pill, and the fast-mode toggle, all from one shared control row, with fast mode honored on create. +- **Smoother chat scrolling.** Scrolling through Work chats is faster — assistant previews are cached for visible rows and deferred until after the stream merges, with per-session terminal fingerprints. +- **Mobile push removed.** Push notifications have been removed; the app relies on its live sync connection, and PR actions from widgets now navigate in-app. diff --git a/chat/capabilities.mdx b/chat/capabilities.mdx index 20cda82f7..5dbc93d18 100644 --- a/chat/capabilities.mdx +++ b/chat/capabilities.mdx @@ -1,40 +1,85 @@ --- title: "Chat capabilities" -description: "What ADE chat agents can do inside a lane or PR context." +description: "The tools a chat agent can use inside a lane — read and edit files, run commands, drive Git, open PRs, and capture proof." icon: "toolbox" --- -The exact tools depend on provider, permissions, and project setup, but most ADE chat sessions can do the following. +A chat agent works like a teammate who has the lane checked out. ADE gives every agent a set of tools scoped to its role, so a regular lane chat can do real work — read and edit files, run commands, create lanes and PRs, pull in Linear context, and capture proof — without reaching the elevated control-plane tools reserved for the CTO. + +## Universal tools + +Every agent gets these, in every session. - - Search the repo, inspect files, apply edits, and explain changes. + + Range-aware file reads, plus `grep` and `glob` search across the worktree. Always allowed, even in read-only plan mode. + + + Apply a single-file edit or create and replace a file. Each write produces a file-change event and a diff. Blocked in plan mode. - Use the lane terminal for tests, builds, package managers, scripts, and local tools. + Run shell commands for tests, builds, package managers, and scripts. Emits command events with output and exit code. Blocked in plan mode and gated by your approval in edit mode. - - Check status, inspect diffs, stage files, commit, push, and manage branches. + + Fetch a URL or run a web search when the task needs outside information. Always allowed. - - Create PRs, update descriptions, read CI failures, respond to comments, and help resolve review feedback. + + Maintain a session todo list so multi-step work stays visible in the transcript. - - Read linked issues, update issue context, and attach useful outcomes when Linear is connected. + + Pause cleanly and ask you for a choice or clarification instead of guessing. The composer locks until you answer. + + + +## Workflow tools + +Chat agents also get the tools that turn a conversation into shipped work. + + + + Branch a fresh git worktree for a new piece of work, optionally stacked on the current lane. + + + Create a pull request from the lane's changes, with a generated title and body. + + + When a chat is launched to fix a PR, it can refresh checks, re-run failed CI, reply to review threads, and resolve them. - Attach screenshots, recordings, traces, logs, or verification notes to the work. + Screenshot the environment and file the result to the proof drawer (macOS), or attach an existing image with `ade proof attach`. - - Accept screenshots, mockups, and diagrams as message attachments. + + Persist a structured closeout — status, summary, artifacts, and any blocker — as a card in the transcript. - - Pause cleanly for a choice or clarification instead of guessing. + + When Linear is connected, a chat can read a linked issue's context; attaching an issue links it back to the lane and the next PR body. + +The exact set depends on the session: writes and commands are gated by the permission mode, screenshot capture needs a supported platform, and Linear tools appear only when the integration is connected. The CTO additionally gets operator tools (spawning chats, managing workers, dispatching Linear) that regular chats never see. + + +## See what an agent can reach + +Open the tools panel from the composer to see what a session has available and which actions need your approval before they run. + + + Open the tools an agent chat can use + + +## The right agent for the tool + +Capabilities are shared across providers, but the model still matters. Pick the provider and model that suits the task when you start the session — a fast model for a small fix, a stronger one for a gnarly refactor — and switch within the same family mid-session. + + + Provider and model picker for an agent chat + + ## Good chat requests +Specific, verifiable asks get better results than open-ended cleanup. + ```text Find why the billing test fails and fix the smallest underlying bug. ``` @@ -49,4 +94,13 @@ Read the auth module and explain where the redirect state is stored. ## Review before trusting -Agent chat is powerful because it can change real files. Treat the result like any human contribution: inspect the diff, run relevant checks, and read the final summary. +Agent chat is powerful because it changes real files. Treat the result like any contribution: inspect the diff in **Files**, run the relevant checks, and read the closeout summary before you commit or merge. + + + + What's in context, and how to keep a session focused. + + + Read, stage, and resolve the changes an agent makes. + + diff --git a/chat/context.mdx b/chat/context.mdx index 423b9df13..28cc3e214 100644 --- a/chat/context.mdx +++ b/chat/context.mdx @@ -1,53 +1,58 @@ --- title: "Context and artifacts" -description: "Keep agent chats focused with lane context, attachments, proof, and session history." +description: "What's in a chat's context — the lane it starts in, attachments, the transcript, and how summaries carry work forward." icon: "database" --- -ADE keeps chat context tied to the selected lane and session. The agent can inspect the repository directly when it needs more detail. +A chat's context is everything the agent can draw on: where it started, what you attach, and the running transcript of the session. The agent reads files directly from the lane's worktree on demand, so you don't paste source — point it at the right place and let it inspect. -## What the agent sees +## What the agent starts with -- Your prompt. -- The selected lane and branch. -- Relevant PR or Linear context when linked. -- Attachments you add to the chat. -- Recent session context when you resume a conversation. +A new chat opens with its working context already set from the lane: the lane's **name, branch, and working directory** are injected so the agent knows which worktree it's in and where it can write. From there, its context is: -## Attachments and artifacts +- Your prompt and any attachments you add. +- The lane's files, read on demand from the worktree. +- A linked Linear issue, when the lane already has one connected. +- The session transcript — the running record of the conversation. -Use artifacts when they make the task clearer: +## Attach the spec -| Artifact | Example | -|----------|---------| -| Screenshot | UI state the agent should match or debug. | -| Log | Error output from a failing command. | -| Proof | Evidence captured after a change. | -| PR comment | Review feedback the agent should address. | -| Linear issue | Requirements or acceptance criteria. | +When a task has acceptance criteria, attach the Linear issue from the composer so the agent works from the real spec instead of your paraphrase. ADE writes the issue into a per-session context file the agent can read, and — when the chat is on a lane — links the issue so it shows up in the next PR's "Linked Linear issues" block. -## Context window + + Attach a Linear issue to an agent chat + -Long chats eventually fill the model context window. When that happens: +You can also attach images directly to a message — screenshots, mockups, or diagrams the agent should match or debug. + +## The transcript and turns + +Everything the agent draws — messages, reasoning, tool calls, commands, file changes, plans, and questions — is one stream of events that the UI renders as the transcript. Each exchange is a **turn**: your message, the agent's work, and a final marker that records the model, token usage, and (on a lane) a per-turn diff summary. + +The transcript persists to disk, so a session survives an app restart. When you resume a chat, ADE rehydrates the provider's own session and injects a continuity summary, so the next turn picks up where you left off instead of starting cold. + +## The context window + +Long chats eventually fill the model's context window. Providers compact context automatically as it fills, and you'll see a marker in the transcript when they do. When a session gets long: - Continue if the agent is still on track. - Ask the agent to summarize the current state. -- Start a new session in the same lane with the summary. -- Attach the key logs or screenshots instead of relying on old messages. +- Start a fresh session in the same lane, seeded with that summary. +- Re-attach the key logs or screenshots rather than relying on old messages. -Compaction and summaries are useful, but they are not exact memory. Restate any critical constraint before asking the agent to continue. +Compaction and summaries are useful, but they are not exact memory. Restate any critical constraint before asking the agent to continue past a compaction. -## Find old context +## Recover old context -Use **History** to reopen transcripts, inspect tool calls, and recover proof or PR links from previous sessions. +Use **History** to reopen past transcripts, inspect their tool calls, and recover proof or PR links from earlier sessions. A summary pulled from a finished session is the cleanest way to seed a new one in the same lane. - - Search past sessions. + + The full catalog of what a chat agent can do. - - Capture and attach evidence. + + How a lane-scoped chat works, end to end. diff --git a/chat/grid.mdx b/chat/grid.mdx new file mode 100644 index 000000000..e46d3ca9d --- /dev/null +++ b/chat/grid.mdx @@ -0,0 +1,52 @@ +--- +title: "Grid & multi-model" +description: "Run several agents at once and compare their work side by side in grid view." +icon: "grid-2" +--- + +Grid view tiles multiple chat sessions next to each other so you can run several agents in parallel — across lanes or against the same task — and watch them all at once. + + + +## When to use the grid + + + + Send the same prompt to Claude, Codex, and Cursor, then keep the best result. + + + Tile one agent per lane and supervise a whole batch of parallel work. + + + Let several agents attempt the same fix and compare diffs before committing. + + + +## Send one prompt to several models + +Compose a prompt once and launch it across the models you pick. Each runs in its own tile with its own transcript, diff, and approval gate. + + + Compose a prompt for multiple models at once + + + + Grid view with multiple agents + + +## Keep what works + +Each tile is a full chat. Open one to read the full transcript, inspect its diff in Files, or promote its work to a PR — and close the rest. Nothing is committed until you say so. + + +Grid view is most useful for narrow, well-specified tasks where comparing a few attempts is cheap. For broad, multi-step work, give each agent its own lane instead so they don't compete for the same files. + + + + + How a single lane-scoped chat works. + + + Patterns for splitting work cleanly across agents. + + diff --git a/chat/overview.mdx b/chat/overview.mdx index 34c4f4e09..a8927f797 100644 --- a/chat/overview.mdx +++ b/chat/overview.mdx @@ -1,54 +1,81 @@ --- title: "Agent chat" -description: "Talk to coding agents that can read, edit, test, commit, and help create PRs inside a lane." +description: "Talk to a coding agent that reads, edits, runs commands, and opens PRs — all scoped to one lane's worktree." icon: "comments" --- -Agent chat is the fastest way to get work done in ADE. Open a chat in a lane, describe the task, and watch the agent use files, shell commands, Git, tests, and PR actions. +Agent chat is ADE's interactive coding surface. You open a chat in a lane, describe the task, and the agent reads and edits files, runs commands, inspects diffs, commits, and opens PRs — all inside that lane's git worktree. Every tool call streams into the transcript and is expandable, so you can inspect each edit or command before you trust it. -## When to use chat + + Agent chat on the ADE desktop + -Use chat for: +## Lane-scoped by design -- Small features and bug fixes. -- Codebase questions that need real file inspection. -- Test failures and CI failures. -- PR description and review follow-up. -- Iterating on an agent's first pass. +Every chat binds to a lane — a git worktree and branch — and that worktree is the agent's boundary. The lane's branch and working directory are injected into the agent's context, so it always knows where it is. File edits and mutating commands stay inside the lane's worktree; the agent can read outside it for context when it needs to, but it writes only inside the lane unless ADE relaunches it elsewhere. -For broader coordination across lanes, use the CTO and workers. +Because work is isolated per lane, several agents can run in the same repository at once without writing over each other or your primary checkout. -## Providers +## Start a chat or a CLI session -ADE can run chat through several backends depending on your setup: +From an empty Work composer you can launch into an existing lane, or let ADE auto-create a worktree from your prompt. In a lane you can start either an **agent chat** (the streaming, tool-aware surface) or a provider **CLI session** (the provider's own terminal client) — both run scoped to the lane's worktree. -| Provider | Typical setup | -|----------|---------------| -| Claude / Claude Code | API key or authenticated CLI | -| Codex | Codex CLI or OpenAI-backed setup | -| Cursor | Cursor API key through the Cursor SDK | -| OpenCode | Local OpenCode configuration | + + Choose between an agent chat and a CLI session in a lane + -Switch provider and model from the chat header. +## Pick a provider and model per session -## Chat scope +ADE runs five coding agents against the same lane. Pick the provider and model that fits the task when you start the session, and switch within the same family mid-session when you want a different model. -Every chat has a scope: + + Provider and model picker for an agent chat + -| Scope | What it means | -|-------|---------------| -| **Lane chat** | Edits files and runs commands in one lane. This is the normal coding flow. | -| **CTO chat** | Looks across the project and can delegate to workers. | -| **PR-linked chat** | Focuses on a PR, its CI, comments, and review tasks. | +| Provider | Runtime | +|----------|---------| +| **Claude Code** | The bundled Claude Agent SDK — no separate install needed. | +| **Codex** | The `codex` app-server, resolved from PATH, the app bundle, or a configured install. | +| **Cursor** | The official `@cursor/sdk`, authenticated through the SDK. | +| **Factory Droid** | The official `@factory/droid-sdk`, resolved from PATH, the app bundle, or a configured install. | +| **OpenCode** | The OpenCode server runtime, routing your provider API keys, OpenRouter, or a local model (Ollama, LM Studio). | -## What you see + +Add a provider key or subscription in **Settings** before its models appear in the picker. Claude, Codex, Cursor, and Droid can also be installed and signed in from an inline card in the chat when their CLI is missing or unauthenticated. + -- Streaming agent responses. -- Expandable tool calls. -- Terminal output. -- File changes in Files. -- Questions when the agent needs input. -- Proof artifacts when the agent captures evidence. +## See every tool call + +Chat is not a black box. As the agent works, ADE streams each step into the transcript so you can follow — and stop — what it does: + +- Streaming assistant text and reasoning. +- Tool calls and shell commands, grouped into an expandable work log so you can read each file edit or command and its result. +- File changes mirrored into **Files** as a diff, with a per-turn diff summary. +- Questions when the agent needs a decision instead of guessing — the composer locks until you answer or decline. + +Approval gates depend on the session's permission mode: a read-only **plan** mode proposes changes without touching files, while edit and full-auto modes let writes and commands through (with post-hoc review when the session is interactive). + +## The same chat, every surface + +Chat sessions are owned by the machine's runtime, not by any one client. A chat you start on the desktop is the same conversation in the terminal and on your phone — the renderer, `ade code`, and the iOS app are all clients of the same session. + + + + + Agent chat on the ADE desktop + + + + + Agent chat in ade code + + + + + Agent chat on the ADE iOS app + + + Keep the first prompt specific. "Fix the failing auth redirect test" works better than "clean up auth." @@ -56,9 +83,9 @@ Keep the first prompt specific. "Fix the failing auth redirect test" works bette - See what chat agents can do. + The full catalog of what a chat agent can do inside a lane. - - Learn how context, transcripts, and attachments work. + + Run several agents at once and compare their work side by side. diff --git a/computer-use/config.mdx b/computer-use/config.mdx index 42687bf52..b7c4c8eff 100644 --- a/computer-use/config.mdx +++ b/computer-use/config.mdx @@ -1,41 +1,59 @@ --- title: "Proof configuration" -description: "Storage, retention, and troubleshooting for proof artifacts." +description: "Where proof artifacts are stored, how long they last, and how to troubleshoot capture." icon: "sliders" --- +Proof artifacts live with the project, under its `.ade/` directory on the machine that owns the project. Files sit on disk; their owners, review state, captions, and kind live in ADE's project database. The pairing is what lets an artifact still know which PR and chat it belongs to even though the file on disk is just an image or video. + ## Storage -Proof files live under the project's `.ade/` directory: +Captured files land under the project's `.ade/` scaffold: ```text .ade/artifacts/computer-use/ - .png - .mp4 - .zip + .png # screenshots + .mp4 # recordings + .zip # browser traces ``` -Metadata such as owner links, review state, notes, and file type lives in ADE's local database. +Each capture also writes one row to the project database (`.ade/ade.db`) with the artifact's kind, caption, storage URI, and owner link. That metadata — not the file itself — is what surfaces the proof in the chat drawer and at PR review. -## Retention + +For a project opened on a **remote runtime**, proof is stored on the remote host, not your desktop machine. The desktop drawer fetches preview bytes over the same connection as the rest of the remote project; the raw files are not synced back, so proof is viewable while the runtime that captured it is reachable. + -ADE keeps proof artifacts until you dismiss or delete them. This preserves review evidence after a PR or task is complete. +## Configuration and troubleshooting -Clean up old proof from the UI when artifacts are no longer useful. Avoid deleting files directly from `.ade/artifacts/`, because that leaves database records pointing at missing files. + + + There is no automatic retention policy — captures persist until the project is cleaned up. Disk is the budget; nothing ages out on its own. -## Troubleshooting + Dismiss or remove proof through ADE rather than deleting files directly from `.ade/artifacts/computer-use/` — deleting on disk leaves database rows pointing at missing files. Removing through ADE clears the metadata too. + - - Grant Screen Recording permission to ADE in macOS System Settings, then quit and relaunch ADE. + Grant **Screen Recording** permission to ADE in **System Settings → Privacy & Security**, then quit and relaunch ADE. macOS only applies the permission to a fresh launch. + - Run `ade proof status --text` and confirm the local capture tools are available. + Run `ade proof status --text` and confirm capture is reported as available. Capture relies on the macOS built-in `screencapture`; on unsupported platforms the command exits non-zero. If status looks wrong, relaunch ADE. - - Open the proof, check its owners, and publish or attach it to the PR again. + + + `ade proof capture` exits non-zero when it can't resolve an owner and no `--owner-kind`/`--owner-id` flags were passed — an un-owned proof has no home in the UI. Run it from inside an ADE chat or lane session, or pass the owner explicitly. - - Confirm each input has real content through `path`, `uri`, `text`, or `json`. + + + Each input needs real content through `path`, `uri`, `text`, or `json`; an input with none of these is skipped. Path-based inputs must resolve inside an allowed import root — the project's `.ade/artifacts` or `.ade/tmp`, the OS temp dir, or `~/.agent-browser`. Paths outside those roots are rejected. + + + + The `ade proof` capture, attach, and ingest commands. + + + Where ADE keeps the rest of your project state. + + diff --git a/computer-use/overview.mdx b/computer-use/overview.mdx index dc7945df5..77c4d61e3 100644 --- a/computer-use/overview.mdx +++ b/computer-use/overview.mdx @@ -1,52 +1,74 @@ --- title: "Proof" -description: "Capture screenshots, recordings, traces, logs, and verification notes as evidence for agent work." +description: "Capture screenshots, recordings, browser traces, console logs, and verification notes as evidence for agent work — linked to the chat, lane, PR, or Linear issue they belong to." icon: "camera" --- -Proof is ADE's evidence system. It lets an agent or human attach concrete verification to a chat, lane, PR, Linear issue, or worker task. +**Proof** in ADE is *intentional* evidence — a screenshot, recording, browser trace, console log, or verification note — captured at the moment a result is visible to show that a change actually does what it claims. Agents often say they tested something; proof makes that claim inspectable, and ties it to the work it belongs to. + +Nothing watches your agent and files screenshots for it. When the agent (or you) reaches a checkpoint worth showing — a login succeeds, a form submits, an error reproduces, a test passes — proof is captured on purpose and normalized into one canonical artifact model that a reviewer can skim in under a minute. + + + + Concrete artifacts a reviewer can open, instead of a claim buried in a transcript. + + + Every proof links to a chat, lane, PR, or Linear issue — and can link to several at once. + + + Captures are deliberate. There's no auto-observer; the agent or you decide a moment deserves evidence. + + ## Proof kinds +ADE normalizes every capture into one of five canonical kinds, whatever tool produced it. + | Kind | Use it for | |------|------------| -| Screenshot | Show the visible state of an app or browser. | -| Recording | Capture a short interaction or repro. | -| Browser trace | Preserve browser steps and diagnostics. | -| Console logs | Attach useful runtime output. | -| Verification note | Record what was checked and why it passed. | +| **Screenshot** | Show the visible state of an app or browser. | +| **Recording** | Capture a short interaction or repro. | +| **Browser trace** | Preserve browser steps and diagnostics from a test tool. | +| **Console logs** | Attach useful runtime or browser output. | +| **Verification note** | Record what was checked and why it passed. | -## Why proof matters + + Inspecting a page in ADE's browser pane + -Agents often say they tested something. Proof makes that claim inspectable. A PR with a screenshot, a test log, and a short summary is easier to review than a PR with only a chat transcript. +## What proof attaches to -## Where proof appears +Every artifact carries at least one owner. A single artifact can link to more than one, so it surfaces wherever the work is reviewed — and evidence can flow from an exploratory chat to a PR comment without losing provenance. -- Chat artifact panels. -- Lane and History records. -- PR detail views. -- Linear issue updates when connected. -- Worker activity when a worker captures it. +- **Chat** — the proof drawer below the composer in the session that produced it. +- **Lane** — alongside the worktree's diff and review. +- **PR** — surfaced at pull request closeout, where reviewers look. +- **Linear issue** — attached to the issue when Linear is connected. +- **Automation run** — captured as part of a dispatched agent or worker run. -## Basic flow +## Where it fits - - Use the proof controls or ask the agent to capture evidence for a completed step. + + A UI change renders, a flow completes, a test passes, an error reproduces. - - Open the artifact and confirm it shows the right thing. + + The agent or you capture a screenshot, recording, trace, log, or note with a short caption. - - Link it to the PR, Linear issue, chat, or lane that needs the evidence. + + The artifact rides along with the chat, lane, PR, or issue — so the result is verifiable, not just asserted. + +Capture proof at the moment the result is visible, and write captions like a teammate is reading them. A good proof set is three to eight captures with captions a reviewer can read in one pass — not a screenshot after every click. + + - - More detail on ownership and publishing. + + Prerequisites and the `ade proof` capture commands. - - Capture prerequisites and CLI usage. + + The capture, review, and attach lifecycle in detail. diff --git a/computer-use/proofs.mdx b/computer-use/proofs.mdx index d8c0cd408..e84ae0f8e 100644 --- a/computer-use/proofs.mdx +++ b/computer-use/proofs.mdx @@ -1,63 +1,76 @@ --- -title: "Proof workflow" -description: "Capture, review, and attach evidence to chats, lanes, PRs, Linear issues, and worker activity." +title: "Review proof" +description: "The capture → review → attach lifecycle: owners, review states, and good habits." icon: "camera" --- -Proof is only useful when it is easy to review and tied to the work it supports. +Proof is only useful when it's easy to review and tied to the work it supports. A screenshot without an owner is just a file; the same screenshot linked to a PR and chat explains what it proves. The lifecycle is short — capture, review, attach — and every artifact carries an owner and a review state. -## Proof kinds +## Where proof surfaces -| Kind | Typical use | -|------|-------------| -| Screenshot | Confirm a UI state or visible result. | -| Recording | Show a short flow or reproduction. | -| Browser trace | Preserve structured browser diagnostics from a test tool. | -| Console logs | Attach useful runtime or browser output. | -| Verification note | Record what was checked and what passed. | +Proof shows up in two places: -## Owners +- **Chat** — the proof drawer below the composer shows a thumbnail grid for the current session. Captions render in full under each thumbnail; click to preview at full size. +- **Lane and PR review** — linked proof is surfaced alongside lane work and at PR closeout, where reviewers actually look. -A proof can be linked to more than one owner: +## Owners -- Lane. -- Chat session. -- Pull request. -- Linear issue. -- Worker task or worker activity. +A single proof can be linked to more than one owner. That link is what makes the artifact useful later, and adding an owner never drops the existing ones — provenance is preserved as evidence flows downstream. -That link is what makes the artifact useful later. A screenshot without an owner is just a file; a screenshot linked to a PR and chat explains what it proves. +- **Chat session** — the conversation that produced it. +- **Lane** — the worktree the work happened in. +- **Pull request** — where reviewers actually look. +- **Linear issue** — when Linear is connected; attached at closeout. +- **Automation run** — when a dispatched agent or CTO worker captured it. ## Review states +Every artifact moves through a small set of states so reviewers know what's been judged: + | State | Meaning | |-------|---------| -| Pending | Not reviewed yet. | -| Accepted | Good evidence for the claim. | -| Needs more | Useful but incomplete. | -| Dismissed | Not relevant. | +| **Pending** | Captured, not reviewed yet (the default). | +| **Accepted** | Good evidence for the claim. | +| **Needs more** | Useful but incomplete — capture again. | +| **Dismissed** | Not relevant to the final result. | +| **Published** | Promoted to a PR comment or Linear issue. | -## Basic lifecycle +Accept / request-more / dismiss are first-class controls on each proof in the drawer. + +## The lifecycle - Capture a screenshot, recording, trace, log, or verification note. + Capture a screenshot, recording, trace, log, or verification note from the relevant chat or lane. - Open the proof and decide whether it supports the work. + Open the proof and decide whether it supports the work — accept, request more, or dismiss. - Link accepted proof to the PR, Linear issue, lane, chat, or worker activity. + Link accepted proof to the PR, Linear issue, lane, or chat. The same artifact can ride along to several owners at once. - Use the proof during review so the result is inspectable. + Use the proof during review so the result is inspectable, not just asserted. ## Good proof habits -- Capture after the relevant change is visible. -- Give the artifact a plain title. -- Attach test output when the proof is about correctness. -- Prefer one clear screenshot over a long unrelated recording. -- Dismiss proof that no longer supports the final result. +- Capture **after** the relevant change is visible, not during the work. +- Write a caption that names the exact state being proven — "checkout succeeds, confirmation visible," not "screenshot 3." +- Keep a set to three to eight captures a reviewer can read in one pass; avoid dumping a screenshot after every click. +- Attach test output or a verification note when the proof is about correctness. +- Dismiss proof that no longer supports the final result, so the record stays honest. + + +For a reviewer, the strongest PR pairs a visual proof with a short verification note: a screenshot of the result plus one line on what was checked and why it passed. + + + + + What proof is and why it matters. + + + Storage, retention, and troubleshooting. + + diff --git a/computer-use/setup.mdx b/computer-use/setup.mdx index a2668856f..92fbf5a87 100644 --- a/computer-use/setup.mdx +++ b/computer-use/setup.mdx @@ -1,55 +1,110 @@ --- -title: "Proof setup and CLI" -description: "Use local capture tools and `ade proof` commands to record evidence." +title: "Capture proof" +description: "Capture evidence from the CLI with the real `ade proof` commands — capture, attach, list, and status." icon: "terminal" --- -On macOS, ADE uses built-in tools for screenshots and short recordings. The first capture may require Screen Recording permission in **System Settings -> Privacy & Security**. +On macOS, ADE captures screenshots and short recordings with the system's built-in tools — no extra install. The first capture may ask for **Screen Recording** permission in **System Settings → Privacy & Security**; grant it to ADE, then quit and relaunch. -## Common commands +Both you and agents capture proof the same way, through the `ade proof` CLI. Captures are intentional — you run a command when a moment deserves evidence. Each capture is scoped to the chat or lane it runs in: agents launched inside ADE pick up the right owner automatically from the session they're running in, so most captures need no owner flags at all. -| Command | Use | -|---------|-----| -| `ade proof status --text` | Check available capture capabilities. | -| `ade proof list --text` | List proof artifacts for the current scope. | -| `ade proof screenshot` | Capture a screenshot. | -| `ade proof record --seconds 20` | Capture a short recording. | -| `ade proof ingest --input-json '{...}'` | Ingest a trace, log, or verification from another tool. | - -## Typical flow +## Capture, then it's filed - - Run a screenshot, recording, or ingest command from the relevant lane/session. - - - ADE writes the file under `.ade/artifacts/computer-use/` and records metadata in the local database. + + Run `ade proof capture` to screenshot the current state, or `ade proof attach ` to promote a file you already produced. - - Link the proof to a chat, lane, PR, Linear issue, or worker activity. + + The file is copied under `.ade/artifacts/computer-use/` and a row is written to the project database with its owner link. - Open the proof from the UI and accept, request more, or dismiss it. + The proof appears in the chat drawer and at lane / PR review, where you can accept it, request more, or dismiss it. -## Ingest external evidence +## Command reference + + + + Take a screenshot now and file it as proof for the current session. + + ```bash + ade proof capture --caption "logged in as admin" + ade proof capture --caption "order #1234 submitted, confirmation visible" + ``` + + | Flag | Use | + |------|-----| + | `--caption ""` | Short label, prominent in the drawer grid. Write it like a teammate is reading it. | + | `--owner-kind chat\|lane` | Override the inferred owner. Rarely needed. | + | `--owner-id ` | Pair with `--owner-kind` to target a specific chat or lane. | + + The owner is inferred from the session you're in. If no owner can be resolved and no flags are passed, the command exits non-zero — an un-owned proof has no home in the UI. + + + + Promote an image, video, or browser-trace file you produced out-of-band — a headless-browser screenshot, a Playwright trace rendered as PNG, anything on disk. + + ```bash + ade proof attach /tmp/playwright-run/checkout-success.png \ + --caption "checkout flow completes on Firefox" + ``` + + The proof kind is inferred from the file extension: images become **screenshots**, `.mov`/`.mp4`/`.webm` become **recordings**, `.zip`/`.har` become **browser traces**. The original file is left in place; ADE copies it into `.ade/artifacts/computer-use/`. + -Use `ade proof ingest` for output from browser tests or other verification tools: + + Print the proof set for the current session as JSON. Primarily for agents to see what they've already captured. -```bash -ade proof ingest --input-json '{ - "backend": { "name": "playwright" }, - "inputs": [ - { "kind": "browser_trace", "title": "checkout flow", "path": "/tmp/trace.zip" }, - { "kind": "console_logs", "title": "checkout console", "text": "..." } - ], - "owners": [ - { "kind": "pull_request", "id": "123" } - ] -}' -``` + ```bash + ade proof list --text + ade proof list --owner-kind lane --owner-id --limit 20 + ``` + + + + Report whether the runtime can capture (`screencapture` availability, OS support). + + ```bash + ade proof status --text + ``` + + `ade proof record --seconds ` records a short video proof where supported. + + + + Ingest externally produced artifacts directly through the proof broker, with owners set in one call. Owner kinds are `chat` (alias for `chat_session`), `lane`, `pr` (alias for `github_pr`), `linear_issue`, and `automation_run`. + + ```bash + ade proof ingest --input-json '{ + "backend": { "name": "playwright" }, + "inputs": [ + { "kind": "browser_trace", "title": "checkout flow", "path": "/tmp/trace.zip" }, + { "kind": "console_logs", "title": "checkout console", "text": "..." } + ], + "owners": [ + { "kind": "pr", "id": "123" } + ] + }' + ``` + + Each input needs real content through `path`, `uri`, `text`, or `json`. Paths must resolve inside an allowed import root (the project's `.ade/artifacts` or `.ade/tmp`, the OS temp dir, or `~/.agent-browser`). + + -If screenshots are blank, restart ADE after granting Screen Recording permission. +Run `ade help proof` for the complete, current flag list. The `ade proof` commands print a JSON summary on success and exit non-zero on failure. + + +If screenshots come out blank, grant Screen Recording permission to ADE and relaunch — macOS only applies the permission to a fresh launch. + + + + + The capture, review, and attach lifecycle. + + + Storage, retention, and troubleshooting. + + diff --git a/configuration/ai-providers.mdx b/configuration/ai-providers.mdx index 4db27041f..f1288cf23 100644 --- a/configuration/ai-providers.mdx +++ b/configuration/ai-providers.mdx @@ -1,41 +1,81 @@ --- title: "AI providers" -description: "Configure Claude, Codex, Cursor, OpenCode, and other providers for ADE agent sessions." +description: "Connect Claude Code, Codex, Cursor, Factory Droid, and OpenCode — with your own key or an existing subscription." icon: "brain" --- -ADE can route chats, CTO work, and workers through multiple providers. Configure at least one provider before starting agent work. +ADE runs **Claude Code, Codex, Cursor, Factory Droid, and OpenCode** — every chat, CTO task, and worker routes through one of these five agents. Connect at least one before starting agent work. Each can use your own API key or, where supported, an existing subscription sign-in. -## Supported paths +## The five agents -| Provider | Typical use | -|----------|-------------| -| Claude / Claude Code | General coding, planning, review, and worker tasks. | -| Codex | OpenAI coding workflows and CLI-backed sessions. | -| Cursor | Cursor agent sessions through the Cursor SDK. | -| OpenCode | Local or provider-backed OpenCode workflows. | -| OpenRouter / local endpoints | Cost routing, experimentation, or local models. | +| Agent | Connect with | Typical use | +|-------|--------------|-------------| +| **Claude Code** | Claude subscription or Anthropic API key | General coding, planning, review, worker tasks. | +| **Codex** | OpenAI sign-in or API key | OpenAI coding workflows and CLI-backed sessions. | +| **Cursor** | Cursor API key (`CURSOR_API_KEY`) | Cursor agent sessions through the Cursor SDK. | +| **Factory Droid** | Factory sign-in or API key | Droid agent sessions, including AGI mode. | +| **OpenCode** | API key, OpenRouter, or local endpoint | Broadest model reach; local or provider-backed. | -## Configure a provider +## The models you can reach through ADE's agents + +These agents — plus OpenCode and OpenRouter routing — give you access to models from every major lab. Pick whichever fits the task. + + +
+ Anthropic Claude + OpenAI + Google Gemini + DeepSeek + Qwen + Mistral + Meta Llama + Grok + Ollama + Perplexity + Cohere +
+ + +## Connect a provider - - Choose the provider you want to use. + + Choose the agent you want to connect. - Paste an API key, configure a local endpoint, or authenticate the provider CLI. + Paste an API key, sign in with a subscription, configure a local endpoint, or authenticate the provider CLI. - Run the provider check and make sure ADE can start a session. + ADE probes the provider CLI and lists its available models. A green status means it's ready to start a session. - Set your default chat model and any role-specific overrides you need. + Set your default chat model and any role-specific overrides for CTO, workers, or specific lanes. +Per-agent key steps are below. + + + + Sign in with a Claude subscription or paste an Anthropic API key. ADE runs Claude through the bundled Claude Agent SDK, so the `claude` CLI does not need to be installed separately. See [Claude Code](/ai-tools/claude-code) for lane context and permission modes. + + + Sign in with your OpenAI account or provide an API key. Codex runs as a CLI-backed session and reaches OpenAI models. + + + Provide a Cursor API key (or set `CURSOR_API_KEY` in the environment ADE launches from). ADE recognizes the key as valid auth and discovers Cursor's available models at startup. See [Cursor](/ai-tools/cursor). + + + Sign in with Factory or provide an API key. Droid runs as an agent provider and supports AGI mode for larger autonomous tasks. + + + Toggle OpenCode on; ADE downloads and manages the binary and local server. OpenCode is what powers API-backed and local-model chats — back it with an Anthropic or OpenAI key, an OpenRouter key for any model, or a local OpenAI-compatible endpoint such as LM Studio or Ollama. See [OpenCode & Windsurf](/ai-tools/windsurf). + + + ## Permission presets -Providers expose different native permission models. ADE maps them into a small set of practical choices: +Providers expose different native permission models. ADE maps them into a small set of practical choices. | Preset style | Use it when | |--------------|-------------| @@ -44,10 +84,25 @@ Providers expose different native permission models. ADE maps them into a small | Full access | You are in a trusted environment and want minimal prompts. | | Custom | You want the provider's own config to decide. | -## Cost control +Set stricter modes for unfamiliar repositories. The full mapping lives in [Permissions](/configuration/permissions). + +## Cost and usage -Running several agents in parallel can spend quickly. Use cheaper models for routine follow-up and stronger models for planning, architecture, and hard debugging. Review usage from **Settings -> Usage**. +Running several agents in parallel can spend quickly. Use cheaper models for routine follow-up and stronger models for planning, architecture, and hard debugging. The top-bar **Usage** popup shows live provider quota windows and lets you set a budget cap; **Settings → Stats** is the retrospective view of token, cost, and GitHub activity. + + + Per-provider usage and quota windows in ADE + -Provider calls go directly from your machine to the provider or local endpoint you configure. Keep keys out of committed files. +Provider calls go directly from your machine to the provider or local endpoint you configure. Keep keys out of committed files — ADE stores them in local encrypted settings. + + + + Lane scope, provider modes, and how secrets are handled. + + + Every Settings section and a first-pass order. + + diff --git a/configuration/overview.mdx b/configuration/overview.mdx index 89fc075c7..b461f8a41 100644 --- a/configuration/overview.mdx +++ b/configuration/overview.mdx @@ -1,47 +1,60 @@ --- title: "Configuration overview" -description: "Where ADE stores local project state, shared defaults, credentials, and runtime files." +description: "The `.ade/` directory, the shared-vs-local trust model, and what stays out of Git." icon: "folder-tree" --- -ADE keeps project state local. Most of what ADE creates belongs under `.ade/` in your repository and should not be committed. +ADE keeps project state local. Everything ADE creates for a project lives under `.ade/` at the repository root, alongside your source tree but outside Git's control. Your code stays under normal version control; ADE's runtime bookkeeping stays out of it. ```text .ade/ - ade.db - worktrees/ - artifacts/ - cache/ - secrets/ + ade.db # lanes, sessions, PR mappings, proof metadata, settings + ade.yaml # shared, version-controlled team config + local.yaml # per-user overrides (gitignored) + worktrees/ # managed lane worktrees (one directory per lane) + artifacts/ # proof artifacts (screenshots, recordings, traces) + cache/ # derived data ADE can rebuild + secrets/ # encrypted, machine-local credentials ``` -## What is local +## Shared vs. local config + +ADE splits configuration into two files, both merged into one effective config at read time: + +| File | Scope | In Git? | Holds | +|------|-------|---------|-------| +| `.ade/ade.yaml` | Shared | Committed | Team-wide processes, stacks, tests, lane templates, automations, AI mode, and provider/Linear preferences. | +| `.ade/local.yaml` | Local | Gitignored | Personal overrides: ports, env vars, machine-specific paths, local-only processes. | + +Keep secrets and machine-specific paths in local config. Shared config is visible to the whole team, so anything in it ships to every teammate. + +## What stays local | Area | Contains | |------|----------| -| Database | Lanes, sessions, PR mappings, settings, History metadata. | -| Worktrees | Managed lane worktrees. | -| Artifacts | Proof, transcripts, exported evidence, and supporting files. | -| Secrets | Encrypted or machine-local credentials. | -| Cache | Derived data ADE can rebuild. | +| Database (`ade.db`) | Lanes, sessions, PR mappings, proof metadata, and settings. | +| Worktrees | The isolated working copy for each lane. | +| Artifacts | Proof captures — screenshots, recordings, and traces. | +| Secrets | Encrypted, machine-local credentials. | +| Cache | Derived data ADE can regenerate on demand. | -## What can be shared +## Trust model -Some teams choose to share project defaults, such as recommended processes, test commands, provider preferences, or lane templates. Keep secrets and machine paths out of shared files. +Commands saved as shared project defaults can run on developer machines. ADE treats those definitions as sensitive: when the shared config changes, it requires a local trust confirmation before the new version can spawn processes. Review such changes the same way you'd review a CI script or Dockerfile. Local config isn't trust-gated — you only need to trust your own overrides. - -Never commit provider keys, tokens, local secret files, or the whole `.ade/` directory. - +## What's committed, and what isn't -## Trust model +ADE manages this for you. It writes a `.ade/.gitignore` that ignores everything under `.ade/` by default and allowlists only the authored files meant to travel with the repo — `ade.yaml`, lane templates, skills, and project icons. Runtime files (the database, worktrees, artifacts, cache, and secrets) stay out of Git automatically, so you don't have to maintain ignore rules by hand. -Commands saved as shared project defaults can run on developer machines. ADE treats those changes as sensitive and may require local approval before using newly changed command definitions. + +Never put provider keys, tokens, or other secrets in `.ade/ade.yaml` or any committed file. Secrets belong in the local encrypted store or `.ade/local.yaml`, both of which stay off the shared path. + + + Lane scope, provider modes, and the shared-config trust model. + Configure the app from the UI. - - Review security and permission controls. - diff --git a/configuration/permissions.mdx b/configuration/permissions.mdx index 433717965..9bd4a01d3 100644 --- a/configuration/permissions.mdx +++ b/configuration/permissions.mdx @@ -1,57 +1,89 @@ --- title: "Permissions and security" -description: "How ADE keeps agent work scoped, reviewable, and local-first." +description: "How ADE keeps agent work scoped to a lane, makes shared config trusted before it runs, and keeps secrets local." icon: "shield-check" --- -ADE agents can edit files and run commands, so permissions matter. The goal is to keep work scoped to the right lane and make risky actions visible before they happen. +ADE agents edit files and run commands, so permissions matter. The goal is simple: keep each agent's work scoped to the right lane, make shared config trusted before it can run on your machine, and keep secrets off disk in plaintext. ## Main controls - Sessions run inside a selected lane worktree. + Sessions run inside the selected lane's worktree under `.ade/worktrees/`, isolated from your primary checkout and from other lanes. - - Claude, Codex, Cursor, and OpenCode each expose provider-specific approval modes. + + Claude Code, Codex, Cursor, Factory Droid, and OpenCode each expose their own approval modes; ADE maps them to a common set. - - Shared command definitions may require local approval before they run. + + Shared config that can spawn processes requires a trust confirmation before ADE will run it. - Credentials stay in local encrypted stores or gitignored files. + Provider keys and credentials stay in local encrypted stores or gitignored files — never in shared config. -## Practical defaults +## Lane scope -- Use worktree lanes for agent edits. -- Keep the primary checkout for inspection or manual commands. -- Review diffs before committing or pushing. -- Use stricter provider approval modes for unfamiliar repositories. -- Do not store provider keys in committed files. -- Treat shared command changes like CI or Dockerfile changes: review them carefully. +A lane is a git worktree. Chats, terminals, CLI sessions, and the processes they start are scoped to that worktree, so an agent working a task can't reach into your primary checkout or another lane's files. Do agent edits in lanes and keep the primary checkout for inspection — it's your real working tree and the safer default to leave alone. + +## Per-agent tool control + +Each agent runs with a permission mode that governs how freely it can edit files and run commands. Set a stricter mode for unfamiliar repositories, and a more permissive one only when you trust the lane and the task. You can also scope which tools a session may use from the chat header. + + + The chat tools button in ADE + + +## Provider permission modes + + + Permission names vary by provider, but ADE groups them into a common set: + + | Mode | Meaning | + |------|---------| + | Plan / read-only | The agent can inspect and propose, but cannot freely edit. | + | Edit / default | The agent works in the lane with normal approval guardrails. | + | Full auto | The agent runs with fewer prompts. Use only when the environment is trusted. | + | Custom | The provider's own configuration decides. | + + Set defaults per provider in **Settings → AI Connections**, and override per chat or worker as needed. + -## Provider modes +## The trust model for shared config -Permission names vary by provider. In general: +ADE splits project configuration into shared, version-controlled `.ade/ade.yaml` and a per-user, gitignored `.ade/local.yaml`. Shared config can introduce new commands — processes, stacks, test suites — that you haven't approved. ADE treats that as sensitive: when the shared config changes, it must be **trusted** again before ADE will return an executable config that spawns processes. Cloning a repo and opening it requires confirming trust on its shared config the first time. -| Mode style | Meaning | -|------------|---------| -| Read-only / plan | The agent can inspect and propose, but cannot freely edit. | -| Default / edit | The agent can work in the lane with normal guardrails. | -| Full access | The agent can run with fewer prompts. Use only when the environment is trusted. | +Local config isn't trust-gated — you only need to trust your own overrides. Treat a shared-config change the same way you'd review a CI script or Dockerfile. + +## Practical defaults + +- Do agent edits in worktree lanes, not the primary checkout. +- Keep the primary checkout for inspection or manual commands. +- Review diffs before committing or pushing. +- Use stricter approval modes for unfamiliar repositories. +- Keep provider keys and tokens out of shared config and out of Git. +- Review shared-config changes carefully before confirming trust. ## Sensitive actions Be extra careful with: - Force pushes. -- Commands outside the repository. +- Commands that run outside the repository. - Secret files and `.env` files. - Scripts pulled from unreviewed branches. - Networked deployment or release commands. -ADE helps enforce boundaries, but it is still running tools on your machine. Review what agents ask to do, especially in new repositories. +ADE helps enforce boundaries, but agents still run tools on your machine. Review what they ask to do, especially in new repositories and the first time you open a teammate's shared config. + + + + Connect each agent and set permission presets. + + + The `.ade/` directory, the trust model, and what not to commit. + + diff --git a/configuration/settings.mdx b/configuration/settings.mdx index 288a8a479..d1b55d4d7 100644 --- a/configuration/settings.mdx +++ b/configuration/settings.mdx @@ -1,67 +1,88 @@ --- title: "Settings" -description: "The main ADE settings sections and when to use them." +description: "The real ADE settings tabs, a recommended first pass, and the first-run setup that detects your stack." icon: "sliders" --- -Open Settings with `Cmd+,` or the gear icon. +Settings is where you connect providers, link GitHub and Linear, tune how ADE looks and behaves, and shape how lanes are created. It's organized by the kind of thing you're changing, not by which service backs it. -## Main sections + + The ADE Settings page + + +## The tabs - App updates, startup behavior, onboarding, help, and basic preferences. + AI mode, task routing, terminal preferences, keybindings, project setup re-entry, and the `ade` CLI install / health surface. - Theme, density, terminal appearance, and UI preferences. + Theme, chat density and font size, code-block options, completion sound, and voice dictation. + + + Provider CLIs, sign-in and API keys, model availability, and provider readiness for the five agents. - - Provider keys, CLI detection, default models, and session preferences. + + Lightweight AI helpers: auto-naming chats and lanes, summarizing finished work, and drafting PR and commit messages. - GitHub, Linear, proof, and external service connections. + GitHub, Linear, and the `ade` CLI integration tabs. - - Pair the iOS app, manage devices, and choose notification behavior. + + Lane initialization recipes and lifecycle policies — what new lanes set up, and when old ones get cleaned up. - - Review provider usage, budget signals, and session spend. + + A retrospective dashboard: local AI token / cost summaries and GitHub-backed PR, commit, and code-movement totals. + +A few controls live in the **top bar**, not in Settings: live provider quota windows and the automation budget sit in the **Usage** popup, and phone pairing and multi-device sync sit in the **Sync** popover. Settings → Stats is the retrospective view; the Usage popup is the live one. + + +## First-run setup + +When you open a project for the first time, ADE shows a setup dashboard — a single page of status cards rather than a blocking step-by-step wizard. It detects your stack and suggests config so you don't have to write it by hand: + +- **Developer tools** — checks for `git` and the GitHub CLI. +- **Stack detection** — looks for `package.json`, `Cargo.toml`, `go.mod`, `pyproject.toml`, a `Makefile`, `docker-compose`, and `.github/workflows/`, then suggests processes, test commands, and stacks. +- **AI runtimes** — a compact band to set up Claude, Codex, Cursor, Factory Droid, and OpenCode. +- **GitHub and Linear** — optional cards for repository auth and Linear connection. +- **Existing worktrees** — import git branches you already have as lanes in one click. + +Nothing here blocks you. You can skip any card and re-run setup later from **General**. + ## Recommended first pass +Only the first step is required to start running agents — the rest unlock GitHub, Linear, and mobile workflows. + - Make sure at least one agent provider is green. + In **AI Connections**, make sure at least one of Claude Code, Codex, Cursor, Factory Droid, or OpenCode is green. That's all you need to start a lane chat. - Do this if you want PR creation, CI state, comments, and merge workflows. + Do this for PR creation, CI state, comments, and merge workflows. Do this if issues should link to lanes, CTO work, and PR updates. - - Do this if you want iPhone updates for agent work and PR activity. + + From the top-bar **Sync** popover, reveal the pairing PIN to bring agent work and PR activity to iOS. - - Set budgets or choose cheaper default models before running many agents in parallel. + + Check the top-bar **Usage** popup and set a budget cap before running many agents in parallel. -## Provider settings - -Provider settings control which agents can run. Keep at least one reliable default model configured, then override per chat or worker when needed. - -## Local-first behavior +## Shared vs. local config -Settings that include secrets are stored locally. ADE does not commit credentials to your repository. +ADE splits project configuration into two files: shared, version-controlled team config (`.ade/ade.yaml`) and a per-user, gitignored overlay (`.ade/local.yaml`). Saving shared config triggers a trust confirmation, since shared settings can introduce commands that run on every teammate's machine. Anything with a secret — provider keys, GitHub and Linear tokens — stays in a local encrypted store and is never committed. - Provider-specific setup and permission presets. + Connect each agent, set permission presets, and control cost. - - Pair your phone and manage mobile notifications. + + Where ADE stores local state and what to keep out of Git. diff --git a/cto/linear.mdx b/cto/linear.mdx deleted file mode 100644 index 398ff7514..000000000 --- a/cto/linear.mdx +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: "Linear" -description: "Connect Linear so ADE can link issues, lanes, PRs, CTO context, and follow-up notes." -icon: "layers" ---- - -Linear is optional. Connect it when your planning and review loop already runs through Linear issues. - -## What the integration does - - - - Attach Linear issue details to lanes, chats, CTO prompts, and PRs. - - - Publish useful progress and closeout notes back to issues. - - - Ask the CTO to plan or route work from a Linear issue. - - - Keep the issue, lane, commits, PR, and proof connected. - - - -## Connect Linear - - - - Choose Linear and start the connection flow. - - - Use OAuth or a token with the required issue access for your workspace. - - - Select the workspace/team ADE should use when creating or linking work. - - - Link an issue to a lane and verify it appears in the lane and CTO context. - - - -## Good CTO prompts with Linear - -```text -Read ENG-142 and propose a lane plan with acceptance criteria. -``` - -```text -Summarize what changed on the PR linked to ENG-142 and draft a Linear update. -``` - -```text -Which Linear issues are blocked by current PR or CI state? -``` - - -ADE uses the permissions granted to your Linear connection. If issue updates fail, reconnect Linear or check the token scopes. - diff --git a/cto/overview.mdx b/cto/overview.mdx index 2a2de12e4..7ab1addd7 100644 --- a/cto/overview.mdx +++ b/cto/overview.mdx @@ -1,40 +1,76 @@ --- title: "CTO" -description: "Use the CTO as a project-level agent for planning, delegation, Linear context, and worker coordination." +description: "The CTO is ADE's persistent, project-level operator — one per project. It keeps context across every lane, plans work, and delegates to workers." icon: "crown" --- -The CTO is ADE's project-level agent. Use it when the question or task spans more than one lane, needs planning, or should be delegated to workers. +The **CTO** is ADE's persistent, project-level operator: one identity per project, not a rotating set of chats. While a lane chat works inside a single worktree, the CTO sees the whole project — every lane, PR, and connected Linear issue — and reasons across them. It carries an identity and persona, continuity across long sessions, plans, and a team of **workers** it delegates execution to. -## Use the CTO for +Reach for the CTO when a question or task spans more than one lane, needs planning, or should be handed to workers and tracked to completion. + + + The CTO delegating work to a team of worker agents + + +## What the CTO is - - Ask what changed, what is blocked, and what needs attention. + + One CTO per project with a name, personality preset, and continuity that survives long conversations — not a fresh chat each time. - - Break larger work into lane-scoped worker tasks. + + It reasons across every lane, PR, and connected Linear issue, instead of one worktree at a time. - - Read issues, link work, and publish updates when Linear is connected. + + Splits a plan into scoped tasks and hands each to a worker that runs in its own lane. - - Ask for PR risk summaries, CI explanations, or follow-up plans. + + When Linear is connected, the CTO triages issues, dispatches the work, and syncs status back. -## CTO vs lane chat +## CTO vs. lane chat -| Use lane chat when | Use CTO when | -|--------------------|--------------| +The CTO doesn't replace lane chats — it sits above them. A lane chat edits files in one worktree; the CTO plans the work, splits it into lanes, hands pieces to workers, and summarizes the result. Pick whichever matches the altitude of your question. + +| Use a lane chat when | Use the CTO when | +|----------------------|------------------| | You know the specific lane and task. | The work spans several lanes or issues. | | You want one agent to edit files. | You want planning, routing, or delegation. | -| You are debugging a local failure. | You need project-wide state summarized. | +| You're debugging a local failure. | You need project-wide state summarized. | +| The change fits in one review. | You want issues run end to end from Linear. | + + +The CTO lives in its own **CTO** tab, organized into Chat, Team, Workflows, and Settings. The Chat surface is light by default — Team, Workflows, and Settings load only when you open them. + -## Workers +## How delegation works -Workers are scoped agent identities the CTO can assign work to. They can have roles, budgets, model settings, and activity history. See [Workers](/cto/workers) for the operational model. +Ask the CTO for a plan, approve the shape, and it dispatches the work to **workers** — scoped agents it delegates to, each running in its own lane. You watch the lanes fill in from Work, Lanes, and History, then review diffs and PRs as they land. Nothing merges without your review. + + + + The CTO proposes a split into lane-sized tasks. + + + Each task goes to a worker running in its own lane. + + + The CTO reports progress, risk, and what's ready to ship. + + + +Workers are agent identities with roles, model settings, budgets, and activity history. See [Workers](/cto/workers) for the operational model. -Ask the CTO for a plan before asking it to delegate. A good split saves time and reduces review noise. +Ask the CTO for a plan before asking it to delegate. A clean split into small, independent lanes saves time and reduces review noise. + + + + Pick a provider and persona, connect GitHub and Linear, and add workers. + + + Manage the scoped agents the CTO delegates to. + + diff --git a/cto/setup.mdx b/cto/setup.mdx index 19857b620..9c8cbf736 100644 --- a/cto/setup.mdx +++ b/cto/setup.mdx @@ -1,35 +1,76 @@ --- title: "Set up the CTO" -description: "Prepare the CTO agent for project-level planning and delegation." +description: "Give the CTO a persona and model, connect GitHub and Linear, add a worker or two, and start with a planning prompt." icon: "wand-magic-sparkles" --- -The CTO needs a working AI provider and enough project context to make useful decisions. +The CTO is usable in minutes. First-run setup is intentionally short — you pick a **personality** for the operator and it's ready to chat. A capable model, GitHub, Linear, and workers all layer in afterward, only when you need them. -## Setup checklist + + Running the CTO operator from a chat + + +## First run + +The first time you open the CTO tab, a short wizard asks you to pick a **personality preset** — the only required step. Everything else is deferred to Settings and the relevant tabs. - - In **Settings -> AI Providers**, choose a model you trust for planning and review. + + Choose a preset — strategic, professional, hands-on, casual, minimal, or custom. Custom lets you write your own overlay. This sets the CTO's tone; its core doctrine is fixed by ADE and not editable. - - Recommended for PR summaries, CI explanations, and review follow-up. + + In CTO Settings, set the provider, model, and reasoning effort. The CTO reasons across the whole project, so favor a capable model over a fast one. Until you pick one, the CTO uses the project's default model. - - Optional. Use it when issues should map to lanes, PRs, and CTO updates. + + Recommended for PR summaries, CI explanations, and review follow-up across lanes. - - Add worker identities for recurring responsibilities, such as testing or PR review. + + Connect it when issues should drive lanes, PRs, and status updates. See [Linear](/integrations/linear). - - Start with: `Summarize the current project state and identify the highest-risk open work.` + + Create worker identities for recurring responsibilities such as testing or review. See [Workers](/cto/workers). + +Setup finishes without Linear, a model choice, or any workers — those connect later. The CTO is meant to be a daily chat surface first. + + +## Personality presets + +The preset shapes the CTO's communication style. The underlying operator doctrine and capability set are owned by ADE and stay fixed across presets — you're choosing tone, not rewriting the agent. + + + + Big-picture framing and trade-offs. + + + Measured, businesslike updates. + + + Pragmatic and execution-focused. + + + Relaxed, conversational tone. + + + Terse, low-noise replies. + + + Write your own personality overlay. + + + + +You can re-run the wizard any time from **CTO → Settings → Reset Onboarding**, and edit the persona and model from the identity editor without resetting anything. + + ## First useful prompts +Lead with planning and summarization before delegation — that's where the CTO earns its keep. + ```text -Look across active lanes and tell me what is ready for review. +Summarize the current project state and identify the highest-risk open work. ``` ```text @@ -40,11 +81,15 @@ Plan how to split this feature into reviewable lanes before anyone starts coding Read Linear issue ENG-142 and recommend the first lane to create. ``` + +Treat the CTO's first plan as a draft. Refine the split in chat until the lanes are small and independent, then approve before any worker starts coding. + + - - What the CTO is for. - - Manage delegated agent identities. + Manage the delegated agent identities the CTO assigns work to. + + + Connect Linear so the CTO can triage and route issues. diff --git a/cto/workers.mdx b/cto/workers.mdx index 03ad346ac..7b6f3b485 100644 --- a/cto/workers.mdx +++ b/cto/workers.mdx @@ -1,27 +1,66 @@ --- title: "Workers" -description: "Manage scoped agent identities that the CTO can use for delegated work." +description: "Workers are named agent identities the CTO delegates scoped work to — each with a role, model, budget, and activity history, running in its own lane." icon: "users" --- -Workers are agent identities with a role. The CTO can use them for focused tasks such as implementation, testing, review, or documentation. +**Workers** are named agent identities that the CTO can wake for delegated work. The CTO owns the team; each worker runs inside a lane with its own role, model settings, budget, and activity history. When the CTO splits a plan into lane-sized tasks, it hands each task to a worker, and they run in parallel under the CTO's coordination. + + ## What a worker has | Field | Meaning | |-------|---------| -| Name | Human-readable identity, such as `test-writer`. | -| Role | What kind of work the worker should do. | -| Provider and model | How the worker runs. | -| Budget | Monthly spend or usage boundary for that worker. | -| Activity | Recent tasks, sessions, and outcomes. | +| Name & role | A human-readable identity (e.g. `test-writer`) and a role: engineer, QA, designer, devops, researcher, or general. | +| Adapter & model | How the worker runs and which model it uses. | +| Budget | A soft monthly spend cap, tracked per worker and across the team. | +| Heartbeat | Whether the worker stays running or wakes only when called. | +| Activity | Recent runs, sessions, and outcomes in its feed. | + +## Create a worker + +The Team tab's two-step wizard makes adding a worker quick. + + + + Start from a template — backend engineer, frontend engineer, QA tester, devops, researcher, or custom. Each seeds a sensible role and capabilities. + + + Set the name, role, capabilities, model, and a monthly budget. Save persists the identity and records a config revision. + + -## When workers help + +Worker config is strict about secrets: raw API keys are rejected. Reference secrets as `${env:VAR_NAME}` so credentials never land in a saved worker config. + + +## Adapters + +A worker dispatches through exactly one of three adapter types. Anything that wraps an external runtime does so as a `process` adapter — there are no other types. -- A task should be split into several lane-scoped parts. -- You want a repeatable role, such as tester or reviewer. -- You need project-level coordination but focused execution. -- You want budget and activity visibility by responsibility. + + + Spawns the Claude CLI locally. + + + Spawns the Codex CLI locally. + + + A generic managed subprocess for a long-lived or out-of-tree worker runtime. + + + +## Budgets and heartbeats + + + + Each worker has a monthly cap tracked per worker and across the team. Nothing blocks execution when a cap is hit — the UI surfaces a warning chip so you can step in. + + + A worker with a heartbeat stays "always running"; with it off, the worker only comes to life when the CTO wakes it or a Linear workflow dispatches to it. + + ## Basic flow @@ -33,13 +72,26 @@ Workers are agent identities with a role. The CTO can use them for focused tasks Confirm lanes, worker roles, and validation expectations. - Watch active lanes and sessions from Work, Lanes, and History. + Each worker runs in its own lane. Watch active sessions and runs from Work, Lanes, and History. Inspect diffs, tests, proof, and PRs before merging. + + The CTO dispatching work to a team of worker agents + + -Workers are still coding agents. Review their output like any other contribution. +Workers are still coding agents. Review their output like any other contribution — nothing merges without your review. + + + + How the project-level operator plans and delegates. + + + Patterns for splitting work cleanly across agents. + + diff --git a/docs.json b/docs.json index c98f4e315..60013697b 100644 --- a/docs.json +++ b/docs.json @@ -10,11 +10,11 @@ "background": { "decoration": "grid" }, - "favicon": "/favicon.svg", + "favicon": "/favicon.png", "logo": { - "light": "/logo/light.svg", - "dark": "/logo/dark.svg", - "href": "https://github.com/arul28/ADE" + "light": "/logo/ade-wordmark.png", + "dark": "/logo/ade-wordmark.png", + "href": "https://ade-app.dev" }, "seo": { "metatags": { @@ -27,18 +27,17 @@ "navigation": { "tabs": [ { - "tab": "Get Started", - "icon": "rocket", + "tab": "Documentation", + "icon": "book-open", "groups": [ { - "group": "Welcome", + "group": "Start here", "icon": "hand-wave", "expanded": true, "pages": [ "welcome", "quickstart", - "key-concepts", - "architecture" + "key-concepts" ] }, { @@ -47,23 +46,10 @@ "pages": [ "getting-started/install", "getting-started/connect-provider", - "getting-started/project-setup", + "getting-started/open-project", "getting-started/first-lane", "getting-started/first-agent" ] - } - ] - }, - { - "tab": "App Guide", - "icon": "grid-2", - "groups": [ - { - "group": "Run", - "icon": "play", - "pages": [ - "tools/project-home" - ] }, { "group": "Lanes", @@ -72,114 +58,113 @@ "lanes/overview", "lanes/creating", "lanes/stacks", - "lanes/packs", - "lanes/environment", - "guides/multi-agent-setup" + "lanes/environment" ] }, { - "group": "Agent Chat", + "group": "Agent chat", "icon": "comments", "pages": [ "chat/overview", "chat/capabilities", - "chat/context" - ] - }, - { - "group": "Terminals", - "icon": "rectangle-terminal", - "pages": [ - "tools/terminals" + "chat/grid", + "chat/context", + "guides/multi-agent-setup" ] }, { - "group": "Files", - "icon": "file-code", + "group": "Work surfaces", + "icon": "window-restore", "pages": [ - "tools/files-editor" + "tools/files-editor", + "tools/terminals", + "tools/browser", + "tools/ios-simulator", + "tools/project-home" ] }, { - "group": "Graph", - "icon": "diagram-project", + "group": "Review & ship", + "icon": "code-pull-request", "pages": [ - "tools/workspace-graph" + "tools/review", + "tools/pull-requests", + "guides/stacked-prs", + "tools/conflicts", + "tools/workspace-graph", + "tools/history" ] }, { - "group": "Pull Requests", - "icon": "code-pull-request", + "group": "CTO & automation", + "icon": "crown", "pages": [ - "tools/pull-requests", - "tools/conflicts", - "guides/stacked-prs" + "cto/overview", + "cto/setup", + "cto/workers", + "tools/automations" ] }, { - "group": "History", - "icon": "clock-rotate-left", + "group": "Integrations", + "icon": "plug", "pages": [ - "tools/history" + "integrations/github", + "integrations/linear" ] }, { - "group": "CTO and Workers", - "icon": "crown", + "group": "Proof & computer use", + "icon": "camera", "pages": [ - "cto/overview", - "cto/setup", - "cto/linear", - "cto/workers" + "computer-use/overview", + "computer-use/setup", + "computer-use/proofs", + "computer-use/config" ] }, { - "group": "Mobile", + "group": "Mobile & terminal", "icon": "mobile-screen", "pages": [ - "tools/ios-companion" + "tools/ios-companion", + "tools/ade-code", + "tools/remote-machines" ] } ] }, { - "tab": "Settings", - "icon": "gear", + "tab": "Settings & dev guide", + "icon": "sliders", "groups": [ { - "group": "Settings Reference", - "icon": "sliders", + "group": "Settings", + "icon": "gear", "expanded": true, "pages": [ "configuration/settings", - "configuration/ai-providers" - ] - }, - { - "group": "Project Configuration", - "icon": "folder-tree", - "pages": [ - "configuration/overview", - "configuration/permissions" + "configuration/permissions", + "configuration/overview" ] }, { - "group": "Computer Use", - "icon": "desktop", + "group": "AI Connections", + "icon": "brain", "pages": [ - "computer-use/overview", - "computer-use/setup", - "computer-use/proofs", - "computer-use/config" + "configuration/ai-providers", + "ai-tools/claude-code", + "ai-tools/cursor", + "ai-tools/windsurf" ] }, { - "group": "AI Tool Integrations", - "icon": "wand-magic-sparkles", + "group": "For developers", + "icon": "code", "pages": [ - "ai-tools/claude-code", - "ai-tools/cursor", - "ai-tools/windsurf" + "reference/cli", + "architecture", + "reference/troubleshooting" ] } ] @@ -194,6 +179,7 @@ "expanded": true, "pages": [ "changelog", + "changelog/v1.2.7", "changelog/v1.2.6", "changelog/v1.2.5", "changelog/v1.2.4", @@ -238,6 +224,11 @@ ], "global": { "anchors": [ + { + "anchor": "Download", + "href": "https://github.com/arul28/ADE/releases/latest", + "icon": "apple" + }, { "anchor": "GitHub", "href": "https://github.com/arul28/ADE", @@ -251,7 +242,7 @@ "primary": { "type": "button", "label": "Download ADE", - "href": "https://github.com/arul28/ADE/releases" + "href": "https://github.com/arul28/ADE/releases/latest" } }, "contextual": { @@ -274,17 +265,17 @@ { "header": "Product", "items": [ - { "label": "Features", "href": "/lanes/overview" }, - { "label": "Download", "href": "https://github.com/arul28/ADE/releases" }, + { "label": "Download", "href": "https://github.com/arul28/ADE/releases/latest" }, + { "label": "Lanes", "href": "/lanes/overview" }, { "label": "Changelog", "href": "/changelog" } ] }, { - "header": "Resources", + "header": "Get started", "items": [ - { "label": "Documentation", "href": "/welcome" }, - { "label": "Quick start", "href": "/quickstart" }, - { "label": "App Guide", "href": "/tools/project-home" } + { "label": "Welcome", "href": "/welcome" }, + { "label": "Quickstart", "href": "/quickstart" }, + { "label": "Key concepts", "href": "/key-concepts" } ] }, { diff --git a/favicon.svg b/favicon.svg deleted file mode 100644 index d50ceedd0..000000000 --- a/favicon.svg +++ /dev/null @@ -1,5 +0,0 @@ - - - - - diff --git a/getting-started/connect-provider.mdx b/getting-started/connect-provider.mdx index 3f8b73de8..4106b3103 100644 --- a/getting-started/connect-provider.mdx +++ b/getting-started/connect-provider.mdx @@ -1,32 +1,59 @@ --- title: "Connect an AI provider" -description: "Add one working provider so ADE can run coding agents." +description: "Add one provider — by API key or your existing subscription — so ADE can run coding agents." icon: "key" --- -Open **Settings -> AI Providers**. ADE needs at least one verified provider before it can run agent chat, workers, CTO delegation, auto-titles, or AI summaries. +ADE runs the agents you already use. Connect at least one provider and you can start chats, workers, CTO delegation, auto-titles, and AI summaries. Bring your own API key, or sign in with a subscription you already pay for. -## Common choices + + Connect AI providers in ADE Settings + -| Provider | Best for | Setup | -|----------|----------|-------| -| **Claude / Claude Code** | Strong default for coding tasks and project reasoning | API key or authenticated `claude` CLI | -| **Codex** | OpenAI coding agent workflows | Authenticated Codex CLI or configured OpenAI access | -| **Cursor** | Cursor agent runs from inside ADE | Cursor API key | -| **OpenCode** | Local or OpenRouter-backed CLI workflows | OpenCode config and provider key | -| **OpenRouter / local providers** | Cost control or local experimentation | API key or local endpoint | +## The five agents + +Open **Settings → AI Providers** and connect whichever you use. Each runs against your lanes with live diffs and approval gates. + + + + Strong default for coding and project reasoning. API key or an authenticated `claude` CLI. + + + OpenAI's coding agent. Authenticated Codex CLI or configured OpenAI access. + + + Cursor agent runs from inside ADE. Cursor API key or signed-in CLI. + + + Factory's Droid agent, including AGI mode. Droid CLI or API key. + + + Local or OpenRouter-backed CLI workflows. OpenCode config and a provider key. + + + +One reaches dozens of models — Anthropic, OpenAI, Gemini, Qwen, and more — depending on the provider you connect. + + +
+ Anthropic + OpenAI + Gemini + Qwen +
+ ## Add and verify - Pick the provider you already use, or start with Claude if you are unsure. + Pick the one you already use, or start with Claude Code if you're unsure. - Paste the API key or make sure the provider CLI is installed and authenticated. + Paste an API key, or make sure the provider CLI is installed and signed in. - - ADE checks the provider and shows whether it can start sessions. + + Click **Verify** or **Refresh**. ADE checks the provider and confirms it can start sessions. Choose a default model for chat. You can override it per session later. @@ -34,12 +61,27 @@ Open **Settings -> AI Providers**. ADE needs at least one verified provider befo -Provider calls go from your machine to the provider. ADE does not proxy model requests through an ADE-hosted service. +Provider calls go from your machine straight to the provider. ADE does not proxy model requests through an ADE-hosted service. ## If verification fails -- Confirm the key is active and has model access. -- Restart ADE after installing a new CLI. -- Open a terminal and test the provider CLI directly. -- Check **Settings -> AI Providers** again and click **Refresh**. + + + - Confirm the key is active and has model access. + - Restart ADE after installing a new provider CLI. + - Open a terminal and run the provider CLI directly to confirm it's authenticated. + - Return to **Settings → AI Providers** and click **Refresh**. + + + +## Next + + + + Point ADE at the Git repository you want it to manage. + + + Per-provider setup, models, and defaults in detail. + + diff --git a/getting-started/first-agent.mdx b/getting-started/first-agent.mdx index 5cd6bf66e..f2aca830f 100644 --- a/getting-started/first-agent.mdx +++ b/getting-started/first-agent.mdx @@ -1,34 +1,43 @@ --- title: "Run your first agent" -description: "Start a lane-scoped chat, watch the agent work, and review the result." +description: "Start a lane-scoped chat, watch the tool calls, and review the diff." icon: "robot" --- -Start with Agent Chat. It is the fastest way to learn ADE because it shows the full loop: prompt, tool calls, file changes, terminal output, review, and commit. +Agent chat is the fastest way to learn ADE — it shows the whole loop: prompt, tool calls, file changes, terminal output, review, and commit. ## Start the chat - - Open the lane you created for this task. + + In **Work**, open a new chat. You can pick an existing lane or let ADE create one for the task. - - Start a new chat session in that lane. The session header should show the lane name. - - - Use the default provider or pick another verified provider from the model selector. + + Use the default, or choose any verified provider — Claude Code, Codex, Cursor, Factory Droid, or OpenCode — from the model selector. - Ask for one contained change. Avoid broad prompts like "clean up the whole app" for your first run. + Ask for one contained change. Skip broad prompts like "clean up the whole app" for your first run. - The transcript shows reads, edits, shell commands, and test output as the agent works. + The transcript streams reads, edits, shell commands, and test output as the agent works. Open **Files**, inspect every changed file, run tests if needed, then commit. + + Start a new agent chat + + + + Pick a provider and model for the chat + + + + Choose an existing lane or let ADE auto-create one + + ## First prompt ```text @@ -37,18 +46,22 @@ Add a GET /health endpoint that returns { "status": "ok" } and add one test for ## If the agent gets stuck -- Press **Stop** and ask for a shorter plan. -- Paste the exact test or build error back into the chat. -- Switch to a stronger model for the session. -- Keep the task inside the lane; do not move it to your primary checkout. + + + - Press **Stop** and ask for a shorter plan. + - Paste the exact test or build error back into the chat. + - Switch to a stronger model for the session. + - Keep the task inside the lane — don't move it to your primary checkout. + + -## After the task +## Next - - Review and edit the changed files. + + How chats, providers, and tool calls work. - Create a PR once the lane is ready. + Open a PR once the lane is ready. diff --git a/getting-started/first-lane.mdx b/getting-started/first-lane.mdx index c9b076c71..f65061a1a 100644 --- a/getting-started/first-lane.mdx +++ b/getting-started/first-lane.mdx @@ -4,7 +4,11 @@ description: "Create an isolated branch and worktree for your first agent task." icon: "code-branch" --- -A lane keeps agent work out of your primary checkout. Use one lane per task. +A **lane** is ADE's name for a git worktree — an isolated branch and working copy for one task. It keeps agent work out of your primary checkout, so you can run several tasks in parallel without colliding. Use one lane per feature, fix, or experiment. + + +Your repo root is already the **primary lane** — it always exists and is edit-protected. You don't pick a "lane type"; you simply add a new worktree lane for the task. This first one branches a fresh worktree off your default branch. + ## Create the lane @@ -13,16 +17,32 @@ A lane keeps agent work out of your primary checkout. Use one lane per task. Choose **Lanes** from the sidebar. - Give the lane a short task name, such as `add-health-endpoint` or `fix-login-copy`. + Give it a short task name, like `add-health-endpoint` or `fix-login-copy`. - - For your first lane, use your default branch, usually `main`. + + For your first lane, use your default branch — usually `main`. ADE creates a Git worktree under `.ade/worktrees/` and checks out a branch for the lane. + + Start a new lane from the Lanes tab + + + + Name a lane and choose its base branch + + +## Let ADE name it for you + +You don't have to create lanes by hand. Describe a task in chat and ADE spins up a fresh worktree, auto-named from the task — no stashing, no context switch. + + + Auto-create a git worktree from a task + + ## Good lane names | Good | Avoid | @@ -33,13 +53,13 @@ A lane keeps agent work out of your primary checkout. Use one lane per task. ## When the lane is ready -The lane should show a clean diff and no active sessions. Open it in **Work** to start chat or a terminal. +The lane should show a clean diff and no active sessions. Open it in **Work** to start a chat or a terminal. Start a small lane-scoped chat. - - Learn how lanes, stacks, and cleanup work. + + How lanes, stacks, and cleanup work. diff --git a/getting-started/install.mdx b/getting-started/install.mdx index e58b3121b..321dba2b2 100644 --- a/getting-started/install.mdx +++ b/getting-started/install.mdx @@ -1,50 +1,71 @@ --- title: "Install ADE" -description: "Download the macOS app, move it to Applications, and launch it." +description: "Download ADE for macOS — DMG or Homebrew — launch it, and run in guest mode with no account." icon: "download" --- +ADE is a native macOS app. Download it, drag it to Applications, and launch — no account required. You can be in a project in under a minute. + + + Add your first repository from the ADE welcome screen + + ## Requirements - - ADE ships as a macOS desktop app for Apple Silicon and Intel Macs. + + Apple Silicon or Intel. ADE ships as a signed, notarized macOS app. - Required. ADE uses branches and worktrees for lanes. + Required — ADE uses branches and worktrees to run lanes. - Needed for agent work. You can connect it after launch. + Needed to run agents. Connect it after launch — guest mode lets you explore first. ## Install - - - Open [GitHub Releases](https://github.com/arul28/ADE/releases) and download the latest ADE macOS release. - - - Open the DMG and drag **ADE.app** into `/Applications`. - - - Open ADE from `/Applications` or Spotlight. If macOS asks for confirmation, choose **Open**. - - +The fastest path is Homebrew. Prefer a download? Grab the DMG from GitHub Releases. + + + + ```bash + brew install --cask arul28/ade/ade + ``` + + This taps the ADE cask and installs the latest macOS build into `/Applications`. Update later with: + + ```bash + brew upgrade --cask ade + ``` + + + 1. Open [GitHub Releases](https://github.com/arul28/ADE/releases/latest) and download the latest ADE macOS `.dmg`. + 2. Open the DMG and drag **ADE.app** into `/Applications`. + 3. Launch ADE from `/Applications` or Spotlight. If macOS asks for confirmation, choose **Open**. + + + +## Launch and explore + +Open ADE and you land on the welcome screen. ADE starts in **guest mode** — no sign-up, no account — so you can add a repository and look around right away. Connect a provider whenever you're ready to run agents. -ADE stores project state inside each repository's `.ade/` directory and app preferences under your user Library. It does not require admin privileges. +ADE keeps itself current with a built-in auto-updater: it downloads new releases in the background and applies them on relaunch. Installed via Homebrew? Run `brew upgrade --cask ade` instead. -## First launch + +ADE is macOS-only today. A Windows build is paused — releases ship for macOS. + -After the app opens, continue with: +## Next - Verify Claude, Codex, Cursor, OpenCode, or another supported provider. + Add Claude Code, Codex, Cursor, Factory Droid, or OpenCode. - Choose the Git repository you want ADE to manage. + Point ADE at the Git repository you want it to manage. diff --git a/getting-started/open-project.mdx b/getting-started/open-project.mdx index d45d4eeb0..5c031249c 100644 --- a/getting-started/open-project.mdx +++ b/getting-started/open-project.mdx @@ -1,10 +1,14 @@ --- title: "Open your first project" -description: "Point ADE at a Git repository and let it create local project state." +description: "Point ADE at a Git repository — open a local folder or clone from GitHub — and let it create local project state." icon: "folder-open" --- -Use **Open Repository** on the welcome screen or press `Cmd+O`. Choose the root of a Git repository. If you choose a subfolder, ADE tries to find the repository root automatically. +Use **Open Repository** on the welcome screen or press `Cmd+O`. Choose the root of a Git repository, or clone one straight from GitHub. If you pick a subfolder, ADE finds the repository root automatically. + + + Open a local repository or clone from GitHub + ## What ADE creates @@ -19,7 +23,9 @@ On first open, ADE creates a local `.ade/` directory: secrets/ ``` -This directory contains local runtime state, lane worktrees, transcripts, proof, and credentials. It should normally be gitignored. +This holds local runtime state, lane worktrees, transcripts, proof, and credentials. It should normally be gitignored. + +Your repository root becomes the **primary lane** — it always exists and is edit-protected. Every other lane you add is a separate worktree under `.ade/worktrees/`, so agent work never touches your main checkout until you choose to merge it. Do not commit `.ade/` wholesale. It contains machine-local paths and state. If your project needs shared ADE defaults later, use the project configuration flow rather than committing local secrets or runtime files. @@ -35,7 +41,7 @@ The setup flow checks the basics: - Linear is available if your team uses it. - Optional mobile pairing can be configured later in Settings. -You can skip setup steps and return to them from **Settings**. +You can skip any step and return to it from **Settings**. ## After opening @@ -45,7 +51,7 @@ Create a lane before running your first agent. That keeps your primary checkout Start isolated work for a small task. - - Review what the onboarding flow checks. + + Make sure at least one agent is ready to run. diff --git a/getting-started/project-setup.mdx b/getting-started/project-setup.mdx deleted file mode 100644 index 335cb4bf8..000000000 --- a/getting-started/project-setup.mdx +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Project setup" -description: "What ADE checks when you open a repository for the first time." -icon: "wand-magic-sparkles" ---- - -Project setup is a convenience flow, not a gate. You can skip any step and configure it later in **Settings**. - -## Setup checklist - - - - ADE checks for Git and other useful local tools. Git is the important one because lanes use worktrees. - - - Connect or verify at least one provider so chats and workers can run. - - - Optional, but recommended if you want PR creation, CI status, review comments, and merge workflows inside ADE. - - - Optional. Connect Linear if you want issues linked to lanes, PRs, CTO planning, and follow-up notes. - - - Review project name, default branch, lane defaults, and any suggested process or test commands. - - - -## Where settings live - -Most configuration is local to your machine. Provider credentials and secrets stay out of Git. Project-specific defaults can be shared deliberately, but ADE keeps local runtime state under `.ade/`. - - - - See the main settings sections. - - - Understand local project state and shared defaults. - - diff --git a/guides/cto-linear-workflow.mdx b/guides/cto-linear-workflow.mdx deleted file mode 100644 index 97e8282d3..000000000 --- a/guides/cto-linear-workflow.mdx +++ /dev/null @@ -1,153 +0,0 @@ ---- -title: "Guide: CTO + Linear workflow" -sidebarTitle: "CTO + Linear Workflow" -description: "Connect the CTO agent to Linear for automated issue triage, task delegation, and status syncing." -icon: "graduation-cap" ---- - -The CTO agent can sync with your Linear workspace to read incoming issues, triage them, delegate work to AI agents, and update issue statuses as work progresses. This guide walks you through connecting Linear and configuring the CTO for automated workflows. - ---- - -## 1. Connect Linear - - - - Navigate to **Settings > Linear** in ADE. - - - Click **Connect Linear** and authorize ADE with your Linear workspace. ADE requests read/write access to issues, projects, and labels. - - - Choose the Linear team whose issues the CTO should monitor. You can change this later or add multiple teams. - - - -Once connected, ADE shows a sync status indicator in the Linear settings panel. - ---- - -## 2. Configure the CTO Agent - -Navigate to **CTO** in the sidebar to access the CTO agent's settings and chat interface. - - - - In **CTO Settings**, select which AI model the CTO uses. A capable model (Claude Sonnet or Opus) is recommended for triage and planning tasks. - - - - **Sync interval** — how often the CTO checks for new issues (default: 5 minutes) - - **Issue filters** — which issue states, labels, or priorities to include - - **Auto-triage** — whether the CTO should automatically triage new issues or wait for your instruction - - - Control how aggressively the CTO delegates work: - - **Ask first** — the CTO proposes a plan and waits for your approval - - **Auto-delegate** — the CTO assigns work to agents without asking (within budget) - - - -### Workflow targets - -The CTO can route incoming Linear issues to different execution surfaces: - -| Target | When to use | -|--------|------------| -| `employee_session` | Simple tasks a single worker can handle in one session | -| `worker_run` | Tasks that need a dedicated lane, durable status, and audit | -| `pr_resolution` | PR review comments or failing checks that need fixing | -| `review_gate` | Work that should be reviewed by the CTO before proceeding | - -The CTO chooses the target based on issue complexity, your delegation policy, and available budget. - ---- - -## 3. Triage Incoming Issues - -When new issues arrive in Linear, the CTO can triage them: - -- **Read the issue** — the CTO reads the title, description, and any comments -- **Assess complexity** — estimates effort and identifies which parts of the codebase are involved -- **Propose a plan** — suggests whether the issue should be a worker run, PR fix, review gate, or deferred -- **Assign priority** — updates the Linear issue with a recommended priority if auto-triage is enabled - -In Supervised mode, you review the CTO's triage in its chat interface before any work begins. In Auto-delegate mode, the CTO proceeds directly to delegation. - ---- - -## 4. Delegate to Worker Agents - -When the CTO decides to act on an issue, it: - - - - The CTO spawns a new lane for the issue, named after the Linear issue ID (e.g., `linear/ENG-142`). - - - A worker agent is launched in the new lane with context from the issue, the project pack, and any relevant code references. - - - The CTO tracks the worker's progress and reports status back to the Linear issue. Comments are added to the issue as work progresses. - - - -For larger issues, the CTO splits the work into dedicated lanes and worker runs. - ---- - -## 5. Status Syncing - -As work progresses, ADE keeps Linear updated: - -| ADE event | Linear update | -|---|---| -| Worker starts | Issue moves to **In Progress** | -| PR opened | Issue linked to the PR, comment added | -| Worker completed | Issue moves to **Done**, summary comment added | -| Worker failed | Issue flagged with a comment describing the failure | -| Intervention needed | Issue comment requesting human input | - -### Custom status mapping - -Configure status mappings in **Settings → Integrations → Linear**: - -| ADE state | Default Linear status | Configurable | -|-----------|----------------------|--------------| -| Worker started | In Progress | Yes | -| PR opened | In Review | Yes | -| Worker completed | Done | Yes | -| Worker failed | Blocked | Yes | -| Intervention needed | Blocked | Yes | - -You can also configure `activeStateTypes` (which Linear states trigger CTO attention) and `terminalStateTypes` (which states mean the issue is done) to match your team's Linear workflow. - ---- - -## 6. Review and Close - -When a worker completes: - -- The CTO posts a summary comment on the Linear issue with links to the PR and any artifacts -- The issue status is updated based on the outcome -- You can review the work in ADE's History view or PR panel, then close the issue in Linear - ---- - -## Tips - -- Start with **Ask first** mode until you trust the CTO's triage judgment. Switch to **Auto-delegate** once routing behavior matches your workflow. -- Use Linear labels to control routing — for example, label issues `ai-eligible` and filter the CTO to only triage those. -- Keep architecture and convention docs current so the CTO can inspect the repo and make better triage decisions. - ---- - -## Next Steps - - - - Understand the CTO's role and org chart model. - - - Learn how CTO workers pick up delegated tasks and report progress. - - diff --git a/guides/multi-agent-setup.mdx b/guides/multi-agent-setup.mdx index ecae6affa..b4a9e1deb 100644 --- a/guides/multi-agent-setup.mdx +++ b/guides/multi-agent-setup.mdx @@ -1,16 +1,22 @@ --- title: "Multi-agent setup" -description: "Run several agents safely by giving each task its own lane and review path." +description: "Run several agents safely by giving each task its own lane, watching for collisions, and choosing the grid when you want to compare attempts." icon: "users" --- -The safest multi-agent setup is simple: one lane per task, one clear goal per agent, and a review pass before merge. +The safest multi-agent setup is simple: one lane per task, one clear goal per agent, and a review pass before merge. Isolation is what keeps parallel agents from writing over each other — give each its own worktree and the collisions disappear. -## Recommended pattern + + Launching agents in the background and supervising them + + +## One lane per task + +Every lane is its own git worktree — its own branch, files, and sessions. That isolation is the whole game: two agents in two lanes can't touch each other's working tree, so they run in parallel without stashing, rebasing, or fighting over the same files. - Turn a large goal into small lane-sized tasks. + Turn a large goal into small, independent, lane-sized tasks. Name lanes after the outcome, not the agent. @@ -19,34 +25,59 @@ The safest multi-agent setup is simple: one lane per task, one clear goal per ag Keep each prompt scoped to that lane's goal. - Use Work for live sessions and Graph for branch relationships. + Use Work for live sessions and Graph for branch relationships and merge risk. - Inspect each diff, run tests, and create PRs separately. + Inspect each diff, run tests, and open PRs separately. ## Good task splits +A clean split has slices that touch different files and can be reviewed on their own. + | Goal | Better split | |------|--------------| | "Improve onboarding" | Copy fixes, provider validation, first-run UI, tests. | -| "Fix checkout bugs" | Repro failing case, patch backend, patch UI, add regression tests. | +| "Fix checkout bugs" | Repro the failing case, patch backend, patch UI, add regression tests. | | "Ship mobile sync polish" | Desktop status, iOS display, reconnect behavior, docs. | -## Keep agents from colliding +## Watch for collisions + +Parallel agents stay safe as long as their work doesn't overlap. Most collisions come from scope creep, not from the tool. -- Do not send two agents into the same lane for unrelated work. -- Avoid broad prompts that invite repo-wide edits. -- Use stacked lanes when one task depends on another. +- Don't send two agents into the same lane for unrelated work. +- Avoid broad prompts that invite repo-wide edits — keep each agent narrow. +- Use [child lanes](/lanes/stacks) when one task genuinely depends on another, rather than racing them. - Merge parent work before rebasing children when possible. -- Use History to understand what each session changed. +- Use History to see exactly what each session changed. + +## Grid vs. separate lanes + +Both run agents in parallel, but they answer different questions. + + + + Same task, several models — race a narrow, well-specified change and keep the best diff. Each tile is a full chat. + + + Different tasks — give each its own worktree so broad, multi-step work never competes for the same files. + + + + + Grid view with multiple agents running at once + + + +Use the grid for narrow, well-specified work where comparing a few attempts is cheap. For broad, multi-step features, give each agent its own lane instead. + - - Isolate each task. + + Run several agents at once and compare side by side. - - See how parallel work relates. + + Isolate each task in its own worktree. diff --git a/guides/stacked-prs.mdx b/guides/stacked-prs.mdx index d8e411899..839b40ea3 100644 --- a/guides/stacked-prs.mdx +++ b/guides/stacked-prs.mdx @@ -1,68 +1,78 @@ --- title: "Guide: stacked PRs" sidebarTitle: "Stacked PRs" -description: "Create, review, and land a chain of dependent PRs with ADE lanes." +description: "Land a stack of dependent PRs in order using child lanes — small, ordered diffs that build on each other." icon: "layer-group" --- -Use stacked PRs when one feature is too large for a single review but each slice depends on the previous slice. +Use stacked PRs when one feature is too large for a single review but each slice depends on the previous one. Each lane in the stack becomes its own PR, targeting the lane below it instead of `main` — so reviewers see small, ordered diffs. + +ADE builds the stack out of **child lanes**: a lane branched off another lane instead of `main`. The child-lane chain *is* the PR stack. + + + A stacked PR targeting its parent lane's branch + ## 1. Create the base lane -Create a lane from `main` for the first slice of work. Commit the foundation there. +Create a lane from `main` for the first slice of work and commit the foundation there. -## 2. Create child lanes +## 2. Stack child lanes -Select the base lane and create a child lane for the next slice. Repeat only as needed. +Select the base lane and create a **child lane** for the next slice — it branches off the base lane, not `main`. Repeat only as far as the dependency is real. ```text main - feature-auth-models - feature-auth-ui - feature-auth-tests + feature-auth-models (base lane, off main) + feature-auth-ui (child of the base lane) + feature-auth-tests (child of feature-auth-ui) ``` -## 3. Open PRs + + The worktree graph showing a child-lane stack + + +## 3. Open PRs in order -Open PRs from the bottom of the stack upward: +Open PRs from the bottom of the stack upward. Each PR targets the branch of the lane it was stacked on. -- Base lane targets `main`. -- First child targets the base lane branch. -- Next child targets the first child branch. +- The base lane targets `main`. +- The first child lane targets the base lane's branch. +- The next child lane targets the first child's branch. ADE keeps this relationship visible in Lanes, Graph, and PRs. -## 4. Review in order +## 4. Review bottom-up -Review the base PR first. Child PRs will be easier to understand once the parent is approved. +Review the base PR first. Each child PR is easier to understand — and to merge — once its parent is approved. ## 5. Land the stack - Land the first PR into `main`. + Land the bottom PR into `main`. - + Rebase or retarget the next PR so it now builds on `main`. - - Continue up the stack until all slices are merged. + + Continue child by child until every slice is merged. ## Tips -- Keep each PR small enough to review independently. -- Avoid deep stacks unless the dependency is real. -- Use Graph to see the chain. -- Run tests again after rebasing a child. -- If a child becomes independent, split it into a sibling lane. +- Keep each PR small enough to review on its own. +- Avoid deep stacks unless the dependency between slices is real. +- Use the worktree graph to see the chain and its merge order. +- Re-run tests after rebasing a child lane. +- If a child lane stops depending on its parent, split it into a sibling lane off `main`. - - Understand the lane model. + + The lane model behind a stack — child lanes in detail. - Review and merge from ADE. + Create, review, and merge PRs from ADE. diff --git a/index.mdx b/index.mdx deleted file mode 100644 index 04dbb8a14..000000000 --- a/index.mdx +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: "ADE - Agentic Development Environment" -description: "Run AI coding agents in parallel from one local-first desktop control plane." ---- - -ADE helps you run multiple coding agents without losing track of branches, files, chats, terminals, PRs, and proof. It is a desktop app for coordinating real work in real repositories. - - - - Learn what ADE does and follow the shortest setup path. - - - Install ADE, open a repo, create a lane, and run one agent task. - - - Browse the main surfaces: Run, Lanes, Work, Files, PRs, CTO, and Mobile. - - - See what shipped in recent desktop and iOS releases. - - - -## What ADE gives you - - - - One isolated git worktree per task, with its own branch, terminals, chat sessions, and environment. - - - Chat with Claude, Codex, Cursor, or OpenCode inside a lane and watch every tool call, command, and file change. - - - Create PRs, inspect CI and reviews, simulate conflicts, and merge work from inside ADE. - - - Coordinate larger tasks through a project-level agent and scoped worker agents. - - - Capture screenshots, recordings, traces, and logs as evidence tied to chats, PRs, Linear issues, or lanes. - - - Pair your phone to follow work and act on updates while away from the Mac. - - diff --git a/integrations/github.mdx b/integrations/github.mdx new file mode 100644 index 000000000..f85cde2aa --- /dev/null +++ b/integrations/github.mdx @@ -0,0 +1,62 @@ +--- +title: "GitHub" +description: "Connect GitHub so ADE can open, review, and merge pull requests for your lanes — without leaving the app." +icon: "github" +--- + +Connecting GitHub turns a finished lane into a reviewable, mergeable pull request inside ADE. Once connected, ADE opens PRs from your lanes, pulls in CI status and review comments, and merges — so you never leave for a browser tab. + + + + Turn a lane's branch into a GitHub PR in a click, with the title and body pre-filled. + + + Read checks, reply to review threads, and merge — including auto-merge when the checks go green. + + + +## Connect GitHub + +Open **Settings → Integrations → GitHub** and authenticate. ADE stores the token in your machine's encrypted credential store — it's never written into project files or committed. + + + + Authenticate in the GitHub section of Settings. A token that can read and write the repositories you work in is all ADE needs. + + + ADE probes access to the active repository and reports a single connection state (below). Hit **Refresh** after changing permissions on github.com to re-check immediately. + + + +## Connection states + +ADE reduces GitHub auth to one "is it usable here" signal, shown the same way in Settings and in the app banner. + + + + The token is valid and can reach the active repository. PR creation, CI, comments, and merge are all available. + + + The token authenticates, but can't reach the active repo — common with fine-grained tokens missing that repository. Grant it access and refresh. + + + No token, or the token can't identify a user. PR features stay disabled until you connect. + + + + +**Fine-grained tokens** are only considered connected once a repository probe passes — it's the one reliable check that the token can actually act on your repo. If Settings shows Limited access, add the active repository to the token's allowed list. + + + +GitHub is optional. ADE runs fine without it — you just won't get in-app PRs until it's connected. Everything else (lanes, chat, diffs, history) works regardless. + + + + + Create, review, and merge PRs once GitHub is connected. + + + Link issues to lanes and PRs, and let merges close them. + + diff --git a/integrations/linear.mdx b/integrations/linear.mdx new file mode 100644 index 000000000..f7d6f120b --- /dev/null +++ b/integrations/linear.mdx @@ -0,0 +1,114 @@ +--- +title: "Linear" +description: "Linear is a first-class, two-way integration owned by the CTO — attach issues to lanes and chats, sync status, and run issues end to end with workflow presets." +icon: "layers" +--- + +Linear is a first-class, two-way integration, owned by the CTO. Connect it when your planning and review loop already runs through Linear issues — then you can attach issues to lanes and chats, keep status in sync, and let the CTO triage an issue, delegate the work, open a PR, and close the issue back out. + + + +## What the integration does + + + + Connect a Linear issue to a lane or chat. ADE derives the branch name and attaches the issue as context. + + + Connected lanes prefix commits with the issue reference and seed the PR title and body so Linear links the work back. + + + As work moves, ADE updates the issue and posts progress and closeout notes. + + + Define workflows that dispatch a matching issue to a session, a worker, or a PR resolution — automatically. + + + +## Connect Linear + +You can connect from **CTO → Workflows** or **Settings → Integrations**. There are two paths: + + + + The primary path. ADE opens a Linear sign-in and stores the resulting token, refreshing it for you. The sign-in session is short-lived, so finish it promptly. + + + The alternative — paste a key that doesn't expire. Good for headless or automated setups. + + + Pick which Linear projects ADE watches and which states count as active vs. terminal. + + + Attach an issue to a lane and confirm it shows up in the lane and in CTO context. + + + + + Connecting a Linear workspace to ADE + + + +Until a token is stored, the whole integration stays dormant — nothing polls, nothing binds, no background work runs. Connecting is a deliberate act. + + +## The CTO-driven Linear loop + +Once Linear is connected, a workflow can run a whole issue end to end. The shape is the same every time. + + + + A new or updated issue is matched against your workflows by trigger — assignee, labels, team, project, priority, or state transition. + + + The matched workflow dispatches the work as an employee session, a worker run, or a PR resolution, with the issue attached as context. + + + The agent implements in its lane, then commits, pushes, and opens a PR — linked back to the issue. + + + On completion, ADE transitions the issue's state, posts a summary comment, and attaches proof artifacts. + + + +### Workflow targets + +A workflow dispatches an issue to one of four targets. Workflows can also chain stages — a worker run feeding into a PR resolution, say. + +| Target | What it launches | +|--------|------------------| +| Employee session | A CTO or employee chat with the issue as context. | +| Worker run | A delegated worker run in a fresh lane. | +| PR resolution | A PR-focused resolver session. | +| Review gate | A human review pause — no work launched until you decide. | + + +The CTO owns Linear issue intake. [Automations](/tools/automations) can react to Linear events for their own context, but they never duplicate this routing — the CTO is the canonical path. + + +### Human review and delegation + +Workflows can insert a review gate so a run pauses for your approval before it continues or lands a PR. And if a workflow can't resolve an issue's assignee to a known worker, the run waits in **awaiting delegation** with a dropdown to assign it — it never dispatches to an invalid target. + +## Good CTO prompts with Linear + +```text +Read ENG-142 and propose a lane plan with acceptance criteria. +``` + +```text +Summarize what changed on the PR linked to ENG-142 and draft a Linear update. +``` + +```text +Which Linear issues are blocked by current PR or CI state? +``` + + + + Pick a persona and model, connect GitHub and Linear, and add workers. + + + Manage the scoped agents that run worker-target Linear workflows. + + diff --git a/introduction.mdx b/introduction.mdx deleted file mode 100644 index a0be0046a..000000000 --- a/introduction.mdx +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Introduction to ADE" -description: "A concise overview of ADE's current desktop, agent, PR, and mobile surfaces." -icon: "book-open" ---- - -ADE is a macOS desktop app for coordinating AI coding work across a Git repository. It gives each task a lane, each lane a clear record of chats and terminal sessions, and each finished change a path into review. - - - - Install ADE, connect a provider, open a repo, create a lane, and run one task. - - - Lanes, Work, chats, CTO, workers, proof, PRs, and iOS pairing in one page. - - - See how desktop, the ADE runtime, CLI, iOS, and project state fit together. - - - Explore the main ADE surfaces by workflow. - - - -## Why it exists - -AI agents are useful one at a time. They get harder to trust when several are working at once. ADE gives that parallel work a structure: - -- Lanes isolate code changes by task. -- Work sessions keep chats and terminals visible. -- Files and PRs make review concrete. -- Graph and History explain how branches and sessions relate. -- CTO and workers help with larger coordination. -- Proof artifacts and iOS pairing make work easier to verify and follow. - -## What ADE is not - -ADE is not a hosted build service, a replacement Git remote, or a generic docs portal. It is a local-first app that runs on your Mac and uses your existing repository, providers, GitHub account, and optional Linear workspace. diff --git a/key-concepts.mdx b/key-concepts.mdx index db21d3253..5b9a2a044 100644 --- a/key-concepts.mdx +++ b/key-concepts.mdx @@ -20,7 +20,7 @@ ADE has a small set of ideas. Learn these and the rest of the app becomes easier ## Lane -A lane is ADE's unit of parallel work. It is a Git branch in an isolated worktree, usually under `.ade/worktrees//`. Agents, terminals, diffs, tests, and PRs are scoped to that lane. +A lane is ADE's name for a git worktree — its unit of parallel work. It is a Git branch in an isolated working copy, usually under `.ade/worktrees//`. Agents, terminals, diffs, tests, and PRs are all scoped to that lane. Use one lane for one feature, bug fix, experiment, or review thread. If the work grows, split it into another lane or stack a child lane on top of it. @@ -32,7 +32,7 @@ Work is where active execution happens. A Work session can be a chat, a terminal Agent chat is a conversation with a coding agent inside a lane. The agent can read files, edit files, run shell commands, inspect diffs, create commits, and help open PRs. Tool calls and results stay in the transcript. -Provider support depends on what you have configured, but the main paths are Claude, Codex, Cursor, and OpenCode. +Provider support depends on what you have configured, but the agent paths are Claude Code, Codex, Cursor, Factory Droid, and OpenCode. ## CTO diff --git a/lanes/creating.mdx b/lanes/creating.mdx index 787de2a46..281801083 100644 --- a/lanes/creating.mdx +++ b/lanes/creating.mdx @@ -1,47 +1,150 @@ --- title: "Create and manage lanes" -description: "Create lanes from a branch or another lane, then rename, archive, or delete them when the work is done." +description: "Every way to start a lane — new worktree, child lane, imported branch, or attached external worktree — plus rename, archive, and delete." icon: "plus" --- -Create a lane whenever a task deserves its own branch and review path. +Your repo root is always the **primary lane** — it exists from the moment you open the project, and it can't be deleted or restacked. Every *other* lane is a git worktree you create for a single task, isolated under `.ade/worktrees/`. You never pick a "lane type"; what varies is **how** you bring the new lane into being. -## Create a lane + + The New lane button in the Lanes view + + +## The four ways to create a lane + + + + Branch a fresh worktree from your default branch — or any other branch. The default, and the safest place for agent work. + + + Branch a lane off another lane instead of `main` to build dependent work as a stack. ADE calls these **child lanes**. + + + Pull a branch you already have — local or remote — into a worktree ADE manages. + + + Already made a `git worktree` outside ADE? Attach its path and ADE tracks it without ever moving or cleaning it. + + + +## New worktree off a branch + +This is the default path. Open the **Create lane** dialog, name the task, and choose what to branch from. - - Click **New lane** from the Lanes view. + + Click **New lane** in the Lanes view. - Use a short outcome name like `fix-auth-redirect` or `add-health-endpoint`. + Use a short, outcome-shaped name like `fix-auth-redirect` or `add-health-endpoint`. The name becomes the branch and the worktree folder slug; ADE also picks an unused accent color for the lane. - - Start from the primary branch, an existing branch, or another lane when creating stacked work. + + By default ADE branches from your default branch. Open the branch picker to start from a specific branch instead. - ADE creates the worktree and shows the lane in the list. + ADE runs `git worktree add`, checks the new branch out under `.ade/worktrees/`, and the lane appears in the list. -## Attach an existing worktree + + Naming a lane and choosing its base branch + + + +The branch picker filters as you type and shows each branch's last-commit author and date. Branches with an open pull request carry a **PR pill** (`#NNN`, dimmed for drafts) so you can tell at a glance what's already in review. + + +### Auto-create from a task or Linear issue + +You don't have to fill in the dialog by hand. Hand ADE a task — or connect a Linear issue — and it derives the branch name, names the lane, and attaches the issue as context so the agent starts with the right spec. + + + + +Connecting a Linear issue derives the branch name from the issue identifier and title (`IDENT-title-slug`). ADE refuses to create the lane if that branch already exists locally or on the remote, so you don't accidentally collide with existing work. + + +## Child lane (stacked) + +To build on top of work that hasn't merged yet, create a **child lane**: its branch is based on the parent lane's branch instead of `main`. Select the parent lane, choose **New child lane**, and the chain forms automatically. The full review flow — stacked PRs and rebase propagation — lives in [Stack lanes](/lanes/stacks). + +## Import an existing branch + +Have a branch already, local or remote, that you want ADE to manage as a worktree? Use the **import existing branch** path inside the Create lane dialog. It swaps the dialog body for the branch picker; pick a branch and ADE creates a managed worktree checked out to it. + + +The same picker that backs new worktrees powers import — search by name, filter to your own branches (`author:me`), or jump straight to a PR number (`#NNN`). The PR pills come from GitHub and are fail-soft: if the PR lookup errors, the picker still works, just without pills. + + +## Attach an external worktree -If you already created a Git worktree outside ADE, attach it from the lane actions. ADE tracks the lane but does not move the directory. +If you created a `git worktree` outside ADE, attach its path from the lane actions. ADE records the lane and tracks its status, but never moves or cleans the directory — deleting an attached lane only removes ADE's row, leaving your files in place. + + +If you later want ADE to own an attached worktree (and eventually auto-clean it), use **adopt** to move it under `.ade/worktrees/` and promote it to a managed lane. + + +## Rescue uncommitted work + +Started editing in the wrong place? ADE can lift uncommitted changes into a fresh child lane — it stashes the work in the source worktree and applies it in the new lane, then rolls back cleanly if the apply fails. This is the "rescue uncommitted work" path; it needs the source to have no staged changes and no in-progress merge or rebase. + +## Create a lane from a commit + +In the **History** tab, the **Create lane here** action on any commit branches a new lane starting from exactly that commit, instead of from a branch head. ADE verifies the ref and uses the resolved commit as the worktree's start point. ## Rename, archive, or delete +Open a lane's manage dialog to change it once work is underway or done. + + + The manage button on an existing lane + + | Action | Use it when | |--------|-------------| -| Rename | The task name is unclear. This changes ADE metadata, not necessarily the Git branch name. | -| Archive | The work may be useful later but should leave the active list. | -| Delete | The worktree is no longer needed. Commit or stash anything important first. | +| **Rename** | The task name is unclear. This updates ADE's lane metadata. | +| **Recolor** | You want a different accent dot. Colors already used by other active lanes are disabled. | +| **Archive** | The work may matter later but should leave the active list. The worktree stays on disk and **unarchive** brings it back. | +| **Delete** | The lane is done. This tears the lane down — see below. | + + + The rename, archive, and delete options for a lane + + +### What delete tears down + +Delete isn't just `rm -rf`. ADE runs an ordered teardown and shows live progress for each step: it cancels auto-rebase, stops the lane's processes, terminals, and file watchers, cleans up lane environment resources, releases the lane's leased port range, removes the git worktree, and only then clears ADE's rows. You can optionally also delete the local branch (and the remote branch). Before you confirm, ADE surfaces a preflight check — dirty files, unpushed commits, running processes, and whether a remote branch exists. -Deleting a managed worktree can remove uncommitted changes. ADE warns before destructive cleanup, but review the lane status first. +Deleting a managed worktree removes its working directory, including uncommitted changes. ADE warns you about dirty state and unpushed commits first, but commit or push anything you want to keep before you confirm. Once a delete starts it runs to completion — it can't be cancelled. ## Good cleanup habits -- Archive stalled experiments instead of keeping every lane active. -- Delete lanes after their PRs merge and follow-up work is complete. +- Archive stalled experiments instead of leaving every lane active. +- Delete lanes once their PRs merge and follow-up work is done — this returns the port range to the pool. - Keep lane names tied to outcomes, not model names. -- Use History if you need to find what happened in a deleted or archived lane. +- Use the History tab to find what happened in a deleted or archived lane. + + + + Every lane action is also available from the `ade` CLI and inside `ade code`: + + ```bash + ade lanes list --text # list lanes in the active project + ade lanes create "fix-checkout-flow" # branch a new worktree lane + ade lanes delete --force # tear down a merged or abandoned lane + ``` + + Run `ade lanes --help` to see every command and flag. In `ade code`, the `/new lane` and `/lane delete` slash commands drive the same paths. + + + + + + How lanes isolate work and sync across surfaces. + + + Build child-lane chains and reviewable stacks. + + diff --git a/lanes/environment.mdx b/lanes/environment.mdx index 0221747a0..c08640827 100644 --- a/lanes/environment.mdx +++ b/lanes/environment.mdx @@ -1,44 +1,84 @@ --- -title: "Lane environment" -description: "Ports, environment variables, startup commands, and preview links for lane-scoped work." +title: "Lane runtime" +description: "Each lane can be a full parallel dev environment — its own port range, .localhost hostname, OAuth callback routing, and optional env init. Advanced, and automatic for most." icon: "server" --- -Each lane can have its own runtime environment. This keeps parallel tasks from fighting over ports, credentials, and local state. - -## What can vary by lane - -| Area | Example | -|------|---------| -| Port | Lane A uses `3001`, lane B uses `3002`. | -| Environment variables | A lane points at a test database or feature flag. | -| Startup command | A lane starts `npm run dev` or another local server. | -| Preview URL | A clickable local URL opens the lane's running app. | - -## Basic setup - - - - Open the lane that needs custom runtime settings. - - - Add only the variables or command overrides that are specific to this lane. - - - Use Run or the lane terminal to start the app. - - - Open the preview URL and make sure it points at the selected lane. - - - -## Keep it simple - -- Prefer project defaults until a lane truly needs an override. -- Never paste production secrets into lane settings. -- Use clear variable names and document unusual overrides in the lane prompt. -- Stop unused lane processes so ports return to the pool. +Worktree isolation already keeps each lane's files, branch, and git operations separate. **Lane runtime** isolation goes further: it makes a lane a complete parallel dev environment, so two agents can each run the app — with its own ports, its own preview URL, and its own auth — without colliding. -Agents inherit the lane environment when they run commands. If a test depends on a lane-specific variable, mention that in the prompt. +This is advanced and mostly automatic. ADE leases ports and routes previews for you; most users never open a single setting here. Reach for the manual pieces only when a lane needs custom environment setup. + +## What's isolated per lane + + + + Each lane gets its own non-overlapping range of ports, leased automatically, so lanes never fight over `3000`. + + + A `.localhost` hostname proxies to the lane's dev server and opens as a clickable preview. + + + A single callback URL is routed back to the correct lane, so multi-lane sign-in flows work side by side. + + + Optional per-lane setup — env files, Docker services, dependency installs, copy and mount paths. + + + +## Ports and previews are automatic + +When you create a lane, ADE leases it a port range and can route a `.localhost` hostname to whatever your dev server binds inside that range. Start your app in the **Run** tab or a lane terminal, and the preview URL resolves to that lane's server. Because browsers scope cookies by hostname, `feat-auth.localhost` and `bugfix.localhost` never share a session — auth isolation comes for free. + +The **Run** tab's lane runtime bar shows the live state at a glance: a health dot, the responding port, proxy and preview status, and the OAuth callback URL for the selected lane. + + +Stop a lane's dev server when you're done with it, or delete the lane — both return its leased ports to the pool. If a lane ever flaps unhealthy on a slow cold start, the health bar settles once the server finishes binding. + + +## Per-lane environment init + +For lanes that need more than a running server, ADE can run an **env-init** sequence when the lane is created and show each step's progress right inside the create dialog. Every step validates its paths against the worktree root, so setup can't escape the lane. + + + + Env init runs in order, and each step is optional: + + | Step | What it does | + |------|--------------| + | **Env files** | Copy or template `.env` files with lane-specific substitutions (port, hostname, keys). | + | **Docker** | Start lane-specific Docker Compose services. | + | **Dependencies** | Run an install command from an allowlist (`npm`, `yarn`, `pnpm`, `pip`, `bundle`, `cargo`, `go`, `bun`, and a few more). Anything outside the list is rejected. | + | **Mount points** | Configure runtime mount points for agent profiles and context. | + | **Copy paths** | Copy non-template files from the project root into the worktree. | + + Each step reports `pending → running → done` (or `failed`) with a duration, so you can watch the lane bootstrap. + + + Rather than configure env init lane by lane, package it once as a **template** — a complete init recipe plus an optional setup script. Manage templates in **Settings → Lane Templates**, set a default, and new lanes pick it up. The setup script can carry platform-specific variants (Unix vs. Windows commands) and expose the primary worktree's path to its commands. + + + - **Run tab** — the lane runtime bar (health, port, proxy, preview, OAuth) and process dashboards. + - **Settings → Proxy & Preview** — start/stop the proxy and configure OAuth redirect. + - **Settings → Lane Templates** — manage reusable init recipes and the default template. + - **Settings → Diagnostics** — the global health view across lanes. + + + +## Health and fallback + +ADE aggregates port, proxy, and process signals into a per-lane health status (`healthy`, `degraded`, `unhealthy`, `unknown`) and surfaces fixes — reassign a conflicting port, restart the proxy, re-init env. If isolation itself fails, ADE prompts you to enable **fallback mode** for that lane rather than switching silently, because fallback drops the per-hostname cookie isolation and that's a contract worth opting into deliberately. + + +Never paste production secrets into lane env files or templates. Lane runtime is for local, disposable dev environments — point lanes at test databases and feature flags, not live credentials. + + + + + Start dev servers, run tests, and watch lane runtime health. + + + How lanes isolate work and sync across surfaces. + + diff --git a/lanes/overview.mdx b/lanes/overview.mdx index 7b7367d30..13f23d6e6 100644 --- a/lanes/overview.mdx +++ b/lanes/overview.mdx @@ -1,70 +1,123 @@ --- title: "Lanes" -description: "Use lanes to isolate parallel agent work in separate Git worktrees." +description: "A lane is ADE's name for a git worktree — one isolated branch and working copy per task, so agents work in parallel without colliding." icon: "code-branch" --- -A lane is one task's workspace. It has its own branch, worktree, sessions, diff, and PR link. Lanes let several agents work in the same repository without writing over each other. +A **lane** is ADE's name for a git worktree: an isolated branch and working copy for a single task. Each lane has its own files, branch, chat and terminal sessions, processes, diff, and PR — so several agents can work in the same repository at once without writing over each other or your main checkout. - - - Each worktree has its own files and branch. + + Auto-create a git worktree from a task + + +## The primary lane vs. your lanes + +When you open a repository, your existing checkout — the repo root — becomes the **primary lane**. It always exists and can't be deleted or restacked. Agents *can* work in it, but it's your real working tree, so the safer habit is to leave the primary lane alone and do agent work in fresh lanes. + +Everything else is a lane you create. Each new lane is its own git worktree under `.ade/worktrees/`, completely isolated from the primary checkout and from other lanes. + + +You don't pick a "lane type" — the primary lane is just your repo root, and every other lane is a worktree. What differs is **how** you bring a lane into being. + + +## Ways to create a lane + + + + Branch a fresh worktree from your default branch — or any other branch. This is the default, and the safest place for agent work. - - Chats and terminals run in the selected lane. + + Branch a lane off another lane instead of `main` to build dependent work as a stack. ADE calls these **child lanes**. - - A lane can be committed, pushed, and turned into a PR. + + Pull a branch you already have — local or remote — into a managed worktree, PR pills and all. + + + Already made a `git worktree` outside ADE? Attach its path and ADE tracks it without ever moving or cleaning it. -## Lane types +## The same lanes, everywhere + +Lanes sync across every surface. Start one on the desktop, continue it in the terminal, check on it from your phone. -| Type | Use it when | -|------|-------------| -| **Primary** | You need to inspect or run commands in the repository root. Be careful: agents write to the main checkout here. | -| **Worktree** | You are doing normal agent work. This is the default and safest choice. | -| **Attached** | You already have an external worktree and want ADE to track it. | + + + + Lanes on the desktop + + + + + Lanes in ade code + + + + + Lanes on iPhone + + + -## Common actions +## What's isolated to a lane + +A lane is more than a branch — it's a full parallel workspace. + + + + A dedicated worktree and branch. Stashes, rebases, and merges stay local to the lane. + + + Chats, terminals, and CLI sessions run scoped to the lane's worktree. + + + Dev servers and tests get their own port range and preview, so lanes don't fight over `3000`. + + + A clear diff, conflict risk, and a PR link — review and ship each lane on its own. + + + +## The lane lifecycle - Start from the default branch or from another lane when building stacked work. + Branch a worktree from your default branch, stack a child lane, import a branch, or attach an external worktree. - Open chat, terminals, Files, or Run scoped to the lane. + Open chat, terminals, Files, or Run — all scoped to the lane. Inspect the diff, tests, proof, History, and conflict risk. - Commit, push, create a PR, merge, archive, or delete the lane. + Commit, push, open a PR, merge, then archive or delete the lane. -## Stacked lanes - -A stacked lane is based on another lane instead of `main`. - -```text -main - auth-base - auth-ui - auth-tests -``` + + The worktree graph + -Use stacks when one large change is easier to review as several smaller PRs. ADE keeps the relationship visible in Lanes, Graph, and PRs. + + + Every lane action is also available from the `ade` CLI and `ade code`: -## Cleanup + ```bash + ade lanes list --text # list lanes in the active project + ade lanes create "fix-checkout-flow" # branch a new worktree lane + ade lanes delete --force # tear down a merged or abandoned lane + ``` -Archive lanes you may need later. Delete lanes when the branch is merged or abandoned and you are done with the worktree. ADE asks for confirmation before removing managed worktrees. + Run `ade lanes --help` to see every flag. + + - More detail on lane creation and cleanup. + Every way to start a lane, in detail. - - Work with branch chains and reviewable stacks. + + Build child-lane chains and reviewable stacks. diff --git a/lanes/packs.mdx b/lanes/packs.mdx deleted file mode 100644 index 06f045c9d..000000000 --- a/lanes/packs.mdx +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: "Lane context" -description: "How ADE keeps each agent focused on the selected lane and the artifacts you attach." -icon: "cube" ---- - -Lane context is the information ADE gives an agent so it starts in the right place. It is intentionally small and local to the work. - -## What context includes - -- Lane name, branch, base branch, and worktree. -- The current chat or terminal session. -- The task prompt and any explicit instructions. -- Artifacts you attach, such as proof, logs, screenshots, or linked issues. -- PR and Linear context when the lane is linked. - -## What agents still need to do - -Agents should inspect the repository directly when they need code, architecture, tests, or product details. ADE does not rely on a giant generated summary as the source of truth. - -## Improve a lane's context - - - - A clear lane name gives humans and agents the first clue. - - - Say what should change, where to look, and how to verify it. - - - Add screenshots, logs, Linear issues, or PR comments when they matter. - - - Continue the same chat or start a new lane-scoped chat when the work changes direction. - - - - -Good context is specific, not large. A failing test name and expected behavior often help more than a long background essay. - diff --git a/lanes/stacks.mdx b/lanes/stacks.mdx index bcc60a720..00ce51398 100644 --- a/lanes/stacks.mdx +++ b/lanes/stacks.mdx @@ -1,51 +1,83 @@ --- title: "Stacked lanes" -description: "Use stacked lanes when a large change is easier to review as several dependent PRs." +description: "Child lanes branch off another lane instead of main, so one big change ships as a stack of small, dependent PRs that merge in order." icon: "layer-group" --- -A stack is a chain of lanes. Each child lane is based on the lane above it instead of directly on `main`. +A **stack** is a chain of lanes linked parent → child. A **child lane**'s branch is based on its parent's branch instead of on `main`, so a large change ships as several small, reviewable PRs that land in order rather than one giant branch. ```text main - auth-models - auth-ui - auth-tests +└─ auth-models ← base lane (parent) + └─ auth-ui ← child of auth-models + └─ auth-tests ← child of auth-ui ``` -Each lane can become its own PR. Reviewers see small diffs instead of one giant branch. +Each lane in the stack opens its own PR. Reviewers see small diffs, and each **child PR targets its parent's branch** — not `main` — so the diff shows only that slice's changes. + +## Why stack + + + + One reviewable PR per slice instead of a thousand-line branch nobody wants to read. + + + Start feature B on top of feature A before A merges, without waiting or duplicating work. + + + Merge the base PR first, then each child in turn — ADE keeps the chain rebased as you go. + + ## Create a stack - Start the first slice from `main` or your default branch. + Branch the first slice from `main` or your default branch like any other lane. - - Select the parent lane and choose **New child lane**. + + Select the parent lane and choose **New child lane**. Its branch is based on the parent's branch, so its diff starts from the parent's work. - - Keep stacks shallow. Two or three levels are much easier to review than six. + + Each new child stacks on the one above it. Keep stacks shallow — two or three levels are far easier to review than six. + +A child only tracks its parent when the parent is a real (non-primary) lane. A lane parented to the primary lane compares against your default branch instead — which is why you create children off other working lanes, not off the repo root. + + ## Work with a stack -- Open PRs from bottom to top. -- Child PRs target their parent branch. -- Merge the base PR first. -- Rebase or retarget child PRs after the parent lands. -- Use Graph when the stack gets hard to picture. +- Open each lane's PR, bottom to top. +- Child PRs automatically target their parent's branch. +- Merge the base PR first, then walk up the stack. +- When the parent advances, ADE keeps the children current (below). +- Open the [graph](/tools/workspace-graph) when the stack gets hard to picture. + + + A stack of child lanes in the worktree graph with PR links and merge order + + +## Rebase propagation when the parent moves + +When a parent lane's branch advances — new commits, or the base PR merges — its children are now behind. ADE notices and **suggests a rebase** on the affected child lanes, surfaced as an inline banner with **Rebase now**, **Snooze**, or **Hide**. Run it and ADE rebases the lane (and, by default, its descendants) onto the freshly advanced parent, in parent-to-child order so each child rebases onto an already-rebased parent. + + +Prefer not to click? Turn on **Settings → Lane Behavior → Auto-rebase child lanes** and ADE rebases children for you whenever a parent moves. If a rebase hits a conflict, the lane pauses and surfaces the conflicting files so you can resolve and continue. + + +You can also reorganize a stack after the fact: the manage dialog's stack section lets you pick a new parent lane (or override the base branch), and ADE rebases the lane onto the new base. It refuses moves that would create a cycle — you can't reparent a lane under one of its own descendants, and the primary lane can never become a child. ## When not to stack -Do not stack unrelated work. If two tasks can merge independently, use two sibling lanes instead. +Stack only genuinely dependent work. If two tasks can merge in either order, give them **sibling lanes** off your default branch instead — independent PRs are simpler to review and don't block each other. A stack is the right tool only when slice B literally builds on slice A's not-yet-merged changes. - - Follow the end-to-end review flow. + + The end-to-end review and merge flow for a stack. - Visualize stack relationships. + See stack relationships, PR links, and merge order. diff --git a/logo/dark.svg b/logo/dark.svg deleted file mode 100644 index 446ac9aba..000000000 --- a/logo/dark.svg +++ /dev/null @@ -1,10 +0,0 @@ - - - - - - - - ADE - - diff --git a/logo/light.svg b/logo/light.svg deleted file mode 100644 index 6b25bc29e..000000000 --- a/logo/light.svg +++ /dev/null @@ -1,10 +0,0 @@ - - - - - - - - ADE - - diff --git a/quickstart.mdx b/quickstart.mdx index 86f3f8953..5096f9059 100644 --- a/quickstart.mdx +++ b/quickstart.mdx @@ -6,18 +6,22 @@ icon: "rocket" This page is the shortest useful path. You can tune providers, permissions, Linear, mobile, and worker settings later. + + The ADE desktop app + + Download the latest macOS DMG from [GitHub Releases](https://github.com/arul28/ADE/releases), open it, and drag **ADE.app** into `/Applications`. - Open **Settings -> AI Providers** and verify at least one provider. Claude, Codex, Cursor, and OpenCode are the main agent paths. + Open **Settings -> AI Providers** and verify at least one provider. Claude Code, Codex, Cursor, Factory Droid, and OpenCode are the agent paths. Use **Open Repository** on the welcome screen or press `Cmd+O`. Choose the repository root, not a subfolder. - In **Lanes**, create a new lane from your default branch. The lane gets its own branch and worktree under `.ade/worktrees/`. + In **Lanes**, create a new lane from your default branch. A lane is ADE's name for a git worktree — it gets its own branch and working copy under `.ade/worktrees/`, isolated from your main checkout. Open the lane in **Work** or **Chat** and send a narrow task. Start with something easy to inspect. diff --git a/reference/cli.mdx b/reference/cli.mdx new file mode 100644 index 000000000..3c622d4dd --- /dev/null +++ b/reference/cli.mdx @@ -0,0 +1,144 @@ +--- +title: "ade CLI" +description: "The ade command is the typed control plane for ADE from any shell — the same lanes, chats, PRs, and tests, scriptable for humans and agents alike." +icon: "terminal" +--- + +`ade` is the typed control plane for ADE. Everything you do in the desktop app — create lanes, run agents, ship PRs, kick off tests, attach Linear issues — has a CLI command, so you can drive ADE from any shell. Agents running inside ADE use the same commands, which is how they inspect and operate the workspace they live in. + +```bash +ade lanes create "fix-checkout-flow" # spin up a worktree for a task +ade brain status --text # check the machine runtime +ade code # open the terminal UI +``` + + +Two commands discover everything: `ade --help` for exact flags on any command, and `ade actions list --text` for the full service-backed action catalog behind the typed commands. + + +## Output modes + +Most commands take an explicit output mode. Use `--text` for a human-readable summary and `--json` for stable, scriptable fields (the default when output is piped). + +```bash +ade lanes list --text # readable summary +ade lanes list --json # stable JSON for scripts and agents +``` + +## Command groups + + + + Register projects and manage worktrees (lanes). + + ```bash + ade init # add the current directory as a project + ade projects list --text # list registered projects + ade lanes list --text # list lanes in the active project + ade lanes create "fix-checkout-flow" # create a lane from the default branch + ade lanes create "auth-ui" --parent auth-base # stack a lane on another lane + ade lanes reparent auth-ui --parent auth-base # restack an existing lane + ade lanes delete --force --delete-branch + ``` + + + + Start and inspect agent chats, terminals, and CLI sessions inside a lane. + + ```bash + ade chat list --lane --text + ade chat create --lane --model gpt-5.5 + ade shell start-cli codex --lane --permission-mode edit --message "fix failing tests" + ade shell start --lane -- npm test + ade code # open the terminal UI + ``` + + + + Commit, push, and turn a lane into a pull request; read CI and comments. + + ```bash + ade git commit --lane + ade git push --lane + ade prs create --lane --base main --title "Fix checkout flow" --text + ade prs list-open --text + ade prs checks --text # CI status for a PR + ade prs comments --text + ``` + + + + Start dev processes and run test suites in a lane. + + ```bash + ade run defs --text # list configured run targets + ade run start web --lane + ade tests run --lane --suite unit --wait + ``` + + + + Attach and update Linear issues through ADE's own Linear connection — no API key needed. + + ```bash + ade lanes create-from-linear --issue-id ENG-431 --start-chat --provider codex + ade linear attach --this-session --issue-id ENG-431 + ade linear comment "Pushed a fix; CI running" + ade linear set-state ENG-431 + ``` + + + + Control the machine-owned ADE runtime (the brain) and pair a phone. + + ```bash + ade brain status --text # endpoint, service, and sync state + ade brain start # load the login service + ade brain stop # unload the login service + ade brain restart # re-exec after an app update + ade brain pin generate # generate a phone pairing PIN + ade brain pin set 123456 # set an explicit pairing PIN + ``` + + + + List the computer-use proof artifacts ADE captured for a chat or session. + + ```bash + ade proof list --arg ownerKind=chat --arg ownerId= + ``` + + + + Find commands, flags, and the full action catalog, and check local readiness. + + ```bash + ade --help # exact flags for any command + ade actions list --text # full service-backed action catalog + ade actions run git.stageFile --arg laneId= --arg path=src/index.ts + ade doctor # local runtime, git, provider readiness + ade skill list --text # bundled agent skills + ``` + + + + +Prefer typed commands — they validate arguments and return stable fields. Reach for `ade actions run ` only when no typed command covers the workflow yet. + + +## Full reference + +For every command, subcommand, flag, and the runtime modes behind them, see the complete CLI README on GitHub. + + + The full `ade` command reference, runtime modes, and install paths. + + + + + The interactive terminal UI built on the same runtime. + + + How the control plane, runtime, and clients fit together. + + diff --git a/reference/troubleshooting.mdx b/reference/troubleshooting.mdx new file mode 100644 index 000000000..74339c475 --- /dev/null +++ b/reference/troubleshooting.mdx @@ -0,0 +1,94 @@ +--- +title: "Troubleshooting" +description: "Fixes for the common snags — the brain not running, providers with no models, mobile sync, stuck lanes, and remote SSH connections." +icon: "wrench" +--- + +Most issues come down to one of a few things: the brain isn't running, a provider isn't authenticated, two devices aren't on the same network, or a remote SSH route is down. Two commands answer most questions: + +```bash +ade brain status --text # endpoint, service, and sync state +ade doctor # local runtime, git, GitHub, Linear, and provider readiness +``` + + +`ade doctor` reports local readiness only — it never calls provider, GitHub, or Linear networks and never prints secret values. It's safe to run anytime. + + + + + The desktop app, `ade code`, and the iOS app are all clients of the **brain** — the always-on ADE process for your channel. If it isn't running, clients have nothing to attach to. + + ```bash + ade brain status --text # is the endpoint listening? is the service loaded? + ade brain start # load the login service + ade brain restart # re-exec after an app update + ade doctor # broader local readiness check + ``` + + After a desktop update, the brain re-execs the new bundled CLI on first launch. If clients still look stale, `ade brain restart` forces it. Before restarting, close active chats, terminals, and mobile sessions that depend on the brain. + + + + A provider only lists models once it's authenticated. + + - **Add the key.** Open **Settings → AI**, connect the provider (Claude subscription or Anthropic key, Cursor API key, OpenCode backend, etc.), and confirm a green status. + - **Give discovery a moment.** Cursor and Droid model lists are discovered live and served stale-while-revalidate — a freshly connected provider may need a refresh in **Settings → AI**, or an ADE restart. + - **For CLI-launched agents** (a provider run as a terminal session that isn't installed or signed in), ADE surfaces an inline auth card in chat with install / login buttons that open a tracked terminal on the active machine. + - **Check `ade doctor`** — it reports provider/model readiness from local config, API-key references, and provider CLI availability. + + + + The phone pairs with a brain and connects to its sync websocket. Two things have to be true: + + 1. **Paired with a PIN.** Generate or set a pairing PIN on the machine and enter it on the phone: + ```bash + ade brain pin generate + ade brain pin set 123456 + ``` + You can also manage the PIN from the desktop Mobile control. + 2. **Reachable on the network.** The phone and the machine must be on the same LAN, or both on a Tailscale tailnet. Install Tailscale on both when they aren't on the same local network. + + Confirm the brain's sync is up with `ade brain status --text` (it reports sync state). Note that a **manual runtime** (`ade runtime run`) has sync off by design — pairing only works against the brain. + + + + A lane is a git worktree, so a normal delete refuses when the worktree has uncommitted changes. Force it (and optionally remove the branch): + + ```bash + ade lanes list --text # find the lane id + ade lanes delete --force --delete-branch + ``` + + If the lane is an **attached external worktree** (one you created with `git worktree` outside ADE), ADE tracks it but never moves or cleans it — detach it in ADE and remove the worktree yourself with `git worktree remove`. + + + + Remote machines connect over SSH and run `ade rpc --stdio` on the far side. ADE surfaces the specific failure inline on the remote target; common ones: + + - **`SSH server at closed the connection before ADE could finish the SSH handshake`** — the TCP route opened but the server reset the handshake. Check Remote Login / sshd, firewall rules, and any Tailscale SSH policy. + - **`Remote machine was manually disconnected. Connect again to use this remote project.`** — you explicitly disconnected; ADE won't reconnect until you press **Connect**. + - **`ADE stopped automatic reconnecting after 10 failed attempts. Press Connect to try again.`** — implicit reconnects were paused after repeated failures. Press **Connect** once the box is reachable. + - **`ADE service is not installed … no bundled ADE service is available`** — the desktop has no bundled runtime for that remote's architecture. Use a release build that includes runtime resources for it, or install `ade` on the remote. + - **`Remote ADE service version mismatch` / `does not support multi-project mode`** — the remote is running an older or mismatched runtime. Re-bootstrap from a current desktop build. + + Authentication failures for an agent CLI on the remote (Claude / Codex / Cursor / Droid not installed or signed in) appear as an inline auth card whose install / login buttons run on the **remote** machine. + + + + A remote project uses the **remote machine's** GitHub, Linear, and provider credentials — not your laptop's. Authenticate providers on the box that's actually running the agents (the inline auth card targets the active runtime), and expect the remote's Linear and GitHub connections to drive work that happens there. + + + + +When in doubt, run `ade doctor` and `ade actions list --text`. The first reports what's ready locally; the second confirms the brain is reachable and lists every action it exposes. + + + + + The full command reference behind these fixes. + + + How the brain, clients, and remote runtimes fit together. + + diff --git a/tools/ade-code.mdx b/tools/ade-code.mdx new file mode 100644 index 000000000..d76054ac0 --- /dev/null +++ b/tools/ade-code.mdx @@ -0,0 +1,71 @@ +--- +title: "ade code (terminal)" +description: "ADE, terminal-native. The same lanes, chats, and PRs in a fast TUI you can drive over SSH." +icon: "rectangle-terminal" +--- + +`ade code` is ADE in your terminal — the same lanes, chats, and PRs as the desktop app, rendered as a fast TUI. It attaches to the same machine, so a chat you start in the terminal shows up on the desktop and your phone, and vice versa. Start in the shell, finish anywhere. + + + +## Launch it + +```bash +ade code +``` + +That attaches to your machine's ADE runtime and opens the workspace. From there you get a lane and chat drawer, a chat pane, and a side pane for PR details, lane info, the model picker, and Linear status. + + + The ade code terminal UI + + +## What you can do + + + + Start and steer chats with any provider, watch tool calls stream, and approve diffs. + + + Create, switch, and inspect lanes without leaving the keyboard. + + + Commit, push, and open PRs with slash commands; check CI from the side pane. + + + Run it on a remote box and drive ADE entirely from a terminal session. + + + +## Slash commands + +Most actions have a slash command. A few of the common ones: + + + + | Command | Does | + |---------|------| + | `/new lane` | Create a new lane | + | `/model` | Open the provider and model picker | + | `/commit` | Stage and commit the lane's changes | + | `/push` | Push the lane's branch | + | `/pr` | Open a pull request from the lane | + | `/linear` | Attach or update a Linear issue | + | `/info` | Show plan steps, token usage, and PR status | + + Type `/` in the composer to see the full list for the current session. + + + + +`ade code` is a client of the same runtime as the desktop app — it isn't a separate copy of your project. Both read and write the same lanes, transcripts, and PR state. + + + + + How chats, providers, and tool calls work. + + + Point ADE at a repository that lives on another box. + + diff --git a/tools/automations.mdx b/tools/automations.mdx new file mode 100644 index 000000000..60e4f7846 --- /dev/null +++ b/tools/automations.mdx @@ -0,0 +1,117 @@ +--- +title: "Automations" +description: "Rule-based background workflows: a trigger fires, an agent session or built-in action runs, and guardrails gate anything that publishes externally." +icon: "robot" +--- + +**Automations** are rule-based background workflows. Each rule pairs a **trigger** — a schedule, an event, or a webhook — with an **execution surface**, then runs either a scoped AI chat session or a sequence of deterministic built-in actions. **Guardrails** gate anything that would publish externally, so a low-confidence or unreviewed run never writes to GitHub, Linear, or the web on its own. + +Automations sit between the CTO (heavy, stateful, chat-driven) and raw cron (deterministic, no AI). They're for the repeatable background work you'd otherwise do by hand — a nightly audit, a review on every PR, a summary when a chat ends. + + +The **Automations** tab is rolling out. In production builds it currently shows a **"Soon"** badge while the surface lands — the rule engine and run history described here are how it works once enabled. + + +## Anatomy of a rule + + + + What starts the rule — a cron schedule, an action event, or an inbound webhook. + + + Either an `agent-session` (a scoped AI chat) or `built-in` (deterministic ADE actions). + + + Confidence threshold, duration cap, human review, and path/lane allowlists. + + + Where results go — a comment, a follow-up lane or task, a draft PR, or evidence only. + + + +## Triggers + +A rule fires from one of three broad classes of trigger. + + + + A 5-field cron schedule (minute, hour, day-of-month, month, day-of-week). Seconds aren't supported. The editor previews the next fire time. + + ```text + 0 9 * * 1-5 # weekdays at 09:00 + ``` + + + Git and lifecycle events: `git.commit`, `git.push`, `lane.created`, `lane.archived`, `file.change`, `session-end`, and `manual`. GitHub events cover PR and issue lifecycle (`github.pr_opened`, `github.pr_merged`, `github.issue_opened`, `github.issue_labeled`, and more), with filters for labels, authors, target branch, repo, and title/body regex. + + + Inbound `webhook` and signed `github-webhook` events, plus `linear.*` events consumed as context. GitHub events arrive over a real webhook, a relay, or direct polling — matching is identical regardless of source. + + + + +Linear triggers here are **context only**. The CTO owns Linear issue intake and routing — automations react to Linear events for their own work but never duplicate that pipeline. See [Linear](/integrations/linear). + + +## Execution surfaces + +Choosing the surface is the key decision — it sets how much orchestration a rule carries. + + + + A scoped AI chat thread with the rule's prompt and allowed tools. Best for reviews, audits, and short summaries. Appears in run history as a thread. + + + A sequence of deterministic ADE actions — create a lane, run a command, run tests, predict conflicts, or dispatch an allowlisted ADE action. No AI in the loop; sandboxed to the target lane's worktree. + + + + +Built-in actions are deterministic by design — they shouldn't wrap an AI call. When a step needs reasoning, use an `agent-session` (a built-in chain can embed one as a step). + + +## Guardrails + +Automations publish effects — comments, PRs, Linear updates, webhooks. Guardrails decide whether a run is allowed to publish, or whether it parks in a review queue first. + +| Guardrail | What it does | +|-----------|--------------| +| Confidence threshold | A run below the threshold (baseline ~0.65) lands in review instead of publishing. | +| Duration cap | Runs that exceed `maxDurationMin` (baseline 10 min) are cancelled. | +| Require human | Force human review regardless of confidence. | +| Verify before publish | The run must pass a verification step — or a reviewer's approval — before external effects apply. | +| Path / lane allowlists | Built-in shell and file actions are sandboxed to specific lane worktrees or subpaths. | + +Each rule also carries a **review profile** (quick, incremental, full, security, release-risk, cross-repo-contract) that sets the base confidence — `security` and `release-risk` start higher than `quick`. + + +Runs that need a human land in a queue with statuses like **pending review**, **verification required**, and **completed clean**. The dashboard shows a severity summary so you can triage without opening every run. + + +### Secrets and scope + + + + Webhook secrets and access tokens must be `${env:VAR_NAME}` references — raw secret values are rejected and resolved at run time. + + + Built-in shell actions stay inside the allowed workdirs; paths that escape the lane worktree or project root are rejected. + + + +## Authoring a rule + +You can write a rule from a free-text brief — a planner turns the brief into a draft rule (triggers plus actions) that you review before saving — or build it directly in the rule editor by picking a trigger, an execution surface, and guardrails. Templates seed a new draft to start from. + + +Use the **simulate** path to dry-run a rule against a synthetic trigger before enabling it — it lists exactly which actions would fire, with nothing published. + + + + + The persistent operator that owns Linear intake and worker delegation. + + + Why Linear routing lives with the CTO, not automations. + + diff --git a/tools/browser.mdx b/tools/browser.mdx new file mode 100644 index 000000000..323c5aeeb --- /dev/null +++ b/tools/browser.mdx @@ -0,0 +1,58 @@ +--- +title: "Browser" +description: "ADE's built-in browser pane in Work — open pages beside your code, inspect elements, and hand exactly what you see to an agent." +icon: "compass" +--- + +The **Browser** lives in the Work tab, right next to your chat. Open a web page beside the code that drives it, inspect an element, and hand exactly what you're looking at to an agent — no copy-pasting URLs or describing the bug in prose. + + + +## Code and page, side by side + +The browser opens on the Work right-edge sidebar, in the same surface as your agent chat — so the page you're testing and the agent fixing it share one screen. Change code in a lane, reload the page, and see the result without leaving ADE. + +Unlike the lane-scoped tools, the browser belongs to the **ADE window**: each window owns its own tabs and active page, while all windows share one signed-in session, so a site you log into once stays logged in across them. + + + The ADE browser pane next to an agent chat in the Work tab + + +## Inspect and hand off + +Switch the pane into inspect mode and a DevTools-style outline tracks the element under your pointer. Click to commit it, and ADE captures the element — its markup, a stable selector, what's rendered, and a screenshot — then attaches it to the active chat as a context chip. Instead of "the button looks wrong," the agent gets the actual element it needs to fix. + + + Inspecting a page element to hand to an agent + + +## What it's for + + + + Reload the running app and confirm an agent's fix actually landed. + + + Select an element or page state and pass it straight into a chat. + + + Grab what you see as an artifact attached to the work. + + + + +Point the browser at the dev server you started in [Run](/tools/project-home) — the page and the process that serves it stay in the same lane, so a reload reflects the lane's latest code. + + +## Drive it from anywhere + +The same browser is scriptable. The `ade browser` CLI surface lets an agent — or you — navigate, screenshot, inspect, and pick context from the shared tabs, so a chat agent can drive the page it's reasoning about. + + + + Hand browser context to an agent and let it work. + + + Drive apps and capture evidence of what happened. + + diff --git a/tools/conflicts.mdx b/tools/conflicts.mdx index e1efb239d..e9e949f54 100644 --- a/tools/conflicts.mdx +++ b/tools/conflicts.mdx @@ -1,54 +1,89 @@ --- title: "Conflicts" -description: "Find likely merge conflicts between lanes before they block a PR." -icon: "triangle-exclamation" +description: "Predict, simulate, and resolve merge conflicts between lanes before they ever block a merge." +icon: "code-merge" --- -ADE helps you see conflict risk while work is still in progress. It compares active lanes and shows where two branches are likely to collide. - -## Where conflicts appear - -- Lane status badges. -- Workspace Graph edges. -- PR detail views. -- The Conflicts page. - -## How to use conflict signals - - - - A lane, graph edge, or PR shows conflict risk. - - - Review the lanes, files, and summary of the overlap. - - - Sometimes the easiest fix is to land one branch first and rebase the other. - - - Use Files, Git, or an agent-assisted pass to resolve the conflict. - - - Run tests and recheck PR state after the conflict is gone. - - +ADE surfaces integration risk before it becomes a merge-time emergency. A single engine predicts conflicts, computes pairwise risk, runs pre-flight merge simulations, and drives AI-assisted resolution — so you can reorder, rebase, or fix a collision while work is still in progress. + +There's no standalone "Conflicts" tab; the signal is projected into the surfaces where it matters: lane status badges, the **Graph** risk matrix, and the **PRs** rebase and integration views. + +## Pre-flight detection + +ADE compares your active lanes — against each other and against their base — by running `git merge-tree` on the host that owns the worktrees. It predicts whether a merge or rebase *would* conflict without actually performing one, then caches the result and surfaces it as a status. + +| Status | Meaning | +|--------|---------| +| **Merge-ready** | A base prediction exists, no predicted conflicts, and the lane isn't behind. | +| **Behind base** | No conflicts, but the lane is behind its base and should rebase. | +| **Conflict predicted** | A dry merge predicts conflicts with the base or a peer lane. | +| **Conflict active** | A real merge or rebase is in progress and has produced actual conflicts. | + + +Predictions older than five minutes are marked **stale** and shown with a clock indicator rather than silently refetched — the UI annotates them, and clicking re-runs the prediction for that pair. + ## Risk levels +For each lane pair, ADE derives a risk level from how many files overlap and whether a real conflict is predicted. + | Level | Meaning | |-------|---------| -| Low | Some overlap, but likely easy to merge. | -| Medium | Shared files or nearby changes need review. | -| High | Merge is likely to block or require manual resolution. | +| **None** | No overlapping files. | +| **Low** | A small overlap — likely an easy merge. | +| **Medium** | Several shared files; review before merging. | +| **High** | Marker-level conflicts predicted, or heavy overlap — expect manual resolution. | + +The project-wide **risk matrix** in the Graph tab renders every pair at once, animating cells as risk levels change between prediction sweeps. Hover a cell for the overlapping file list; click an edge to open merge simulation and resolution. + +## Live merge simulation + +From a Graph edge or a lane's merge panel, you can run a one-shot **merge simulation** between two lanes (or a lane and its base). ADE computes the merge base, runs `git merge-tree`, and returns one of: + +- **Clean** — no conflicts; the merged file list and diff stat. +- **Conflict** — the conflicting files, each with rendered conflict-marker previews. +- **Error** — a bad ref or corrupt index, surfaced rather than assumed clean. + +This is the same primitive that backs the PR merge-readiness check and integration (merge-plan) proposals, so the simulation you see in Graph matches what the PRs tab predicts. + +## Rebase when a lane drifts + +When a lane falls behind its base, a rebase pulls it forward and is usually the cleanest way to clear a predicted conflict before it reaches a PR. ADE resolves the right comparison ref for you — a queue's tracking branch if the lane is in a merge queue, the parent branch for a stacked lane, or `origin/` otherwise. + + + Rebase options for a lane that drifted from its base + + +## AI-assisted resolution + +When a conflict needs more than a reorder, ADE can resolve it for you in two ways: + + + + ADE builds a bounded context for the specific conflict, asks a model for a patch, and lets you apply it unstaged, staged, or as a commit — with one-click undo. If required file context is incomplete, it refuses to guess and tells you why. + + + For bigger merges, ADE spawns a Codex or Claude CLI session in the lane's worktree (or a dedicated integration lane), captures the changes, and commits them as an explicit, reviewable step. + + ## Prevention -- Keep lanes narrow. +- Keep lanes narrow so they touch fewer shared files. - Stack related changes instead of editing the same area from unrelated lanes. - Rebase long-running lanes regularly. -- Use Graph before merging several PRs. +- Check Graph before merging several PRs at once. - Ask an agent to explain a conflict before asking it to fix one. Conflict prediction is a warning system. Always verify with Git, tests, and PR checks before merging. + + + + See lane topology, stack order, and the risk matrix at a glance. + + + Review CI, comments, and merge readiness for each PR. + + diff --git a/tools/files-editor.mdx b/tools/files-editor.mdx index e0d36c077..468321f08 100644 --- a/tools/files-editor.mdx +++ b/tools/files-editor.mdx @@ -1,50 +1,109 @@ --- title: "Files" -description: "Review and edit lane-scoped files, diffs, conflicts, and Git changes." +description: "ADE's review workbench — a lane-scoped file tree, Monaco editor, diffs, conflict resolution, and a Git panel for staging, committing, and pushing." icon: "file-code" --- -Files is ADE's review workbench. It shows the selected lane's file tree, editor tabs, diffs, staged changes, and Git actions. +**Files** is ADE's review workbench: the place you read exactly what an agent changed, fix anything that's off, and turn a reviewed diff into a commit. It pairs a lane-scoped file tree and a full Monaco editor with diff and conflict views and a Git panel for staging, committing, stashing, and pushing — all without leaving the tab. + + + + Files review workbench inside ADE + + + The Git panel inside ADE + + ## What Files is for - Review exactly what changed before committing. + Read every hunk an agent touched before it ever reaches a commit. - Edit files directly when a small human adjustment is faster than another prompt. + Open a file in Monaco and edit it directly when a small human adjustment beats another prompt. - Stage files, write a commit message, amend, stash, or push. + Stage related files together, write a message, and push the lane's branch from the Git panel. -## Lane scope +## Pick a workspace + +The file tree is scoped to one **workspace** at a time. A workspace is a directory Files can browse, and there are three kinds: + +| Workspace | Where it comes from | +|---|---| +| **Primary** | Your repository root — always present. | +| **Lane worktree** | The isolated worktree behind a lane, under `.ade/worktrees/`. | +| **Attached** | An external worktree path you linked in. | + +ADE shows the active workspace name prominently so you never edit the primary checkout when you meant to edit a lane. Switching workspaces changes the tree, diffs, and Git panel together — confirm the selector before you save. + + + Choose the lane worktree to review in Files + + +## Read the diff + +Open a changed file to inspect its hunks. Diffs come from a few sources — staged vs. working tree, `HEAD` vs. working tree, or commit-to-commit — and you can switch how they render: + +- **Preview** for prose and markup, where you want the rendered result. +- **Raw** for the unified diff, where you want to read code line by line. + +The file tree itself carries Git status decorations, so changed, added, and deleted files are colored in place before you even open them. + + + Toggle between rendered preview and raw diff + -The file tree is scoped to one lane at a time. Switching lanes changes the worktree you are editing. Check the lane selector before saving if you have several lanes open. +## Edit in Monaco -## Common flow +Files opens in a real Monaco editor with syntax highlighting and read/write semantics. Saves are **atomic** — ADE writes to a temp file and renames it into place — so a dev server watching the file never catches a half-written save. Markdown files add a per-tab preview toggle that swaps the editor for a rendered view. + + +Read-only workspaces are enforced end to end: the editor opens read-only and the create, rename, and delete controls are disabled, so you can browse a protected worktree without risking an accidental write. + + +## Stage, commit, and push + +The Git panel turns a reviewed diff into a commit. Stage related files together, write a message, stash or amend when you need to, and push the lane's branch — all from the same surface. + + + Stage, commit, and push from the Git panel + + +## The review flow - Choose the lane an agent worked in. + Choose the lane worktree an agent worked in from the workspace selector. - Open each modified file and inspect the hunks. + Open each modified file and inspect the hunks, raw or rendered. - Edit directly or ask the agent to continue from the review notes. + Edit directly in Monaco, or send the agent back with specific review notes. - Stage related files together and commit once the work is coherent. + Stage related files together, commit once the work is coherent, then push. ## Conflicts -When a merge or rebase produces conflicts, Files shows the conflicted files and lets you resolve them in the editor. After resolving, continue the Git operation from the lane or PR workflow. +When a merge or rebase produces conflicts, Files opens a three-way merge view with **Base**, **Ours**, **Theirs**, and **Result** panes, plus *Accept Ours*, *Accept Theirs*, and *Accept Both* actions. Resolve the file, then continue the Git operation from the lane or PR workflow. See [Conflicts](/tools/conflicts) for the full risk model and prevention tips. -Use Files as the final human checkpoint. Even when an agent says tests passed, inspect the diff yourself before pushing. +Use Files as the final human checkpoint. Even when an agent reports that tests passed, read the diff yourself before you push. + + + + Turn a reviewed, committed lane into a GitHub PR. + + + Trace any commit back to the lane and session that produced it. + + diff --git a/tools/history.mdx b/tools/history.mdx index c66e3c21c..d2796e81b 100644 --- a/tools/history.mdx +++ b/tools/history.mdx @@ -1,49 +1,82 @@ --- title: "History" -description: "Search the record of chats, terminals, commits, PRs, lane changes, proof, and checkpoints." +description: "A per-project timeline with two surfaces: a commit graph for each lane and a unified activity feed." icon: "clock-rotate-left" --- -History answers the question: what happened in this project? +The **History** tab is your project's timeline. It has two surfaces sharing one page: a **Commits** view — a GitKraken-style commit graph for the focused lane — and an **Activity** view that merges operations, chat sessions, CTO sessions, and worker runs into one feed. Use it to recover context, audit agent work, or recover from a lane that wandered off. -It records sessions, commits, lane changes, PR events, proof artifacts, checkpoints, and worker activity. Use it to recover context, audit agent work, or pick up where a session ended. +## Commits -## Common uses +The Commits surface draws the commit DAG for whichever lane you pick from the toolbar. Each row shows the short SHA, optional `HEAD` and merge pills, branch ref pills, the subject, the author, and a relative timestamp — laid out as a virtualized graph that stays fast on long histories. + +Right-click any commit (or use the actions strip in the detail panel) for a full set of git actions: - - Search a previous chat or terminal transcript. + + Check out, compare with parent, view changed files, or open the commit in the Lanes git pane. - - Trace a commit back to the lane and session that produced it. + + Branch, tag, or fork a brand-new lane from this exact commit with **Create lane here**. - - Reopen an old session summary or checkpoint. + + Cherry-pick, revert, or soft/mixed/hard reset to the commit. - - Find proof artifacts attached to a lane, PR, or chat. + + Open or copy the GitHub link, copy the patch, the SHA, or the subject. -## Event types +A search box above the graph supports bare text plus prefixed keys — `message:`, `author:` (or `@`), `commit:` (or `#`), `branch:`, `parent:`, and filters like `is:merge`, `is:local`, `is:pushed`. The Commits toolbar also carries a **lane git actions** menu for fetch, pull, push, rename, archive, rebase, and other lane-scoped operations without leaving History. + + +The Commits view also exposes per-lane **undo / redo** for the last HEAD-changing operation. ADE re-reads HEAD before it touches git and refuses if the branch moved since, so a reset never clobbers work you did afterward. + + +## Activity + +The Activity surface is a unified feed. It combines recorded **operations** — discrete, typed actions that changed state — with synthesized rows pulled from chat sessions, CTO snapshots, and worker runs, sorted newest-first. + +| Source | Examples | +|--------|----------| +| **Git operations** | Commit, checkout, merge, rebase, push, pull, fetch, cherry-pick, revert, tag, reset, stash, undo/redo. | +| **PR operations** | PR creation and related actions. | +| **Pack refreshes** | Lane and project context-pack regeneration. | +| **Chat sessions** | Agent chats, with provider, model, and status. | +| **CTO & workers** | CTO sessions and worker runs with their status and wakeup reason. | + +Pick from three view modes — **Graph** (per-lane swimlanes), **List** (a sortable table), or **Compact** (one dense line per event). A **scope** selector sets how much detail shows (Key → Standard → Detailed → All), and you can further filter by lane, category, status, and time range, or search across labels, kinds, and metadata. Running events auto-refresh while the tab is focused. + + +Synthesized chat/CTO/worker rows are rebuilt on every refresh for display only — they're never written into the operations table, and they don't appear in an export. + -| Event | Examples | -|-------|----------| -| Session | Chat started, terminal ended, agent interrupted. | -| Git | Commit, branch change, rebase, merge. | -| Lane | Created, archived, deleted, stacked. | -| PR | Opened, updated, reviewed, CI changed, merged. | -| Worker | Assigned, completed, failed, paused. | -| Proof | Screenshot, recording, trace, log, verification note. | +## Export -## Search and filters +Export the operations history to **CSV or JSON** with the current lane and status filters applied. ADE returns the rows and the desktop writes the file through a native save dialog. -Filter by lane, event type, date range, agent/provider, PR, or worker. Search text includes titles, summaries, command output snippets, commit messages, and PR metadata. + + + History is also available from the `ade` CLI and `ade code`: -## Checkpoints + ```bash + ade history list # recent operations in the active project + ade history list --lane # scope to one lane's timeline + ``` -Checkpoints are useful moments in a lane's timeline. They let you inspect what changed around a session or commit and, when needed, branch new follow-up work from that point. + Run `ade history --help` to see every filter and flag. + + -History is local project evidence. It is meant to make agent work inspectable, not to replace Git history or GitHub review. +History is local project evidence — it makes agent work inspectable. The Commits view reads real `git log`; it doesn't replace Git history or GitHub review. + + + + Open the diff behind any commit you find in History. + + + Run an on-demand AI review over a commit range you spot in the graph. + + diff --git a/tools/ios-companion.mdx b/tools/ios-companion.mdx index 5da39bebf..0388b8478 100644 --- a/tools/ios-companion.mdx +++ b/tools/ios-companion.mdx @@ -1,52 +1,93 @@ --- title: "iOS companion" -description: "Pair the ADE iOS app with desktop to follow work, receive updates, and act on project state from your phone." +description: "Pair the ADE iOS app with your Mac over a live WebSocket and mirror lanes, chats, and PRs in real time — start chats, review and merge PRs, all from your phone." icon: "mobile-screen" --- -The ADE iOS app is a companion to the desktop runtime. It does not run coding agents on the phone. Your Mac remains the execution host. +The ADE iOS app is a client for your Mac. It pairs over a live WebSocket and mirrors your lanes, chats, and PRs in real time. Start or continue a chat, review and merge a PR, or browse a lane's diff — from your phone. Your source code never leaves the Mac. The phone is a thin client; the agents run on the desktop runtime. + + + + Agent chat on the ADE iOS app + + + Pull request review on the ADE iOS app + + ## What mobile is for - See lanes, chats, PRs, and worker activity while away from the desktop. + See lanes, chats, PRs, and worker activity update live while you are away from the desktop. - - Receive push updates for completed work, failures, questions, and review events. + + Start a new chat or continue an existing one — the agent runs on the Mac, the transcript streams to your phone. - - Review status and send small follow-up commands when the desktop runtime is reachable. + + Read the diff, CI status, and comments, then merge when it is green — without opening a laptop. - Pair with the local runtime so project state can mirror to the phone. + The same lanes and sessions follow you between desktop, `ade code`, and the phone over one live connection. ## Pair your phone +Pairing links the app to your Mac's runtime with a one-time PIN. Generate the PIN on the desktop (or from the CLI), enter it on the phone, and the app connects. + - - The desktop app shows pairing status and a QR code when mobile support is available. + + Open desktop **Settings -> Mobile** and generate a pairing PIN, or run `ade brain pin generate` from any shell. - - Scan the QR code from the iOS app. + + Open the ADE app on your iPhone and type the PIN to pair with your machine. - - Desktop should show the device as paired. The phone should show the project catalog or current project state. - - - Keep the events you care about, such as agent completed, agent failed, PR ready, or question waiting. + + The phone shows your project catalog and current lanes; the desktop lists the device as paired. From here, lanes, chats, and PRs stream live. + + + The pairing PIN is owned by the machine's ADE brain, so you can manage it without the desktop UI: + + ```bash + ade brain pin generate # generate a one-time phone pairing PIN + ade brain pin set 123456 # set an explicit PIN + ade brain pin clear # invalidate the current PIN + ade brain status --text # endpoint, service, and sync state + ``` + + Run `ade brain --help` to see every flag. + + + +## Review and merge from anywhere + +A PR your agents opened shows up on the phone with its diff, CI status, and comments. Read it, leave the work running on the Mac, and merge when it goes green. + + + Pull request review and merge on the ADE iOS app + + ## What to expect -- Desktop must be running for local command execution. -- Network reachability matters. Local Wi-Fi is simplest; tailnet setups can make reconnection easier. -- Large artifacts may load on demand. -- Sensitive source and project data remain tied to the paired desktop/runtime. +- The Mac must be running — agents execute on the desktop runtime, and the phone mirrors them. +- Connection is a live WebSocket, so lanes, transcripts, and PR state update as they change. No manual refresh. +- Network reachability matters. Local Wi-Fi is simplest; a tailnet makes reconnection easy when you leave the house. +- Large artifacts and diffs load on demand. +- Source and project data stay tied to the paired Mac. The phone holds no checkout. -If mobile looks connected but updates do not arrive, check desktop Settings -> Mobile first, then verify both devices are on a reachable network. +If the app looks connected but updates do not arrive, check desktop **Settings -> Mobile** first, then confirm both devices can reach each other on the network. + + + + The same lanes and chats in a fast terminal UI. + + + How PRs are created, reviewed, and merged in ADE. + + diff --git a/tools/ios-simulator.mdx b/tools/ios-simulator.mdx new file mode 100644 index 000000000..3e1f357d4 --- /dev/null +++ b/tools/ios-simulator.mdx @@ -0,0 +1,114 @@ +--- +title: "iOS Simulator" +description: "A macOS-only drawer in Work that builds, launches, mirrors, inspects, and controls a booted iOS Simulator — and turns a tapped SwiftUI view into source-anchored chat context." +icon: "mobile" +--- + +The **iOS Simulator** drawer drives the system iOS Simulator from inside ADE's Work tab. It discovers your launchable iOS targets, builds and launches the app, mirrors the running Simulator window into the drawer, and turns drawer gestures into either simulator input or context for the active chat. When you tap a SwiftUI view in inspect mode, the agent gets the element's **source file and line** — not a guess from stale code. + + +This feature is **macOS-only**. `xcrun`, `xcodebuild`, and Simulator.app must be available on the runtime host. `idb` and `idb_companion` are optional but unlock direct tap, drag, text, and accessibility-backed inspection. + + +## What the drawer does + + + + Discover Xcode projects, DerivedData app bundles, and installed simulator apps, then build, install, and launch the one you pick. + + + Stream the real Simulator.app window into the drawer, parked behind ADE so it stays out of your way. + + + Tap an element to capture it as chat context — with its component id, source file, and line when the app is annotated. + + + Tap, drag, swipe, and type into the running app when `idb` and `idb_companion` are installed. + + + +## Source-anchored inspection + +The magic of the drawer is **ADE Inspector**, a debug-only Swift kit that lives inside the iOS app under inspection. When you annotate a view with `.adeInspectable("settingsButton")`, the kit publishes a per-frame JSON snapshot of every annotated view's frame, component id, and source location into the app's data container. + +When you tap in inspect mode, ADE correlates that snapshot with a fresh screenshot and attaches the matched element to your chat as a context chip carrying the component id, the source file and line, and a screenshot of the hit. The agent reasons about *that* view at *that* line, not the surrounding container. + + + + Wrap buttons, list rows, and headline labels with `.adeInspectable("componentId")` and mount `.adeInspectorHost()` once near the root. The kit is `#if DEBUG`-only — release builds compile it to a no-op. + + + ADE builds and launches your selected target, then mirrors the Simulator window into Work. + + + A tap resolves the SwiftUI view under your finger and produces a context item. + + + The element lands in the chat composer as a chip with the source file and line baked in. + + + + +Annotate selectively. The snapshot already drops zero-area and off-screen frames, but tagging every structural container inflates the JSON and creates ambiguous hit-tests. Tag the views you'll actually want to talk about. + + +## When the app isn't annotated + +ADE Inspector is opt-in, and inspection degrades gracefully: + +- **Accessibility fallback** — with `idb` installed, a tap falls through to the OS accessibility tree, so the agent still gets labels and roles (just no source file or line). +- **Coordinate fallback** — without `idb`, ADE still attaches the screenshot and the hit coordinates, so the agent can reason about the region. + +## Preview Lab + +Beyond a running app, the drawer can render SwiftUI **previews**. It discovers nearby `#Preview` and `PreviewProvider` definitions, ranks the best match for your selected source file or last-tapped element, opens Xcode when needed, and renders the preview into ADE's Preview drawer — a one-shot bridge from "the view I just selected" to "show me what it looks like." + +## One owner per session + +Each launched simulator session has one owning chat or lane. If a second chat tries to launch against an active session, it's told the simulator is owned by another session until the current owner releases it or you force a shutdown. + +## Drive it from the CLI + +Everything the drawer does is also available from the `ade ios-sim` command group, so an agent can build, launch, inspect, and control the simulator headlessly. Use `--socket` so the CLI and the desktop drawer share the same live session, selection, and proof state. + + + + ```bash + ade --socket ios-sim status --text # tool readiness checklist + ade --socket ios-sim devices --text # list simulators + ade --socket ios-sim apps --text # list launch targets + ade --socket ios-sim launch --target --text + ade --socket ios-sim live-start --text # start the mirrored window stream + ade --socket ios-sim snapshot --text # capture screen + elements + ade --socket ios-sim select --x 120 --y 420 --text # tap → chat context + ade --socket ios-sim tap --x 120 --y 420 --text # tap as input (needs idb) + ade --socket ios-sim preview-current --text # render the selected element's preview + ade --socket ios-sim shutdown --text + ``` + + A `no-context` result from a preview command means ADE has no selected source-backed element yet — `select` one first rather than guessing the screen. + + + +## Troubleshooting + + + + Verify Simulator.app is running and not minimized. The drawer reports the specific macOS window issue when capture is blocked. + + + Install `idb` and `idb_companion` — they back direct input and accessibility inspection. Without them you still get the mirrored live view. + + + Run `ade --socket ios-sim shutdown --force --text`, or use the drawer's takeover action. + + + + + + The same inspect-and-hand-off flow, for web pages. + + + Act on the element you tapped, in context. + + diff --git a/tools/project-home.mdx b/tools/project-home.mdx index 82d0afce0..d3d3b4f6c 100644 --- a/tools/project-home.mdx +++ b/tools/project-home.mdx @@ -1,53 +1,76 @@ --- title: "Run" -description: "Start dev processes, run tests, and keep project health visible." +description: "ADE's project home and per-lane runtime dashboard — managed processes, stacks, tests, ports, health, and logs in one place." icon: "play" --- -Run is the project control room. Use it to start the app stack, watch process output, run tests, and check whether the project is ready for agent work. +**Run** is the project's home surface and its execution dashboard in one. For a fresh install it's the welcome screen that opens, creates, or clones a repository. Once a project is loaded it becomes the **per-lane runtime dashboard**: a grid of the dev processes and test commands your project defines, each startable per lane, with status, ports, health, and logs in view — so you never re-invent a command or lose track of what's running. - Start, stop, restart, and inspect dev servers or background commands. + Start, stop, restart, and inspect dev servers or background commands, with restart policy and readiness checks. - Run known validation commands without leaving ADE. + Run your project's known validation commands without leaving ADE. - See crashes, logs, ports, and CI signals in one place. + Watch status dots, ports, uptime, and logs per run, with a runtime drawer for proxy and preview info. -## Add a process - - - - Choose **Run** from the sidebar. - - - Give the command a name, working directory, and command line. - - - ADE opens a managed session, streams logs, and tracks status. - - - Agents can inspect logs or run tests against the same project state. - - - -## Good process examples - -| Name | Command | -|------|---------| -| Web app | `npm run dev` | -| API | `npm run dev:api` | -| Tests | `npm test` | -| Typecheck | `npm run typecheck` | +## The welcome screen -## When agents use Run +On a fresh launch — or whenever no project is open — Run shows the welcome screen: the ADE logo, an **Add project** button, and your recent projects with their lane counts and last-opened times. Add project opens a chooser to **Open** an existing folder, **Create** a new repo (ADE runs `git init` and writes a starter `README` and `.gitignore`), or **Clone** from a URL or your connected GitHub repos. Click a recent project to jump straight back in. + +## The command grid + +Once a project is loaded, Run renders one **command card** per process your project defines. Each card owns: + +- **Name and description** from your project config. +- **A lane picker** — point the card at any lane to run that process in that lane's worktree, independent of your global lane selection. +- **Aggregate status** — a status dot (stopped, starting/degraded, running, crashed), pid, uptime, listening ports, and a live-run count when several runs are active. +- **Run / Stop** — Run always starts a fresh run with its own id; Stop targets the most recent active run. +- **An inline log panel** per run, so you drill into a specific run's output right on the card. + +Cards are organized by **process groups** — a chip row filters the grid, and you can run or stop a whole group at once. A collapsible **Advanced** drawer surfaces the selected lane's runtime context: health, preview and proxy info, OAuth callback URL, and port leases. -Run gives agents a shared view of what is already running. A chat agent can ask for test output, inspect logs, or start a configured command instead of inventing a new one. +## Run it per lane + +Because a lane is its own worktree, you can run the same process against several lanes at once — each on its own port — and compare them live. Per-lane port leases and a proxy keep two dev servers from fighting over `3000`, and the dashboard fans out across every lane your cards point at. -Processes run on your machine. Make sure commands are safe before saving shared project defaults. +Group runs are **parallel**, not ordered: process groups are a filter and a bulk-action key, not a dependency contract. If you need strict start ordering for a bundle, keep those processes on a single lane and use a stack. + +## When agents use Run + +Run gives agents the same shared view of what's running that you have. A chat agent can ask for test output, inspect a failing server's logs, or start a configured command instead of inventing a new one — and you see the exact managed session it does. Managed processes spawn on whichever machine owns the lane's worktree, so the agent and the logs stay on the same host. + + + + Typical entries for a JavaScript project — a name on the left, the command on the right: + + | Name | Command | + |------|---------| + | Web app | `npm run dev` | + | API | `npm run dev:api` | + | Tests | `npm test` | + | Typecheck | `npm run typecheck` | + | Lint | `npm run lint` | + + Each process can also carry a working directory, environment, a restart policy with backoff, a readiness check (a port to wait on or a log pattern to match), and group membership. Definitions are saved to your project config so every lane — and every agent — starts from the same known-good set. + + + + +Processes run on your machine (or the lane's remote host). Review a command before saving it as a shared project default — those defaults are committed and travel to everyone who opens the repo. + + + + + Ports, variables, preview URLs, and startup commands per lane. + + + How managed processes sit alongside chats, CLIs, and shells. + + diff --git a/tools/pull-requests.mdx b/tools/pull-requests.mdx index 76e6a849c..57c7f8602 100644 --- a/tools/pull-requests.mdx +++ b/tools/pull-requests.mdx @@ -1,54 +1,116 @@ --- title: "Pull requests" -description: "Create, review, and merge GitHub PRs that are tied to ADE lanes." +description: "Open, review, and merge GitHub PRs from inside ADE — with stacked PRs, a merge queue, and auto-merge." icon: "code-pull-request" --- -The PRs tab connects ADE lanes to GitHub review. It shows open PRs, CI, reviews, comments, changed files, stack relationships, and merge readiness. +Every PR your agents open lands in ADE's **PRs** tab — the diff, CI checks, comments, and a merge button, without a GitHub browser tab. ADE keeps remote GitHub state warm through background polling while treating your local git state as the source of truth for merge and conflict simulation. -## What PRs gives you + + +## Open a PR from a lane + +Because every lane is its own branch, opening a PR is one step. Pick the lane, confirm the base branch, and ADE creates the PR — from the lane, from a chat, or straight from the PRs tab. The draft title and body are prefilled from the lane's commits and diff, and ADE returns both the GitHub URL and an ADE deep link so an agent can drop both into its closeout note. + + + Create a new pull request from a lane + + + +Branch names are validated before submission, so an invalid git ref fails in ADE with a clear message instead of an opaque GitHub API error. + + +## Inspect the PR + +The detail view splits a PR into focused tabs — **Overview**, **Files**, **CI / Checks**, and **Activity** — and each one loads on its own, so a slow comments fetch never holds up the checks or files. + + + Files changed and CI checks for a pull request + + +The Overview renders as a **Timeline + Rails** layout: a central event timeline (commits, comments, reviews, label changes, merges, deployments), a left rail with the commit list and push-time checks, and a right rail with merge readiness, reviewers, labels, and participants. A dismissible AI summary card sits above the timeline — risk areas, reviewer hotspots, unresolved concerns — and regenerates when new commits land. + + + The PR review and comments view + + +You can reply to review threads, resolve them, react to comments, request reviewers, and submit your own review — approve, request changes, or comment — without leaving ADE. + + + + The PRs tab sidebar + + + The commits section of a PR + + + +The GitHub tab lists every PR in the repository — including ones opened outside ADE — with label filters, CI badges, review indicators, and the linked lane's color, so a glance correlates a PR with the lane that produced it. + +## Merge it + +When checks pass and reviews are in, merge from the readiness panel. Pick the method — **squash**, **merge**, or **rebase** — and land it. - - Know which lane produced which PR. + + Let the PR merge itself the moment it's green — useful for stacked work where each child waits on its parent. - - See approvals, requested changes, comments, and CI failures. + + When branch protection blocks a clean merge, opt in to retry with an admin merge. GitHub still decides whether the bypass is allowed. - - Keep stacked PRs targeted at the right base branches. + + ADE deletes the branch, archives the lane if configured, refreshes the base, and rescans rebase needs — all best-effort, so cleanup never undoes a good merge. -## Create a PR from a lane +## Stacked PRs - - - Review the diff, run the right tests, and commit the work. - - - Use the lane inspector, PRs tab, or chat prompt to create a PR. - - - ADE can prefill the title and body from commits, diff, linked issues, and proof. - - - Submit as draft or ready for review. - - +A PR opened from a child lane targets its **parent lane's branch**, not `main` — so a chain of dependent PRs each gets reviewed on its own but merges in dependency order. When a parent PR merges, ADE retargets and rebases the child onto the new base automatically. -## Handle review feedback + + + Land a whole stack in one action: ADE merges the root, then each downstream PR in order, auto-rebasing any descendant that drifted and stopping on the first failure. + + + When a child is behind its parent — which may itself be behind *its* parent — the Rebase view shows the full chain so you can fix several descendants by rebasing one ancestor. + + -Open the PR, read comments and failing checks, then ask an agent in the PR's lane to address a specific issue. Keep the loop narrow: +See [Stack lanes](/lanes/stacks) for the lane side of stacking. -```text -Fix the failing lint check on PR #142. Read the check output first and only change what is needed. -``` +## Merge queue -## Stacked PRs +For landing several PRs in sequence, a **merge queue** runs each one through an explicit state machine with visibility into every step. -When lanes are stacked, ADE keeps each PR targeted at the correct parent branch. After a parent lands, use the PR and Lanes views to rebase or retarget the remaining work. + + + The queue picks the next pending entry, optionally rebases it if it's behind, waits for CI when **CI gating** is on, then merges it with your chosen method. Each entry moves through `pending` → `rebasing` → `landing` → `landed` (or pauses for attention), and the tab shows where it's stuck and why. + + + With auto-resolve on, a merge conflict during landing launches a Codex or Claude CLI resolver in the lane's worktree. ADE commits and pushes the resolution, then retries the land — so a conflict mid-queue doesn't stall the whole stack. + + + A paused queue waits for you; resume it when ready. Cancelling force-fails any in-flight entry cleanly rather than leaving it half-landed, and you can reorder entries before they land. + + + +## Conflict simulation + +Before you hit Merge, ADE predicts whether the PR lands cleanly on its base by running `git merge-tree` locally — no actual merge required. A predicted conflict disables the merge button (unless you opt into bypass) and surfaces the conflicting files. The same engine powers integration (merge-plan) proposals and the Rebase view. + + + PR sources and rebase options + ADE uses your GitHub authentication. If PR data is missing, check GitHub access in Settings. + + + + Run an on-demand AI review on a PR — or any diff — before you merge. + + + Detection, simulation, and AI-assisted resolution across lanes and PRs. + + diff --git a/tools/remote-machines.mdx b/tools/remote-machines.mdx new file mode 100644 index 000000000..8495705dd --- /dev/null +++ b/tools/remote-machines.mdx @@ -0,0 +1,74 @@ +--- +title: "Remote machines" +description: "Point ADE at a repository or dev stack that lives on another box over SSH, while the desktop stays your control plane." +icon: "server" +--- + +A remote machine lets you drive a repository that lives somewhere else — a Linux dev box, a beefy build server, a cloud VM — without copying the code to your laptop. ADE connects over SSH and runs the agents, builds, and tests on that box. Your desktop app stays local and stays in charge: it is the control plane, the remote is the workspace. + + + +## When to use it + + + + The repository and its dev stack are on another machine and you would rather not clone or sync it locally. + + + Builds, tests, and agents run on a box with more cores, more RAM, or the right GPU. + + + Services, databases, and toolchains are already set up on the remote and you want agents to run against them. + + + +## How it connects + +ADE adds the remote over SSH using the same connection details you already use from a shell. The desktop spawns a lightweight ADE bridge on the far side and tunnels its control protocol back over the SSH channel — so lanes, chats, diffs, and PRs all behave exactly as they do locally, just backed by the remote's filesystem and runtime. + + + Adding a remote machine to ADE over SSH + + + + + Give ADE the SSH target for the remote box. ADE bootstraps its runtime there on first connect. + + + Choose the repository on the remote you want to work in. It becomes a normal ADE project, backed by the remote filesystem. + + + Create lanes, run agents, review diffs, and open PRs from the desktop. Everything executes on the remote. + + + +## The desktop still drives everything + +Connecting a remote does not move ADE off your Mac. The desktop app remains the control plane: you compose prompts, approve diffs, and merge PRs locally, while the agent processes, builds, and tests live on the remote. The remote's own GitHub, Linear, and provider credentials are used for work that happens there. + + +`ade code` can attach to the same saved remote machines from a terminal — useful when you are already SSH'd somewhere and want the TUI instead of the desktop window. See [ade code](/tools/ade-code). + + + + + `ade code remote` reads the same saved remote-machine registry as the desktop app: + + ```bash + ade code remote --list-targets # list saved remote machines + ade code remote --target mac --project ADE # attach to a remote project + ade code remote session --target mac --project ADE --session chat-1 + ``` + + Run `ade code remote --help` to see every flag. + + + + + + Drive ADE from a fast terminal UI, locally or over SSH. + + + How the control plane, runtime, and clients fit together. + + diff --git a/tools/review.mdx b/tools/review.mdx new file mode 100644 index 000000000..b3ee39c70 --- /dev/null +++ b/tools/review.mdx @@ -0,0 +1,94 @@ +--- +title: "Review" +description: "On-demand AI code review. Pick a scope, run a review, and act on the findings — separate from PR comments." +icon: "magnifying-glass" +--- + +The **Review** tab runs an AI code review on demand. You choose exactly what to review — a lane's uncommitted changes, a range of commits, a whole pull request, or one lane's diff against another — and ADE runs a read-only inspection and returns **findings** you can act on, plus the evidence and transcript behind each one. + +This is separate from the review-comments thread on a PR. Review runs are local by default: nothing is posted to GitHub unless you choose to publish. Think of it as a second pair of eyes you can summon for any slice of work, at any point, without opening a PR first. + + +The review agent is read-only. It can read and inspect files but never edits, commits, or pushes. A run produces findings and saved artifacts — acting on them is up to you. + + +## Pick a review scope + +Every run starts by choosing a **lane** and a **target mode**. The mode decides which diff gets reviewed. + + + + Review a lane's branch changes against the default branch — or against another lane. The most common scope: everything the lane has done since it split off. + + + Review only a slice of a lane's history. Pick an earlier base commit and a later head commit from ordered dropdowns; the base is excluded, the head is included. + + + Review the staged, unstaged, and untracked changes in a lane right now — the working tree against the checked-out HEAD. No commit required. + + + Review a whole PR's diff as one scope, with findings you can optionally publish back as a GitHub review. + + + +For a lane diff, you choose what to **compare against**: the lane's default branch, or another lane (lane-to-lane). The launch dialog draws a small before/after diagram of the scope you've picked — which branch or commit is on each side — so you can confirm the comparison before spending a run. + + +Comparisons run against your **local** refs. If you want the latest remote changes included, fetch or pull the base branch first, then launch the review. + + +## Run a review + +Open **Launch new review** from the toolbar, set the lane, target mode, and (for lane diffs) the comparison, then pick a model and reasoning effort. Start the run and it appears in the runs list on the left while it works. + +A run moves through `queued` → `running` → `completed` (or `failed` / `cancelled`). Several specialist reviewers look at the diff from different angles — diff risk, cross-file impact, checks and tests, security and data, UI and regression — and ADE adjudicates their candidates into one merged set of findings. You can cancel a running review at any time, and **Rerun** re-runs the same scope after you've pushed more changes. + +## Read the findings + +Each finding is a card you can act on. Cards carry a **severity** (critical, high, medium, low, info), a **confidence** score, the file and line they anchor to, and an evidence trail — quotes, diff hunks, file snapshots, and tool signals (typecheck, test, lint, build, CI) that back the claim. + + + + Jump straight to the file and line in the Files tab to see the change in context. + + + Send the finding's location to your external editor. + + + Copy one finding — or all of a run's findings — as a single message to paste into a chat or issue. + + + +Filter the list by severity, and act on each card to teach the engine: **acknowledge** it, **dismiss** it with a reason, **snooze** it, or **suppress** it so similar findings are filtered out of future runs. + +## Review learnings + +Findings you dismiss or suppress feed a learning loop. The **Learnings** panel shows quality over time and the suppressions you've built up. + + + + Counters for total runs, total findings, how many were addressed, and a **noise rate** — dismissed plus suppressed over total findings — so you can see how much of the review output the team actually acts on. A breakdown by finding class shows how well each category is being addressed. + + + Every suppression you've created, scoped to the repo, a path pattern, or globally. Each shows how many times it has filtered a matching finding, and you can remove any of them to let those findings surface again. Suppressions are matched by title and scope and persist across runs. + + + +## Review notes and evidence + +Beyond the findings, each completed run keeps the full audit trail so you can check the engine's work: + +- **Review scope** — the before/after diagram of exactly what was compared, the model used, and whether the run was kept local or published. +- **Review process** — the specialist reviewers that ran, the context they were given (changed-file manifest, risk map, rule overlays, validation signals), and per-reviewer candidate counts. +- **Reviewer outputs** — candidate counts, adjudication results, and the merged final set. +- **Artifacts** — the raw diff bundle, prompts, and payloads for audit. +- **Review agent transcript** — open the saved read-only session in **Work** for the full turn-by-turn trace. + + + + Open, review, and merge GitHub PRs — and request an AI review on one. + + + Predict, simulate, and resolve merge conflicts before they bite. + + diff --git a/tools/terminals.mdx b/tools/terminals.mdx index 494590773..ec6a0d699 100644 --- a/tools/terminals.mdx +++ b/tools/terminals.mdx @@ -1,44 +1,75 @@ --- -title: "Work and terminals" -description: "Run chats, terminals, provider CLIs, and managed sessions in lane-scoped workspaces." +title: "Work sessions" +description: "Agent chats, provider CLIs, plain shells, and managed processes — every Work session is lane-scoped and tracked in one place." icon: "terminal" --- -Work is where active sessions live. A session can be a chat, an interactive terminal, an agent terminal, or a managed process opened from Run. +**Work** is where active sessions live. A session can be an agent chat, a provider CLI running in its own terminal, a plain shell you type into, or a managed process started from Run. Whatever kind it is, it's scoped to a lane's worktree and tracked as a durable session — with a transcript, a status, and a clear lane association — so nothing an agent does is anonymous. -## Session types +## Four kinds of session -| Type | Use it for | -|------|------------| -| **Chat** | Ask an agent to inspect, edit, test, or explain. | -| **Interactive terminal** | Run commands manually in a lane. | -| **Agent terminal** | Watch commands an agent runs during a chat or worker task. | -| **Managed process** | Follow logs from commands started in Run. | +Every Work session is the same kind of tracked record under the hood, which is why they all live in one list and one grid. + + + + A chat backed by a provider SDK — Claude Code, Codex, Cursor, Factory Droid, or OpenCode. Streams tool calls and diffs, with approval gates. + + + The provider's own CLI running inside ADE in a tracked terminal. ADE knows how to resume it, so an ended CLI session can be continued. + + + A plain interactive shell (a PTY) in the lane's worktree, for running commands by hand. + + + A dev server or background command launched from [Run](/tools/project-home), with its logs and status surfaced here too. + + ## Lane scope -Each Work session belongs to a lane. Commands run in that lane's worktree, with that lane's environment. Check the lane label before typing or prompting. +Each Work session belongs to a lane and runs in that lane's worktree, with that lane's environment. The same command behaves differently across two lanes, so check the lane label before you type or prompt. Launching a session always resolves the lane's worktree first — sessions can't drift into the wrong directory. + +## Tracked, not anonymous + +Every session is a row that ADE keeps so you can revisit it later. A session record carries: + +- **Identity** — the lane, the tool type, and (for terminals owned by a chat) the parent chat. +- **Intent** — a title and goal, often auto-derived from the first prompt. +- **Lifecycle** — running, completed, failed, disposed, or detached, with start/end times and exit code. +- **Content** — a transcript and a last-output preview. +- **Provenance** — the commit range the session spanned and links to its diff. + +Tracked provider CLI sessions also store enough resume metadata that, after one exits, you can **Resume** the TUI or send a follow-up prompt and ADE rebuilds the right `claude --resume`, `codex resume`, or equivalent command — continuing in the same durable session. + +## Organize the list, tile the grid + +The Work sidebar lists sessions and can group them **by lane**, **by status**, or **by time**, with search and filters. The view area shows them as tabs, a single focused session, or a **grid** of tiled panes so several terminals and chats stay live at once. + + +Grid view keeps every tile mounted, so multiple agent CLIs or shells run side by side without detaching. Arrange them Auto, Rows, or Columns from the grid menu. + + +## Tools alongside the session + +A right-edge sidebar follows the active lane and Work session, with tabs for **Git**, **Files**, the **iOS Simulator**, **App Control**, and the **Browser**. Pick an element in the browser or simulator and it's inserted as context into the active chat, draft, or agent CLI — so the agent works against exactly what you're looking at. -## What ADE records +## The same sessions in the terminal -ADE keeps transcripts and metadata for sessions so you can revisit them later: +Work sessions aren't desktop-only. `ade code` attaches to the same machine and renders the same lanes, chats, and PRs as a fast TUI — start a session on the desktop and pick it up in the shell, or the other way around. -- Start and end time. -- Lane and working directory. -- Command output. -- Agent attribution. -- Related file changes. -- Links to commits, PRs, proof, or Linear issues when available. + + ADE sessions in the terminal via ade code + ## Recovery -If ADE restarts, it restores the visible session record and attempts to reconnect to live processes where possible. If a process is gone, the transcript still remains in History. +If ADE restarts, it reconciles each session against the process that owns it: live sessions owned by another window or the daemon are left alone, while genuinely orphaned ones are marked detached. The durable row and transcript always remain, so even a session whose process is gone stays readable in [History](/tools/history). - - Use chat for agent-driven edits. + + The same lanes, chats, and sessions in a fast TUI. - - Search completed sessions and checkpoints. + + Define and manage dev servers and test commands per lane. diff --git a/tools/workspace-graph.mdx b/tools/workspace-graph.mdx index 3a2b35d65..104c5cebb 100644 --- a/tools/workspace-graph.mdx +++ b/tools/workspace-graph.mdx @@ -1,44 +1,81 @@ --- title: "Workspace graph" -description: "See lanes, branches, PRs, stacks, and merge risk in one visual map." +description: "A visual map of your lanes, stacks, PRs, and merge risk — rendered on a live canvas." icon: "diagram-project" --- -The Graph view turns your repository state into a map. Use it when the lane list is not enough and you need to see how work relates. +The **Graph** tab turns your repository state into a spatial map. It projects the same lanes, conflicts, PRs, and git state the rest of the app uses onto a React Flow canvas — topology, stack structure, PR overlays, and pairwise merge risk — so you can see how work relates when the lane list isn't enough. + + - See lanes, branches, PR links, and stack relationships. + Lanes laid out from the primary down, each child under its parent, with stack edges drawn between them. - Spot branches that are likely to conflict before merge time. + Risk-colored edges and a pairwise matrix show which branches are likely to collide before merge time. - Jump from the graph into a lane or PR. + Click into a lane, open an agent, or jump straight into a conflict's resolution panel. -## What appears on the graph +## What the graph shows + +The canvas builds up in layers so it's usable before every overlay finishes loading: topology first, then risk, PR, and sync overlays stage in after the first paint. + + + The workspace graph showing lane topology, PR links, and merge risk + + +Every lane is a node carrying its own state — role (primary, attached, worktree, or integration), conflict status, sync state, PR badge, and a live count of the agents running in it. Edges encode the relationships: -| Node | Meaning | -|------|---------| -| Lane | A registered ADE lane and its branch. | -| PR | A GitHub pull request linked to a lane. | -| Branch | A branch ADE can see but has not registered as a lane. | +- **Stack edges** — parent-to-child links that read top to bottom. +- **Risk edges** — colored by pairwise conflict risk between overlapping lanes. +- **PR overlays** — per-lane badges and edge coloring derived from PR state. +- **Integration proposal nodes** — merge-plan proposals with their source lanes chipped in. -Edges show base-branch and stack relationships. +## View modes -## When to use it +All four modes share the same primary-centric layout, so switching between them never rearranges the canvas. -- Before merging several active lanes. -- When a stack gets hard to reason about. -- When you need to know which work depends on another branch. -- When an agent has created several lanes and you want the map. +| Mode | What it emphasizes | +|------|--------------------| +| **Overview** | The stack tree. The risk "overlap web" is hidden by default — one click away. | +| **Dependencies** | Parent-child stack edges; drag a node to reparent it. | +| **Conflict Risk** | Risk edges always drawn between overlapping lanes, with the matrix for file-level detail. | +| **Activity** | The same layout, with busy lanes sorted and sized up by recent activity. | + +## Interact with it + + + + Open the conflict panel: merge simulation outcome, the overlapping file list, and the AI proposal apply flow. + + + Reparent, archive, delete, create a child, view the diff, or open a terminal — straight from the node. + + + Hide a lane's descendants; the parent shows how many are tucked away. + + + Narrow by status, lane type, tags, or text; pan, zoom, and use the minimap to navigate large graphs. + + ## Merge simulation -ADE can simulate merges and surface likely conflicts. Treat the result as a warning system, not a substitute for final CI and review. Re-run simulation after major commits. +Clicking an edge runs a real merge simulation and surfaces likely conflicts inline, alongside the overlapping files and an AI resolution flow. Treat the result as a warning system, not a substitute for final CI and review — re-run it after major commits. -Graph is most useful late in a work session, when you are deciding merge order and cleanup. +Graph is most useful late in a work session, when you're deciding merge order and cleanup across several lanes at once. + + + + Predict, simulate, and resolve overlapping changes before they reach a PR. + + + Build branch chains and reviewable stacks. + + diff --git a/welcome.mdx b/welcome.mdx index 4a0dd3c71..a1b2c46df 100644 --- a/welcome.mdx +++ b/welcome.mdx @@ -1,60 +1,127 @@ --- title: "Welcome to ADE" -description: "ADE is a local-first desktop app for coordinating AI coding agents across lanes, chats, terminals, PRs, and mobile." +description: "ADE runs every AI coding agent in one native workspace — macOS, iOS, and the terminal, synced in real time." icon: "hand-wave" +mode: "wide" --- -ADE is the control plane for agentic development on your Mac. It does not replace your editor or GitHub. It sits around them so you can run several coding agents at once, keep their work isolated, and review the results with a clear record of what happened. +ADE runs **Claude Code, Codex, Cursor, Factory Droid, and OpenCode** — every major AI coding agent — inside one native workspace. Every task gets its own git worktree, so agents ship features in parallel without colliding. Review and merge PRs in-app. Approve a diff from your phone while another agent tests on your Mac. - - - Put each task in its own git worktree so agents do not collide with your main checkout or each other. + + ADE desktop — lanes, agent chat, and tools in one window + + + + + Ship your first agent task in five steps. + + + The vocabulary, in two minutes. + + + Free, open source. macOS 13+. - - Start lane-scoped chats with Claude, Codex, Cursor, or OpenCode and let agents edit, test, commit, and explain. + + +## What you get + + + + Every task gets its own git worktree — its own branch, files, and sessions. Agents work side by side, no stashing, no context switch. - - Use Files, PRs, Graph, and History to inspect diffs, CI, conflicts, proof, and session transcripts. + + Claude Code, Codex, Cursor, Factory Droid, and OpenCode — pick the model per task, all against the same lane with live diffs and approval gates. + + + Every PR your agents open lands in ADE — diff, CI, comments, merge button. No GitHub tab. Auto-merge when green. + + + A built-in browser, Files, Git, and the iOS simulator live right next to your chat, so the agent works against what you see. +## One workspace, every surface + +The same lanes, chats, and PRs follow you across the desktop app, the terminal, and your phone — backed by the same machine in real time. + + + + + ADE on macOS + + + + + ADE in the terminal + + + + + ADE on iPhone + + + + ## The usual loop ADE creates local project state under `.ade/` and leaves your source tree under Git's control. - - A lane is an isolated branch and worktree. Use one lane per feature, fix, experiment, or PR. + + A **lane** is ADE's name for a git worktree — an isolated branch and working copy for one task. - - Ask for a targeted change in chat, launch an interactive shell, or hand larger coordination to the CTO and workers. + + Ask for a change in chat, launch a terminal, or hand larger coordination to the CTO and its workers. - - Review changed files, terminal output, tests, PR state, and proof artifacts from one place. + + Inspect diffs, terminal output, tests, PR state, and proof artifacts from one place. - - Commit, push, create a PR, stack follow-up lanes, or ask another agent to continue in a separate lane. + + Commit, push, open a PR, and merge — without leaving ADE. ## App map -| Surface | Use it for | -|---------|------------| -| **Run** | Start dev processes, run tests, and see project health. | -| **Lanes** | Create, inspect, stack, archive, and clean up isolated worktrees. | -| **Work** | Manage chats, terminals, and CLI sessions across lanes. | -| **Files** | Read diffs, edit files, stage changes, and resolve conflicts. | -| **Graph** | See lane topology, PR links, stack relationships, and merge risk. | -| **PRs** | Create and review GitHub PRs, read CI, and manage stacked work. | -| **History** | Search the record of sessions, commits, PR activity, and checkpoints. | -| **CTO** | Ask project-level questions, delegate work, and manage worker agents. | -| **Settings** | Configure providers, GitHub, Linear, permissions, mobile, and usage. | - - + + + Agent chats, terminals, and CLI sessions across lanes, with Git, Files, Browser, and iOS tools alongside. + + + Create, inspect, stack, archive, and clean up isolated worktrees. + + + Read diffs, edit files, stage changes, and resolve conflicts. + + + Create and review GitHub PRs, read CI, and manage stacked work. + + + Lane topology, PR links, stack relationships, and merge risk. + + + Ask project-level questions, delegate to workers, and route Linear issues. + + + +## Runs the agents you already use + +ADE doesn't replace your agent — it runs all of them, against the same worktrees, in one place. + + +
+ Claude Code + Codex + Cursor + Factory Droid + OpenCode +
+ + + Start small. Your first successful ADE session should be one lane, one agent, one narrow change, and one review pass. - + From 65e787299097f51da720613bf93aef0618a13d0d Mon Sep 17 00:00:00 2001 From: Arul Sharma <31745423+arul28@users.noreply.github.com> Date: Tue, 16 Jun 2026 22:30:41 -0400 Subject: [PATCH 2/3] release: satisfy validate-docs for v1.2.7 Force-add the brand favicon.png + logo/ade-wordmark.png (the repo gitignores *.png), add the v1.2.7 CHANGELOG.md section + link reference, and point the changelog index card at v1.2.7. Unblocks the release verify job (ci-pass requires green validate-docs on the tag). Co-Authored-By: Claude Opus 4.8 --- CHANGELOG.md | 22 +++++++++++++++++++++- changelog/index.mdx | 4 ++-- favicon.png | Bin 0 -> 91970 bytes logo/ade-wordmark.png | Bin 0 -> 72949 bytes 4 files changed, 23 insertions(+), 3 deletions(-) create mode 100644 favicon.png create mode 100644 logo/ade-wordmark.png diff --git a/CHANGELOG.md b/CHANGELOG.md index 5ed2e8129..70099e3a7 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -7,6 +7,25 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 ## [Unreleased] +## [1.2.7] - 2026-06-16 + +### Added + +- ADE Code: multi-question approvals in the terminal — arrow keys choose an option and move between questions, number keys pick and submit — replacing the old single-question quick-select. +- Mobile: auto-created lanes are now named from your prompt by the host's small AI model (Chat and CLI), with a deterministic fallback if the model is offline or times out. +- iOS: the new-chat composer now matches an in-session thread (single permission dropdown when space is tight, model pill, fast-mode toggle), with fast mode honored on create. + +### Changed + +- ADE Code: selecting a lane no longer reflows the drawer — single-line lane cards, a shared chat row, and reserved viewport rows kill the flicker; provider glyphs and colors now match the model picker, and grid navigation escapes cleanly with Tab. +- iOS: faster Work chat scrolling, with assistant previews cached for visible rows and deferred until after the stream merges. +- Stored chat transcripts are compacted while preserving durable replay and live output. + +### Removed + +- macOS VM runtime, UI, and `ade vm` CLI commands. +- Mobile push notifications; the app now relies on its live sync connection, and PR actions from widgets navigate in-app. + ## [1.2.6] - 2026-06-16 ### Fixed @@ -409,7 +428,8 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 - Initial public release. -[Unreleased]: https://github.com/arul28/ADE/compare/v1.2.5...HEAD +[Unreleased]: https://github.com/arul28/ADE/compare/v1.2.7...HEAD +[1.2.7]: https://github.com/arul28/ADE/compare/v1.2.6...v1.2.7 [1.2.6]: https://github.com/arul28/ADE/compare/v1.2.5...v1.2.6 [1.2.5]: https://github.com/arul28/ADE/compare/v1.2.4...v1.2.5 [1.2.4]: https://github.com/arul28/ADE/compare/v1.2.3...v1.2.4 diff --git a/changelog/index.mdx b/changelog/index.mdx index 804c404c7..f9893c7d1 100644 --- a/changelog/index.mdx +++ b/changelog/index.mdx @@ -5,6 +5,6 @@ description: "Latest ADE release notes and release history." ADE release notes live here in newest-first order. Start with the latest release, or browse the release list in the sidebar. - - v1.2.6 - voice input downloadable straight from the chat mic, image paste fixed in remote ADE Code, and steadier phone sync across project hide, unhide, and forget. + + v1.2.7 - ADE Code drops the drawer flicker and gains multi-question approvals, mobile auto-names lanes with AI, iOS chat scrolling is faster, and the macOS VM and mobile push surfaces are retired. diff --git a/favicon.png b/favicon.png new file mode 100644 index 0000000000000000000000000000000000000000..93e404347a67040dc17d0e89f08b80ea83a1b9e6 GIT binary patch literal 91970 zcmZ_01ys~g*Ec$JhajDb(hb5mq*5Xc(k(4HG$SyC(k0#9AuUJ^jnZAxLk!(rcl3GQ z_xsje_cCkN|I9i2^gcU&`}_%2RhA>brN#vS00i>yq}2fcRAdqrfQ^ZKoOw>(ARp*f zZOX7zB0Ni*1fE^P60F(>>P&lPGsfi*B zq%CyhEtQl2?8r1W043N4fR0R|AivbeF93j+jRHVJK2iSWWuyL2DJmcv?f<0z65?Ie ze?^iF*?iD()lpIenK{~Xo0>a*wBYu%clt{J5cLEhllB&_ri`BUb`CBePqF9!C_u>c z-)x@ejQ>bnZN;AJD5)|^IXYV~3UTvt^F9~HWn^R&bvCyIsY}cLw>t8d*mG-FS0@k; zkB5f`w}$|?qq7wc-|N?}d3gDG`1!ez6kIM|4z8x2Tn;Ww|7qlZ+L5+!F>|(YaB+(6ztciakmqj+4<9!#&;PcKtSb697bN9q z=jg2AWNKz1&L{eh@c+*GKfU~iTGhtW!cIrp#@@og1vw&dK3;yo|JM3{7yW-$)&2jk z`hOMux2h=5-wFR;3-F)S{g;beUU6Jep8wq{aomo5krDtv5+E=A=7T57UaL*j%inJF ziJBhJORjsP!^MfkTApMd06qXW`Pn*Kfn=T(5#3Sf55^ zb73jz8g*AeReuE5ynTcAqY<6$?F$T&l^DiqLS8(}!;}Nx+h+X)Se)+GQj1sZw7!Q| zWo^^pz+mmhZw+0RT4xTG#sOVP>=CLC-FDrTAGMO6e-dWNJO@#SkE2uIKi)TfhUzam zXzN({OXD>TOXhkhGmpPQWjSq|f4^~1Kg3SB$+^O5QtP)%JX`MEY4TkSXevC(8r2L7 zdSft-Y?847!@!EM;dc~PpecXB6kosW2p%IzeJv@^4uV?%!I2fmy$_fGRbJRn}YBgza8>vG}O7fqN&F>{uk z>jyHvwVsKGV1p?1CAP2wRb`s8C|bO$CdQnWj7Pe4Q}qm4=G1|swQ`e)EBxH z5wWP97%Wbg%1E&hz!M+7TmkN8USqy~Yvup4p&jh-F1q$W!H8>o%7svLQMNW87!W~Fx zGc8I8Dop5D&A_m<_lJ)*as@^WWOtSCb}DX&1dFzMQP_0-d3Csbm>Rdj=~Tm6^{e;D zedu;}CR;{`v2V$fwf*^?NAtQD$xbi_a@^0kszQRU-G94$yR5Hkp%_b!FT4xD82aOW zI_Q|`mEc7aUAAN~-~Kzb6@z^2SAtrp*N)go%P*nR;mU~HYA32;Q{|-qi@M*UuBmeL zantl~$TJ?_ky5yjCnGB?nhY^LdaZxEROZT4_8L&7Zgpvb7aGWZ9@Hz+9bmy5VTwK$ z*;XG$?OR4YwJx{J=qul#_&G38tntlRaR^R(`s>Spb+|6V)xbRJAR_!Vl96UPdBcPD z8h_QzF%j93Zw$sgs*eum^67*HY<&1Qx2IYtKETeg#l_#S??^aKMjA_@<3pbdGlCYom90>62}vphtrvH6mW z8+YWPyT@QSE0oGB@mU~;8dXhyOvg<;6?d7DMdH}sg-opf#wu0GZ+=9_Dy2omuai~2 z`ut?D^pE1UgB8~6!trxXpjP(R2V_i8TLoQ1}1uMDHI^q|&ShZKJM$!gS;HL-43C(ikN zB)3U<$fNl+TqfRQUNroKVk7VUD}qX0wt;wy{^3+3OuCw#9YkUu>cA*vd`XvJP1p(f z23(JqOJd+RDfjac(VGO>&mymTy^`GK@4}8KR#*G$SdE5Z?|_lRGAAyg!>B@doTVMf z%*$S<%5e;H-g>@&d=vtPL|`urErXg3X%Q_0x`HrxyY>e;{g>PtiArsOukmQH@Z#rY zpMKN)61)d7xC)#0&)wiiU0%3$puiHXbS57v!d`CiELJD~Jy1Sq@r&1@uz=#5RjM)} z^o|qByx9?=;r*bsi>Do+;Qul}T?T`wO1M&7lw)D{-KPY{mI74_n9 zdeVBbxr)fZ=&xxPrH+2?H5ka^Nbj|M{#lTqlADEF-1ZuLJ&fTyp0UF@p#8z!s7>_D z%eo|BD0Qj4+v`-|Iy@iQ`4cg^5obM5J~=thcfhr z$t<=&g*ja}){KJ}pb6c?lE2k;ZEDBWzW#onmJr2ZY6RIF$cr1U#Xq*`Z^6G=<_6Jf zTZu(3d3n{2TNUIrB_s%O7}BRe7KfRPw+2YE3idd!lis_K(9Lu9fB0aj)mF1z9LuTB ztUX>1;`JGGGP-^`HFBJxh&Ncq_bW|>{-(T6cN?K>Rlt=tTyCMek>)MGt@}%{-?6YU zZXIZ)mYB<5dy*ipUC3GLs=EQk7*ZJVhUf(08!m~$`*bh8=1a<3qH3AAr7m0eYsQoQ z5en;Wq_~x{X0gesjJz%6hH@Xrt=08&_X(cV99ib%;KqD)$P|PW48}T6^CO&#LanB3 zQblPiYuiOLpwlfi zZgbY3QV;?1F=*j@4L%tNVi5Kj;C^h`pcCHGPi*trFwc=F5&Qv4DJT~brzuy|6}lD( z&Ok5Hw50l5KS@@AE0cXd)Etq(&jsTIZJ&ho)*{qC{D8ZVhaiVS?Z@e5p0mnto}-i} z-=$$>BRH{EyWU|T)K%A_bd&FzQWJZUf^*O)GR%L@!_EOVQHGn2u2CvhD9r zHImNMb#rk&MT*??D?zW#Ri!+!?W;z;c&!7VI8DpH@dVOYVd)ee$e0%#50Xek?%8;r zhb1!yTi1>v_~X_r`rr5Wt)^r2S4pNsz9rYywJtWWah1P%VUUWXoG`cQAdU1Y*ft+$ zDHw=Ph*v3Tgd;u-O#cjNd6D^ocCp3gNWP`E-C`_>!(9DAF)!F_+ifZTs(hV!W80}A z8pCn}aoRuhK1(*~OO|ldCpGmE8=Twz7i;5z`w^Uqh23TN#1G3OF$t^2&p zhSh3X5Ob6;p|S@%k~Z^&EwuqP&*~6|vPT@ZZPUM&6+LKaP3J)WX*s&9r(?UfXO$d7 zWn8|}8ho=YNIN1mAWEy;HNbCx;N<1NQ-q(LBH3IiH?)fjSNW33aYClHk{vva#A3}~FZ^z3FQ@e| z`l*YUuwFazTA3K%TrHYUND>bXwzW-H?A+y0{BpHURGCk#lh>aGrzo^awrI5;*HzNWpM-NoX%!LY>9)W%Ex=Xz zqJVY%}vcS!r9)F{?xEZ|vQV!>Hl) zk`8i*IIaE-93vx77NjG*0|tiQ;4jTvYgh{1$aI__NaYlqn(Qo8DbIxoMv#IqS)7Yg z-$>6l^vc4u&|)WEQ;XV=M4Zqn(CX`$l7P)nU8JRK)jB40wvmV_zZZeq)i~T4(i<|@ z|0yP)1#dl#dlG3WlOMG-$_h8IIlq2v^!9Ks7RjdnLEwu0qvF#GcWgVzAhl(jO6s2# zT~qL#-IFxh-hyNDoC&YBH5*XR@esOESRR*rZH?P+cAiLX9LKIX6Z7XZEv%e)#^ls# zMo*S|W1v#a9jg#;Gx~`YS?7;SThB!B15J(ew5algd@efv4F5X(m5x!P!}wj9?2y(o zGi#Lc2smqwMm58it?ntp-gixw( z`#WaCA9rNTRDFW9%)d=jMNQ{UPS&|>f(e1bR$llPyD@S`B=)r2L<_REor8k9(_d1y zIR%-cU$(ApJ6?8GM(`p*Mun;RP`V z%Xr4V1eMoH`r;)=I*{Y&dbOavde7UY?3c+0*}OO+8tw$eR?*C#RC!?kD0#+DlV>wQ zoWfqq8W|aF;+g{Cuoe{!4fZ*L9HRt;4*ShXDy1l{DXna9mxXMe!b=v*aqCaeaiClcs)2zfY zm{s6Wv}Vm3zGChVOve$P5HgDERis!Qvp|4#uy{l$0m zw2=)A2e-b6!$Tr(s0gEsuu$gF!P6}31H!iH144)C`TYul%B3azZWK|iGAhrE9ivOP zs+Ls@G~N$iD5aTj+oGjA$=+ego5ah%ezG=W?J6I;bm_BFkP333^zgLGia77uDXzas zYVhp`{kkLj)Q;75#Gy3yJqvd?0itvI19JZ9bhPY@=*F|^;&OSxL2JbIk8Ki>k@xvb z)Q{G!&a@XV8+R%(hTbnCX+cyIN>Bb1X6&s}yy?UOKCm1@$CD*gBR=UgkYx zy&WZ2LI&i?@@9ofb6&^Ht>5Th-Nl_=?|S~sHua&OH|`M;_YSo?qLPg=l@JAbnyFTV zJ(OrL98Wh5O-Z8bSKLfbm3mw_6Vr>&QixCxK`M=?uNFl>_ltUnORc*w*zF!sB=B;G~$)7@L)O9u#y{`;kjo5jZ4m-u;ZLe5_Z)z=Yz zJB+Mmq>66X=F~L!qpwD(UxY1>kH@mB%;&#E0Vzf+tYR+ZHx!(n=n&X^SR7Y<+YrOH{P> zY`5w;<}>f7)Sq{ZW0>&N>Q~dv?N3{9PdaZ2EmCj8pm7wa_xP(v$INaQy59F8FcDnR zT+GYSyEUBSPY7P3FIyT`Kf|_)L;LXZ4A%f7vC+zJH9iC+7GokfKXlR;j(x|$$|%AMQgy|Qkoh{R$(#B- znUai`rXt^!B48U zpLQb5`h&L2lx+xzmJEcKYh*0f#J2N>&KKx4yR2u6jR2#mJbPt5FVjQc)(C8=9jTcj zl47XXQFlyk@eR45g9Lk)f^sM3q~w~y)%>_YsB~ld`(~2+@Af<$L+%gs5!fr&r#IP$ zx%1jbPp8LhvWEfmfeuQ7ck@O=%bq1`S@*448~%%4Nte4RrVfnzOWD-3(1>W23xPp_@3V_6vJ>XyD5Z9J!>DtN`VQq4&bS zU*oW8Oy|3z1(XWUlnvh1^uNyw??P&36XwXwX}I~7s7=OnNHn!C{@!Qry-diTBD)Vo zem}Oxc1*oc8J5n72nho}omY8mZAVXPf6_j9vY5uOaBloCdocFrkp9c+CL_WOy@mr4 zDCYXKDR;A8nn{w0XE;ow;OF1$N=r?AegXo8tE2qjY}*I+X98civm_TRD+& zDoz^8BwX;=E7w#}SLQ4(x}vg3clP8`H;vF=-3IRBx*G*!J*)OdoV;l^!iIMJ9f?9@8Vy*8B&1-8q2{EQdANs=I zRlcuECp;ml^*EcWUMGG>N30QlQ-NTbdj}e7mbD4&$wKLWR3drwie-nAo1OIWp!P3PzK7|{3un$_5JQx0snuF@$nl$45A!@PO| zQ*pd_T7co>GaBcT19^XV68}y?2+`tJ@hA20FMOp{`7uo^IA^?WYzx17*CE4W!&6bWYt>QB$p|B!C&1dnp9e4 z_xMG+e3G;RuxZ@$X~K3PW`&A;B0)L<2Ef$0C59h5Y~UzFmM*QUTY zV51cZ$nMzO?O0mty4vlzc9ok-ear3b=UlDNwWr@*BqlDfS`Ysa8C?w;J@#gGwLd_x znqykC!(ZQ~S_f%&|D3uERiKFu!z&{SAKF>;)X*XGsXIl`xAS}EB{2n@vA>OM`?oTQ z1E}k$lhLxc-il}+c>8}hq#U@*Tct#aV0k?*;z#Pu|cdH&hbRf(D3SD#57gsX$=VcU@%2lftw z$R6x?qIJ0A7E9;VLKk^1<17Wo(kt-tG*Kwl@O{ke2?H@1J`UjuXM1R0L%8NW+UppV z(@T^fGC7J#^-mF!+mG>3Zc_VECG50!i-;z&qRH+qxXAaU zFQU%I|96z%lBY#z99Qk=wji@gVqIhq(gCR<`*5$+x$XLNM9TJLXS-${!Ea$;Yt8Ir z0qBp(l9NTcNW+-Irt;h6zzlA)bnVOCuKPTf>y5QGYfWh5_{pbWp7REwEF7)0q&APO zBO2&d@#8So?L($;wv?xJG7O?7+IRy7kEBG0ah0!Ct{A_oyd7me;>(J@c^@{mCicqX z&{VU!ko`5KGb_@_L#FH@H`9kV_yot_Fu8Qo>*|AFnE>sggfKFRJ0IC~W^76PDS&zHqmrwA|E zdIr_e7hIy;A($6De({reI57&T=O>)L%j0RPZ>ZeCescbzUpX z_L+6c`m(hA(;Eh`wi@GCcb>VtBMfW%S#6S9yFWx!7S6ja+v@MvmO%*bEsf_3`cx*( z#8C@9>}XkN4LQpRzZ;2tQ?V zS_uV75WeFK9v`Kj?PdmG;?0IqTr4wD2cjQO+W?Nlk|H!-7WK!N4s{%ySLA>7o9G|u z&yuDHuI*6L`8zMcVehB?SD@ZIuW!poIw~#amF0pPWuCRQ6Rn>6So8OR`wWNp4n7x_ zhrM+Ek5R?0H*1RfVrxqi63-77?&z!4e)?6kE0q)W;`nHu&D)$2ig~-qxO`32-va^2 z^MEn6?Ksr{H^Agqwg3Pg)~frF(6be}ZjYsFg5xz27`p?eG5H&U#v@L0e1}$N%k!nj zgR0L*JVs3qBDayfAmxksB&#s#EauJ-KT(5s+$0~EP~y?t&`D-65s?dm;C{uek=P$& z#1Y7NK|m=?zVW#$D4KpGHF`LXO}ynkrTCOoi9-SpN*zg%g<(1VqQK2SPZZ4vx|<~1 zm)54YFcY4SZrMsKieDwWtpRVorvUzclh{$@Ei13Nc$BhFfD+wn0pI10z?NTBL z`j14sL%S0=-a1@)yDdr?b@-vUPNt&iLEpA4>0#_oWy?j6^65EsBxa0?It$)- z9pKef>G493wO`HLFmZ3=uf!)tg}~uwD5t$jnVdE>O0*Fx-rG%lgZQpYba&u4d6UC&dlW=yx}x1^u(`TJe4HWA0|<5llNgTx;^ z_f(%l$;qa)HL)!TjwO$c+K+ke!t_RhcMmAOXXQCWeA8DNi8aRlPL^)r{NSX&C$_rA z&)N7a=?CFBDhg2+n^A=!iMCKyFJjFG3}3Mr>k(uk#}@v)x+HhBAKiQ?a!UcbTTFv` z=c(%!jF7DSVIUamN|fpzy?}cJf|= zftZ(D!Vg^#F>K;Zxzvs z;Syt41NPpKA1^YwhnL&{@nQ?cf3>qbUUq2v#T&sh9keQT?s73U?n;T5AUQfP9P!eQ zbg8ca=LZ95#}4{fU%_JBS@ui#_I}qy@Ay;w=Ds5i5w?N|;m@B@-t?7Smwu@zFTWBbQ++Lp``tlwQ(K7VeozF<_|cIt zaE8aTBg&eHJEUm%LFxEFWPz?tN-`*fU{Qt`lo%0fE5o$QZzy_((v~}u-Yh@$fnJ`ysk#ib-Pdq> zyDu@j^QoTq2)@T^G^we z;oy1Y{mbLQ1Q^G`{1xxT?ixBH?KX!*BU3HXL+$zwS!%+4S`@AcrUO_IUCtoycbF`o z9z9WG@oU?Y&kL>l5$%qt*-0*oMo;Ep*QUMa?%p$WFvB}ATjJIvGUA{)&4cXj8}xF# zf`>t?Ea82t5rvy8DzAW_tVAk_^~wwNM$Rc5Mu}Ndx$dY?DfLkJ(;cu@k}1eueWAOW zR&3J3(%|v`&J;)|X%iVUjHXQytmdr4>3cwV@b>S{BljL~9eJDuDZ$1Nr{YeH zJY74PZmuS9(l?N}VM^zo?ErV(%V7oP^&KvFE+4{b?stV}IB2HmK`2HXTa5Z!Hlg+>c@~LjyHnV#(ASfrqGs=&kc|nk;9*N!VIl*j}wpERhKstK7;ib zIv0=K+gT(k#`k}K*=Bej=*|X8wzap;CIZe2^&mI=C~dg5C33Tyf5d%#3qQA{N(R=s(QpR)mDr|i2zx@p@P z6w1_YnZM2^zrLjXSyw3&Lom82^~wBA-p6`pwHC+`8CYkIOzwX1v^D#3(1!wwi1t{1 z7#|R0V4#*H@+(AxjMJHZ0EnPdcYOn#7#KRg+bbW8aa9P|ZW72CHtVg;cT0g7Bvp1z ztjS!v{V#f-EwkRW$K8N#yHih+;y`XX{R|hr!}O zR;h$-)fi7ss!M-xU9 zk22Wfbg)XL*x7mDqDR|e@drM-sxW1MI}s~ZK{Ps}l^zlCADj^2Y!;!Ep;_TGokZl| zUn&W@Zl91z-$w@S3QqJY{LYIYlw=E&o_-fg_SZg4PAS}T)yV{o@%tDQ4@6r}A5GbR zaIBw)0{4(m!m9{C`3I>(%gbVygF7^aKO)|{S?-;?Tg^IdpXZ^Ko)-sMq#lmmF|v2Z zRio_C!E2(e3pS1>9kK*xXa;i2(lIPQ`TyGZ)zjx{1mMr3`&Fdx5vs5o9Zn-sX$D{B za8i=n{ru)JkEV#*_cSu&(ATVWJjoWdR}OXE6)=p$7+FF(`u6f;qo%5d18u`s=7=wR zoNUU#)A4I;t3st4nf#(@n|Z?aNnC3!g@5y@ZAW5IU>dHjGu7z4kkVs{yb9m;hK(4g zPF^o;W6`c{%IoT`2xfJ;(qk-&UzxRyjx^YSq9U|-wV_Q1#p)r1X(13~dD0P{6 zd&JP{3SWjb8qK|BY40+9vp!+1T+@|b zz)t3hjFzvvpzfp4eRW4CR_>XsC(F?N!%!vf-<1p>XBk*-#?p`xJ2!<9{&Qau)PM5N zKSjsyPJ_|ssSrztQhk~J+WaQd+Wz8U*!~Izt;V%&XqmMsxRE z2!wKET|=tc)o#g?uM9}USgExjoj}PK7HMf5l{HID@^aG?a8TIte_}sgup1*Stg*oF z3K++K65N1vK-Bg6QozbC?}Yu~mdSn^E)Qc>5*H)t@MwV=>sbbuhsi6Coj`)ias z-m0iqD1s!C8Gg)!csrjaP|R#m?J&&ce&r~4@#4N#zTyPOMU8uLixJTnQ!n*uu-nav z0Kk|v9TO(ZMk+-;R3pz8(W6+t)Gexv$=u#eu|t2(!!|Gy4pyp%RI*@gr$sQ&QJ;$1UaD(y1>gIh2V{S<-#CMe#>)&2Ab;nOUNKxL)yl0M_u$0@JGU z>!K9G{~X~fV9#K)T;A9Q-xbS1ixF=ZI&B_3aA0cpKlNK@9s^M>1|e@0ypP70DK6pG z%T-0}A_OHRQxEB6%TT0hRQRVFO?0^=1u}t5fGpZeCzH|bO}dZuUPdh~moj6Ov?jkE z5p71q<>{Z6uG2Dx2gFx>9-H#h@iFwrk^`E0vp84(p=V|$ zC?{rhyfJUR-yu5Z1Azi2N-fo=7~VS8Sb1pmEIgBkUg!HqM44shDpNN)FZ~>G22^l9 zU$Nu1UTd&O(ov-YN!oiyz4-!zp24xR`-0Ii7xLv5Sbk5P@*;0zl1kK`A>EEO{EwYO zf>iH=w~t@YPJoLi_!WuHffJ~*4CiDI#m92>Ni6sEGWG9o&p}H@`;fzqi7d~Zip9zY z(r51Tg5(#Hw=6xRNe`Ix#0&%yT%li|-W*|K@Uu)&IYmmO%=~jD`}$DxD99@V4zWx` zPE!)Fx>t_gwbWm}Y;4J#!GWkqI9-q$Uv28cuJ!7hz6zD_P~T%(zG=3;)nv)`CqOAB zC2nR^Z5sH+J#PElA?S;xjx;+OO~kQ0Fjv0IDxu5Og@9rT<()w4KNtY9UDrr3!b`Zl z>9jyHy6;e`Vl@9xb-Nn-2!=3J0!-sy9>F>6!FEh zHP#+;Lrla?}h}gkYdLO&xG-*KFYCwO_hIOKqm3+ z5%iE&oaM&IW5e3%Y;gPl_0+3I|Lg?6en(sFMcOF$=R0-~9w5RCB@NeOH z;%;j8nk5*0u97Rp^NpWJ2|$nMk%5lTmS7@FgYt*h$2nzJrN*bIYAYR*K7G)syVKTn zPMa%@UqJ=;fsf-R_NYxEBSE)O0XvCx(nad zKNam(YfMtDsWV46lsMT;6MXz(wE<0rv9Ulh-of6F*fdB*78<9MF`W3roa+s9mV8o> z@OF{%KyOKQycfI3Zi|k1usKPT6;5cczGkFEu6_O=>j7=z?;)16N6psPKHvwQ<-L{% z(%gB{2NMlZx9g%Fy>o}L!#rCBE9-zjNYhzf1N0TDBms2tYCsrT!32o-2d}4NM1^DI z8wb_^pT4WJP3ksFdZ5M>*OnQDJwpaNu8&WLE*}aYJ`D=C1uGyXhW72(v z4A8q?f~nrpaCKOMtCeeG?E5*>X9Sr5G6G8Q+SPw}SsJ;Ox86HpKkMh9^b0wxdpX`$ zhYXObhk}_>&6Wc-$D?0gqYZvec^y+UbyRSb-Vr%I?A(*qy1o4@Fl? zuR6)?U4~SbYUQJWkQbMMc$^s+*7l@a?ncI~tc0LHYx~14h^P4Ma&lPFS+=m5g$0JB?N)6@h2}!$dD7QkED?c-ziKY4Ak0hzf;OoqaJ| z$d_gbv-X($Yqd9F?XNLw3l%}V<7iA8xw}|DvIsy(Lg506)4})Vo{p6v7~L1FnYZ}X z85Lq|^spl~yU31|B+B6;Bfk5*fjFyMGd@Nww9#nU+dkR5mkGCUB-n+7yIQy;Z!@GF zl|&*1aB3$%?_WB;dG4I4gnMK>JbB_; zwz6IJ%y-frGElVY`)YlJ?@N5`UShKt4S(Dsa{qSKJ zQ)Mtu{;Px6u!n;YM+PzIWGAa6k#f~i-!{y zP(~CF$&3X*jG(viXON5>V6!woF~z1azbeJoSC=^kDv>83e z#e-edRlkI=zihiV3l6RnCHo@xvG&B_m^bLb=BeZrR&iL}(MU^Oufz^v@>A~p|FFa! z*NW-BL=*=368*HKa8F*6I0l24#5C&OYS)`e3C%K1aos~fCmlv|^vt>^P`f3;m1*Z&Ik$m3oj22q1%(j9mIT6M5N)yqQ(V zLVOQUU~=1)cI}hS`zNX!`9DhmQjc7f`r8+knb%972|rgp79pL@$6~h3#v_f~4MQmm zxh@`xbJMFVqmz=M8E)ES47Qyj|Nq+YE9*LbmWpV5`+=1-=)t*$KiM-uj{;Ym@9D5G zTbY)Yu5YYHjD0VC7T?2E#5KL7PpaX*!j^J=4lGCg1Nd&#Q33=7=RkPe3Mi7k;dgaM zG7C?{~}7XTQT^3$Bi*Ic30RxcA}Ra^lO+j?KP_sU>llg z{xi7TM39eLhZmTR5(*-^hsO62o_h;Kd4y)zc$4&mU6dt!x&`tmO*$z5>q{v|VOS5; z5^G*b?;%YSMB2Vc&l@NbxPTB=In}F|;Il6Zz~&feHE-95jq&~>XxN<}06KhJejSs^ zq^NUl&c9^gt_JU1Bg`^^lyD`8z>up~C%<|ArnWgcqh|4&7_At=mS@AMlNQ}QDQbNJ zgMVl1f~{A7!tms$ov)1o*r!SI%kHRx23Dr~19Xi2ZQo#|#x?!{!Us zh7*u1O6quD>9&?4rnCl1zm`;%qWr}a(x#Gecr2R`_(~WaE?~c;nq&o6>iXm9+;QR# zu>7u?-`Idp8$nh#H>>j(gkUrw?uqrDvpm<9MKX^ldy;1 zqsv_+2?WPSDbcHE3f`B&g!f>sR!bz__Rr>^)NSuVUJ4l}A)K4A8?V@6~K9u--Txn~837uy1 zyQZobiSqzzERr`?^;8NsmhX4P(@uF!!8V0OF*f5S5e;JkQJsP<$|6dlF5wpLCLe?5rH0?Lr<)$D>jA1N;E zVng-b9}xlJrbXV4*m)S=top-vg1;Y#2PQnO;Sb+vZ{3$w-h!vOUH@^S6M2=cAGzY^ z)`_);(=1|5Z}j5u^ACsknYZhD@YUMc2MVDTmjs61H*ZDB%FvarcHgxTvJe-&j`;O) z6{Iqayo04cij3zGVbI+xbw#uGnT2}W(D{MY=F~%}EJ@XHHDl?8XuAeu;!*503HeIi z_u&D8PgQe`_Rqax=g(+QTxOmHRSgR-^L$VDr5yn9ULT6X_4^6j-u}g$9Ek8@NDEKL zzazoybQ@8$=q8?{ms7W0M!SKn`XXXub|pEF*7s!lz0a4+3sJN}Gwy*@5pc_Qz&6T0 z8!<&>ki0f3>3bh15{Z#z)e8ZN(|zyLB?>C|s;H9lhK5dczjC zYjeyF%-b@qfHmCMq9f!z?URXB&S)vLBK8!>tz%gx3ww0>Ek#;!eCrz*cvLf}b@z}6 ztT&a~$j+S!q3qL*rHlYH1{pULg^T<07i(DhXOT-e`F`IYl*PmG<_kfnP`Ba)nRUmYb9N5el{MJbAG)c78n|^@F}a zFkcCQEHEhT+35z3t}J~faGu|SF74$uB&W7}BBE%(WFDCOrQy$qpR$gRpU4@{qS}2* z?|p^>9|jl*jx9K-*I_l+b;ZHEC+iaP*N6W(bI4QYO&-I5*ZUnXPvYry-+Eoumj;&0f2BZ3Ex-p@5gq7H*zCg|=v^=hx2Cjql|Kk@h`1S5<5t zKx#RH5T#=>gsW%0r!8Fybq6f->Sh2aK&$rRbk~*EN;f@|nNvwCN0xC+maWNtHRh_Ur+RL$XM!ZSLfb%-E07I zzoiS|v7IGgn_^8HZ+>lUeu5H(_^OS%5T(fxT5R~ajy{NBJ8zrV^kk?pW?Bwq z{O*Q$q%E^cRBHzL+J%r8sDePkWflox4!%`3d%78kH`Ky9R0l~n#nz0DrOL}>ZqL~= zJBQ6s8&IKtjy~h#ohmmV+tQ-%?u6Fe8KK>yJe)ANH2)3A{QWS7W4vwL^b^mZ&o&KK z5o?9OtZyz&(ES#i55H-Zxfj4M*9HBoS9=tr2BTgyXv#^RZjkiZyhj{A$qVD-<`&$p z&DYf;pZ_`f!VS=`^~27~F1y7!B~vOkuaC=l>KW;ml~w2tw(FgK;HRo<;?3e8klA?W zl8Yx}*6CeKP<%s~Q*F+{|GNCcsB>JB%W^r~e#Bzl()CPQyH-6v+35%tNR1?BKcRCF zT_1IrdSXA)`6Lre?z|+(1K5LJsyg5*9v@0QI_4>;19^O6Iq9^2Ea-U2(*X=~bbHLm z!ucnU!Qg47K7ok0K`zB`J8;IZtz4gC9PN_B^Q5dFsmWHI-vQt=bmw-|Dai%!j{NnU z@rO5@M$a$} z*KV^z8L`&&LlR9lZ?G#z-aK%(sM3KY0Tz|04!Jgc`*l8MhB%-b_F2|*{@@^ z5qA=t3I*@oUI?YC2z%T*wlxQnmZjEfdUu|%v)hriqTn0JNEpWaS0)1Sp4Lgi!lKI- zIX*4fjGZwx3mn9^YK!wz{pe`#l5V9FIjp02o=I9oofjw z+j$}30!CN8`y9`An(b{{xUlv#P|HS%iws>I1V+(J+GqWa)0!&zPf5)ND{bNrx9}Hr zQOU03AzlG`==z+RHaOX4^=7yN&R5cy!lsvkUM0qM=A;?nSR6{HmvurHt2%gWmz{C= zfhUaK<^{FD^=UD*B;(n3h&{2Ue>Ig8P=ywky!u(*h;2v~N`?xM%~b6Q`Efl5@Y_CZ zlh5g5PVB6>Pt+`^A^Hc(JpB>P=D20P2=}!9tlcq^hqwyN19zF%iMwJK_RpP=vdL7a zVLsq*na`Sgd|OC8Yu*K|pPqg6taCa;OZ<#we=y`f9siByd~WDqN9bM6_ef7EXiIgk z78kn`*Vbk0SXAJ|I@KH?o)d;V-iM?7*#l0Hp(J~ao6as~4bH30eG?ZzDUCK#Z|uTB zX#%=gC}$4r2z?<|RGb=N=6hL^kIIpy%f@5h&L8*@ML_sMr52ih*%hD`Bp+*Y=)a4! z@p=G<8K;d)jSE~+4HY4T{oDBNX>Q7S$2tKjP^iq^lo2mCCJK5`%&WT$-A@=6gnmRH z$d~Q4|6DTqg#KqnmDp?kP;}M6@$ZTxrN|4G8YhD^OR5-%emS-AWB-^5lg=+%yK)Y4 zs)DzE2+C>dzm912gPo9`-euOG{3f&5v;Qw_I1L;^jqhW%gLbja(eO_Xu{)pa>D^9m zmEFl@;aVS$RgdP2bGLr)m*|`GzzkE6Y#Ia>A++ejhYTWXHmvELOiHd8xIQJAQF;^R z@Xse2G9J)hBG^R?h~0sN^RhDlv8-PbqjT=|Eh|@B;g>f1{zD7Un)<)|Wun3Fiz7dK z5}-C%=||QB6HXME_43d2`^I`?XL%WD)|CH~gtqBdYwO=%O^}n4W(PXxm+US8>tCko z+T~cO7W?{~zUXTA-_3o(k4P$>B)_|t7J>rI=L&vbQ9gaIX!hT~$IDb3tA4?XoV|9o z|G$aBzlmQK+FkwQMCHP;=@GCD@-UQt!qVwgLt_mHwko{_-Ua!aS+_iR5z9_HeaN{T z%rFg;5i2-+R$mgGHU}h5Sq=O1lo(|2HVQuytAUsCNM7T?FsX8=&;v4%y7_J-n71#$ z#usbm%B)a%(NtNR9~&@&8xi(@+oJq(uv2w?cwSbBEW;XKU1ds@Y>3q=n89fl>cLbZ zfcaM#FZVe3na>YFsI8)8Vf{u!-@|y-+=hOd?dOw67+~P|55h3w-=h-Jb=LylJC+|5 zws$<|Q6}qFko#(Go_4#FR=eKj>LFfvYB9f|c)yheium*TLhjRWaK``d`B9rh;E zm#Ea2;_4%r)H%D=+UixICp+^>+w4wL4t4XGW`{Mm+hL|f2;MM|x3@EF0VblktulDJUkt5g zgG>3x%WRrh5`gu4+S*}HUKCs4*H4vUG)~Ghp2Gnw(3`GPD`4iH**LSJ&yD;IQ0yMA zM=V69KNo-tgt}bTf)5NRH+uAI>Llp*PtA+x&l6^K-N-Q2XEjZ@B(w`q-_V zgqFUrXFU*~|2#{M3qWQQ*2V_bcbinUDV2Aea%M@VpEq_{SA+Qh^QY2X8Lea47}j(D zY1xd5hC(bHGvdygnQPEvDrn1XU)J-~px@OU*N4=RANkbi;g{kWG!X$%%0OM8_i;}D z2iyJtx5=pZYB41%t1d?iWqxPYs=Z3^R_u@nJsEoIml^hD{Dv%fb}}0x(U|VXYy<2) zCBa!Z09t8OlO*$>>}veOXc(V=J=jm)L61dELWmDd$`pH>R8+za5!=RJty4Iv3U^U> zJc3#j52g(z{;|yYZ%3wY2|b%h^%f>qyFy7bSDroG$}jiu%j>ady4A634haC|e$V>q z=x)BnaN(dRB{wn@RbDqi*Ra4BpqkMJ>Xr62#ez}5so=twnvOK ziUW+Yb1NwK#2TQExCA8%FbBf7`4&1V&ZwAk!H(paUmp5zF-=_qCYaW(c#&}iRUP~h zSFt0kV!@2QDmLw?^k4=xjJqwwU#^P4tp&#*QVST`a-I_bqHHT3J|5Y3;D2yvdnRM< zu;3XaGmfO@mr+mxi|`0e;2b#9T+jD%4IhP}<0L5A(n2_Z%H-{Eo=E5aI#GR2=y06+bK|5;>Or(!8NFrRN#VJ_e3f|-ZQlSD<#&oqWgP5) z|0Rz^u;L_=-Y6;B_RyV_?JV8XIgC+1l)KN-&{y`!ynA*r3`eN3dbW$hQ99t@|4UBv7S7IIc3|BE&$7r~fNb+0;)|*7)ot zq`j>xiJ?&F?ADQ*%s>6jUnmdFShKsZPoq&9Xzc;as$uXT8FKy$^TVCpvRWx4vyAA! zQT`L>%fR*vACa}f2|J`a*d;gnp;KDJBtGx)qC)HXn4R*>GRMs?f|421_ve80S5%oY zjF_WyX9tJEC5Oo@f=iQp2jc(b$EL;~()FP(_0zsHlKodyM~2eRSM3f6-nTve|_$jGK8ZjE@cVmc#MWlF$r#{0z1i4oEhoWCrKK5>c3NhyQQr z`cXANK#Py?@WLY$4Hs}T%?2|2^!_NlP?sU)b>AR?q5zZk`1xH&S?Xdu2l-y{Y!^i`o z_Q9AQHkp*@r*~L||N7MY_Z=!}@n0=t>Q&QlXG4>JvPPU31r$|>-ehZ_9Zh6ReT>El zf#X-r**J6l5Lvaf%I5Zp+=HI8#@EP}!1(zR(YLf#My3CspktT%r~RG1;PNn73XfR^ z6dz)o9Jsh^XNz38hpzQkJF{+g^c^#R>0=Vm;HcRjAH<(cG7l{Dv-47UcezQV$hd%( zBfP@lF-Wj> z79tjje$RUTLgAb@kq$5*Z1ENv7ZD51MMG}laTw&yn6_nbgQQd$s~j}eb+AvGmd^6d zKAtURTOifZTtCd?b7)|y|>e0YhB~r_OVMd1}UynZ&2iN(>9yPb>rB z3#B@cj4?QvX5O{^CG38gv=9-L&B5(JWgg(Da-(!yO~@%K1SLO%mZsH}$1?3Ec>x}u zxLDykiAW26g!Y~F#M!cGsB}`Yn!Fh|CT@Uod$Oa##^{u=QXo+!ph{YW&myrn%)!4B z6dg6#rXa>e4)yNP+4%1cCv-jaBiKbdR8k|S#cAK_DRQ+Vs>qE6<$w8}M=dU3dEOmx zT(hajQ_7kflUHoC;gVumRx>3X>`5brs)R@mmyt?C9>vbohY4Du{tFMXLr+cvGw<=; zjZxxtRm=1ZGmATIIlQpHq~9DQl6!&XS3A=6kFMQa8s6%a(DDIU!yqK9Je9-`2xYOF zoWlOaqt$GDCb*K%YDQ20LPZrK{F}1&ss>8q zMz-)6O6$hMCYV)wz_#+vq;kmv{)Kk$lQznPXbb07K;84mk!U*tZycBeIWX+oJJ=sP z{dY_IQ|@nD__O2Uf|Mj|*s(5GHB5fGm#uKmY*>pR23kAwamEEjT-lh`{($CwNbw5* z`Jry_Z)c?MSuK!nS;JRT9n#jEqbsXrjWmky*76fei@GK2DA!EY5=l_pygP}ys6-`p zS2zHWwVJ9sc8-iG<|L`q51WNqqvRmX1q$Cvz-GAVZ{zsFseP<+r~)CT80MGcxQ3FU z@0`&#`4MBX?s8)&yGuq#a>rD}nytxJSpP9L>^B-}LV`k`uln0`^3fM{-j|b8S8@V} zi++$vHDnYSRTBvP#2VeYBMZY1{Sop(JD>p$ zX^D~hWM-tk=m7{2N!Wv9`mleTq+V4%N`H(N}Aj=JW@qJ;+G4?ny-QPuy-c!<6`?i zU>rL`A&w0BuHbuZXI_ADgP6ZWIAcMlH_gt=g&B^GcP0f?GEa=#B9xolb-^FTCYU1& z6iN?Kw4U;3f5pA@GkiUSG@vLY9<+32%2uSEOcrm@W8@fKt=ZtBBsxCZQ-^emN4#mf zTN1vEPGydh{Cc!WujBq*q>6rz(%n>riz7(|H58 z^TtwZ?kwnjto!EVF`n@QgY<&b66E@m(%wjzS0E4hX!eG(Jkp-enI`y~ZW~UFU(0M$ zm=uoU(7&VpZv3EC^u{wEF@7j^!UuD75i z6ECpNKsv|0r!9%7CQ~}*jmk*&ARr>fn*-Sn^1rl09S4?Nmm9^~WbS23z_g6+!3l6u zp;kSxhEP&t!XX>tiXIs3len>Qg8Nw`+49kMe=Zayo!pMumN4qd80Sz6$-B1T9N8EK z?3EAQQrjK3_L1wV@&?%uj7@fSQuvR(C(XGZ>Nu=7e^i+QTT6kF4bedwvlH`ZX#1?r zKh5R0BL}Q&bb(gTb0mq#VudM63H#Pd zCxr~Bqa?e!%V_6@H*B&48xv+6^>u6$k|PG=uRZLd+TZ)xd9`^0gh>t`tn0TNzCni7 zO7s?7L7u0pGVK}5k7j=y&F4u=Ubl(oq=SgOoNyOA@)3V^s{8feK|!sL3OhWpon_Qr z#y?U~s-2wNZTyqV_GvtxXl$C_xEx_j-TQ*+j+s&?FP8bPHZkK=0Xw7nG-Nc~e~1Sa zZsAN=6&<06Lk6QpX0!tLhhn{sx@R7!_N2#K$g&7EgP&W28Gt*S^?L=Y+^hBQeQAW& zVkY4$Oqz&!7>SrD;j8Zq(r~6QP2$@SP0QUry;w9ETG&49Ac&oadu^I;$Y%B|{ev?= z{m56hmD7E{LfpvUb1(NKiWvMDd*V`(H8USiW+E==jA6E**7A?KI_xEQs*SVVtX$653 zp%xoEE))4$SIV^=pw!MC^^i~;k)0jziiT#OGwSgEZ?7-e)>nS-eA#`|4^>Z11X#e# zC+|&xmwJb&_1#M#<2=>4d*$1rWgTQaEvAT{wTq~2VDn>%=2;)%;#ic+bduAf3z;J4 z+&cY><#6_b_*)d)cSbjCel|yPWD1eV!AKU>z4Ru+T^$6&fryyF=n*s0mv59I zeGRt2BjoUOSh|H5Czf6aT>d`7c)N@>7S(znMLA7X zJE={I!{^;&pEoLm5JL^UqL;%il%02CaK$j5BQW@z_-1NAGm^a2x`=pEB(i>KxG^77 zQ+T4#JNvcygW9ap-aW50kDh(F0T4iYU9gAk{7a1jxj#F$J`mA^4zM1k9FXq6MPmh(Io3-D?Wm9gq<$oQQ ziQEmMlV`1Z=qk4XWI*!@HcIS1tYNr`?6?F!K!rj~q+`tEAjp>$AS^)QCSO zn7dqdS72~wZ-$UWps!#4Lw@6TewYLY%AoZ@9&0H^zvy&i%*4z-3=<80rpM^fg3a?3`K(@mS}o? zZfPN_r1WaMCi&JyjN7?PPXV3Ey|Mcqpe1YG+ycoM><(D2K$NRP`!6DiBJ`ME<>Dzy z!g!}m?LtJ@k;xAtB@i5xdVR9VOe4@};wC7@!==UG`!jfJT+#dcJ1=N@a+!)ybr@v% zt)%C{k*u`Lv{Dd_Q`_6D3Ter)F~5hqCK;E{c94Gd)KphL8P8)WsEXRTOfb6Y!X6a` z)J2|61P#~bFZkH2Aj(B17JvEb6+dtV)Hv^EIimhZX5Z3pvQ+yHmes^A0_CzOtrhE~haSN;* z7^6AG#$QC$%U=^+8f+Fe#NufIc;V9ua=|#6js@OnrUOUy_|2rNQG#+jb265sCKyWgmC})79x!9IpBQPi1V}{!#`(9yJP9O%l_zOj z04VgcFsN`4IeU1j!YG#6&jFzE2rnqYb+YjhH>YdzPSL9xU`x;SJ2Y*{{-bQ&U z^EW97e8^?Dj5^yv$dK3ZFcs$LQugQV*(C~u8VA=}t?Q_{BSkHkb$gA^{8isxeN{e| z>nFH9-uk!8ThD_f@15p-%OdI`;DDOM2MhbV%MazVvL*l*J>|>nr!XN! z`P?qZcHy;WB`IdFH*uhkXO(Vc?eZ#5(HZht^c<0O_LImvGc5JUJ3{w|QDEU&52LL zeJYvf4S5RX*C?CW7>l>)evP~+Mro3OYw67R{EfF06M|K{8!qK1AVqg2i;KE4tCW*H ziG#{Zw!ec+9Lc4^;UNi08e#=6G5(YA{1oih5w6bW?nBWXzrDVD@$R z%1~?(m^QfnN3FvrZWygmq}Sr+K&&%1D|)ILu;agAJdTF3z`0D#OdyzFIu3id=^!=& z`~&^=kn<)AV*H&zj3}SUN=!{gLg%)&jBJ7QC6Nk|dbz~E>PkV_kD1Ia44tgxx;hrp z>~zNMz|f-=Vyy*TiCtA=C0UZkbCcQDlE*2Z!{Qmr5kN3G1j5tK+M|}~=tfHZEtW?p z%Hrt=l#31gh0@c39P->i&N{*B_k-dxvG?ou#jo{aL)dv;0J-f)1G$}N`(t>5%97t> z{?;xu#|fdymA?!novKln z;ci$yks>MR&ePJhsBZia)Qp-70QLNvR2p0N#=%Y* zJ{9ue*wZGoR4l;jKaoKCuFZ9X{qX^p+jS`%g?r6eMA|H-F8Pl> zhxX9+YcjSk8949*QRJ$3bdcqCnh0`VAUJ`)zvMsW>RgAc{1j2TLAdFhyMA%PZQ75v zrt*j0w#OQJ8_<@hy(UEMC6dO%MzOoFySjGEtzzX8CXnpyZs;Sub6=mzV(e%QckS+UJ_^lka>w-*3IE zD73F?=sQwWr};lDrD%qfhqJ>E`Xt&youHY-zwZ~=jw}Yxg10M(k)`)Tzet8&lCqsb z`T1V`liJ4i9g6K{G|4NWG%QZE|J^lmN#OW%&)DLwqgyF$=%(Ww1T+NftyMkmtHiW6!|whblW^Kr0OEm}xIimW=UO98emW%=U}kZ6qYllO zsS97R#Wl16uHjCTxss1*W-Qwa3p6C`cr9_tw1^3xbC%V|1j_dm;1ON)W|85KA^&UM z(@x0QNVFRP&Zmt0%*8=e*_<6tt(N0`? z73I9Co(k2`%9#95$s#2+1h+0e?^eT{=K4w+RLGnnmrV|ARER4|FpV@Rm)-5C0bm1? z9|yE=P+%z*8=)O>mJi6>BXJ7$UWgbnljt1Bdnoyp=|>9gGg#6=JD3BnpR3a|Go*~@ zhzbcuB>S^r^5mSy2F99_*Y*Xxiv9tZ|K?Az)P_2mO6%g&%-khTpu@^_a4;xNSjx3L zPPZvK`Av3J+*eWU%qRLB%nAAs_XfTNH0@vxH|WLNN&EH2w~285W)5H9Q~u;ok3hXv z_f)?apr|4*4*M7kJbYfXNlqM(0Q?_B#oPK|G|zJq45Sf7VZAKO6`x~6|gEWc=|UR=1fQh zgqIh)*WR5Hx~(YqWLjC_8kYJ-{de_aDYuDEK0-!Co=&gE1*6(4$M&W9-YTGKoUPV< zf5GoL`K2$eAeLqB=DGf`UQNi4vCA-8zq>KwO3tZ9|-FD}P9kVab< zRV9-mes|8<*7uzwM@1sizfKzuIBKCIKrdf7WZdjM%QThh?n(;C1o(6-7nUHsG z1+AfTKTaG{H^>8OB=DJ9FTA?MvTIG`DlHo3)@I3^?cZf-Svo<^l8$_v80x}e#5w~* ziVwREZ|?Va`sHUtd@U4T{X3PBF-j;3eAVHV4M(;NnTkG|wVW;JT*4jmOr%tgf-T}> z+FNwa^l<|*Q40)kxr$F`vm-9BeS*_JkZNa-9;^=_Lt8h zSG(jmhCM%iIilBsD<-0Xt`h{Zl%o(|y`a*rcBE?*HucWPWo8@c5&~M|W$chrLwmGE!c^Qogd zw?AdU{&gVmJ13D#p+~@>y zK1vx1EQdi3Ez{#;Xp?Umx&5vff$yU!tI*-svm7gaGZ%nQ<9m~c4z{(A?+~r?MO?UU zCC--}7;`4`wWx{UWdjsi*=|XX){4B)0zx*~)XFi94w#O}E zWxMx|kgyPyNb+~O<@Wv8MVm2^>mnao#YYzB<$8Du5g{31_4Mel4!8$PHT32=Ad z`w#1hBKwf}1qlESO#T$~?=#(eMkVnJ=F^c!-F*nT-f}0lA1#6JA;{VEocXSz&PXBW zkCVF7dk>%B9z=OOwKp1j~J(h>W(mX)UY&Eoc@RKxb5zbV5)TU z@UL?t_vFlS)Cba((u-1!d~L)v5IqGZeF-(9xdn5G0Y&u) zYE7wi>@TtXz3ZB&D>bftr*A8O8{9}N{QYR1-KwV|cX77qe1Xm)@e=(QV(NeeTC9fu zy7SxEj6aBys7zWCpdGq3;ASWo2Lk zrGi!xzmN+gUtxH;WR1>Y`s9wh%DYWbsGi+N*dYVr(sZ%dg?cjVXIRrStOrmD9xRTBCmc$Rvg zPz<%{u>HwD^xm6WX*R^&uR{AbXnhdY(42*#2h=_Ky{0eA1CFFZmGC}m4uvhqmOP*q zq9_udhXowGq7vreTJIk6Kh~xkr}5ayV%vU!DD9J-Mx`3Y*x9#Ca3nkE?J{Q>s;;@SsCMVfw4-?#nSC=52(LH42gg&^tetP0`o8nJ}fbLhUoHKL`k`| zh``5G@6*WhoC<^yo$oR=)^Wo(sq79m?0fmOk?Fop(_#y=xDD{l<4%KBeOs-DJB$RW zgNCR0c0Je$H;tl?W3|frouzyMPvJ7a2 zDZk2PJ*#elH49k7RMqf>wz0r(H2YC_$^vkzWaLn{^gLT1^ql?LX%g88I>V4m4>Ab& zE`VqzdPdFeOkAficx}Xav%H_19c4Mc8)bp8LH;ZZgo$CyGm!G6 zTI%-c)A2?L31WYd1YvWi+{(*T>(>|V07+*Cj{jaGHZ0?i@Hnh~=+HI|IV>2FxEMO( z31qs4=x3OZ!*tNbuPpd1{V;&jHn!URu@B@&R1nr_q$$L~;(xB+m0ZVpPW>m)0Ilh- z=PNTq8R#D^uZr&`(Gqaoq1*D{&fvr7=%QeXP4Lkp*E)34vxTxX(9AXX?DDZ~Hfa+m zZO3>R4uh7R*9IBu4*17@JUj<&0__{`5d0qu?)VY_OYE6@Ocpg zg@uxx`2M|DsNE`xe2MvX(yOlRV-e*MdXyC`$=?xYi=6AHbWW>>9zdS?B43u2&jJ$5 zToFYGiGmT#Mv3kMHGIyY{RhHxewe#43q=C-{Bt3s8Fs6V)sMKy{wD14WWo<7>*hLM|aDwS-#z-BJ1$SJ?NAhO%SV*936 zcy5QaR-Z!T-VJ-vTI?elNfRt>1mR(oE~3e%4Gi`!>hkB3sr)T8L&r7)RFRGvSL_mn_bMu$jkT8boe8W)23}{Kd5jf#Q{DebqSSU2J*JzUrdWy-h2z$PX&-;TP$n z=Uoe!x(JACO&x~33vbOq@nU^UlCcfl_qq{tzRyB$ND@UdG!(s$9O*OH6y;OxN1n02 zyu}Q5=W~gFqHhT*Msw&O5XsGp`jyu@y9K|b__^ahefvFaGpjZd|9G=?bhn%@^{A<- zxT(3g$j$U;6mVz@hyNxP&$oyy6qX1!n6Eb&@P{3k1*fBj0r}GBZ?%@fv)1^+?~6A` zLa>1&i7XXgNF~q8-m_2Dt$c3jeEL-BW>Ne8BD3A>%J6XV$hhvVtQ~j1KJI3-9gILG zBb?@NF#JOmVi`VPB@E8o{tw%90cvJ97fa9I%kfZQQJPcdK|W}${#5zNvJUL~?15QzC}2*}}=rZ_@tjbFJv}*5mf<5>GlOqZSJ`KAjdPx~qTy^V|UT zVRRAyJ_`KmY2ONio$s=9k4Ekyp$5dnem;BR5+W6{9TIJ-?}JnyA^@&_|(Ph#2TxNxCFo)VsnwCy1Ub#dWbRRF-Ild^%3Zgp3R(d-w62OUj8CUj& z;nlEWdej?3d74ev-vf~;XjF@e)RI6oSK_32zdT$c%ggVCqA#nK=mY1qGg_v&6azIh zt2lr_pjasLJtCq5e!nu05iAA9kQSZVpJg`uGtw@d_<~&|N=J$NkjZBxI)``NZ?RhDlhJx-SdUheL9W67b3L!h_^Shz#j{1|fu_jV0ox z1U^?IecRLs>5?jn=ffRBwny;h$g)G!p}G`=ALR!tE)`mjGj=oa8Q%k$xYg<7^{&<1 zeJ54wyddU#`31txi?_tX+7@CAeE7 zF4OHs;>LN3bNCme@F(4OBee8a3nj4X8R^tn1TCJy%N`$)IcE5AgT32rDJGz4lad*) zUqDTm1OLSlUTHWm9$jDakGppuVXo&|cApc*8-0!qn4Gs6{Z6L@7_m99gi&w&t3KpX zHAJ+h94s1fcf(N4qF+|3D}0j20%c`=aKNuL(DQgs;OVSu*yxB2tz($W!kb(hhN7@v z=J$M=Kt)2@Ss_Wfy*)X(+`SFm(p{Fe!iYt5wtYQ?y6&^H#D^BGa8 z^Qq#RVoe>~zfwOYk9Nw(tgh>?(04L4aewbwfr8%%90FM#bfMvkGYK`@Wo&qKKJD_y z_jthOU_Qk{t=^o7h*Hz?xxay)h=f1V-MOD!y<^cnB{I`IXPQ3)g=vy89)5)#?ooig z;+m68SoV`iqej#@b~@Z3Z(LsqO#jkQrQ}EvWj-WH?(Xz@;~hE6Ra`)7{7#$DZWA-% zxqE@`bcgAlgzNe4=a-*KVQoXVj(Z9g;cR-~Y*WT!WjCaBq=W(!H+@BNRMt<5ZAEC} z8)U$)hRiQAFpz&i*=rtm20ZS{^a#42&F>^9L%gxvGW6-{J_3BYZnI9oFEIeDkHYTk zweb(;uh35^Am60Rkm_O2p1{9shS!G4p?u7o;qpIa|0wG*7up3e1VKj@lJzdka>~F20pSpKe_01zVLB#WvfMOe2 zOH%#+b;T_dJq&|fB{`n=Il#ChMJ7gCf?(bu)l%wq_&%)2&#Kpg=R+}2jQ-YF1Q)Ji z=40soS8q}LK%iAel$o%j48`Q?bM^kz&E>Zd$%Hh}ha$@`@InqYRAr>FuElQ0=eo;R zL{P<#e8eqd(H!RA;p+lB;>TP*qgr030krxT6VX{(g^LA>rONtXHHY#yMrZnEyDZG2 z^{xB_9F7VTQWYj%F2r=Gt!vEV_ap^;OcpAhJMy9+Y7G!?)%^qz^ z3Bhk5&B5xo%?a4|ZN9lblUG3LRV>EU{)xi-uc(P$Gl~?CULc+s7?v|0N)o4LyqW zqZQUGzt6bJC$z7hNVrL2GC+saOvSo%+kJ)&E4Vl4L@;NX{X93Q) zZ4jQM%n#d_-Clp%v{VwJG7G~AO7p5wncecb?{H%Ptm=^pY10HV!dMYqHHZs_RpQmE z-3!IB*b}mcu3`X)36=wwl~5;Xb8;EBI&3`@>2LW)iC%9?VU*f3y=43TBj$Sb$O+Du zVxwfVlXNGo(Xq;IX$mQFUA6uqK^W{A(p#5{AC`%{PrE&^!TPC)W~haMY)I~BeyTY{ z+~Ok*>Pn$0)g=15k_!&Dp1STQk>$%!yy$Q%Bc(`oW58oMonG#^q!*AkWOax4X!*Gv4r5YUj22 zFxAZ>n-pe37fVOnwgVk>w%(EQE4z)z^oN6V4FQ?^k#S3ro) z*nAQLp{TQ={a|{ueOFpX3@^0cTlth3&m9*SM(<6&e<1Og20(v4jG52VUXSe>&(0sv z>kss}1$Z^;<*|b4yOnPl(yiyXO3V~(y(`9P9CT1NJ}rIWdRhj}McxXQqjuk}g@opC zuth1z4qyr#j$WeG{k?%W6>Ei}ox;1{&S5hE)ubtqBS*`LecYlCd9-43J>lFtBZ0B8 z%>i(3JOAQ$h#m8<3xA~-jRv?CB!n7%vUkTDHR<(oBG)hunV5*r2A6l+?z z$Dva&_OQ+JD$7FJ;ax5TWz(M7bzu$P`#W;5yT`M-o-Y93+$+`{GSRi}(#^uqNL$!3d^z~)}O|7Q(W*eU2%-6Av9Uw($ZRBcSSHE$B(3Er`1REe8pL5QdaLHJMfVbBhb3r7e*67H}XS>zTUXC^)mQ$ z#Q|h%sFlQZvP9&6+x-T40;6<@FvYl{K3Yz7Ogqctf#IH%B3SzI%Q6vy8NyFZR#_q6 zG+=E9teP4OFK?uOV36Bm`f$Vx zO2ccm%ZkL6R+}9AaVl=OR=LAH`nsZ(xMvrO-lLT^G9X-!K zM3LGL%N`+Wu|{&b!V24P)a|W*zXrSzPOso~Rj*bimCBCWJBQ2mEP%VD<)C#CmKF_oxC+Ul_$!R_ zVm#M1o=B8b{X1vrZml}5xGlEj&hN%_3y$ztdJk^sZ_^MRIp&Lwt0KZnPOB*)J0@)? zsPV1y>k_=y1^*T&n8oDhrR1OAU6RM4W5wuwRTx@cQCI6pH+8;%KewQV*S{_Z#qqIS z=G8Dot(Q)aWOD$+5f1KK)%z&is_{8|DIdYa-WzR?zJWi-qvtpiYe1h(0z09OhOjdG z*PtEjG-%bIJpZ;(I-nn3D75xZjj!dJ@58P}w-cV!@bEK-o`$i&s@6L=UaGp4eH<6) z{Yv-<8<|e8L2kQxJq3Q{sw2vYJe48ta}V~duvrsEA%}e+c;=NwHPO6@Fd4QWCZ3wv z%sX)RneH3M>u6Q4DaffVA2htB!zQr(gP^Y;7jZ-QKmfwc8=6X|YpO&3@+IAaLbJtj zrN`&lZcX#EHN_=7b;T~lK)y63uha_obE3tIYPaW+y@F_Ja$b#Kfvsyj87=r9_szd_ z5*wKThZ@2Gb8CuiW2@Uf>BOhpF%#fmEk!bCx6bC2oY-9uz2K<&^iBr~dKJKMi8iZl zzmhTvnIT<+0)VV>Qu%hebfjrwsrI3879N;a@HD!dew3ZcTGhtkyE?}s0n(ZG3!dl^ z=2VQQ4-w0_^mf}FTqR%A48q?sg>_Ok(%h^|wZrncR_$^xrWA*(ZZ8ZHlL4l>OTIox zuXc^guG(nV>|!3~{Cq}jbfRNEZtaNj0_>!D#b~$-s)1Ozw(hIJ2Kxi-nA{$-keUl} z@11c_w((7iI!PXG>tSYApjk$D$tjhJREJwG6_0|k5pHyxr*UF2FX4a~C`7cWezKJs zPqSu-67Jf^)P5QS;tE%#?luIfMIa;Sf=v7<5~sDl8>ICl?<4y2$HA!UWC;w7;9Udw zu8)g<>SEUjMDTJ;iyz2*4HH~aB7Y^reOA9*;*Z4i@3_^!A!=87dS5eFRU_XnT)huY z=w<0K)7b$su9S7CqcPd)SybooWs5&?BcI&=cRiK)eJ?-25i7M^G zUgbpwvQWRpcbj8?3w&KxX8v(d3rJJt{Ck5?Rd6@^-F%w1pAmfffFc``0DF!5;*p}7 zQ_@C!gdb{Q#t}H#>$b9`@G8eoj(5E1Mh;dA)hCbi2%q1IZ(3K15@Pow4R{3}Y~F+U z7x5T`i6KoHrt~X6R~~^{Y-Z{5hJh47LFBj%kz$|O?gjsLJEqF~McLXWM{DqVS$8bg z9Eus4=M3@2=SpFV*UM~5R(BQL)Icvpx-S85C=W{gckZ|3SkF6_Ixg!O$C*B+TQ~!b zY>@w|nnwVL!_%szK@E``BY~w!*dqnh|GWVDLwyXZV*a!$bMi|w9DshO$AIoX?H~

~xs; z9i{nB#$xj%BReVA5z|dRh|)B zBM88H5(4)lS+kMtM^k*M-x3GKKgL(+WB?eAlod|HqhGJ@+sK&S16vl zkr@MQ^A|Fgc8O2tk9tq>lZRWu`>n^!kkO!?jizvPckf8}xVQwgT1=MY4G!|=}B_~+zvwDGsn^Om&)6+2*kZMzX7|mmGw@vM}Jrma_f12ss0JT1Ci5wnjRJh-wE)e4zh^|nq9{RizdI~0 zgSYSg{|AvkZof`X<^>cPO3*dKhCR1$-?0xr{Lm+AN>FH?frbOd84^&5mZ_`z&a7L# z+OQc`pOkbp7r~x7iurlIaKK(%_*W1EReNvkAKACA{w=0`e#)K?tPe*)D4_tzs*=4t zH>&%7i55yp7tR&p@Hok@%l!nVD+C?I!V8}A(xoGqqfiZZ>|^msnuL{VR; z1hXqMW`FwSy`guK@VhOeu3n96J{f`OO^i3882A1kod;k59cn@&<#2U>Tyfn%G z`1y)2H!NY*31U;KCVw)SQ`Cn`U$ni=CAVW-t^PCn?)ATkl6s$^9qOuUn_UD+6yJbE zmi}GgM#Hi*6d;1|PoU?4Oz1C?yUPR2Q&1w;P^J^sp%Rh z2EliR8U1DA-@HWFngneSz;PXX)bN$AvZs`s(ed=)>b%{)vEe;3Pk+ll0?LpBNLJVn z;MmvKtw#DqdWP!xd+%R@9Hpbo-)Z*!pW%*{fUp1)!nBw{-qN8Y>`r!T^V=+CWFiwi zMc=kHQD$OqM)%R3a@xMs`%ML_tRQgw@q74vu<%~2(%ha(p8VP3qH}5+BA9&nNA<*;BTE;VbwuxpT2@ zw~KGu_iz7Qc6_{#pN6NT5K{hLHoa-=luxz}b=RZtElF9LfG%7N7rqCj%Fh#^ac93J zF-N*(%Tp0Ltuei=J)})r@?O30QkY(sg`3v%-eCQGV%?4R{voGdwvhtkaEonBehR9S z0$UL3_D!L+U;WKkLhIc*rDEr*NR z4`Ai4z4P{mm_5fG_ZCAEL&vnt{rNA=vR*t)Ml;O=kns15u|a|^m0x6IAbN_4k|JTC zz3Q82T3Riz(YVQBHh0552I^r-m_0KtLwrsXn}_N|QCK zKA!H~Yt@0IoKW;im1S*ptw(nbD{q% z)wd^v?$0EBb$-I#t>I!uQH$06Nphejj3o1q zva4E|rBqC%#wT7|L)O_R`@Y}5Wp?K(aM=f3v$F%d2rGe|r3ug4z-O&`+5Y%D|AK%{ z#Ta4qy9;+I0EmA!H9C5#Vh1?b$U9NZ3O!KLCN0fm&}#p3@vzNT&JiAepR`6?!QdPH zbIvKK+Re51h|khN(M4;_cfxhli-bO22HTWgq_xvElYv}$N1FY@XQGbtSf;Cfe;QntB zhqb(vwKfjo5Lw0Kie<1(^ao;e;tg?UypT@(67EXTFT%ytbBn1nn!hQ}av|@rm)?2z z09*bEZ9?s$^V%|?;StihH#}&52x#C0!@ARE&iO&7zC9FB&7Znq6j0s5X&->pxztym zB-B4Wx$xVCUZc$E@k;R-o?eJ#7XjO_3SQYCu-2j{=W?sV!2iur5zI!x8hLpZsP`~BJnpvTfOKo;0zU>q0A zM)%<^%Vb5-ZE(@@q1vg8^mRgTBqTEs#4=(Wul3#rG66asH>(@AzRt43L|Aov-0F)I z07h#nvr_6rw;V@y7g`5wsrWotGCzcL+3yjn&LeyM{@=G7>wiSu!&=qYOUYvmaO`6l z45C#|S|fU4Um}%Av(89L(Jwxal)5XdBZcftXiIOxb|!{0=eE6TpWgV;u3fp2^bm>bjk^zkJa5NU z)tJ5DIhyv=*Ae(^3#_e(izUYMHRkK)Ua14jdnkX=&j)B}GXx!5>b*Y!*2;jU-KqT% z`^~eZpwQINK>zG0QimH}KEhL1KevU%@<51ox%5-ns*(;$I}c#iFW{akHKfyo#&ycF zR^ZN%OT(Asv8J86B%6zdVQQ^4TU}@2z8oN=_-$=3fDkqQa@>FwX6e0CuDFx>QDfsl5C`NheOY*dKwN8q>@D6^_{!VijDPvfI8i(562f z=o_v!tO!$`09}Hu{TE^y-~=u$;S`79yzOpSoJ6dk^8u;H-Mp z?9T>WvRGvl3niv?`7oM#bJf;b@7sfw+xFI_x9#OuE{sVnU?$vE4E^*gb2dA-X03JQ z2O;k+;GiLa#o|euFYjZle-msZ7?NH-`PZgAtJRyfym7~l%pS#>940g-Kt{f0nf*{1 zlQ44-X_v*wDfJ5&X|9^0D>{{nuB>1DHtZgh2pz;DI+v(BrRE+40ses0TzolEJf>2D z5SyE9w0tidwB!pxm0w?v@4>h9BW1OKQr6N+65rS-q}d4s{A||t&%VT_1YiTcTK}&> zo-*?Tmg^td$7{cD=jVRWhr+aWTxx?m;YQx_pmwG);v0ax1QLL%7ip7AKt#Ubb!KS7 z0uU5cVL6MH%iEhP-JVi1EYhcZ$zK>YX@AcSqX=0CmC0WBMAeS)nQ$GCUg<*`DvbbC zr3ZZ}zZo*ENx42xN8d+vDO}G#K9le}(SuGy`t^sX7x zR}Wt%^-dSx6F3m8#FDLt^-pYl<1-Ka#vAY0&;P>D5lvzH;nN8<@2$c3@8M%*+s{0J zJD-vsGyAo@xL z<x`%@KB2!`3~f)(I7(v$pnvXli1vD$?ul}dq?n%o6i$`P%-IkZv**i`v0HoC`a(<(B zhJes5(`X+t)?Sl%pjUS3(p$FrXx$d}vTyvD#(h6tz|Yu~XKm;MaiON1HE3Lt#8?w<4-rFx=19fFv0J3e=j z4m4*;P?yAmwRF<=mUpI39~Enl1Y3dap%t@TbGA;I7-NR<|Ct%pv#_^AQsLrfkdVM+ zJ7P8>nlB&50}H+UMDJ24O%EsU|j zvZ(!MYD@r}(MTcwgmGZ8QD+lP8f?}}EWw4m*g6+Ik9(J}A*^HE!=m6UMhp%{8<=ha zJ_Ez|2Y|WUuDxkh1Vy`2wQlRiLu4FsNaWzEafxa zqf;)6^;tV!{2_banX&Sr^8wp=)wtz7dynmG*I}-Q7)Mo@ztV>I(fAA zXp{d$+Kt+)0^eZb)m#o}M|lPzB0(AR9Pfb&QlZqJ)k%)Xb*woW*Ja5i0!&dnwErMj zxo%tr`0;NWhA*YwG!tkNYmbwQT=j=g&eF(Jl(*sgNwP8?c z!>&I3O*^~r!*;NAmT$se)&cd9l@EYq;1Xagr(qIS9@?o_i?;tBy?^kP9l~AgwI@kw zUPP616z)AZZz~&2P{g7ZoH8V*dl1ULGa$_5HDt}yWvWr2oN=&v0q_|6{Dfjb z?X5R!x9qb=zi$Wj|Jx`N+8$a0kJTZr@a2NuvZofK%{tJrd-neS8@6+HB|oKIHm-nY63Tu`GuD|}z=AXsjZgknFNva%1u=czJqje8Z}$>> z(o>RgyvJqt0Z5*GA`_KY6$*A-vs#H;I5pI0?Jm?B#J*)Pxf z;W=98?kCXoiIMNEjH*WsE5ihQkM;jIu80l6*wThf7#F(T5LDGzcm*R|tzDsieGfCT zg2KG$4ZZc&yGaCR4c(DPdlz~z-J@&?eDoX)m*E6iP-PZX&nWD2h$)ud;Zo&G_`yuG zy=6CVA|%*T;NIFL_DP7nl+lupp<>yLRv!XgM4M2HB9sa4Y2C@8rArCY^17AtePFT* zuS;b-nrrv+h}Wk+j|M3Tl?oog6E1D~Nm+9c6mfXPx(fX-9L=jr>ilV)iSO0jarEexV-O6%O*O+B9i3aIr=-7pH!=;S)~ z0SI0RYYD6(m4Pk*rLpT8(@8L8g;NHMI#Kb;cxN7C+PX_B>c42SS||U!#_AJId<^~; zgc?kX%wA)hePvmESXvQPsmUU3XUG{;GLJq93QQg~KV=mFreO^uz#%pJ{?eP5?9rn& z%%mVYfh%C;m|-~L#V^3j>h$(BWFZ11uF1}S8rM9s@MUNEPDgMK^wjKf35tT<-F%bf zfb4Cs9YQN6o_p^qtK2YK^i1ncUIDjhkqpHdi|47N&q%o7EK=8d5!5ZQkMhhqsx)3U-87%=QpkXKn^lA^)o=P$!)x zn-7&xIx3u;RpAuFGFJtqx6D;aE)`jk=N6VZpC`b(tR?MB@8IVbn6l(H91HGg!gpRWO|~xw*!45KF~;VcjTjn#9j3E*tZK)O@ZP{&uRVFYSavp6{&SL1 z;=*U`=G!oc8prF>tC0z{K+h|%6UFY#oqQx(H_;%jR$s$Z&k%wb6H-A-2(K^);QF=e zFy_gsWH_C$V8<@jZFWH^26z(s;`0>^5`gRe@^fqs!=yu}f%2ttQ@)B;qgQpSjzUtu z8zh&I-xe2X(ht~Zb*Eo!q=TeH-_N6e5FVrALY}fpQWp-v0uWM8YR~9sY%!#i(~t%# zfGl2R6jJw4UIJazhH8wphoOQ^yT0+q;9tWkB%#bB0v2h>rJLf7@07IE3e~|D^AK8E z0TD0FztQEx0=i56Xggusd5Jq{Ib-(92ynv3_^xpA((kTRgj={m33*(8bjT9q;Tvrs zlmEzj;$1KXx>yh5U4gUD10zpA?iK|mnnm z9Y1B_SaZcz>K`NM6+Vn-syFs<`4K0_eVFNi^~a&#mylZ+B&0ijVUJbz1x6odGV8la zOW*gR0PHOu=M~0FeqvlPYx;*)Z9HUGK=3Jp=T5q`tdct8m`s{rtUDpcqeCOS*WY*- zoIx%Kttb?9Po3vW>1RFDuRHb-l>lKb^)HN>E4fhLUC?j@eh9R+C;rBvBVNmNRzMj9V^+P7qn+Qy?6obhW7*~j3HinEx_3L#C|>%O z4c`mT>p#Ion_T)xTXh)mE|}ZtBv`Unz)|(8RI1o)X%Bd5QXS*r8j#OAkY8)wvfG>Q z;LF5V>Y;M}EIQQ$Q7$MdQi=l=bW0wC$9Db3I=@};rf|lhKpqDe3(&I|X~!DJHWE{2 zJWYOESemud&ojkw%-!u$l&CT48Ql1I%^uy=dgT$=gVy|tjbI^IX}<3V_Y|1MtX