feat(providers): add Oh My Pi Early Access support

.agents/references/contributing.md

@@ -0,0 +1,64 @@
+# Contribution and records
+
+Read when preparing a commit/PR or updating the durable fact index. Paths below are repository-relative.
+
+## Landing changes
+
+Every change lands the same way, and you do not need to be asked each time. Do
+not commit directly to `pylon`, and do not fast-forward a task branch onto it.
+
+1. **Branch from the latest `pylon`.** `git fetch origin pylon`, then branch
+   from `origin/pylon` — never from a stale local ref, which may sit well
+   behind. Name the branch for the work: `fix/<topic>`, `feat/<topic>`,
+   `docs/<topic>`, or `upstream/<yyyy-mm-dd>-<topic>` for adopted upstream work.
+2. **Build and verify on the branch**, per `AGENTS.md` validation guidance.
+3. **Open a PR against `pylon`.** Push the branch and open it. This workflow is
+   the standing ask, so opening one needs no separate request.
+4. **Merge once checks are green and the developer approves.** Delete the branch
+   afterwards.
+
+`pylon` only ever moves by merging a PR. If you are about to run
+`git push origin pylon`, stop — closing that path is the point of this section.
+
+A branch checked out in a worktree is pinned there and cannot advance elsewhere,
+so keep `pylon` checked out in the main repository and give worktrees their own
+task branches. A worktree left sitting on `pylon` silently holds the branch back
+while work lands from elsewhere.
+
+## Pull requests
+
+- Conventional commit titles, plain language: `fix(web): new threads no longer spike CPU`.
+- Body: the problem in a sentence or two, then how you fixed it. End with the model and harness that did the work.
+- **Rebase onto the latest `pylon` branch before opening.** Stale branches conflict and burn a review round. Never rebase a Pylon branch directly onto a T3 remote.
+- UI changes need before/after images. Motion or timing needs a short video.
+- Upload PR evidence to GitHub. Never commit PR-only screenshots or assets such as `.github/pr-assets/`.
+- One concern per PR. An upstream dependency chain or closely related changes to one subsystem can be one concern, with a combined diff and verification. Split independent product decisions or unrelated high-risk changes; do not impose a source-commit quota.
+- When babysitting: poll checks and comments newer than the last push, verify each bot finding against the source, fix real ones, dismiss false positives with a written reason. Stay quiet when nothing is new. Stop when the bots are green on the latest commit.
+
+## Documentation
+
+Most code changes do not need an internal documentation change. Agents can read the code.
+
+- `docs/internals/` is for architectural decisions and their reasons, constraints that span components, and implementation traps that are hard to discover from the source. Before adding a paragraph, ask what a maintainer would get wrong without it. If reading the relevant code answers the question, leave it out.
+- Do not document every feature, enumerate fields or methods, narrate control flow, maintain file catalogs, or append PR summaries. Types, tests, and code already record the implementation. The glossary in `docs/internals/glossary.md` defines shared vocabulary; it is not a feature index.
+- Keep a local implementation explanation in a nearby code comment. Use an internal doc when the reasoning crosses boundaries or needs context the code cannot carry well. Link to the relevant source instead of copying it.
+- When a documented decision or constraint changes, rewrite or remove the affected text. Do not append another account of the new behavior. A new internal page needs a distinct, durable reason to exist.
+- `docs/user/` helps users accomplish tasks. Give each major feature a concise section explaining what it does, how to start, and anything unintuitive. A settings path is useful; descriptions of visible buttons, icons, layouts, animations, or every UI state are not. Before adding text, ask what task or decision it helps the user with.
+- Keep user docs in the shipped product's voice, without implementation details, source paths, or contributor tooling. Update the relevant feature section when how to use it changes. A UI tweak does not need a documentation entry, and a new control does not need its own page.
+- `docs/operations/` holds maintainer setup, release, and debugging procedures. Keep instructions for operating an installed Pylon server in the user guides.
+
+## Plans and work artifacts
+
+- Do not commit implementation plans, research notes, or agent scratch files. Keep temporary working material outside the worktree. `.plans/` is gitignored only as a safety net for legacy tooling.
+- Track active maintainer work in the GitHub issue or project item that owns it. External proposals follow `CONTRIBUTING.md` and belong in Ideas discussions.
+- Put durable architecture, constraints, and decisions in `docs/internals/`. Update those docs when the product changes so agents find current facts instead of abandoned intentions.
+- A merged PR is the implementation record. Close or update its tracking item when the work lands; do not preserve a second checklist in the repository.
+
+## Durable project facts
+
+`.agents/durable-facts.jsonl` is the append-only fact log for coding agents. It is an index of stable project knowledge, not a replacement for canonical code and documentation.
+
+- Never edit, delete, or reorder an existing line. Append new records at the end of the file.
+- Each line is one JSON object with a unique `id`, UTC `recorded_at`, focused `scope`, concise current `fact`, full `source_commits`, repository-relative `source_paths` verified at the current head, and a `supersedes` array.
+- Record non-obvious, durable product behavior, architecture, compatibility boundaries, and maintainer constraints. Do not record plans, task status, debugging chronology, guesses, or short-lived implementation details.
+- When a fact changes, update its canonical code or documentation and append a complete replacement whose `supersedes` array names the old record IDs. Readers must prefer the replacement; history stays intact.

.agents/references/local-development.md

@@ -0,0 +1,32 @@
+# Local development
+
+Read when starting a dev environment, pairing a client, or preparing fixtures.
+
+## Dev servers
+
+- `vp i` installs. Worktrees get this from the compatibility-named `t3.json` setup script; if module resolution looks broken, it probably did not run.
+- `vp run dev` starts server and web. In a worktree, state defaults to that worktree's gitignored `.t3`, which deliberately outranks an ambient `T3CODE_HOME` so you cannot land on shared state by accident. An explicit `--home-dir` still wins.
+- Ports derive from the worktree path and are stable across restarts, but read the real ones from the `[dev-runner]` line since occupied ports shift.
+- `vp run dev` needs a TTY. Launched from a plain non-interactive background shell it prints its first two lines and exits 0 without ever binding a port, which reads exactly like a fast successful start. Run it under `script -q /dev/null …` or `nohup … &` (there is no `setsid` on macOS), then confirm the port is actually listening before you trust it.
+- Sharing over the tailnet is three steps: run `vp run dev --share` in the background, wait for the `pairingUrl:` line in its output, then hand that full URL to the user with its pairing token intact. Do not wire up `tailscale serve` by hand for this, and do not open the complete pairing URL yourself.
+- The web app requires pairing. For an explicit human handoff, provide the pairing URL rather than the bare origin — a URL without its token is useless to whoever you gave it to. Treat the token as a secret everywhere else: never commit it, capture it in screenshots, or reuse it. If a token got consumed, mint a fresh one with `node apps/server/src/bin.ts pair`; it carries standard scopes, while the startup URL carries admin scopes (needed for Settings → Connections management).
+- Stop what you started, by the PID you tracked. See the process-ownership boundary in `AGENTS.md`.
+
+## Test data
+
+Use populated fixtures when the affected flow needs them. For an authorized snapshot of existing Pylon data, copy into isolated worktree state:
+
+- Copy from **`~/.pylon-code/userdata`** — Pylon's own runtime home, and the only realistic fixture that matches this repo's schema. Worktree state still lives at `<worktree>/.t3/userdata`, which is a compatibility-named path, not a second source of data.
+- **Do not seed from `~/.t3/userdata`.** Despite the compatibility-named path, that is T3 Code's database, and it carries upstream's migration numbering. Pylon renumbered 037–040 (`ProjectionThreadsPinned`, `ProjectionThreadsContinuedFrom`, `ProjectionTurnsKeysetIndex`, `ProjectionThreadsPinOrderKey`) and retired id 36, so a Pylon server started against a copy of T3's database records those ids as already applied and then dies on the first query with `no such column: continued_from_thread_id`. Reading it is still fine; seeding from it is not.
+- Snapshot the database with `VACUUM INTO`, which is safe even while a server has the source open and yields one consistent file:
+
+  ```bash
+  mkdir -p .t3/userdata
+  # Use a fresh destination; VACUUM INTO refuses to overwrite an existing file.
+  bun -e "new (require('bun:sqlite').Database)(process.env.HOME + '/.pylon-code/userdata/state.sqlite', { readonly: true }).run(\"VACUUM INTO '.t3/userdata/state.sqlite'\")"
+  ```
+
+  A plain `cp` is only safe when no server has the source open, and must bring the `-wal` and `-shm` siblings along. A live file copy is a corrupt copy.
+
+- Bring `secrets` and `settings.json` only if the flow under test needs them.
+- Copy in, never symlink. Data flows one way: into your sandbox, never back out.

.agents/references/product-identity.md

@@ -0,0 +1,18 @@
+# Product identity
+
+Read for branding, packaging, launch identity, or upstream desktop adoption.
+
+## Compatibility names
+
+Pylon still retains upstream compatibility identifiers such as `.t3`, `T3CODE_HOME`, `t3.json`, `npx t3`, `@t3tools/*`, `com.t3tools.*`, and some T3-named source files. Treat those as implementation details, not product copy. Do not rename compatibility identifiers during branding or UI work unless the developer explicitly expands the scope and the migration is handled across every client and connection mode.
+
+The desktop product identity is deliberately independent from T3 Code so both apps can be installed and run at the same time. Preserve these Pylon-owned boundaries when adopting upstream desktop work:
+
+- macOS/Windows application ID: `com.pylon.code` (`com.pylon.code.dev.*` for local development);
+- renderer protocols: `pylon-code://` and `pylon-code-dev://`;
+- runtime home: `~/.pylon-code` unless explicitly overridden;
+- Electron profiles: `pylon-code` and `pylon-code-dev`;
+- Linux executable/registration: `pylon`, the per-channel desktop entries `com.pylon.code.desktop`, `com.pylon.code.nightly.desktop` and `com.pylon.code.dev.desktop`, and the matching `com.pylon.code[.nightly|.dev]` WM class and Wayland app ID (Electron derives both from the desktop entry, and XDG portals require a dotted ID);
+- packaged app and artifacts: `Pylon (Alpha)` / `Pylon (Nightly)` and `Pylon-*`.
+
+T3-named environment variables may still be passed to the bundled compatibility server. They are not permission to point Pylon at T3's default runtime or Electron data directories.

.agents/skills/effect-server/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: effect-server
-description: Implement and review Pylon server changes with the repository's Effect and event-sourced architecture. Use when changing `apps/server`, Effect services or layers, orchestration commands and events, deciders, projectors, reactors, receipts, provider adapters, server-side contracts, persistence, or focused backend tests.
+description: Implement or review Pylon Effect services and event-sourced server behavior.
 ---
 
 # Effect Server Work
@@ -9,7 +9,7 @@ Keep orchestration pure, put provider-specific complexity at adapter boundaries,
 
 ## Load the local conventions first
 
-Before writing Effect code, read `.repos/effect-smol/LLMS.md` completely. It documents the repository's vendored Effect APIs and takes precedence over recalled upstream patterns.
+For the Effect APIs being changed, consult the relevant sections of `.repos/effect-smol/LLMS.md`. It documents the repository's vendored Effect APIs and takes precedence over recalled upstream patterns.
 
 For orchestration work, also read the relevant sections of `docs/internals/glossary.md` and inspect the neighboring implementation and tests. Never edit or import from `.repos/`; it is a read-only reference.
 

.agents/skills/ios-debugger-agent/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ios-debugger-agent
-description: Build, launch, inspect, and drive iOS apps with the repository-configured XcodeBuildMCP server. Use on macOS for iOS Simulator builds, focused native test runs, semantic UI automation, screenshots, logs, or debugging, including Pylon Mobile verification.
+description: Build, inspect, and debug an iOS Simulator app using the pinned XcodeBuildMCP tools.
 ---
 
 # iOS Debugger Agent

.agents/skills/pylon-branding/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: pylon-branding
-description: Maintain Pylon's visual identity across source vectors, generated app icons and favicons, in-product marks, wordmarks, and product-name copy. Use when changing Pylon logos, icons, branding, colors, typography, or visible naming; when validating branding across web, desktop, mobile, and marketing; or when an upstream merge may have restored T3 assets or copy.
+description: Change or audit Pylon brand assets, product naming, and generated app icons.
 ---
 
 # Pylon Branding
@@ -9,7 +9,7 @@ Keep brand changes source-driven and consistent across every affected surface. S
 
 ## Establish the scope
 
-- Read `AGENTS.md`, especially **Compatibility names** and **Hit every surface**.
+- Read `.agents/references/product-identity.md` for exact compatibility and product identifiers.
 - Treat `.t3`, `T3CODE_HOME`, `t3.json`, `npx t3`, `@t3tools/*`, `com.t3tools.*`, URL schemes, and legacy source filenames as compatibility identifiers. Do not rename them during visual-brand work unless the developer explicitly requests a coordinated migration.
 - Keep typography, color, naming, and logo changes as separate decisions when the request limits scope. Do not change fonts merely because a logo or wordmark changes.
 - Inspect the current diff before editing. Preserve unrelated upstream or user changes.