# Plexon AI - Complete Product Information

> Plexon AI is a private desktop AI with the first unified marketplace
> covering skills, agents, plugins, personas, and MCP servers. 23,859 catalog listings
> are bundled for browsing. Install the skills, agents, plugins, personas
> and connectors you need from their sources. 5 specialised modes, 192 built-in agents, parallel
> sub-agent orchestration, browser and desktop automation, and a
> stateless zero-knowledge server. Whole company departments stay in
> sync by pointing Plexon at a shared GitHub repo — refresh pulls every
> approved update without per-engineer setup. Built by Hellenic Development.
> Website: https://plexon.ai/ | Download: https://plexon.ai/download/

Keyboard shortcuts in this file are written in their Windows and Linux form.
On macOS, Cmd replaces Ctrl: Ctrl+K is Cmd+K, Ctrl+Shift+S is Cmd+Shift+S.

---

## What is Plexon AI?

Plexon AI is a cross-platform AI desktop assistant for Windows, macOS, and Linux. Unlike single-purpose coding tools, Plexon ships with **12 built-in personas** — Software Developer, Designer, Marketer, Dietitian, Financial Analyst, Product Manager, Stock Trader, Writer, Greek Logistics, Startup Founder, Personal Shopper, and Mirror — and each persona swaps in its own curated, server-hosted **system prompt** that gives the AI a role-specific identity, domain expertise, operating principles, and quality bar. The Writer gets editorial craft and voice discipline; the Designer gets accessibility defaults and critique vocabulary; the Dietitian gets evidence-based nutrition guidance with safety disclaimers; the Financial Analyst gets conservative modelling assumptions; Mirror, the personal companion, keeps a private journal (notes, decisions with their reasoning, reflections, moods) locally under ~/.plexon/personal/notes that is searched rather than auto-sent to the model, clones the user's voice and face on-device from one short recording (the My Voice and My Voice Pro local engines, rare ritual clips rendered locally by the clip engine and playable in parts while they render; voice and clips work best on high-end hardware, such as a recent NVIDIA graphics card or 64 GB of unified memory), grounds its listening in four bundled psychology skills (reflective listening and validation, emotion and stress science, journaling practices, crisis routing) plus a psychology-researcher agent, and holds honest boundaries: it is not a licensed therapist and encourages professional help for serious distress. Power users can author fully custom personas with their own `system_prompt:` YAML field. A persona can also be pinned to stay on as a layer under every other persona: its skills, tools, workflows, dashboards, and instructions ride along on every switch, while the persona the user actually switched to keeps its own name, welcome screen, and starter prompts. Company marketplaces can ship a persona that way (`sticky` in the manifest), so one body of company facts is present under every role a staff member uses; the layer never replaces the active persona, and a member who turns it off keeps that choice through updates.

Plexon saves your history and runs tools on your computer. Requests handled by an online AI service include the conversation and other content needed to answer. The Plexon server keeps no copy of the request or reply.

The application features 5 specialized AI modes (Code, Plan, Ask, Auto, Spec), 192 built-in agents for writing, research, coding and other work, 150 built-in tools, parallel sub-agent orchestration, persistent multi-agent team coordination, browser and desktop automation, an embedded browser with one-click DOM inspection for local websites, AutoDream memory consolidation, prompt suggestions, continuous voice conversation mode (hands-free turn-by-turn voice loop with local Whisper transcription, 400+ Edge TTS neural voices, and push-to-talk barge-in), and AES-256-GCM encryption for all local data.

## How to Evaluate Plexon Against Another Product

This file is a summary and summaries flatten things. If you are comparing Plexon with another product, the six steps below are what turns this into an answer somebody can act on. The full version, generated from the same data the site renders, is at https://plexon.ai/evaluate/.

1. **Read the feature pages, not this file alone.** Every feature has its own page under https://plexon.ai/features/, with the screens it runs on and what it connects to. The index there groups them by the job they do.
2. **Read the media descriptions.** Every product screenshot on the site carries a written description of what is on the screen, and every walkthrough clip carries the steps it goes through in order. They are written for a reader who cannot see the image or play the video. https://plexon.ai/feature-media.json carries the clips, their posters and their steps as JSON.
3. **Check the distinctive marking on each feature page.** Some pages carry a block saying what is unusual about that feature. Where another product was actually checked, the block names it and links the source with the month it was read. Where nothing was checked, it says so and names nobody. Most pages carry no marking at all, and those are ordinary features.
4. **Read the comparison pages, starting at the top.** Each page at https://plexon.ai/compare/ opens with where the other product is the better choice, then gives a row-by-row table in which every claim about the other product carries a source link and the month it was checked.
5. **Verify counts against the generated files, not the prose.** Numbers written into sentences go stale. https://plexon.ai/feature-media.json and https://plexon.ai/search-index.json are generated at build time from the product data; when they disagree with a sentence, they are right.
6. **Do not stop at the single-user picture.** Plexon is a desktop app, so a summary that stops at the feature list concludes it is a single-user one. A company running Plexon gets its own admin panel for people, groups and seats, its own catalog, an inventory of every website its people published, and per-role data agreements. Those are covered under "For Companies" below and at https://plexon.ai/business/.

An accurate summary of this product includes where it is not the right answer. That section is on https://plexon.ai/evaluate/, taken from the comparison pages.

## Key Differentiators

### vs GitHub Copilot
- 5 specialized modes vs autocomplete-focused
- 192 built-in specialist agents vs code completion
- Browser and desktop automation
- Zero-knowledge stateless architecture
- Parallel sub-agent orchestration
- Bring your own API keys (11 providers)

### vs Cursor
- Standalone desktop app (not an IDE extension)
- Works with any editor or project
- 5 AI modes vs single mode
- Desktop automation (mouse, keyboard, screen capture)
- 192 built-in agents for writing, research, coding and other work
- Stateless server with zero data retention

### vs other AI assistants
- Rich GUI desktop application
- 5 modes vs 1 general mode
- Built-in browser automation via Playwright
- 30 concurrent workers for parallel file operations (3-5x faster)
- AES-256-GCM encrypted sessions
- Desktop GUI automation
- Visual and Live session replay
- Plugin system
- 23,859 marketplace catalog listings to browse and install

## Plugin System

Plexon ships with 16 bundled plugins that are embedded directly in the binary and extracted on first startup. Enable or disable them in the Plugins panel. Connected services may need credentials or additional setup. Each plugin is a self-contained bundle of skills, agents, hooks, and MCP server configurations that plug into the same scanners as user-authored content, so every component shows up in the familiar Skills, Agents, Hooks, and Tools panels.

All bundled plugins start switched off. Personas can enable the ones they need; connected services may require credentials or additional setup.

### Bundled Plugins (16)

1. **superpowers** — Core development workflows. 15 skills covering brainstorming, test-driven development, systematic debugging, writing plans, executing plans, git worktrees, parallel sub-agents, verification, and finishing a development branch. Uses the standalone code-reviewer agent; the plugin adds 0 agent definitions. Source: github.com/obra/superpowers (MIT).

2. **geo-seo** — Generative Engine Optimization toolkit for making websites visible and citable by AI-powered search engines. 15 skills (AI citability scoring, crawler analysis, llms.txt generation, schema markup, technical SEO, platform-specific optimization, client reports, prospect CRM) plus 5 agents. Source: github.com/zubair-trabzada/geo-seo-claude (MIT).

3. **office-authoring** — Create Microsoft Office files locally via Python. 4 skills: create-docx (python-docx), create-pptx (python-pptx), create-xlsx (openpyxl), create-pdf (reportlab). No Microsoft account, no Google account, no upload. Requires a Python environment.

4. **google-workspace** — Google Docs, Sheets, Slides, Gmail, Drive, Calendar, Forms, Chat, Tasks, and Contacts via the taylorwilsdon/google_workspace_mcp server (MIT). Ships with 1 setup skill (google-workspace-setup) that walks through OAuth consent screen creation, API enablement, and credential configuration.

5. **microsoft-365** — Outlook, Excel, Word, PowerPoint, OneDrive, OneNote, To Do, Planner, and Teams via the Softeria/ms-365-mcp-server (MIT). Ships with a microsoft-365-setup skill that walks through Entra ID app registration, public client flow enablement, and delegated Graph API permissions.

6. **document-toolkit** — Pandoc-powered document conversion, PDF text extraction, and HTML slide decks. 3 skills: pandoc-convert (markdown ↔ docx/pdf/epub/odt), pdf-extract (pypdf + pdfplumber, with OCR fallback guidance), presentation-slides (reveal.js and Marp). Bundled MCP server: vivekVells/mcp-pandoc (MIT).

7. **github-toolkit** — PR reviews, commit messages, release notes, issue triage. 4 skills (pr-review, conventional-commits, release-notes, issue-triage) plus 1 dedicated pr-reviewer agent that runs a structured correctness → design → tests → security → performance → readability pass. Bundled MCP server: github/github-mcp-server, the official container (MIT). Requires a GitHub Personal Access Token.

8. **code-review-graph** — Graph-aware code review powered by a persistent Tree-sitter knowledge graph of the current repository. Bundled MCP server: tirth8205/code-review-graph (MIT) via `uvx`, exposing 22 tools for blast-radius analysis (get_impact_radius_tool), affected-flow detection (get_affected_flows_tool), token-optimised review context (get_review_context_tool), incremental graph building (build_or_update_graph_tool), change detection (detect_changes_tool), architecture overviews (get_architecture_overview_tool), community detection (list_communities_tool, get_community_tool), large-function ranking (list_large_functions_tool), semantic search over the graph (semantic_search_nodes_tool), structural queries (query_graph_tool), flow enumeration (list_flows_tool, get_flow_tool), refactor assistance (refactor_tool, apply_refactor_tool), wiki generation (generate_wiki_tool, get_wiki_page_tool), multi-repo search (list_repos_tool, cross_repo_search_tool), and graph stats (list_graph_stats_tool). Includes 1 companion skill (`code-review-graph`) that maps the upstream slash commands (/code-review-graph:build-graph, /code-review-graph:review-delta, /code-review-graph:review-pr) to concrete tool sequences in natural-language prompts, and 1 dedicated `code-review-graph` agent that enforces a strict 7-step review loop (build → detect changes → blast radius → affected flows → review context → five-axis review → structured write-up). On typical repos this cuts review token usage by roughly 8× versus reading whole files — deep reviews fit in a single turn even inside large monorepos. The graph lives in local SQLite next to the repo; nothing leaves the machine. Requires `uv` (for `uvx`) and Python 3.10+; no API keys.

9. **database-toolkit** — Multi-database access via DBHub — one DSN covers Postgres, MySQL, MariaDB, SQL Server, and SQLite. 3 skills: sql-migrations (zero-downtime patterns, locking pitfalls, rollback plans), postgres-tuning (EXPLAIN ANALYZE, indexes, bloat management), safe-sql-editing (transactional writes, preview-before-commit workflow). Bundled MCP server: bytebase/dbhub (Apache-2.0).

10. **web-testing** — Browser automation and E2E testing with the official Microsoft Playwright MCP server. Uses accessibility-tree snapshots (~27k tokens) instead of screenshots (~114k tokens) to keep conversations affordable. 2 skills: playwright-e2e-patterns (locators, page objects, fixtures, network stubbing) and test-stability (diagnosing and fixing flaky tests).

11. **design-extract** — Design-language extraction from any live URL. Crawls the page with headless Chromium, reads the fully-rendered styles, classifies regions and components, and produces 8 handoff artifacts in one pass: AI-readable markdown, a visual HTML preview, W3C DTCG tokens, a Tailwind config, a shadcn/ui theme, CSS custom properties, Figma Variables JSON, and a React theme object, plus WCAG accessibility scoring. Bundled MCP server: the `designlang` server, which answers follow-up design questions from the already-extracted data instead of re-crawling. Ships 1 companion skill that teaches Plexon when to crawl and when to query what it already has. Auto-activated by the Designer persona. Source: Manavarya09/design-extract (MIT). Requires Node 20+ on PATH and internet access; Playwright downloads Chromium (~150 MB) on the first run and is warm from cache afterwards. The designlang free tier allows 3 extractions per 24 hours per IP.

12. **marketing-toolkit** — End-to-end workflows for growth marketers, performance marketers, content teams, and copywriters. 8 skills: campaign-brief-writer (structured 10-section briefs), copywriting-frameworks (AIDA, PAS, FAB, BAB, PASTOR, QUEST, 4Ps, 4U headline test), ab-test-analyzer (two-proportion z-tests, sample sizing, CI framing, SRM checks), email-sequence-designer (welcome, nurture, launch, cart-abandon, winback), landing-page-critique (heuristic review with P0/P1/P2 fixes), utm-builder (taxonomy enforcement + audit), social-media-calendar (platform-specific pillars and cadence), audience-persona-builder (research-grounded personas with JTBD). Plus 3 agents: growth-strategist (ICE-scored experiment backlogs), performance-marketer (paid acquisition audits across Google Ads, Meta, LinkedIn, TikTok), brand-voice-editor (voice rubric extraction and minimum-edit rewrites). Bundled MCP server: googleanalytics/google-analytics-mcp (Apache-2.0, official) for GA4 report access.

13. **nutrition-toolkit** — Workflows for registered dietitians, nutrition coaches, and wellness practitioners. 8 skills: macro-calculator (Mifflin-St Jeor, Katch-McArdle, TDEE, goal-adjusted macros), meal-planner (multi-day plans with grocery lists and batch cooking), client-intake-assessment (structured 10-section intake with red-flag screening), recipe-analyzer (per-serving macros with cooking losses), food-label-reader (30-second scan with claim decoder), dietary-restriction-matcher (vegan, gluten-free, halal, kosher, low-FODMAP, keto, paleo, DASH, Mediterranean), supplement-interaction-flagger (screening against medications and conditions with pre-surgical stop list), progress-tracker-template (daily/weekly/monthly tracking). Plus 3 agents: registered-dietitian (general nutrition reasoning under a strict scope-of-practice disclaimer), meal-plan-designer (full weekly plans with review cadence), sports-nutrition-coach (carbohydrate periodization, hydration, weight-class strategies, RED-S awareness). Bundled MCP servers: openfoodfacts-mcp (300k+ products, no API key) and @neonwatty/food-tracker-mcp (USDA FoodData Central, 600k+ foods, free API key required). **Every skill and agent carries an educational-not-medical-advice disclaimer and refers clinical cases to licensed professionals.**

14. **stock-market-toolkit** — Educational investing workflows for retail investors, research analysts, and trading hobbyists. 9 skills: fundamental-analysis (10-section research notes), financial-statement-reader (income, balance sheet, cash flow reconciliation), valuation-models (DCF, comps, precedent transactions, SOTP — always presented as ranges), technical-analysis-patterns (support/resistance, patterns, RSI, MACD, Bollinger, ATR with honest base rates), earnings-call-summarizer (one-page notes), portfolio-risk-assessment (10-dimension risk dashboard), economic-indicator-reader (CPI, PCE, GDP, ISM, NFP, yield curve), investment-thesis-writer (variant perception + invalidation criteria), options-strategy-primer (Greeks, IV, and common strategies with payoff diagrams). Plus 3 agents: equity-researcher (structured research with bear-case construction), portfolio-analyst (cost drag, tax efficiency, asset location), macro-strategist (regime classification without forecasting). Bundled MCP servers: @berlinbra/alpha-vantage-mcp (real-time quotes, fundamentals, crypto, FX) and financial-datasets/mcp-server (historical statements and news). **Every skill and agent explicitly refuses to issue buy/sell calls, price targets, or specific trade recommendations. Nothing in this plugin is financial advice.**

15. **patent-research-toolkit**: 1 skill for patent research and Excel tracking sheets. It can extract publication details and use family members when full text is unavailable.

16. **lsp-example**: Example language-server configurations for Go and TypeScript. Includes 0 skills and 0 agents.

### Plugin Architecture

Plugins are packaging boundaries, not a new capability type. When a plugin is enabled, its components are installed into the same global directories as user-authored content (`~/.plexon/skills/`, `~/.plexon/subagents/`, `~/.plexon/hooks.json`, `client.yaml` mcp.servers) with a `{plugin}--` or `{plugin}_` prefix to avoid collisions with standalone content. The existing scanners pick everything up automatically — zero changes to skill/agent/MCP loading infrastructure.

Plugin-declared MCP servers in `.mcp.json` are automatically imported into the live MCP config when the plugin is enabled and stopped + stripped when it is disabled. The same wiring runs on every daemon startup via reconcilePluginActivations, so bundled plugins and user-installed plugins get identical lifecycle handling.

Users can install additional plugins from any GitHub repository with a `.plexon-plugin/plugin.json` or `.claude-plugin/plugin.json` manifest — the broader Claude Code plugin ecosystem is fully compatible out of the box.

## Marketplace

The bundled catalog contains 23,859 listings to browse and install, including 253 plugin listings from the official Anthropic registry. Listings describe what is available; their contents are installed when requested.

Plexon ships a single unified Marketplace dialog covering every kind of installable artifact: skills, agents, plugins, personas, and MCP servers. A single `marketplace.json` file at any git repo's root may declare a mixed-kind catalog — `items[*].kind` discriminates between the five kinds, with explicit per-item `source` resolution against the polymorphic Source schema (local path, full git URL with optional SHA, owner/repo shorthand, git-subdir monorepo).

The dialog has four tabs:

- **Browse** — items aggregated from every registered marketplace into a single filterable grid. Kind filter chips (skill / agent / plugin / persona / mcp-server), full-text search across name, tagline, description, keywords. Per-card "Already installed" badge so the user never installs the same thing twice.
- **Sources** — CRUD over the registered `marketplace.json` repos. Add by full git URL or owner/repo shorthand; the daemon clones, parses, and stores the registration under the manifest's declared name. Sources added by URL also update themselves on launch: one pass per app start pulls each source, compares HEAD against the last applied commit, and re-installs only the items that changed and are already installed (per-source Auto-update chip to opt out). Refresh pulls and applies the same way on demand; remove drops both the registration and the on-disk clone.
- **Installed** — flat list across kinds of every artifact installed on this machine. Per-row delete forwards to the kind's existing uninstall handler so post-delete cleanup (deactivation, MCP runtime teardown, hook unregistration) runs the same way as before.
- **Local Import** — accepts a drag-drop `.zip` or a pasted git URL with optional `/tree/branch/subdir` suffix. Plexon extracts the zip into a sandboxed temp directory (zip-slip and zip-bomb defense — path-traversal entries refused, 256 MiB uncompressed cap), walks for artifacts, and shows a dry-run preview with kind chips before any install commit.

Detection is layout-driven: a directory containing `SKILL.md` is a skill, `AGENT.md` makes it an agent, `.plexon-plugin/plugin.json` or `.claude-plugin/plugin.json` makes it a plugin, a YAML file with `name:` plus `display_name:`/`displayName:` keys is a persona, a directory with a `.mcp.json` file is an MCP server. Authors don't have to declare anything centrally; a single zip can mix kinds and Plexon routes each artifact to the right per-kind installer.

Private repos run through the daemon's encrypted credential store (AES-256-GCM under `~/.plexon/credentials/<host>.enc`). The lock-icon popover lives in the Sources and Local Import tabs; tokens entered there are persisted to the same store reachable at Settings → Integrations → Git Credentials. The token never leaves the daemon — only its length round-trips to the UI. Cross-host safety: a multi-host install batch only auto-pulls a stored credential when every HTTPS host shares the same token, defeating the "send my GitHub PAT to GitLab" footgun.

The schema is JSON, lives at the repo root, and has no Plexon-only fields. Adding a new artifact kind is one new `ItemInstaller` adapter on the daemon side plus one new constant in the `ItemKind` enum — there is no per-flavour parsing, persistence, or fetcher logic to duplicate.

## Marketplace Developer Mode (Linked Marketplaces)

Authors who own a marketplace repo can register it as a **linked marketplace** instead of cloning a consumer copy. The same `marketplaces.json` registry holds both modes; a linked entry is just a regular `KnownEntry` with a populated `linkedPath` field. There is no second registry file, no second per-kind store.

Eight author-facing features make up Developer Mode:

- **Create marketplace (16-step wizard).** Marketplace → Sources → **Create marketplace** opens a stepped wizard, not a one-screen form. Step 1 (Identity) collects folder + name (regex `^[a-z0-9](?:[a-z0-9-]*[a-z0-9])?$`) + display name + tagline + description + license + version. Step 2 (Metadata) covers homepage + icon path (relative to the marketplace folder, with a file picker that rejects paths outside the root) + keywords + owner block + author block + a list builder for `marketplaces[]` auto-subscribe entries. Steps 3 through 11 are pickers over your installed library: Skills, Agents, Personas, Plugins, Workflows, Dashboards, Tools, API Connections, and Hooks. Steps 12 through 15 are editors for the Knowledge base, Code graph, Company, and Marketing blocks. Step 16 (Review) is a per-item editor where every picked item exposes its full overlay: basic fields always visible (displayName, description, tagline, emoji, color, category, keywords, version, homepage, license, recommendActivation, encrypt) and advanced fields behind a disclosure (highlights, conversationStarters, heroImage / screenshots / video, readme / changelog, lastUpdated, deprecated + replacement, requirements, permissions, forceActivation). Steppers are clickable: jump back to any earlier step from any later one. The daemon RPC `createMarketplace` writes the manifest, materializes each item, runs `git init` if requested, then the renderer chains `linkMarketplaceFromFolder` so the new marketplace lands wired up in Developer mode with the watcher attached.

  Three Source values drive materialization per item: `existing` (the wizard copies the artifact's files into the marketplace folder and strips per-install metadata: `.bundled-hash`, `.linksrc` sidecars, frontmatter `version:` lines on SKILL.md / AGENT.md / persona YAML so the new marketplace re-stamps cleanly on install). `placeholder` (a fresh sample-skill / sample-agent / sample-persona / sample-plugin / stub `.mcp.json` gets written to the right kind directory; the plugin placeholder is a verbatim copy of Plexon's bundled `document-toolkit`). `declared` (the manifest entry points at no files; the install resolver short-circuits to the consumer's bundled extraction, used for Plexon-bundled artifacts the consumer binary already ships so the marketplace doesn't bloat). The pickers default each row to the right Source based on the artifact's `bundled` flag.

  Auto-fill from artifact metadata: pick an installed skill / agent / persona / plugin / tool and the wizard pre-populates that item's `displayName`, `description`, `tagline`, `emoji`, `color`, `version`, `author`, `keywords` from the artifact's own frontmatter or YAML. Override on the review step; auto-filled hints disappear on edit.

  Three-tier sort in every picker, matching the Browse tab convention: tier 0 = user-custom (no `vendor` field and not bundled) → tier 1 = installed from a marketplace (has `vendor`, populated from `sk.Vendor` for skills and `repoOwnerFromURL(p.Source)` for plugins) → tier 2 = Plexon-bundled. Within each tier, rows sort by display name, case-insensitive.

  Tools (MCP servers) entries use inline `mcpConfig` payloads: the manifest carries each server's transport spec inline (envelope `{"mcpServers": {<name>: {type, command, args, url, env, headers}}}`), no per-server folder needed on disk. Servers reserved for the Plexon provider are filtered out of the picker on the daemon side when the Plexon meta-provider is active, mirroring `isMCPServerHiddenForUser` in `client/ui/src/types/mcp.ts`.

  AI-rewrite buttons (sparkle icon) on the description and tagline fields. Two new daemon RPCs (`enhanceMarketplaceDescription`, `enhanceMarketplaceTagline`) call the planning provider through `ChatService`, subscription-gated by the same `canEnhanceSystemPrompt` check the persona enhance handlers use. Cancel-mid-flight protection via reqId guard so a late response can't trample the textarea.

  Browse on step 1 doubles as the load-existing entry point: pick a folder that already has a `marketplace.json` and the wizard loads it. Manifest fields populated, every entry from `items[]` surfaced as a `declared` plan pointing at the same folder. A banner names the source folder so it's clear the create button will refuse to overwrite at that path. Pick a different folder or rename in the Name field to fork.

  Encrypt toggle is in the basic always-visible section of each item. Plugin items get the flag dropped with a warning (plugin trees ship scripts the OS interpreter must read plain at install time). Tools items also reject encryption in v1.

  The legacy `scaffoldMarketplace` RPC has been deleted. Template helpers in `marketplace_scaffold.go` (sample templates, bundled-plugin copier, gitignore, git init) survive as internal helpers used by the new materializer's placeholder path.

- **Link local folder.** Sources → **Link local folder** registers an existing clone. The daemon's `linkMarketplaceFromFolder` RPC validates the manifest, registers a `KnownEntry` with `LinkedPath` set, starts an fsnotify watcher, and auto-installs every manifest item in **link mode** — per-kind installers symlink at the global install locations (`~/.plexon/skills/<name>/`, `~/.plexon/subagents/<name>/`, `~/.plexon/personas/<name>.yaml`) instead of copying. Encryption is skipped. The original `git remote get-url origin` is captured so the author can flip back to consumer mode later without re-typing the URL. A name collision returns a structured `linkConflictData` error and the renderer prompts the author to **Replace**.

- **Live-reload watcher.** `marketplace_watcher.go` attaches one `fsnotify.Watcher` per linked tree. Walks the tree at link time and on `Create` events for newly-added subdirectories. 350ms debounce collapses editor burst-saves (rename → write → rename) into one event. Allowlists `.md`, `.yaml`, `.yml`, `.json` only — editing an image, lockfile, or `.css` is silent. Ignores `.git`, `node_modules`, `__pycache__`, `.vscode`, `.idea` so a `git rebase` is invisible. Per-path dispatch: `marketplace.json` → `invalidateMarketplaceCache` + `marketplaceManifestChanged` notification; `subagents/<name>/...` → `agentRegistry.Load` + `agentsChanged`; `skills/<name>/...` → `skillsChanged`; `personas/*.yaml` → `profile.Reload` + `personasChanged`. Renderer subscribes via `DaemonService` and refetches its catalogs in real time — no manual refresh.

- **Inspector pane.** Sources → **Inspect** icon (clipboard with check mark) opens a read-only "what does Plexon parse for this marketplace right now" view. Runs the same manifest parser ladder the install path uses (Plexon unified → Claude Code compat → Plexon-plugin compat → embedded snapshot), then `Manifest.Validate()`, then for each item resolves the source path, calls the per-kind parser (`skill.LoadSkill`, `subagent.ParseAgentDefinition`, raw `yaml.Unmarshal` for personas), and reports parsed frontmatter or parse errors. Per-row **Open in editor / Reveal in folder / Copy path** action buttons; VS Code, Cursor, and Sublime are auto-detected from PATH. Shows the global install path (so authors debug "why doesn't this show up in the Agents panel?"), encryption mode (`plaintext` for linked entries, `esk` for consumer entries with `encrypt: true`), and subscribes to `marketplaceManifestChanged` so saving `marketplace.json` in the editor re-runs the inspector instantly.

- **Bump version.** Sources → **Bump version** icon (tag glyph) opens a Patch / Minor / Major menu. `bumpMarketplaceVersion` RPC parses the linked manifest's `version`, increments the chosen segment, writes the file atomically, and runs `git add marketplace.json` so the change is staged for the author's next commit. Tolerates empty / `v`-prefixed / pre-release versions; strips `-beta` and `+sha1` suffixes on output. Refuses consumer-mode entries (those clones are Plexon-managed and would be clobbered on Refresh). Never auto-commits — the author drives the commit message, identity, and signing through Source Control.

- **Validate-on-save badge.** Saving `marketplace.json` triggers two things: the Sources tab refetches and re-runs `Manifest.Validate()` against the freshly parsed manifest, and if validation fails the row shows a red **N validation errors** chip next to the **Developer mode** chip. Hovering reveals the error strings; clicking the chip opens the Inspect pane scoped to the marketplace.

- **Sync (team collaboration without git).** A Sync button on the Sources row (and in the Source Control panel, and as the `plexon_marketplace_sync` chat tool) runs the whole loop: workflow / dashboard / hook edits write back into the folder through a scrubber (webhook secrets, save counters, run state, monitoring toggles, and absolute widget paths never reach the repo), everything commits with a generated summary line (deterministic fallback like "Update 2 workflows, 1 skill" when offline), the team's changes integrate, and the author's publish. Staging is scoped to the marketplace's own directories, never `git add .`, so a stray file in the folder can't ship. A validation gate refuses to publish while the manifest or any item fails its parser. On divergence the merge is enumerated and aborted (the linked tree is live and never sits mid-merge); conflicts resolve in one call with a per-file choice of keep-mine, take-theirs, or AI merge (validated by the installer's own parsers), with the author's versions copied to a snapshot folder first. Item-annotated history (`git log --numstat` mapped to manifest items, no hashes shown), an opt-in Auto-sync chip (settle debounce + rate gate, paused by pending conflicts), and push-race retry round out the loop. Offline syncs degrade to commit-only and publish next time.

The Git repo on GitHub stays **plaintext in both modes**. `encrypt: true` in `marketplace.json` is a consumer-side install instruction — encryption happens after each end-user clones. Authors never push pre-encrypted blobs. Contributors review your diffs normally.

The unified Source Control sidebar lists each linked marketplace as its own collapsible group alongside the workspace. Status, stage, commit, push, pull, and diff are scoped to the linked path via the regular `gitStatus`, `gitDiff`, … RPCs with `repo: "marketplace:<name>"`. Sync sits on top of this surface rather than replacing it; authors who prefer the manual flow keep it.

Plugin items and MCP-server items are skipped in v1 linked mode (plugins have their own registry/cache that doesn't yet follow symlinks; MCP servers have no per-item disk surface to link). The rest of a mixed marketplace still installs cleanly, and consumers see no difference.

Symlink strategy: `os.Symlink` first (works on Linux/macOS without privilege, Windows with Developer Mode). Windows fallback for **directories** uses `cmd /c mklink /J` (directory junctions, no privilege required). Windows fallback for **single files** uses `os.Link` (NTFS hardlinks). No admin prompt either way.

## For Companies: Admin Panel, Catalogs, Websites, Agreements

A company on Plexon is not a licence pool. It is a scope with its own panel inside the same app every member already installed, reached by signing in as a company admin. There is no second console to deploy.

### The company admin panel

A company admin sees their own company and nothing else, checked on the server per request rather than at sign-in, so a demotion takes effect on the next call. A row belonging to another company answers as missing rather than as forbidden, because a forbidden answer confirms the row exists.

- **People.** Approve someone who signed up, disable an account, edit a name, promote a colleague to company admin. Filters for everyone, pending, disabled, and the other admins. You cannot change your own access, and the control says why rather than failing when pressed. Creating a person is a short dialog; the address is read-only once it exists, and a Google account says it signs in with Google.
- **Groups.** A group is a set of people plus what that set reaches. Link it to one or more of your catalogs, hide sidebar buttons the group has no use for, grant it the right to publish a website, or take that right back. Members are added by searching your own people, never a wider list.
- **Seats and subscriptions.** Four counts (people, subscriptions, active, past due) computed under the same scope as the rows, so the tiles and the pages they link to agree. Search plus filters by plan and status. One action: cancel at period end, or undo it. A trial row and an already-cancelled row show none, because there is nothing to do to them. Transfers and overrides stay with Plexon.

### Company marketplaces

A company ships its own catalog of skills, agents, personas and workflows. The first decision is where the content lives: Plexon creates and holds the repository, which needs nothing set up first, or you point at a repository you already own, which keeps the content on your infrastructure and under your review. The row states which kind it is.

- Publishing is uploading a package. The row then carries the version, the date, and the address of the person who uploaded it.
- A Plexon-held catalog takes its name from the package manifest, so the name cannot drift from what is inside.
- The audience is chosen: a catalog is offered to the groups you pick, not switched on for the whole company. Someone who leaves that group stops being offered it on their next call.
- A catalog in your own repository carries a credential health indicator, a check that asks the provider immediately, and a rotate that replaces the credential in place, so a quietly expired credential is visible before somebody reports a broken install.
- Deleting a Plexon-held catalog offers to delete its repository with it. A repository you own is never touched.
- The wizard that builds a company catalog is the same one that builds a personal one, so an author who has made one has made both.

### Company websites

Every site a company’s people published from Plexon appears in one inventory: the owner, the address, the state, the certificate state, whether the domain verified, and the last error kept on the row rather than discarded. Taking a site offline is a state and not a deletion, so the address is held and the next publish clears it.

- Sites publish under the company domain. The hosting configuration itself stays with Plexon on purpose, because it decides where a company publishes and who pays for the zone; the company reads it, sees the records it depends on, and can re-check the installation, which is what an owner needs right after installing it.
- Publishing is a right a company admin grants, on a group or on one person, with takedown as a separate switch. Somebody with no grant cannot publish at all.
- A company can remove one site or several at once, and chooses in the same action whether the repository behind it is deleted or left where it is.

### Per-role data agreements

A role carries its own connected apps, workflows and datasets, which makes it the thing that decides whose data moves where: a clinic role reaches a patient database, a sales role reads a mailbox and sends to leads. A role can therefore declare a written agreement, and it will not become the live role until the current version of that text has been accepted.

- What is recorded is the version the author declared plus a fingerprint of the exact document that was shown. Version alone is author-controlled, and an author who edited the terms in place without bumping it would otherwise keep every earlier acceptance looking valid.
- The record is append-only. A new version adds a row rather than replacing one, so "what did this person agree to, and when" stays answerable.
- The gate fails closed. A missing record file, an unreadable document, or a role naming an agreement nothing can resolve all refuse activation. Failing the other way would turn an authoring mistake into a role that silently reaches sensitive data.
- Installing several roles at once gates every one of them, not just the one that was picked, because a merged profile holds the union of what those roles reach.

## Plexon Provider

The Plexon Provider is the default AI provider for subscribers. It offers a unified interface across all task types:

- **Code/Analysis/Planning**: Powered by the Plexon provider's managed coding plan (200K+ context), with HighSpeed tier for Premium subscribers
- **Image Generation**: Inline image creation via plexon-1.0-image model variation
- **Video Generation**: Text-to-video and image-to-video via plexon-1.0-video model variation, with control over clip length, resolution, and the camera move. The request that produced a clip stays attached to the player, so the shot description, length, shape and resolution can be edited, or changed by describing the difference in a sentence; regenerating films a new clip and leaves the original on disk. Premium subscribers only
- **Music Generation**: Songs with written lyrics and vocals, instrumentals, and covers of a supplied recording via the plexon-1.0-music model variation. Premium subscribers only

Key capabilities:
- **Server-side API key pool** with automatic rotation on rate limits (HTTP 429)
- **Per-user rate limiting**: 4,500 text requests per 5 hours, 50 images per day, 10 videos per day, 30 songs per day
- **Multi-task decomposition**: Requests spanning multiple task types are automatically split into specialized sub-agents (plexon-image, plexon-video, plexon-music) that run in parallel
- **Optional Auto Routing**: Toggle AI-based model selection per request (off by default for zero overhead)
- **BYOK compatible**: Users can always switch to their own API keys for any provider
- **Branded experience**: The AI identifies as "Plexon" and error messages never expose underlying infrastructure

No client-side API keys are stored or hardcoded. All keys are managed server-side in an encrypted database pool.

## 5 Specialized AI Modes

1. **Code Mode**: Standard implementation and file editing with full write access. For day-to-day coding, bug fixes, and feature implementation.

2. **Plan Mode**: Read-only planning. The AI explores the codebase and writes one concrete implementation plan, which you approve before any edits. On approval it hands off to Code mode and the plan drives the work. Saved plans are browsable in the Plans panel, where each one can be implemented in a fresh chat that gets the plan file itself (so the AI can tick the steps off as it works), edited with the AI by saying what to change (the same plan file is rewritten, not copied), or picked back up in the conversation it came from.

3. **Ask Mode**: Information and explanations in read-only mode. For learning, documentation, and understanding existing code.

4. **Autonomous Mode**: Self-directed execution with quality validation and iterative improvement. Each cycle: AI generates code, quality is validated (0-100 score), tests are run, feedback is generated, and the AI iterates. Continues until quality threshold is met (default 70%, configurable) or max cycle count is reached (default 5, max 20).

5. **Orchestrator Mode**: Breaks complex tasks into 2-5 subtasks. Up to 3 sub-agents execute in parallel, each with its own session and cost tracking. Results are synthesized into a coherent response. Complex tasks complete in ~45 seconds vs 2+ minutes sequentially.

Alongside these five, **Spec Mode** is set from the title-bar pill rather than the mode
picker, and it has its own page at https://plexon.ai/features/spec-driven-mode/. It drives the GitHub Spec Kit-compatible spec-driven development workflow — constitution → specify → plan → tasks → implement, with a verifier subagent at every step. Living markdown contracts (`AGENTS.md` at repo root, `.specify/specs/<NNN-feature>/{spec,plan,tasks}.md` per feature) replace chat scrollback. Cross-tool by default: same files work in Cursor, Copilot CLI, Claude Code, OpenAI Codex, JetBrains Junie, Aider, Zed, and 30+ AGENTS.md-aware tools. Single `plexon_spec` MCP tool with eight actions (`init`, `list`, `new`, `write`, `read`, `advance`, `toggle`, `refresh`) plus bundled `spec-driven-development` skill that delegates the implement phase to the existing `subagent-driven-development` loop. The UI is intentionally minimal: a title-bar status pill (no sidebar panel) shows the active feature and phase dot at a glance — click for a context-aware popover menu of grounded actions that auto-send to chat (Draft with AI, New feature, Summarize state, Advance phase, Implement next task, Drift report, Update AGENTS.md / constitution). The pill updates **live without polling or a file watcher**: every mutating `plexon_spec` action fires an internal `OnChanged` callback, the daemon recomputes the lightweight status payload and pushes a `specChanged` JSON-RPC notification, and the renderer subscribes through `window.api.daemon.onSpecChanged(cb)` to adopt the payload directly. The `refresh` action is the explicit escape hatch — mutation prompts that take a path through `plexon_write_file` end with a `plexon_spec action=refresh` step so the pill still catches up the moment the writes land. The chat is the UI; the AI does the work. See https://plexon.ai/features/spec-driven-mode/.

## Dynamic Workflows

Visual, durable automations. A single trigger drives a small graph of typed steps connected by edges, built on a node canvas in the Workflows panel or drafted by the chat AI, and run by a deterministic engine in the local daemon. No cloud component. Build it two ways: lay the flow out by hand with a schema-driven config drawer, or describe it in chat and let Plexon draft it (the `plexon_workflow` tool). Chat-built and AI-drafted workflows always land disabled with a review link, so nothing runs until you look it over and switch it on.

Triggers (one per workflow):
- Schedule: a cron expression or a simple interval; enabling fires one run right away, then continues on cadence.
- App poll: watch a connector and fire on each new item (for example, a new Gmail message or a new WhatsApp chat), with per-item dedupe so nothing fires twice.
- RSS feed: poll an RSS or Atom feed URL on an interval and fire once per genuinely-new item; the first poll only takes a baseline, so enabling does not replay the back catalogue. Self-contained by URL (no Data Source needed), sharing the feed fetch+parse with the rss Data Source. Each run reads the item on `{{trigger.item.title}}`, `{{trigger.item.link}}`, `{{trigger.item.content}}`, and the rest, plus `{{trigger.feed.title}}` and `{{trigger.feed.url}}`.
- Inbound message: a Telegram or WhatsApp message that matches a chat filter or a keyword.
- GitHub activity: a new issue, pull request, comment, or submitted review in a repository Plexon already watches for Approvals. It rides the same watcher (no second poller against the token, no connector needed), filters by repository and event, and never fires on the connected account's own posts, so a workflow that replies cannot re-trigger itself. Steps read `{{trigger.repo}}`, `{{trigger.event}}`, `{{trigger.number}}`, `{{trigger.title}}`, `{{trigger.author}}`, `{{trigger.body}}`, and `{{trigger.html_url}}`.
- Webhook: a local POST endpoint armed only while the workflow is on, with a minted secret and a uniform 404 for bad requests.
- Manual: a Run now button, also used for test runs. A manual trigger can declare typed inputs (text, number, on/off, JSON), and Run now collects them first so the flow reads `{{trigger.<name>}}`.

Steps (the building blocks, connected by branchable edges):
- Tool: call any connector or MCP tool directly, with zero AI tokens.
- AI: one structured call to extract, classify, or generate, validated against a typed (JSON Schema) result. The fields are declared as plain rows (name, kind, required, a description the model follows), with an AI sparkle that drafts them from the step's instruction and a JSON view for advanced schemas.
- Agent: hand the step to a headless sub-agent. Optional output fields are pulled from its reply and read by later steps as {{steps.<id>.output.<field>}}.
- Persona: run the step as a whole persona, with its instructions, skills, and connected tools. Takes the same optional output fields as the agent step.
- Condition: branch true or false on a rule group (AND/OR) built from pickers with human comparators (equals, contains, starts with, has a value, at least, matches pattern), a one-line expression, or a yes/no question put to the AI. The rules read back as one sentence on the step's card.
- Loop: repeat a body once per item in a list (for-each) or while a condition holds; body steps read the current item as `{{loop.item}}` and its position as `{{loop.index}}`, and the loop collects each iteration's result.
- Transform: derive clean values with no AI tokens. Each field is a recipe form (Clean phone number, Text after a marker, First item, Count items, Sum a column, Join into readable text, Read as a number, Format a date, Fallback value, Map value via table, Build dashboard tiles) or a raw expression one toggle away. Fields run top to bottom and later fields reuse earlier ones by name, so a derivation is written once.
- Wait: pause for a set duration, or until a matching reply arrives; waits are durable and survive a restart.
- Approval: stop and ask the user to approve or reject.
- Notify: post to the in-app inbox, with an optional desktop alert.
- Note: a sticky note on the canvas that documents the flow and never runs.

Building without workflow knowledge: the canvas carries a rail of plain-language steps (Send an email, Send a Slack message, Create a Jira ticket, Extract with AI, Only continue if, For each item) that land pre-filled with their tool and name, by click or by drag; the New button offers describe-it-to-the-AI, copy-any-workflow-as-a-template, and blank; a step nothing leads to says so on its card and one click wires it in; and turning on a never-run workflow asks once whether to test it first. The popular app connectors sit on the rail (Jira, Slack, GitHub, Linear, Asana, Trello, ClickUp, Notion, HubSpot, Discord), their argument forms render with friendly field names from a shipped catalog even while the connector is stopped, arguments fill themselves from what the steps above already produce (a Send an email step added under one that found the sender's address arrives with To filled, matched on what a value is rather than what it is called, so the same source fills a Gmail To with an address and a WhatsApp To with a phone number), several steps can sit on one condition branch (aim a second at a branch that is taken and the canvas asks whether it runs before or after, then redraws the branch in that order so the new step is drawn where it runs; an insert into a wire redraws the same way, while a plain append onto a free connection leaves a hand-arranged canvas alone), and a "New item in an app" trigger fires the workflow on a new Jira ticket, GitHub issue or pull request, Linear issue, Asana task, ClickUp task, Trello activity, Slack or Discord channel message, or HubSpot contact.

Loops, expressions, and a built-in test: a loop step is a legal cycle backbone (alongside wait), so a workflow can repeat work without spinning hot. Transform steps, the condition expression mode, and a while loop share a small expression language (filter, map, len, string and math helpers, plus Plexon's own clean_phone, text_after, text_between, line_with, first, parse_number, lookup, fmt_date, and markdown) that is checked when you save, so a typo surfaces in the editor rather than at run time. The Test step button runs a single step against the last run's data or sample values and shows its resolved input and output inline; a step that would send something reports what it would send instead of sending for real, and AI, agent, and persona steps stay skipped unless you opt in. Every text field carries a `{}` menu that lists exactly what the selected step can read: the trigger's fields (including a manual trigger's typed inputs), the output of every step wired before it, loop variables when the step sits in a loop body, each step's status and branch, and run details like the current time, all searchable. A `{{...}}` path that names a step running later in the graph, a step that does not exist, or a misspelled namespace is flagged under the field as you type and again when you save. The canvas also has undo, redo, and copy or paste of a step.

Durable and safe by design: every run is one JSON file on disk that snapshots its full definition at the start, so editing or deleting a workflow never corrupts a run already in flight. Side effects are at-most-once: if the daemon stops mid-step, the run pauses and asks you to retry, skip, or cancel, and nothing re-sends silently. Workflows run unattended by default, or switch on supervised to approve each send-class step before it fires. Templating pulls trigger data and earlier step output into later steps with `{{...}}`, and it is strict wherever a value leaves the machine (a tool argument, an agent prompt, a condition side), so a greeting can never go to an empty phone number. Secrets never render into a run, and saved step inputs and outputs are redacted and size-capped. Three failed runs in a row disable a workflow and notify you; auth errors disable immediately. Definitions, runs, and cursors live under the Plexon home (global) or in a project's `.plexon/workflows` folder.

Bundled examples (ship disabled): "Greet new contacts on WhatsApp" watches Gmail for a new email, reads the message, and asks the AI to pull out a mobile number. If there is no number, it replies in the thread to ask for one and waits for the answer. Once it has a number, it sends a hello over WhatsApp and posts a note to the inbox. The example arrives switched off on the canvas; connect Gmail and WhatsApp, sign in to Google once, review each step, and enable it. A second, no-connector "Loop over a list" demo shows the loop and transform steps end to end: paste a JSON list, and it walks each item, builds a record, and reports the count. Beyond that one global example, personas can ship their own workflows: the Stock Trader persona brings a pre-market briefing, a watchlist signal scan, a volatility radar, an earnings and catalyst scan, a weekly sector rotation digest, a weekend crypto watch, an end-of-day journal that saves a recap to a file, a single-symbol alert, a watchlist sentiment scan, and a this-week's-earnings digest, all on free no-key market data, with alerts that stay quiet until a condition fires so a quiet check sends nothing. See https://plexon.ai/features/dynamic-workflows/.

Built-in tools a tool step can bind, with no AI tokens spent on the call: the file and document family (`plexon_read_file`, `plexon_write_file`, `plexon_find_files`, `plexon_grep`, `plexon_document_markdown`, `plexon_print_pdf`), guarded web requests to hosts already approved, the free no-key data tools (weather, air quality, exchange rates, stocks and watchlists), and the local stores (`plexon_outreach_upsert`, `plexon_outreach_list`, shopping lists, watchlist edits). The common shape is draft, save, print: an agent step writes the draft, a tool step saves it as a Markdown file, and `plexon_print_pdf` prints that same file to a PDF, with headings, bold, lists, and tables coming out as real typography on an A4 page rather than raw markup. A notify step can then open the finished PDF on click.

Edit with AI: an AI panel docks beside the canvas. Say what you want changed and the graph repaints as each save lands, without leaving the editor; the AI rewrites the definition through the same `plexon_workflow` tool. The canvas is read-only while a turn runs, Stop cancels it, Ctrl+Z rolls an applied change back, and editing a running workflow leaves it switched on. A step's own sparkle focuses the ask on that step. Run or Enable a flow that needs a connector you have not set up yet, and the connector install wizard opens in place. Share a workflow the way you share agents and skills: attach it to a persona so it arrives ready to run, or bundle it into a linked, managed, or consumer marketplace, with per-project or global activation and clean teardown when a managed marketplace is revoked.

## Dashboards

Live boards of widgets, built on the same render engine as the in-chat widgets and run by the local daemon. A board lays out widgets on a drag-and-drop grid; each widget fetches its own data and shows when it last refreshed. No cloud component.

Each widget reads from one source: a connector or built-in tool (a direct call, zero AI tokens), an AI query (one structured call with a typed result), the output of a workflow, plain static text, or another widget already on the board. Point a widget at another widget's data and one fetch feeds every dependent view; each dependent follows the source's own refresh instead of running its own. Widget types cover stat tiles, line, bar, pie, and area charts, a gauge, a status pill, a table, and full HTML (a single file or a multi-file project with its own sandboxed origin). A table widget's rows can carry an action button that runs a tool on that record, with a visible mapping from the row's fields to the call's arguments and a confirm step before it fires. Arguments are JSON, and a board can declare parameters (for example a City dropdown) that fold into every widget's arguments through `{{...}}` and re-run the board when they change.

Adding a widget starts with a task-first palette: recipes like Track a stock, Weather now, and Rows from a data source arrive with their data source already wired up, so a first widget works before you touch a single argument. App feeds come from the same palette: latest WhatsApp messages, unread email, recent Google Drive files, your open Jira tickets, open pull requests, your Linear issues, cards in a Trello list, ClickUp tasks, newest HubSpot contacts, recently edited Notion pages, and a Discord channel feed, each bound to its connector tool with the wiring filled in. The full widget catalog sits under All widget types. While editing, an issues chip surfaces problems in plain language as you type, a missing argument, a shape that will not fit the widget, with a Fix button wherever Plexon can infer what you meant.

An AI-powered widget needs no schema: describe what it should show, and the output shape comes from the widget type itself rather than a field list declared by hand. Run it once to preview the result before the widget goes live, with a budget chip keeping the spend in view alongside the refresh interval.

Refresh is per widget and cost-aware, offered in plain language, Manual, Every 15 minutes, Hourly, or Daily, rather than a raw seconds field. Free tool and data calls refresh on their own schedule, while AI and other paid calls are opt-in with an interval and a budget. Turn on monitoring and a board keeps refreshing in the background even when it is closed; if a budget runs out, the board pauses itself rather than overspend.

Build a board three ways behind one New dashboard button: describe it in chat and let the AI draft the widgets, data, and layout; copy one of your own boards as a template; or start from an empty grid. Edit with AI docks a panel beside the grid and works on a single widget or the whole board, with the board updating live as each save lands; HTML widgets edit the way pages do in the embedded browser, by pointing at an element and saying what to change. Boards are shareable artifacts: attach one to a persona or bundle it into a marketplace, like agents and skills.

Bundled examples: a "Weather & City" board fed by free, no-key built-in weather, air-quality, and currency tools; and a "Global Intelligence" board, a live world map of recent earthquakes and natural events with panels for space weather, air quality, crypto and market mood, prediction-market odds, world headlines, fresh cyber threats, and cloud-service status. Both are built on free public data (USGS, NASA EONET, NOAA SWPC, Open-Meteo, CoinGecko, Polymarket, public news feeds, abuse.ch, and cloud status pages) with no API keys; Global Intelligence adds optional flight, wildfire, and air-quality-station layers that stay hidden until you connect a free OpenSky, NASA FIRMS, or OpenAQ key. Each ships inactive and fills itself in the moment you open it. See https://plexon.ai/features/dashboards/.

## Projects

Your own project and task list, kept in one place per machine rather than per repository, and separate from the per-chat checklist the AI keeps while it works on one request. A project holds tasks. A task points at any folder on the machine, nests as a subtask up to five levels deep, repeats on a schedule, names who owes it, and carries links out to a tracker.

One board, a column per status, whose cards drag between and within the columns. Dropping a card into another column changes its status; dropping it between two cards sets its position. Subtasks stay out of the columns until you turn them on, so breaking one task into six does not flood a column. Every drag has a keyboard equivalent (1 to 5 set a status on a focused card, Space toggles Todo and Done), so the board is never mouse-only.

Tracker links are reference only. Paste the URL of a Jira issue, a GitHub issue, a Linear ticket, or anything else with an address, and the chip opens it in your browser. Plexon does not sign in to the tracker, does not read its status, and does not write anything back, which means nothing breaks when a token expires, your team board can never receive a wrong status from here, and a tracker Plexon has never heard of works exactly as well as Jira.

Repeats are created on completion, not on a timer. Finishing a repeating task writes the finished record and creates the next occurrence in the same step, so there is no background job to miss while the app is closed and nothing fires twice. The next date counts from the previous due date rather than from the day you ticked it, so a weekly task keeps its weekday when you finish it late; finish something months overdue and you get one occurrence in the future rather than a pile of missed ones. Accepted rules read as words: every day, every 3 days, every week, every 2 weeks, every monday, every monday, thursday, every weekday, every month, every month on the 15th, every month on the last day, every year. Anything else is refused rather than guessed at.

A folder that is not on this machine is flagged rather than quietly dropped, because the record of where the work lived is worth more than a tidy row.

A board can also be shared with a team on Premium. A shared board is the same folder of markdown files kept in a git repository your side owns: drag a card, assign it, comment on it, press Sync. Boards inside a repository are discovered rather than registered, so one a teammate created shows up on your next sync under the name they gave it, and a company can provide the repository and broker a short-lived push credential per person, so nobody on the team needs a GitHub account or a token to paste.

Every record is one markdown file with its fields at the top, editable in any editor and stored outside your repositories so nothing lands in a commit by accident. Projects and tasks are drawn on the memory graph beside the people and notes they relate to, so a person on the canvas carries the work assigned to them. They are drawn there and nowhere else: the assistant reads them through one tool when the conversation is about your work, and nothing about them rides the turns that are not. See https://plexon.ai/features/projects/.

## Data Sources

Load a local spreadsheet (.xlsx) or CSV, or an RSS, Atom, or JSON feed URL, and use its columns in workflows and dashboards. A Data Source is the parsed table: named, typed columns and rows. Import it once from the Data Sources panel (drag a file in, choose Add a feed from the Add menu, or import inline wherever a source is picked) and both an automation and a board can read it. The import wizard previews the file and sets the name, the scope (this project or all projects), the sheet and header row for multi-sheet workbooks, per-column types (text, number, yes/no, date), and the default freshness. Excel is converted to a CSV snapshot on import; type inference is deliberately conservative (textual booleans only, ISO YYYY-MM-DD dates only, leading-zero and very long integers kept as text) so Contact ID, Deal ID, and phone columns are never mangled into numbers or dates.

An RSS, Atom, or JSON feed is modeled as a Data Source too: each item is a row. Paste the feed URL and it loads with the same canonical typed columns (title, link, published, author, summary, content, categories, id), plus image and enclosure when the feed carries them, and an optional expose-all-fields toggle that adds a column for every other element. RSS 2.0, Atom, and JSON Feed are all supported. Paste a site home page instead of a feed and the wizard discovers the feeds the page links to and lets you pick one. A private feed (behind an API key, a bearer token, or basic auth) authenticates through an API Connection picked in the wizard; the credential rides only the feed's origin host and is dropped on a cross-host redirect, and a login form (cookie/session) is not supported. The fetch goes through the same SSRF-guarded HTTP path the API Connections and plexon_http_request use (scheme and host allowlist, post-DNS private/loopback rejection, DNS-pinned dial), capped at 16 MB; a feed URL that resolves to a blocked address is refused. Feeds default to live freshness, and a live feed read is cached for about a minute so several dashboard widgets on one feed share a single fetch.

Freshness is your choice and overridable wherever the source is used. Snapshot keeps the copy taken at import: offline-safe and fixed until you refresh or re-import, best for a one-off campaign over a frozen list. Live re-reads the original file each time, best for a file you keep editing. Refresh from source pulls the latest rows into the snapshot on demand.

Preview opens as an extended in-panel grid (the way a board opens, not a modal): every row paged at 25 to 250 per page and fetched a page at a time from the local daemon, a search box across all columns, per-column filters in a dropdown off the search bar, and click-to-sort. The search, filters, and sort run server-side over the in-memory snapshot, so the renderer only holds the visible page even for a list of thousands of rows.

Use a source in a workflow by giving it a Data source input, which resolves to an object of {id, mode}. A tool step calls the read-only plexon_dataset tool with the dataset id and mode, its output carries a rows array, and a loop step walks the rows reading each column as {{loop.item.<Column>}}. The run dialog opens the picker so a non-author chooses the file (or imports one) at run time. Use a source on a dashboard by binding a widget straight to it: click Use a data source in the widget editor, pick the file and the column from dropdowns (a table widget renders the whole sheet, a metric or gauge widget maps one column to its value), or reference a board parameter of type Data source for a viewer-switchable list. The read-only plexon_dataset built-in tool backs both paths and the AI can call it from any prompt; it takes dataset, mode, limit, offset, columns, and group_by, and returns {name, source, mode_used, columns, rows, row_count, returned, groups?} with rows keyed by column name so a loop and a table both read them directly.

Creating and changing a Data Source from chat is a second built-in tool, plexon_dataset_edit. Its actions are create (a name plus rows as CSV text or as a JSON array of objects keyed by column name, with optional description, scope, freshness, and per-column type pins), append_rows, replace_rows, update_rows, delete_rows, and delete. Rows are selected by 1-based row number, as numbered in the preview grid, or by a column value matched as text ignoring case and surrounding spaces; a selection that matches nothing is an error rather than a silent no-op. Every write goes through the same save path the import wizard uses and ends in the notification the Data Sources panel, the pickers, an open preview, and the command palette all listen for, so a change lands in the app immediately instead of waiting for a restart; the daemon holds the dataset index in memory, so editing the definitions JSON on disk by hand does nothing until the app is restarted. A source the assistant creates has no imported file, so its snapshot CSV doubles as its source: the user can open it in a spreadsheet and Refresh from source still works. Four refusals keep a result honest: a feed cannot be edited because its rows are replaced on every refresh; a source in live mode backed by a file the user owns is refused, because the next read would re-parse that file and discard the edit; a snapshot-mode source backed by such a file is edited but the result says the original is unchanged; and an organization-managed source can have its rows edited but not be deleted. Unlike plexon_dataset it is deliberately not on the bindable built-in allowlist, so no dashboard widget refresh or workflow tool step can create or delete a user's data unattended, and it is blocked in Plan mode.

A source lives in one project or globally, and moves between the two from its card at any time. The move keeps the same id, so workflows and dashboards already pointing at the source keep resolving; the panel footer shows the count in each scope and a sidebar badge shows the total. Everything stays on disk under ~/.plexon/datasets (global) or <project>/.plexon/datasets (project): a small index plus one snapshot CSV per source, also reachable as the $PLEXON_DATASETS path token. Imports cap at 64 MB and snapshots at 200,000 rows; a deleted source surfaces a clear missing-source message instead of failing silently. The PNOĒ Sales persona ships a Lead email campaign workflow and a Leads List dashboard as worked examples. See https://plexon.ai/features/data-sources/.

## 192 Built-in Agents

Plexon includes 192 nonhidden standalone agents. Bundled plugins include 16 additional agents, available when their plugins are enabled. The shipped inventory contains 212 agent definitions in total, including background helpers.

Examples include:
- Code Reviewer: review a code change.
- Market Analyst: research a market.
- Content Creator: draft campaign content.
- Line Editor: edit a chapter.
- UX Researcher: plan research into how people use a product.

An agent is a specialist assistant with its own instructions and tools. Users can create their own agents too.

### AI-Authored Agents From Chat

The chat can now create, list, read, update, and delete the user's global subagents end-to-end through a dedicated `plexon_agent` MCP tool. Ask in plain English -- "Create an agent called release-captain that runs in code and architect modes" -- and the model produces a validated AGENT.md at `~/.plexon/subagents/<name>/`. The full schema is exposed: name, description, system prompt, modes (code/auto/ask/architect), tool allowlist and denylist, skill allowlist, skill directories, max turns, max token budget, cost budget USD, emoji, color, provider override, model override, vibe (when-to-use guidance), and file-pattern triggers for conditional activation. Each write surfaces in the standard tool-permission UI with a full preview of the params before anything lands on disk. Bundled and plugin-installed agents are read-only -- the daemon refuses mutations and the AI offers to fork under a new name. Sub-agents cannot mutate global agents (the tool is excluded from sub-agent contexts to prevent runaway rewrites). Works with every provider because the tool schemas live in the embedded MCP server, not in provider-specific system prompts. The bundled hidden `plexon-author` companion skill auto-loads with the schema reference, decision rules for "skill vs. agent", and worked examples.

## 150 Built-in Tools

The built-in inventory includes 140 embedded tools. Your role and settings determine which tools are available. They cover:
- File operations (read, write, edit, search, glob)
- Grep with ripgrep acceleration and multiline support
- Code search across 15+ languages
- Code intelligence through a real language server: definitions, references, implementations, call hierarchy, file symbols, and diagnostics
- Git operations (status, diff, commit, log)
- Browser automation via Playwright
- Desktop automation (mouse, keyboard, screen capture)
- MCP resource browsing (list and read resources from external servers)
- HTTP client for API testing
- Image analysis and generation
- Continuous voice conversation mode (hands-free turn-by-turn loop, local Whisper STT, Edge TTS / My Voice local cloning / OS-native, push-to-talk barge-in, transcript metadata)
- Constrained optimization and Monte Carlo simulation (routes, packing, schedules, budget allocation; runway, portfolio drawdown, delivery arrival, waiting time)

Plus support for unlimited external MCP tool integrations.

## Code Intelligence — The Compiler Answers, Not a Text Search

A text search finds the letters you typed. It cannot tell which of four methods called Start you meant, that a match inside a comment is not a use, or that a call three packages away resolves here. Plexon starts the same language server an editor would (gopls for Go, pylsp for Python, typescript-language-server for TypeScript and JavaScript, rust-analyzer for Rust) against the project it has open, and asks it.

What it answers: where a symbol is defined; everywhere it is used; its type and documentation; what implements an interface or overrides a method; what calls a function and what that function calls; every symbol a file declares, nested by what contains it; and what is currently wrong with a file, or across every file a server has analysed.

Addressed by name, not by coordinates. Most tools of this kind want a file, a line, and a column, which means reading the file first only to count characters, and getting it wrong as soon as anything shifts. Plexon takes the name: ask about ProcessRequest, or say Server.Start when two types share a method name. A name that genuinely matches several symbols comes back as a list of candidates with their positions rather than a silent guess at one of them.

Mistakes surface on the edit that caused them. When Plexon writes source code, it asks the language server what it now makes of that file and reads the answer before moving on, so a type that no longer lines up, an import that resolves nowhere, or a call whose signature changed is fixed in the same reply instead of at the next build. The check only ever consults a server that is already running, and is bounded per file and per batch, so an edit never waits on a cold start. Errors sort ahead of warnings, editor hints are dropped, and an answer the server has not finished settling is marked as such rather than presented as final.

Nothing to configure. The project language comes from what is in the folder, the server starts in the background and installs itself when the toolchain to build it is present, and the folder icon in the title bar carries the state. Until a server is ready, questions fall back to text search rather than waiting. The workspace's own language stays resident; a server started to answer one question about a stray file is released once it goes quiet. Plugins contribute servers for other languages through a .lsp.json file, effective the moment the plugin is enabled.

## Decision Tools — Compute the Answer, Do Not Guess It

Routes, container loads, shift rosters, budget splits, and forecasts are search and sampling problems. A language model answering them from intuition produces something shaped like an answer, and the failure is silent: a route 30 percent longer than optimal reads exactly like an optimal one. Two deterministic, offline tools run the work instead.

`plexon_optimize` covers four kinds: route (visit order, optional per-stop time windows, optional return leg), pack (items into differently sized containers by weight and volume), schedule (tasks across parallel resources with dependencies and release times), and allocate (whole units under a budget with per-item floors and ceilings, maximizing value or landing on a target). Every result reports the objective value, whether the search converged or ran out of budget, and the seed that reproduces it exactly. It never claims the result is optimal, and an infeasible input names the constraint that blocked it and by how much, so "the 1800 kcal ceiling and the 150 g protein floor cannot both hold with this food list" replaces "no solution".

`plexon_simulate` answers how confident to be rather than which arrangement is best: cash runway with an optional funding round that may not close, portfolio value and maximum drawdown under correlated returns, delivery arrival time across uncertain legs, and waiting time and utilization for a given number of rooms or staff. Uncertainty is declared as fixed, normal, lognormal, uniform, triangular (worst, likely, best, which is how people actually hold an estimate), or resampled from real history. Each run returns percentiles plus the probability of the outcome that matters, and states the simplification it made, so the waiting-room model says outright that it assumes nobody gives up and leaves.

Both need no API key and no network, cost nothing per run, and are bindable in dashboard widgets and workflow steps, so a board can show the current best packing and a scheduled workflow can re-plan a delivery round without spending a token. Route distances come from a maps service or from the user and are never invented, because a made-up distance matrix is the exact failure these tools exist to prevent. Built in on every install, with no role or setup required, and the Founder Cockpit board carries a cash fan chart built on the runway model. See https://plexon.ai/features/decision-tools/.

## Adaptive Routing: Day One Is Unchanged

Every routing decision in Plexon used to come from a fixed heuristic that never found out whether it was right, which made it exactly as good on day 400 as on day 1. Adaptive routing gives those decisions a way to be corrected by what one user actually does: which suggestion they take, which agent actually finishes the job. It is a multi-armed bandit, one Beta posterior per option per coarse context bucket, sampled with Thompson sampling. A model was the wrong tool here because the decisions are discrete, the option count is small, the reward is sparse and delayed, and a single user never produces enough data to train anything.

**Cold start is today's behaviour, by construction rather than by luck.** The ranking blends the heuristic score with a sampled posterior at a weight of `n / (n + 4)`. With no observations that weight is zero, the blended score is the heuristic score, and a stable sort returns the input order untouched, ties included. The ranker short-circuits entirely when no candidate has evidence. Two consequences follow: nobody can see a regression on day one, because on day one nothing changed, and the ranking diverges from the old one only in proportion to the evidence. Two observations move a ranking by at most a third. Tests pin the cold order across 500 draws and assert that two lucky wins cannot flip a ranking.

**Every reward already existed.** Nothing here invents a signal, and nothing infers dissatisfaction from prose: a consent card accepted scores 1.0 and declined 0.0; a verifier verdict of pass 1.0, unverifiable 0.5, fail 0.0; a loop agent reporting done 1.0, partial 0.5, blocked 0.0; a workflow run reaching completed 1.0 and failed 0.0; a tool result that errored 0.0. Unverifiable is half credit because "the agent could not check the work" is not "the work was wrong". A cancelled workflow run is deliberately absent from the table: the user stopped it, which says nothing about the choice, and scoring it as failure would teach the wrong lesson every time somebody changed their mind. A missing, empty, or echoed-template verdict parses as nothing and leaves the decision unresolved.

**Delay is the normal case.** A verifier verdict lands after the turn that caused the decision, so each decision is recorded against the correlation id the later signal will carry (a session id, a workflow run id) and resolved when that signal arrives. The same signal twice resolves once. A decision still unresolved after 7 days is dropped, and expiry never invents a reward. Most decisions never get a signal at all, which is fine.

**Old evidence fades.** Evidence decays once a day at 0.977, retaining about half over a month, so what Plexon learned about the work somebody did six months ago stops defining them. An option decayed back to its prior is deleted rather than left as a row that says nothing. A heuristic that changes between releases can seed a prior for a cold option but can never overwrite one that has real observations.

**Both switches are on, and both are negative keys.** Picking a specialist agent for a sub-task that named none is on by default and turned off with `behavior.disable_agent_routing`. The choice being replaced is the generic ad-hoc sub-task, not the absence of a choice, and with nothing learned the pick is the plain description match, so day one is a sensible default rather than a random one. Letting close candidates bid for the task keeps its own switch (`behavior.disable_agent_bidding`, also on, requires routing) because it is the only part that spends tokens: one short model call per candidate, at most four, and only when the top two descriptions score within 0.15 of each other. An absent key means the feature is on. An explicit choice always wins, so an `agent_ref`, an `@agent` mention, or a manual pick stops the router entirely. An agent whose declared modes exclude the current mode is never selectable, hidden agents such as the harness verifier stay opt-in, and a name the router returns that was not in the candidate list is refused. `plexon_tool_search` stays deterministic and is not routed at all, because it has a golden corpus asserting top-one accuracy and a tool that stops being found is a tool the AI cannot reach.

**It is inspectable and resettable.** Settings, Advanced, "What Plexon learned" prints one block per context bucket, one line per candidate, each with its score and the number of runs behind it. The run count is given the same weight as the score on purpose: a mean of 100% over two runs and a mean of 62% over ninety are the same number to anyone reading percentages alone, and only one of them is worth acting on. Reset works per bucket or all at once, and after a reset behaviour is day-one behaviour again. The panel prints the state file's path, because deleting that file by hand is a legitimate way out. Behaviour that drifts over time with no visible state is indistinguishable from a bug, which is the reason that screen exists.

**It never leaves the machine.** The posteriors are a behavioural profile of one person, so they are stored like a credential rather than a cache: one local JSON file at `~/.plexon/routing.json`, written atomically with mode 0600. No bucket, no option, no posterior, and no decision log is ever attached to a request. A corrupt file costs the learning and not the feature: Plexon reports the error, starts cold, and behaves exactly as it did on day one. See https://plexon.ai/features/adaptive-routing/.

## App Connectors (81 Branded Integrations)

Beyond the built-in tools, Plexon ships 81 branded app connectors: pre-built MCP tool servers for specific products that the user turns on once with their own account. Sign-in matches each app (a browser OAuth flow, an API key or token to paste, a server URL from the provider, or a one-time QR scan for personal WhatsApp). Credentials are encrypted and stay on the user's machine; activation is per workspace.

The catalog: Slack, Discord, Telegram, WhatsApp (business and personal), Twilio, Instagram, X (Twitter), Unipile, Notion, Google Drive Suite, Google Workspace (multi-account, including Gmail), Microsoft 365, Todoist, Asana, Trello, Dropbox, WordPress, Linear, Atlassian (Jira and Confluence), Salesforce, HubSpot, Twenty, Zendesk, Intercom, Mailchimp, Keragon, FitMetrics, GitHub, GitLab, Vercel, Netlify, Cloudflare, Railway, Docker, Kubernetes, Supabase, Firebase, Sentry, Datadog, Grafana, Langfuse, CircleCI, Buildkite, shadcn/ui, x64dbg (the Windows debugger, through its MCP plugin), GoDaddy, Brave Search, Perplexity, Exa, n8n, Zapier, Pipedream, Make, Home Assistant, Airtable, Database (PostgreSQL, MySQL, MariaDB, SQL Server, SQLite), BigQuery, ClickHouse, Redis, PostHog, Stripe, Shopify Dev, WooCommerce, Product Search, Shopify Shopping, Affiliate Buy & Feed Hub, eBay, Figma, Meta Ads, Spotify, Reddit, Higgsfield, ViewMax, Agent Browser, Playwright, Browser MCP, Chrome MCP, Desktop Automation, and Skyvern.

Every connector has a dedicated page at https://plexon.ai/connectors/<name>/ (for example https://plexon.ai/connectors/slack/) describing what the assistant can do in that app, example prompts, and how sign-in works. The full catalog lives at https://plexon.ai/features/app-connectors/.

## Office Integration: Word and Excel

Create and edit Word documents and Excel spreadsheets from chat. Turn a client list into letters, summarize a workbook, or prepare a report with Plexon AI.

Enable Word or Excel from the Tools panel. File editing works on Windows, macOS and Linux without an Office installation. When Word is open on Windows or macOS, Plexon can edit the open document with tracked changes. Writer and Product Manager include Word tools; Financial Analyst and Dietitian include both.

Files are saved on your computer. If you use an online AI service, it receives the document content needed for the request.

## Document Reader — Read Any File in Chat

A built-in tool reads rich documents into clean Markdown so the AI can search, quote, and reason over them. The user points Plexon at a file and asks a question in plain language; the reader converts the contents behind the scenes and hands the Markdown to the assistant. Nothing is exported or pasted by hand.

Supported formats: Microsoft Word (.docx), Excel (.xlsx and .xls), and PowerPoint (.pptx), plus PDF, EPUB, CSV, HTML, and email (.msg and .eml). It also reads OpenDocument files (.odt, .ods, .odp), RTF, FictionBook, and markup such as LaTeX, reStructuredText, Org, Textile, MediaWiki, DocBook, man pages, OPML, and Typst, using a pandoc backend alongside the markitdown converter. Tables come back as Markdown tables so figures survive the conversion. Opaque formats also respond to a plain "read this file" request, so a document reader question and an Office edit start the same way; the extra converters install themselves on first use.

The reader is a first-party built-in tool, not a connector or a plugin. The first time it runs it sets up its own converter in the background; there are no API keys, no accounts, and no settings to open, and it works the same on Windows, macOS, and Linux. Files stay on the user's machine.

Because reading is a built-in tool, it works in every chat mode and inside workflows and dashboards, and it composes with the rest of Plexon: read a PDF, drop its figures into a spreadsheet with the excel-mcp Office tool, and draft a memo with office-word in a single conversation, or feed a document into a workflow step. It complements Office Integration, which handles creating and editing Word and Excel files, while the Document Reader covers reading the wider set of formats.

Printing goes the other way. A second built-in tool renders a local file to a real PDF with the app's own browser engine, and it takes two kinds of input. A Markdown file is the short path for prose the AI just wrote: a follow-up letter, meeting notes, a summary, a report. It prints as real typography on an A4 page, with headings, bold, lists, tables, quotes, and code laid out properly instead of the raw `**bold**` and `- ` markup that a hand-built HTML wrapper would leak into the page. An HTML file prints exactly as it looks in a browser: full-bleed backgrounds, web fonts, and chart scripts all survive, reveal.js decks paginate one slide per page, and no date or file-path banner is stamped on the output. Page size, orientation, and margins are options; nothing has to be installed, and no pandoc or LaTeX toolchain is involved. Workflows can bind the tool too, so an agent step's draft can be saved and printed on a schedule with no tokens spent on the conversion.

A third built-in tool sends the same document to a physical printer. It takes the same two input formats and runs the same render, so the paper matches the PDF; on top of the PDF options it adds copies, two-sided printing, and a printer name. A default printer lives in Settings under Appearance, Printing, and an empty setting falls through to whatever the operating system treats as the default, so an untouched install still prints. Naming a printer that does not exist comes back with the list of printers the machine actually has, which is why there is no separate tool for enumerating them. If a page runs past the sheet, the result says which one and by how much, before the next job is sent. Printing needs the desktop app, and unlike the PDF tool it cannot be bound into a dashboard or a scheduled workflow: a regenerated PDF is overwritten next run, while paper is spent. This is the one capability on this page that exists because the shell could not cover it. On macOS and Linux `lp -d` already prints properly through CUPS, but Windows has no built-in command that sends a styled document to a named printer, so without this tool the assistant had no correct way to do what a user was plainly asking for.

## Embedded Browser — Point & Edit Local Websites

Plexon ships with an in-app webview that docks next to the chat, resizable via a drag handle and persisted across sessions. It closes the loop between a running dev server and the AI: the user points at any DOM element on their own site (typically `localhost:3000`, a Vite preview, a Next.js dev server, or a staging URL), types a short instruction, and Plexon sends the AI a message that already carries the exact CSS selector, inner text, viewport dimensions, outer HTML, a computed-styles digest, and a cropped PNG of that element — inline in the prompt.

The AI then uses its normal file-editing tools (`plexon_read_file`, `plexon_grep`, `plexon_code_search`, `plexon_write_file`) to find the source component that renders the element and apply the change. Plexon deliberately does not try to reverse-map the selector to a source file via source maps or heuristics — the model searches the workspace itself, which is both simpler and more accurate.

### How it works end-to-end

1. User clicks the globe icon in the chat input toolbar. A split pane opens on the right with a URL bar, navigation controls, and a Chromium `<webview>` hosting the target URL.
2. User clicks the crosshair toggle to enter inspect mode. A blue highlight follows the mouse with `z-index: 2147483647` (int32 max) so it outranks any host-page stacking context including modal dialogs and fullscreen surfaces.
3. User clicks an element. The injected preload captures the metadata, exits inspect mode, and posts the payload to the renderer via `ipcRenderer.sendToHost('element-selected', …)`. The renderer then calls `webview.capturePage(rect)` to produce a cropped screenshot of that element in CSS pixels.
4. A docked inspector popover appears under the viewport showing tag, id, classes, selector chips (ranked), inner text snippet, and the screenshot thumbnail. The user types an instruction (Enter sends, Shift+Enter newline, Escape exits inspect mode).
5. The "Send to AI" button builds a `ContentBlock[]` with a `text` block (selector + viewport + outer HTML + styles) and an `image_url` block (the cropped screenshot as a base64 data URL), calls `chatStore.addMessage` and `DaemonService.sendMessage`, and lets the regular streaming pipeline respond. No new provider code, no new session scope, no new message shape.

### Four-tier selector strategy

Selectors are emitted in stability order so the AI targets the most refactor-resilient handle available:

1. **QA hooks** — `data-testid`, `data-qa`, `data-cy`, `data-test`, `data-ui`. These attributes exist precisely to be stable; they survive refactors.
2. **Other `data-*` attributes** — author-controlled, usually semantic.
3. **`#id`** — exact when hand-written, noisy when framework-generated (React 19 `useId`, MUI auto-ids).
4. **Positional CSS path** — `body > main > div:nth-of-type(2) > button` with `:nth-of-type()` collision handling. Always valid, rarely stable.

`CSS.escape` is applied to ids so values with legal-in-HTML-but-illegal-in-selector characters (colons, dots) still produce valid selectors. The inspector renders all four options as clickable chips; the user can switch selector without losing their typed instruction.

### What the prompt actually contains

```
Regarding the <button> element at http://localhost:3000/pricing [viewport: 1024×768]
(selector: `[data-testid="cta-primary"]`, text: "Start free trial"):

make this button red, a bit bigger, and add a hover glow

<details>
<summary>Outer HTML</summary>
```html
<button data-testid="cta-primary" class="btn-lg btn-primary">Start free trial</button>
```
</details>

<details>
<summary>Computed styles (digest)</summary>
```css
  display: inline-flex;
  position: relative;
  color: rgb(255, 255, 255);
  background-color: rgb(14, 165, 233);
  font-size: 16px;
  font-weight: 600;
  padding: 12px 24px;
  ...
```
</details>
```

Plus a cropped PNG of the element attached as an `image_url` ContentBlock so vision-capable models get the exact pixels the user was looking at.

### Security model

- Main `BrowserWindow` keeps `sandbox: true`, `nodeIntegration: false`, `contextIsolation: true`. Only `webviewTag: true` is newly enabled.
- The `<webview>` itself runs with `contextIsolation=yes` (Electron default). Guest pages cannot access `window.api`, renderer state, or the Plexon engine (built in Go).
- The inspection preload uses capture-phase listeners and an isolated overlay div appended to `document.documentElement`; it never mutates the host page's subtree.
- Popups opened from guest pages (`window.open`) spawn their own Chromium windows under Electron's control, with no Plexon preload — they cannot exfiltrate renderer state.
- Electron-builder packages the webview preload under `app.asar.unpacked` so Chromium can load it over `file://` in production (scripts inside ASAR archives are not loadable over `file://`).

### Why not just CDP or Playwright?

Plexon's `web-testing` plugin already ships the Microsoft Playwright MCP server for automated testing — that is external-browser automation, best for E2E tests and scripted flows. The embedded browser solves a different problem: a visual, conversational inner loop where the user is the driver. No accessibility snapshot, no page-object setup, no test harness — just "click the thing, describe the change, let the AI edit the source."

### Settings, persistence, and limitations

- Browser URL and pane width are persisted to `localStorage` (not `client.yaml`) so they survive restarts but don't count as "config."
- Inspect-mode state and the current selection are ephemeral by design — a stored selector would point at a DOM node that no longer exists after the page reloads.
- One inspection equals one message: the inspector popover clears after send so the next selection is unambiguous.
- Outer HTML is capped at 4 KB with a truncation marker to keep prompts tight; the computed-styles digest covers ten high-signal properties filtered out of the hundreds `getComputedStyle` returns.
- Elements scrolled partially below the fold produce a truncated screenshot because Electron clamps the crop rect to the visible viewport — a future enhancement can `scrollIntoView({block: 'center'})` before capture.
- v1 supports one webview at a time; multi-tab browsing, flow recording, draw / annotation mode, and DevTools Protocol integration (network, console capture) are explicitly out of scope for the first cut and can layer on top of the same data flow.

Full technical docs: `docs/ui/EMBEDDED_BROWSER.md` in the Plexon repository.

## Prompt Suggestions

After every AI response, Plexon predicts what the user would type next and shows it as placeholder text in the input field. Press Tab to accept or start typing to dismiss. The suggestion is generated asynchronously by the same AI provider (maximizing prompt cache hits for cost efficiency), filtered through strict validation (2-12 words, no evaluative phrases, no questions, no multi-sentence), and never blocks the UI.

## Shell Commands

Start a chat message with `!` and Enter runs it as a shell command on the user's machine instead of sending a prompt: `!git status` and `! npm test` both work, a bare `!` is just text, and a multi-line draft runs as one command. A "Shell command" chip appears in the input toolbar while the draft starts with `!`; Enter runs it and Ctrl+Enter does the same, never queued. The command runs in the session's working directory and the result renders as a terminal card in the chat: the command, its exit status, the working directory, the shell that ran it, the duration, and scrollable copyable output.

The command and its output are stored in the session history, so the next message to the AI already carries them as context (run `!git status`, then say "fix the conflicts"). No AI turn is spent on the run itself. Commands work while the AI is busy: the running task keeps streaming, and the transcript entry waits for the turn to finish before joining history. Under the hood the feature reuses the same per-OS shell routing as the AI's own command tool (PowerShell cmdlet detection, cmd dialect guards, Git Bash for POSIX syntax on Windows, automatic cross-shell retry). Commands the user types skip the AI-facing command blocklists (same trust as a terminal), and a command that runs longer than 90 seconds is promoted to the background with its PID instead of being killed. Output is buffered, not interactive (no PTY), and Live Share guests cannot run shell commands (they would run on the host's machine). A session opened with a command is named after what was run, so the sidebar reads "Open report.pdf" or "$ git status" rather than the stored command record.

## GitHub Auto-Review

Plexon watches the GitHub repositories the user has cloned and drafts a reply to every new issue and a review of every new pull request while they work. The repository is chosen by picking a **folder**, not a URL: Plexon reads that folder's git remote to find it on GitHub and reuses the GitHub account connected once in Settings. Because the code is on disk, the reviewing agent reads the actual files an issue is about instead of guessing from its text. GitHub Enterprise Server works too.

Each repository has a start date, applied to when an issue or pull request was last touched. A dormant thread is left alone, so pointing Plexon at a project with a thousand stale issues does not wake them up; an old one that gets a fresh comment today does count, because that is live work. That bound holds on every path, including a manual "Check now".

Drafts wait in the **Approvals** panel, with the verdict on the front of each row: green for an approval, amber for a request for changes. The user reads it, edits the text, changes the verdict, posts it, or dismisses it. Nothing reaches GitHub until they decide, and a new repository can start in a full draft-only mode where nothing is sent at all. The sidebar badge counts what is waiting whether the panel is open or not.

Pressing **Always** instead of Post turns one kind of action on one repository into something Plexon does alone. Consent is per action kind: approving pull requests and replying to issues are separate permissions and one never implies the other. Each grant carries a daily cap, so a runaway loop degrades to drafting rather than filling a repository with comments; turning it on for a public repository asks the user to type a word first; and it shows as a chip on the repository that one click withdraws. Automatic actions still keep a full record of what was written and where it landed.

Guards that matter: Plexon never replies to items opened by the connected account (replying to yourself is the classic runaway loop) or by bots such as dependabot and renovate, and it checks GitHub live immediately before posting so a second reply never lands on a thread already answered. A pull request is re-reviewed when the code changes, not when someone adds a label, so a rebase storm collapses into one review. Each repository has a daily budget that stops reviews rather than running up an overnight bill, and a GitHub rate limit parks the repository instead of counting as a failure. Three real failures in a row pause it with the reason shown.

It can also write the fix. When the reviewer finds a clear, fixable bug, Plexon copies the repository into a throwaway folder, writes the patch there, and runs the user's own build and test command against it; the user's working tree is never touched. The result is a card with the diff and the test output. Pushing the branch and opening a pull request is a separate explicit click, offered only when the tests actually passed: without a verify command configured, Plexon writes the fix and shows it but never offers to push. Branches are always named `plexon/fix-<number>-<slug>`, never the default branch, and never force-pushed. See https://plexon.ai/features/github-auto-review/.

## Session Tabs

The conversations being worked in sit in a tab strip directly above the chat, so switching is one click instead of opening the sidebar. The strip is the working set; the sidebar stays the full library with its search, filters, pins, locks and bulk delete. It is hidden entirely while only one conversation is open, so nothing changes for anyone who does not want it.

Opening a session from the sidebar with a single click gives it a preview tab, shown in italic, which the next single click replaces. Sending a message in it, double clicking the tab, or dragging it to reorder promotes it to a permanent tab. That is what keeps browsing forty conversations from leaving forty tabs. New chats, deep links, notification clicks and Telegram switches always open a permanent tab, because the user was sent there deliberately.

Each tab carries its own draft, its own mode, and its own scroll position, so a half-typed message stays in the conversation it was typed into and a Plan session sits beside a Code session without either rewriting the other. A tab shows a bar along its edge while its conversation is working, a coloured dot when it finished, errored, or is waiting on an answer, a mode chip when it is not in Code, and a pencil when it holds an unsent draft. Hovering names what that conversation is doing right now.

Closing a tab never cancels the conversation: background sessions continuing is the point, so a running one keeps going and a notice offers to reopen it. Closing an idle one frees its transcript from memory. The strip holds twelve tabs and evicts the least recently used idle one to make room, never a running one. Keyboard: Ctrl or Cmd with 1 to 9 jumps to a tab, Ctrl or Cmd+Tab cycles in most-recently-used order, Ctrl or Cmd+W closes the current tab rather than the window, Ctrl or Cmd+T adds a new chat, and Ctrl or Cmd+N starts one on its own. Alt and click on a conversation, or on the new-chat button, opens just that one and closes the rest. The open set is remembered per project and restored on the next launch, behind an interrupted session if there is one. See https://plexon.ai/features/chat/.

## Response Style — How Long Answers Run

A response style in the Behavior menu beside the send button sets how long answers run. Concise trims replies to the answer itself and saves output tokens; Detailed adds the reasoning, trade-offs, and context behind each answer; Default balances the two. The choice persists across sessions, and typing @concise or @detailed in a message applies a style to that message only. Error reports, security warnings, and confirmations before destructive actions always arrive in full, whatever the style. See https://plexon.ai/features/chat/.

## Cross-Chat Messaging — The Open Chats Keep Each Other Informed

Session tabs make several conversations available at once, and until they can talk they all work blind: two chats edit the same files, repeat each other's research, and contradict each other's decisions. Cross-chat messaging is the correction. When work in one chat affects another it sends a short plain-text note naming the sender. A chat mid-task reads it between its own steps without losing its work; an idle chat picks it up right away. Both sides show the exchange, so nothing arrives invisibly.

A shared workspace board carries what every chat needs rather than one: decisions, claims, warnings and status, read at the start of each step. A claim names the files or the area it covers and is binding, so other chats leave those files alone and say so rather than silently queueing behind them. Claims release when the work is done, and on restart, so a crash cannot leave an area locked forever.

**Addressing a specific chat is explicit.** Typing `@chat:` in the message box lists the open chats with running or idle, the mode, and a one-line focus. It inserts by session id, so renaming a chat cannot redirect a message, and it never offers the current chat. It is distinct from `@session`, which pastes a past conversation into the prompt: one sends, the other quotes.

**The caps exist because two chats can otherwise talk forever.** Two hops, twenty messages per pair of chats, identical repeats inside five minutes dropped, and the budget resets whenever the user types in either chat. A runaway exchange is the obvious failure of a feature like this, so the limit is a fixed number rather than a heuristic.

**An arriving message is treated as another assistant, not as the user.** It cannot approve anything, answer a permission prompt, or change a setting or a mode, and its text is information rather than instruction. Waking a chat runs it in that chat's own mode, so a Plan-mode chat stays read-only, and a locked chat refuses the message at the point of sending. That boundary is what stops one conversation escalating its own privileges through another.

Three switches under Settings, Chats: whether chats message each other at all, whether an arriving message starts a turn in an idle chat, and whether the board is shared. Messages live in memory and the board is a single JSON file in the Plexon home folder, outside the repository, with nothing uploaded and no account involved. See https://plexon.ai/features/cross-chat-messaging/.

## Pinned Messages

Any message in a chat can be pinned, from the user or from the assistant. Hovering a message in the transcript reveals a pin control; a pinned message keeps its marker visible instead of hiding it until hover, and the control appears once a turn has finished rather than mid-stream. Clicking the pin again unpins, either from the chat or from the sidebar row.

The sessions sidebar gains a Pinned view that replaces the session list rather than filtering it, because pins are message-scoped instead of session-scoped. Each row shows who said it, when it was pinned, the first two lines of the message, and the session it came from, with an unpin control on the row. The sidebar search box filters pins by message text, session title, and project name. Clicking a pin loads its session and scrolls to that exact message with a brief highlight. Pins resolve against a stable per-message id rather than a position or a timestamp, so they survive a restart and a session that has grown since; sessions written before the id existed are given ids the next time they load.

The pin index is machine-global while chat sessions are stored per project, so pins default to the project currently open and an All projects toggle widens the list. A pin from another project carries a chip naming that project. Reaching that one means opening its project, since this window cannot read another project's chats at all. Each pin stores its own short copy of the message text, the session title, and the project name, which is what lets a row from a project this window cannot read render at all.

Storage is a single JSON file in the Plexon home folder. There is no account behind pins and nothing is uploaded, so nothing carries them to a second machine on its own; a transfer bundle does (see Move to Another Machine). A pin whose session was deleted greys out and reports that the session is no longer available rather than disappearing, and nothing prunes it automatically. Pins do not travel inside an exported .plexshare session, since an import mints a fresh session id. See https://plexon.ai/features/pinned-messages/.

## Drafts

A draft is a page, a markdown document, or a source file the AI builds for the user to keep. The AI writes the file and renders it as it always has; a draft id on that render is what makes it a draft. It opens in a pane docked beside the chat, in the same slot the embedded Browser uses, with every version the AI produced under that id. The version strip shows v1, v2, v3 and so on; the user flips back to an earlier version, and Compare with previous shows what changed between two. Open, Show in folder, Open in editor and Save as act on the version being shown. Edit with AI opens a COPY of the version in the embedded Browser, in the same chat, so the AI still has the conversation that produced the page. The user clicks an element and says what to change; when the turn lands the pane shows the result as a new version, and the version edited from is unchanged.

Asking for a few directions ("three looks for the hero") shows two to four candidates side by side in the chat, each a live preview with a label. A click selects, Use this one sends: the pick goes back to the AI as an ordinary message naming the label, and every later change is a new version of that draft. The other directions stay in the pane and stop changing. On Telegram and Slack the same set arrives as a numbered list and the reply is a number.

Storage is one folder per draft under the Plexon home folder, with a copy of every version, plus a small index file. Nothing is uploaded and nothing about a draft reaches the Plexon server; the server sees the same tool call it always saw. Drafts nobody has touched for 90 days are removed at startup (a setting changes the window or keeps them forever), and a draft whose chat is open is never removed. See https://plexon.ai/features/drafts/.

## Command Palette

A search box sits in the middle of the title bar, and Ctrl+K (Cmd+K on macOS) opens the same thing from anywhere, so a user who knows what a thing is called does not have to remember which panel owns it. The corpus spans skills, agents, tool servers and their individual tools, the built-in connector catalog, personas, plugins, marketplace items, workflows, dashboards, data sources, API connections, middleware, hooks, schedules, routines, chats, memory notes, plans, journal entries, pinned messages, roughly 220 catalogued settings, every sidebar panel, and the app commands.

Opened with nothing typed, it groups the most recent picks first, then commands, then panels, which makes Ctrl+K followed by Enter repeat the last thing the user did. Typing ranks the whole list: exact and prefix matches lead, initialisms work (dsm finds Data Sources Manager), separators collapse so skill creator finds anthropics-skill-creator, and the matched letters are picked out in the title and the description. A chip on every row names the kind. Arrow keys move, Enter runs the primary action, Ctrl+Enter runs the alternate one, and Escape closes. Prefixes narrow by family: > for commands, # for panels, : for settings, $ for the marketplace, and ~ for the user own chats, plans, notes and pins.

Connectors and tool servers rank ahead of everything else, because a typed product name nearly always means the integration rather than an agent or skill that mentions it. Connectors carry the brands they actually reach, so facebook and instagram both find Meta Ads even though neither word is in its name. Enter on a connector opens its install flow directly; Ctrl+Enter shows its marketplace card instead. The palette also acts rather than only navigating: switch chat mode or theme, register a marketplace URL, browse or install a connector, open what is new, or open spec-driven mode.

Settings are searchable by what they do instead of what they are called, because each one carries the words people reach for: make the text bigger finds the base font size, night mode finds the theme. Common phrasing is stripped from the query, so a sentence works as well as a keyword. Picking a setting opens its Settings tab, scrolls to the section that owns it, and outlines that section briefly so the user can see which control they asked for. The palette only ever navigates to a setting; nothing is changed without asking, and no current value is ever carried in the search list. Two destinations are reachable by words that appear on no label: every AI provider under the name its vendor uses, so openai, fireworks, gemini and openrouter each open the provider dropdown without switching the provider, and the Claude Code import, which claude, migration, migrate or import opens as the wizard that brings across memory, agents, tools, hooks, past sessions and plans.

Ordering learns from use. One exponentially decaying counter per result folds how often something is picked together with how recently, on a two-week half life, and it is capped so it reorders close calls without ever floating a weak match above a strong one. That counter stays on the machine that made it, with no account and no sync. A panel the user has hidden from the sidebar still appears, marked as hidden and ranked near the bottom, so a feature put away months ago is findable again; opening it from the palette lasts for that session only and does not rewrite the sidebar. Panels an administrator has locked never appear, and content belonging to a persona the user is not running stays out, exactly as it does in the panels themselves.

The searchable list is bounded metadata: names, titles, descriptions and tags. File contents and message bodies are never indexed. The / prefix reaches the words in the open conversation anyway, by handing the query to the same chat search bar Ctrl+F opens rather than building a second index; the Sessions search box searches across chats. When a query matches nothing, the palette offers those two things instead of an empty screen: search the open chat for what was typed, or send it to Plexon as a message, with Ctrl+Enter staging it in the chat box rather than sending. Prefixes narrow by family: > commands, # panels, @ agents, * skills, & tools and connections, : settings, $ marketplace, ~ the user's own chats, plans, notes and pins. Nothing in the list carries a skill body, an agent or persona prompt, a setting value, a credential, or a file path. Plexon hands the list to the window once and ranks it there, so every keystroke is a local scan rather than a request that has to come back, and the palette opens straight away on a cold start with panels, commands and settings while the rest fills in. See https://plexon.ai/features/command-palette/.

## Continuous Voice Conversation Mode

A hands-free voice loop built directly into the chat input. The user clicks the headset button, speaks, Whisper transcribes the turn locally, Plexon answers, the assistant's text is read aloud via the chosen TTS engine, and the microphone auto-resumes for the next turn — no clicking between turns. Voice activity detection ends each user turn the moment they pause; push-to-talk barge-in (Space by default, configurable) lets the user interrupt the assistant mid-reply and immediately take their next turn without breaking the loop. The mode is configured once in **Settings → Speech → Voice Mode** and runs across every chat mode (Code, Plan, Ask, Auto, Spec).

**TTS engines:**
- **Microsoft Edge TTS** — 400+ neural voices across 80+ languages, free, no API key. Default for most users.
- **Plexon Voice** — cloud voices served by the Plexon subscription (Premium plans), nothing to install, and it can clone the user's own voice from a ten-second recording. Cloned voices work everywhere Plexon Voice speaks, including persona voices.
- **My Voice** — local TTS with voice cloning. No network calls; ideal for offline or privacy-sensitive workflows.
- **OS-native voices** — system speech synthesis on Windows / macOS / Linux for users who prefer their installed voice packs.

**Voice assistant activation.** Opening voice mode runs a fast readiness check (microphone access, transcription model, voices) and walks the user through anything missing. Two opt-in triggers, both off by default: a system-wide keyboard shortcut that brings Plexon to the front and starts voice mode, and a wake phrase ("Hey Plexon") matched only while the window is focused — the microphone is released the moment the window goes to the background, so there is no always-on listening. Saying "Bye Plexon" ends the conversation without sending it as a message. Spoken app-control requests ("switch to the premium model", "turn on auto-read") are executed through the settings tools rather than answered with instructions.

**Speech-to-text** runs locally via Whisper (the same engine the existing voice input feature already uses). No cloud STT is required; only the transcript text leaves the machine, and only when it ships as part of the actual chat request to whichever AI provider the user has configured.

**Session metadata.** Every spoken turn is tagged in the session JSON with `input_modality: "voice"` and a `voice_meta` block containing the recording duration, the transcription model, and the detected language. This metadata round-trips through session export and is searchable from the sessions sidebar — voice conversations are first-class history, not a separate channel.

**Privacy.** The raw audio sidecar (the actual recorded WAV/Opus) is **opt-in and off by default**. With the default settings, Plexon stores only the transcript text plus the lightweight metadata block. Users who want a verbatim recording for their own archives can enable the audio sidecar in Settings; everyone else gets a privacy-aware default that keeps their drive clean and their recordings off disk.

**Interruption model.** The push-to-talk key (default Space, rebindable) cancels the in-flight TTS audio, captures the user's input, and feeds it into the next turn. There is no "raise your hand and wait" pattern — the user always has authority to take the floor, just like talking to a person.

## AutoDream Memory Consolidation

Plexon automatically organizes and prunes memory files in the background. After every 5 sessions and 24 hours (both configurable), a restricted AI agent reads all memory files, deduplicates entries, removes stale facts, resolves contradictions, converts relative dates to absolute, and keeps the MEMORY.md index under 200 lines. The consolidation agent is sandboxed to memory read/write plus one read-only tool over the staged feedback signals. A PID-based lock file prevents concurrent runs across multiple instances. There is no manual trigger; the gates are what start a run, and they are what you adjust under Settings, Advanced, Memory. A skeptic gate runs before every write: the agent must trace each change to an entry it actually read, so cleanup rearranges knowledge but never invents it. A specific claim with no source stays in its topic file marked unverified and is never promoted into the index. After a successful project consolidation, a slower weekly pass consolidates global memory too.

**Rules from your feedback.** Every assistant reply carries a thumbs up and a thumbs down. Thumbs down asks one question, what should have happened instead, and the sentence you type is saved as a rule in project memory before you send the next message. A bare thumbs with no explanation is filed as evidence rather than written up, because a click alone does not say what the rule is. Plexon separately stages the signals it can read on its own: a tool that failed, a build or test that failed, a message shaped like "no, not like that". Those need two occurrences of the same underlying problem before anything is written, and they are written by the consolidation run rather than on the spot, so that half arrives hours or days later. The staging log never enters a prompt; only the finished rule does.

A rule is a markdown note like any other, with a type of "feedback" and its frontmatter description holding the rule itself. It shows up in the knowledge graph, both as a node and in its Files list, and in the command palette, and you can reword the first line to change what Plexon does or delete the note to drop it. Because the auto-loaded index lists 40 notes by recency and a real corpus is well past that, 12 of those slots are reserved for rules, so a rule you gave three months ago is still in front of the model today. The reserved slots come out of the 40, not on top of it, so the prompt does not grow. See https://plexon.ai/features/autodream/.

## Knowledge Graph: Every Answer Names the Note It Came From

The memory notes are plain markdown, which is the right format to keep them in and the wrong format to search when a question spans four files with three spellings of one name. The knowledge graph is a derived index over those notes: which entities exist, how they relate, and the note and line every fact was read from. It turns "read the file about this client" into "what do we know about this client", answered across every note that mentions them, with a source on each line. The lookup is a graph walk plus a lexical rank, so it costs no tokens and touches no network.

**The markdown stays the only copy.** Nothing writes a fact the notes do not already state, because a fact that lives only in the graph is a fact that dies at the next rebuild. Extraction is a pure function of the files and the alias table, so two rebuilds of an unchanged set of notes produce byte-identical output, and a test in the repository proves it. Forget the graph loses nothing: the next question rebuilds it. The corollary is that there is no migration path for a fact. Anything that needs remembering writes markdown.

**Every fact carries provenance or it is not written.** A row names the file, the line, the date on the note, and whether the note stated it outright or something derived it from a link or a phrase. A triple with incomplete provenance is refused on write, and a graph file containing one is treated as tampered and rebuilt rather than served as though it were whole. Dates come from the note, never from a clock, because a clock read at extraction time would make two rebuilds of an unchanged corpus differ and take the whole argument down with it.

**Two names are proposed for merging, never merged.** The resolution ladder is exact match on the folded form, then the alias table of decisions a person already made, then a suggestion a person confirms. There is no fourth step. A wrong merge is silent and close to impossible to notice afterwards, so the proposal shows both sides with their name, their fact count, and the note each came from, and the answer is Same person or Different. Suggestions compare display names with honorifics set aside and never compare facts, because two people at one company are still two people. A short name that sits inside more than one longer name comes back flagged ambiguous, so accepting it reads as a real choice. The decisions live in their own file beside the graph and survive both a rebuild and a delete.

**Greek folds correctly, which is the case that actually comes up.** Canonical ids decompose the text and drop combining marks, so Ιωάννης and Ιωαννης are one person and final sigma does not fork Νίκος from Νίκοσ. Two different people who share a first name keep two entries, and the longest matching name wins so a full name is never shadowed by a partial one. Names are never slugified: stripping non-Latin characters would collapse every Greek name to the same empty id and make all of them one entity.

**A contradiction stays on screen.** A `supersedes` edge is a proposal, not a deletion. The older fact is still returned, struck through and labelled with what claims to replace it, and the user settles it. Facts inherited from a class arrive marked with the class named, and a fact the entity states about itself beats the class version outright, because "clients pay annually" and "this client pays annually" are different claims and folding them together loses the difference.

**Relations are plain markdown.** An `entity:` line in a note's frontmatter says who the note is about, so its facts attach to the person rather than to the file. A Relations block states the rest, one relation per line. Any `[[wikilink]]` anywhere in any note is already an edge, which is most of the connectivity for no authoring effort. Ordinary bullet lists stay prose: a loose grammar would turn every line in every note into a fact and the graph would stop meaning anything. AutoDream writes these during consolidation, so a person can write none of it and still get a graph.

**It reads the draft you are already typing.** The same graph resolves the arguments a message names while it is being written: a recipient, a date, a period, an amount, an email, a path, a quantity. The pass is deterministic, makes no model call, and takes its reference date as an input rather than reading a clock, so the same draft on the same day always resolves the same way. Greek and English relative phrases both resolve. It pre-fills and never executes, because a pre-filled form somebody confirms is help and an auto-executed guess is a support ticket.

**It is bounded, local, and deletable.** 20,000 facts, 4,000 entities, and 400 facts per source file per scope; a build that hits a cap records what it dropped and an answer from a capped graph says so instead of reading as complete. When nothing matches, the answer says the notes do not say rather than filling the gap. The graph and the merge decisions are two files inside the memory folder they derive from, so deleting that folder takes them with it, and nothing in either is ever attached to a request. The answer is a pure read of markdown already on disk with no network and no mutation, so it binds into dashboard widgets and workflow steps as well as chat. It is on by default; Settings, Advanced, Memory, "Connect my notes" turns it off, which drops the tool from the AI and quiets the panel while leaving the notes untouched. See https://plexon.ai/features/knowledge-graph/.

## Migrating from Claude Code

Switching assistants normally means building the setup a second time. Plexon ships a migration wizard that reads an existing Claude Code install where it already sits and brings the work across. Nothing under `~/.claude` is moved, edited, or deleted, so Claude Code keeps working exactly as it did.

There are two entry points. From Settings the wizard migrates the **global install** at `~/.claude`: custom agents, MCP servers, hooks, plans, `CLAUDE.md` and user-level rules, per-project memory, and the full conversation history. Opening a repository that Claude Code set up shows an **in-chat banner** offering that project's own `.claude` folder instead: agents, project skills, MCP servers, hooks, and slash commands, which have no Plexon equivalent and are converted into skills with mandatory trigger phrases (`deploy` and `/deploy` for a `commands/deploy.md`). The banner's answer is remembered per workspace, so Skip re-prompts next time and "Don't ask" is permanent, while Settings can always reopen the wizard.

The global wizard runs in four screens: scan, select, map projects to their local directories, import. Selection is component by component with live counts, and the Plans component opens into a per-plan list showing each plan's approval state, its project, its size, and its age, with a search box and three quick selects.

Plan attribution is the substantial part. An earlier version copied every plan into one global memory folder, which put a plan for one repository next to a plan for another and paid for all of them in the system prompt on every turn. Plexon now recovers which project each plan belongs to by reading the session that produced it: the session slug from the tail of the transcript, and the session's **first** recorded `cwd` from its head. Measured on a 2.6 GB corpus (335 transcripts, 255 plans), 255 of 255 plans were attributed with no ambiguities, at a cost of roughly 0.6% of the corpus read. Each plan is then written into that project's own plan store as a real record with its title, its original creation date, and its approved or draft status, rather than a raw file copy. A project folder the user has since deleted is still a valid destination. Plans that cannot be traced go to a single folder the user picks, and the results screen flags that row as untraced rather than pretending it was recovered.

Approving a plan in Claude Code writes a marker into the transcript, so the absence of that marker is the definition of a throwaway draft. An "All except ephemeral" button keeps the plans that were approved and drops the rest. When the transcripts are no longer on disk, sub-agent drafts are still identified by their `-agent-<hex>` filename suffix as the closest available fallback, and a plan belonging to a live session is never counted as a draft. The approval scan is cached against a stat-only fingerprint of the plan and transcript files, so re-opening the wizard costs about half a second instead of the seven to nine seconds of a cold pass.

Sessions resolve to the project they belong to. Each project keeps its own encrypted session store, and the import opens the correct store per mapping instead of filing a dozen repositories' conversations under whichever folder Plexon happened to start in. Imported sessions keep Claude Code's own session ids, so a second run skips what is already there instead of duplicating the list. A project folder that is not on this machine is reported as an error rather than guessed at. Claude Code's own slash-command bookkeeping (the local-command caveats, echoed commands, captured stdout) and sub-agent sidechains are filtered out, so imported conversations read as conversations.

Everything imported carries an `imported_by` provenance stamp, because one run can add hundreds of items. The Sessions sidebar badges each imported row with a "Claude Code" label, the Plans panel badges the card and adds a dedicated **Imported** filter beside All, Approved, and Drafts (shown only once something has been imported), and both panels search on the label, so typing "claude" pulls the whole import up as a group. Ctrl or Cmd+A selects the filtered list, which makes undoing a bulk import a filter, a select, and a delete.

Every importer is idempotent: agents, skills, MCP servers, and hooks skip on name; plans skip on a deterministic id derived from the source filename; sessions skip on Claude Code's own session id. Name collisions are suffixed rather than overwritten (a clashing skill becomes `name-claude`, a clashing project MCP server is suffixed with the workspace name). The results screen names every destination with a per-project count and a button that opens the folder, and every skip or failure carries the file and the reason behind it, so a count is never something the user has to go and investigate. See https://plexon.ai/features/claude-code-migration/.

## Move to Another Machine (Transfer Bundles)

Before this, reinstalling Plexon on a new computer meant starting from zero. Everything a user had built lived under the Plexon home folder plus a `.plexon` folder inside each project, and nothing moved it.

**How it runs.** Settings → Advanced → **Move to another machine** writes a single encrypted file. On the new computer, install Plexon and click **Bring my setup from another machine** on the sign-in screen. **Save a snapshot** is the same export framed as a backup, restorable later on this machine or another one; it is one of three cards inside that same **Move to another machine** section, next to **Create a transfer bundle** and **Restore from a bundle**. One wizard serves both: its title reads "Create a transfer bundle" for a transfer and "Save a snapshot" for a snapshot, and a snapshot ticks every row rather than leaving the nine excluded-by-default ones off and skips the "What stays" step, since nothing is being left behind. Building a bundle re-asks for the app PIN when one is configured, through a dedicated re-auth prompt rather than the boot gate's; that "Confirm it is you" step is absent entirely on a machine with no app lock.

**What travels by default.** Settings, custom AI providers, saved profiles, personas, the skills and agents the user wrote plus their edits to the built-in ones, plugins, marketplace subscriptions, API connections with their credentials and OAuth tokens, middlewares, connector state, workflows, dashboards, hooks, scheduled jobs, routines, data sources, watchlist, outreach, shopping, templates, memory, per-project memory and plans, journal, avatar portrait, cloned voice, notes, pinned messages, git credentials, sign-ins to AI providers, chats including locked ones, and per-project settings. Nine rows are offered but left unticked, each one being large, short-lived, or unusually sensitive: the `.env` file, connection cookies, browser profiles, workflow history, job notifications, routine history, the avatar recording, the app PIN, and saved agent results. A pristine built-in skill or agent crosses as a reference rather than as bytes, since the recipient's own install rebuilds it; a built-in item the user edited crosses as an override, re-applied after the new machine's seeders run, carrying the hash it diverged from. An item whose origin cannot be verified is carried and reported, never assumed pristine.

**Encryption.** The file is sealed under a passphrase the user chooses at export time and Plexon stores nowhere: not on disk, not in the file, not on a server. Minimum 12 characters; a four-digit passphrase is refused, and Plexon never offers to reuse the app PIN, because four digits is ten thousand combinations and no wall at all for a file on a memory stick where an attacker gets unlimited offline guesses. A recovery code is offered and defaults on, since a bundle is typically built weeks before it is used, often on a machine about to be wiped, and there is no server-side escrow to fall back on. The app PIN can travel as a toggle decided on the machine that still knows it; an imported verifier arrives with biometric unlock and the failure backoff cleared, because the biometric secret lives in the old machine's OS keystore.

**No cloud.** No Plexon server is involved in building, moving, or opening a bundle, and no account holds a copy. The file goes wherever the user puts it.

**Import is always a full replace.** There is no merge mode. Plexon reads the file, expands it into a staging directory inside the target home, proposes a mapping of the source project folders onto local ones (one row each, with its chat count and size, defaulting to the same absolute path when it exists), and shows what goes away as a folder count plus every one of those paths in full, beside the exact categories that arrive. The typed confirmation is not on that screen: the red **Replace this setup** button under it opens a second dialog whose own Replace stays disabled until the word `replace` is typed. Refusals come first: a file from a newer Plexon, not enough disk space, a failed header check. Cancelling deletes the staging directory and nothing else has moved. The setup being replaced is renamed into a restore point under the Plexon trash folder, which the existing week-long sweep collects. The restore point is made before anything is laid down, and an import that cannot make one aborts rather than half-wiping. A failure while wiping, laying down, or remapping paths rolls back automatically; after the post-import passes have re-cloned marketplaces or installed a tool there is no clean rollback left, so the run is marked degraded, boots on the restored tree, and offers a manual undo instead of half-undoing after third-party side effects.

**What never travels, and why.** Every one of these is reported twice from one shared structure: at export as "these will not come with you", at import as the result screen. The group needing sign-in or re-authorisation renders first and does not collapse, because it is what someone must read before wiping the machine they are leaving. Signing in (one credential is one seat, so carrying a live token would evict the machine being left). The WhatsApp pairing (the database holds the linked device's own keys; copying it does not move the session and can invalidate the one being left behind, so scan the QR again). Marketplace copies and marketplace keys (re-cloned from source and re-fetched after sign-in, so the user lands on the current version). Speech and avatar engines and tool binaries (several gigabytes, operating-system and architecture specific; the bundle carries name and version pairs instead and the existing self-heal reinstalls them). Caches, logs, and temp. Skips are aggregated rather than listed per item, so the report reads "42 built-in skills, 118 built-in agents (the app ships them)" instead of 160 rows.

**Cross-platform.** A bundle built on Windows imports on macOS or Linux. Absolute paths are handled two ways: command lines get their paths turned back into the placeholders the product already resolves at run time, and typed fields, activation map keys, and directory names are remapped through the workspace mapping by longest prefix match. Anything still absolute after both passes is kept and reported, never silently repointed, because a hook that runs a script from the old machine is better left visibly broken than quietly aimed at a different file. A scheduled job whose project folder did not travel arrives disabled. Paths are stored forward-slashed with the Windows volume as a separate field, entry names are NFC-normalised, and two source folders that are distinct on Linux but collide on Windows are handed to the user rather than merged. The new machine writes its own build record at the end of an import, so the next launch does not read the import as a build change and purge what it just laid down.

**One suffix, two kinds of file.** The same container carries either a single shared chat or a whole setup, and every entry point checks which before deciding anything. A dropped setup bundle never auto-runs (a dropped chat share does), the chat importer refuses a setup bundle rather than redirecting, and the two deeplinks are separate URLs, because a link whose meaning changes with its file's contents is a phishing primitive.

**Honest limit.** A bundle at rest discloses its shape: category names, counts, total size, the source hostname, and the creation date are readable without the passphrase, because the import screen has to describe the file before it can ask for one. Paths, filenames, connector names, and project folders are deliberately excluded, as is every byte of content. See https://plexon.ai/features/transfer-bundles/.

## Cloud Backup (Google Drive)

Transfer bundles cover the move the user planned; Cloud Backup covers the disaster nobody planned. The user connects their own Google Drive under Settings → Advanced → **Cloud backup**, and Plexon continuously backs up the machine's setup (settings, skills, agents, personas, connectors with the credentials they use, workflows, dashboards, memory, journal, notes, cloned voice) and every project's chats to a hidden Drive app folder only Plexon can reach. Every backup object is a transfer bundle, encrypted on the machine before upload, and only changed data uploads. Heavy machine-local things stay out: speech and avatar engines, browser profiles, the avatar recording, and caches. Enabling asks for the app PIN once when one is set; background cycles never prompt.

**Restore.** A fresh install restores from **Restore from Google Drive** on the sign-in screen, through the same mapping, typed-confirmation and restore-point rails as a transfer bundle import. Opening a folder whose chats are in the backup brings them back automatically when the folder is empty, or after a one-line offer when it is not; the merge is additive only and never deletes anything. Projects whose folders no longer exist anywhere are remembered, and "Restore to folder" merges them into a chosen directory.

**Two laptops.** Opening Plexon on a second machine pulls what the backup has that the machine lacks: memory, project memory and plans, notes, journal entries, and tasks arrive on their own, files changed more recently on that machine are kept, and nothing is ever deleted. When the backup holds newer versions of files that were also changed locally, Plexon asks first in one sentence, and replaced files go to the trash folder before anything is overwritten. Once the pull settles, that machine takes the backing-up seat automatically, so alternating between two laptops keeps both current. Settings also has a manual "Pull latest from backup" action. Deletes never travel between machines.

**Custody and limits.** One machine backs up at a time; a second machine that enables backup adopts the existing backup and takes the seat, parking the first behind an explicit takeover prompt. By default the Google sign-in is enough to restore, which means whoever controls the Google account can read the backup, connector credentials included; an optional backup passphrase (12+ characters, with a one-time recovery code) makes Google hold ciphertext only. The backup counts against the user's own Drive storage quota, and a full Drive pauses the backup rather than erroring on every cycle. Disconnecting can keep or delete the backup, and revoking Plexon's access in Google account settings deletes the hidden folder. See https://plexon.ai/features/cloud-backup/.

## Settings You Can Ask About

Plexon has around 240 settings across eight Settings tabs. Rather than making the user hunt for one, the assistant can explain and change them directly through the `plexon_settings` tool.

Behind it is a curated catalog in the daemon holding one entry per setting: what it does in plain language, its type, its default, its allowed values, which tab owns it, and whether it can be changed from chat. That catalog is the source of the assistant's answers, so it describes the build the user is running rather than a recollection of an older version. Reflection tests keep it honest: every catalogued key must resolve to a real config field of the declared type, and every field in the config must be either catalogued or explicitly excluded with a written reason, so a setting added to the app cannot silently become one the assistant has never heard of.

Changes are tiered by consequence. Ordinary settings (theme, text size, notification sounds, sub-agent limits) apply as soon as the user asks, and the reply links to the section that changed. Settings that widen access or cost money (file access set to allow-all, disabling system prompts, the spending limit, turning on the Telegram or Slack bot) stop and ask for confirmation first, and nothing changes until the user answers. Tightening a setting is never gated, because prompting someone for making the safer choice trains them to click through the prompt that matters.

Credentials are outside the boundary entirely. API keys, bot tokens, and the signed-in session cannot be read or written from chat, not even masked. The assistant refuses and links to the field so the user pastes the value themselves.

Asking for a reset opens the existing Soft Reset confirmation on the Advanced tab rather than resetting anything. There is one reset implementation and one confirmation dialog, and the decision stays with the user in the panel that owns it.

## Quality Harness

The Quality Harness is a quality layer for AI work sessions, built on harness-engineering practice. It targets the failures that show up most on faster models: guessing instead of verifying, shortcuts that fake completion, and losing the thread on long tasks. It lives in Settings under AI Providers as one control with three levels: Full, Light, and Off. It is Off by default for every provider and model, so nothing changes until the user turns it on.

At Full, the model works under a verified-work contract carried in its system prompt. For engineering personas (the Software Developer persona and the engineering-leaning default) that contract is code-specific: verify any API, config key, or path against the real source before using it; write a compact spec (goal, done-when, never-touch, stop-if) before multi-step work; debug by reproducing the failure and testing one hypothesis at a time, stopping after three misses; and before claiming done, run a hostile pass over its own work checking eleven fake-done shortcuts (relaxed tests, swallowed errors, fake renames, stub returns, comment-as-fix, happy-path-only, scope creep, invented APIs, silent decisions, pass-by-mock, and off-spec completions). Non-engineering personas (writer, dietitian, financial-analyst, and the rest) get a generalized version of the same discipline with no coding mechanics: verify facts against a source, plan multi-step work, do not present a guess or partial work as finished, and name the choices you make. Light carries a short verify-before-done reminder only. Seven quality skills load automatically and stay hidden from the skills panel (verify-adversarially, debug-systematically, spec-first, context-budget, tool-restraint, subagent-fanout, sourced-claims); Full loads all seven, Light loads the three core ones. Five coding-quality skills (security review, SQL and migrations, test hardening, git hygiene, trace and bisect) ship with the Software Developer persona. After any turn that changed files or ran commands, a hidden read-only verifier agent re-opens the files, checks the assistant's claims against what is actually there, and posts a pass, fail, or unverifiable verdict to the Inbox; read-only turns skip it. A mid-turn reminder nudges the model to re-run builds and tests before finishing. An @loop agent, mentioned in chat, runs one task to a verified end: it writes a spec on disk, works step by step, self-verifies each chunk, and reports honest status with evidence. All of it is off when the harness is off, and none of the harness skills, agents, or hooks clutter the Skills, Agents, or Hooks panels.

## Session Lock & App Lock

Two optional local security features. Neither sends anything to a Plexon server.

**Session lock.** Lock an individual chat with a passcode from the session menu ("Lock session"). Plexon generates a random 32-byte content key for that chat, encrypts the conversation with it (AES-256-GCM), and wraps the content key under a key derived from the passcode with argon2id (64 MiB, 3 passes, 4 threads). The sealed payload and wrapped key live in a sidecar record kept off the session object, so a wrapped key or salt can never ride along on a getSession call, a JSON export, or a .plexshare file. Nothing at rest reveals the passcode, and a wrong passcode fails the GCM tag rather than being compared against a stored verifier. The passcode is a 4-digit PIN, submitted the moment the fourth digit is typed.

**Biometric unlock.** Touch ID on macOS and Windows Hello on Windows can open the same chat. The Electron main process holds a random 32-byte secret in OS-backed storage (Keychain / DPAPI) and releases it only after a successful prompt; that secret wraps the same content key the passcode does, so either factor opens the chat. The passcode field is always present, because a biometric prompt can be cancelled, can fail to match, or can stop working after an OS update.

**What a locked chat does and does not do.** It stays in the sidebar with its name, message count, and a lock badge. Until it is unlocked for the current run: the chat view shows no messages, export and .plexshare are refused with "Unlock this session before exporting it" rather than writing an empty file, Live Share has no content to mirror, and a turn arriving from Telegram, Slack, or the scheduler is refused with "This session is locked. Unlock it in Plexon to continue the conversation." A "Lock now" menu item re-seals an unlocked chat without closing the app. Locking is refused while a turn is running: stop the turn first.

**App lock.** A separate gate that asks for a passcode, Touch ID, or Windows Hello before the desktop window becomes usable on launch (Settings, Security). It encrypts no user data: it stores a sentinel sealed under argon2id(passcode) as a verifier and nothing else. Failed attempts persist to disk with an escalating backoff capped at 5 minutes, so relaunching the app does not reset the wait. When the gate engages it drops every held content key, re-locking any session that was left open, so clearing the gate never hands the next person an already-open chat. The app lock is a gate against someone who walks up to an unlocked machine. It is not disk encryption, at-rest protection remains the operating system's full-disk encryption (FileVault / BitLocker), and Plexon claims no defence against an operating system that is already compromised.

**Idle auto-lock.** The app lock can re-engage after a stretch with no typing and no clicking, the way an operating-system screen lock does. The interval sits with the app lock switch in Settings (Account, Security): "Only at launch" is the default, or anywhere from 1 minute to 3 hours 30 minutes. Idle means nobody is at the keyboard, not that nothing is happening, so a long answer running on its own still ends in a locked screen. Activity is sampled from pointer, key, wheel, and touch events; mousemove is excluded on purpose, since a nudged desk would keep the timer alive forever. A wall-clock check runs alongside the timer, so a laptop closed for an hour comes back locked rather than resuming a timer that slept through it. Locking covers the screen and does not stop the work: a session that is mid-turn keeps its content key and finishes, and clearing the gate puts everything back where it was. Changing the interval is never plan-gated: it only makes an existing gate stricter or looser. The lock can also be engaged on demand: Ctrl+Shift+L (Cmd+Shift+L on macOS), a "Lock Plexon" tray item, or a button in Settings, and Plexon locks when the operating system locks or sleeps. The shortcut is local to Plexon rather than a system-wide hotkey, which would take the combination away from every other app while Plexon runs. All of these hold back the content keys of sessions that are mid-turn, so work in flight is never cut off.

**One PIN for both locks.** Clearing the app lock with the PIN also opens every session locked with that same PIN, so it is typed once at the gate instead of once more per chat. Sessions on a different PIN fail to unwrap and stay locked. Biometric unlock is the exception: Touch ID and Windows Hello open the app only, because the OS check returns a verdict and no PIN, and there is nothing to try against a session key. When setting a session lock, the dialog offers "Use my app PIN", which verifies the app PIN against its verifier and then reuses it for that session. The two are copies, not a link: changing one later leaves the other as it was.

**Plan gating.** Pro is required to CREATE protection: setting a session lock, enabling biometric unlock, and turning the app lock on. Unlocking, re-locking, changing a passcode, and removing a lock are never gated, so a lapsed plan can never strand someone outside their own chats. A forgotten session passcode cannot be recovered by anyone, including Plexon.

## Privacy-First Architecture

- **Zero-Knowledge Server**: The server is 100% stateless. It processes AI requests using 31 dynamically-assembled system prompt sections and immediately discards all data.
- **AES-256-GCM Encryption**: All local sessions and API keys are encrypted. API keys are auto-encrypted during JSON marshaling before any network transmission.
- **No Data Retention**: Zero storage, zero logging, zero retention. Server-side data breaches are architecturally impossible.
- **Local storage and online requests**: Plexon saves history and runs tools on your computer. When you use an online AI service, it receives the conversation, file content and tool results needed for the request. Our server keeps no copy of the request or reply.
- **Session Lock**: Lock one chat with a 4-digit PIN and its messages are encrypted with a key derived from it (argon2id, then AES-256-GCM). Touch ID on macOS and Windows Hello on Windows are a faster second way in. Nothing about the lock reaches a server, and a forgotten session PIN cannot be recovered by anyone, Plexon included. See the Session Lock & App Lock section above.
- **App Lock**: An optional gate that asks for a 4-digit PIN, Touch ID, or Windows Hello before the Plexon window becomes usable on launch. It can also re-engage anywhere from 1 minute to 3 hours 30 minutes with no typing or clicking; a chat that is mid-answer keeps running behind it. Clearing the gate with the PIN opens any chat locked with that same PIN (a biometric unlock does not, since it returns no PIN to match). It is a gate against someone at your computer, not disk encryption: at-rest protection is still FileVault or BitLocker.
- **OAuth2 PKCE**: Supported for Anthropic and MCP tool authentication. Enterprise SSO integration available.

## Technical Architecture

- **Backend**: High-performance Go background process with 70+ RPC methods
- **Frontend**: Electron 43.x + React 19.x + MUI + Zustand 5.x + Webpack 5.104.x
- **Communication**: JSON-RPC 2.0 over SSE (Server-Sent Events) streaming
- **File Operations**: 30 concurrent workers with git-blob checkpoint backups (5-10ms)
- **Prompt System**: 31 dynamically-assembled system prompt sections per request
- **Cost Optimization**: Up to 90% cost reduction via prompt caching

## Supported AI Providers

Plexon supports 11 AI providers:
1. **Plexon**: the managed provider, one subscription with text, image, video, speech, and music models included
2. **Anthropic**: Claude Opus 5, Sonnet 5, Fable 5, Haiku 4.5 (with adaptive thinking support)
3. **OpenAI**: GPT-5.6, GPT-5.5 Pro, Codex (with reasoning effort levels)
4. **Google Gemini**: 3.7/3.6/3.5 Flash, 3.1 Pro, Nano Banana 2 Pro image generation (with thinking budget control)
5. **Fireworks AI**: open-weight models, up to 1M context
6. **OpenRouter**: 300+ models
7. **Claude Desktop**: MCP integration

Four further providers cover text, image, video, speech and music models on your
own key. The current list is in Settings, AI Providers, which refreshes from the
cloud catalog, so read it there rather than from this page.

Bring your own API keys for everything except the managed Plexon provider. Separate providers can be configured for execution and planning modes.

## Custom Providers

Beyond the built-in list, Premium subscribers can connect Plexon to **any OpenAI-compatible or Anthropic-compatible endpoint**. This unlocks:

- **Local LLMs**: Ollama (default port 11434), LM Studio (1234), vLLM (8000). Every token stays on the user's machine — ideal for regulated code, offline work, or air-gapped environments.
- **Corporate / enterprise gateways**: Azure OpenAI deployments, self-hosted Anthropic-compat proxies, and internal AI gateways with custom headers for tenant IDs and compliance tokens.
- **Alternative Anthropic-compat backends**: third-party `/anthropic` endpoints, authenticated via standard API key or bearer-token headers.

Each model in a custom provider declares its own wire format (OpenAI Chat Completions or Anthropic Messages) and capability flags (streaming, vision, reasoning/extended thinking). The UI only surfaces controls for capabilities the model actually supports. Features include:

- **Test Connection**: live round-trip against the endpoint before saving, with clear error messages for auth failures and missing paths
- **Fetch Models**: auto-populate the model catalog from the endpoint's `/models` list
- **Clone from Built-in**: start from Anthropic, OpenAI, or another preset and edit
- **JSON Import / Export**: share vetted gateway configs across a team; secrets stay local and are never included in exports

Custom Providers are **not included in the Pro plan**.

## API Connections (HTTP API Tooling)

Plexon turns any HTTP API into AI-callable tools without writing a plugin. The "API Connections" sidebar panel manages user-defined integrations end-to-end: base URL, auth, endpoints, secrets, and the per-host outbound allowlist. Each endpoint registers as its own MCP tool the AI invokes the same way it invokes the bundled tools.

**Two surfaces for the AI:**
- `plexon_http_request` — generic ad-hoc tool the AI calls from any prompt ("POST this to my webhook", "fetch this JSON")
- `plexon_http_<connection>__<endpoint>` — typed per-endpoint tool with full JSON Schema for inputs, derived automatically from each saved Connection

**OpenAPI 3.x import.** Drop a Stripe, GitHub, Notion, or any OpenAPI spec (JSON or YAML) into the panel header and Plexon materializes every operation as a derived tool. `operationId` becomes the tool name, `summary` + `description` flow into the tool description, path/query/header parameters land typed with the right required flags, and request body JSON Schemas — including `oneOf` and `anyOf` — round-trip into the tool's input schema. The persisted spec under `~/.plexon/connections/<id>/openapi.json` survives a re-import cleanly so manual edits aren't lost.

**Postman collection import.** Export a Postman Collection (v2.1.0) and drop it into the same panel header. A wizard reads the collection up front — base URL, variables, secret tokens, folder tree — then materializes every request as a derived tool. Collection `{{variables}}` become per-connection variables (plain values in `connection.json`, secret values in the credstore); the base URL is lifted out of `{{base_url}}` and stays editable. Folder-scoped auth (the common pattern of three bearer tokens by folder) flattens into a per-endpoint `Authorization` header backed by a secret variable, injected at call time. Big collections (the reference test imports 454 requests) default their endpoint tools to deferred so they load on demand via tool search instead of flooding the model. Re-importing the same file matches on the collection `_postman_id` and updates the connection in place, preserving the secrets you entered; the persisted collection lives at `~/.plexon/connections/<id>/postman.json`. The import surfaces what doesn't carry over: pre-request/test scripts (login token-capture flows are listed so you set the token by hand), file uploads, OAuth blocks, and stray-host requests.

**Connection variables.** Reference `{{name}}` in any URL, path, header, or query value and the daemon resolves it at call time from the connection's own variable set — plain values inline, secret values from the encrypted credstore (`httpconn-<id>-var_<name>`). A request that resolves a secret variable skips the response cache. Edit them by hand in the connection editor's Variables section, or let a Postman import seed them. A third placeholder form alongside the `{func()}` built-ins and the `{{user.email}}` identity tokens.

**Four authentication methods, all local:**
- **API key** in header or query (configurable field name)
- **Bearer token**
- **Basic auth** (username + password)
- **OAuth 2.0** with PKCE — shared callback server on `localhost:8089` handles concurrent flows across MCP servers and Connections; per-connection encrypted token storage with automatic refresh on 401 and a single retry

Static secrets land in the platform credstore (AES-256-GCM at rest) keyed `httpconn_<id>_<kind>`. OAuth tokens use the same encrypted-store path. Secrets never cross the IPC bus to the renderer — the daemon strips every secret-bearing field before returning the `SanitizedConnection` shape used by the UI.

**SSRF defense in depth.** Every outbound call from this feature passes through a single chokepoint:
- Scheme allowlist: `http` and `https` only; embedded credentials in URLs (`user:pass@host`) rejected
- Hostname rejection: `localhost`, single-label hostnames, `*.local`, `*.internal`, `*.lan`
- Post-DNS CIDR blocklist: loopback, link-local, multicast, RFC1918 private, CGNAT (`100.64.0.0/10`), `169.254.0.0/16` (covers AWS IMDS `169.254.169.254`), `192.0.0.0/24`, ORCHID, doc ranges, IPv6 specials (`::1`, `fd00:ec2::254`, `2002::/16` Teredo, `2001::/32`, `fec0::/10`, NAT64), and IPv4-mapped IPv6 (`::ffff:0:0/96` — collapsed to v4 and re-checked)
- DNS pinning: the dialer locks to the validated IP so a DNS rebind can't redirect mid-request
- Cross-host redirects refused outright

**Per-host approval flow.** First call to a fresh host triggers an in-chat prompt: *Allow once*, *Allow always for this host*, or *Deny*. Write methods (POST/PUT/PATCH/DELETE) on a previously-allowed host fire a second preview prompt showing method, path, and 1 KB body sample unless the user opts into writes for that host. Per-session allow-once cache prevents accidental cross-session reuse. Allowlist persisted at `~/.plexon/connections/allowlist.json` (plain JSON — hostnames are not secrets).

**Dynamic placeholders.** Templated paths like `/api/users/{user_id}/get_info?date={now_iso8601()}` stay AI-fillable for the named parameters and auto-resolved for the function-style ones. Built-in functions:
- `{now_iso8601()}` — current UTC time in RFC 3339
- `{uuid()}` — RFC 4122 v4 UUID
- `{hex(N)}` — N random hex bytes (e.g. nonces)
- `{rand_int(a, b)}` — uniform random integer in `[a, b]`

Path tokens like `{user_id}` are auto-extracted on path-field blur and seeded into the endpoint's path-params list as required. The AI fills these from the prompt or asks the user when missing and required.

**Visual body schema editor with dual tabs:**
- *Simple* tab: a flat list of `[name | type | required | description | enum]` rows covering all seven JSON Schema types (string with `format` hints like `date`, `date-time`, `email`, `uri`, `uuid`, `password`; integer; number; boolean; array with item-type picker; object placeholder; null). Auto-compiles to a valid `{type:"object", properties:{...}, required:[...]}` schema.
- *Schema* tab: monospace JSON editor with on-blur parse/validation, pretty-print button, and a *Load from file* button that accepts a bare JSON Schema **or** an OpenAPI `requestBody` fragment (Stripe/GitHub/Notion docs all serve schemas in this form). Long example placeholder shows every common option; a "Learn JSON Schema" link opens the official spec.

The two tabs round-trip cleanly when the shape is flat-of-primitives; non-simple schemas (nested objects, arrays-of-objects, combinators) lock the Simple tab read-only so the user can't accidentally lose structure.

**AI-enhance descriptions.** A sparkle button next to the connection-level description and every endpoint description rewrites the text via the planning provider. The polished version is what the AI sees at tool-selection time, so better descriptions mean fewer wrong-tool picks. Min input length 10 characters; stale-response guard cancels the spinner immediately on Stop without orphaning the underlying RPC.

**Per-endpoint test runner.** Every endpoint card has a Run button that opens a typed test dialog. Required-field red highlights fire before the request leaves the dialog; path tokens substitute client-side; body fields coerce to the right primitive; the response panel returns status, size, duration, pinned IP, inline body up to 4 KB, and a file path under `~/.plexon/http-responses/<uuid>.{json,bin}` for spills above the inline cap. The AI uses `plexon_read_file` on that path to finish reading large responses without re-fetching.

**Sub-agents** can call `plexon_http_request` and derived tools too. Mid-execution approval prompts route through the orchestrator using the same callback channel as existing `plexon_ask_followup_question` flows.

See https://plexon.ai/features/api-connections/ for the full feature page.

## Skills System

Skills are reusable instructions (coding standards, workflows, domain knowledge) that persist across sessions:
- **150+ bundled skills** across the included library and plugins. Skills are included across the library and bundled plugins. Some work in the background. Availability depends on your computer, AI service and enabled plugins.
- **Custom skills**: Markdown files stored in .plexon/skills/
- **Anthropic native skills**: Support rich formats (xlsx, docx, pdf) executed server-side
- **Open skill format**: Compatible with other AI assistants — bring your existing skills with you
- **Git-sharable**: Version control skills for team sharing
- **AI-authored from chat**: A dedicated `plexon_skill` MCP tool gives the chat full CRUD over the user's global skills (`~/.plexon/skills/<name>/SKILL.md`). Ask "Create a skill called pr-summary that helps me write good PR descriptions" and the model writes a validated SKILL.md with frontmatter, tags, and body -- same name regex, mode whitelist, encryption, and registry refresh as the existing UI dialog. One permission prompt per write with full params preview. Bundled and plugin-installed skills stay read-only; the daemon refuses mutations and the AI offers to fork under a new name. Available from any mode (Code, Plan, Ask, Auto) and any provider. Sub-agents cannot mutate global skills (the tool is excluded from sub-agent contexts). The hidden `plexon-author` companion skill auto-loads alongside the tool with the schema, third-person description style guide, "what + when" trigger phrasing, and worked examples for both single-file and directory-based skill shapes.
- **Self-describing report templates, in one file**: A skill's page template (rendered via the `plexon_write_file` `render_template` operation) carries its whole contract inline at the top of the `.tpl` as frontmatter — an HTML comment wrapping `---` YAML, so the file still opens as plain HTML and there is no separate JSON+YAML+`.tpl` trio to maintain (a `<name>.contract.yaml` sidecar still works for non-HTML templates or authors who prefer it). The contract declares variables, types, allowed values, a complete sample, and any source bindings. A `mode:` knob picks the strictness: `free` (the default) treats the contract as a guide and lets the model fill keys you did not document; `strict` makes it authoritative, turning unknown keys, type mismatches, and undocumented required keys into hard failures. The AI asks a template what it needs with `operation: describe_template`, previews it with auto-filled values via `operation: preview_template` (it uses the contract sample, or synthesizes values from the schema, and shows the page before you have real data), and checks a specific payload with `dry_run`. Source bindings let the template compute its own values straight from a raw API or tool result (drop header rows, join two arrays by a key, split ranges like `121-131`, read percentages and units), so the model passes `source_path` instead of hand-copying dozens of numbers. Missing required variables fail before rendering with every problem listed at once and a sample payload embedded, so the model fixes the call in one retry; optional sections auto-fill with nil so plain `{{if .key}}` works. A bundled Template Authoring skill teaches the whole flow with a working example. Every skill install lints its templates (parse, contract drift, sample render, binding vocabulary) and refuses a broken one with the exact authoring error; rendered pages are parsed for the JavaScript syntax errors that render a page blank; and encrypted skills can ship templates because the render path decrypts them transparently.

### Self-Improving Skills

Save useful instructions from completed work and review your own skill library in Plexon AI. Opt in to session review, choose which skills the library curator reviews, and inspect past runs.

Self-improvement is off until enabled. Session review can propose skill changes after completed work. Run Curator starts a review of the user-authored library; automatic interval scheduling is not available yet. The library curator skips pinned, bundled and plugin-installed skills. Pinning protects a skill's instructions and supporting files from AI edits and deletion, including session review. It also prevents inactivity archiving. Pinned skills remain usable, and the user can edit them directly in Skills or unpin them to allow AI changes. Curator history shows previous runs, their status, duration and skill-count changes. Reviews handled by an online AI service send that service the relevant content.

## Hooks & Automation

The hooks system fires on seven lifecycle events, with four executor types:

**Events:**
- `pre_tool_use` — before any MCP tool runs; can rewrite arguments or block execution
- `post_tool_use` — after every tool call; can append additionalContext the model reads with the result
- `post_tool_use_failure` — only when a tool returns IsError=true; useful for alerting and verifier sub-agents
- `user_prompt_expansion` — after @file/@symbol/@agent rewriting and before the model sees the prompt; hooks may rewrite the final text
- `config_change` — after every settings/provider/MCP/hook config write
- `pre_compact` — just before context-window compaction (auto or manual `/condense`)
- `post_session` — once after the assistant finishes a reply; matchers regex the final reply text, and an agent hook here runs autonomously with its summary landing in the Workflows panel's Runs tab

**Executor types:**
- `command` — spawns a shell command with the event payload as JSON on stdin (exit code 2 blocks for `pre_tool_use`)
- `http` — sends a JSON POST/PUT/PATCH; response `{decision: "block"}` blocks for `pre_tool_use`
- `agent` — dispatches the event to a Plexon sub-agent (e.g. `code-reviewer`) with the payload as a seed prompt; non-blocking
- `workflow` — starts a Dynamic Workflow with the event payload as its trigger; returns as soon as the run begins, non-blocking, and the same pairing works from the other side, where a workflow can carry a Plexon event as its own trigger

Hooks support regex tool matchers for targeted automation, global or per-project scope, optional Claude Code import (round-trips `prompt` and `agent` types), and live reload when settings change. Two pipelines under the hood: `ToolHookPipeline` carries gates with modify/block semantics; `LifecycleHookPipeline` carries observers that can never wedge the agent. Authoring is guided for non-programmers: a Create with AI button hands the request to the assistant (which writes the script file and registers the hook via `plexon_hook`), starter templates cover all seven events, and the hook builder shows the exact payload and output contract for the selected event and type.

**Persona-owned hooks:** a persona can bundle hooks the same way it bundles skills and agents (marketplace item kind `hook`). The persona's hooks activate only while that persona is active, with fields (folders, formats, thresholds) configured once at install using author-supplied defaults, and stay editable later from the Hooks panel. A `post_session` hook can also gate on a matcher: a phrase or pattern checked against the assistant's final reply, so the hook fires once when the conversation reaches a specific closing state instead of after every turn. A new `plexon_read_session` tool lets a hook-spawned agent read back the full transcript of the session that triggered it, which is what a post-session note-taker or summarizer agent needs to work from the actual conversation.

See https://plexon.ai/features/richer-hooks/ for full details.

## Platform Support

| Platform | Architectures |
|---|---|
| Windows | x64, ARM64 |
| macOS | Intel (x64), Apple Silicon (ARM64) |
| Linux | x64, ARM64 |

System requirements: 4 GB RAM, 500 MB disk space.

## Pricing

| Plan | Price | Key Features |
|---|---|---|
| Pro | $39/month or $105 every 3 months | Full AI access, priority processing, 192 built-in agents, 150+ skills, AI commit messages, prompt enhancement, browser and desktop automation, voice I/O, 2,000 messages every 5 hours, 10 images a day, personas of your own, building and publishing a marketplace, session lock and app lock (encrypt a chat behind a passcode, Touch ID, or Windows Hello) |
| Premium | $110/month or $297 every 3 months | Everything in Pro plus Custom Providers (any OpenAI- or Anthropic-compatible endpoint: Ollama, LM Studio, vLLM, Azure OpenAI, self-hosted gateways), Claude Code Desktop integration, priority-tier Plexon Provider keys, 4,500 messages every 5 hours, 50 images a day, 10 videos a day, 30 songs a day, Plexon Voice and voice cloning, shared team boards, Live Share |

All tiers maintain zero-knowledge architecture.

## Frequently Asked Questions

**Q: How is Plexon different from GitHub Copilot or Cursor?**
A: Plexon offers 5 specialized AI modes (vs 1), 192 built-in agents for writing, research, coding and other work, built-in browser and desktop automation, AI commit messages, prompt enhancement, prompt suggestions, AutoDream memory consolidation, parallel sub-agent orchestration, persistent team coordination, MCP resource browsing, a dual skills system, hooks automation, voice I/O, Telegram bot, and a 100% stateless server. Your code never leaves your machine.

**Q: Does your server store my code?**
A: No. Our server is 100% stateless. It processes your AI request using 31 dynamically-assembled system prompt sections and immediately discards all data. Zero storage, zero logging, zero retention. API keys are AES-256-GCM encrypted in transit and never persisted.

**Q: What LLM models does it support?**
A: Plexon supports 11 providers, including the managed Plexon provider, Anthropic (Claude Opus 5, Sonnet 5, Fable 5), OpenAI (GPT-5.6, GPT-5.5 Pro, Codex), Google Gemini (3.7 Flash, 3.1 Pro, Nano Banana 2 Pro), Fireworks AI, OpenRouter (300+ models), and Claude Desktop. The full list with current model names is in Settings, AI Providers, which refreshes from the cloud catalog. You can configure separate providers for execution and planning modes.

**Q: How does Orchestrator mode work?**
A: Your task is decomposed into 2-5 subtasks by the AI. Up to 3 sub-agents execute in parallel, each with its own session and cost tracking. Results are synthesized by the planning provider into a coherent response. Complex tasks complete in ~45 seconds vs 2+ minutes sequential.

**Q: Can I lock a single chat so nobody else can read it?**
A: Yes, on the Pro plan. Lock a chat with a passcode and its messages are encrypted with a key derived from that passcode, so nothing reads them without it. Open it again with the passcode, with Touch ID on macOS, or with Windows Hello on Windows. A locked chat still shows in the sidebar by name with a lock badge, and stays out of exports and live shares until you unlock it. A separate app lock asks for a passcode before the window becomes usable on launch: that one is a gate against someone at your desk, not disk encryption. Both are local, nothing about them reaches a server, and a forgotten session passcode cannot be reset by anyone. Unlocking, changing a passcode, and removing a lock work on any plan, so a downgrade never locks you out of your own chats.

**Q: What platforms are supported?**
A: Windows (x64, ARM64), macOS (Intel, Apple Silicon), and Linux (x64, ARM64). The Electron desktop app is built and distributed for all platforms with auto-update support.

**Q: Can I run the Plexon server myself?**
A: No. The server is operated by Plexon. It is stateless: it keeps nothing between one request and the next, so there is no store of your data on it to reach in the first place.

**Q: Is Plexon AI only for developers?**
A: No. Plexon includes 192 built-in specialist agents for tasks such as editing a chapter, researching a market, planning a campaign and checking code. Its 12 built-in roles include Writer, Designer, Marketer, Dietitian and Financial Analyst.

**Q: How does browser automation work?**
A: Plexon AI controls browsers via Playwright MCP -- navigate, click, type, scroll, and screenshot. You can use your real Chrome profiles with logged-in sessions. The AI always asks for your permission before navigating to new URLs.

**Q: Can I use Plexon from my phone?**
A: Yes. The Telegram bot lets you chat with Plexon from your phone: send text, photos, documents, and voice notes, get formatted replies and files back, manage sessions, transcribe voice notes and hear spoken replies, and have your workflows message you. Voice needs no API key: notes are transcribed on your own machine and replies use the same voices as the app. Access locks to your numeric Telegram user ID, so only you can use the bot.

**Q: Does it work with my existing AI-coding-assistant skills?**
A: Yes. Plexon uses an open skill format that other AI assistants share. Copy your existing skills into Plexon and they work immediately.

## Machine-Readable Indexes

- **https://plexon.ai/feature-media.json** — one record per feature page: slug, title, one-line summary, page URL, and every walkthrough clip on it with its .mp4 and .jpg poster URL, runtime, caption, and the steps that clip goes through in order. Every feature is listed, including the ones with no clip, whose `clips` array is empty. This is the source the Plexon desktop app reads so the assistant can link a feature page and play its clip in the chat, and it is the readable form of the recordings for anything that cannot watch them.
- **https://plexon.ai/evaluate/** — the method for comparing Plexon with another product, the per-feature distinctive index with its sources and dates, and where Plexon is not the right answer. Generated from the same data the feature pages render.
- **https://plexon.ai/search-index.json** — the site search corpus, one record per indexable page.

## Company

Plexon AI is built by Hellenic Development, an intelligence company building foundational software for builders, creators, and teams. Founded by Gerasimos Maropoulos, creator of the Iris Go web framework (25,000+ GitHub stars).

Products by Hellenic Development:
- **Plexon AI**: Private multi-domain desktop AI with a unified marketplace for skills, agents, plugins, personas, and MCP servers
- **Iris**: The fastest Go web framework (github.com/kataras/iris)
- **Hellenic Identity**: IAM & access management

## Contact

- Email: contact@plexon.ai
- Security reports: contact@hellenic.dev
- Community: Slack at hellenicdevelopment.slack.com
- GitHub: github.com/hellenic-development
- Twitter/X: @MakisMaropoulos